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

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

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

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

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

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

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

AWS SRA で提供されている以外の AWS アカウントと OU 構造の推奨事項については、ブログ記事「中小企業向けのマルチアカウント戦略」を参照してください。OU とアカウント構造を確定する際は、サービスコントロールポリシー (SCPs。

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

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

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

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

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

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

この時点で、以下が必要です。

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

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

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

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

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

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

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