【AWS Well Architectedフレームワーク】セキュリティの柱の概要

クラウドサービスを利用するにあたり、公開された環境であるためセキュリティは強く意識して取り組む必要があります。

このセキュリティを取り組むにあたり、AWSには、ベストプラクティス（Well Architected フレームワークのセキュリティの柱）があります。

ただし、このベストプラクティスはボリュームも多く、初見には読み解くには厳しいものがあります。そのため、本記事では、ドキュメントを再整理し、少しでも分りやすく伝えることを狙いとしています。

セキュリティを設定するにあたり、参考にするドキュメント（AWS Well-Architected フレームワーク| AWS セキュリティの柱）

AWSには、Well-Architectedフレームワークという考え方があります。

AWS Well-Architected は、クラウドアーキテクトがさまざまなアプリケーションやワークロード向けに高い安全性、性能、障害耐性、効率性を備えたインフラストラクチャを構築する際に役立ちます。AWS Well-Architected では、6 つの柱 (優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性) に基づいて、お客様とパートナーがアーキテクチャを評価し、スケーラブルな設計を実装するための一貫したアプローチを提供しています。

AWS Well-Architected

簡単に書くと、設計や運用のためのベストプラクティスをまとめたものです。AWS Well-Architectedフレームワークには、下記の6つの柱があります。

本ブログでは、Security（セキュリティの柱）について解説します。

セキュリティ基盤 | Security foundations

セキュリティの柱では、クラウドテクノロジーを活用して、セキュリティ体制を改善できる方法でデータ、システム、資産を保護する方法について説明し、AWSで安全なワークロードを設計するための詳細なベストプラクティスガイダンスを提供します。

セキュリティの設計原則 | Design principles

クラウドには、ワークロードのセキュリティを強化するのに役立つ原則が多数あります。これらの原則を踏まえて、設計することが重要です。

設計原則 ( Design principles )	解説
強力な ID 基盤の実装 (Implement a strong identity foundation)	最小特権の原則を実装し、AWS リソースとのやり取りごとに適切な承認による職務の分離を強制します。 ID 管理を一元化し、長期にわたる静的な認証情報への依存を排除することを目指します。
トレーサビリティの維持 (Maintain traceability)	環境に対するアクションや変更をリアルタイムで監視、警告、監査します。 ログとメトリックの収集をシステムと統合して、自動的に調査してアクションを実行します。
すべての層にセキュリティを適用する (Apply security at all layers)	複数のセキュリティ制御による多層防御アプローチを適用します。 すべてのレイヤー (ネットワークのエッジ、VPC、負荷分散、すべてのインスタンスとコンピューティング サービス、オペレーティング システム、アプリケーション、コードなど) に適用します。
セキュリティのベスト プラクティスを自動化する (Automate security best practices)	自動化されたソフトウェア ベースのセキュリティ メカニズムにより、より迅速かつコスト効率よく安全に拡張する能力が向上します。 バージョン管理されたテンプレートのコードとして定義および管理されるコントロールの実装を含む、安全なアーキテクチャを作成します。
転送中および保存中のデータを保護する (Protect data in transit and at rest)	データを機密レベルに分類し、必要に応じて暗号化、トークン化、アクセス制御などのメカニズムを使用します。
人々をデータから遠ざける (Keep people away from data)	メカニズムとツールを使用して、データへの直接アクセスや手動処理の必要性を減らすか排除します。 これにより、機密データを扱う際の誤操作や変更、人的エラーのリスクが軽減されます。
セキュリティ イベントに備える (Prepare for security events)	組織の要件に合わせたインシデント管理と調査のポリシーとプロセスを用意して、インシデントに備えます。 インシデント対応シミュレーションを実行し、自動化されたツールを使用して、検出、調査、回復の速度を向上させます。

責任の共有

AWSのセキュリティでよく聞くキーワードとして、「責任共有モデル」があります。

責任共有モデルは、AWSと利用者の間で共有される責任を指します。下記に責任共有モデル のイメージとAWSと利用者の責任を記載します。

悪用と侵害に対する AWS の対応

AWSは、不正行為に対して、AWS利用者と協力してAWSリソースから疑わしい悪意のあるアクティビティを検出して対処します。その際に、AWSから利用者のAWSアカウントの連絡先に対して連絡する場合があります。

連絡先の登録が1つだけだと、それがSPOFになってしまうので複数登録しましょう。

AWSでは、下記のメカニズムによりリソース内の不正行為を検出しています。

AWS アカウントの管理と分離

機能や、コンプライアンス要件、共通の制御セットに基づいて、ワークロードを個別のアカウントおよびグループアカウントに整理することを推奨しています。

AWSには、AWS Organizationというサービスがあり、このサービスを利用することで下記のような制御が可能になるため、アカウントを分類する際の助けになります。

制御	解説
アカウント一元管理	AWSアカウントの作成と管理、作成後のアカウントの制御を自動化する。 アカウントを組織単位（Organization Unit | OU）二グループ化も出来るため、ワークロードの要件と目的に基づき様々な環境を表すことが出来る。
制御を一元的に設定	サービスコントロールポリシー（SCP）を使用して、Organization、OU、アカウント単位でアクセス許可のガードレールを適用できる。 この設定は、全てのIAMに適用される。
サービスとリソースを一元的に構成	AWSサービスの構成を支援している。例えば下記のようなことが可能になる。 ・AWS CloudTrailを使用して、組織全体で実行されるアクションの集中ログを設定できる。 ・AWS Configを使用して定義したルールのデータを一元的に集約できる。

ワークロードを安全に運用する

ワークロードを安全に運用するには、セキュリティのあらゆる領域に包括的なベスト プラクティスを適用する必要があります。

そのため、自動化により、プロセスの一貫性と再現性を高めます。また、個々のワークロードではなく共通の機能と共有コンポーネントを使用して時間を節約します。

ID とアクセスの管理

AWS のサービスを使用するには、ユーザーとアプリケーションに AWS アカウント内のリソースへのアクセスを許可する必要があります。

適切なユーザーが適切な条件下で適切なリソースにアクセスできるようにするため、堅牢なID管理と権限を導入する必要があります。

アイデンティティ管理

安全なAWSワークロードを運用する場合に、管理対象は下記の2つのIDがあります。

アイデンティティ	解説
人間	対象の例 ・アプリケーションの管理者 ・開発者 ・オペレーター ・および消費者 目的 ・AWS 環境およびアプリケーションにアクセスする
マシン	対象の例 ・ワークロード アプリケーション ・運用ツール ・コンポーネント 目的 ・AWS サービスにリクエストを行う

権限管理

権限を管理して、AWS およびワークロードへのアクセスを必要とする人間およびマシンの ID へのアクセスを制御します。

さまざまな種類のリソースへのアクセスを許可するには、さまざまな方法がありますが、その1 つの方法は、さまざまなポリシー タイプを使用することです。

• IAMポリシー
  • ユーザ、グループ、ロール等のIAM IDにアタッチして利用します。そのIDが実行d家いることを指定できる。
  • IAMポリシーは、下記に分類できる。
    • AWS管理ポリシー
      • AWSによって作成されたポリシー
    • 顧客管理ポリシー
      • AWSアカウントで作成、管理するポリシー。AWS管理ポリシーよりも詳細に制御可能
• リソースベースのポリシー
  • リソースにアタッチが出来る。
  • リソースと同じアカウントまたは別のアカウントに存在するプリンシパルにアクセス許可を付与します。
• SCP（組織のサービス制御ポリシー）
  • Organizationや、OUのアカウントメンバーに対する最大アクセス許可を定義します。
  • SCPはIAMベースのポリシー、リソースベースのポリシーがアカウント内のエンティティに付与するアクセス許可を制御する。
  • アクセス許可は付与しない。
• セッションポリシー
  • ロールまたは、フェデレーションユーザを想定している。
  • セションポリシーを使用する場合は、セッションポリシーを渡して、ロールまたはユーザのIDベースのポリシーがセッションに付与するアクセス許可を制限する。
  • 作成されたセッションのアクセス許可を制限するが、アクセス許可を付与するものではない。

検出

検出は下記の2つの部分で構成されます。検出により潜在的なセキュリティ構成ミス、脅威、または予期しない動作を特定可能です。

検出の種類	解説
予期しない、または不要な構成変更の検出	・アプリケーション配信ライフサイクルの複数の場所で発生する可能性がある。 デプロイ前に検出 ・IaC等を使用すると、CI/CDパイプラインまたはソース管理にチェックを実装することで、ワークロードがデプロイ前に不要な構成をチェックできる。 本番環境にデプロイ時 ・AWS、OSS、AWSパートなツール等使用して構成をチェックできる。 ・セキュリティ原則やベストプラクティスを満たしていない構成、テスト済みの構成と展開された構成の間に加えたれた変更に対して行う事が可能
予期しない動作の検出	・ツールを使用するか、特定の種類のAPI呼び出しの増加に応じてアラートを送信できる。 ・特定の種類のAPI呼び出しの増加に応じてアラートを送信できる。 ・ワークロードでの使用が予期されないAPI呼び出しの変化やセキュリティ体制を変更するAPI呼び出しを明示的に関する必要がある。

インフラ保護

ベスト プラクティスおよび組織または規制上の義務を満たすために必要な多層防御などの制御方法が含まれます。これらの方法論の使用は、クラウドでの継続的な運用を成功させるために不可欠です。

インフラストラクチャの保護は、情報セキュリティ プログラムの重要な部分です。これにより、ワークロード内のシステムとサービスが、意図しない不正なアクセスや潜在的な脆弱性から確実に保護されます。

AWSのリージョン、AZ、AWSローカルゾーン、AWS Outpostsについて下記に記載します。

各ロケーションおよびサービス	解説
リージョン	・データセンターをクラスター化する世界中の物理的な場所 ・論理データセンターの各グループをAZという。 ・各リージョンは、地理的エリア内に物理的に分散された複数のAZで構成される。 ・地域のコンプライアンスとデータ所在地の要件を満たすために役立つ（例えばデータをヨーロッパに置かないなど）
アベイラビリティーゾーン（AZ）	・独立した電源、冷却、および物理セキュリティがある。 ・AZ は他の AZ から物理的にかなりの距離 (数キロメートル) 離れているが、すべて相互に 100 km (60 マイル) 以内にある。 ・AWS リージョン内のすべての AZ は、完全冗長の専用メトロ ファイバーを使用して高帯域幅、低レイテンシーのネットワーキングで相互接続されており、AZ 間に高スループット、低レイテンシーのネットワーキングを提供している。 ・AZ 間のすべてのトラフィックは暗号化される。
AWSローカルゾーン	・コンピューティング、ストレージ、データベース、その他の厳選された AWS サービスをエンドユーザーの近くに配置する ・メディアおよびエンターテイメントコンテンツの作成、リアルタイムゲーム、シミュレーション、電子設計の自動化、機械学習など、エンドユーザーにとって 1 桁ミリ秒のレイテンシーを必要とする要求の高いアプリケーションを簡単に実行する。 ・AWS Local Zone の各ロケーションは AWS リージョンの拡張 ・エンドユーザーに地理的に近い場所で Amazon EC2、Amazon VPC、Amazon EBS、Amazon File Storage、Elastic Load Balancing などの AWS のサービスを使用して、レイテンシの影響を受けやすいアプリケーションを実行できる ・ローカル ワークロードと AWS リージョンで実行されているワークロードとの間に高帯域幅の安全な接続を提供する
AWS Outposts	・ネイティブの AWS サービス、インフラストラクチャ、および運用モデルを、データセンター、コロケーション スペース、またはオンプレミス施設に配置する。

ネットワークの保護

ワークロード内の多くのリソースは VPC 内で動作し、セキュリティ プロパティを継承するため、自動化に裏付けられた検査および保護メカニズムで設計がサポートされることが重要です。同様に、純粋にエッジ サービスやサーバーレスを使用して VPC の外部で動作するワークロードの場合、より簡素化されたアプローチでベスト プラクティスが適用されます。

コンピューティングの保護

多層防御、脆弱性管理、攻撃対象領域の縮小、構成と運用の自動化、遠隔地でのアクションの実行など、考慮する必要がある共通の戦略を共有しています。

データ保護

データ分類は機密レベルに基づいてデータを分類する方法を提供し、暗号化は不正なアクセスに対して理解できないようにすることでデータを保護します。

AWS では、データ保護に取り組む際に使用できるさまざまなアプローチが多数あります。

データの分類

適切な保護と保持の制御を決定するのに役立つように、重要度と機密性に基づいて組織データを分類する方法を提供します。

保管中のデータの保護

暗号化と適切なアクセス制御が実装されている場合、保存データを保護すると、不正アクセスのリスクが軽減されます。

保護スキームには、暗号化とトークン化があります。

転送中のデータの保護

転送中のデータとは、あるシステムから別のシステムに送信されるデータです。これには、ワークロード内のリソース間の通信だけでなく、他のサービスとエンド ユーザー間の通信も含まれます。転送中のデータに適切なレベルの保護を提供することで、ワークロードのデータの機密性と整合性を保護します。

インシデント対応

成熟した予防および検出制御を備えている場合でも、組織はセキュリティ インシデントの潜在的な影響に対応し、軽減するためのメカニズムを実装する必要があります。

クラウド対応の設計目標

クラウド環境のセキュリティインシデント対応に関連する、下記の設計目標を評価することを推奨しています。

設計目標	解説
対応目標を確立する	・ステークホルダー、弁護士、組織のリーダーと協力して、インシデントへの対応目標を決定します。 ・一般的な目標には、下記が含まれます。 　・問題の封じ込めと軽減 　・影響を受けたリソースの回復 　・フォレンジック用のデータの保存、および属性の特定
計画を文書化する	インシデントへの対応、発生中のコミュニケーション、およびインシデントからの回復に役立つ計画を作成します。
クラウドを使用して応答する	イベントとデータが発生する場所に応答パターンを実装します。
所有しているものと必要なものを把握する	・ログ、スナップショット、その他の証拠を一元化されたセキュリティ クラウド アカウントにコピーして保存します。 ・タグ、メタデータ、および保持ポリシーを強制するメカニズムを使用します。 例）調査目的でデータの完全なコピーを作成するには、Linux dd コマンドまたは Windows の同等のコマンドを使用することを選択できます。
再デプロイメント メカニズムを使用する	セキュリティ異常の原因が構成ミスである可能性がある場合、適切な構成でリソースを再デプロイすることで差異を除去するだけで修復が簡単になる場合があります。 可能であれば、応答メカニズムを複数回実行しても、未知の状態の環境でも安全に実行できるようにしてください。（冪等性の確保）
可能な場合は自動化する	問題やインシデントが繰り返される場合は、プログラムで優先順位を付けて一般的な状況に対応するメカニズムを構築します。（始めてで、機密性の高いインシデントは人間が行います。）
スケーラブルなソリューションを選択する	クラウド コンピューティングに対する組織のアプローチのスケーラビリティに合わせて、検出から対応までの時間を短縮するよう努めます。
プロセスを学び、改善する	プロセス、ツール、または人材のギャップを特定したら、それらを修正する計画を実行します

教育する

自動化することが前提になります。自動化することで、ワークロードのセキュリティを強化する時間を確保が出来ます。

セキュリティチームの教育には、下記の領域を組み込むことを推奨しています。

教育の領域	解説
開発スキル	プログラミングスキルを身につけることで、自動化の取り組みが加速化します。
AWSサービス	クラウドネイティブツールの使用方法を理解すると、対応時間が短縮される。 ツールも変化するので継続的に教育を行う。
アプリケーション	ワークロードと環境の詳細についてトレーニングする。 どのようなログが出力されるのか？ログにどのような情報が含まれるか？等理解することで優位になる。

セキュリティチームだけではなく、組織全体にも教育を施す必要がある。さらなる調査が必要な場合に、不審な動作をセキュリティチームに報告するように訓練されていることが必要です。

準備

インシデント発生中、インシデント対応チームは、インシデントに関係するさまざまなツールやワークロード リソースにアクセスできる必要があります。そのため、イベントが発生する前に適切なアクセス権を事前に提供されていることを確認する必要があります。

すべてのツール、アクセス、計画は文書化され、イベントが発生する前にテストし、迅速な対応が可能であることを確認する必要があります。

シミュレートする

シミュレーションにより、下記のサイクルを回します。

• インシデントからの回復
  • チームはベストプラクティスを実装することで、侵害を完全に除去することにフォーカスできます。
  • 下記のようなアクティビティを行います。
    • インシデント中に侵害されたファイルまたはデータをバックアップまたは以前のバージョンから復元する
    • 疑わしいアクティビティがすべて停止していることを確認し、安定した状態を確保するために監視を継続する
• インシデント後の報告会
  • このセッションにより、チームは学習内容を共有し、組織のインシデント対応計画の全体的な有効性を高めることができます。
  • 下記を行う必要があります。
    • インシデントの処理を詳細にレビューする。
    • 学んだ教訓を文書化する。
    • 学んだことに基づいてランブック（手順書）を更新する。
    • 新しいリスク評価が必要かどうかを判断する。

反復する

アプリケーションのセキュリティ

ソフトウェア開発ライフサイクル (SDLC) およびリリース後のプロセスの定期的な一部としてアプリケーション セキュリティ テストを採用すると、本番環境に侵入するアプリケーション セキュリティの問題を特定、修正し、防止するための構造化されたメカニズムを確保できます。

通常、SDLC の開始が早いほど、欠陥を解決するためのコストと複雑さは低くなります。

実装ガイドラインは、下記の領域に重点を置いています。

• 組織と文化
• パイプライン の セキュリティ
• 依存関係管理

よくある質問

AWS Well-Architected フレームワーク の 6つの柱とはなんですか？

本文にも記載いたしましたが、下記の6つが定義されています。

• Operational Excellence
• Security
• Reliability
• Performance Efficiency
• Cost Optimization
• Sustainability

AWS セキュリティのベストプラクティスを教えてください

ベストプラクティスというわけではありませんが、AWSが、公開している「今⽇からスタート︕AWS セキュリティ 初めの⼀歩」は参考になります。

また、このAWSが公開している記事を読み解いたものを下記にまとめていますので、よろしければご覧ください。

最後に

今回の記事では、「Well Architected フレームワークのセキュリティの柱」を解説しました。

セキュリティは、クラウドサービスを利用するにあたり最初に抑えておさえておこなければならない重要事項です。

最初からすべてを詳細に理解し実践することは、難しいですが継続的に学習することが重要と考えます。

少しでも、皆様のお役に立てれば幸いです。

今回も読んで頂きましてありがとうございました。

参考ドキュメント

• Amazon Web Services: Overview of Security Processes
• Security Pillar – AWS Well-Architected Framework
• NIST SP 800-61 コンピュータ セキュリティ インシデント処理ガイド