クラウド・セキュリティを学んでみよう！：運用編

脅威情報
2011.7.8
更新日：2018.3.15

※本記事は、マカフィー株式会社　コーポレートサポート本部　本部長　諸角昌宏によるものです。

第1回から第5回までは、クラウド・セキュリティ・ガイダンスの「ガバナンス編」について説明しました。これからは、セクションIII　「運用編」についての説明を行いたいと思います。今回は、「運用編」中で、「ドメイン8：伝統的なセキュリティ・ビジネス継続性・ディザスタリカバリ」、「ドメイン9：データセンター運用」、「ドメイン10：インシデント対応、通知および復旧」について説明します。

ドメイン8：　伝統的なセキュリティ・ビジネス継続性・ディザスタリカバリ
クラウドコンピューティングが新しい技術を使っているとしても、伝統的なセキュリティ、ビジネス継続性、ディザスタリカバリの必要性は基本的な保護要件であるため、これらが無くなることはないでしょう。ビジネスと技術が大きな転換を続けていても、伝統的なセキュリティ方式は残るべきであり、その中で起こりうるリスクについて議論し、試験を進め、より良いリスク管理モデルにしていくことが重要です。

このセクションでは、クラウドコンピューティングにおけるセキュリティの問題点とそれに対するガイダンスとして、事業者、利用者、監査機関/標準化組織の点から説明しています。

1. 問題点

サイロ型のアプローチ、すなわち、アプリケーションや組織ごとに物理サーバーを設置しているようなインフラのアプローチをクラウド環境に適用すると、内部からの脅威に対して非常に大きな脆弱性を持つことになります。
クラウドプロバイダーの施設は、重要インフラ（電力、水など）や地形（地震、ハリケーンなど）に依存します。このプロバイダごとの違いに影響を受けることになります。
アウトソーシングに伴う責任、アカウンタビリティなどについて、プロバイダーと利用者の間で混乱を引き起こす可能性があります。
物理的なアクセスが切り離され、論理的なアクセス制御になります。このため、サイロ型のアクセス制御が適用しにくいことになります。
スピード重視のクラウド設計思想から、セキュリティポリシーの充実が図られなくなる可能性があります。また、手順やトレーニングが不十分な状況で運営されてしまう場合もあります。

2. ガイダンス
事業者が行うこと [外部系]

見込みのあるクライアントの中で、最高レベルのセキュリティ要件を調べてください。これにより、利用者の要求よりも厳しいセキュリティ・ベースラインを提供することができます。
様々なコンプライアンス（国際法、国法）規格を調査し、業界標準に則った伝統的なセキュリティ、ビジネス継続性、ディザスタリカバリの問題点を確認してください。

[人系]

従業員のスクリーニングプロセスを使用して、悪行従業員への定期検査と不正使用の確認を実施してください。
アクセスは、仕事上それを必要とする人だけに限るようにしてください。職位や組織の立場によって、アクセス権を認めてしまうようなことはしないでください。
内部および外部の両方のスタッフに対して、頻繁にリスク評価を行うようにしてください。
会社全体、全従業員に対して、セキュリティ文化の展開を行ってください。

[ファシリティ系]

クラウドに使用するデータセンターの物理面、および、サイバー面から、調査を行ってください。
データセンターへの物理的なアクセス制御を実装し、維持してください。
潜在的なインフラの問題を頻繁にレビューするプロセスを作成し、HVACテストなどを行ってください。
伝統的な物理的セキュリティへの投資を行ってください。違反行為や侵入者などに迅速に対応できるようにしてください。

利用者が行うこと

クラウドに置くデータの把握とセキュリティ要件の明確な理解をしてください。
事業者への確認事項として、以下の点を行ってください。
- 物理的、人的なセキュリティ、ディザスタリカバリ、ビジネス継続性の点検を行ってください
- 重要な機能のリカバリ目標の誓約書を入手してください。
- セキュリティに関する契約上の責任を要求してください。契約書には、責任を回避する（免責事項）ように書かれている場合があります。
- インフラの相互依存性を明確にしてください。
- 事業者のオンサイト査察をいつでもできるようにしておいてください。
- セキュリティ、ビジネス継続性、ディザスタリカバリについて、利用者のポリシーおよび手順に結び付けてください。また、包括的なエンタープライズリスクマネジメントに反映させてください。

監査機関、標準化組織が行うこと

規格の更新と変更を実施してください。これにより、クラウド環境のアーキテクチャと運用の違いを常に説明できるようになります。
基準と規則の構造を柔軟に作成してください。これにより、技術とビジネス・プラクティスの変化に対応できるようになります。

ドメイン9：データセンター運用
クラウドコンピューティングが拡大されるに従って、そのインフラであるデータセンターも、同様に拡大していきます。クラウドコンピューティングを最大限、効率的に行うためには、データセンターをインフラおよび管理の両面から考えていく必要があります。

クラウド向けデータセンターでは、リソース共有の最大化を行い、営業利益率を最大にすることが必要です。特に、社内のデータセンターではピークに合わせたリソース設計の必要性から、リソースの有効利用という面では難しい部分がありましたが、クラウド向けデータセンターでは、これを最大限に行うことが可能になります。一方で、リソースの共有を最大化すると、セキュリティを保証するためのリソースの区画化やセグメント化の保証が懸念されます。従ってクラウドの利用者は、たとえ多くの時間を必要であるとしても、クラウド事業者がデータセンターをどうのように管理しているかを理解すべきです。このためのガイドラインとして、以下の点について十分押さえておく必要があります。

クラウド事業者がドメイン1の「クラウドコンピューティングの5つの特徴」をどのように実行し、その技術とインフラストラクチャが彼らのサービスレベルアグリーメント(SLA)にいかに影響するかを理解すべきです。
クラウド事業者のインフラに技術的相違がある限り、彼らは完全なシステム、ネットワーク、マネジメント、プロビジョニングおよび個人の包括的な区分を明らかにすることができます。
もし実行可能であるならば、クラウド事業者によるビジネスの変化が顧客経験に影響を与えるかどうかを評価するために、別の利用者を見つけと良いでしょう。
リソースの民主化がクラウド事業者の中で起きた時に、利用者のビジネス変動にどのくらいシステムの可用性やパフォーマンスをもたらすか理解すべきです。
IaaS、PaaSについては、クラウド事業者のパッチ管理ポリシーおよび実行手順、またそれが開発されたアプリケーションにどのように影響するかを明確に理解するべきです。この理解は契約書の文言に反映されるべきです。
ドメイン8で述べたように、ITの点から事業継続とディザスタリカバリを見直し、それがいかに社員およびプロセスに影響するかを検証すべきです。クラウド事業者は技術的なアーキテクチャとして新規で実績が証明されていない手法を使うことがあります。利用者の事業継続計画はクラウドコンピューティングのインパクトと限界に対処する必要があります。
クラウド事業者の顧客サービス機能を定期的にテストし、彼らのサポートレベルを判断すべきです。

ドメイン10：インシデント対応、通知および復旧
クラウドのインシデント対応は、基本的に、展開されているアプリケーションに影響を及ぼすインシデントへの対応ということになります。そのインシデントとしては、OWASPから出されている以下のトップ10セキュリティ脆弱性で代表されます。

OWASP Top 10 for 2010

A1: Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

クラウド・セキュリティ・ガイダンスでは、以下の3つの問題点を提起しています。

クラウドで展開されているアプリケーションは、必ずしもセキュリティの面から設計されていません。その結果、脆弱性のあるアプリケーションが存在し、これらがインシデントを引き起こす原因となっています。
クラウド事業者の従業員がアプリケーションの管理していないデータにアクセスする、プライバシーの問題が存在しています。
SaaS,　PaaS,　IaaSなど、大手のサービス事業者のサービス提供形態が複雑化しており、インシデント対応に関して重大な問題をもたらしています。

クラウド事業者は、このようなインシデントに対して、以下の2つの責務を持ちます。

インシデントの特定と通知
アプリケーション・データへの犯罪的アクセスに対する修復措置のオプションの提示

クラウド化が進むにつれて、これらを狙ったサイバー犯罪も増加する傾向にありますので、注意が必要です。

では次に、クラウド上におけるアプリケーションの脆弱性対策について説明します。

クラウド上のアプリケーションは、ファイアーウォール（FW）、不正侵入検知システム（IPS）、アプリケーションレベルのファイアーウォール（WAF）などで探知され、イベントとして連絡されます。アプリケーション・フレームワークでは、OWASP脆弱性に対するプロテクション機能を提供するコンポーネントを提供しています。さらに、ユーザー側においても検知を行い、アプリケーション・オーナーに対して通知することが必要になります。さらに、アプリケーションレベルのロギング機能により、トラフィック分析、インシデントの報告に活用されます。このようなクラウド上でのアプリケーションの脆弱性対策が必要になります。

次に、インシデントの通知ですが、数多くのアプリケーション所有者がいる場合には、通知プロセス自体が複雑になりますし、通知方法も同じにはなりません。従って、クラウド事業者は、アプリケーションインターフェース（URL,　SOAサービスなど）ごとに、アプリケーション所有者のレジストリを作成し、インシデント発生時に誰にコンタクトするかについて明確にしておく必要があります。

最後にインシデントからの復旧ですが、クラウド事業者と利用者の間で、インシデントによるサービスの停止時間を最小化するための適切な改善方法を決めることが必要です。しかし、情報漏えいや悪意のある使用が検知された際、最初に取られるアクションはアプリケーションのシャットダウンであり、問題が完全に診断された後に復旧が完了するのが現実です。

次回は、運用編の第2回として、クラウド・セキュリティ・ガイダンスの「ドメイン11：アプリケーション・セキュリティ」、「ドメイン12：暗号化と鍵管理」、「ドメイン13：アイデンティティとアクセス管理」について説明します。

*本記事は、弊社「クラウド・セキュリティ・勉強会」メンバーである、藤井大翼、桐谷彰一、中山幹夫の協力により、執筆されました。