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

セキュリティ設定を定期的に監査し、現在のビジネスのニーズに対応していることを確認する必要があります。監査では、不要な IAM ユーザー、ロール、グループ、およびポリシーを削除し、ユーザーとソフトウェアに対して必要なアクセス権限だけを与えるようにすることができます。

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

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

次の状況では、セキュリティ設定を監査する必要があります。

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

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

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

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

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

監査のガイドライン

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

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

• 推測しない。セキュリティ設定のある面 (例: 特定のポリシーやロールの存在の背後にある根拠) が良くわからない場合、満足するまでビジネスニーズを調査します。

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

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

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

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

2. アカウントのアクセスキーを保持する必要がある場合は、定期的に更新します。

IAM ユーザーの確認

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

1. ユーザーを一覧表示し、非アクティブのユーザーを削除します。

2. 必要のないユーザーをグループから削除します。

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

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

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

5. 定期的に (許可されていない人と共有する場合は臨時に) ユーザーのセキュリティ認証情報をローテーション (変更) します。詳細については、「IAM ユーザーガイド」の「IAM ユーザーのパスワードの管理」および「IAM ユーザーのアクセスキーの管理」を参照してください。

IAM グループの確認

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

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

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

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

IAM ロールの確認

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

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

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

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

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

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

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

2. SAML プロバイダごとの AWS メタデータドキュメントをダウンロードして確認し、ドキュメントが現在のビジネスのニーズを反映していることを確かめます。または、信頼を確立しようとしている SAML IdP から最新のメタデータドキュメントを取得して IAM のプロバイダを更新します。

モバイルアプリの確認

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

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

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

   モバイルアプリが Amazon、Facebook、Google、またはその他の OIDC 対応 ID プロバイダーへのログイン情報を使用する認証をサポートしない場合は、アプリケーションに一時的なセキュリティ認証情報を配信できるプロキシサーバーを作成できます。

Amazon EC2 セキュリティ設定の確認

各 AWS リージョンについて、次のステップに従います。

1. 使用していない、または組織外の人に知られている可能性がある Amazon EC2 キーペアを削除します。

2. Amazon EC2 セキュリティグループを確認します。

   • ニーズを満たさなくなったセキュリティグループを削除します。

   • ニーズを満たさなくなったセキュリティグループからルールを削除します。そのルールでポート、プロトコル、IP アドレス範囲が許可されていた理由を確認しておいてください。

3. ビジネスニーズに対応しない場合や、承認されていない目的のために組織外のユーザーによって開始された可能性がある場合、インスタンスを終了します。ロールを使用してインスタンスを起動する場合、そのインスタンスで実行するアプリケーションは、そのロールによって付与されたアクセス権限を使用して AWS リソースにアクセスできることに注意してください。

4. ビジネスニーズに対応しない場合や、組織外のユーザーによって作成された可能性がある場合、スポットインスタンスリクエストをキャンセルします。

5. Auto Scaling グループと設定を確認します。ニーズを満たさない場合や、組織外のユーザーによって設定された可能性がある場合、シャットダウンします。

他のサービスの AWS ポリシーの確認

リソースベースのポリシーを使用するか、他のセキュリティメカニズムをサポートするサービスのアクセス権限を確認します。いずれのケースも、最新のビジネスニーズを持つユーザーとロールのみがサービスのリソースにアクセスできること、またリソースに付与されたアクセス権限がビジネスニーズを満たすのに必要最低限の数であることを確認してください。

• Amazon S3 バケットポリシーと ACL を確認します。

• Amazon SQS キューポリシーを確認します。

• Amazon SNS トピックポリシーを確認します。

• AWS OpsWorks 権限を確認します。

• AWS KMS キーポリシーを確認します。

AWS アカウントのアクティビティの監視

AWS アクティビティのモニタリングでは、以下のガイドラインに従います。

• 各アカウントの AWS CloudTrail をオンにし、サポートされている各リージョンでそれを使用します。

• 定期的に CloudTrail ログファイルを確認します。(CloudTrail には、ログファイルの読み取りと分析のためのツールを提供するいくつかのパートナーが存在します)。

• Amazon S3 バケットロギングを有効化し、各バケットに対して作成されたリクエストを監視します。

• アカウントの不正使用があったと考えられる場合は、発行された一時的認証情報には特に注意を払ってください。不明な一時的認証情報が発行された場合は、その権限を無効にします。

• 各アカウントに対する請求アラートを有効にし、通常の使用範囲を超えたら通知されるように料金のしきい値を設定します。

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

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

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

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

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

• ユーザーの許可は、該当するすべてのポリシー、つまり 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/*) を示すために使用します。そのクラスまたはパスのすべてのリソースへのアクセスを許可する際に便利です。

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

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

詳細はこちら

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

• 「IAM ユーザーガイド」の「IAM users and Groups」(IAM ユーザーおよびユーザーグループ)。

• IAM ユーザーガイドの Permissions and Policies

• IAM ユーザーガイドの IAM ロール (委任とフェデレーション)。

• Using IAM Policy Simulator の使用ガイドの IAM Policy Simulator。

Amazon EC2 セキュリティの詳細については、以下を参照してください。

• Linux インスタンス用 Amazon EC2 ユーザーガイドのネットワークおよびセキュリティ

• AWS セキュリティブログの Demystifying EC2 Resource-Level Permissions。

監査用の AWS 監視およびレポートツールを使い始めるには、AWSArchitecture Centerの「セキュリティ、アイデンティティ、コンプライアンスのベストプラクティス」を参照してください。