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

セキュリティアーキテクチャの構築 - 段階的アプローチ

が推奨するマルチアカウントセキュリティアーキテクチャAWSSRAは、設計プロセスの早い段階でセキュリティを導入するのに役立つベースラインアーキテクチャです。各組織のクラウドジャーニーは一意です。クラウドセキュリティアーキテクチャを正常に進化させるには、目的のターゲット状態を構想し、現在のクラウドの準備状況を理解し、ギャップを埋めるためのアジャイルアプローチを採用する必要があります。AWS SRA は、セキュリティアーキテクチャのリファレンスターゲット状態を提供します。段階的に変換することで、広範囲にわたる予測を行う必要性を最小限に抑えながら、価値をすばやく実証できます。

AWS クラウド導入フレームワーク (AWS CAF） では、Envision、Align、Launch、Scale の 4 つの反復的および段階的なクラウドトランスフォーメーションフェーズを推奨しています。起動フェーズに入り、パイロットイニシアチブを本番環境で提供することに焦点を当てるときは、スケールフェーズの基盤として強力なセキュリティアーキテクチャを構築することに集中する必要があります。これにより、最もビジネスクリティカルなワークロードを自信を持って移行して運用する技術的能力が得られます。この段階的なアプローチは、スタートアップ企業、事業を拡大したい中小企業、または新しいビジネスユニットを取得しようとしている企業、または合併や買収を受けている企業に適用されます。AWS SRA は、そのセキュリティベースラインアーキテクチャを実現するため、AWSOrganizations の拡張する組織全体にセキュリティコントロールを均一に適用できます。ベースラインアーキテクチャは、複数のAWSアカウントとサービスで構成されます。計画と実装は、ベースラインセキュリティアーキテクチャを設定するというより大きな目標を達成するために、より小さなマイルストーンを繰り返し処理できるように、複数フェーズのプロセスである必要があります。このセクションでは、構造化されたアプローチに基づくクラウドジャーニーの一般的なフェーズについて説明します。これらのフェーズは、 AWS Well-Architected フレームワークのセキュリティ設計原則と一致しています。

フェーズ 1: OU とアカウント構造を構築する

強固なセキュリティ基盤の前提条件は、適切に設計されたAWS組織とアカウント構造です。このガイドのSRA「構成要素」セクションで前述したように、複数のAWSアカウントを持つことで、さまざまなビジネス機能とセキュリティ機能を設計的に分離できます。これは、最初は不要な作業のように思えるかもしれませんが、迅速かつ安全にスケーリングするための投資です。このセクションでは、AWSOrganizations を使用して複数のAWSアカウントを管理する方法と、信頼されたアクセスと委任された管理者機能を使用して、これらの複数のアカウント間でAWSサービスを一元管理する方法についても説明します。

このガイドの前半で説明したように AWS Control Tower を使用して、ランディングゾーンをオーケストレーションできます。現在 1 つのAWSアカウントを使用している場合は、「複数のAWSアカウントへの移行」ガイドを参照して、できるだけ早く複数のアカウントに移行してください。例えば、スタートアップ企業が現在 1 つのAWSアカウントで製品を作成し、プロトタイプを作成している場合は、市場に製品を起動する前にマルチアカウント戦略を採用することを検討する必要があります。同様に、小規模、中規模、エンタープライズの組織は、最初の本番ワークロードを計画したらすぐにマルチアカウント戦略の構築を開始する必要があります。基盤OUsとAWSアカウントから始めて、ワークロード関連の OUsとアカウントを追加します。

で提供されているもの以外のAWSアカウントと OU 構造の推奨事項についてはAWSSRA、ブログ記事「中小企業向けマルチアカウント戦略」を参照してください。OU とアカウント構造を確定する際には、サービスコントロールポリシー () を使用して適用する組織全体のセキュリティコントロールの概要を考慮してくださいSCPs。

フェーズ 2: 強力な ID 基盤を実装する

複数のAWSアカウントを作成したらすぐに、それらのアカウント内のAWSリソースへのアクセス権をチームに付与する必要があります。アイデンティティ管理には、ワークフォースアイデンティティとアクセス管理、カスタマーアイデンティティとアクセス管理 (CIAM） の 2 つの一般的なカテゴリがあります。ワークフォースIAMは、従業員と自動化されたワークロードがジョブを実行するAWSために にログインする必要がある組織用です。 CIAMは、組織のアプリケーションへのアクセスを提供するためにユーザーを認証する方法が必要な場合に使用されます。チームがアプリケーションを構築して移行できるように、まずワークフォースIAM戦略が必要です。ヒューマンIAMユーザーまたはマシンユーザーにアクセスを提供するには、常にユーザーではなく IAMロールを使用する必要があります。組織管理アカウントと共有サービスアカウント内で AWS IAM Identity Center を使用して、AWSアカウントへのシングルサインオン (SSO) アクセスを一元管理する方法に関するAWSSRAガイダンスに従ってください。また、このガイダンスでは、 IAM Identity Center を使用できないときにIAMフェデレーションを使用するための設計上の考慮事項についても説明します。

IAM ロールを使用して AWSリソースへのユーザーアクセスを提供する場合は、このガイドの「セキュリティツールと組織管理」セクションで説明されているようにAWSIAM、Access Analyzer とIAMアクセスアドバイザーを使用する必要があります。 組織管理アカウントこれらのサービスは、最小特権の達成に役立ちます。これは、適切なセキュリティ体制を構築するのに役立つ重要な予防コントロールです。

フェーズ 3: トレーサビリティを維持する

ユーザーが にアクセスして構築を開始するAWSと、誰が何を、いつ、どこから何をしているのかを知りたいでしょう。また、潜在的なセキュリティ設定ミス、脅威、予期しない動作を可視化することもできます。セキュリティの脅威をよりよく理解することで、適切なセキュリティコントロールに優先順位を付けることができます。AWS アクティビティをモニタリングするには、 を使用し、ログアーカイブアカウント内でログをAWS CloudTrail一元化して、組織の証跡を設定するためのAWSSRA推奨事項に従ってください。セキュリティイベントのモニタリングには、AWS「Security Tooling アカウント」セクションの説明に従って、AWSSecurity AWS Hub GuardDuty、Amazon、Config、Security Lake を使用します。 セキュリティ OU - Security Tooling アカウント

フェーズ 4: すべてのレイヤーにセキュリティを適用する

この時点で、次のものが必要です。

このフェーズでは、AWS「組織全体にセキュリティサービスを適用する」セクションで説明されているように、AWS組織の他のレイヤーにセキュリティを適用することを計画します。ネットワークアカウントセクションで説明されているようにWAF、、AWSShield、AWSFirewall Manager、AWSNetwork Firewall、 AWS Certificate Manager (ACM） CloudFront、AmazonVPC、Amazon Route AWS 53、Amazon などのサービスを使用して、ネットワークレイヤーのセキュリティコントロールを構築できます。 Amazon Route 53 テクノロジースタックを下るときは、ワークロードまたはアプリケーションスタックに固有のセキュリティコントロールを適用します。「アプリケーションアカウント」セクションの説明に従って、VPCエンドポイント、Amazon Inspector、Amazon Systems Manager、AWSSecrets Manager、および Amazon Cognito を使用します。

フェーズ 5: 転送中と保管中のデータを保護する

ビジネスデータと顧客データは、保護する必要がある貴重なアセットです。 AWSは、転送中および保管中のデータを保護するためのさまざまなセキュリティサービスと機能を提供します。「ネットワークアカウント」セクションで説明されているように、 AWS Certificate Manager AWS CloudFront で を使用して、インターネット経由で収集された転送中のデータを保護します。内部ネットワーク内で転送されるデータについては、「アプリケーションアカウント」セクションで説明されているように、プライベート認証機関を備えた Application Load Balancer を使用します。 AWSKMSと AWS クラウドHSMは、保管中のデータを保護するための暗号化キー管理を提供します。 AWS ワークロード OU - アプリケーションアカウント

フェーズ 6: セキュリティイベントに備える

IT 環境を運用する際に、セキュリティイベントが発生します。これは、セキュリティポリシー違反やセキュリティコントロールの失敗の可能性を示す、IT 環境の日常業務における変更です。セキュリティイベントをできるだけ早く認識するには、適切なトレーサビリティが不可欠です。セキュリティイベントがエスカレートする前に適切なアクションを実行できるように、このようなセキュリティイベントをトリアージして対応できるように準備することも同様に重要です。準備を行うと、セキュリティイベントを迅速に優先順位付けして、潜在的な影響を把握できます。

はAWSSRA、Security Tooling アカウントの設計とすべてのAWSアカウント内での一般的なセキュリティサービスのデプロイを通じて、AWS組織全体のセキュリティイベントを検出する機能を提供します。 AWSSecurity Tooling アカウント内の Detective は、セキュリティイベントのトリアージと根本原因の特定に役立ちます。セキュリティ調査中、関連するログを確認して、インシデントの全範囲とタイムラインを記録し、理解できる必要があります。ログは、特定の目的のアクションが発生したときにアラートを生成するためにも必要です。

では、すべてのセキュリティログと運用ログのイミュータブルストレージとして、中央のログアーカイブアカウントAWSSRAを推奨しています。CloudWatch Logs Insights を使用してロググループに保存されているデータにクエリを実行し、Amazon S3 に保存されているデータに Amazon Athena と Amazon OpenSearch Service を使用して CloudWatch ログをクエリできます。 Amazon S3 Amazon Security Lake を使用して、AWS環境、Software as a Service (SaaS) プロバイダー、オンプレミス、その他のクラウドプロバイダーのセキュリティデータを自動的に一元化します。で説明されているように、Security Tooling AWS アカウントまたは任意の専用アカウントのサブスクライバーを設定してSRA、調査のためにそれらのログをクエリします。