の値 AWS SRA - AWS 規範ガイダンス
の使用方法 AWS SRAの主要な実装ガイドライン AWS SRA

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

の値 AWS SRA

AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えるために、簡単なアンケートに回答してください。

AWS には、セキュリティおよびセキュリティ関連のサービスの大規模 (および増加) なセットがあります。お客様は、当社のサービスドキュメント、ブログ投稿、チュートリアル、サミット、カンファレンスで入手可能な詳細情報を歓迎しています。また、全体像をよりよく理解し、AWSセキュリティサービスの戦略的視点を得たいとも言っています。お客様と連携して、必要なものをより深く理解すると、次の 3 つの優先順位が浮上します。

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

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

  • お客様は、セキュリティサービスを最も効果的な方法で統合するためのガイダンスと例を探しています。例えば、自動化された監査およびモニタリングパイプラインの面倒な作業を行うために、Config AWS を他の サービスと連携させ、接続する最善の方法を教えてください。 お客様は、各AWSセキュリティサービスが他のセキュリティサービスにどのように依存しているか、またはサポートしているかについてのガイダンスを求めています。

これらについては、「」を参照してくださいAWSSRA。リスト (モノが進む場所) で最初に優先されるのは、メインアーキテクチャ図と、このドキュメントで説明されている内容です。推奨される AWS Organizations アーキテクチャと、 account-by-accountどのサービスがどこに移動するかの説明を提供します。 リストの 2 番目の優先度 (セキュリティサービスの全セットについて考える方法) を開始するには、AWS「組織全体にセキュリティサービスを適用する」セクションをお読みください。このセクションでは、AWS組織内の要素の構造に従ってセキュリティサービスをグループ化する方法について説明します。さらに、これらの同じアイデアは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Virtual Private Cloud (Amazon VPC) ネットワーク、およびより広範な アカウントなど、アカウントの特定のレイヤーに焦点を当ててセキュリティサービスを運用する方法をハイライトするアプリケーションアカウントの説明に反映されています。最後に、3 番目の優先度 (サービス統合) がガイダンス全体に反映されます。特に、このドキュメントのアカウントの詳細セクションの個々のサービスの説明とコードリポジトリのAWSSRAコードの説明に反映されます。

の使用方法 AWS SRA

クラウド導入ジャーニーのどの段階にあるかAWSSRAに応じて、 を使用する方法はさまざまです。AWS SRA アセットから最大のインサイトを得る方法 (アーキテクチャ図、文書化されたガイダンス、コードサンプル) のリストを次に示します。

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

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

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

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

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

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

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

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

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

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

の主要な実装ガイドライン AWS SRA

ここでは、セキュリティを設計および実装する際に留意AWSSRAすべき 8 つの重要なポイントを示します。  

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

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

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

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

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

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

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

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