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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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