AWS Identity and Access Management
ユーザーガイド

サービスの最終アクセス時間データを使用するためのシナリオ例

サービスの最終アクセス時間データを使用して、IAM エンティティまたは AWS Organizations エンティティに付与するアクセス許可に関する決定を行うことができます。詳細については、「サービスの最終アクセス時間データを使用したアクセス許可の調整」を参照してください。

注記

IAM または AWS Organizations のエンティティあるいはポリシーに関するアクセスデータを表示する前に、データのレポート期間、レポート対象のエンティティ、評価対象のポリシータイプをご確認ください。詳細については、「主要事項」を参照してください。

お客様は、管理者として、会社に適したアクセシビリティと最小限のアクセス権限のバランスを取る必要があります。

データを使用して IAM グループのアクセス許可を制限する

サービスの最終アクセス時間データを使用して、ユーザーが必要とするサービスのみを含むように IAM グループのアクセス許可を変更することができます。この方法は、サービスレベルで最小限の権限を付与する上で重要なステップです。

たとえば、Paulo Santos は、サンプル株式会社の AWS ユーザーのアクセス許可を定義する責任を担う管理者です。この企業は、AWS を使用し始めたばかりで、ソフトウェア開発チームは、使用する AWS サービスの内容をまだ定義していません。Paulo は必要なサービスにのみアクセス可能なアクセス許可をチームに付与しようと考えていますが、サービスが定義されていないため、パワーユーザーのアクセス許可を一時的に付与します。ここで、サービスの最終アクセス時間データを使用して、グループのアクセス許可を最小限に変更します。

Paulo は、次の JSON テキストを使用して、ExampleDevelopment という名前の管理ポリシーを作成します。次に、Development という名前のグループにそのポリシーをアタッチし、開発者全員をグループに追加します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessToAllServicesExceptPeopleManagement", "Effect": "Allow", "NotAction": [ "iam:*", "organizations:*" ], "Resource": "*" }, { "Sid": "RequiredIamAndOrgsActions", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:DeleteServiceLinkedRole", "iam:ListRoles", "organizations:DescribeOrganization" ], "Resource": "*" } ] }

90 日後、Paulo は AWS マネジメントコンソール を使用して、Development グループのサービスの最終アクセス時間データを表示します。グループメンバーがアクセスしたサービスのリストを表示します。先週、このユーザーがアクセスしたサービスは、AWS CloudTrail、Amazon CloudWatch Logs、Amazon EC2、AWS KMS、Amazon S3 の 5 つであることが分かりました。AWS の使用開始時は他のいくつかのサービスにもアクセスしていましたが、それ以降はアクセスしていません。

Paulo は、これらの 5 つのサービスと、IAM および 組織 の必要なアクションのみ含まれるようにポリシーのアクセス許可を変更することにしました。また、次の JSON テキストを使用して、ExampleDevelopment ポリシーを編集します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "FullAccessToListedServices", "Effect": "Allow", "Action": [ "s3:*", "kms:*", "cloudtrail:*", "logs:*", "ec2:*" ], "Resource": "*" }, { "Sid": "RequiredIamAndOrgsActions", "Effect": "Allow", "Action": [ "iam:CreateServiceLinkedRole", "iam:DeleteServiceLinkedRole", "iam:ListRoles", "organizations:DescribeOrganization" ], "Resource": "*" } ] }

アクセス許可をさらに制限するために、Paulo は、AWS CloudTrail の [イベント履歴] でアカウントのイベントを表示します。そこでは、詳細なイベント情報を表示して、開発者が必要とするアクションとリソースのみが含まれるように、ポリシーのアクセス許可を制限することができます。詳細については、AWS CloudTrail ユーザーガイドの「CloudTrail コンソールのCloudTrail イベント」を参照してください。

データを使用して IAM ユーザーのアクセス許可を制限する

サービスの最終アクセス時間データを使用して、各 IAM ユーザーのアクセス許可を制限することができます。

たとえば、Martha Rivera は、アクセス許可を管理する IT 管理者であり、AWS アクセス許可を組織内のユーザーに過剰に付与しないように管理する必要があります。定期的なセキュリティチェックの一部として、彼女はすべての IAM ユーザーのアクセス許可を見直します。これらのユーザーの中には、以前にセキュリティエンジニアのロールを担っていた、Nikhil Jayashankar という名前のアプリケーション開発者がいます。ジョブ要件が変更され、Nikhil は現在 app-dev グループと security-team グループの両方のメンバーです。新しいジョブで app-dev グループに配属されたことで、Amazon EC2、Amazon EBS、Auto Scaling、Route 53、Elastic Transcoder などの複数のサービスへのアクセス許可が付与されています。以前のジョブの security-team では、IAM および CloudTrail へのアクセス許可が付与されています。

管理者である Martha が IAM コンソールにサインインしてユーザーを選択後、nikhilj という名前を選択し、[アクセスアドバイザー] タブを選択します。

Martha は [最終アクセス時間] 列を確認し、Nikhil が最近 IAM、CloudTrail、Route 53、Amazon Elastic Transcoder など、多数の AWS サービスにアクセスしていないことに気づきました。Martha は、Nikhil が社内のセキュリティチームのメンバーではなくなったため、IAM と CloudTrail にアクセスするビジネス上のニーズがなくなったことを確認します。

これで、Martha はサービスの最終アクセス時間データに関する作業を行う準備ができました。ただし、前の例のグループとは異なり、nikhilj のような IAM ユーザーには、複数のポリシーが適用され、複数のグループのメンバーになることがあります。Martha は、nikhilj やその他のグループメンバーのアクセスを誤って中断しないように慎重に進める必要があります。彼女は、Nikhil に付与する必要のあるアクセス権だけでなく、これらのアクセス許可が付与されている背景を確認する必要があります。

Martha は、[アクセス許可] タブを選択します。ここでは、nikhilj に直接アタッチされているポリシーと、グループからアタッチされているポリシーを確認します。各ポリシーを展開して、ポリシーの概要を確認し、Nikhil が現在使用していないサービスへのアクセスを許可しているポリシーを確認します。

  • IAM – IAMFullAccess AWS 管理ポリシーは、nikhilj に直接アタッチされているほか、security-team グループにもアタッチされています。

  • CloudTrail – AWS 管理ポリシー AWSCloudTrailReadOnlyAccess は、security-team グループにアタッチされています。

  • Route 53 – App-Dev-Route53 カスタマー管理ポリシーは、app-dev グループにアタッチされています。

  • Elastic Transcoder – App-Dev-ElasticTranscoder カスタマー管理ポリシーは、app-dev グループにアタッチされています。

Martha は、nikhilj に直接アタッチされている AWS 管理ポリシー IAMFullAccess を削除することにしました。また、Nikhil の security-team グループのメンバーシップも削除します。これらの 2 つのアクションによって、IAM および CloudTrail への不要なアクセスが削除されます。

Route 53 および Elastic Transcoder への Nikhil のアクセス許可は、app-dev グループによって付与されています。Nikhil は、これらのサービスを使用していませんが、グループの他のメンバーは使用する可能性があります。Martha は、app-dev グループのサービスの最終アクセスデータを確認し、複数のメンバーは最近 Route 53 にアクセスしましたが、昨年 Elastic Transcoder にアクセスしたグループメンバーはいなかったことが分かりました。彼女は、カスタマー管理ポリシー App-Dev-ElasticTranscoder をグループから削除します。

次に、カスタマー管理ポリシー App-Dev-ElasticTranscoder のサービスの最終アクセス時間データを確認します。このポリシーは、その他の IAM アイデンティティのいずれにもアタッチされていないことが分かりました。彼女は社内で調査を行い、このポリシーは今後不要であることを確認して削除しました。

IAM リソースを削除する前にデータを使用する

IAM リソースを削除する前に、サービスの最終アクセス時間データを使用して、最後にリソースを使用してから一定の時間が経過したことを確認できます。これは、ユーザー、グループ、ロール、ポリシーに適用されます。これらのアクションの詳細については、以下のトピックを参照してください。

IAM ポリシーを編集する前にデータを使用する

IAM アイデンティティ (ユーザー、グループ、ロール)、またはそのリソースに影響するポリシーを編集する前の IAM ポリシーのサービスの最終アクセス時間データを確認できます。使用しているユーザーのアクセスを削除しないように、このステップは重要です。

たとえば、Arnav Desai は、サンプル株式会社の開発者兼 AWS 管理者です。チームが AWS の使用を開始した際、Arnav は、IAM と 組織 を除くすべてのサービスへのフルアクセスを許可するパワーユーザーのアクセス権をすべての開発者に付与しました。最小限の権限の付与の最初のステップとして、Arnav は AWS CLI を使用して、アカウントの管理ポリシーを確認しようとしています。

そのために、Arnav はまず、アイデンティティにアタッチされているアカウントのカスタマー管理ポリシーを表示します。次のコマンドを使用します。

aws iam list-policies --scope Local --only-attached --policy-usage-filter PermissionsPolicy

レスポンスから、各ポリシーの ARN をキャプチャします。Arnav は次に、次のコマンドを使用して、各ポリシーのサービスの最終アクセス時間データのレポートを生成します。

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

レスポンスから、JobId フィールドから生成したレポートの ID をキャプチャします。続いて、Arnav は、JobStatus フィールドより COMPLETED または FAILED の値が返るまで、次のコマンドをポーリングします。ジョブが失敗した場合は、そのエラーをキャプチャします。

aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

ジョブが COMPLETED のステータスになったら、Arnav は JSON 形式の ServicesLastAccessed 配列の内容を解析します。

"ServicesLastAccessed": [ { "TotalAuthenticatedEntities": 1, "LastAuthenticated": 2018-11-01T21:24:33.222Z, "ServiceNamespace": "dynamodb", "LastAuthenticatedEntity": "arn:aws:iam::123456789012:user/IAMExampleUser", "ServiceName": "Amazon DynamoDB" }, { "TotalAuthenticatedEntities": 0, "ServiceNamespace": "ec2", "ServiceName": "Amazon EC2" }, { "TotalAuthenticatedEntities": 3, "LastAuthenticated": 2018-08-25T15:29:51.156Z, "ServiceNamespace": "s3", "LastAuthenticatedEntity": "arn:aws:iam::123456789012:role/IAMExampleRole", "ServiceName": "Amazon S3" } ]

Arnav は、この情報から、ExamplePolicy1 ポリシーによって、Amazon DynamoDB、Amazon S3、Amazon EC2 の 3 つのサービスへのアクセスが許可されていることを理解します。IAMExampleUser という名前の IAM ユーザーが、11 月 1 日に DynamoDB に最後にアクセスを試み、8 月 25 日には IAMExampleRole ロールを使用して、Amazon S3 にアクセスしようとしたユーザーがいました。昨年 Amazon S3 にアクセスを試みたエンティティは他にも 2 つあります。ただし、昨年 Amazon EC2 にアクセスしようとしたユーザーはいませんでした。

つまり、Arnav は、ポリシーから Amazon EC2 アクションを安全に削除することができます。Arnav は、このポリシーの最新の JSON ドキュメントを確認しようとしています。まず、次のコマンドを使用して、ポリシーのバージョン番号を確認する必要があります。

aws iam list-policy-versions --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1

レスポンスから、Arnav は Versions 配列の現在のデフォルトバージョン番号を収集します。続いて、次のコマンドでそのバージョン番号 (v2) を使用して、JSON ポリシードキュメントをリクエストします。

aws iam get-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --version-id v2

Arnav は、PolicyVersion 配列の Document フィールドで返る JSON ポリシードキュメントを保存します。Arnav は、ポリシードキュメント内で、ec2 名前空間内のアクションを検索します。ポリシーに残っている他の名前空間からのアクションがない場合、影響を受けるアイデンティティ (ユーザー、グループ、およびロール) からポリシーを切り離します。その後、ポリシーを削除します。この場合、ポリシーには、Amazon DynamoDB サービスと Amazon S3 サービスが含まれています。したがって、Arnav は、ドキュメントから Amazon EC2 アクションを削除し、変更内容を保存します。また、次のコマンドを使用して、ポリシーをドキュメントの新しいバージョンで更新し、そのバージョンをデフォルトのポリシーバージョンとして設定します。

aws iam create-policy-version --policy-arn arn:aws:iam::123456789012:policy/ExamplePolicy1 --policy-document file://UpdatedPolicy.json --set-as-default

これで、ExamplePolicy1 ポリシーは更新され、不要な Amazon EC2 サービスへのアクセスは削除されました。

その他の IAM シナリオ

IAM リソース (ユーザー、グループ、ロール、ポリシー) によって、サービスに最後にアクセスを試みた際に関する情報は、次のタスクを完了する際に役立ちます。

データを使用した組織単位のアクセス権限の調整

サービスの最終アクセス時間データを使用して、AWS Organizations で組織単位 (OU) のアクセス許可を制限することができます。

たとえば、John Stiles は AWS Organizations 管理者です。彼は、会社の AWS アカウントでユーザーに過剰なアクセス権限を与えないようにする責任があります。定期的なセキュリティ監査の一部として、彼は自分の組織のアクセス権限を見直します。彼の Development OU には、新しい AWS サービスのテストによく使用されるアカウントが含まれています。John は、180 日間以上アクセスされていないサービスに関するレポートを定期的に見直すことに決定します。その後、彼は OU のメンバーがそれらのサービスにアクセスするためのアクセス許可を削除します。

John は自分のマスターアカウント認証情報を使用して IAM コンソールにサインインします。IAM コンソールで、彼は Development OU の 組織 データを見つけます。彼は、サービスアクセスレポートテーブルを見直し、希望期間の 180 日間以上アクセスされていない 2 つの AWS サービスがあることを確認します。彼は、開発チームが Amazon Lex および AWS Database Migration Service にアクセスするためのアクセス権限を追加したことを覚えています。John は、開発チームに連絡し、これらのサービスをテストするビジネスニーズがないことを確認します。

これで、John はサービスの最終アクセス時間データに関する作業を行う準備ができました。彼は、[Edit in AWS Organizations (AWS Organizations での編集)] を選択し、SCP が複数のエンティティにアタッチされていることが通知されます。彼は [Continue (続行)] を選択します。AWS Organizations で、彼は SCP がアタッチされている 組織 エンティティを確認するためにターゲットを見直します。すべてのエンティティは Development OU 内にあります。

John は、NewServiceTest SCP の Amazon Lex および AWS Database Migration Service アクションへのアクセスを拒否することに決定します。このアクションにより、サービスへの不要なアクセスが削除されます。