クラウド利用時にクリアすべきリスクと課題：なぜクラウドは「不安」なのか（後編）（2/3 ページ）

[篠崎将和，NRIセキュアテクノロジーズ株式会社]

技術的観点からみた課題

　技術的な課題に関しては、技術進歩に伴い改善されていくものと予想される。要素技術について課題を掘り下げていくとかなり細分化されてしまうため、ENISAでも取り上げられている4つの分類、

• ネットワークのセキュリティ
• ホストのセキュリティ
• アプリケーションのセキュリティ
• データのセキュリティ

で整理した。

　課題の傾向をみると、クラウド事業者側で対応しなければならないものが多いが、利用者側でリスクを軽減したり、リスクの影響を小さくするなど対応可能なものもある。SaaS／PaaS／IaaSなど、利用するサービスによっては対応できないケースもあるので、実際の利用ケースを想定してリスクおよび課題を参照してほしい。

　クラウドサービスは“マルチテナント”であること、仮想化技術や分散処理技術を利用していることから、同じシステムを社内に導入した場合と比べてリスク要因が多く、リスクの影響範囲もより大きい。　ネットワークのセキュリティは事業者側で対応しなければならない課題が多いが、通信の暗号化など利用者側でも対応可能なケースもある。アプリケーションに関しては、PaaSやIaaSを利用する場合には利用者側でセキュリティ対策を行う必要がある。クラウド事業者がアプリケーションを提供するSaaSとはこの点が異なる。

　ホスト（サーバ）のセキュリティについても、PaaSやIaaSでは利用者側が定常的にシステム監視を行うことにより、セキュリティ上の危険が発生したときは迅速に対応することが可能となる。特に仮想マシンのセキュリティについては注意が必要だ。クラウド環境ではIaaS上で簡単に仮想マシンを複製することができるため、セキュリティの脆弱な仮想マシンを数多く作ってしまうケースが多い。仮想マシンを最初に作成する際に、十分にセキュリティ設定を考慮し設定を施した仮想マシンイメージを作成し、このイメージから複製を作成する作業手順を確立しておくことが重要である。

　データのセキュリティについては、転送中と保存時のセキュリティを分けて考える必要がある。転送中のセキュリティは、クラウド事業者のネットワークのセキュリティに依存してしまうが、保存時のセキュリティはデータの暗号化などにより利用者側で対応可能である。

　データを暗号化する際は暗号化キーの管理が最大の課題となる。暗号化キーは利用者が管理するのが最もセキュリティが高いが、利用者側での管理作業が煩雑になる。このためKMIP（Key Management Interoperability Protocol）のような暗号鍵管理プロトコルを用いて暗号化システム間を接続することが解決策の1つとして提案されている。

大分類	小分類	リスク・課題の内容
技術	ネットワークのセキュリティ	・通信路(クラウド事業者内、クラウド事業者間、利用者とクラウド事業者間)の信頼性と通信品質の確保 ・中間者攻撃、なりすまし、サイドチャネル攻撃、リプレイ攻撃などによる通信盗聴【注】 ・DoS攻撃やDDoS攻撃による、自社システムに対する直接的なサービスの妨害、他社システムに対する間接的なパフォーマンスへの影響
	ホストのセキュリティ	・マルチテナント環境下での利用者間の情報漏えい（ストレージ、メモリ、ルーティングなどの設定不備、OSやWebアプリケーションサーバの脆弱性対策不備）
	アプリケーションのセキュリティ	・アプリケーションのポータビリティ（クラウド事業者と自社システム間、クラウド事業者間） ・EDoS攻撃によるサービス利用料金の増加【注】 ・アプリケーションに対するインターネット越しのペネトレーションテストの実施が事業者から許可されない
	データのセキュリティ	・利用者がデータ削除やサービス解約を行った後のデータ復元や情報漏えい ・クラウド事業者におけるデータ削除が証明されず利用者が確認できない ・データ保存時の暗号化の必要性、暗号化キー管理の必要性
表2　技術的観点からみたリスク・課題

【注】
サイドチャネル攻撃：
暗号装置の動作を読み取る手法の1つ
リプレイ攻撃：
ログイン情報を盗聴し同じデータを使って不正にアクセスする手法
EDoS攻撃：
不正アクセスにより膨大な従量課金の料金を発生させる手法

運用の観点からみた課題

　クラウドサービスはブラックボックス化されているがために、利用に際しては契約約款やSLAの内容に留意することに加え、締結した内容に従ったクラウド事業者のサービス履行に関しても留意が必要である。

　運用段階では、実際に提供されているサービスレベル品質や、事業者側のインシデント対応状況を利用者がモニタリングすることが重要である。利用者のデータがクラウド上の複数のサーバ上に保存されているケースでインシデントが発生した場合に、クラウド事業者はどこまで調査を実施してくれるか、事前に確認をしておきたいところである。

　加えて、ITリソースの利用状況もあわせて確認し、状況に応じて設定を変更することも必要である。これを適切に行わない場合、利用者は予期しない金銭的負担を強いられることにもなりかねない。期間限定で公開をしていたサーバの利用終了手続きを怠ると、いつまでも課金される恐れがある。また、柔軟な伸長性により想定額以上の料金を支払うことも想定される。

　もう1つの課題は、内部統制にかかわる監査である。クラウドの特性を考慮した監査基準が確立されると利用者としては安心できるのだが、クラウドサービス向けの明確な監査基準はまだできていない。これについては今後の課題であろう。

大分類	小分類	リスク・課題の内容
運用	サービスの監視	・従量課金の正確さの確保、不正利用の排除 ・適切なログ取得とユーザーへの提供、モニタリング機能の提供
	アクセスコントロール（ID管理）	・仮想OSやハイパーバイザへのアクセスコントロール ・ユーザー利用端末の認証 ・自社システムとクラウド環境での統合認証方式
	パッチ管理・脆弱性管理	・クラウド内（仮想OS、ハイパーバイザ）のセキュリティ対策 ・パッチマネジメント
	インシデントレスポンス	・インシデント発生時の原因究明や解析などに利用するログの取得（ログの種類とタイミング） ・クラウド環境におけるインシデント調査のレスポンスタイム ・利用者側のインシデント調査チームによるクラウド事業者環境への立ち入り調査の実現性
	構成管理	・クラウド構成機器の設定ファイルが事業者側で変更された場合における、利用者側のバージョン判別 ・複数のクラウドサービスを同時に利用した場合の社内システムの全体把握
監査	クラウドサービス利用者側	・クラウド事業者への監査要求が受け入れられない可能性
	監査実施者側	・クラウド監査技法の整備（既存の保証型監査との関連性確認など） ・多数の利用者からの監査要求に対応するための監査法人の人材確保
表3　運用の観点からみた課題