最後にセキュリティ面のリスクについて見ていこう。システム障害とは種類が違うが、パブリッククラウドを採用する際には避けて通れない問題である。
パブリッククラウドにおけるリスクとしては(1)IDの不正利用、(2)プラットフォームの脆弱性を利用した不正アクセス、(3)運用ミスによる情報漏洩、の三つが想定される(図10)。これら三つのリスクは、それぞれユーザー/クラウド事業者の責任範囲が異なるので注意が必要だ。
まず、ID管理については、適切な管理ができていないなど、ほとんどの場合はユーザーの責任下にある。プラットフォームの脆弱性に関しては、IaaSではユーザー側で対処すべき点が多く、PaaS/SaaSではクラウド事業者の責任によるところが大きい。情報漏洩についてはクラウド事業者、ユーザーのどちらでも運用ミスが起こり得る。セキュリティ被害自体はいつか必ず「起こるもの」と考え、被害を最小限に食い止める対策が必要になる。
まずは管理者のIDを守る
ID管理については、まず最優先に考えるべきは管理者のアカウントである(図11)。管理者権限はシステムに対して何でもできる力を持つ。管理者のアカウントを悪用されると、情報を盗み出されたり、全データを消去されたりといった恐れがある。しかもパブリッククラウドの場合、インターネット経由でどこからでも悪用されかねない。
管理者IDを守るには次の三つの方法を適宜組み合わせる。(1)認証要素の追加、(2)役割に応じた権限の分離、(3)認証ゲートウエイの追加──である。事業者に対して「管理者IDの利用をモニタリングする仕組みが存在するか、悪用された場合に早急に変更する方法があるかも確認しておくといい」(デロイトトーマツリスクサービスの谷口パートナー)。
追加できる認証要素はクラウドサービスごとに異なる。例えばAWSではオプションで、管理者のログイン時にワンタイムパスワードを利用できる。AWSのクラウドサービスの導入支援を手掛ける野村総研の矢口上級テクニカルエンジニアは「今後、管理者アカウントのワンタイムパスワード認証は標準的な手法になるだろう」と見る。SFDCでは通信元のIPアドレスを制限して、特定の場所(厳密にはネットワーク)以外からは利用できない設定が可能だ。
役割に応じた権限管理は、やはりAWSに先進的な機能がある。アプリケーション開発者、運用担当者、監視担当者、経理担当者などの立場ごとに、仮想マシンの消去や追加、ソフトの書き換え、電源のオン/オフ、稼働状況の監視、利用料金の確認などの権限を設定できる。
三つめの認証ゲートウエイの設置は、サードパーティーのソフトやサービスを利用する。シマンテックの「O3(オゾン)」などのソフトが代表例だ。導入すると、認証ゲートウエイ側で認証手段や操作ログ収集を実施できる。加えて、複数のクラウドサービスへのシングルサインオン、ディレクトリーサービスとクラウドの権限管理の連携なども可能になる。ただ、ほかの二つの方法よりも導入コストがかかる。