AWSにおけるセキュリティとコンプライアンスのベストプラクティスを読んでみた

#セキュリティ

#AWS

横田あかり

2013.08.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

sec-999

AWSは今エンタープライズ祭り

AWSと聞いて、ホームページを運営するためのレンタルサーバーぐらいに思っている方は認識を改めた方が良いかと思います。今、AWSをエンタープライズ分野で利用する企業が増えています。そこで、必ずといっていいほど出てくるキーワードが、セキュリティです。まぁ、自前でラックを用意して運用するよりも、AWSに預けた方が安全なのは明らかなのですが、セキュリティがザルなオンプレからクラウドに移行するにあたって、改めて考えてみようということで読んで頂ければと思っています。今回は、トレンドマイクロ社が公開しているホワイトペーパーを読みながら理解を深めます。

クラウドコンピューティングとは

毎度おなじみの用語の定義です。ここでは、NIST（The US National Institute of Standards and Technology）が定義するクラウドコンピューティングについておさらいしています。

sec-000

サービスモデル

Infrastructure as a Service (IaaS)

コンピューティングリソース、ストレージ、ネットワークなど、OSを含む基本的なコンピュータリソースをユーザが指定して利用する形態のサービスです。OS上で動かすソフトウェアには制限が無く、OSやミドルウェアの設定をほぼ自由に行うことができます。しかし、クラウドインフラ以下の層を操作することはできません。サービス例：Amazon Web Services

Platform as a Service (PaaS)

クラウドインフラ上にユーザが作成したアプリケーションを配備できるサービスです。様々なプログラミング言語やライブラリ、サービス、ツールなどを活用して作ることができます。ユーザはクラウドインフラを含む、OS、ストレージ、ネットワークなどを直接的に管理することはできませんが、環境変数の設定を行うことができます。サービス例：Google AppEngine, Microsoft Azure

Software as a Service (SaaS)

ユーザは、クラウドインフラ上で提供されているアプリケーションを利用すうことができます。利用方法としては、ブザウザなどのクライアント端末やアプリケーションインタフェースを用います。ユーザは、クラウドインフラを含む、OS、ストレージ、ネットワーク、環境変数の設定などを行うことができません。ユーザの実行範囲など非常に限定的なアプリケーションの設定を行うことができます。サービス例：Salesforce.com

以下にユーザ（顧客）とクラウドサービスプロバイダーのコントロール範囲を表したものをご覧頂きます。

sec-001

配備モデル

配備モデルとは、クラウドサービスプロバイダーによって提供されるサービスによって、ユーザがどこにアプリケーションをデプロイするのか示したものです。

パブリック

このタイプのクラウドインフラは、公開されているネットワークや巨大企業のインフラを使って提供されるもので、ユーザはその一部を使って、あたかも自分のインフラのように利用することができます。サービス例：EC2-Classic

バーチャルプライベート/オンサイト仮想化

このタイプのクラウドインフラは、単一の組織用に独立しているものです。組織内による管理か、プロバイダーによる管理かで、オンプレミスかオフプレミスになります。サービス例：VPC、VMWare

ハイブリット

このタイプのクラウドインフラは、複数のクラウド環境（パブリック、コミュニティ、プライベートなど）を組み合わせて提供されるものです。標準化された技術やプロプライエタリな技術によってデータやアプリケーションのポータビリティを可能にしています。

簡単に言いますと、それぞれ異なるセキュリティの特徴がありまして、プロバイダー毎のセキュリティーに関する責務は大きく異なってきます。

クラウドサービスモデルに関するセキュリティー責務

クラウド内で実行されている処理について、セキュリティに関する要望に対応するために、まずは責任の所在を確認する必要があります。異なるクラウドコンピューティング環境では、役割や責任が異なります。IaaSモデルのクラウドプロバイダーは、一般的にインフラ部分について責任があり、SaaSモデルのクラウドプロバイダーは、インフラとアプリケーションの保護に責任があります。SPIモデル（SaaS、PaaS、IaaS）は、スタックが上位に移動するとセキュリティコントロールを実装するプロバイダーの責任が増大します。スタックが下位に移動すると顧客の責任が増大します。概念図は以下をご覧ください。

sec-002

例えば、Amazon Web Services (AWS)のようなIaaSモデルの場合、クラウドを活用する上で最も大きな自由を与えられますが、顧客自身がデータやアプリケーションのセキュリティについて積極的に関わる必要があります。ですから、AWSを選択する場合は、それがパブリックかプライベート(VPC)の提供かどうか、リスク軽減のベストプラクティスを理解することが重要です。

クラウドプロバイダーによるセキュリティ共有責任

クラウドコンピューティングが直面している脅威の詳細については特に新しいことではありませんが、その軽減方法と誰が責任を取るのかについては異なります。例えば、従来のITモデルによる"内部の脅威"については、クラウドコンピューティングにも当てはまります。しかし、クラウドサービスを提供する、運営かつ物理でコントロールができるようなプライマリーの場合、脅威の削減についてはクラウドサービスプロバイダーが行います。組織が自分たちのデータを守るためには、以下の３つのタイプのうち１つ以上を選択します。

運営コントロール

運営コントロール（または、手続きコントロールとも呼ばれます）は、ポリシー、手続き、標準ガイドラインに書かれた内容の承認により構成されています。運営コントロールのフレームワークは、ビジネスの実行と人の管理のためにあります。ワークロードが、伝統的な企業のITインフラで実行されている場合、それは物理的にオンプレミス施設かつ/または、管理下の組織によって位置していますので、信頼できる環境であると考えることができます。ネットワークインフラを完全に制御するということは、施設への物理的なアクセスと共に、新しい従業員を雇う際の身辺調査と変更管理プロセスの実装を含みます。

クラウドに移行する場合、アプリケーションとデータは、組織によって直接コントロールすることはできません。クラウドプロバイダーによって外部にホストされるインフラによって管理や維持がされています。組織によって定義された様々なコントロールの導入を通じて、IT環境を直接的に制御する代わりに、クラウドサービスプロバイダーとの関係やサービスレベルアグリーメント(SLA)によって実現されています。これにより、プラウドプロバイダーを選択する場合、組織は指定された運営コントロール、業界の証明書や第三者認証の存在が重要になります。例えば、AWSの場合、aws.amazon.com/awsで見つけることができます。

物理コントロール

物理コントロールは、コンピュータ施設や職場の環境を監視したり制御したりします。また、そのような施設から監視や制御を行います。管理/物理コントロールは、最終的に物理的なセキュリティ制御に依存します。認証してない従業員を遮断する物理的なアクセス制御が無い場合、認証済みの従業員のアクセスを許可するだけでは目的を達成しません。従来のITモデルでは、組織がネットワークと職場環境を分離しながら、コンピュータ施設を守るために物理コントロールを実施し、安全対策を講じる責任がありました。クラウドサービスへ移行する場合は、物理コントロールの実装はクラウドプロバイダーの責任です。

組織の要件を満たしていることを確認するため、物理コントロールを特定したり図示することは理解するために重要です。例えば、AWSインフラは、世界中のアマゾンが制御しているデータセンター内に収容されています。AWS内で正当な業務を担当する人のみ、これらのデータセンターの実際の場所を知ってアクセスする必要があります。警備員、複数の認証、二要素認証など物理的な様々なコントロールによって、自社のデータセンターへの不正なアクセスを全て防止しています。

論理コントロール

論理コントロール（または、技術コントロールとも呼ばれます）は、情報システムへのアクセスを制御・監視するために、ソフトウェアやデータを用います。例えば、パスワード、ネットワークやホストベースのファイアウォール、IPS(侵入検知システム)、アクセスコントロールリスト、データ暗号化や論理制御などです。論理コントロールの実装については、クラウドのサービスモデルによって異なります。IaaSのクラウドサービスモデルでは、システム（例：インスタンス）に関連づけられている論理的な制御の実装について、全てのコントロール権限を持っています。インスタンスを保護するために論理コントロールを選択するときは、以下のような質問に答えられるか考慮してください。

選択したコントロールは、オンデマンドでスケールしますか？
"クラウド対応"であり、インスタンスがスケールアップ/ダウンしたときに瞬時に閲覧できるAPIを提供していますか？
一貫したセキュリティーポリシーを強化を助け、単一のポリシー管理インタフェースを提供するために、既存のITインフラをクラウドインフラへ拡張することができますか？
自動的に新しいリソースを検出し、必要に応じてアクセスコントロールを割り当てる機能を有していますか？
セキュリィーポリシーは、インスタンスがオンライン時に公開する窓口（ポート等）を減らすために、強制的に適応することができますか？
クラウド管理ツールと統合していますか？例えば、暗号化されたデータを保存するために、暗号化ソリューションを選択するとき、それは"クラウド対応"でしょうか？

これらのことから、現在のインハウスのインフラ管理と同じようにクラウドも集中型管理がでで、技術ソリューション上の利点があることがはっきりしました。

クラウドセキュリティとIaaSの共有責任

クラウドプロバイダーを活用する組織では、セキュリティは共有責任となります。以下のモデルは、組織がAWSのようなIaaSを活用し、セキュリティコントロールとセキュリティ対策について責任があることを、様々な領域で図に示したものです。

sec-010

AWSは、ハイパーバイザー（ホストOS）、物理的なセキュリティ、環境的セキュリティ、仮想化セキュリティまでを提供しています。クラウドを利用する顧客は、ITシステム（インスタンス）、ゲストOS（WindowsやLinux等）、ミドルウェア技術、アプリケーション等のセキュリティについて責任があります。

セキュアなクラウド導入のための手順

AWSの顧客は、AWS上で実行されているワークロードのセキュリティを担当しています。これは、インスタンス上で実行されているアプリケーションの保護や、AWS証明書ファイルの保護など含まれています。Amazonは、AWS IAM（ID＆アクセス管理）サービス、二要素認証（MFA）ソリューション、セキュリティグループ、セキュリティ責任を助けるAWS CloudHSMなどのツールを提供しています。また、Amazonは、全てのワークロードにおいて完全な拠点間のセキュリティを実現するために、サードパーティー製のセキュリティソリューションを推奨しています。

以下は、いくつかのベストプラクティスについての議論で、AWS証明書、ゲストOSのセキュリティ、アプリケーションのセキュリティ、AWSセキュリティグループによるファイアウォールの設定について役立ちます。これらのプラクティスは、安全なコンピューティング環境の構築を支援します。

STEP1. ROOTアカウントの利用を止めてIAMアカウントでアクセスする

AWSアカウントは、AWSとの関係を開始したときに作成される最初のエンティティ（モノ）です。このアカウントは、"ルート"アカウントとみなされ、課金情報を含むすべてのAWSリソースへのアクセスを提供します。ルートアカウントの使用は推奨されておらず、代りにIAMサービスを使います。IAMユーザとグループを作成し、ロールを割り当てて、AWSとのやり取りに用います。ある機能要件に対して特定の権限を割り当てることを推奨しています。

権限を用いてユーザーがAWSにアクセスする方法は、グループレベルで権限を割り当てる従来型のITモデルのアプローチと違いはありません。グループは、仕事上の役割（管理者、マネージャ、テスター等）を持って作成することができ、それぞれのグループに対して関連する権限を割り当てます。IAMユーザはそれらのグループにアサインされた時点で権限が適応されます。

AWSリソースへのアクセスを制御するポリシー（権限のセット）を作成するときは、"最低限の権限"モデルを使用します。このモデルに従えば、ユーザーが正しく自分の職務を実行できるように、正しい権限セットの状態にするためのいくつかの調査が必要になります。また、"職務分離"のセキュリティプラクティスを強制するために、AWS IAMグループを活用することできます。Amazonは、事前に定義済みの権限を含む、ビルトインのポリシーテンプレートがデフォルトで用意されています。これらのテンプレートは、管理アクセスや読み取り専用アクセスなど一般的なユースケースに用いることができます。

STEP2. 強いパスワードポリシーを設定する

強力なパスワードポリシーの必要性は明らかですが、推測やクラッキングからパスワードを守ることは非常に重要です。パスワードが顧客システムのセキュリティ確保に果たす役割は、しばしば過小評価されて見過ごされています。パスワードは、不正なシステムアクセスに対する最初の防衛線を提供します。Amazonは、パスワードの最小長やアルファベット以外の文字列を用いるなどパスワードポリシーを定義をして施行することができます。例えば90日間を証明書の更新に必要な一定間隔として、強力なパスワードポリシーを定義して実施することを推奨しています。

STEP3. 特権ユーザーには二要素認証を用いる

認証のために強力なパスワードポリシーを強制し、認証レベルを定義するときは、特権/管理ユーザのために二要素認証(MFA)を有効にすることを検討してください。AWS MFAは、AWSアカウント設定を強化し、AWSのサービスとリソースの管理を提供する追加のセキュリティレイヤーです。

今日、多くの組織では、管理ユーザーがシステムに対して大きなアクセス権限を持っているときは、追加のセキュリティによって制御する必要があります。全ての特権ユーザー用にAWS MFAを設定することで、AWSリソースを保護することを推奨します。特権ユーザーは、ビジネスオペレーションを妨害することができる権限を持ってインスタンスにアクセスするユーザーである可能性があります。例えば、特権ユーザーは、AWSリソースにアクセスできて、本番インスタンスを終了させることができるユーザーです。

MFAを有効にすることによって、追加のセキュリティとして、AWSのウェブサイトやサービスにアクセスするときに、認証デバイスから固有の認証コードを入力するように言われます。これにより、不正に入手したEメールアドレスやパスワードを使った、偽装のシステムコントロールから防ぐことができます。

Amazonは、MFAを有効にする際に、2つの選択肢を提供しています。サードパーティによるハードウェアベース、または、AWS MFA対応の仮想トークンサービスによるソフトウェアベースのトークンです。

STEP4. ベースとなるセキュアなAMIを作成する

Amazon EC2内に仮想マシンを作成する際に、事前に設定されたOSテンプレートイメージ（AMI）または、カスタマイズされた構成のAMIを使用する場合、ホストされたアプリケーションを使用する前に、顧客自ら使用する前に適切な調査を実施する責任があります。顧客は完全なルートアクセスか仮想システムに対する管理コントロール権限を持っています。

AWSは、顧客のインスタンスへのアクセス権を持ってなく、ゲストOSにログインすることができないため、インスタンスの整合性やセキュリティを保証することはできません。顧客自ら、OS上で必要なアプリケーションやサービスのみが有効になっているか確認することを推奨します。これは、実行中のソフトウェアサービスが合理化されていれば、攻撃の危険性を減らすのに役に立ち、パスワードのみによるホストへのアクセスを無効にするようにインスタンスの設定を最小にし、重要なインスタンスへのアクセスを二要素認証にし、リモートからのルートログインを無効にします。

STEP5. ゲストOSを守る

Amazonは、仮想化やハイパーバイザー（ホストOS）のような管理/物理コントロールを実装および管理するために、とても堅牢なプロセスを持っていますが、防御的なセキュリティコントロールについて定期的に有効性を評価し、AWSインスタンスを継続的に維持することは、顧客の責任となっています。Amazon EC2は、クラウドベースのサーバーを保護するためのAWSセキュリティグループなどのツールが用意されています。

顧客が基本的なセキュリティを実装するために、アンチウィルス、ホストベースのファイアウォール、ホストベースの侵入防止、ファイル整合性監視、ログ監視、暗号化と鍵管理ソリューションなどの技術ソリューションを活用することで、追加のセキュリティを実装することを推奨しています。

ゲストOSを保護することは、体的なセキュリティアップデートとOSパッチの適応を意味します。例えば、インスタンスがホストしている"常に最新"のWebアプリケーションのための更新セキュリティパッチは、非常に困難でコストが掛かるかもしれません。パッチ管理の難しさを緩和するために、脆弱性の遮断のための"仮想パッチ"ソリューションを用いることを推奨しています。これは、セキュリティを損なうことなく、アプリケーションの可用性を確保します。

STEP6. 制限の厳しいファイアウォールを作成してホストベースで使う

Amazonは、クラウドベースのサーバーを保護するためにAWSファイアウォールなどのツールが用意されています。全てのAmazon EC2インスタンスは、特定のインスタンスに対してどのネットワークトラフィックタイプを通すか指定された、ファイアウォールのルールセットを含む1つ以上のセキュリティグループによって保護されています。デフォルトでは、ファイアウォールは全て拒否するモードで動作し、明示的にインバウンドトラフィックを許可するために必要なポートを開く必要があります。しばしば、十分なファイアウォールポリシーは、過度な許容によってセキュリティホールになってしまうことがあります。ファイアウォールを閉じた上で、絶対に必要な通信のみを許可することを推奨します。インスタンス毎に制限されたトラフィックの管理とセキュリティ設定は、基本的に顧客の仕事です。

例えば、リモートアクセス用のポート（RDPやSSH）をオープンするべきではなく、代りに本番インスタンスへのアクセスは"踏み台ホスト"を用いるべきです。そして、本番インスタンスへの管理アクセスは、公開されたネットワークから"踏み台ホスト”を経由するようにします。AWS EC2セキュリティグループは、インバウンド通信のみ（VPCはアウトバウンド通信も）をセミステートフルで制御する保護機能を備えた、基本的なファイアウォールです。

これは、アウトバウンド通信を防ぐことはできず、トラブルシューティングやモニタリングなどのいくつかのケースにおいて重要になる可能性がある場合に、任意のログオプションを持っていません。入力（受信）の通信を制御するためにセキュリティグループを活用し、ネットワークベースのセキュリティを強化するために、ホストベースのファイアウォール技術を活用することで、追加のセキュリティを実装することを推奨します。顧客は、ロギング機能とアラート機能を用いて、ホストベースで双方向なステートフルのファイアウォールを選択する必要があります。これは、"多層防御"のセキュリティ体制を作成するのに役に立ちます。

sec-012

STEP7. アプリケーションを保護してホストベースのIPSを使う

限定的なファイアウォールポリシーを作成し、ホストベースのファイアウォールと共にAWS EC2ファイアウォールを増強することは十分ではありません。従来のファイアウォールは、攻撃面を減らすように設計されていますが、まだ開いているポートへのトラフィックを許可するようになってしまっています。例えば、もし顧客がWebベースのアプリケーションを実行しており、それらのファイアウォールが80/443ポートのトラフィックを許可していた場合、ファイアウォールは全てのトラフィックを許可します。これは、許可されたトラフィックが正規のトラフィックであるかどうかのインテリジェントな判断を欠いています。アプリケーションのセキュリティ保護は、安全なコーディング習慣から侵入テストに至るまで、多くの重要な要素が含まれ、それは単に暗号化された機密性の高い情報のみを許可する"オンデマンド"かつメモリ上でキャッシュしないアクセスを可能にするプラクティスを意味するかもしれません。

今日では、顧客の需要として、増加した機能性と豊富な機能セットを短い開発サイクルで企業が実行する必要があります。これは潜在的に、顧客ビジネスの信用を害する可能性のある、正しくセキュリティで保護されていないアプリケーションのリリースになる可能性があります。組織がインターネットを介して外部からアクセス可能なウェブアプリケーションを開発した場合、インハウスまたはサードパーティの技術を使うということは、必然的にそれがセキュリティホールの影響を受けやすくなります。

アプリケーションが潜在的に直面する、最も一般的なWebアプリケーションの脆弱性は、SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃です。これらの攻撃から顧客のアプリケーションを保護するために、ホストベースの侵入予防策システム（HIPS：host base intrusion preventions system）などのWebアプリケーション保護技術の使用を検討してください。良いHIPSソリューションは、バーチャルパッチ機能を提供することで、パッチ管理の課題を助けることができます。これは、既知のゼロデイ攻撃に対しての防御を提供し、様々な脆弱性からアプリケーションやシステムを守ります。HiPSソリューションを選ぶ際、適切な保護を確保するために、ベンダーのルールセットの適応範囲がコンピューティング環境に合っているか対応付けすることを推奨します。例えば、コンピューティング環境がLinux OSに基づいていて、ベンダーがLinuxベースOSの小さなルールセットしか持っていない場合、最良の選択ではありません。

STEP8. ファイルの整合性についてモニタリングとロギングをする

次のステップは、重要なシステムファイル、アプリケーション構成ファイル、およびアプリケーションログの継続的整合性を確保することです。ファイル整合性監視は、情報セキュリティの重要な側面として浮上しています。これは、侵入されたシステムの兆候を早期に把握することができ、PCIなどのさまざまなコンプライアンス基準で要求されています。ファイル、レジストリ、サービス、プロセス、重要なシステムファイルなど、ファイルの整合性の監視し、システムコンポーネントへの不正な変更を検出するためのログ解析ソリューションの実装を推奨します。ログは、情報セキュリティのもう一つの重要なコンポーネントです。ログがとられていない場合は、セキュリティインシデントを捕捉できず、ログおよびセキュリティイベントが監視されていない場合は、インシデントを検出することができません。オペレーティングシステム、ファイアウォール、アンチウイルスソフトウェア、侵入防御、およびアプリケーションログを含むコンピューティング環境への可視性を提供し、すべてのコンポーネントのログを有効にすることが重要です。

ホストベースのソリューションから、MSSP（managed security service provider）まで、顧客向けの多くのソリューションがあります。既に顧客にて監視ソリューションが確立されていて、中央サーバーでログの収集がされている場合、クラウド内で実行されているインスタンスは、ただ単に監視しなければならないリースのひとつに過ぎません。ファイアウォールの構成変更としては、クラウド環境からセキュアな伝送経路を確保するだけでなく、社内でログ収集する中央サーバーに到達できるようにする必要があります。

STEP9. 機密データを暗号化する

顧客自身が、保護の必要度と移動するデータの分類し、パブリッククラウド上の機密データの潜在的な影響について、デューデリジェンスを行い性質を評価することが重要です。機密データは、ユーザーIDや証明書と同様に、社会保障番号などの個人を特定できる情報（PII : personally identifiable information）である可能性があります。もし、Webサーバーとデータベースのように、サーバー間の通信を保護したいのであれば、IPSecやSSL通信を推奨します。暗号化ソリューションを使って「保存中」の機密データを保護するのであれば、オープンソースのソリューションやOSビルトインソリューション（Microsoft Encrypting File System (EFS)、eCryptfs、その他商用ソリューション）があり、顧客はそれぞれのソリューションを評価し、どれがセキュリティ規定に最良に適合するか確かめてください。

sec-013

データがパブリッククラウドに移動されると、未知の管轄権の規制の対象になることがあるため、顧客自身が特定の地域でデータが格納されるようにクラウドプロバイダーに指示することが重要です。例えば、ヨーロッパの会社が米国の領域にデータを格納している場合、それは、米国政府が米国内に格納されたデータへのアクセスを可能にする米国愛国者法の対象になります。Amazonは、AWSのサービスを利用する際に、地理的なリージョン設定を指定することができます。顧客は、自らのビジネスのために適切なデータ保存の地域をAmazonへ指定する必要があります。

一旦パブリッククラウドまたはVPC環境の中にデータがあるのであれば、顧客は「通信中」と「保存中」の状態両方のために、データを暗号化することを考慮するべきです。例えば、Webアプリケーションとユーザーのブラウザー間で機密データを送信するのであれば、常にSSLを使った通信の暗号化をするべきです。セキュリティ要件を満たすのに、十分な個々のファイルを暗号化するか、必要とされているボリューム全体を暗号化するか？ソリューションを選択するもうひとつ重要な要素は、鍵管理と鍵管理権です。セキュリティ規定は、暗号化キーを施設に残さないことを要求していますか？もし、答えがYesなら、システム上に暗号化キーが格納されている必要があるため、OS内蔵のソリューションは使えません。

この時点までで、データ、アプリケーション、ホストとネットワーク周りについて、"多層防御"モデルの作成について議論がされてきました。これらのセキュリティ原則を適応することにより、それぞれの層におけるセキュリティコントロールが実装されます。もし、ある防御が失敗した場合でも、データの保護は保証されます。例えば、侵入者がファイアウォールを通過する場合、ホストベースの侵入検知システム(IPS)によって保護することができます。

STEP10. 脆弱性診断を実施する

脆弱性診断（VA）の主な目的は、攻撃者が組織に損傷を与えうる、できるだけ多くの脆弱性を発見することです。脆弱性診断は、顧客のネットワークやシステム、Webアプリケーションに対して実施することができます。多くのツールやサービスがあり、それらの組み合わせて使うことができます。それは、顧客がこの診断を実行するためにツールを使用している場合であっても、よく訓練された内部/外部のセキュリティ評価機関が実施することを推奨します。よく訓練されたセキュリティ評価機関は、より多くのセキュリティ上の欠陥を見付け、既存/追加のセキュリティコントロールについて微調整の助けになるかもしれません。

STEP11. 侵入テストを実行する

実行中のインスタンス周辺において、セキュリティポスチャー（技術的および非技術的要素（ポリシー、手順、およびコントロールなど）へのアプローチ）を作成するのであれば、OSのサービスやアプリケーションの脆弱性を含む、システムの脆弱性を悪用するための侵入テストを実施し、システムの安全性を評価することを推奨しています。

脆弱性診断を行うことで、脆弱性を攻撃されたときに、潜在的な影響が無いか特定します。例えば、脆弱性スキャンは、SQLインジェクションを示すことがありますが、侵入テストでそれを悪用しようとするとき、組織のリスク許容度である、個人を特定できる情報（PII : personally identifiable information）やデータを明らかにするでしょう。

侵入テストは、防御のメカニズムの有効性を検証することについて、非常に有用なアプローチです。この演習は、セキュリティコントロールの実装が、実際の攻撃に耐えることができたのか判断する上で役に立ちます。Amazonは、セキュアなアプリケーションの配備において、侵入テストの重要性を理解しており、ゆえに、侵入テストを実施する許可を要求するためのポリシーを確立しています。PCI DSS、FISMA、NIST、その他、立法や業界の規制においては、侵入テストを義務づけています。

STEP12. 関与し続けてセキュリティを維持する

従来のITコンピューティングモデルでは、セキュリティは1回の演習ではありません。クラウドコンピューティングモデルでも同じです。顧客は、継続的に関与し、セキュリティ規定について維持する必要があります。顧客の責任は、セキュリティフレームワークを選択し、クラウドにワークロードを移動し、ベンダーとしてAWSを選択するだけでは終わりません。ほとんどの場合、顧客は、クラウドに新しいワークロードを移行するか、ビジネスニーズを満たすために、新しいサービスを獲得していきます。顧客の要求の変化に応じて、セキュリティの観点から変更を評価し、保護を提供するために更新または新しいコントロールを展開する必要があります。顧客は、セキュリティ維持の面で、実装のコントロールとモニタリングの変更を文書化することを含む、継続的に管理を確認する必要があります。

まとめ

クラウドは、ビジネスの俊敏性と柔軟性を向上させるために、多くの魅力的なオプションを提供します。しかし、これらの利点を得るには、数々のセキュリティ面について責任を持ち続ける必要があることを意味しています。これらの懸念により、クラウドの採用を妨げるべきではありません。セキュリティ共有責任モデルを理解し、セキュリィ規定について、新しい環境に適応することが必要なのです。