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

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

AWS SRA の価値

簡単なアンケートを実施して、AWSセキュリティリファレンスアーキテクチャ (AWSSRA) のfuture に影響を与えましょう。

AWS には、セキュリティおよびセキュリティ関連のサービスが多数あります (現在も増え続けています)。お客様は、当社のサービス文書、ブログ投稿、チュートリアル、サミット、会議を通じて入手できる詳細な情報に感謝の意を表しています。また、AWS セキュリティサービスの全体像をよりよく理解し、戦略的な見方をしたいとも言っています。お客様と協働して、お客様が必要としているものをより深く理解しようとすると、次の 3 つの優先事項が浮かび上がってきます。

  • お客様は、AWS セキュリティサービスを総合的にデプロイ、設定、運用する方法について、より多くの情報と推奨パターンを求めています。どのアカウントで、どのセキュリティ目標に向けてサービスをデプロイ、管理すべきか?  すべてまたはほとんどのサービスを運用できるセキュリティアカウントが 1 つあるか?  場所 (組織単位または AWS アカウント) の選択は、セキュリティ目標にどのように影響しますか? 顧客はどのようなトレードオフ (設計上の考慮事項) に注意すべきか?

  • 顧客は、多くの AWS セキュリティサービスを論理的に整理するためのさまざまな視点に興味を持っています。これらの異なる視点は、各サービスの主な機能 (ID サービスやロギングサービスなど) にとどまらず、お客様がセキュリティアーキテクチャを計画、設計、実装する際に役立ちます。このガイドで後ほど紹介する例では、お使いの AWS 環境の推奨構造に合わせた保護レイヤーに基づいてサービスをグループ化しています。

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

これらはそれぞれ AWS SRA で取り上げています。このリストの最優先事項は、このドキュメントの主なアーキテクチャ図とそれに付随する説明の焦点です。推奨される AWS Organizations アーキテクチャと、 account-by-account どのサービスがどこで使用されるかについての説明を提供します。 リストの 2 番目の優先事項 (すべてのセキュリティサービスについて考える方法) から始めるには、「AWS 組織全体にセキュリティサービスを適用する」セクションをお読みください。このセクションでは、AWS 組織内の要素の構造に従ってセキュリティサービスをグループ化する方法について説明します。さらに、同じ考えがアプリケーションアカウントの説明にも反映されています。アプリケーションアカウントでは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Virtual Private Cloud (Amazon VPC) ネットワーク、およびより広範なアカウントなど、アカウントの特定のレイヤーに焦点を当ててセキュリティサービスを運用する方法が強調されています。最後に、3 番目の優先事項 (サービス統合) はガイダンスのいたるところに反映されています。特に、このドキュメントのアカウント詳細セクションの個々のサービスと AWS SRA コードリポジトリ内のコードについて説明しています。

AWS SRA を使用する方法

AWS SRA の使用方法は、クラウド導入のどの段階にいるかによって異なります。以下は、AWS SRA アセット (アーキテクチャ図、書面によるガイダンス、コードサンプル) から最大限の洞察を得る方法のリストです。

  • 独自のセキュリティアーキテクチャのターゲット状態を定義してください。

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

  • すでに実装した設計と機能を確認 (および改訂) してください。

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

  • 独自のセキュリティアーキテクチャの実装をブートストラップしてください。

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

  • AWS のセキュリティサービスと機能の詳細をご覧ください。

AWS SRA のガイダンスと説明には、個々の AWS セキュリティおよびセキュリティ関連サービスの重要な機能のほか、デプロイと管理に関する考慮事項が含まれています。AWS SRA の特徴の 1 つは、AWS のセキュリティサービスの幅広さと、それらがマルチアカウント環境でどのように連携するかを大まかに紹介できることです。これは、他のソースにある各サービスの機能と設定の詳細な説明を補足するものです。その一例が、AWS Security Hub がさまざまな AWS サービス、AWS パートナー製品、さらには独自のアプリケーションからセキュリティ結果をどのように取り込むかについての議論です。

  • 組織のガバナンスとセキュリティに対する責任についての議論を推し進めてください。

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

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

ここでは、セキュリティを設計して実装する際に留意すべき AWS SRA の 8 つの重要なポイントを紹介します。  

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

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

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

  • 可能な限り (後のセクションで詳述するように)、すべてのアカウントにデプロイできる AWS サービス (一元化ではなく分散型) を利用し、ワークロードを誤用から保護し、セキュリティイベントの影響を軽減するのに役立つ、一貫性のある共有ガードレールを構築してください。AWS SRA は、すべての AWS アカウントにデプロイされる AWS サービスの基本セットとして、AWS Security Hub GuardDuty (一元的な検出モニタリングとコンプライアンスチェック)、Amazon (脅威検出と異常検知)、AWS Config (リソースモニタリングと変更検知)、IAM Access Analyzer CloudTrail (リソースアクセスモニタリング)、AWS (環境全体にわたるサービス API アクティビティのロギング)、Amazon Macie (データ分類) を使用しています。

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

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

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

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