IAM でのセキュリティのベストプラクティス

AWS のリソースを保護するには、AWS Identity and Access Management (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 ユーザーとの長期的な認証情報が必要な特定のユースケースがあります。ユースケースには次のようなものがあります。

ルートユーザーの認証情報を保護するためのベストプラクティスに沿う

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 ロールとユーザー) のアクセスを制御するための許可ガードレールを確立することをお勧めします Organizations リソースコントロールポリシー (RCP) を使用して、組織全体の AWS リソースについてのアクセスを制御する許可ガードレールを確立することをお勧めします。SCP と RCP は、AWS 組織、組織単位 (OU)、またはアカウントレベルで組織内の許可を管理するために使用できる組織ポリシーの一種です。

ただし、SCP と RCP だけでは、組織内のプリンシパルとリソースに許可を付与するには不十分です。SCP および RCP によって許可は付与されません。許可を付与するには、IAM ユーザー、IAM ロール、またはアカウント内のリソースに ID ベースまたはリソースベースのポリシーをアタッチする必要があります。詳細については、「SRA building blocks – AWS Organizations, accounts, and guardrails」を参照してください。

アクセス許可の境界を使用して、アカウント内のアクセス許可の管理を委任する

シナリオによっては、アカウント内のアクセス許可の管理を他の人に委任する場合があります。例えば、デベロッパーが自分のワークロードのロールを作成および管理できるようにすることができます。アクセス許可を他のユーザーに委任するときは、アクセス権限の境界を使用して、委任する権限の上限を設定します。アクセス許可の境界は、管理ポリシーを使用してアイデンティティベースのポリシーが IAM ロールに付与できるアクセス許可の上限を設定する高度な機能です。アクセス許可の境界自体は、アクセス許可を付与しません。詳細については、「IAM エンティティのアクセス許可境界」を参照してください。