IAM でのセキュリティのベストプラクティス
AWS リソースのセキュリティを確保するために、AWS Identity and Access Management (IAM) サービスの以下の推奨事項に従うことができます。
トピック
- AWS アカウント ルートユーザーのアクセスキーをロックする
- ロールを使用してアクセス許可を委任する
- 最小限の特権を認める。
- AWS 管理ポリシーを使用したアクセス許可の使用開始
- ポリシーの検証
- インラインポリシーではなくカスタマー管理ポリシーを使用する
- アクセスレベルを使用して、IAM のアクセス許可を確認する
- ユーザーのために強度の高いパスワードポリシーを設定する。
- MFA の有効化
- Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
- アクセスキーを共有しない
- 認証情報を定期的にローテーションする。
- 不要な認証情報の削除
- 追加セキュリティに対するポリシー条件を使用する。
- AWS アカウントのアクティビティのモニタリング
AWS アカウント ルートユーザーのアクセスキーをロックする
お客様はアクセスキー (アクセスキー ID およびシークレットアクセスキー) を使用し、AWS に対してプログラムによるリクエストをすることができます。ただし、AWS アカウント のルートユーザーアクセスキーを使用しないでください。AWS アカウント のルートユーザーアクセスキーにより、請求情報を含む、すべての AWS サービスのお客様のリソースすべてにフルアクセスできます。AWS アカウント のルートユーザーアクセスキーに関連付けられたアクセス許可を制限することはできません。
そのため、クレジットカード番号や他の機密情報を保護するのと同じように、ご自身のルートユーザーアクセスキーを保護してください。これを行うには、いくつかの方法があります。
-
強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、ルートユーザーを使用しないことです。その代わりに、ルートユーザーの認証情報はIAM 管理者ユーザーを作成する場合にのみ使用してください。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。日常的なタスクでは、IAM 管理者ユーザーを使用しないでください。代わりに、ロールを使用してアクセス許可を委任してください。
-
ご自身の AWS アカウント ルートユーザーのアクセスキーをすでにお持ちの場合は、削除してください。それを保持する必要がある場合は、アクセスキーを定期的にローテーション(変更)してください。 のアクセスキーを削除または変更するには、AWS Management Console の「
My Security Credentials page」にアクセスして、アカウントの E メールアドレスとパスワードでサインインします。ご自身のアクセスキーは [Access keys] セクションで管理できます。アクセスキーのローテーションの詳細については、「アクセスキーの更新」を参照してください。 -
ご自身の AWS アカウント のルートユーザーパスワードやアクセスキーを決して他者に開示しないでください。本書の残りのセクションでは、AWS アカウント ルートユーザー認証情報を他のユーザーと共有するのを避ける方法について紹介します。また、アプリケーションに埋め込むのを避ける方法も説明します。
-
AWS Management Console にアクセスするアカウントレベルを保護するために、強度の高いパスワードを設定します。AWS アカウント ルートユーザーパスワードの管理の詳細については、「AWS アカウントのルートユーザーのパスワードの変更」を参照してください。
-
AWS アカウント ルートユーザーアカウントの AWS Multi-Factor Authentication (MFA) を有効にします。詳細については、「AWS での多要素認証 (MFA) の使用」を参照してください。
ロールを使用してアクセス許可を委任する
AWS Security Token Service オペレーションを使って IAM ロールを引き受けるか、AWS Management Consoleでロールを切り替えて、一時的にロールセッションの認証情報を受信します。これは、長いパスワードやアクセスキーの認証情報を使用するよりも安全です。セッションの期間は限られているため、資格情報が侵害された場合のリスクを軽減できます。
ベストプラクティスとしては、作業に必要なリソースのみにアクセスできるような IAM ロールの一時的な認証情報を使います (最小限のアクセス許可を与える)。外部 ID ソースから、アカウント内の AWS リソースにユーザーがアクセスできるようにAWS Single Sign-On を設定します。1 つのアカウント内で SAML またはウェブ ID ソースからの ID がロールを引き受けられるように、IAM ロールを設定できます。
IAM ユーザーの場合、特定のジョブのタスクのために別のロールを作成し、これらのタスクのためにロールを引き受けます。IAM 管理者ユーザーを、日常業務に使用しないでください。
ロールの用語については、「ロールに関する用語と概念」を参照してください。
最小限の特権を認める。
IAM ポリシーを作成する場合、最小限のアクセス権を付与するという標準的なセキュリティアドバイスに従うか、タスクの実行に必要なアクセス許可のみ付与します。ユーザー (およびロール) が何をする必要があるのかを決定し、それからそれらのタスクのみの実行を許可するポリシーを作成します。
最小限のアクセス許可から開始し、必要に応じて追加のアクセス許可を付与します。この方法は、寛容なアクセス許可で始め、後でそれらを強化しようとするよりも安全です。
最小限のアクセス許可の代わりに、AWS 管理対象ポリシーまたはワイルドカード *
アクセス許可を持つポリシーを使用して、ポリシーの使用を開始できます。プリンシパルにジョブに必要な以上のアクセス許可を付与すると、セキュリティ上のリスクを考慮してください。これらのプリンシパルをモニタリングして、使用しているアクセス許可を確認します。次に、最小限の特権ポリシーを記述します。
IAM には、付与するアクセス許可を絞り込むのに役立つオプションがいくつか用意されています。
-
アクセスレベルのグループ化 – ポリシーが付与するアクセスレベルを把握できます。ポリシーアクションは、
List
、Read
、Write
、Permissions management
、またはTagging
として分類されています。たとえば、List
やRead
アクセスレベルからアクションを選択し、ユーザーに読み取り専用のアクセスレベルを付与することができます。アクセスレベルの権限を理解するためにポリシーの概要を使用するには「アクセスレベルを使用して、IAM のアクセス許可を確認する」をご覧ください。 -
ポリシーの検証— JSON ポリシーを作成および編集するときに、IAM Access Analyzer を使用してポリシーの検証を実行できます。既存のすべてのポリシーを確認および検証することをお勧めします。IAM Access Analyzer では、ポリシーを検証するために 100 を超えるポリシーチェックが提供されます。ポリシー内のステートメントで、過度に許容されるアクセスを許可すると、セキュリティ警告が生成されます。最小限の特権の付与に向けて作業するときに、セキュリティ警告によって提供される実用的な推奨事項を使用できます。IAM Access Analyzer で提供されるポリシーチェックの詳細については、「IAM Access Analyzer ポリシーの検証」を参照してください。。
-
アクセスアクティビティに基づくポリシーの生成— 付与するアクセス権限を調整するために、IAM エンティティ (ユーザーまたはロール) のアクセスアクティビティに基づく IAM ポリシーを生成できます。IAM Access Analyzer は AWS CloudTrail ログを確認し、指定した日付範囲内のロールが使用したアクセス許可を含むポリシーテンプレートを生成します。テンプレートを使用して、きめ細かなアクセス権限で管理ポリシーを作成し、それを IAM エンティティにアタッチできます。これにより、特定のユースケースでロールが AWS リソースとインタラクションするために必要なアクセス権限のみを付与します。詳細については、アクセスアクティビティに基づいてポリシーを生成するを参照してください。
-
最終アクセス情報を使用 — 最低限のアクセス許可で役立つもう 1 つの機能は、最終アクセス情報です。IAM ユーザー、グループ、ロール、ポリシーのこの情報は、IAM コンソールの詳細ページの [アクセスアドバイザー] に表示されます。最終アクセス情報には、Amazon EC2、IAM、Lambda、Amazon S3 など、一部のサービスで最後にアクセスされたアクションに関する情報も含まれます。AWS Organizations 管理アカウントの認証情報を使用してサインインすると、IAM コンソールの [AWS Organizations] セクションでサービスの最終アクセス情報を表示できます。AWS CLI または AWS API を使用して、IAM または Organizations でエンティティまたはポリシーの最終アクセス情報のレポートを取得するために使用することもできます。この情報を使用して不要なアクセス許可を識別し、最小権限の原則により良く準拠するよう IAM または Organizations ポリシーを改善することができます。詳細については、「最終アクセス情報を使用した AWS のアクセス許可の調整」を参照してください。
-
AWS CloudTrail のアカウントイベントを確認 - アクセス許可をさらに削減するには、AWS CloudTrail のイベント履歴でアカウントのイベントを表示できます。CloudTrail のイベントログには、ポリシーのアクセス許可を減らすために使用できる詳細なイベント情報が含まれます。ログには、IAM エンティティが必要とするアクションとリソースのみが含まれます。詳細については、AWS CloudTrail ユーザーガイドの CloudTrail イベント履歴でのイベントの表示を参照してください。
詳細については、以下を参照してください:
-
各サービスに対するポリシーのトピック。サービスを特定したリソースにポリシーを書く方法の例を挙げています。例:
-
Amazon DynamoDB 開発者ガイドのAmazon DynamoDB に対する認証とアクセスコントロール
-
Amazon Simple Storage Service ユーザーガイドのバケットポリシーとユーザーポリシーの使用
-
Amazon Simple Storage Service ユーザーガイドの「アクセスコントロールリスト (ACL) の概要」
-
AWS 管理ポリシーを使用したアクセス許可の使用開始
最小権限を付与するポリシーを使用するか、タスクの実行に必要なアクセス許可のみを付与することをお勧めします。最小限の権限を付与する最も安全な方法は、チームに必要な権限のみを使用してカスタムポリシーを作成することです。必要に応じて、チームがより多くの権限を要求できるようにプロセスを作成する必要があります。チームに必要な許可のみを提供する IAM カスタマーマネージドポリシーを作成するには、時間と専門知識が必要です。
AWS 管理ポリシー を使用して、IAM ID(ユーザー、ユーザーのグループ、およびロール)へのアクセス許可の追加を開始。AWS 管理ポリシーは一般的な使用例をカバーし、AWS アカウントで利用できます。AWS 管理ポリシーは、最小特権のアクセス許可を付与しません。プリンシパルにジョブに必要な以上のアクセス許可を付与すると、セキュリティ上のリスクを考慮する必要があります。
ジョブ機能を含む AWS 管理ポリシーを任意の IAM ID にアタッチできます。最小特権のアクセス許可に切り替えるには、AWS Identity and Access Management Access Analyzerを実行して、AWS 管理ポリシーでプリンシパルをモニタリングします。どのアクセス許可を使用しているかを学習したら、カスタムポリシーを作成するか、チームに必要なアクセス許可のみを持つポリシーを生成できます。これは安全性が低くなりますが、チームが AWS をどのように使用しているかを学習するにつれて柔軟性が高まります。
AWS 管理ポリシーは、多くの一般的ユースケースでアクセス許可を提供できるように設計されています。特定のジョブ機能用に設計された AWS 管理ポリシーの詳細については、AWSジョブ機能の 管理ポリシー を参照してください。
ポリシーの検証
作成するポリシーを検証するのがベストプラクティスです。JSON ポリシーを作成および編集するときに、ポリシーの検証を実行できます。IAM は JSON 構文エラーを識別します。一方、IAM Access Analyzer は 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーを作成するのに役立ちます。既存のポリシーをすべて確認して検証することをお勧めします。ポリシーの検証の詳細については、「IAM ポリシーの検証」を参照してください。IAM Access Analyzer で提供されるポリシーチェックの詳細については、「IAM Access Analyzer ポリシーの検証」を参照してください。。
インラインポリシーではなくカスタマー管理ポリシーを使用する
カスタムポリシーの場合は、インラインポリシーではなく、管理ポリシーを使用することをお勧めします。これらのポリシーを使用する主な利点は、コンソール内のすべての管理ポリシーを 1 か所で確認できることです。また、AWS CLI または AWS API の単一オペレーションで、この情報を表示することもできます。インラインポリシーは、 アイデンティティ (ユーザー、ユーザーグループ、ポリシー) にのみ存在するポリシーです。管理ポリシーは、複数のアイデンティティにアタッチできる個別の IAM リソースです。詳細については、「管理ポリシーとインラインポリシー」を参照してください。
状況によっては、管理ポリシーよりインラインポリシーを選択することをお勧めします。詳細については、「」を参照してください管理ポリシーとインラインポリシーの比較
インラインポリシーを管理ポリシーに変換できます。詳細については、「インラインポリシーを管理ポリシーに変換する」を参照してください。
アクセスレベルを使用して、IAM のアクセス許可を確認する
AWS アカウントのセキュリティを向上させるには、IAM ポリシーを定期的に確認し、モニタリングする必要があります。ポリシーにより、必要なアクションのみの実行に必要な最小限の権限が付与されていることを確認します。
ポリシーを確認する場合、そのポリシー内の各サービスのアクセスレベルの要約を含むポリシー概要を表示できます。AWS は、各サービスのアクションを、各アクションが実行する内容に基づいて、5 つのアクセスレベル (List
、Read
、Write
、Permissions management
、または Tagging
) のいずれかに分類します。これらのアクセスレベルを使用して、ポリシーに含めるアクションを判断できます。
たとえば、Amazon S3 サービスでは、大きいグループのユーザーに List
および Read
アクションへのアクセスを許可します。このようなアクションによって、これらのユーザーはバケットを一覧表示し、Amazon S3 内のオブジェクトを取得できます。ただし、S3 バケットの削除やオブジェクトの追加に必要な Amazon S3 Write
アクションへのアクセスは、小さいグループのユーザーにのみ許可する必要があります。さらに、Amazon S3 Permissions management
アクションへのアクセスを管理者のみに許可するように、アクセス許可を制限する必要があります。これにより、限られた数の人だけが Amazon S3 のバケットポリシーを管理できるようになります。これは、IAM および AWS Organizations サービスでの Permissions management
アクションにとって特に重要です。Tagging
アクションを許可すると、リソースのタグのみを変更するアクションを実行するアクセス許可がユーザーに付与されます。ただし、一部の Write
アクション (CreateRole
など) は、リソースの作成時またはそのリソースの他の属性の変更時にリソースのタグ付けを許可します。したがって、Tagging
アクションへのアクセスを拒否してもユーザーによるリソースのタグ付けを防ぐことはできません。アクセスレベルの概要の詳細と例については、「ポリシー概要内のアクセスレベルの概要について」を参照してください。
サービス内の各アクションに割り当てられているアクセスレベルの分類を表示するには、「AWS のサービスのアクション、リソース、および条件キー」を参照してください。
ポリシーのアクセスレベルを確認するには、まずポリシーの概要を特定する必要があります。ポリシー概要は、管理ポリシーの [ポリシー] ページ、ユーザーにアタッチされているポリシーの [ユーザー] ページに含まれています。詳細については、「ポリシー概要 (サービスの一覧)」を参照してください。
ポリシー概要のアクセスレベルの列には、ポリシーにより、サービスの 4 つの AWS アクセスレベルの 1 つ以上に対してフルまたは制限付きのアクセスが許可されていることが示されます。あるいは、ポリシーにより、サービス内のすべてのアクションへのフルアクセスが許可されることが示される場合もあります。この [Access level (アクセスレベル)] 列の情報を使用して、ポリシーにより許可されるアクセスのレベルを把握できます。その後、AWS アカウントをより安全にするためのアクションを取ることができます。アクセスレベルの概要の詳細と例については、「ポリシー概要内のアクセスレベルの概要について」を参照してください。
ユーザーのために強度の高いパスワードポリシーを設定する。
ユーザーが各自のパスワードを変更できるように許可する場合は、強力なパスワードを作成し、定期的にパスワードを変更することをユーザーに要求するカスタムパスワードポリシーを作成します。IAM コンソールの [Account Settings
MFA の有効化
セキュリティを高めるために、アカウントのすべてのユーザーに対して多要素認証 (MFA) を要求することをお勧めします。MFA では、ユーザーは認証チャレンジに対するレスポンスを生成するデバイスを所有します。サインインプロセスを完了するには、ユーザーの認証情報とデバイス生成のレスポンスの両方が必要です。ユーザーのパスワードまたはアクセスキーが侵害された場合でも、追加の認証要件により、アカウントのリソースは安全です。
レスポンスは、以下のいずれかの方法で生成されます。
-
仮想およびハードウェア MFA デバイスは、ユーザーがアプリケーションまたはデバイスで表示してサインイン画面に入力するコードを生成します。
-
U2F のセキュリティキーは、ユーザーがデバイスをタップするとレスポンスを生成します。ユーザーはサインイン画面に手動でコードを入力しません。
機密性の高いリソースまたは API オペレーションにアクセスできる特権を持つ IAM ユーザーには、U2F またはハードウェア MFA デバイスを使用することをお勧めします。
MFA の詳細については、「AWS での多要素認証 (MFA) の使用」を参照してください。
アクセスキーの MFA 保護 API アクセスを設定する方法については、「MFA 保護 API アクセスの設定」を参照してください。
Amazon EC2 インスタンスで実行するアプリケーションに対し、ロールを使用する
Amazon EC2 インスタンスで動作するアプリケーションは、AWS の他のサービスにアクセスするために認証情報が必要です。アプリケーションに認証情報を提供する安全な方法は、IAM ロールを使用することです。IAM ロールは独自のアクセス許可を持ったエンティティではありますが、ユーザーまたはユーザーグループではありません。また、IAM ユーザーが持っているような永続的な自身の認証情報は設定されていません。Amazon EC2 の場合、IAM は EC2 インスタンスに一時的な認証情報を動的に提供し、これらの認証情報は自動的に更新されます。
EC2 インスタンスの起動時に、起動パラメータとしてインスタンスのロールを特定することができます。EC2 インスタンスで作動するアプリケーションは、AWS リソースにアクセスする際に、ロールの認証情報を使用できます。アプリケーションに許可される操作は、ロールのアクセス許可で決定されます。
詳細については、「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する」を参照してください。
アクセスキーを共有しない
アクセスキーを使用すると、プログラムから AWS にアクセスできます。暗号化されていないコード内にアクセスキーを埋め込んだり、これらのセキュリティ認証情報を AWS アカウントのユーザー間で共有したりしないでください。AWS へのアクセスを必要とするアプリケーションの場合は、IAM ロールを使用して一時的セキュリティ認証情報を取得するようにプログラムを設定します。プログラムによるアクセスをユーザーに個別に許可するには、個人用のアクセスキーを持つ IAM ユーザーを作成します。
詳細については、「IAM ロール (AWS API) の切り替え」および「IAM ユーザーのアクセスキーの管理」を参照してください。
認証情報を定期的にローテーションする。
お客様自身のパスワードとアクセスキーを定期的に変更し、アカウント内のすべての IAM ユーザーにも変更を促してください。そうすることにより、知らない間にパスワードまたはアクセスキーが漏れた場合でも、その認証情報を使ってお客様のリソースにアクセスされる期間を制限できます。カスタムパスワードポリシーをアカウントに適用することで、すべての IAM ユーザーに AWS Management Console パスワードの変更を要求できます。更新する頻度を選択することも可能です。
アカウントのカスタムパスワードポリシーを設定する方法の詳細については、「IAM ユーザー用のアカウントパスワードポリシーの設定」をご参照ください。
IAM ユーザーのアクセスキーの更新については、「アクセスキーの更新」を参照してください。
不要な認証情報の削除
IAM ユーザーの不要な認証情報 (つまり、パスワードとアクセスキー) は削除します。たとえば、コンソールを使用しないアプリケーションで IAM ユーザーを作成した場合、 ユーザーにパスワードは必要ありません。同様に、ユーザーのみコンソールを使用する場合、他のユーザーのアクセスキーは削除します。最近使用されていないパスワードやアクセスキーは削除の対象となります。使用していないパスワードまたはアクセスキーを検索するには、CLI または API を使用するか、認証情報レポートをダウンロードします。
最近使用されていない ユーザーの認証情報を検索する方法については、「使用していない認証情報の検索」を参照してください。
IAM ユーザーのパスワードを削除する方法については、「IAM ユーザーのパスワードの管理」を参照してください。
ユーザーのアクセスキーを非アクティブ化または削除する方法については、「IAM ユーザーのアクセスキーの管理」を参照してください。
IAM 認証情報レポートの詳細については、「AWS アカウントの認証情報レポートの取得」を参照してください。
追加セキュリティに対するポリシー条件を使用する。
実行可能な範囲内で、どの IAM ポリシーがリソースにアクセスできるかという条件を定義します。例えば、要求が発生しなければならない許容 IP アドレスの範囲を指定するための条件を記述できます。また、指定した日付範囲または時間範囲内でのみリクエストが許可されるように指定することもできます。また、SSL または MFA (多要素認証) の使用を必要とする条件を設定することもできます。たとえば、Amazon EC2 インスタンスを終了できるようにするため、ユーザーに対し MFA デバイスの認証を要求することもできます。
詳細については、『IAM ポリシー要素の参照』の「IAM JSON ポリシー要素Condition」を参照してください。
AWS アカウントのアクティビティのモニタリング
AWS のロギング機能を使用すると、ユーザーがアカウントで実行したアクションや使用されたリソースを確認できます。ログファイルには、アクションの日時、アクションのソース IP、不適切なアクセス許可のために失敗したアクションなどが示されます。
ロギング機能は次の AWS サービスで使用できます。
-
Amazon CloudFront
— CloudFront が受信したユーザーリクエストを記録します。詳細については、Amazon CloudFront 開発者ガイドの「アクセスログ」を参照してください。 -
AWS CloudTrail
– ログ AWS アカウントに代わって行われた AWS API コールおよび関連イベント。詳細については、AWS CloudTrail ユーザーガイドを参照してください。 -
Amazon CloudWatch
は、AWS のクラウドリソースおよび AWS で実行しているアプリケーションをリアルタイムでモニタリングします。定義したメトリクスに基づいて、CloudWatch でアラームを設定できます。詳細については、Amazon CloudWatch ユーザーガイドを参照してください。 -
AWS Config
–IAM ユーザー、ユーザーグループ、ロール、およびポリシーを含む、AWS リソースの設定に関する詳細な履歴情報を提供します。たとえば、AWS Config を使用すると、特定の時刻にユーザーまたはユーザーグループに属していたアクセス許可を確認できます。詳細については、AWS Config開発者ガイドを参照してください。 -
Amazon Simple Storage Service (Amazon S3)
— Amazon S3 バケットへのアクセスリクエストを記録します。詳細については、Amazon Simple Storage Service ユーザーガイドの「Server Access Logging」を参照してください。