トップレベルでは、クラウドインフラストラクチャのセキュリティの基本は、オンプレミスネットワークのそれと類似しています。例えばNISTサイバーセキュリティ フレームワークはクラウドにも利用され、保護対象の特定、資産の保護、悪質なアクティビティの検知、セキュリティイベントへの対応、事後の復旧を行う必要があります。しかし、クラウド環境が持つ特別な側面上、これらを達成する方法は従来とは大きく異なります。
おそらく最も明白でありながら誤解されている違いは、クラウド環境では、クラウドサービスプロバイダ（CSP）がクラウド環境の安全の一部に対して責任を負うという点です。CSPが実際に責任を担う範囲に対して誤解があります。AWSのようなCSPでは、責任分担を明確にするため責任共有モデルが形成されています。責任共有モデルでは、クラウドインフラストラクチャを保護する責任を負うのはAWSとされています。つまり、AWSがハードウェアの保守や更新だけでなく、これらのハードウェアに対する物理的なセキュリティにも責任を負います。AWSインフラストラクチャを使用するユーザーは、AWS上に配置するものすべてに対して保護する責任を負います。つまり、ユーザーが責任を負うのは、オペレーティングシステムの更新やパッチの適用、使用するAWSサービスの適切な設定、これらのサービスへのアクセスの管理などです。AWS環境の保護について詳しくご確認ください。
組織の誰かが、クラウドプロバイダが責任を持つセキュリティの側面について誤った想定をしている場合、クラウド上の資産が適切に保護されない可能性があります。だからこそ、クラウド環境を変更する能力を誰かに付与する前に、その人物が、共有責任モデルと組織が責任を負うセキュリティ面について十分に知識しておくことが大変重要です。
クラウド環境独自のもう1つの特徴が、新しい資産の作成とデプロイが容易な点です。オンプレミスネットワークの場合、新たに追加するインフラストラクチャはすべてIT部門とセキュリティ部門が管理します。クラウドネットワークでは、適切な認証情報を持つアカウントやシステムならすぐに新しいインフラストラクチャを追加できます。その結果、クラウドネットワークの変更がはるかに容易になる一方で、適切な安全規則と監視が設けられていなかった場合、新しいインフラストラクチャが安全に設定されず、脆弱になる恐れがあります。
一方で、クラウド環境は急速に変化します。自動スケーリングやサーバーレスコンピューティングでは、クラウドネットワーク上の資産は常に出現と消滅を繰り返します。脆弱性スキャンのような従来のセキュリティ対策ではもはや十分とは言えません。数分または数時間しか存在しない脆弱な資産もあり、毎日/毎週のスキャンでそのような資産を検出することは不可能です。逆にこれは、資産がリスクになるほど長い間ネットワーク上に存在しないことを意味すると思うかもしれませんが、Project Heisenbergのグローバル ハニーポットのネットワークデータによると、新しい資産は組み込まれてからわずか数時間で悪質な攻撃者にスキャンされることが分かっています。
クラウド環境はデプロイメントや容易で変化するペースも速いため、セキュリティチームがクラウド環境全体を把握することは非常に困難です。ハイブリッド環境（オンプレミス/クラウドネットワークの両方が含まれるIT環境）やマルチクラウド環境（複数のクラウドプロバイダからのクラウドネットワークが含まれるIT環境）ではさらに深刻です。様々なデータが様々なシステムに保存されており、しばしば異なるセキュリティツールで保護されているからです。このような状況の場合、セキュリティチームはセキュリティへの取り組みを管理するために様々なシステムを行き来する必要があります。データが統合されていないため、組織のセキュリティ姿勢の総合的な把握や、クラウドとオンプレミスネットワークを行き来する悪意ある攻撃者の追跡は、困難（あるいは不可能）です。
オンプレミスネットワークを同様に、AWSの安全性は自らの構築によって左右されます。ここまでは責任共有モデルと、基盤となるインフラストラクチャのセキュリティに対してAWSが負う責任について説明してきました。実際のところ、多くの企業がオンプレミスネットワークに費やすリソースよりも、AWSが責任共有モデルに費やすリソースの方が大きいのです。このような組織にとって、AWSへの移行はセキュリティ態勢の一部を強化することになります。
一方で、AWSやその他のパブリッククラウドプロバイダへの移行によって新たなリスクも発生します。前述の通り、クラウド環境には固有の問題があります。既存のセキュリティ戦略をそのままクラウドに適用することはできません。それでも、クラウドセキュリティに固有の側面について理解した上でベストプラクティスを適用すれば、AWSをオンプレミスと同じように（あるいはそれ以上に）保護することができます。
強固なAWSセキュリティが重要なのは、一般的なサイバーセキュリティが重要であるのと同じ理由からです。悪質な攻撃者から組織やユーザーを守らなければいけません。重要なワークロードと機密性の高いデータをクラウドに移行する企業は増えており、多くの組織で、強固なAWSセキュリティを確保する重要性が増しています。
強固なAWSセキュリティが重要となるもう1つの理由が、回避できないインシデントによって発生する組織の評判への損害です。ガートナーは、2020年末までに発生するクラウドセキュリティ障害のうち、95%がユーザーに起因するものになるであろうと予測しています。組織が回避できる簡単なミスで侵害されていることを知れば、顧客の組織に対する信頼が揺らぎ、他社へと変更してしまう可能性があります。
本題に入る前に。AWSでは、その名前が示す通り、頭字語が好んで使われています。これによって、多種多様なAWSサービスについて理解する際に混乱を招くことがあるかもしれません。ここで簡単に説明します。
その他のAWSサービスについては後ほど詳しく説明しますが、先に基本情報についてのみご紹介しておきます。続いてベストプラクティスについて説明します。
AWS環境の導入を始める前に、どうやってAWSを保護するかについても考慮しておくほうが良いでしょう。すでに導入を開始していても心配ありません。ベストプラクティスを実装する取り組みが少し多くなるだけです。
クラウド環境を初めて検討する際、開発者がインフラストラクチャを変更できないようにするなどして、クラウドを保護し慣れているオンプレミス環境を模倣したものにしようとする人がセキュリティチームから出てくるでしょう。ほとんどの場合、その結果、セキュリティチームはクラウドセキュリティの責任から解放されることになるか、エンジニアが制限を回避する何らかの方法を見出すことになります（これが良くない理由については、ベストプラクティスの9を参照してください）。
セキュリティチームは、クラウドの潜在的なリスク面である変化のスピードやデプロイメントの容易さは、逆に、クラウドインフラストラクチャを使用することで得られる最大の利点にもなることを認識する必要があります。クラウドの導入を成功させるには、周りからクラウドの実現者として見られるようにセキュリティチームが努力する必要があります。組織にとってクラウドがメリットとなるような側面を抑圧しすぎることなく、クラウドインフラストラクチャを安全に保つ方法を見つける必要があります。偏見を持たずに、クラウド環境のリスク管理を成功させるには、新しい戦略とプロセスが必要となることを認識することから始めましょう。
セキュリティチームとDevOpsチームが連携し、AWS環境をセキュリティ観点からどのように形成するのかについて定義します。セキュリティベースラインでは、資産の設定方法からインシデント対応計画にいたるまで、すべてを明示する必要があります。セキュリティチームは、「AWS Well-Architected Framework」や「CIS Benchmarks for AWS」といったリソースの利用の検討から始めることをお勧めします。また、AWS環境の構築を支援するAWSソリューションアーキテクトに技術支援を依頼することもできます。
ベースラインが本番環境だけでなく、テストや本番前の環境にも適用されていることを確認します。最低でも6カ月間に一回はベースラインを見直し、新たな脅威や環境の変化を反映します。
セキュリティチームとDevOpsチームがAWSセキュリティベースラインを定義したら、実際に適用します。すでに適切に設定済みにインフラストラクチャのテンプレートを提供して、開発者がベースラインに容易に順守できるようにします。これを行うには、AWS CloudFormationやTerraformのようなInfrastructure As Codeベンダーを利用します。
また、（誤設定が含まれるデプロイや、デプロイメント後の変更などによって）ベースラインに対してコンプライアンス違反しているものがないか検知する監視ソリューションも必要です。このためには、AWS Security Hubを使用することも可能ですが、いくつかのサードパーティーの脆弱性管理ソリューションにも、クラウドの誤設定を監視する機能が組み込まれているものがあります。誤設定検知機能が組み込まれたVMソリューションの利用には2つの利点があります。1つ目の利点は、2種類のリスク監視（資産の脆弱性とクラウドインフラストラクチャの設定ミス）を1つのツールに統合できる点です。2つ目の利点は、ほとんどの脆弱性管理ソリューションでは、誤設定ルール/検知はすべてベンダーが管理してくれますが、AWS Security Hubの場合、自分でルールを設定および管理する必要がある点です。脆弱性検査とクラウド設定を行うInsightVMの詳細をご確認ください。
セキュリティベースラインを適用するもう1つの方法に、Cloud Security Posture Management（CSPM）ソリューションがあります。高機能なCSPMであれば、複数のクラウドプロバイダのアカウントで設定ミスを監視することが可能です。これは非常に大きなメリットで、組織はすべてのクラウドプロバイダに対して1つのセキュリティベースラインを設定し、単一のツールを使って適用できるようになります。クラウドアカウントの設定ミスを監視することができたら、設定ミス検知後、設定ミスを直ちに自動修正できるCSPMを検討しましょう。CSPMによってセキュリティチームの負担は大幅に軽減され、亀裂からの漏れを確実に検知できます。
CSPMに求めるその他の機能として、デプロイされる前にInfrastructure As Codeの問題にフラグを立てる機能、IAMガバナンス（詳細は次のセクションを参照）、コンプライアンス監査があります。CSPMは高コストになりがちですが、複数のクラウドプロバイダを使用する企業や、1つのプロバイダに多数のアカウントを持つ企業にとっては、その複雑なアカウント管理を容易にする方法の1つとなります。
安全なAWS環境を構築する上で最も重要なのは、アクセス権限を必要なユーザーとシステムだけに限定することです。これは、AWS Identity Access Management (IAM)を使用して実施します。IAMは次のコンポーネントで構成されています。
IAMを構成するコンポーネントの基本について理解しました。次に、ベストプラクティスについて説明します。AWSにはぜひ目を通しておきたいIAMベストプラクティスのリストがあります。「CIS Benchmarks for AWS」にも同様の記載があります。このベストプラクティスはすべて重要ですが、簡潔に説明するため、ここでは最も重要な（そしてよく守られないことのある）ガイドラインをいくつかご紹介します。
多くの人がパッチの未適用から生じる脆弱性は、クラウド内であっても脅威であることを認識していません。EC2インスタンスで脆弱性を検知するには、AWS Inspectorやサードパーティーの脆弱性管理ソリューションが利用できます。脆弱性管理ソリューションを使用することで、作業の優先順位付け、レポート機能の改善、インフラストラクチャオーナーとの意思の疎通が促進され、リスク低減に向けた進捗を全員が監視できるようになります。加えて、ハイブリッド/マルチクラウド環境を扱うセキュリティチームは、多くの場合、すべての環境の脆弱性とリスクを一元管理できるサードパーティーのソリューションを好みます（詳細はベストプラクティスの9項を参照）。
脆弱性管理は多くのサイバーセキュリティ プロフェッショナルにとって馴染み深いものですが、AWSのようなクラウド環境のVMには注意すべき特徴がいくつかあります。上述の通りクラウド環境は急速に変化します。クラウド上の資産は分単位で出現し、消滅します。このようなダイナミックな環境において脅威とリスクエクスポージャーを正確に把握するには、毎日/毎週のスキャンでは不十分です。存在するEC2インスタンスを確実に把握し、その存続期間を通じて継続監視する方法を確立することが重要です。EC2インスタンスの全体像を確実に把握するには、新規インスタンスのデプロイを自動検知するダイナミック資産検知機能を備えた脆弱性管理ソリューションの導入を推奨します。CloudWatch Eventsを利用すればAWS Inspectorでも同様の機能を実現できますが、設定には若干の手間がかかります。
EC2インスタンスで脆弱性を検知した場合、いくつか対処方法があります。その方法の1つが、AWS Systems ManagerのPatch Managerを使用することです。この方法は、従来のオンプレミスネットワークで脆弱性を管理する方法とよく似ています。しかしながら、クラウド環境の多くは不変であることを前提に設計されています。言い換えれば、EC2インスタンスのような資産は、一度デプロイしたら変更すべきではないのです。変更が必要な場合は、既存の資産を終了し、変更内容を反映した新しい資産と置き換えます。
つまり、変更することができない環境では、パッチを適用するのではなく、パッチを含んだ新しいインスタンスをデプロイします。そのための1つの方法は、ベースとなるAMIを作成し、定期的に更新して、使用する任意のオペレーティングシステムの最新版を実行しておく方法があります。この方法なら、脆弱性が検知された場合に、対応パッチを組み込んだベースラインAMIを新たに作成できます。これにより、将来デプロイするEC2インスタンスから脆弱性は排除されますが、現在実行中のEC2インスタンスも再デプロイする必要があります。
もう1つの方法としては、ChefやPuppetなどのインフラストラクチャ自動化ツールを使用して、AMIの更新や再デプロイを行う方法があります。EC2インスタンスの維持にこれらのツールのいずれかを使用している場合は、この方法が便利です。
他のシステムと同様に、AWS環境におけるすべてのアクティビティはログに記録する必要があります。ログは、監視やコンプライアンスにとって重要なだけでなく、NISTサイバーセキュリティフレームワークに立ち返って見てみると、悪質なアクティビティ（特に最新のSIEMに侵入された場合）を検知する重要な一部であり、セキュリティイベントへの対応と、その復旧に重要な役割を果たします。
AWSでは、ほとんどのログはCloudTrailを使用して取得されます。このサービスは、AWS APIのアクティビティをAWSでManagement Eventsと呼ばれるイベントとして自動的に取得し、AWSアカウントに無料で保存します（ただしストレージ費用は有料）。CloudTrailは、AWSサービスへのログインおよび設定の変更などの重要なセキュリティ情報を含む、数万件ものイベントを取得します。また、CloudTrailで「証跡」を作成し（有料機能）、追加のアクティビティを取得したり、ログをS3に送信して長期保存やエクスポートすることも可能です。ここでは、CloudTrailをAWSアカウントに設定する際のベストプラクティスをいくつかご紹介します。
CloudTrailはほとんどのログを収集しますが、収集されないログの中にいくつか確実に取得しておくべきログがあります。VPCフローログは、仮想プライベートクラウド（VPC）内のネットワークインターフェースに出入りするIPトラフィックデータを表示します。これらのログは、VPC内のポートスキャン、ネットワークトラフィックの異常、既知の悪質なIPアドレスを特定するのに役立ちます。AWS Route 53をDNSとして使用しているなら、DNSクエリのログも取得する必要があります。これらのログを脅威インテリジェンスと照合し、既知の悪質な脅威や急速に広がっている脅威を特定できます。なお、DNSログを表示するには、AWS CloudWatchを使用する必要があります。
ここまでは、AWS環境のアクティビティをログで可視化する方法を学びました。続いて可視化した情報の活用方法を見ていきます。その方法の1つ（ほとんど手作業になります）に、AWS CloudWatchアラームの活用があります。このアプローチでは、不正なAPI呼び出しやVPCの変更などの疑わしいアクションに対してアラームを構築します。推奨されるアラームのリストは、「CIS Benchmarks for AWS」に含まれています。この方法の問題点は、各アラームを手動で設定し、維持する必要があることです。
また、AWS GuardDutyを使用する方法もあります。GuardDutyは、CloudTrail、VPCフローログ、DNSログを使用して、疑わしい行動を検知して警告します。GuardDutyが優れているのは、AWSが管理する検出リスト（潜在的なセキュリティ問題）と、機械学習で機能している点です。つまり、不審なアクティビティに関するアラートを受信するために、手動での設定やメンテナンスは必要ありません。しかし、不審なアクティビティを検知するのは、インシデント対応の初めの一歩に過ぎません。セキュリティチームは、関連するログやその他のデータを取得してインシデントの発生を確認し、最適な対応と復旧手順を決定しなければなりません。この情報を収集するにあたり複数のデータソースを検索しなければならない場合、調査の実施に必要となる時間がかなり長くなる可能性があります。この問題は、ハイブリッド/マルチクラウド環境ではさらに深刻になります。
すべての調査関連データを自動で一元管理できるのは、多くのセキュリティチームが最新のSIEMとインシデント検知ツールを選ぶ理由の1つに過ぎません。優れたSIEMソリューションにはCloudTrailが統合されており、オンプレミスネットワークや他のクラウドプロバイダーから（AzureやGoogle Cloud Platform（GCP）など）のログと併せて、AWSからのすべてのログを保存できます。すべてのデータを一元管理するこの機能は、環境を移動する悪意ある攻撃者の追跡に特に有効で、調査の高速化に役立ちます。
優れたSIEMは、セキュリティチームの攻撃を検知、確認および対応する能力を様々な機能で向上させます。例えば、最新のSIEMでは、複数の技術を用いて不審な行動を検知します。導入を検討すべきその他の機能として、カスタムアラート作成機能、ディセプションテクノロジー（アクセスがあるとアラートを発動するよう予め構築されたハニーポットやハニーユーザー機能）、ファイル整合性監視（FIM）などがあります。これらの機能はすべて、検知のための新たな層を追加してくれます。また、一元化したデータを使いやすくするカスタマイズ可能なダッシュボードや、調査タイムラインなどの可視化機能を提供するSIEMも検討したほうがよいでしょう。加えて、検討しているSIEMに自動化機能が組み込まれていることを確認してください。インシデント発生時の対応時間を大幅に短縮ことができます。最後に、セキュリティチームの多くは、AWSとサードパーティーツールの両方を活用してAWS環境を保護する方法を好みますが、その場合、GuardDuty統合機能を備えたSIEMを用意することが重要です。
よくある間違いの1つに、既存のITインフラストラクチャのセキュリティ対策とは別にAWSのセキュリティをサイロ化するアプローチがあります。これにより悪意ある攻撃者が悪用できるセキュリティホールが生まれることになります。例えば、組織のオンプレミスセキュリティとAWSセキュリティが、それぞれ別な潜在的脅威に対処するようにネットワークが設計されていることがあります。その結果生まれるギャップにより、両方のネットワークに脆弱性が生まれます。
単一のチームがすべてのITインフラストラクチャのセキュリティを担うことで、「他の」セキュリティチームが何をして、何をしていないかを推測する必要がなくなります。代わりに、組織のサイバーセキュリティ態勢のあらゆる側面に責任を担うことを自覚したチームが1つ存在することになります。セキュリティ対策を1つのチームに集約することは、インシデント発生時にも非常に重要です。チームはより多くのデータに短期間でアクセスすることができます。また、各チームメンバーの責任範囲を明確に保つことも容易になります。
セキュリティに対する責任を1つのチームに集約するだけでなく、すべてのセキュリティデータを1つのツールに集約することも重要です。大半の企業は、AWSのみを使用していません。少なくとも、オンプレミスネットワークと従業員の端末のセキュリティは保護する必要があります。また、複数のクラウドプロバイダを利用している企業も少なくありません。環境ごとに異なるセキュリティソリューションを使用すると、盲点が発生しやすくなります。さらに、セキュリティチームが使用するツールが増えると、組織のサイバーセキュリティの全体像を把握するために絶え間なくツール間を行き来して手動で情報を収集しなければならず、作業負荷が大きくなります。
AWS保護に関するベストプラクティスがこれだけ多くある以上、そのすべてを全員が記憶すべきだと言うのは合理的ではありません。仮に全員が記憶できたとしても間違いは起こります。AWS環境がセキュリティベースラインに従っているかを継続的に確認するためには、自動化が必要です。例えば、CloudFormationとLambdaを組み合わせて使用したり、Terraformのようなツールや高度なCSPMを使用したりして、新しいAWSインフラストラクチャのデプロイメントを自動化し、それらが設立したベースラインに準拠しているか確認することができます。また、これらのツールを使用して、コンプライアンスに違反するインフラストラクチャに自動でフラグを立てたり、停止させたりすることができます。
自動化を採用することのもう1つの利点は、セキュリティチームのリソース確保にあります。セキュリティプロフェッショナル家の不足は慢性化しており、チームには過度の負担がかかっています。クラウドへの移行が進むにつれて、保護が必要なインフラ環境は飛躍的に増大し、この問題は悪化の一途をたどっています。状況の改善を図るために、セキュリティ オーケストレーションと自動化によるレスポンス（SOAR）ツールの導入を検討しましょう。SOARは、オンプレミスとクラウドサービス間のデータの受け渡しを容易にし、ITインフラストラクチャ全体に対する組織の意思統一を促進します。また、SOARは、オンボーディングやオフボーディングのような繁雑な作業や、初期のインシデント調査でのデータ集計などの手間のかかる作業を軽減します。SOARを使用すれば、セキュリティチームの負担は軽減し、作業効率が改善します。その結果、インシデント調査にかかる時間が短縮し、チームは重要な作業に集中する時間を確保できます。