翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# セキュリティアーキテクチャの構築 – 段階的なアプローチ
| |
| --- |
| [簡単な調査](https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua)を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。 |
AWS SRA が推奨するマルチアカウントセキュリティアーキテクチャは、設計プロセスの早い段階でセキュリティを挿入するのに役立つベースラインアーキテクチャです。各組織のクラウドジャーニーは一意です。クラウドセキュリティアーキテクチャを正常に 進化させるには、希望するターゲット状態を構想し、現在のクラウドの準備状況を理解し、ギャップを埋めるためのアジャイルアプローチを採用する必要があります。 AWS SRA は、セキュリティアーキテクチャの参照ターゲット状態を提供します。段階的に変換することで、広範囲の予測を行う必要性を最小限に抑えながら、価値をすばやく実証できます。
[AWS クラウド導入フレームワーク](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/welcome.html) (AWS CAF) では、 [ビジョン化、調整、起動、スケーリングの 4 つの反復的および増分的なクラウド変換フェーズを推奨しています](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/your-cloud-transformation-journey.html)。起動フェーズに入り、本番稼働環境でパイロットイニシアチブを提供することに重点を置く際には、最もビジネスクリティカルなワークロードを自信を持って移行して運用するための技術的な能力を確保するために、スケールフェーズの基盤として強力なセキュリティアーキテクチャを構築することに集中する必要があります。この段階的なアプローチは、スタートアップ企業、事業を拡大したい中小企業、または新しいビジネスユニットを買収したり、合併や買収を行っている企業に適用されます。 AWS SRA は、そのセキュリティベースラインアーキテクチャを実現するのに役立ちます。これにより、 で拡張する組織全体にセキュリティコントロールを均一に適用できます AWS Organizations。ベースラインアーキテクチャは、複数の AWS アカウント および サービスで構成されます。計画と実装は、より小さなマイルストーンを繰り返してベースラインセキュリティアーキテクチャを設定するというより大きな目標を達成できるように、複数フェーズのプロセスである必要があります。このセクションでは、構造化されたアプローチに基づくクラウドジャーニーの一般的なフェーズについて説明します。これらのフェーズは、 [AWS Well-Architected フレームワークのセキュリティ設計原則](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec-design.html)と一致しています。
## フェーズ 1: OU とアカウント構造を構築する
強力なセキュリティ基盤の前提条件は、適切に設計された AWS 組織とアカウント構造です。このガイドの[「SRA 構成要素](organizations.md)」セクションで前述したように、複数の を使用することで、さまざまなビジネス機能とセキュリティ機能を設計的に分離 AWS アカウント できます。これは最初は不要な作業のように見えるかもしれませんが、迅速かつ安全にスケーリングするための投資です。このセクションでは、 AWS Organizations を使用して複数の を管理する方法と AWS アカウント、信頼されたアクセスと委任された管理者機能を使用してこれらの複数のアカウント AWS のサービス 間で一元管理する方法についても説明します。
このガイドで前述した[AWS Control Tower](org-management.md#mgmt-tower)ように を使用して、ランディングゾーンをオーケストレーションできます。現在 1 つの を使用している場合は AWS アカウント、 [「複数のアカウントへの移行 AWS アカウント](https://docs.aws.amazon.com/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/welcome.html) 」ガイドを参照して、できるだけ早く複数のアカウントに移行してください。例えば、スタートアップ企業が現在 1 つの製品で製品のアイデアとプロトタイプを作成している場合は AWS アカウント、製品を市場に投入する前にマルチアカウント戦略を採用することを検討する必要があります。同様に、小規模、中規模、エンタープライズの組織は、最初の本番ワークロードを計画したらすぐにマルチアカウント戦略の構築を開始する必要があります。基盤 OUs と から開始し AWS アカウント、ワークロード関連の OUs とアカウントを追加します。
SRA で AWS 提供されているもの以外の AWS アカウント および OU 構造の推奨事項については、ブログ記事 [「中小企業向けのマルチアカウント戦略](https://aws.amazon.com/blogs/mt/multi-account-strategy-for-small-and-medium-businesses/) 」を参照してください。OU とアカウント構造を確定するときは、サービスコントロールポリシー (SCPs)、リソースコントロールポリシー (RCPs)、宣言ポリシーを使用して適用する組織全体のセキュリティコントロールを検討してください。
**設計上の考慮事項**
OU とアカウント構造を設計するときは、会社のレポート構造をレプリケートしないでください。OUs は、ワークロード関数と、ワークロードに適用される一般的な一連のセキュリティコントロールに基づいている必要があります。アカウント構造全体を最初から設計しないでください。基本的な OUs に焦点を当て、必要に応じてワークロード OUs を追加します。 [OUs 間でアカウントを移動](https://docs.aws.amazon.com/organizations/latest/userguide/move_account_to_ou.html)して、設計の初期段階で代替アプローチを試すことができます。ただし、OU とアカウントパスに基づく SCPs、RCPs、宣言ポリシー、IAM 条件によっては、論理アクセス許可の管理に多少のオーバーヘッドが発生する可能性があります。
**実装例**
[AWS SRA コードライブラリ](https://github.com/aws-samples/aws-security-reference-architecture-examples)は、[アカウント代替連絡先](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/account/account_alternate_contacts)のサンプル実装を提供します。このソリューションは、組織内のすべてのアカウントの請求、オペレーション、およびセキュリティの代替連絡先 を設定します。
## フェーズ 2: 強力な ID 基盤を実装する
複数の を作成するとすぐに AWS アカウント、それらのアカウント内の AWS リソースへのアクセス権をチームに付与する必要があります。ID 管理には、[ワークフォース ID とアクセス管理、カスタマー ID](https://aws.amazon.com/identity/workforce-identities/) と[アクセス管理](https://aws.amazon.com/identity/customer-identities/) (CIAM) の 2 つの一般的なカテゴリがあります。ワークフォース IAM は、従業員と自動化されたワークロードがジョブを実行する AWS ために にログインする必要がある組織向けです。CIAM は、組織のアプリケーションへのアクセスを提供するユーザーを認証する方法を組織が必要とする場合に使用されます。チームがアプリケーションを構築して移行できるように、まずワークフォース IAM 戦略が必要です。人間またはマシンユーザーにアクセスを提供するには、常に IAM ユーザーではなく IAM ロールを使用する必要があります。[組織管理](org-management.md#mgmt-sso)アカウントと共有[サービス](shared-services.md#shared-sso)アカウント AWS IAM アイデンティティセンター 内で AWS を使用して、 へのシングルサインオン (SSO) アクセスを一元管理する方法に関する SRA ガイダンスに従ってください AWS アカウント。このガイダンスでは、IAM Identity Center を使用できないときに IAM フェデレーションを使用するための設計上の考慮事項も示しています。
IAM ロールを使用して AWS リソースへのユーザーアクセスを提供する場合は、このガイドの[「セキュリティツールと組織管理](security-tooling.md)」セクションで説明されているように、IAM Access Analyzer と IAM アクセスアドバイザーを使用する必要があります。 [組織管理アカウント](org-management.md)これらのサービスは、最小特権の達成に役立ちます。これは、適切なセキュリティ体制の構築に役立つ重要な予防コントロールです。
**設計上の考慮事項**
最小特権を実現するには、ID と適切な機能に必要なアクセス許可との関係を定期的に確認および理解するプロセスを設計します。学習したら、これらのアクセス許可を微調整し、最小限のアクセス許可に徐々に減らします。スケーラビリティについては、中央のセキュリティチームとアプリケーションチームの間で責任を共有する必要があります。 [リソースベースのポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)、 [アクセス許可の境界](https://aws.amazon.com/blogs/security/delegate-permission-management-to-developers-using-iam-permissions-boundaries/)、 [属性ベースのアクセスコントロール](https://www.youtube.com/watch?v=Iq_hDc385t4&t=1318s)、 [セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) などの機能を使用して、アプリケーション所有者がきめ細かなアクセスコントロールを定義できるようにします。
**実装例**
[AWS SRA コードライブラリ](https://github.com/aws-samples/aws-security-reference-architecture-examples)には、このフェーズに適用される 2 つのサンプル実装が用意されています。
[IAM パスワードポリシー](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/iam/iam_password_policy)は、一般的なコンプライアンス標準に合わせてユーザーのアカウントパスワードポリシーを設定します。
[Access Analyzer](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/iam/iam_access_analyzer) は、委任管理者アカウント内の組織レベルのアナライザーと、各アカウント内のアカウントレベルのアナライザーを設定します。
## フェーズ 3: トレーサビリティを維持する
ユーザーが にアクセスして構築を開始する AWS と、誰が何を、いつ、どこで行っているかを知ることができます。また、潜在的なセキュリティ設定ミス、脅威、予期しない動作を可視化することもできます。セキュリティ脅威をよりよく理解することで、適切なセキュリティコントロールに優先順位を付けることができます。アクティビティをモニタリング AWS するには、 を使用して[ログアーカイブ](log-archive.md)アカウント内にログを[AWS CloudTrail](security-tooling.md#tool-cloudtrail)一元化することで、組織の証跡を設定するための AWS SRA の推奨事項に従います。セキュリティイベントのモニタリングには、「 Security [Tooling アカウント](security-tooling.md)」セクションで説明されているように、、 AWS Security Hub CSPM Amazon GuardDuty AWS Config、および Amazon Security Lake を使用します。
**設計上の考慮事項**
新しい の使用を開始するときは AWS のサービス、サービスの [サービス固有のログ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html) を有効にし、中央ログリポジトリの一部として保存します。
**実装例**
[AWS SRA コードライブラリ](https://github.com/aws-samples/aws-security-reference-architecture-examples)には、このフェーズに適用される以下のサンプル実装が用意されています。
[Organization CloudTrail](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/cloudtrail/cloudtrail_org) は組織の証跡を作成し、 によって設定された CloudTrail の重複を減らすためにデータイベント (Amazon S3 や など AWS Lambda) を設定するデフォルトを設定します AWS Control Tower。このソリューションには、管理イベントを設定するためのオプションが用意されています。
[AWS Config Control Tower 管理アカウント](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_management_account) は、管理アカウント AWS Config で がリソースのコンプライアンスをモニタリングできるようにします。
[Conformance Pack Organization Rules](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_conformance_pack_org) は、組織内のアカウントと指定されたリージョンにコンフォーマンスパックをデプロイします。
[AWS Config アグリゲータ](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/config/config_aggregator_org) は、監査アカウント以外のメンバーアカウントに管理を委任することで、アグリゲータをデプロイします。
[Security Hub CSPM Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/securityhub/securityhub_org) は、組織内のアカウントと管理対象リージョンの委任管理者アカウント内で Security Hub CSPM を設定します。
[GuardDuty Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/guardduty/guardduty_org) は、組織内のアカウントの委任管理者アカウント内で GuardDuty を設定します。
## フェーズ 4: すべてのレイヤーにセキュリティを適用する
この時点で、次のものが必要です。
+ に適したセキュリティコントロール AWS アカウント。
+ SCPs、RCPs、宣言型ポリシー、最小特権 IAM ロールとポリシーを通じて定義された予防コントロールを持つ明確に定義されたアカウントと OU 構造。
+ を使用して AWS アクティビティをログに記録し AWS CloudTrail、 AWS Security Hub CSPM、、Amazon GuardDuty、および を使用してセキュリティイベントを検出 AWS Configし、Amazon Security Lake を使用してセキュリティのために専用のデータレイクで高度な分析を実行する機能。
このフェーズでは、「組織全体にセキュリティサービスを適用する」セクションで説明されているように、 AWS 組織の他のレイヤーにセキュリティを適用する計画を立てます。 [AWS](security-services.md) ネットワークアカウントセクションで説明されているように AWS WAF AWS Shield、 AWS Certificate Manager (ACM) AWS Firewall Manager、Amazon CloudFront AWS Network Firewall、Amazon Route 53、Amazon VPC などのサービスを使用して、 [ネットワーク](network.md)レイヤーのセキュリティコントロールを構築できます。テクノロジースタックを下に移動するときは、ワークロードまたはアプリケーションスタックに固有のセキュリティコントロールを適用します。[アプリケーションアカウント](application.md) セクションで説明されているように、VPC エンドポイント、Amazon Inspector AWS Systems Manager AWS Secrets Manager、および Amazon Cognito を使用します。
**設計上の考慮事項**
多層防御 (DiD) セキュリティコントロールを設計するときは、スケーリング要因を検討してください。中央セキュリティチームには、環境内のすべてのアプリケーションの動作に関する帯域幅や完全な理解はありません。アプリケーションチームに、アプリケーションに適したセキュリティコントロールを特定して設計する責任と説明責任を持たせます。中央セキュリティチームは、アプリケーションチームを可能にするための適切なツールと相談の提供に集中する必要があります。が AWS セキュリティへのよりシフトレフトなアプローチを採用するために使用するスケーリングメカニズムを理解するには、ブログ記事「セキュリティ [所有権を分散するメカニズムである Security Guardians プログラム AWS の構築方法](https://aws.amazon.com/blogs/security/how-aws-built-the-security-guardians-program-a-mechanism-to-distribute-security-ownership/)」を参照してください。
**実装例**
[AWS SRA コードライブラリ](https://github.com/aws-samples/aws-security-reference-architecture-examples)には、このフェーズに適用される以下のサンプル実装が用意されています。
[EC2 Default EBS Encryption](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/ec2/ec2_default_ebs_encryption) は、提供された AWS KMS key 内のデフォルトを使用するように Amazon EC2 のデフォルトの Amazon EBS 暗号化を設定します AWS リージョン。
[S3 ブロックアカウントパブリックアクセス](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/s3/s3_block_account_public_access) は、組織内のアカウントに対して Amazon S3 のアカウントレベルのブロックパブリックアクセス (BPA) 設定を構成します。
[Firewall Manager](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/firewall_manager/firewall_manager_org) は、組織内のアカウントのセキュリティグループポリシーと AWS WAF ポリシーを設定する方法を示します。
[Inspector Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/blob/main/aws_sra_examples/solutions/inspector/inspector_org) は、組織内のアカウントと管理対象リージョンの委任管理者アカウント内で Amazon Inspector を設定します。
## フェーズ 5: 転送中および保管中のデータを保護する
ビジネスデータと顧客データは、保護する必要がある貴重なアセットです。 AWS は、移動中および保管中のデータを保護するためのさまざまなセキュリティサービスと機能を提供します。 [ネットワークアカウント](network.md) セクションで説明されているように AWS Certificate Manager、 で Amazon CloudFront を使用して、インターネット経由で収集された転送中のデータを保護します。内部ネットワーク内で転送中のデータについては、「アプリケーションアカウント」セクションで説明されているように、 で Application Load Balancer を使用します。 AWS KMS と は、保管中のデータを保護するための暗号化キー管理を提供する AWS CloudHSM のに役立ちます。 AWS Private Certificate Authority [ワークロード OU — アプリケーションアカウント](application.md)
## フェーズ 6: セキュリティイベントに備える
IT 環境を運用すると、セキュリティイベントが発生します。これは、セキュリティポリシー違反の可能性やセキュリティコントロールの失敗を示す、IT 環境の日常業務における変更です。セキュリティイベントをできるだけ早く認識するには、適切なトレーサビリティが不可欠です。セキュリティイベントがエスカレートする前に適切なアクションを実行できるように、このようなセキュリティイベントの優先順位付けと対応を準備することも同様に重要です。準備は、セキュリティイベントを迅速にトリアージして、潜在的な影響を理解するのに役立ちます。
AWS SRA は、 [Security Tooling アカウント](security-tooling.md) の設計と [すべての 内での一般的なセキュリティサービスのデプロイを通じて AWS アカウント、](security-tooling.md#tool-common)組織全体のセキュリティイベント AWS を検出する機能を提供します。Security Tooling アカウント内の [Amazon Detective](security-tooling.md#tool-detective) は、セキュリティイベントの優先順位付けと根本原因の特定に役立ちます。セキュリティ調査中、関連するログを確認して、インシデントの全範囲とタイムラインを記録し、理解できる必要があります。特定の目的のアクションが発生した場合にアラートを生成するには、ログも必要です。 AWS SRA では、すべてのセキュリティログと運用ログのイミュータブルストレージとして、中央 [のログアーカイブアカウント](log-archive.md) を推奨しています。 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) を使用して CloudWatch ロググループに保存されているデータをクエリし、[Amazon Athena](https://aws.amazon.com/athena/) と [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) を使用して Amazon S3 に保存されているデータを CloudWatch クエリできます。Amazon Security Lake を使用して、 AWS 環境、Software as a Service (SaaS) プロバイダー、オンプレミス、その他のクラウドプロバイダーのセキュリティデータを自動的に一元化します。SRA で説明されているように、Security Tooling AWS アカウントまたは専用アカウントの[サブスクライバーを設定](security-tooling.md#tool-security-lake)して、調査のためにそれらのログをクエリします。
[AWS Security Incident Response](https://aws.amazon.com/security-incident-response/) は、セキュリティインシデント対応、調査、修復を自動化するのに役立ちます。セキュリティイベントに迅速かつ一貫して対応できるように、構築済みのプレイブックとワークフローが用意されています。プロアクティブレスポンス機能を有効にすると、Security Incident Response は [Security Hub CSPM および GuardDuty と統合](https://docs.aws.amazon.com/security-ir/latest/userguide/detect-and-analyze.html)され、セキュリティ検出結果が検出されるとレスポンスワークフローが自動的にトリガーされます。このサービスは、 AWS 組織全体のインシデント対応プロセスを標準化および自動化するのに役立ちます。追加のサポートが必要な場合は、サービスサポートケースを開いて、カスタマーインシデント対応チーム (CIRT) AWS に連絡できます。
**設計上の考慮事項**
クラウドジャーニーの最初からセキュリティイベントを検出して対応するための準備を開始する必要があります。限られたリソースをより有効に活用するには、データとビジネス重要度を AWS リソースに割り当てます。これにより、セキュリティイベントを検出したときに、関連するリソースの重要度に基づいてトリアージと対応を優先できます。
このセクションで説明するように、クラウドセキュリティアーキテクチャを構築するためのフェーズは、本質的に順次です。ただし、次のフェーズを開始する前に、1 つのフェーズが完全に完了するのを待つ必要はありません。反復アプローチを採用することをお勧めします。反復アプローチでは、複数のフェーズに並行して作業を開始し、クラウドセキュリティ体制を進化させるたびに各フェーズを進化させます。さまざまなフェーズを進めるにつれて、設計は進化します。次の図に示す推奨シーケンスを特定のニーズに合わせて調整することを検討してください。
![\[クラウドセキュリティアーキテクチャの構築における連続フェーズと反復フェーズ。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/security-reference-architecture/images/sra-phases.png)
**実装例**
[AWS SRA コードライブラリ](https://github.com/aws-samples/aws-security-reference-architecture-examples)は、** **[Detective Organization](https://github.com/aws-samples/aws-security-reference-architecture-examples/tree/main/aws_sra_examples/solutions/detective/detective_org)** **のサンプル実装を提供します。 これにより、管理をアカウント (監査やセキュリティツールなど) に委任して Amazon Detective を自動的に有効にし、既存および将来の AWS Organizations アカウント用に Detective を設定します。