SRA AWS の値

お客様は、 AWS セキュリティサービスを包括的にデプロイ、設定、運用する方法の詳細と推奨パターンを求めています。サービスのデプロイと管理を行うアカウントとセキュリティ目標 すべてまたはほとんどのサービスが動作するセキュリティアカウントが 1 つありますか? 場所 (組織単位または AWS アカウント) の選択は、セキュリティ目標にどのように役立ちますか? 顧客が注意すべきトレードオフ (設計上の考慮事項) はどれですか?

お客様は、多くの AWS セキュリティサービスを論理的に整理するためのさまざまな視点に関心を持っています。これらの代替視点は、各サービス (アイデンティティサービスやログ記録サービスなど) の主な機能を超えて、お客様がセキュリティアーキテクチャを計画、設計、実装するのに役立ちます。このドキュメントで後述する例では、 AWS 環境の推奨構造に沿った保護レイヤーに基づいてサービスをグループ化します。

お客様は、セキュリティサービスを最も効果的な方法で統合するためのガイダンスと例を求めています。例えば、自動監査およびモニタリングパイプラインの手間をかけるために、他の サービスとどのように連携し、接続 AWS Config するのが最適ですか? お客様は、各 AWS セキュリティサービスが他のセキュリティサービスにどのように依存またはサポートしているかについてのガイダンスを求めています。

独自のセキュリティアーキテクチャのターゲット状態を定義します。

最初のアカウントセットのセットアップ AWS クラウド 、または確立された AWS 環境の強化を計画している場合でも、SRA AWS はセキュリティアーキテクチャの構築を開始する場所です。アカウント構造とセキュリティサービスの包括的な基盤から始め、特定のテクノロジースタック、スキル、セキュリティ目標、コンプライアンス要件に基づいて調整します。より多くのワークロードを構築して起動することがわかっている場合は、カスタマイズされたバージョンの SRA AWS を取得し、組織のセキュリティリファレンスアーキテクチャの基礎として使用できます。 AWS SRA で説明されているターゲット状態を達成する方法については、「セキュリティアーキテクチャの構築 – 段階的アプローチ」を参照してください。 

すでに実装している設計と機能を確認 (および修正) します。

セキュリティ設計と実装が既にある場合は、SRA AWS と必要なものを比較するために少し時間をかける価値があります。 AWS SRA は包括的に設計されており、独自のセキュリティを確認するための診断ベースラインを提供します。セキュリティ設計が SRA AWS と一致する場合、 を使用する際にベストプラクティスに従っていることをより確信できます AWS のサービス。セキュリティ設計が AWS SRA のガイダンスと異なる、または一致しない場合でも、これは必ずしも何か間違ったことをしている兆候ではありません。代わりに、この観察結果により、決定プロセスを確認する機会が得られます。 AWS SRA のベストプラクティスから逸脱する正当なビジネスおよびテクノロジー上の理由があります。おそらく、特定のコンプライアンス、規制、または組織のセキュリティ要件には、特定のサービス設定が必要です。または、 を使用する代わりに AWS のサービス、 または構築して管理する AWS Partner Network カスタムアプリケーションの製品の機能設定がある場合があります。このレビュー中に、以前の決定が、適用されなくなった古いテクノロジー、 AWS 機能、またはビジネス上の制約に基づいて行われたことに気付くことがあります。これは、更新を確認して優先順位を付け、エンジニアリングバックログの適切な場所に追加する良い機会です。 AWS SRA に照らしてセキュリティアーキテクチャを評価する際に検出した内容は、その分析を文書化することが有益です。決定とその根拠の履歴を記録すると、将来の決定に関する情報を提供し、優先順位を付けるのに役立ちます。

独自のセキュリティアーキテクチャの実装をブートストラップします。

AWS SRA Infrastructure as Code (IaC) モジュールは、セキュリティアーキテクチャの構築と実装を迅速かつ確実に開始する方法を提供します。これらのモジュールは、コードリポジトリセクションとパブリック GitHub リポジトリでより深く説明されています。エンジニアは、 AWS SRA ガイダンスのパターンの高品質の例に基づいて構築できるだけでなく、IAM パスワードポリシー、Amazon Simple Storage Service (Amazon S3) ブロックアカウントのパブリックアクセス、Amazon EC2 のデフォルトの Amazon Elastic Block Store (Amazon EBS) 暗号化、 との統合などの推奨セキュリティコントロールを組み込む AWS Control Tower ことで、新しい AWS アカウント がオンボーディングまたは廃止されるときにコントロールを適用または削除できます。

AWS セキュリティサービスと機能の詳細について説明します。

AWS SRA のガイダンスと議論には、個々の AWS セキュリティおよびセキュリティ関連のサービスに関する重要な機能や、デプロイと管理に関する考慮事項が含まれています。SRA AWS の機能の 1 つは、 AWS セキュリティサービスの幅と、マルチアカウント環境でどのように連携するかについての概要を提供することです。これにより、他のソースで見つかった各サービスの機能と設定を深く掘り下げることができます。この例の 1 つは、 AWS Security Hub Cloud Security Posture Management (AWS Security Hub CSPM) がさまざまな、 AWS Partner 製品 AWS のサービス、さらには独自のアプリケーションからセキュリティ検出結果を取り込む方法の説明です。

セキュリティに関する組織のガバナンスと責任について説明します。

セキュリティアーキテクチャまたは戦略を設計および実装するための重要な要素は、組織内の誰にどのセキュリティ関連の責任があるかを理解することです。例えば、セキュリティ検出結果をどこに集約してモニタリングするかという質問は、どのチームがそのアクティビティを担当するかという質問に関連付けられています。組織全体のすべての検出結果は、専用の Security Tooling アカウントにアクセスする必要がある中央チームによってモニタリングされていますか? または、個々のアプリケーションチーム (またはビジネスユニット) が特定のモニタリングアクティビティを担当しているため、特定のアラートおよびモニタリングツールにアクセスする必要がありますか? 別の例として、組織にすべての暗号化キーを一元的に管理するグループがある場合、( AWS Key Management Service AWS KMS) キーを作成するアクセス許可を持つユーザーと、それらのキーを管理するアカウントに影響します。さまざまなチームや責任など、組織の特性を理解することは、ニーズに合わせて AWS SRA を調整するのに役立ちます。逆に、セキュリティアーキテクチャの議論が、既存の組織の責任について議論し、潜在的な変更を検討するための推進力になることがあります。 は、ワークロードチームがワークロードの機能と要件に基づいてセキュリティコントロールを定義する責任がある分散型意思決定プロセス AWS を推奨します。一元化されたセキュリティおよびガバナンスチームの目標は、ワークロード所有者が情報に基づいた意思決定を行い、すべての関係者が設定、検出結果、イベントを可視化できるようにするシステムを構築することです。SRA AWS は、これらの議論を特定して通知するための手段となります。

AWS Organizations と適切なマルチアカウント戦略は、セキュリティアーキテクチャの必須要素です。ワークロード、チーム、機能を適切に分離することは、職務の分離とdefense-in-depth戦略の基盤となります。このガイドでは、これについては後のセクションで詳しく説明します。

Defense-in-depthは、組織のセキュリティコントロールを選択するための重要な設計上の考慮事項です。これは、 AWS Organizations 構造のさまざまなレイヤーに適切なセキュリティコントロールを挿入するのに役立ちます。これにより、問題の影響を最小限に抑えることができます。1 つのレイヤーに問題がある場合、他の重要な IT リソースを分離するコントロールがあります。 AWS SRA は、 AWS テクノロジースタックのさまざまなレイヤーでのさまざまな AWS のサービス 機能、およびそれらのサービスを組み合わせて使用することでdefense-in-depthを実現する方法を示しています。この defense-in-depthの概念 AWS については、後のセクションでさらに詳しく説明し、アプリケーションアカウントで設計例を示します。

堅牢で回復力のあるクラウドインフラストラクチャを構築するには、複数の AWS のサービス および 機能にまたがるさまざまなセキュリティ構成要素を使用します。特定のニーズに合わせて SRA AWS を調整するときは、 AWS のサービス および 機能の主な機能 (認証、暗号化、モニタリング、アクセス許可ポリシーなど) だけでなく、アーキテクチャの構造にどのように適合するかも考慮してください。このガイドの後のセクションでは、一部のサービスが AWS 組織全体でどのように動作するかについて説明します。他のサービスは 1 つのアカウント内で最適に動作し、一部のサービスは個々のプリンシパルにアクセス許可を付与または拒否するように設計されています。これらの両方の視点を考慮すると、より柔軟で階層化されたセキュリティアプローチを構築できます。

可能であれば (後のセクションで説明するように）、すべてのアカウントにデプロイできる を使用し AWS のサービス (一元管理ではなく配布）、ワークロードを誤用から保護し、セキュリティイベントの影響を軽減するのに役立つ一貫した共有ガードレールのセットを構築します。 AWS SRA は AWS Security Hub CSPM 、 (集中検出結果のモニタリングとコンプライアンスチェック)Amazon GuardDuty (脅威検出と異常検出）、 AWS Config (リソースモニタリングと変更検出）、IAM Access Analyzer (リソースアクセスモニタリング）、 AWS CloudTrail (環境全体のロギングサービス API アクティビティ）、Amazon Macie (データ分類) を、すべての AWS のサービス にデプロイされる の基本セットとして使用します AWS アカウント。

ガイドの委任管理セクションで後述するように AWS Organizations、サポートされている の委任管理機能を使用します。これにより、サポートされているサービスの管理者として AWS メンバーアカウントを登録できます。委任管理は、企業内のさまざまなチームが、責任に応じて個別のアカウントを使用して環境 AWS のサービス 全体で管理するための柔軟性を提供します。さらに、委任された管理者を使用すると、 AWS Organizations 管理アカウントへのアクセスを制限し、アクセス許可のオーバーヘッドを管理することができます。

組織全体で一元的なモニタリング、管理、ガバナンスを実装します AWS 。マルチアカウント (場合によってはマルチリージョン) 集約 AWS のサービス をサポートする と委任管理機能を使用することで、中央のセキュリティ、ネットワーク、クラウドエンジニアリングチームが適切なセキュリティ設定とデータ収集を広範囲に可視化し、制御できるようになります。さらに、データをワークロードチームに提供して、ソフトウェア開発ライフサイクル (SDLC) の早い段階で効果的なセキュリティ上の意思決定を行う権限を与えることができます。

AWS Control Tower を使用して、セキュリティリファレンスアーキテクチャのビルドをブートストラップする事前構築済みのセキュリティコントロールの実装により、マルチアカウント AWS 環境を設定および管理します。 は、アイデンティティ管理、アカウントへのフェデレーティッドアクセス、集中ロギング、および追加のアカウントをプロビジョニングするための定義されたワークフローを提供するブループリント AWS Control Tower を提供します。その後、Customizations for AWS Control Tower (CfCT) ソリューションを使用して、SRA コードリポジトリで示されているように、追加のセキュリティコントロール、サービス設定、ガバナンス AWS Control Tower を使用して、 AWS によって管理されるアカウントをベースライン化できます。Account Factory 機能は、承認されたアカウント設定に基づいて設定可能なテンプレートを使用して新しいアカウントを自動的にプロビジョニングし、 AWS 組織内のアカウントを標準化します。ガバナンスを既存の個人に拡張するには、すでに管理されている組織単位 (OU) に登録 AWS アカウント します AWS Control Tower。

AWS SRA コード例は、Infrastructure as Code (IaC) を使用して SRA AWS ガイド内のパターンの実装を自動化する方法を示しています。パターンをコーディングすることで、IaC を組織内の他のアプリケーションと同様に扱い、コードをデプロイする前にテストを自動化できます。IaC は、ガードレールを複数の (SDLC やリージョン固有など) 環境にデプロイすることで、一貫性と再現性を確保するのにも役立ちます。SRA コード例は、 の有無にかかわらず、 AWS Organizations マルチアカウント環境にデプロイできます AWS Control Tower。を必要とするこのリポジトリのソリューションは、 および Customizations for AWS Control Tower (CfCT) を使用してAWS Control Tower環境にデプロイ AWS CloudFormationされ、テスト AWS Control Tower されています。不要なソリューションは、AWS Organizationsを使用して環境内でテスト AWS Control Tower されていますAWS CloudFormation。を使用しない場合は AWS Control Tower、 AWS Organizationsベースのデプロイソリューションを使用できます。