クラウドサービスといっても幅広く、セキュリティを考える際にも、クラウド利用者とクラウド事業者では講じる対策も全く異なります。また、利用者側といってもどのようなクラウドサービスを利用するかによって考慮すべきセキュリティ対策は異なります。
例えば、クラウド事業者が提供するソフトウェアサービス（Saas）は事業者側のセキュリティ対策に依存しがちです。ここでは、利用者が拡大しており、かつ、利用者側のコントロールが限定的なSaasを利用する際に、セキュリティの観点からチェックしておきたいポイントを考察します。
目次
１．クラウドのサービスモデルと責任共有モデル
まず前提として、クラウドには大きく以下の３つのサービスモデルがあり、提供形態がそれぞれ異なります。
|
サービスモデル |
内容 |
代表的なサービス |
|
SaaS(Software as a Service) |
サービスの形で提供されるソフトウェア |
Salesforce.com |
|
PaaS (Platform as a Service) |
サービスの形で 提供されるプラットフォー ム |
GoogleAppEngine |
|
IaaS (Infrastructure as a Service) |
サービスの形で提供されるインフラストラクチャ |
AWS |
そして、クラウドサービスのセキュリティについては、利用者・事業者の一方がすべての責任を負うのではなく、利用形態に沿って責任を分担する「責任共有モデル」という考え方がります。
例えば、Iaasの代表的なサービスであるAWSでは以下のモデルを提示しています。
※詳しくは、AWSの責任共有モデルを参照ください。
この責任共有モデルはサービスモデル（クラウドの利用形態）に応じて異なります。下記のイメージの通り、とくにSaasは利用者側のコントロール範囲が狭く、セキュリティ対策においても事業者側の対策に依存する傾向が強くなります。
クラウドサービスのメリットとしては、
・需要に応じてスケールアウト／スケールインできるスピーディな拡張性
・ネットワークを通じて様々なデバイスから利用できる利便性
・リソース（ストレージ、処理能力、メモリ、ネットワーク帯域）の共用による効率性
などが挙げられます。
一方で、上記でご紹介した通り、とりわけSaasは事業者（プロバイダー）側のコントロール範囲が広く、セキュリティ対策も事業者側に依存しなければならない部分が多く、セキュリティの観点で言うと利用者側は主に以下の点を注意したいところです。
・その事業者のポリシーが、自社のセキュリティポリシー上許容できるか
・事業者側ではどのようなセキュリティ対策を講じているか
上記を踏まえて、ここでは、利用者側のコントロールが限定的なSaasを利用する際に、セキュリティ上どのような点に注意していくべきかについて考察します。
2．導入予定サービスのセキュリティ体制を確認する
まず、導入を検討しているサービスがどのようなセキュリティポリシーを持っていて、具体的にどのような対策をしているのか、確認しておきたい主な項目を見ていきます。
2-1 プライバシーポリシーの確認
プライバシーポリシーはその企業の個人情報やデータの取扱い・保護への考え方といえるものです。収集した情報の利用目的・利用範囲、その組織が業務委託している場合には第三者への開示や共同利用などの記載を確認しましょう。
2-2 ネットワークの対策
・通信の傍受への対策
クラウド環境におけるネットワークでの通信が傍受されないような対策を行っている必要があります。通信経路も暗号化されていることが望ましいでしょう。
・中間者攻撃やなりすましへの対策
中間者攻撃とは、通信している二者間に第三者が介在し、送信者・受信者になりすまして通信を盗聴・制御されることをいいます。代表的な対策として、デジタル証明書による本人確認・強力な暗号化などが挙げられます。
・ネットワークのキャパシティ
クラウドサービスの利用時におけるネットワークの通信量・接続機器の数といったキャパシティも考慮する必要があります。利用状況に応じて柔軟に対応できる構成の管理・キャパシティの管理ができるかという視点でも検討しましょう。
2-3 物理的な対策
・外部対策
サイバー攻撃はネットワークからの攻撃だけではなく、データセンターへの侵入によってシステムに障害を与えたり、データを搾取する可能性もありますので、物理的な侵入対策が必要です。
以前はセキュリティの観点からデータセンターの位置情報を明確にしないことが一般的でしたが、近年は災害に備えてデータセンターの位置の把握をしたいという利用者の要望から、データセンターの大まかな位置が公開されているケースもありますので、複数拠点でのバックアップや所在地域による災害リスクなどを把握しておくこともできます。
・内部対策
データセンターへの入退出管理、機器へのアクセス認可レベルを確認することで、誰が・どの居室に入出できて・どの情報レベルにアクセスできるかが把握できます。
2-4 その他
・アプリケーション（ソフトウェア）へのアクセス制御
パスワードの複雑さだけではなく、二段階認証など単体のパスワードの強度だけに依存しない対策を行うことも重要です。
・サイトのフィッシング対策
なりすましによるID・パスワードの搾取などについてどのような対策をしているのか確認しましょう。
３．自組織のセキュリティポリシー上許容できるか確認する
3-1 自組織のコントロールが効かないネットワーク
事業者側のネットワークがDOS攻撃を受ける、他社も利用するネットワークですので他社の管理不備に巻き込まれるといった可能性があります。ネットワークのセキュリティについてどのような対策が講じられているのか確認しましょう。
3-2 自組織のファイアウォールを通過していない
事業者のネットワークへのアクセスについて、自社では許可していないIPからの通信が発生している可能性もあります。また、社員が社外から通信するときには自社のコントロールがきかないため、
データの授受などについてどのような制限（ログインできるIPアドレス、ログインできる時間の制限など）をしているのか確認しましょう。
3-3 アカウント、パスワード管理
プロバイダー側の管理運用ルールが自社のポリシーと合わないケースがあります。
ソフトウェアや情報へのアクセスについて利用者ごとに権限のコントロールができるか、利用者個人ごとにIDを発行しているかといった管理上の確認だけでなく、パスワードの設定文字列・有効期間・過去パスワードの利用回数制限・ログイン失敗によりロックするまでの回数など自組織のポリシーと対比して確認しましょう。
４．事業者との合意（SLA）
クラウドサービスで利用されている技術は先進的なものも多く、脆弱性の客観的な検証が難しいケースもあります。新しいアプリケーションを開発する際に事業者側がどのようにセキュリティを担保しているか、第三者機関による監査を受けているか、その他セキュリティ管理体制を含めてSLA（Service Level Agreement）上、確認しておく必要があります。
経済産業省のSaaS 向け SLA ガイドライン（PDF）でも、JIS Q 27001:2006、JIS Q 27002:2006 に基づくセキュリティ監査・システム監査、ペネトレーションテスト等ネットワークからの攻撃に対する検証試験、ウェブアプリケーションの脆弱性検査の実施と結果の提示を求めることなどが推奨されています。
SLAのレベルを引き上げるとコストも増加する可能性がありますが、自組織のSaas利用時のポリシーを明確にしたうえで、適切な事業者を選定しましょう。
著者：マカフィー株式会社 マーケティング本部
