ID とアクセスを管理するためのセキュリティコントロールの推奨事項 - AWS 規範ガイダンス

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

ID とアクセスを管理するためのセキュリティコントロールの推奨事項

ID は で作成することも AWS、外部 ID ソースに接続することもできます。 AWS Identity and Access Management (IAM) ポリシーを使用して、ユーザーが AWS リソースと統合アプリケーションにアクセスまたは管理するために必要なアクセス許可を付与します。効果的な ID とアクセスの管理は、適切な人材とマシンが適切な条件下で適切なリソースにアクセスできることを検証するのに役立ちます。 AWS Well-Architected フレームワークは、ID とそのアクセス許可を管理するためのベストプラクティスを提供します。ベストプラクティスの例としては、一元化された ID プロバイダーへの依存や、多要素認証 (MFA) などの強力なサインインメカニズムの使用などがあります。このセクションのセキュリティコントロールは、これらのベストプラクティスの実装に役立ちます。

ルートユーザーアクティビティの通知のモニタリングと設定

を初めて作成するときは AWS アカウント、ルートユーザーと呼ばれる単一のサインインアイデンティティから始めます。デフォルトでは、ルートユーザーはアカウント内のすべての AWS のサービス およびリソースへのフルアクセスが許可されます。ルートユーザーを厳密に制御およびモニタリングし、ルートユーザーの認証情報を必要とするタスクにのみ使用する必要があります。

詳細については、以下のリソースを参照してください。

ルートユーザーのアクセスキーは作成しないでください

ルートユーザーは、最も権限のある AWS アカウントのユーザーです。ルートユーザーへのプログラムによるアクセスを無効にすると、ユーザー認証情報が誤って公開され、クラウド環境が侵害されるリスクを軽減できます。および リソースにアクセス AWS アカウント するための一時的な認証情報として IAM ロールを作成して使用することをお勧めします。

詳細については、以下のリソースを参照してください。

ルートユーザーの MFA を有効にする

AWS アカウント ルートユーザーと IAM ユーザーに対して複数の多要素認証 (MFA) デバイスを有効にすることをお勧めします。これにより、 のセキュリティバー AWS アカウント が引き上げられ、アクセス管理が簡素化されます。ルートユーザーは特権アクションを実行できる権限の高いユーザーであるため、ルートユーザーに MFA を要求することが重要です。時間ベースのワンタイムパスワード (TOTP) アルゴリズム、FIDO ハードウェアセキュリティキー、または仮想認証アプリケーションに基づいて数値コードを生成するハードウェア MFA デバイスを使用できます。

2024 年、MFA は のルートユーザーにアクセスする必要があります AWS アカウント。詳細については、 AWS セキュリティブログの「Secure by Design: AWS to enhance MFA requirements in 2024」を参照してください。このセキュリティプラクティスを拡張し、 AWS 環境内のすべてのユーザータイプに MFA を要求することを強くお勧めします。

可能であれば、ルートユーザーにハードウェア MFA デバイスを使用することをお勧めします。仮想 MFA はハードウェア MFA デバイスと同じレベルのセキュリティを提供しない可能性があります。仮想 MFA は、ハードウェア購入の承認または配信を待っている間に使用できます。

で何百ものアカウントを管理する状況では AWS Organizations、組織のリスク許容度によっては、組織単位 (OU) 内の各アカウントのルートユーザーにハードウェアベースの MFA を使用することはスケーラブルではない場合があります。この場合、OU 管理アカウントとして機能する OU 内の 1 つのアカウントを選択し、その OU 内の他のアカウントのルートユーザーを無効にすることができます。デフォルトでは、OU 管理アカウントは他のアカウントにアクセスできません。クロスアカウントアクセスを事前に設定することで、緊急時に OU 管理アカウントから他のアカウントにアクセスできます。クロスアカウントアクセスを設定するには、メンバーアカウントに IAM ロールを作成し、OU 管理アカウントのルートユーザーのみがこのロールを引き受けられるようにポリシーを定義します。詳細については、IAM ドキュメントの「チュートリアル: IAM ロール AWS アカウント を使用した 間のアクセスの委任」を参照してください。

ルートユーザー認証情報用に複数の MFA デバイスを有効にすることをお勧めします。任意の組み合わせで最大 8 台の MFA デバイスを登録できます。

詳細については、以下のリソースを参照してください。

IAM のセキュリティのベストプラクティスに従う

IAM ドキュメントには、 AWS アカウント および リソースの保護に役立つベストプラクティスのリストが含まれています。これには、最小特権の原則に従ってアクセスとアクセス許可を設定するための推奨事項が含まれています。IAM セキュリティのベストプラクティスの例としては、ID フェデレーションの設定、MFA の要求、一時的な認証情報の使用などがあります。

詳細については、以下のリソースを参照してください。

最小特権のアクセス許可を付与する

最小特権とは、タスクの実行に必要なアクセス許可のみを付与する手法です。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。

属性ベースのアクセスコントロール (ABAC) は、タグなどの属性に基づいてアクセス許可を定義する認可戦略です。グループ、アイデンティティ、リソース属性を使用して、個々のユーザーのアクセス許可を定義するのではなく、大規模なアクセス許可を動的に定義できます。例えば、ABAC を使用して、開発者グループがプロジェクトに関連付けられた特定のタグを持つリソースにのみアクセスすることを許可できます。

詳細については、以下のリソースを参照してください。

ワークロードレベルでアクセス許可ガードレールを定義する

ワークロードレベルでガードレールを柔軟に定義できるため、マルチアカウント戦略を使用するのがベストプラクティスです。 AWS セキュリティリファレンスアーキテクチャは、アカウントを構築する方法に関する規範的なガイダンスを提供します。これらのアカウントは で組織として管理されAWS Organizations、アカウントは組織単位 (OUs) にグループ化されます。

AWS のサービスなどの AWS Control Towerは、組織全体のコントロールを一元管理するのに役立ちます。組織内のアカウントまたは OU ごとに明確な目的を定義し、その目的に従ってコントロールを適用することをお勧めします。 は、リソースの管理とコンプライアンスのモニタリングに役立つ予防、検出、プロアクティブコントロール AWS Control Tower を実装します。予防コントロールは、イベントの発生を防ぐように設計されています。検出コントロールは、イベントの発生後に検出、ログ記録、アラートを行うように設計されています。プロアクティブコントロールは、プロビジョニング前にリソースをスキャンして、非準拠のリソースのデプロイを防ぐように設計されています。

詳細については、以下のリソースを参照してください。

IAM アクセスキーを定期的にローテーションする

長期的な認証情報を必要とするユースケースでは、アクセスキーを更新することをお勧めします。アクセスキーは 90 日以内にローテーションすることをお勧めします。アクセスキーをローテーションすると、侵害されたアカウントまたは終了したアカウントに関連付けられているアクセスキーが使用されるリスクが軽減されます。また、紛失、侵害、盗難にあった可能性のある古いキーを使用することで、アクセスを防止します。アクセスキーをローテーションした後は、必ずアプリケーションを更新してください。

詳細については、以下のリソースを参照してください。

外部エンティティと共有されているリソースを特定する

外部エンティティとは、別のユーザー、ルートユーザー、IAM ユーザーまたはロール、フェデレーティッドユーザー AWS アカウント、、匿名 (または認証されていない) ユーザーなど、 AWS 組織外のリソース、アプリケーション、サービス AWS のサービス、またはユーザーです。IAM Access Analyzer を使用して、外部エンティティと共有されている Amazon Simple Storage Service (Amazon S3) バケットや IAM ロールなど、組織やアカウント内のリソースを特定することは、セキュリティのベストプラクティスです。これにより、セキュリティ上のリスクであるリソースやデータへの意図しないアクセスを特定できます。

詳細については、以下のリソースを参照してください。