SEC03-BP09 サードパーティーとリソースを安全に共有する - AWS Well-Architected フレームワーク

SEC03-BP09 サードパーティーとリソースを安全に共有する

クラウド環境のセキュリティは、組織内にとどまりません。組織が、データの一部を管理するのにサードパーティーに依存することもあります。サードパーティー管理システムの権限管理は、一時的な認証情報を使用する最小特権の原則を用いたジャストインタイムアクセスの実践に従う必要があります。サードパーティーと密に連携することにより、意図しないアクセスの影響が及ぶ範囲とリスクをともに縮小することができます。

期待される成果: アクセスキーやシークレットキーなどの長期 AWS Identity and Access Management (IAM) 認証情報は、悪用された場合にセキュリティリスクをもたらすため、使用を避けます。代わりに、IAM ロールと一時的な認証情報を使用してセキュリティ体制を強化し、長期的な認証情報を管理する運用上のオーバーヘッドを最小限に抑えます。サードパーティーにアクセス権を付与する場合は、IAM 信頼ポリシーの外部 ID として共通な一意の識別子 (UUID) を使用し、IAM ポリシーをコントロール下にあるロールにアタッチして、最小特権アクセスを確保します。外部で共有されているリソースの分析に関する規範ガイダンスについては、「SEC03-BP07 パブリックおよびクロスアカウントアクセスの分析」を参照してください。

一般的なアンチパターン:

  • 条件なしでデフォルトの IAM 信頼ポリシーを使用する。

  • 長期的 IAM 認証情報とアクセスキーを使う。

  • 外部 ID を再利用する。

このベストプラクティスを活用しない場合のリスクレベル:

実装のガイダンス

AWS Organizations 外のリソースを共有したり、アカウントにサードパーティーのアクセスを付与したりする場合があります。例えば、サードパーティーが提供する監視ソリューションが、貴社のアカウント内のリソースにアクセスする必要があるかもしれません。そのような場合、サードパーティーにとって必要な権限のみを含む IAM クロスアカウントロールを作成します。さらに、外部の ID 条件を使用して信頼ポリシーを定義します。外部 ID を使用すると、自分またはサードパーティーが各顧客、サードパーティー、またはテナンシーに対して一意の ID を生成できます。一意の ID を作成後は、自分以外の人物によってコントロールできなくなります。サードパーティーは、外部 ID を安全に、監査可能かつ再現可能な方法で顧客に関連付けるプロセスを実装する必要があります。

また、IAM Roles Anywhere を使用すると、AWS API を使用している AWS の外部のアプリケーションの IAM ロールを管理できます。

サードパーティーが貴社の環境にアクセスする必要がなくなった場合は、ロールを削除します。サードパーティーに長期的な認証情報を提供することは避けてください。他の AWS アカウント とワークロードを共有できる AWS Well-Architected Tool や、所有する AWS リソースを他のアカウントと安全に共有できる AWS Resource Access Manager など、共有をサポートする他の AWS サービスについて把握しておきます。

実装手順

  1. クロスアカウントロールを使用して外部アカウントにアクセスできるようにします。クロスアカウントロールを使用すると、顧客にサービスを提供する目的で外部アカウントやサードパーティーが保存している機密情報の量を、減らすことができます。クロスアカウントロールがあると、アクセスを管理および監査する能力を維持しながら、AWS パートナーまたは組織内の他のアカウントなど、アカウントの AWS リソースへのアクセスをサードパーティーに安全に付与できます。サードパーティーが、ハイブリッドインフラストラクチャからサービスを提供したり、またはオフサイトロケーションにデータをプルする場合があります。IAM Roles Anywhere を使用すると、サードパーティーのワークロードは AWS ワークロードと安全に通信でき、長期的な認証情報の必要性も削減できます。

    外部アカウントアクセスを提供するために、ユーザーと関連付けられた長期的認証情報、またはアクセスキーを使用しないでください。かわりに、クロスアカウントロールを使ってクロスアカウントアクセスを提供します。

  2. デューデリジェンスを実施して、サードパーティーの SaaS プロバイダーの安全なアクセスを確保します。サードパーティーの SaaS プロバイダーとリソースを共有する場合は、そのプロバイダーが AWS リソースにアクセスする際に安全で責任あるアプローチを取っていることを確認するために、徹底的なデューデリジェンスを実施します。責任共有モデルを評価し、どのようなセキュリティ対策が提供され、何が自社の責任に該当するかを理解します。SaaS プロバイダーについて、外部 ID の使用や最小特権アクセス原則など、リソースにアクセスするために安全で監査可能なプロセスがあることを確認します。外部 ID を使用すると、混乱した代理問題 に対処できます。

    サードパーティーの SaaS プロバイダーへのアクセスを許可する場合は、安全なアクセスと最小特権の原則の遵守を確保するため、セキュリティ対策を実施します。これには、外部 ID、共通の一意の識別子 (UUID)、およびアクセスを必要なもののみに厳格に制限する IAM 信頼ポリシーの使用が含まれます。SaaS プロバイダーと密接に連携して、安全なアクセスメカニズムを確立し、AWS リソースへのアクセスを定期的に見直し、監査を実施してセキュリティ要件へのコンプライアンスを確保します。

  3. 顧客が提供する長期的認証情報を廃止します。長期的認証情報の使用を廃止して、クロスアカウントロールまたは IAM Roles Anywhere を使用します。長期的認証情報を使用する必要がある場合、ロールベースのアクセスに移行する計画を立ててください。キー管理の詳細については、「ID 管理」を参照してください。また、AWS アカウントチームおよびサードパーティーと連携して、リスク軽減ランブックを確立します。セキュリティインシデントの潜在的影響への対応とその軽減に関する規範的ガイダンスについては、「インシデント対応」を参照してください。

  4. セットアップに規範的ガイダンスがある、または規範的ガイダンスが自動化されていることを確認します。外部 ID はシークレットとして取り扱われませんが、外部 ID は電話番号、氏名、アカウント ID など推測しやすい値であってはなりません。外部 ID を読み取り専用にすることで、設定のなりすましを目的として外部 ID が変更されないようにします。

    ご自身またはサードパーティーが外部 ID を生成できます。ID 生成に責任がある担当者を決定するプロセスを定義します。外部 ID を作成するエンティティにかかわらず、サードパーティーは顧客間で一貫した一意性とフォーマットを適用します。

    アカウントのクロスアカウントアクセス向けに作成されたポリシーは、最小特権の原則に従う必要があります。サードパーティーは、ロールポリシードキュメント、または AWS CloudFormation テンプレートまたは同等のものを使用する自動化されたセットアップメカニズムを提供する必要があります。これにより、手動ポリシー作成に関連してエラーが発生する可能性が減り、監査可能証跡を提供します。AWS CloudFormation テンプレートを使用してクロスアカウントロールを作成する方法の詳細については、「Cross-Account Roles」を参照してください。

    サードパーティーは、自動化され、監査可能なセットアップメカニズムを提供する必要があります。ただし、必要なアクセスを概説したロールポリシードキュメントを使用することにより、ロールのセットアップを自動化する必要があります。AWS CloudFormation テンプレートまたは同等のものを使用して、監査業務の一環として、ドリフト検出で変化をモニタリングする必要があります。

  5. 変更点を説明します。アカウント構成、サードパーティーのニーズ、または提供されるサービスオファリングは変わる可能性があります。変更と障害を予想し、それに応じて適切な人材、プロセス、テクノロジーを計画する必要があります。定期的に提供するアクセスのレベルを監査し、予想外の変更があった場合にアラートを出す検出方法を実装します。外部 ID のロールとデータストアをモニタリングおよび監査します。予想外の変更やアクセスパターンの結果、サードパーティーのアクセスを一時的または恒久的に取り消す準備をしておく必要があります。また、実行にかかる時間、関与する人材、コスト、および他のリソースの影響など、取り消し操作の影響を測定します。

    検知方法に関する規範的なガイダンスについては、「検知」内のベストプラクティスを参照してください。

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: