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

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

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

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

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

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

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

SRA で AWS 提供されているもの以外の AWS アカウント および OU 構造のレコメンデーションについては、「中小企業向けのマルチアカウント戦略」ブログ記事を参照してください。OU とアカウント構造を確定するときは、サービスコントロールポリシー (SCPs)、リソースコントロールポリシー (RCPs)、宣言ポリシーを使用して適用する組織全体のセキュリティコントロールを検討してください。

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

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

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

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

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

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

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

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

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

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

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

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

AWS SRA は、Security Tooling アカウントの設計と、すべての 内の一般的なセキュリティサービスのデプロイを通じて AWS アカウント、組織全体のセキュリティイベント AWS を検出する機能を提供します。Security Tooling アカウント内の Amazon Detective は、セキュリティイベントのトリアージと根本原因の特定に役立ちます。セキュリティ調査中、関連するログを確認して、インシデントの全範囲とタイムラインを記録し、理解できる必要があります。ログは、特定の目的のアクションが発生したときにアラートを生成するためにも必要です。 AWS SRA では、すべてのセキュリティログと運用ログのイミュータブルストレージとして centralLog Archive アカウントを推奨しています。CloudWatch Logs Insights を使用して CloudWatch ロググループに保存されているデータにクエリを実行し、Amazon AthenaAmazon S3 Amazon OpenSearch Service を使用してログをクエリできます。Amazon Security Lake を使用して、 AWS 環境、Software as a Service (SaaS) プロバイダー、オンプレミス、その他のクラウドプロバイダーのセキュリティデータを自動的に一元化します。SRA で説明されているように、Security Tooling AWS アカウントまたは任意の専用アカウントのサブスクライバーを設定して、調査のためにそれらのログをクエリします。 

AWS Security Incident Response は、セキュリティインシデント対応、調査、修復を自動化するのに役立ちます。セキュリティイベントに迅速かつ一貫して対応できるように、構築済みのプレイブックとワークフローが用意されています。プロアクティブレスポンス機能を有効にすると、Security Incident Response は Security Hub CSPM および GuardDuty と統合され、セキュリティ検出結果が検出されるとレスポンスワークフローが自動的にトリガーされます。このサービスは、 AWS 組織全体のインシデント対応プロセスを標準化および自動化するのに役立ちます。追加のサポートが必要な場合は、サービスサポートケースを開いて、カスタマーインシデント対応チーム (CIRT) AWS に連絡できます。