最終アクセス情報を使用するシナリオ例 - AWS Identity and Access Management
情報を使用した IAM グループのアクセス許可の制限情報を使用した IAM ユーザーのアクセス許可の制限IAM リソースを削除する前に情報を使用するIAM ポリシーを編集する前に情報を使用するその他の IAM のシナリオ情報を使用した組織単位のアクセス許可の調整

最終アクセス情報を使用するシナリオ例

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

注記

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

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

情報を使用した IAM グループのアクセス許可の制限

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

たとえば、Paulo Santos は、Example Corp のAWS ユーザー権限の定義を担当する管理者です。この会社は AWS の使用を開始したばかりであり、ソフトウェア開発チームは使用する AWS のサービスをまだ定義していません。Paulo は必要なサービスにのみアクセス可能なアクセス許可をチームに付与しようと考えていますが、サービスが定義されていないため、パワーユーザーのアクセス許可を一時的に付与します。その後、最終アクセス情報を使用してグループのアクセス許可を制限します。

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

注記

Paulo のパワーユーザーは、一部のサービスや機能を使用するために、iam:CreateServiceLinkedRole アクセス許可が必要な場合があります。彼は、このアクセス許可を追加すると、ユーザーがサービスにリンクされたロールを作成することを許可されることを理解しています。彼は、パワーユーザーのためにこのリスクを受け入れます。

{

    "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 Management Console グループの最終アクセス情報を表示します。グループメンバーがアクセスしたサービスのリストを表示します。先週、このユーザーがアクセスしたサービスは、AWS CloudTrail、 Amazon CloudWatch Logs、Amazon EC2、AWS KMS、Amazon S3 の 5 つであることが分かりました。AWS の使用開始時は他のいくつかのサービスにもアクセスしていましたが、それ以降はアクセスしていません。

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

注記

Paulo のパワーユーザーは、一部のサービスや機能を使用するために、iam:CreateServiceLinkedRole アクセス許可が必要な場合があります。彼は、このアクセス許可を追加すると、ユーザーがサービスにリンクされたロールを作成することを許可されることを理解しています。彼は、パワーユーザーのためにこのリスクを受け入れます。

{
    "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 イベント履歴でのイベントの表示を参照してください。

情報を使用した 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 アイデンティティ (ユーザー、グループ、ロール)、またはそのリソースに影響するポリシーを編集する前の IAM ポリシーの最終アクセス情報を確認できます。使用しているユーザーのアクセスを削除しないように、このステップは重要です。

たとえば、Arnav Desai は Example Corp の開発者および AWS 管理者です。彼のチームが AWS を使い始めたとき、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 の Organizations データを見つけます。彼は、サービスアクセスレポートテーブルを見直し、希望期間の 180 日間以上アクセスされていない 2 つの AWS サービスがあることを確認します。彼は、開発チームが Amazon Lex および AWS Database Migration Service にアクセスするためのアクセス権限を追加したことを覚えています。John は、開発チームに連絡し、これらのサービスをテストするビジネスニーズがないことを確認します。

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

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