ユーザーアクティビティを表示してポリシー範囲を狭める
IAM コンソールでは、IAM ユーザーとロールが最後に AWS サービスにアクセスを試みたときの情報が表示されます。この情報は、サービスの最終アクセス時間データと呼ばれます。このデータによって、不要なアクセス権限を識別し、「最小権限」の原則により良く準拠するよう IAM ポリシーを改善しやすくなります。これは、特定のタスクを実行するために必要な最小権限を付与することを意味します。
注記
最新のアクティビティは通常 4 時間以内に表示されます。アクセスアドバイザーは最新の 365 日のアクティビティを報告します。
IAM エンティティ (ユーザー、グループ、またはロール) が、IAM ポリシー権限を通じて最後に AWS サービスにアクセスした日付と時刻を取得できます。この情報を使用して、IAM ポリシー内の未使用および最近使用されていないアクセス許可を識別できます。その後、未使用のサービスに関するアクセス許可を削除したり、類似の使用パターンを持つユーザーをグループに再編成したりして、アカウントのセキュリティを改善できます。IAM エンティティがアクセス許可を使用したかどうか、および最後に使用したときを把握することは、より少ない処理で不要なアクセス許可を削除して IAM ポリシーを強化するのに役立ちます。
重要
サービスの最終アクセス時間データには、成功したものだけではなく、AWS API へのすべてのアクセスの試行が含まれます。これには、AWS マネジメントコンソール、いずれかの SDK を通じた AWS API、またはその他のコマンドラインツールを使用して行われたすべてのアクセスの試行が含まれます。サービスの最終アクセス時間データで予期しないエントリが表示されても、リクエストが拒否された可能性があるため、アカウントが侵害されたことを意味するわけではありません。すべての API 呼び出しと、それらが成功したか、アクセスか拒否されたかに関する情報については、権威あるソースとして CloudTrail ログを参照してください。詳細については、「AWS CloudTrail を使用した IAM および AWS STS の API コールのログ記録」を参照してください。
このトピックでは、IAM サービスの最終アクセス時間データの機能と、IAM コンソールでの使用方法について説明します。また、サービスの最終アクセス時間データを使用して IAM ポリシーから不要な権限を削除する 2 つの実際的なシナリオについて説明します。
アクセスアドバイザー情報の表示
このデータは、IAM コンソールの [アクセスアドバイザー] タブで任意の IAM ユーザー、グループ、ロール、または管理ポリシーの詳細ビューを参照するときに表示されます。
アクセスアドバイザー情報を見るための最小限のアクセス許可
IAM コンソールでそれらのエンティティを表示するには、ユーザーは、ユーザー、グループ、ポリシーの詳細を表示するためのアクセス許可を持っている必要があります。ただし、このサービスの最終アクセス時間データを表示するには、次のアクションを使用するアクセス許可も必要です。
-
iam:GenerateServiceLastAccessedDetails -
iam:GetServiceLastAccessedDetails -
iam:GetServiceLastAccessedDetailsWithEntities -
iam:ListPoliciesGrantingServiceAccess
このようなアクションは、1 つのリソースに固有ではないため、管理者は、すべてのリソース ("Resource": "*") でこれらのアクションを使用するためのアクセス権限を付与する必要があります。
これらのアクセス許可を付与すると、ユーザーは管理ポリシーにアタッチされたユーザー、グループ、またはロールを表示できることに注意してください。また、ユーザーまたはロールがアクセスできるサービス、アクセスされたサービス、およびアクセスしたユーザーと日時も表示できます。これは
iam:ListEntitiesForPolicy および iam:ListAttached アクセス許可に似ています。
[User/Group/Role]Policies
アクセスアドバイザー情報を表示するには
-
AWS マネジメントコンソール にサインインし、IAM コンソール（https://console.aws.amazon.com/iam/）を開きます。
-
ナビゲーションペインで、[グループ]、または [ユーザー]、または [ロール]、または [ポリシー] を選択します。
-
任意のユーザー、グループ、ロール、またはポリシーの名前を選択してその詳細ビューを開き、[Access Advisor] タブを選択します。このタブには、次の列があるテーブルが表示されます。
- サービス名
-
IAM ポリシーによってアクセス許可が付与されたサービスのリスト (ポリシーを確認している場合)、またはすべての IAM ポリシーによってアクセス許可が IAM エンティティに付与されたサービスのリスト (ユーザー、グループ、またはロールを確認している場合)。
IAM ポリシーによってあるサービスに対する任意のアクセス許可がエンティティに付与されている場合、そのアクセス許可がサービス内の 1 つのアクションだけに関するものであるかそのすべてに関するものであるかにかかわらず、そのサービスの行が表示されます。
- ポリシーのアクセス権限
-
1 つのポリシーの名前と、指定されたサービスにアクセスする権限をこのエンティティに付与する他のポリシーの数。指定されたサービスにアクセスする権限をこのエンティティに付与するすべての IAM ポリシーのリストを表示するには、ポリシー名と数が表示されたリンクを選択します。このリストには、名前、ポリシーの種類 (AWS が管理、お客様が管理、またはインライン)、およびユーザーがポリシーを取得するグループ (該当する場合) が含まれます。
[Policies Granting Permissions] ダイアログボックスで管理ポリシーの名前を選択すると、IAM によってポリシーのテキストを示す新しいブラウザタブが開かれます。ダイアログボックスでグループ名をクリックすると、IAM によってグループの詳細を表示する新しいブラウザタブが開かれます。
- 最終アクセス時間
-
このユーザー、ロール、またはグループのメンバーが、指定されたサービスに最後にアクセスしてからの時間。サービスが更新されたが、更新が 365 日以上前である場合、この値は 365 になります。
- メンバーによるアクセス
-
(グループのみ) グループのメンバーで、このサービスにアクセスしたことがある 1 人のユーザーの名前と他のユーザーの数。グループのメンバーであるすべての IAM ユーザーと、指定されたサービスに各メンバーが最後にいつアクセスしたかを表示するには、このリンクをクリックします。
ダイアログボックスでユーザー名を選択すると、IAM によって、そのユーザーの詳細を表示する新しいブラウザタブが開かれます。
- エンティティによるアクセス
-
(ポリシーのみ) このポリシーを使用して指定されたサービスにアクセスした、1 人のユーザーまたはロールの名前、およびその他のユーザーとロールの数。このポリシーがアタッチされているすべてのユーザーとロールのリスト、および指定されたサービスに各ユーザーがいつアクセスしたかを表示するには、このリンクを選択します。
追加のオプション
-
[Access Advisor] タブの [Filter] メニューを使用して、[Services accessed] および [Services not accessed] のリストを制限します。たとえば、[サービスへのアクセスなし] を選択すると、そのポリシーでリストされているサービスのうち、使用されたことがないものを発見できます。その場合、これらのサービスをポリシーから削除できます。また、[search] ボックスに名前 (または名前の一部) を入力し、入力した内容に名前が一致するエンティティのみにリストを制限することもできます。
-
列見出しのいずれかを選択して、情報をその列の情報に従ってソートします。再び見出しを選択すると、反対の順序にソートできます。
コメント
-
テーブル内のサービスのリストは、IAM ポリシーの履歴状態ではなく現在の状態を反映しています。たとえば、ポリシーの現在のバージョンでは Amazon S3 アクセスのみが許可されており、以前のバージョンでは他の AWS サービスへのアクセスが許可されていた場合、サービスの最終アクセス時間データには Amazon S3 に関するテーブルエントリだけが表示されます。アクセスコントロールの変更履歴を調べようとしている場合や、アクセス履歴を監査する場合は、AWS CloudTrail の使用をお勧めします。
-
通常、最近の [最終アクセス時間] アクティビティがテーブルに表示されるには 4 時間未満の時間がかかります。ただし、一部の状況では最大 12時間かかることがあります。サービスの実行が著しく遅い場合は、IAM コンソールに通知が表示されます。
-
アクセスアドバイザーは最新の 365 日のアクティビティを報告します。アクティビティがない場合、[Not accessed in the tracking period] と報告されます。アクティビティがあったが、365 日前以上である場合、最後にアクセスされた期間として 365 と報告されます。
トラブルシューティングのヒント
サービスの最終アクセス時間データのテーブルが空の場合は、次のいずれかが原因で引き起こされた可能性があります。
-
直接またはグループメンバーシップを通じて、アタッチされているポリシーを持たないユーザーを選択した。
-
メンバーを持たないグループにアタッチされている管理ポリシーを選択した。
-
インラインおよび管理ポリシーのいずれもアタッチされていないユーザー、グループ、またはロールを選択した。
-
リソースベースのポリシーによってのみ付与されるアクセス許可を持つユーザーを選択した。
サンプル使用シナリオ
ポリシー (最初の例) とプリンシパル (2 番目の例) の両方に IAM アクセスアドバイザーを使用することの価値を示す 2 つの例。
IAM ポリシーに関するアクセス許可の分析
チームの AWS インフラストラクチャの管理を担当する管理者について考えます。チームは、Amazon EC2 上で実行されて他の AWS サービスを呼び出すアプリケーションを作成しました。これは、管理者がこのアプリケーションについて EC2 インスタンスをプロビジョニングし、設定を管理する必要があることを意味します。その一部によって IAM ロールがこの EC2 インスタンスにアタッチされます。
注記
IAM ロールを EC2 インスタンスにアタッチすると、これらのインスタンスで実行されるアプリケーションが API リクエストを実行できるようになります。そうすることで、アプリケーションで使用するセキュリティ認証情報を手動で管理する必要がなくなります。AWS 認証情報を作成して配布する代わりに、API リクエストを作成するためのアクセス許可を、インスタンスに割り当てられた IAM ロールに委任できます。詳細については、「Amazon EC2 の IAM ロール」を参照してください。
しかし、管理者は IAM の初心者であり、IAM ロールを EC2 インスタンスにアタッチする際に、ロールのアクセス許可ポリシーに何を入れたらよいか分かりません。管理者は、徹底的なアクセス制御メカニズムを実装することを希望していますが、現時点で優先されるのはアプリケーションが確実に機能することです。そのために、管理者は以下に示している PowerUserAccess AWS 管理ポリシーを単にコピーし、本当に必要なアクセス権限が明確になったときに変更することにします。このポリシーでは、IAM を除くアカウント内のすべての AWS サービスおよびリソースへの完全な読み取り/書き込みアクセス許可が付与されます (もちろん長期的な解決策としてはお勧めしません)。
{ "Statement": [ { "Effect": "Allow", "NotAction": "iam:*", "Resource": "*" } ] }
アプリケーションがしばらく実行された後、管理者はサービスの最終アクセス時間データを使用して、実際に使用されているアクセス許可を確認できます。その後、管理者は、アプリケーションに関するアクセス許可を削減できます。管理者が IAM コンソールにサインインし、Policies を選択すると、アプリケーション実行中に EC2 インスタンスに関連付けられている IAM ロールにアタッチされたポリシーが表示されます。その後、管理者は、ポリシー名を選択して詳細を表示してから、[Access Advisor] タブを選択します。
管理者は [Last Accessed] 列にリストされているタイムスタンプを確認し、チームのアプリケーションが Amazon DynamoDB、Amazon S3、Amazon CloudWatch、Amazon Simple Notification Service (Amazon SNS)、および Amazon Simple Queue Service (Amazon SQS) だけを使用していることに気づきます。その後、[Permissions] タブを選択して、アクセス許可を制限する必要があるポリシーの行を展開できるようになります。ユーザーに直接アタッチされているインラインポリシーの [Edit policy] を選択します。管理ポリシーを編集するには、ポリシー名を選択して [Policies] ページに移動します。このページで、管理者は、アプリケーションが正常に実行するのに必要な許可のみが表示されるように、ポリシーのアクセスを変更できます。
IAM ユーザーに関する権限の分析
組織内のユーザーに過剰な AWS 権限を与えないことに責任を持つ IT 管理者がいるとします。定期的なセキュリティチェックの一部として、管理者はすべての IAM ユーザーの権限を見直します。これらのユーザーの 1 人は、以前にセキュリティエンジニアのロールを務めていたアプリケーション開発者です。ジョブ要件が変更されたため、開発者は新しいジョブの "app-dev" グループ (Amazon EC2、Amazon EBS、Auto Scaling などの複数のサービスへの権限を付与) と古いジョブの "security-team" グループ (IAM と CloudTrail への権限を付与) の両方のメンバーとなっています。
管理者は IAM コンソールにサインインしてユーザーを選択し、開発者の IAM ユーザーの名前を選択して [Access Advisor] タブを選択します。
管理者は [Last Accessed] 列のタイムスタンプと、開発者が最近 IAM、CloudTrail、Route 53、Amazon Elastic Transcoder、他の多くの AWS サービスにアクセスしていないという通知を確認します。これで、管理者はサービスの最終アクセス時間情報に関する作業を行う準備ができました。ただし、前の例とは異なり、開発者の IAM ユーザー (複数のポリシーの対象となっていて、複数の IAM グループのメンバーとなっている可能性があります) などのプリンシパルに対する次のステップを実行するには、管理者が他のユーザーのアクセスを誤って中断しないように慎重に進める必要があります。したがって、最初のステップとして開発者がこれらの権限を受け取る方法を決定します。
管理者は、開発者が内部セキュリティチームのメンバーではなくなったため、IAM と CloudTrail にアクセスするビジネス上のニーズがなくなったことを確認します。これらのアクセス許可について、管理者はグループメンバーシップとポリシーを分析した結果、最も簡単な解決策はポリシーを変更せずに、セキュリティチームの IAM グループから開発者のメンバーシップを削除することであると判断します。
管理者は、app-dev グループから Route 53、Elastic Transcoder などへの開発者へのアクセスも、使用されていないため取り消す必要があると推測するかもしれません。ただし、これらのアクセス許可を app-dev ポリシーから削除すると、グループの他のメンバーに悪影響を及ぼす可能性があります。したがって、削除する前に、管理者は app-dev グループポリシーのサービスの最終アクセス時間データを確認する必要があります。そのデータを使用すれば、すべての app-dev グループメンバーが全般的にこれらの権限を使用していないのか、特定の開発者が使用していないだけなのかを明らかにすることができます。すべてのグループメンバーが本当に使用していない場合、管理者は app-dev グループのポリシーから安全にこれらの権限を削除できます。この開発者だけがその権限を使用していない場合、その開発者用に異なる権限セットを作成することができます。別のオプションとしては、このユーザーにアクセス許可の境界を適用し、このユーザーに許可されるアクセス許可を制限します。または、何もせずに、すべてのユーザーがすべての付与されたアクセス許可を使用するわけではないと見込みます。
この例が示すように、プリンシパルのサービスの最終アクセス時間データを、多数の次のステップ (以下の提案を参照) の開始点として使用することができます。ただし、アクセス可能性と最小限の特権の組織に適した最適なバランスを取るステップを選択するのは、IAM 管理者の責任です。
データが追跡されるリージョン
AWS は、ほとんどのリージョンでサービスの最終アクセス時間データを収集します。データは、最大 365 日保存されます。AWS でさらにリージョンを追加すると、AWS の各リージョンにおけるデータの追跡開始日とあわせて、これらのリージョンが次のテーブルに追加されます。
| リージョン名 | リージョン | 追跡開始日 |
|---|---|---|
| 米国東部（バージニア北部） | us-east-1 | 2015 年 10 月 1 日 |
| 米国東部 (オハイオ) | us-east-2 | 2017 年 10 月 27 日 |
| 米国西部 (北カリフォルニア) | us-west-1 | 2015 年 10 月 1 日 |
| 米国西部 (オレゴン) | us-west-2 | 2015 年 10 月 1 日 |
| アジアパシフィック (東京) | ap-northeast-1 | 2015 年 10 月 1 日 |
| アジアパシフィック (ソウル) | ap-northeast-2 | 2016 年 1 月 6 日 |
| アジアパシフィック (シンガポール) | ap-southeast-1 | 2015 年 10 月 1 日 |
| アジアパシフィック (シドニー) | ap-southeast-2 | 2015 年 10 月 1 日 |
| アジアパシフィック (ムンバイ) | ap-south-1 | 2016 年 6 月 27 日 |
| カナダ (中部) | ca-central-1 | 2017 年 10 月 28 日 |
| 欧州 (フランクフルト) | eu-central-1 | 2015 年 10 月 1 日 |
| 欧州 (アイルランド) | eu-west-1 | 2015 年 10 月 1 日 |
| 欧州 (ロンドン) | eu-west-2 | 2017 年 10 月 28 日 |
| EU (パリ) | eu-west-3 | 2017 年 18 月 12 日 |
| 南米 (サンパウロ) | sa-east-1 | 2015 年 12 月 11 日 |
前の表にリージョンが記載されていない場合、そのリージョンは、まだサービスの最終アクセス時間データを提供していません。
