翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
セキュリティアーキテクチャの構築 — 段階的アプローチ
| 簡単なアンケートを実施して |
AWS SRA が推奨するマルチアカウントセキュリティアーキテクチャは、設計プロセスの早い段階でセキュリティを導入するのに役立つベースラインアーキテクチャです。クラウドへの取り組みは組織ごとに異なります。クラウドセキュリティアーキテクチャをうまく進化させるには、目標とする状態を思い描き、現在のクラウド対応状況を把握し、アジャイルアプローチを採用してギャップを埋める必要があります。AWS SRA は、セキュリティアーキテクチャのリファレンスターゲット状態を提供します。段階的に変革することで、広範囲にわたる予測を行う必要性を最小限に抑えながら、価値を迅速に実証できます。
AWS クラウド導入フレームワーク (AWS CAF) では、「構想」、「調整」、「立ち上げ」、「スケーリング」という 4 つの反復的かつ段階的なクラウド変革フェーズを推奨しています。ローンチフェーズに入り、本番環境でのパイロットイニシアチブの実施に重点を置く際には、最もビジネスクリティカルなワークロードを自信を持って移行して運用するための技術的能力を身に付けるために、スケーリングフェーズの基盤として強力なセキュリティアーキテクチャを構築することに注力する必要があります。この段階的アプローチは、新興企業、事業拡大を目指す中小企業、または新しい事業部門の買収や合併や買収を行う企業に適しています。AWS SRA は、セキュリティベースラインアーキテクチャを実現するのに役立ちます。これにより、拡大する AWS Organizations の組織全体にセキュリティコントロールを統一的に適用できるようになります。ベースラインアーキテクチャは、複数の AWS アカウントとサービスで構成されています。計画と実装は複数の段階に分けて行う必要があります。そうすれば、ベースラインのセキュリティアーキテクチャを設定するという大きな目標を達成するために、小さなマイルストーンを繰り返すことができます。このセクションでは、構造化されたアプローチに基づいて、クラウドへの移行の一般的なフェーズについて説明します。これらのフェーズは、AWS Well-Architected Framework のセキュリティ設計原則に沿ったものです。
フェーズ 1: OU とアカウント構造を構築する
強固なセキュリティ基盤の前提条件は、適切に設計された AWS の組織とアカウント構造です。このガイドの「SRA ビルディングブロック」セクションで説明したように、複数の AWS アカウントを持つことで、設計上、さまざまなビジネス機能やセキュリティ機能を分離できます。これは最初は不必要な作業のように思えるかもしれませんが、迅速かつ安全にスケーリングするための投資です。このセクションでは、AWS Organizations を使用して複数の AWS アカウントを管理する方法と、信頼できるアクセスと委任管理者機能を使用してこれらの複数のアカウントにわたる AWS サービスを一元管理する方法についても説明します。
このガイドの前半で説明したように、AWS Control Tower を使用してlanding zone を調整できます。現在 1 つの AWS アカウントを使用している場合は、「複数の AWS アカウントへの移行ガイド」を参照して、できるだけ早く複数のアカウントに移行してください。たとえば、スタートアップ企業が現在、単一の AWS アカウントで製品のアイデアとプロトタイプを作成している場合、製品を市場に投入する前に、マルチアカウント戦略の採用を検討する必要があります。同様に、小規模、中規模、大企業の組織は、最初の運用ワークロードを計画したらすぐに、マルチアカウント戦略の構築を開始する必要があります。基礎 OU と AWS アカウントから始めて、次にワークロード関連の OU とアカウントを追加します。
AWS SRA で提供されている内容以外の AWS アカウントと OU 構造の推奨事項については、中小企業向けマルチアカウント戦略のブログ投稿を参照してください
設計上の考慮事項
-
OU とアカウント構造を設計するときは、会社の報告構造を複製しないでください。OU は、ワークロード機能と、そのワークロードに適用される共通のセキュリティ制御に基づいて作成する必要があります。アカウント構造全体を最初から設計しようとしないでください。基本的な OU に注目し、必要に応じてワークロード OU を追加してください。設計の初期段階でアカウントを OU 間で移動して、別のアプローチを試してみることができます。ただし、OU とアカウントパスに基づく SCP と IAM の条件によっては、論理的な権限の管理に関してオーバーヘッドが発生する可能性があります。
実装例
AWS SRA コードライブラリには
フェーズ 2: 強固な ID 基盤を実装する
複数の AWS アカウントを作成したらすぐに、それらのアカウント内の AWS リソースへのアクセスをチームに許可する必要があります。ID 管理には、従業員の ID およびアクセス管理と顧客 ID およびアクセス管理
IAM ロールを使用して AWS リソースへのユーザーアクセスを提供する場合、このガイドの「セキュリティツールと組織管理」セクションで説明されているように、AWS IAM Access Analyzer と IAM アクセスアドバイザーを使用する必要があります。これらのサービスは、適切なセキュリティ体制を構築するのに役立つ重要な予防管理である最小権限を実現するのに役立ちます。
設計上の考慮事項
-
最小限の権限を実現するには、自分の ID とそれらが正しく機能するために必要な権限との関係を定期的に見直して理解するプロセスを設計してください。学習するにつれて、それらの権限を微調整し、可能な限り最小限の権限に徐々に絞り込んでください。スケーラビリティのためには、中央セキュリティチームとアプリケーションチームが責任を分担する必要があります。リソースベースのポリシー、権限境界
、属性ベースのアクセス制御、セッションポリシーなどの機能を使用すると、アプリケーション所有者がきめ細かなアクセス制御を定義しやすくなります 。
実装例
AWS SRA コードライブラリには
-
IAM パスワードポリシーは
、一般的なコンプライアンス基準に準拠するようにユーザーのアカウントパスワードポリシーを設定します。 -
Access Analyzer
は、委任された管理者アカウント内には組織レベルのアナライザーを設定し、各アカウントにはアカウントレベルのアナライザーを設定します。
フェーズ 3: トレーサビリティの維持
ユーザーが AWS にアクセスして構築を開始すると、誰が、いつ、どこから何をしているのかを知りたいと思うでしょう。また、潜在的なセキュリティ設定ミス、脅威、予期しない行動を可視化する必要もあります。セキュリティの脅威をよりよく理解することで、適切なセキュリティ制御に優先順位を付けることができます。AWS のアクティビティを監視するには、AWS SRA の推奨事項に従って組織証跡を設定し、ログAWS CloudTrail Log Archive アカウント内で一元管理してください。セキュリティイベントのモニタリングには、セキュリティツールのアカウントセクションで説明されているように GuardDuty、AWS Security Hub、Amazon、AWS Config、AWS Security Lake を使用してください。
設計上の考慮事項
-
新しい AWS サービスの使用を開始するときは、必ずサービスのサービス固有のログを有効にし、中央ログリポジトリの一部として保存してください。
実装例
AWS SRA コードライブラリには
-
CloudTrail組織は組織証跡を作成し
、デフォルトを設定してデータイベント (Amazon S3 や AWS Lambda など) を設定することで、AWS Control Tower CloudTrail で設定したデータイベントの重複を減らします。このソリューションには、管理イベントを設定するためのオプションが用意されています。 -
AWS Config Control Tower 管理アカウントにより
、管理アカウントの AWS Config がリソースのコンプライアンスを監視できるようになります。 -
コンフォーマンスパック組織ルールは
、コンフォーマンスパックを組織内のアカウントと指定されたリージョンにデプロイします。 -
AWS Config Aggregator
は、Audit アカウント以外のメンバーアカウントに管理を委任することでアグリゲーターをデプロイします。 -
Security Hub 組織は
、委任された管理者アカウント内で、組織内のアカウントと管理対象地域のSecurity Hub を設定します。 -
GuardDuty 組織は
、 GuardDuty 委任された管理者アカウント内で組織内のアカウントを設定します。
フェーズ 4: すべてのレイヤーにセキュリティを適用
この時点で、次のことが完了しているはずです。
-
AWS アカウントの適切なセキュリティ管理。
-
SCP と最小権限の IAM ロールとポリシーによって定義された予防統制を備えた、明確に定義されたアカウントと OU 構造。
-
AWS を使用して AWS アクティビティを記録したり、AWS CloudTrail Security Hub、Amazon、AWS Config を使用してセキュリティイベントを検出したり GuardDuty、Amazon Security Lake を使用してセキュリティ専用に構築されたデータレイクで高度な分析を実行したりできます。
このフェーズでは、「AWS 組織全体にセキュリティサービスを適用する」セクションで説明されているように、AWS 組織の他のレイヤーにもセキュリティを適用することを計画します。ネットワークアカウントのセクションで説明されているように、AWS WAF、AWS Shield、AWS Firewall Manager、AWS Network Firewall、AWS Certificate Manager (ACM)、Amazon、Amazon、Amazon Route 53 CloudFront、Amazon VPC などのサービスを使用して、ネットワークレイヤーのセキュリティコントロールを構築できます。テクノロジースタックを下に進むときは、ワークロードやアプリケーションスタックに固有のセキュリティコントロールを適用してください。アプリケーションアカウントセクションで説明されているように、VPC エンドポイント、Amazon Inspector、Amazon Systems Manager、AWS Secrets Manager、および Amazon Cognito を使用してください。
設計上の考慮事項
-
多層防御 (DiD) セキュリティコントロールを設計する際には、スケーリング要因を考慮してください。中央のセキュリティチームには、環境内の各アプリケーションの動作について十分な帯域幅がなく、完全に理解することもできません。アプリケーションチームに、アプリケーションに適したセキュリティコントロールを特定して設計する責任と責任を持たせましょう。中央セキュリティチームは、アプリケーションチームを支援するための適切なツールとコンサルティングを提供することに重点を置く必要があります。セキュリティに対してシフトレフト型のアプローチを採用するために AWS が使用しているスケーリングメカニズムを理解するには、ブログ投稿「セキュリティ所有権を分散するメカニズム、セキュリティガーディアンプログラム（AWS がセキュリティ保護者プログラムを構築した方法
）」を参照してください。
実装例
AWS SRA コードライブラリには
-
EC2 デフォルト EBS 暗号化は
、指定された AWS リージョン内のデフォルトの AWS KMS キーを使用するように Amazon EC2 のデフォルトの Amazon Elastic Block Store (Amazon EBS) 暗号化を設定します。 -
S3 アカウントパブリックアクセスブロックは
、組織内のアカウントの Amazon S3 のアカウントレベルのパブリックアクセスブロック (BPA) 設定を構成します。 -
Firewall Manager
は、組織内のアカウントのセキュリティグループポリシーとAWS WAFポリシーを設定する方法を示しています。 -
インスペクター組織は
、組織内のアカウントおよび管理対象リージョンの委任管理者アカウント内で Amazon Inspector を設定します。
フェーズ 5: 転送中および保存中のデータを保護します。
ビジネスデータや顧客データは、保護する必要のある貴重な資産です。AWS は、移動中および保存中のデータを保護するためのさまざまなセキュリティサービスと機能を提供しています。「ネットワークアカウント」セクションで説明されているように、AWS を AWS Certificate Manager CloudFront と組み合わせて使用することで、インターネット経由で収集される転送中のデータを保護できます。内部ネットワーク内で移動するデータには、「アプリケーションアカウント」セクションで説明されているように、AWS プライベート認証局を備えたApplication Load Balancer を使用してください。AWS KMS と AWS CloudHSM は、保存中のデータを保護するための暗号キー管理を提供するのに役立ちます。
フェーズ 6: セキュリティイベントに備える
IT 環境を運用していると、セキュリティイベントに遭遇します。セキュリティイベントとは、IT 環境の日常的な運用における変化で、セキュリティポリシー違反またはセキュリティ制御の失敗の可能性を示すものです。セキュリティイベントをできるだけ早く把握するには、適切なトレーサビリティが不可欠です。セキュリティイベントが拡大する前に適切な対策を講じることができるように、このようなセキュリティイベントを優先順位付けして対応する準備をしておくことも同様に重要です。準備しておくと、セキュリティイベントを迅速に優先順位付けし、その潜在的な影響を把握できます。
AWS SRA は、Security Tooling アカウントの設計と、すべての AWS アカウント内での共通のセキュリティサービスの展開を通じて、AWS 組織全体のセキュリティイベントを検出できるようにします。Security Tooling アカウント内の AWS Detective は、セキュリティイベントのトリアージと根本原因の特定に役立ちます。セキュリティ調査中は、関連するログを確認して、インシデントの全範囲とタイムラインを記録し、把握できなければなりません。また、対象となる特定のアクションが発生した場合にアラートを生成するためにもログが必要です。
AWS SRA では、すべてのセキュリティログと運用ログを不変に保存するために、中央の Log Archive アカウントを推奨しています。CloudWatch ロググループに保存されているデータについてはログインサイトを使用し、Amazon S3 に保存されているデータについては Amazon Athena
設計上の考慮事項
-
クラウドへの移行の最初から、セキュリティイベントの検出と対応の準備を開始する必要があります。限られたリソースをより有効に活用するには、データとビジネス上の重要度を AWS リソースに割り当てます。これにより、セキュリティイベントを検出したときに、関係するリソースの重要度に基づいて優先順位付けと対応に優先順位を付けることができます。
-
このセクションで説明するように、クラウドセキュリティアーキテクチャを構築する段階は基本的に連続しています。ただし、1 つのフェーズが完全に完了するのを待ってから、次のフェーズを開始する必要はありません。反復的なアプローチを採用することをお勧めします。つまり、複数のフェーズにparallel 取り組み、クラウドセキュリティ体制を進化させるにつれて各フェーズを進化させるというものです。さまざまな段階を経るにつれて、設計も進化していきます。次の図に示す推奨順序を特定のニーズに合わせて調整することを検討してください。
実装例
AWS SRA コードライブラリには
