IAM でのセキュリティのベストプラクティス
AWS のリソースを保護するには、AWS Identity and Access Management (IAM) を使用する際の以下のベストプラクティスに従ってください。
トピック
- 人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする
- ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする
- 多要素認証 (MFA) を必須とする
- 長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する
- ルートユーザーの認証情報を保護するためのベストプラクティスに沿う
- 最小特権アクセス許可を適用する
- AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する
- IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する
- 未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する
- IAM ポリシーで条件を指定して、アクセスをさらに制限する
- IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する
- IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する
- 複数のアカウントにまたがるアクセス許可のガードレールを確立する
- アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する
人間のユーザーが一時的な認証情報を使用して AWS にアクセスする場合に ID プロバイダーとのフェデレーションを使用することを必須とする
人間のユーザーとは、別名人間 ID と呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります。組織のメンバーである人間のユーザーは、ワークフォースアイデンティティとも呼ばれます。人間のユーザーには、あなたと共同作業を行う外部ユーザーや、あなたの AWS のリソースを操作する外部ユーザーも含まれます。この操作は、ウェブブラウザ、クライアントアプリケーション、モバイルアプリ、またはインタラクティブなコマンドラインツールを介して実行できます。
人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用が必要です。一時的な資格情報を提供するロールを引き受けることで、人間のユーザーの ID プロバイダーを使用した AWS アカウント へのフェデレーションアクセスが可能になります。一元的なアクセス管理を行うには、AWS IAM Identity Center (IAM Identity Center) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。ユーザー ID を、IAM Identity Center を使用して管理することも、外部 ID プロバイダーから、IAM Identity Center 内のユーザー ID に付与するアクセス許可を管理することもできます。詳細については、AWS IAM Identity Center ユーザーガイドの AWS IAM Identity Center とは を参照してください。
ロールの詳細については、「ロールに関する用語と概念」をご参照ください。
ワークロードが AWS にアクセスする場合に IAM ロールで一時的な資格情報を使用することを必須とする
ワークロードとは、アプリケーションやバックエンドプロセスなど、ビジネス価値を提供するリソースやコードの集合体のことです。ワークロードには、AWS のサービス へのリクエスト (データの読み取りリクエストなど) を行うために ID を必要とするアプリケーション、運用ツール、コンポーネントが含まれている場合があります。これらの ID には、Amazon EC2 インスタンスや AWS Lambda 関数などの AWS 環境で実行中のマシンが含まれます。
また、アクセスを必要とする外部の関係者のマシン ID を管理することもできます。マシン ID へのアクセスを許可するには、IAM ロールを使用できます。IAM ロールは特定のアクセス許可を持ち、ロールセッションで一時的なセキュリティ認証情報に依存することで AWS にアクセスする方法を提供します。さらに、AWS 環境にアクセスする必要がある AWS の外部のマシンが含まれる場合もあります。AWS の外部で実行されるマシンには、AWS Identity and Access Management Roles Anywhere.を使用できます。ロールの詳細については、「IAM ロール」をご参照ください。ロールを使用して AWS アカウント へのアクセス許可を委任する方法については「IAM チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任」を参照してください。
多要素認証 (MFA) を必須とする
AWS リソースにアクセスする人間のユーザーとワークロードの IAM ロールを使用して、一時的な認証情報を使用することをお勧めします。ただし、アカウントに IAM ユーザー またはルートユーザーが必要なシナリオでは、セキュリティを強化するために MFA が必要になります。MFA では、ユーザーは認証チャレンジに対するレスポンスを生成するデバイスを所有します。サインインプロセスを完了するには、各ユーザーの認証情報とデバイス生成のレスポンスの両方が必要です。詳細については、IAM の AWS 多要素認証 を参照してください。
IAM Identity Center を使用して人間のユーザーによるアクセスを一元的に管理する場合、ID ソースが IAM Identity Center の ID ストア、AWS 管理の Managed Microsoft AD、または AD Connector で設定されていれば、 IAM Identity Center の MFA 機能を使用することができます。IAM Identity Center での MFA の詳細については、「AWS IAM Identity Center ユーザーガイド」の「Multi-factor authentication」(多要素認証) を参照してください。
長期的な認証情報を必要とするユースケースのためにアクセスキーを必要な時に更新する
可能であれば、アクセスキーなどの長期的な認証情報を作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、プログラムによるアクセスと長期的な認証情報を持つ IAM ユーザーが必要なシナリオでは、従業員が退職したときなど、必要に応じてアクセスキーを更新することをお勧めします。IAM アクセス最終使用者情報を利用して、アクセスキーを安全に更新して削除することをお勧めします。詳細については、「アクセスキーを更新する」を参照してください。
AWS の IAM ユーザーとの長期的な認証情報が必要な特定のユースケースがあります。ユースケースには次のようなものがあります。
-
IAM ロールを使用できないワークロード – AWS へのアクセスが必要な場所から、ワークロードを実行する場合があります。状況によっては、IAM ロールを使用して WordPress プラグインなどに対して一時的な認証情報を提供することができない場合もあります。このような状況では、そのワークロードに対して IAM ユーザーの長期的なアクセスキーを使用して、AWS への認証を行います。
-
サードパーティー AWS クライアント – IAM Identity Center を使用したアクセスがサポートされていないツール (AWS でホストされていないサードパーティー AWS クライアントまたはベンダーなど) を使用している場合 は、IAM ユーザーの長期的なアクセスキーを使用します。
-
AWS CodeCommit アクセス — CodeCommit を使用してコードを保存している場合、CodeCommit の SSH キーまたはサービス固有の認証情報を持つ IAM ユーザーを使用して、リポジトリへの認証を行うことができます。通常の認証に IAM Identity Center のユーザーを使用することに加えて、これを行うことをお勧めします。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。IAM ユーザーを設定せずに CodeCommit リポジトリへのアクセス許可をユーザーに付与するには、git-remote-codecommit ユーティリティを設定します。IAM および CodeCommit の詳細については、「CodeCommit の IAM 認証情報: Git 認証情報、SSH キー、および AWS アクセス キー」を参照してください。git-remote-codecommit ユーティリティの設定についての詳細は、「AWS CodeCommit ユーザーガイド」の「認証情報のローテーションを使用した AWS CodeCommit リポジトリへの接続」を参照してください。
-
Amazon Keyspaces (Apache Cassandra 向け) へのアクセス – IAM Identity Center 内のユーザーを使用できない状況 (Cassandra との互換性をテストする場合など) では、サービス専用の認証情報を持つ IAM ユーザーを使用して Amazon Keyspaces で認証できます。IAM Identity Center のユーザーとは、お客様の AWS アカウント またはクラウドアプリケーションにアクセスする必要がある従業員のことです。一時的な認証情報を使用して Amazon Keyspaces に接続することもできます。詳細については、「Amazon Keyspaces (Apache Cassandra 向け) デベロッパーガイド」の「Using temporary credentials to connect to Amazon Keyspaces using an IAM role and the SigV4 plugin」(一時的な認証情報を使用して IAM ロールと SigV4 プラグインを使用して Amazon Keyspaces に接続する) を参照してください。
ルートユーザーの認証情報を保護するためのベストプラクティスに沿う
AWS アカウント を作成すると、AWS Management Console にサインするためのルートユーザーの認証情報が設定されます。他の機密性の高い個人情報を保護するのと同じ方法で、ルートユーザーの認証情報を保護します。ルートユーザープロセスを保護してスケールする方法の詳細については、「AWS アカウントのルートユーザーのベストプラクティス」を参照してください。
最小特権アクセス許可を適用する
IAM ポリシーでアクセス許可を設定するときは、タスクの実行に必要なアクセス許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。その際、ワークロードやユースケースに必要なアクセス許可を検討しながら、大まかなアクセス許可から始めるとよいでしょう。ユースケースが成熟してきたら、最小特権になるように付与する権限を減らしていくことができます。IAM を使用してアクセス許可を適用する方法については、「AWS Identity and Access Management でのポリシーとアクセス許可」を参照してください。
AWS 管理ポリシーの使用を開始し、最小特権のアクセス許可に移行する
ユーザーやワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースに対してアクセス許可を付与する AWS マネージドポリシーを使用します。これらは AWS アカウント で使用できます。AWS 管理ポリシーは、すべての AWS のユーザーが使用できるため、特定のユースケースに対して最小特権のアクセス許可が付与されない場合があることに留意してください。そのため、ユースケースに応じたカスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、「AWS マネージドポリシー」を参照してください。特定のジョブ機能用に設計された AWS 管理ポリシーの詳細については、AWSジョブ機能の 管理ポリシー を参照してください。
IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する
タスクの実行に必要なアクセス許可のみを付与するには、AWS CloudTrail にログインしているアクセスアクティビティに基づいてポリシーを生成することができます。IAM Access Analyzer は、IAM ロールが使用するサービスとアクションを分析し、使用可能な詳細なポリシーを生成します。生成された各ポリシーをテストしたら、ポリシーを本番環境にデプロイできます。これにより、ワークロードに必要なアクセス許可のみが付与されます。ポリシー生成の詳細については、「IAM Access Analyzer ポリシーの生成」を参照してください。
未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除する
AWS アカウント には、必要なくなった IAM ユーザー、ロール、アクセス許可、ポリシー、または認証情報がある可能性があります。IAM から提供される最後にアクセスした情報をもとに、この情報から不要になったユーザー、ロール、アクセス許可、ポリシー、および認証情報を特定し、削除できます。これにより、監視する必要のあるユーザー、ロール、アクセス許可、ポリシー、および認証情報の数を減らすことができます。この情報をもとに、最小特権のアクセス許可により適切に準拠できるように IAM ポリシーを調整することもできます。詳細については、「最終アクセス情報を使用して AWS のアクセス許可を調整する」を参照してください。
IAM ポリシーで条件を指定して、アクセスをさらに制限する
ポリシーステートメントが有効になる条件を指定することができます。これにより、アクションやリソースへのアクセスを許可することができますが、これは、アクセスのリクエストが特定の条件を満たしている場合に限られます。例えば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定することができます。また、条件を使用してサービスアクションへのアクセスを許可することもできますが、これは、AWS CloudFormation などの特定の AWS のサービス を介して使用する場合に限られます。詳細については、「IAM JSON ポリシー要素Condition」を参照してください。
IAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認する
AWS でパブリックアクセスまたはクロスアカウントアクセスのアクセス許可を付与する前に、そのアクセス許可が必要かどうかを確認することをお勧めします。IAM Access Analyzer を使用すると、サポートされているリソースタイプのパブリックアクセスとクロスアカウントアクセスをプレビューおよび分析できます。これを行うには、IAM Access Analyzer が生成する調査結果を確認します。これらの調査結果から、リソースアクセス制御が期待した通りにアクセスを許可しているかどうかを確認できます。さらに、パブリックおよびクロスアカウントのアクセス許可を更新すると、リソースに新しいアクセス制御をデプロイする前に、変更の効果を検証できます。また、IAM Access Analyzer は、サポートされているリソースタイプを継続的に監視し、パブリックアクセスまたはクロスアカウントアクセスを許可するリソースの調査結果を生成します。詳細については、「Previewing access with IAM Access Analyzer APIs」(IAM Access Analyzer API を使用したアクセスのプレビュー) を参照してください。
IAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する
作成したポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) と IAM のベストプラクティスに準拠していることを確認します。IAM Access Analyzer ポリシーチェックを使用して、ポリシーを検証できます。IAM Access Analyzer は 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーを作成できるようサポートします。コンソールで新しいポリシーをの作成や、既存のポリシーの編集を行う際に、IAM Access Analyzer は、ポリシーが保存される前にポリシーを調整して検証するのに役立つ推奨事項を提供します。既存のポリシーをすべて見直し、検証することをお勧めします。詳細については、「IAM Access Analyzer ポリシーの検証」を参照してください。IAM Access Analyzer が提供するポリシーチェックの詳細については、「IAM Access Analyzer ポリシーチェックリファレンス」を参照してください。
複数のアカウントにまたがるアクセス許可のガードレールを確立する
ワークロードをスケールするときは、AWS Organizations で管理されている複数のアカウントを使用してワークロードを分離します。Organizations のサービスコントロールポリシー (SCP) を使用して、アカウント全体のすべてのIAMユーザーとロールのアクセスを制御するためのアクセス許可ガードレールを確立することをお勧めします SCP は組織ポリシーの一種で、AWS 組織、OU、またはアカウントレベルで組織内のアクセス許可を管理するために使用することができます。確立したアクセス許可のガードレールは、対象となるアカウント内のすべてのユーザーとロールに適用されます。しかし、組織のアカウントにアクセス許可を付与するには、SCP だけでは不十分です。管理者は、アイデンティティベースのポリシーまたはリソースベースのポリシーを IAM ユーザー、IAM ロール、またはアカウント内のリソースにアタッチする必要があります。詳細については、「AWS Organizations、アカウント、および IAM ガードレール」を参照してください。
アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する
シナリオによっては、アカウント内のアクセス許可の管理を他の人に委任する場合があります。例えば、デベロッパーが自分のワークロードのロールを作成および管理できるようにすることができます。アクセス許可を他のユーザーに委任するときは、アクセス権限の境界を使用して、委任する権限の上限を設定します。アクセス許可の境界は、管理ポリシーを使用してアイデンティティベースのポリシーが IAM ロールに付与できるアクセス許可の上限を設定する高度な機能です。アクセス許可の境界自体は、アクセス許可を付与しません。詳細については、「IAM エンティティのアクセス許可境界」を参照してください。