AWS セキュリティ監査のガイドライン - AWS Identity and Access Management
セキュリティ監査を実行するタイミング監査のガイドラインAWS アカウントの認証情報の確認IAM ユーザーの確認IAM グループの確認IAM ロールの確認SAML および OpenID Connect (OIDC) 用 IAM プロバイダの確認モバイルアプリの確認IAM ポリシーを確認するためのヒント

AWS セキュリティ監査のガイドライン

セキュリティ設定を定期的に監査し、現在のビジネスニーズに対応していることを確認します。監査により、不要な IAM ユーザー、ロール、グループ、ポリシーを削除し、ユーザーとソフトウェアに対する過剰なアクセス許可がないことを確認する機会が得られます。

以下では、セキュリティのベストプラクティスを実践するために、AWS リソースを体系的に確認し、モニタリングするためのガイドラインを示します。

ヒント

AWS Security Hub を使用して、セキュリティのベストプラクティスに関連する IAM の使用状況をモニタリングできます。Security Hub は、セキュリティコントロールを使用してリソース設定とセキュリティ標準を評価し、お客様がさまざまなコンプライアンスフレームワークに準拠できるようサポートします。Security Hub を使用して IAM リソースを評価する方法の詳細については、「AWS Security Hub ユーザーガイド」の「AWS アイデンティティおよびアクセス管理コントロール」を参照してください。

セキュリティ監査を実行するタイミング

次の状況で、セキュリティ設定を監査します。

  • 定期的な監査。セキュリティのベストプラクティスとして、このドキュメントで説明されている手順を定期的に実行します。

  • 従業員が退職するなど、組織に変更があった場合。

  • 1 つ以上の個別の AWS サービスの使用を停止したことで、アカウントのユーザーにとって不要になったアクセス許可を削除したことを検証する場合。

  • Amazon EC2 インスタンス上のアプリケーション、AWS OpsWorks スタック、AWS CloudFormation テンプレートなど、アカウントでソフトウェアの追加または削除を行った場合。

  • 権限のないユーザーがアカウントにアクセスした疑いがある場合。

監査のガイドライン

アカウントのセキュリティ設定を確認する際は、以下のガイドラインに従います。

  • 徹底して行う。ほとんど使用しないものを含め、セキュリティ設定のあらゆる面について調べます。

  • 推測しない。セキュリティ設定の一部 (例: 特定のポリシーやロールの存在の背後にある根拠) が不明な場合は、潜在的リスクを把握するまでビジネスニーズを調査します。

  • 作業を単純にする。監査 (および管理) を容易にするために、IAM グループ、IAM ロール、一貫した命名スキーム、単純なポリシーを使用します。

AWS アカウントの認証情報の確認

AWS アカウント認証情報を監査するときは、次の手順に従います。

  1. 使用していないルートユーザーのアクセスキーがある場合は、削除できます。AWS での日常的な作業には、ルートアクセスキーを使用するのではなく、AWS IAM アイデンティティセンターのユーザー などの一時的な認証情報を持つユーザーを使用することを強くお勧めします。

  2. アカウントのアクセスキーが必要な場合は、必要に応じて更新してください。

IAM ユーザーの確認

既存の IAM ユーザーを監査するときは、以下の手順に従います。

  1. ユーザーを一覧表示し、不要なユーザーを削除します。

  2. アクセスを必要としないグループからユーザーを削除します。

  3. ユーザーが所属するグループにアタッチされたポリシーを確認します。「IAM ポリシーを確認するためのヒント」を参照してください。

  4. ユーザーが必要としない場合や公開された可能性がある場合、セキュリティ認証情報を削除します。例えば、アプリケーションに使用される IAM ユーザーはパスワードを必要としません (パスワードは AWS ウェブサイトへのサインインにのみ必要です)。同様に、ユーザーがアクセスキーを使用しない場合、ユーザーはそのキーを持つ理由がありません。詳細については、「IAM ユーザーのパスワードの管理」および「IAM ユーザーのアクセスキーの管理」を参照してください。

    アカウント内のすべての IAM ユーザーと、ユーザーの各種認証情報 (パスワード、アクセスキー、MFA デバイスなど) のステータスが示された認証情報レポートを生成し、ダウンロードできます。パスワードやアクセスキーでは、パスワードやアクセスキーを最近使用した日時が、認証情報レポートに表示されます。最近使用していない認証情報をアカウントから削除することを検討してください。(緊急アクセスユーザーを削除しないでください)。詳細については、「AWS アカウントの認証情報レポートの取得」を参照してください。

  5. 長期的な認証情報を必要とするユースケースのために、必要に応じてパスワードとアクセスキーを更新してください。詳細については、「IAM ユーザーのパスワードの管理」および「IAM ユーザーのアクセスキーの管理」を参照してください。

  6. ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。可能であれば、IAM ユーザーから IAM Identity Center のユーザーなどのフェデレーションユーザーに移行してください。アプリケーションに必要な最小限の IAM ユーザー数を保持してください。

IAM グループの確認

IAM グループを監査するときは、次の手順に従います。

  1. グループを一覧表示し、使用していないグループを削除します。

  2. 各グループのユーザーを確認し、属していないユーザーを削除します。

  3. グループにアタッチされるポリシーを確認します。「IAM ポリシーを確認するためのヒント」を参照してください。

IAM ロールの確認

IAM ロールを監査するときは、次の手順に従います。

  1. ロールを一覧表示し、使用していないロールを削除します。

  2. ロールの信頼ポリシーを確認します。プリンシパルが誰かを把握し、なぜアカウントまたはユーザーがロールを引き受けることができるようにする必要があるのかを理解しておいてください。

  3. ロールを引き受けるユーザーすべてに適切なアクセス許可を付与できるよう、アクセスポリシーを確認します。IAM ポリシーを確認するためのヒント を参照してください。

SAML および OpenID Connect (OIDC) 用 IAM プロバイダの確認

SAML または OIDC ID プロバイダー (IdP) との信頼を確立するために IAM エンティティを作成した場合は、以下の手順に従います。

  1. 使用していないプロバイダーを削除します。

  2. SAML IdP ごとの AWS メタデータドキュメントをダウンロードして確認し、ドキュメントが現在のビジネスニーズを反映していることを確認します。

  3. SAML IdP から最新のメタデータドキュメントを取得して、IAM のプロバイダーを更新します。

モバイルアプリの確認

AWS にリクエストを送信するモバイルアプリを作成する場合、以下の手順に従います。

  1. 暗号化ストレージ内であっても、モバイルアプリケーションに埋め込みアクセスキーが含まれていないことを確認します。

  2. その目的のために設計されている API を使用して、アプリケーションの一時的な認証情報を取得します。

注記

Amazon Cognito を使用して、アプリでユーザー ID を管理することをお勧めします。このサービスでは、Login with Amazon、Facebook、Google、または OpenID Connect (OIDC) に対応している任意の ID プロバイダを使用してユーザーを認証できます。詳細については、「Amazon Cognito デベロッパーガイド」の「Amazon Cognito ID プール」を参照してください。

IAM ポリシーを確認するためのヒント

ポリシーは強力かつ微妙であるため、各ポリシーによって付与されるアクセス許可を確認して理解することが重要です。ポリシーを確認するときは、以下のガイドラインを使用します。

  • 個々のユーザーにではなくグループにポリシーをアタッチします。個々のユーザーにポリシーがある場合、なぜそのユーザーはポリシーを必要としているのかを理解しておいてください。

  • IAM ユーザー、グループ、ロールに必要なアクセス許可が付与され、追加のアクセス許可が付与されていないことを確認します。

  • IAM ポリシーシミュレーターを使用して、ユーザーまたはグループにアタッチされたポリシーをテストします。

  • ユーザーのアクセス許可は、該当するすべてのポリシー、つまり (ユーザー、グループまたはロールの) アイデンティティベースのポリシーと、(Amazon S3 バケット、Amazon SQS キュー、Amazon SNS トピック、および AWS KMS キーなどのリソースに対する) リソースベースのポリシーの結果であることに注意してください。ユーザーに適用されるすべてのポリシーを調べ、個々のユーザーに付与されるアクセス許可一式を理解することが重要です。

  • IAM ユーザー、グループ、ロール、またはポリシーの作成とそのプリンシパルエンティティへのポリシーの付与をユーザーに許可すると、実質的に、お客様のアカウント内のすべてのリソースに対するすべてのアクセス権限をそのユーザーに付与することになることに注意してください。ポリシーの作成とユーザー、グループ、またはロールへのポリシーのアタッチを許可されたユーザーは、すべてのアクセス許可をユーザー自身に付与することができます。通常、信頼できないユーザーまたはロールには、アカウントのリソースへのフルアクセスを含む IAM のアクセス許可を付与しないでください。セキュリティ監査を実行する際は、信頼できるアイデンティティに次の IAM アクセス許可が付与されていることを確認してください。

    • iam:PutGroupPolicy

    • iam:PutRolePolicy

    • iam:PutUserPolicy

    • iam:CreatePolicy

    • iam:CreatePolicyVersion

    • iam:AttachGroupPolicy

    • iam:AttachRolePolicy

    • iam:AttachUserPolicy

  • 使用しないサービスにはポリシーがアクセス許可を付与しないようにします。たとえば、AWS 管理ポリシーを使用する場合は、アカウントで使用されている AWS 管理ポリシーが、実際に使用するサービス用であることを確認します。アカウントで使用されている AWS 管理ポリシーを確認するには、IAM GetAccountAuthorizationDetails API (AWS CLI コマンド: aws iam get-account-authorization-details) を使用します。

  • ポリシーが、Amazon EC2 インスタンスを起動するアクセス許可をユーザーに付与する場合、iam:PassRole アクションの実行も許可する可能性があります。この場合、ユーザーが Amazon EC2 インスタンスに渡すことができるロールが明示的に一覧表示されます。

  • * を含む Action 要素または Resource 要素の値を検証します。可能な場合は、ユーザーが必要とする個別のアクションおよびリソースへの Allow アクセス許可を付与します。ただし、* をポリシーで使用するのが適切であることの理由は、以下のとおりです。

    • ポリシーは、管理レベルのアクセス許可を付与するように設計されています。

    • ワイルドカード文字は、便宜上の理由から、類似するアクションのセット (例: Describe*) に使用します。この方法で全アクションのリストを参照すれば便利です。

    • ワイルドカード文字は、リソースのクラスまたはリソースパス (例: arn:aws:iam::account-id:users/division_abc/*) を表示するために使用します。これは、そのクラスまたはパスのすべてのリソースへのアクセス許可を付与する際に便利です。

    • サービスアクションは、リソースレベルのアクセス許可をサポートしないため、リソースの唯一の選択肢は * です。

  • ポリシー名を調べて、ポリシーの機能を反映していることを確認します。たとえば、ポリシーに「読み取り専用」を含む名前が付いていても、そのポリシーは実際には書き込みや変更を許可することもあります。

セキュリティ監査の計画の詳細については、AWS Architecture Centerの「セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス」を参照してください。