# 最終アクセス情報を使用するシナリオ例
最終アクセス情報を使用して、IAM エンティティまたは AWS Organizations エンティティに付与するアクセス許可に関する決定を行うことができます。詳細については、「[最終アクセス情報を使用して AWS のアクセス許可を調整する](access_policies_last-accessed.md)」を参照してください。
**注記**
IAM または AWS Organizations のエンティティあるいはポリシーに関するアクセス情報を表示する前に、データのレポート期間、レポート対象のエンティティ、評価対象のポリシータイプをご確認ください。詳細については、[最終アクセス情報についての主要事項](access_policies_last-accessed.md#access_policies_last-accessed-know)を参照してください。
お客様は、管理者として、会社に適したアクセシビリティと最小限のアクセス権限のバランスを取る必要があります。
## 情報を使用した IAM グループのアクセス許可の制限
最終アクセス情報を使用して、ユーザーが必要とするサービスのみを含むように IAM グループのアクセス許可を制限することができます。この方法は、サービスレベルで[最小限の権限を付与する](best-practices.md#grant-least-privilege)上で重要なステップです。
たとえば、Paulo Santos は、Example Corp のAWS ユーザー権限の定義を担当する管理者です。この会社は AWS の使用を開始したばかりであり、ソフトウェア開発チームは使用する AWS のサービスをまだ定義していません。Paulo は必要なサービスにのみアクセス可能なアクセス許可をチームに付与しようと考えていますが、サービスが定義されていないため、パワーユーザーのアクセス許可を一時的に付与します。その後、最終アクセス情報を使用してグループのアクセス許可を制限します。
Paulo は、次の JSON テキストを使用して、`ExampleDevelopment` という名前の管理ポリシーを作成します。次に、`Development` という名前のグループにそのポリシーをアタッチし、開発者全員をグループに追加します。
**注記**
Paulo のパワーユーザーは、一部のサービスや機能を使用するために、`iam:CreateServiceLinkedRole` アクセス許可が必要な場合があります。彼は、このアクセス許可を追加すると、ユーザーがサービスにリンクされたロールを作成することを許可されることを理解しています。彼は、パワーユーザーのためにこのリスクを受け入れます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessToAllServicesExceptPeopleManagement",
"Effect": "Allow",
"NotAction": [
"iam:*",
"organizations:*"
],
"Resource": "*"
},
{
"Sid": "RequiredIamAndOrgsActions",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization"
],
"Resource": "*"
}
]
}
```
------
90 日後、Paulo は `Development`を使用して、AWS マネジメントコンソール グループの[最終アクセス情報を表示](access_policies_last-accessed-view-data.md#access_policies_last-accessed-viewing)します。グループメンバーがアクセスしたサービスのリストを表示します。先週、このユーザーがアクセスしたサービスは、AWS CloudTrail、 Amazon CloudWatch Logs、Amazon EC2、AWS KMS、Amazon S3 の 5 つであることが分かりました。AWS の使用開始時は他のいくつかのサービスにもアクセスしていましたが、それ以降はアクセスしていません。
Pauloは、ポリシーの権限を縮小して、これら 5 つのサービスと必要な IAM と AWS Organizations アクションだけを含めることにしました。また、次の JSON テキストを使用して、`ExampleDevelopment` ポリシーを編集します。
**注記**
Paulo のパワーユーザーは、一部のサービスや機能を使用するために、`iam:CreateServiceLinkedRole` アクセス許可が必要な場合があります。彼は、このアクセス許可を追加すると、ユーザーがサービスにリンクされたロールを作成することを許可されることを理解しています。彼は、パワーユーザーのためにこのリスクを受け入れます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "FullAccessToListedServices",
"Effect": "Allow",
"Action": [
"s3:*",
"kms:*",
"cloudtrail:*",
"logs:*",
"ec2:*"
],
"Resource": "*"
},
{
"Sid": "RequiredIamAndOrgsActions",
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:ListRoles",
"organizations:DescribeOrganization"
],
"Resource": "*"
}
]
}
```
------
アクセス許可をさらに制限するために、Paulo は、AWS CloudTrail の [**イベント履歴**] でアカウントのイベントを表示します。そこでは、詳細なイベント情報を表示して、開発者が必要とするアクションとリソースのみが含まれるように、ポリシーのアクセス許可を制限することができます。詳細については、*AWS CloudTrail CloudTrail ユーザーガイド*の [CloudTrail イベント履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events-console.html)を参照してください。
## 情報を使用した IAM ユーザーのアクセス許可の制限
最終アクセス情報を使用して、各 IAM ユーザーのアクセス許可を制限することができます。
たとえば、Martha Rivera は、アクセス許可を管理する IT 管理者であり、AWS アクセス許可を組織内のユーザーに過剰に付与しないように管理する必要があります。定期的なセキュリティチェックの一部として、彼女はすべての IAM ユーザーのアクセス許可を見直します。これらのユーザーの中には、以前にセキュリティエンジニアのロールを担っていた、Nikhil Jayashankar という名前のアプリケーション開発者がいます。ジョブ要件が変更され、Nikhil は現在 `app-dev` グループと `security-team` グループの両方のメンバーです。`app-dev` グループでは、Amazon EC2、Amazon EBS、Auto Scaling、Amazon S3、Route 53、Elastic Transcoder などの複数のサービスへのアクセス許可が付与されています。以前のジョブの `security-team` グループでは、IAM および CloudTrail へのアクセス許可が付与されています。
管理者である Martha が IAM コンソールにサインインして**ユーザー**を選択後、`nikhilj` という名前を選択し、[**最終アクセス**] タブを選択します。
Martha は [**最終アクセス**] 列を確認し、Nikhil が最近 、IAM、CloudTrail、Route 53、Amazon Elastic Transcoder、および多数の AWS サービスにアクセスしていないことに気づきました。ニヒルは Amazon S3 にアクセスしました。Martha は、サービスのリストから [**S3**] を選択し、Nikhil が過去 2 週間以内にいくつかの Amazon S3 `List` アクションを実行したことを知ります。Martha は、Nikhil が社内のセキュリティチームのメンバーではなくなったため、IAM と CloudTrail にアクセスするビジネス上のニーズがなくなったことを確認します。
Martha は、サービスおよびアクションの最終アクセス情報に基づいて作業を行う準備ができました。ただし、前の例のグループとは異なり、`nikhilj` のような IAM ユーザーには、複数のポリシーが適用され、複数のグループのメンバーになることがあります。Martha は、`nikhilj` やその他のグループメンバーのアクセスを誤って中断しないように慎重に進める必要があります。彼女は、Nikhil に付与する必要のあるアクセス権だけでなく、これらのアクセス許可が付与されている*背景*を確認する必要があります。
Martha は、[**アクセス許可**] タブを選択します。ここでは、`nikhilj` に直接アタッチされているポリシーと、グループからアタッチされているポリシーを確認します。各ポリシーを展開して、ポリシーの概要を確認し、Nikhil が現在使用していないサービスへのアクセスを許可しているポリシーを確認します。
+ IAM – `IAMFullAccess` AWS 管理ポリシーは、`nikhilj` に直接アタッチされているほか、`security-team` グループにもアタッチされています。
+ CloudTrail - `AWSCloudTrailReadOnlyAccess` AWS 管理ポリシー は、`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 と Amazon S3 にアクセスしたことを知ります。しかし、昨年 Elastic Transcoder にアクセスしたグループメンバーはいませんでした。彼女は、カスタマー管理ポリシー `App-Dev-ElasticTranscoder` をグループから削除します。
次に、カスタマー管理ポリシー `App-Dev-ElasticTranscoder` の最終アクセス情報を確認します。このポリシーは、その他の IAM アイデンティティのいずれにもアタッチされていないことが分かりました。彼女は社内で調査を行い、このポリシーは今後不要であることを確認して削除しました。
## IAM リソースを削除する前に情報を使用する
IAM リソースを削除する前に、最終アクセス情報を使用して、最後にリソースを使用してから一定の時間が経過したことを確認できます。これは、ユーザー、グループ、ロール、ポリシーに適用されます。これらのアクションの詳細については、以下のトピックを参照してください。
+ **IAM ユーザー** – [IAM ユーザーを削除または非アクティブ化する](id_users_remove.md)
+ **グループ** – [IAM グループを削除する](id_groups_manage_delete.md)
+ **ロール** – [ロールまたはインスタンスプロファイルを削除する](id_roles_manage_delete.md)
+ **ポリシー** – [IAM ポリシーを削除する (これにより、ポリシーは ID から切り離されます)](access_policies_manage-delete.md)
## IAM ポリシーを編集する前に情報を使用する
IAM アイデンティティ (ユーザー、グループ、ロール)、またはそのリソースに影響するポリシーを編集する前の IAM ポリシーの最終アクセス情報を確認できます。使用しているユーザーのアクセスを削除しないように、このステップは重要です。
例えば、Arnav Desai は Example Corp の開発者および AWS 管理者です。彼のチームが AWS Organizations を使い始めたとき、IAM と AWS を除くすべてのサービスへのフルアクセスを許可するパワーユーザーアクセスをすべての開発者に与えました。[最小限の権限の付与](best-practices.md#grant-least-privilege)の最初のステップとして、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 リソース (ユーザー、グループ、ロール、ポリシー) によって、サービスに最後にアクセスを試みた際に関する情報は、次のタスクを完了する際に役立ちます。
+ **ポリシー** – [既存のカスタマー管理ポリシーまたはインラインポリシーを編集してアクセス許可を削除する](access_policies_manage-edit.md)
+ **ポリシー** – [インラインポリシーを削除して、管理ポリシーに変換し、削除する](access_policies-convert-inline-to-managed.md)
+ **ポリシー** – [既存のポリシーに明示的な拒否を追加する](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)
+ **ポリシー** – [管理ポリシーを ID (ユーザー、グループ、ロール) からデタッチする](access_policies_manage-attach-detach.md#detach-managed-policy-console)
+ **エンティティ** – [IAM エンティティ (ユーザーまたはロール) が持つことができる最大のアクセス許可を制御するためのアクセス許可の境界を設定する](access_policies_manage-attach-detach.md)
+ **グループ** – [グループからユーザーを削除する](id_groups_manage_add-remove-users.md)
## 情報を使用した組織単位のアクセス許可の調整
最終アクセス情報を使用して、AWS Organizations で組織単位 (OU) のアクセス許可を制限することができます。
たとえば、John Stiles は AWS Organizations 管理者です。彼は、会社の AWS アカウント でユーザーに過剰なアクセス許可を与えないようにする責任があります。定期的なセキュリティ監査の一部として、彼は自分の組織のアクセス権限を見直します。彼の `Development` OU には、新しい AWS サービスのテストによく使用されるアカウントが含まれています。John は、180 日間以上アクセスされていないサービスに関するレポートを定期的に見直すことに決定します。その後、彼は OU のメンバーがそれらのサービスにアクセスするためのアクセス許可を削除します。
John は自分の管理アカウント認証情報を使用して IAM コンソールにサインインします。IAM コンソールで、彼は `Development` OU の AWS Organizations データを見つけます。彼は、**サービスアクセスレポート**テーブルを見直し、希望期間の 180 日間以上アクセスされていない 2 つの AWS サービスがあることを確認します。彼は、開発チームが Amazon Lex および AWS Database Migration Service にアクセスするためのアクセス権限を追加したことを覚えています。John は、開発チームに連絡し、これらのサービスをテストするビジネスニーズがないことを確認します。
John は、最終アクセス情報に基づいて作業を行う準備ができました。彼は、**[AWS Organizations での編集]** を選択し、SCP が複数のエンティティにアタッチされていることが通知されます。彼は [**Continue (続行)**] を選択します。AWS Organizations で、彼は SCP がアタッチされている AWS Organizations エンティティを確認するためにターゲットを見直します。すべてのエンティティは `Development` OU 内にあります。
John は、AWS Database Migration Service SCP の Amazon Lex および `NewServiceTest` アクションへのアクセスを拒否することに決定します。このアクションにより、サービスへの不要なアクセスが削除されます。