翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
境界セキュリティ
| 簡単な調査を行い、 AWS セキュリティリファレンスアーキテクチャ (AWS SRA) の未来に影響を与えます。 https://amazonmr.au1.qualtrics.com/jfe/form/SV_e3XI1t37KMHU2ua |
このセクションでは、AWS SRA ガイダンスを拡張して、AWS 上に安全な境界を構築するための推奨事項を示します。AWS の境界サービスと、それらが AWS SRA で定義されている OU にどのように適合するかについて詳しく説明します。
このガイダンスでは、perimeter (境界) はアプリケーションがインターネットに接続する境界として定義されています。境界のセキュリティには、安全なコンテンツ配信、アプリケーション層保護、分散型サービス拒否 (DDoS) 対策が含まれます。AWS 境界サービスには CloudFront、Amazon 、AWS WAF 、AWS Shield 、Amazon Route 53、および AWS Global Accelerator が含まれます。これらのサービスは、AWS リソースとコンテンツ配信への安全で低レイテンシーかつ高性能なアクセスを提供するように設計されています。これらの境界サービスは、Amazon GuardDuty や AWS Firewall Manager などの他のセキュリティサービスで使用して、アプリケーションの安全な境界を構築できます。
境界セキュリティには複数のアーキテクチャパターンがあり、組織のさまざまなニーズに対応できます。このセクションでは、中央の (ネットワーク) アカウントに境界サービスを展開するパターンと、一部の境界サービスを個々のワークロード (アプリケーション) アカウントに展開する 2 つの一般的なパターンに焦点を当てます。このセクションでは、両方のアーキテクチャの利点と主な考慮事項について説明します。
境界サービスを 1 つのネットワークアカウントにデプロイする
以下の図は AWS SRA をベースとしており、境界サービスがネットワークアカウントにデプロイされるアーキテクチャを示しています。
境界サービスを 1 つのネットワークアカウントに展開することには、いくつかの利点があります。
-
このパターンは、規制の厳しい業界など、組織全体の境界サービスの管理を単一の専門チームに制限したい場合に役立ちます。
-
これにより、ネットワークコンポーネントの作成、変更、削除を制限するために必要な設定が簡単になります。
-
検査が 1 か所で行われるため、ログの集約ポイントが少なくなるため、検出が簡単になります。
-
CloudFront ポリシーやエッジ関数などのカスタムベストプラクティスリソースを作成し、同じアカウントのディストリビューション間で共有できます。
-
変更を実装する場所を減らすことで、コンテンツ配信ネットワーク (CDN) のキャッシュ設定や DNS レコードなど、設定エラーの影響を受けやすいビジネスクリティカルなリソースの管理を簡素化します。
以下のセクションでは、各サービスについて詳しく説明し、アーキテクチャ上の考慮事項について説明します。
Amazon CloudFront
Amazon CloudFront
このデプロイアーキテクチャでは、エッジ関数を含むすべての CloudFront 設定がネットワークアカウントにデプロイされ、一元化されたネットワークチームによって管理されます。ネットワークチームの権限を持つ従業員のみがこのアカウントにアクセスできるようにする必要があります。AWS WAF CloudFront の設定またはウェブアクセスコントロールリスト (ウェブ ACL) を変更したいアプリケーションチームは、ネットワークチームにそれらの変更をリクエストする必要があります。アプリケーションチームが設定変更をリクエストするためのチケットシステムなどのワークフローを確立することをお勧めします。
このパターンでは、動的オリジンと静的オリジンの両方が個々のアプリケーションアカウントにあるため、これらのオリジンにアクセスするには、クロスアカウント権限とクロスアカウントロールが必要です。 CloudFront ディストリビューションからのログは、ログアーカイブアカウントに送信するように設定されています。
AWS WAF
AWS WAF は、保護されたウェブアプリケーションリソースに転送される HTTP と HTTPS リクエストをモニタリングできるウェブアプリケーションファイアウォールです。このサービスは、一般的なウェブエクスプロイトや大量の脅威だけでなく、アカウント作成詐欺、ユーザーアカウントへの不正アクセス、検出を回避しようとするボットなどのより高度な脅威からもリソースを保護するのに役立ちます。AWS WAF は、 CloudFront ディストリビューション、Amazon API Gateway REST APIs、Application Load Balancer、AWS AppSync GraphQL APIs、Amazon Cognito ユーザープール、AWS App Runner サービス、および AWS Verified Access インスタンスのリソースタイプを保護するのに役立ちます。
このデプロイアーキテクチャでは、AWS WAF はネットワークアカウントで設定された CloudFront ディストリビューションにアタッチされます。で AWS WAF を設定すると CloudFront、境界フットプリントはアプリケーション VPC ではなく CloudFront エッジロケーションに拡張されます。これにより、悪意のあるトラフィックのフィルタリングがトラフィックのソースに近づき、悪意のあるトラフィックがコアネットワークに侵入するのを防ぐことができます。
ウェブ ACL はネットワークアカウントにデプロイされますが、AWS Firewall Manager を使用してウェブ ACL を一元管理し、すべてのリソースが準拠していることを確認することをお勧めします。セキュリティツールアカウントを Firewall Manager の管理者アカウントとして設定します。自動修復を使用して Firewall Manager ポリシーをデプロイし、アカウント内のすべての (または選択した) CloudFront ディストリビューションにウェブ ACL がアタッチされるようにします。
S3 バケットへのクロスアカウントアクセスを設定することで、ログアーカイブアカウントの S3 バケットに AWS WAF ログをすべて送信できます。詳細については、このトピックに関する「AWS re:Post の記事
AWS Shield と AWS Route 53 ヘルスチェック
AWS Shield
Shield スタンダードはユーザーが設定できないため、このセクションではShield の詳細設定に焦点を当てます。
CloudFront ディストリビューションを保護するように Shield Advanced を設定するには、ネットワークアカウントを Shield Advanced にサブスクライブします。アカウントに Shield Response Team (SRT) サポートを追加し、DDoS イベント中に SRT チームがウェブ ACL にアクセスするために必要な権限を付与します。アクティブな DDoS イベントが発生している間は、いつでも SRT に連絡して、アプリケーションのカスタム緩和策を作成および管理できます。事前にアクセスを設定しておくと、SRT はイベント中に権限を管理しなくてもウェブ ACL を柔軟にデバッグして修正できます。
自動修復で Firewall Manager を使用して、 CloudFront ディストリビューションを保護されたリソースとして追加します。アプリケーションロードバランサーなど、インターネットに接続する他のリソースがある場合は、それらを Shield Advanced の保護対象リソースとして追加することを検討してください。ただし、データフローに複数の Shield Advanced で保護されたリソースがある場合 (例えば、Application Load Balancer が のオリジンである場合 CloudFront）、Shield Advanced の重複データ転送 (DTO) 料金を削減するために、保護されたリソースとしてエントリポイントのみを使用することをお勧めします。
プロアクティブエンゲージメント機能を有効にすると、SRT が保護対象リソースをプロアクティブに監視し、必要に応じて連絡できるようにします。プロアクティブエンゲージメント機能を効果的に設定するには、アプリケーションの Route 53 ヘルスチェックを作成し、ディス CloudFront トリビューションに関連付けます。Shield Advanced は、イベントを評価する際の追加のデータポイントとしてヘルスチェックを使用します。検出による誤検出を減らすには、Health チェックを適切に定義する必要があります。ヘルスチェックの正しいメトリックスを特定する方法の詳細については、AWS ドキュメントの「Shield Advanced でヘルスチェックを使用する際のベストプラクティス」を参照してください。DDoS 攻撃を検出した場合は、SRT に連絡して、サポートプランで使用可能な最も高い重要度を選択できます。
AWS Certificate Manager と AWS Route 53
AWS Certificate Manager (ACM)
ACM は、 CloudFront ディストリビューションのパブリック TLS 証明書を生成するためにネットワークアカウントにデプロイされます。ビューワーと 間の HTTPS 接続を確立するには、TLS 証明書が必要です CloudFront。詳細については、 CloudFront ドキュメントを参照してください。ACM は DNS または E メールの検証を行って、ドメインの所有権を検証します。Route 53 を使用してパブリック DNS レコードを管理すると、ACM を使用してレコードを直接更新できるため、E メール検証ではなく DNS 検証を使用することをお勧めします。証明書は使用中で DNS レコードが残っている状態であれば、DNS で検証済みの証明書は ACM によって自動的に更新されます。
CloudFront アクセスログと AWS WAF ログ
デフォルトでは、 CloudFront アクセスログはネットワークアカウントに保存され、AWS WAF ログは Firewall Manager ログ記録オプションを使用して Security Tooling アカウントに集約されます。これらのログは Log Archive アカウントに複製して、一元化されたセキュリティチームがモニタリング目的でアクセスできるようにすることをお勧めします。
設計上の考慮事項
-
このアーキテクチャでは、1 つのネットワークチームに多数の依存関係があると、変更を迅速に行うことができなくなる可能性があります。
-
各アカウントのサービスクォータを監視してください。サービスクォータ (limits (制限) とも呼ばれます) は、AWS アカウントのサービスリソースまたはオペレーションの最大数です。詳細については、AWS ドキュメントの「 サービスの制限」を参照してください。
-
ワークロードチームに特定のメトリクスを提供すると、複雑になる場合があります。
-
アプリケーションチームは設定へのアクセスを制限しているため、ネットワークチームが代わりに変更を実装するのを待つことでオーバーヘッドが発生する可能性があります。
-
1 つのアカウントでリソースを共有するチームは、同じリソースと予算をめぐって競合する可能性があり、リソースの割り当てが難しくなる可能性があります。Networking アカウントにデプロイされた境界サービスを使用するアプリケーションチームからチャージバックする仕組みを導入することをお勧めします。
境界サービスを個々のアプリケーションアカウントにデプロイする。
次の図は、境界サービスを個々のアプリケーションアカウントに個別に展開および管理するアーキテクチャパターンを示しています。
境界サービスをアプリケーションアカウントに展開することには、いくつかの利点があります。
-
この設計により、個々のワークロードアカウントがニーズに基づいてサービス構成を自主的にカスタマイズできるようになります。このアプローチにより、共有アカウント内のリソースへの変更を実施する専門チームへの依存がなくなり、各チームの開発者が構成を個別に管理できるようになります。
-
各アカウントには独自のサービスクォータがあるため、アプリケーション所有者は共有アカウントのクォータの範囲内で作業する必要はありません。
-
この設計は、悪意のあるアクティビティを特定のアカウントに限定し、攻撃が他のワークロードに広がるのを防ぐことで、その影響を抑えるのに役立ちます。
-
影響の範囲は問題のワークロードのみに限定されるため、変更のリスクが排除されます。IAM を使用して変更を実装できるチームを制限することもできるため、ワークロードチームと中央ネットワークチームが論理的に分離されます。
-
ネットワークの入出力の実装を分散し、論理的な制御を共通化することで (AWS Firewall Manager などのサービスを使用)、最低限の統制目標を引き続き満たしながら、特定のワークロードに合わせてネットワーク制御を調整できます。
以下のセクションでは、各サービスについて詳しく説明し、アーキテクチャ上の考慮事項について説明します。
Amazon CloudFront
このデプロイアーキテクチャでは、エッジ関数を含む Amazon CloudFront
動的オリジンと静的オリジンは同じアプリケーションアカウントにあり、 CloudFront ディストリビューションはこれらのオリジンにアカウントレベルでアクセスできます。ディストリビューションからの CloudFrontログは、各アプリケーションアカウントにローカルに保存されます。ログは Log Archive アカウントに複製できるため、コンプライアンスや規制上のニーズに対応できます。
AWS WAF
このデプロイアーキテクチャでは、AWS WAF
Firewall Manager によって適用されるルールに加えて、各アプリケーション所有者は、アプリケーションのセキュリティに関連する AWS WAF ルールをウェブ ACL に追加できます。これにより、Security Tooling アカウントの全体的な制御を維持したまま、各アプリケーションアカウントに柔軟に対応できます。
Firewall Manager のログオプションを使用して、ログを一元化し、Security Tooling アカウントの S3 バケットに送信します。各アプリケーションチームには、アプリケーションの AWS WAF ダッシュボードを確認するためのアクセス権が与えられます。Amazon などのサービスを使用してダッシュボードを設定できます QuickSight。誤検出が見つかった場合や、AWS WAF ルールに対するその他の更新が必要な場合は、Firewall Manager によってデプロイされるウェブ ACL にアプリケーションレベルの AWS WAF ルールを追加できます。ログは Log Archive アカウントに複製され、セキュリティ調査のためにアーカイブされます。
AWS Global Accelerator
AWS Global Accelerator
グローバルアクセラレータは現在、クロスアカウントオリジンをサポートしていません。そのため、オリジンエンドポイントと同じアカウントにデプロイされます。各アプリケーションアカウントにアクセラレータをデプロイし、同じアカウントに AWS Shield Advanced の保護対象リソースとして追加します。Shield 緩和は、有効なトラフィックがグローバルアクセラレータの標準アクセラレータのリスナーエンドポイントに到達することのみを許可します。
AWS Shield Advanced と AWS Route 53 ヘルスチェック
CloudFront ディストリビューションの保護に役立つように AWS Shield
Amazon Route 53 ゾーンと ACM
Amazon などのサービスを使用する場合 CloudFront
CloudFront アクセスログ、Global Accelerator フローログ、および AWS WAF ログ
このパターンでは、個々のアプリケーションアカウントの S3 バケットで CloudFront アクセスログと Global Accelerator フローログを設定します。パフォーマンスチューニングや誤検出を減らすためにログを分析したい開発者は、中央のログアーカイブへのアクセスをリクエストしなくても、これらのログに直接アクセスできます。ローカルに保存されたログは、データの保存場所や PII の難読化など、地域のコンプライアンス要件にも対応できます。
すべての AWS WAF ログは、Firewall Manager のロギングを使用して、ログアーカイブアカウントの S3 バケットに保存されます。アプリケーションチームは、Amazon などのサービスを使用して設定されたダッシュボードを使用してログを表示できます QuickSight。さらに、各アプリケーションチームは自分のアカウントからサンプリングされた AWS WAF ログにアクセスして、すばやくデバッグできます。
Log Archive アカウントにある一元化されたデータレイクにログを複製することをお勧めします。一元化されたデータレイクにログを集約することで、AWS WAF リソースとディストリビューションへのすべてのトラフィックを包括的に把握できます。これにより、セキュリティチームはグローバルなセキュリティ脅威パターンを一元的に分析して対応することができます。
設計上の考慮事項
-
このパターンでは、ネットワークとセキュリティの管理責任がアカウントオーナーと開発者に移り、開発プロセスのオーバーヘッドが増える可能性があります。
-
意思決定に矛盾が生じる可能性があります。効果的なコミュニケーション、テンプレート、トレーニングを確立して、サービスが正しく構成され、セキュリティの推奨事項に従っていることを確認する必要があります。
-
基本となるセキュリティ統制とアプリケーション固有の統制を組み合わせることには、自動化が重要であり、明確な期待が寄せられています。
-
Firewall Manager や AWS Config などのサービスを使用して、デプロイされたアーキテクチャがセキュリティのベストプラクティスに準拠していることを確認します。さらに、設定ミスを検出するように AWS CloudTrail モニタリングを設定します。
-
ログとメトリクスを一元的に集約して分析すると、複雑になる場合があります。
境界セキュリティ設定用のその他の AWS サービス
ダイナミックオリジン: Application Load Balancer
動的コンテンツ配信に Application Load Balancer
Application Load Balancer のオリジンはアプリケーションアカウントにデプロイされます。 CloudFront ディストリビューションがネットワークアカウントにある場合は、ディストリ CloudFront ビューションが Application Load Balancer オリジンにアクセスするためのクロスアカウントアクセス許可を設定する必要があります。Application Load Balancer からのログは、ログアーカイブアカウントに送信されます。
を経由せずにユーザーが Application Load Balancer に直接アクセスできないようにするには CloudFront、以下の大まかな手順を実行します。
-
Application Load Balancer CloudFront に送信するリクエストにカスタム HTTP ヘッダーを追加するように を設定し、カスタム HTTP ヘッダーを含むリクエストのみを転送するように Application Load Balancer を設定します。
-
Application Load Balancer セキュリティグループ CloudFront から の AWS マネージドプレフィックスリストを使用します。これにより、Application Load Balancer へのインバウンド HTTP/HTTPS トラフィックが、 CloudFrontのオリジン向けサーバーに属する IP アドレスのみに制限されます。
詳細については、 ドキュメントの「Application Load Balancer へのアクセスの制限」を参照してください。 CloudFront
静的オリジン: Amazon S3 および AWS Elemental MediaStore
静的コンテンツ配信 CloudFront に Amazon S3 または AWS Elemental MediaStore オリジンを使用するように を設定できます。これらのオリジンはアプリケーションアカウントにデプロイされます。 CloudFront ディストリビューションがネットワークアカウントにある場合、オリジンにアクセスするには、ネットワークアカウントの CloudFront ディストリビューションにクロスアカウントアクセス許可を設定する必要があります。
静的オリジンエンドポイントがパブリックインターネット経由でのみアクセス CloudFront され、直接アクセスされないことを確認するには、オリジンアクセスコントロール (OAC) 設定を使用できます。アクセスの制限の詳細については、 ドキュメントのAmazon S3オリジンへのアクセスの制限」および MediaStore 「オリジンへのアクセスの制限」を参照してください。 CloudFront
AWS Firewall Manager
AWS Firewall Managerは、AWS WAF、AWS Shield Advanced、Amazon VPC セキュリティグループ、AWS Network Firewall、そして、Amazon Route 53 Resolver DNS Firewall など、さまざまな保護のために、複数のアカウントとリソースにおける管理とメンテナンスのタスクを簡素化します。
Security Tooling アカウントを Firewall Manager のデフォルト管理者アカウントとして委任し、それを使用して組織アカウント全体の AWS WAF ルールと Shield Advanced 保護を一元管理します。Firewall Manager を使用すると、一般的な AWS WAF ルールを一元管理できると同時に、各アプリケーションチームがアプリケーション固有のルールをウェブ ACL に柔軟に追加できるようになります。これにより、一般的な脆弱性からの保護など、組織全体のセキュリティポリシーを実施できると同時に、アプリケーションチームはアプリケーションに固有の AWS WAF ルールを追加できます。
Firewall Manager ロギングを使用して、AWS WAF ログを Security Tooling アカウントの S3 バケットに集中させ、ログアーカイブアカウントにログを複製して、セキュリティ調査のためにアーカイブできるようにします。さらに、Firewall Manager を AWS Security Hub と統合して、設定の詳細と DDoS 通知をセキュリティハブで一元的に視覚化します。
その他の推奨事項については、このガイドの「Security Tooling アカウント」セクションの「AWS Firewall Manager」を参照してください。
AWS Security Hub
Firewall Manager とSecurity Hub 統合により、次の 4 種類の検出結果がSecurity Hub に送信されます。
-
AWS WAF rules によって適切に保護されていないリソース
-
AWS Shield Advanced によって適切に保護されていないリソース
-
DDoS 攻撃が進行中であることを示すShield アドバンスの検出結果
-
不適切に使用されているセキュリティグループ
すべての組織メンバーアカウントからのこれらの検出結果は、Security Hub 委任管理者 (Security Tooling) アカウントに集約されます。Security Hub を使用すると、セキュリティアラート (検出結果) を集計、整理、優先順位付けする 1 つの場所があります。Amazon CloudWatch Events ルールを使用して、検出結果をチケット発行システムに送信したり、悪意のある IP 範囲をブロックするなどの自動修復を作成したりできます。
その他の推奨事項については、このガイドの「Security Tooling アカウント」セクションの「AWS Security Hub」を参照してください。
Amazon GuardDuty
Amazon が提供する脅威インテリジェンスを使用して GuardDuty 、 GuardDuty 検出結果に応じてウェブ ACLs を自動的に更新
その他の推奨事項については、このガイドの Security Tooling アカウントセクションの「Amazon GuardDuty」を参照してください。
AWS Config
AWS Config は Firewall Manager の前提条件であり、ネットワークアカウントやアプリケーションアカウントを含む AWS アカウントにデプロイされます。さらに、AWS Config ルールを使用して、デプロイされたリソースがセキュリティのベストプラクティスに準拠していることを確認します。例えば、AWS Config ルールを使用して、すべての CloudFront ディストリビューションがウェブ ACL に関連付けられているかどうかを確認するか、すべての CloudFront ディストリビューションがアクセスログを S3 バケットに配信するように設定できます。
一般的な推奨事項については、このガイドの「Security Tooling アカウント」セクションの「AWS Config」を参照してください。
