クラウドサービスの安全性を考える

クラウドサービスの
安全性を考える
Daisuke Nakazawa ( @diceken )

2012/07/23作成
12年7月23日月曜日

この資料は何？

• クラウド(サービス)はどこまで信頼できるか

• クラウドの特徴を正しく理解する

• クラウドの特徴に合わせ適切な運用形態を取る

※本資料は、私的活動で作成した物です。

※併せて読むと色々ると思います(本資料は後編に当たります)

http://www.slideshare.net/DaisukeNakazawa/ss-9659705


about me

• 所属：NTTコミュニケーションズ

• 職業 : (自称)ITアーキテクト

• twitterID : @diceken


「クラウドは信頼できる？」
結論から！

• ケースバイケースです

• お茶を濁している訳ではありません

• 良い面悪い面のトレードオフです


そもそもクラウド系サービスの
品質を左右する要素は何か？

「通常のシステムと同様の要素に、クラウドを
実現している仕組みも加わる。」

※当たり前だと思われた方、その通りです。


そもそもクラウド系サービスの
品質を左右する要素は何か？
クラウドサービス基盤の持つ特徴的な性質

1. 自動化対象・適用範囲が広い

2. 共通のロジックにより運用されている

3. 共用環境である(Public Cloudの場合)

4. プロビジョニングも含まれる


1.自動化対象・適用範囲が広い
• 対象 • 適用範囲

• VM構築/VM削除 • DCの全サーバー

• ネットワーク割当/解放 • １サービス基盤全体

• ストレージ割当/解放 • １ユーザ全て

• データベース作成/削除 • 1VM

• バックアップ作成/削除

• パッチ適用


1.自動化対象・適用範囲が広い

• メリット

• 自動化作業範囲での人為ミスが発生しない

• 人的コスト不要のためコストパフォーマンスが非常に良い

• デメリット

• 自動化ロジックの不備があると・・・

• 処理の永久ループ等が発生しネットワークが輻輳

• 誤ったデータを削除したり(F社事例)


2.共通のロジックにより運用されている

• メリット

• 枯れたロジックであれば非常に安定的

• デメリット

• 融通が利かない

• ロジックに誤りがあると・・・

• 複数ユーザーが纏めて同じ被害に遭う場合も


3.共用環境である
(Public Cloudの場合)

※事業者毎に設計思想が異なるため、Private Cloudでも当てはまる場
合、Public Cloudであっても当てはまらない場合もあります

• シェアードストレージ→複数顧客に影響

• 同一基盤を利用→基盤障害は多数の顧客に影響
※こちらは従来でもネットワークの世界では良く見られた光景

• 同一ソフトウェア基盤環境を利用している(SaaS)→セキュリティ脆
弱性により他人のデータが見えてしまう等のリスクも生じる。


4.プロビジョニング

• 高度な自動化＝暴走可能性の拡大

• オーバーコミット等の予約処理の暴走

• リカバリ処理等の高負荷処理の暴走

• 変更処理適用/Purge処理等の暴走

つまり暴走に起因するデータ破壊や高負荷のリスクがクラウドでは若干
高い。(勿論オンプレでも起こる時は起こる)


オンプレミスなら安全？

• オンプレミスでもデータ消失や接続障害は(思っているよりも)頻繁に
起こる

• データ消失 => RAIDを信頼し過ぎたり、手順誤りがあった
り・・・。

• オンプレミスは表沙汰になりにくい

• クラウド系と異なり毎回個別作り込みの為、枯れていない手順はむし
ろクラウドよりリスクが高い



• オンプレミスは個別に作り込み、費用も多く
積むため、性能のコントロールや、運用の想
定された挙動に対する入念な検証がし易い

• 特に障害後の復旧を手動に出来る所が大きい

• クラウド(特にPublic)はリカバリも含めた全自
動が多いため、割り切った設計にしている傾
向にある



• オンプレミスであっても、単体ソフトウェア
のバグの痛みは等しく受ける。(古いカーネル
タイマーを使ってたら一斉にサーバーが再起
動したりとか・・・)


つまり？

クラウドで特に考慮すべき事項は

1. 基盤共有によるセキュリティリスク耐性

2. 基盤障害への耐性

3. データ損失への耐性


1.基盤共有によるセキュリティリスク耐性

• 基盤共有には必ず基盤のコントローラを狙われる危険が付き纏う

• 無論クラウドサービス毎に防御措置は行っているが、「絶対に」
安全だとは勿論言えない

• 完全に閉じたコントロール下に置きたい（会社の存続、人命に関
わるようなデータ)のであればオンプレミス、近いレベルを求める
場合はプライベートクラウド、ホスティング＆ハウジング、と言っ
た選択肢は有用。

• 大半のケースではパブリックで問題は無いと考えられる


2.基盤障害への耐性

• 重要度に応じて多拠点運用を想定する

• グローバルサーバーロードバランサーの導入(DNS Round Robin)

• 内部ロードバランサーによる切り替え

• APサーバーの多拠点構成

• データベースの多拠点レプリケーション

• バックアップの多拠点化(オブジェクトストレージ等の活用)

• 場合によっては2事業者間、オンプレミスとの冗長化を検討する。

• 肝になるのはデータベース


3.データ障害への耐性

• 1にも2にもバックアップ

• 同期レプリケーションは断時間の短縮に極めて有効
※パフォーマンスへの影響は大体残念な感じになるが、一般的に
大人の対応で許容する(大人になれない場合はインメモリ＋低レイ
テンシー環境で高速化或いは非同期)

• バックアップ方式とレベルは重要度を鑑みて決める

• リカバリ方法/レベル/時間を意識する


3.データ障害への耐性

• 同期/非同期

• 単体/拠点間/クラウド間

• 一方通行/同期

• 論理/物理

• 差分増分/差分/フル

• 自分で取る/サービスに任せる/双方で取る


Any QuestionS?


クラウドサービスの安全性を考える

More Related Content

What's hot

Similar to クラウドサービスの安全性を考える

クラウドサービスの安全性を考える