IAM でのセキュリティのベストプラクティス - AWS Identity and Access Management
人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには、ID プロバイダーとのフェデレーションの使用が必要ですAWS にアクセスするには、ワークロードが IAM ロールを使用して一時的な資格情報を使用する必要があります多要素認証 (MFA) が必要です長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションするルートユーザーの認証情報を保護し、日常的なタスクには使用しない最小特権アクセス許可を適用するAWS 管理ポリシーの開始と最小特権のアクセス許可への移行IAM Access Analyzer を使用して、アクセスアクティビティに基づいて最小特権ポリシーを生成する未使用のユーザー、ロール、アクセス許可、ポリシー、および認証情報を定期的に確認して削除するIAM ポリシーで条件を指定して、アクセスをさらに制限するIAM Access Analyzer を使用して、リソースへのパブリックアクセスおよびクロスアカウントアクセスを確認するIAM Access Analyzer を使用して IAM ポリシーを検証し、安全で機能的なアクセス許可を確保する複数のアカウントにまたがるアクセス許可のガードレールを確立するアクセス権限の境界を使用して、アカウント内のアクセス許可の管理を委任します。

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

AWS Identity and Access Management ベストプラクティスは 2022 年 7 月 14 日に更新されました。

AWS のリソースを保護するには、AWS Identity and Access Management (IAM) を使用する際の以下のベストプラクティスに従ってください。

トピック

人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには、ID プロバイダーとのフェデレーションの使用が必要です

人間のユーザーとは、別名人間 ID と呼ばれ、人、管理者、デベロッパー、オペレーター、およびアプリケーションのコンシューマーを指します。人間のユーザーは AWS の環境とアプリケーションにアクセスするための ID を持っている必要があります。組織のメンバーである人間のユーザーは、ワークフォースアイデンティティとも呼ばれます。人間のユーザーには、あなたと共同作業を行う外部ユーザーや、あなたの AWS のリソースを操作する外部ユーザーも含まれます。この操作は、ウェブブラウザ、クライアントアプリケーション、モバイルアプリ、またはインタラクティブなコマンドラインツールを介して実行できます。

人間のユーザーが AWS にアクセスする際は、一時的な認証情報の使用が必要です。一時的な資格情報を提供するロールを引き受けることで、人間のユーザーの ID プロバイダーを使用した AWS アカウントへのフェデレーションアクセスが可能になります。一元的なアクセス管理を行うには、AWS IAM Identity Center (successor to AWS Single Sign-On) (IAM Identity Center) を使用して、ご自分のアカウントへのアクセスと、それらのアカウント内でのアクセス許可を管理することをお勧めします。ユーザー ID を、IAM Identity Center を使用して管理することも、外部 ID プロバイダーから、IAM Identity Center 内のユーザー ID に付与するアクセス許可を管理することもできます。詳細については、AWS IAM Identity Center (successor to AWS Single Sign-On) ユーザーガイドの「AWS IAM Identity Center (successor to AWS Single Sign-On) とは?」を参照してください。

ロールの詳細については、「ロールに関する用語と概念」をご参照ください。

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 では、ユーザーは認証チャレンジに対するレスポンスを生成するデバイスを所有します。サインインプロセスを完了するには、各ユーザーの認証情報とデバイス生成のレスポンスの両方が必要です。詳細については、AWS での多要素認証 (MFA) の使用 を参照してください。

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 (successor to AWS Single Sign-On) ユーザーガイド」の「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 ユーザーガイド」の「Connecting to AWS CodeCommit repositories with rotating credentials」(認証情報のローテーションを使用した 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 にサインするためのルートユーザー名とパスワードが設定されます。他の機密性の高い個人情報を保護するのと同じ方法で、ルートユーザーの認証情報を保護します。これを行うには、ルートユーザーの認証情報に MFA を設定します。ルートユーザーのアクセスキーを作成すると、請求情報を含むを含むすべての AWS のサービス のリソースへのフルアクセスが可能になるため、お勧めしません。ルートユーザーを日常的なタスクに使用しないでください。ルートユーザーは、ルートユーザーのみが実行できるタスクに使用します。これらのタスクの完全なリストについては、「AWS 全般のリファレンス」の「ルートユーザー認証情報が必要なタスク」を参照してください。詳細については、「AWS Account Management ユーザーガイド」の「Best practices to protect your account's root user」(アカウントのルートユーザーを保護するためのベストプラクティス) を参照してください。

最小特権アクセス許可を適用する

IAM ポリシーでアクセス許可を設定するときは、タスクの実行に必要なアクセス許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。その際、ワークロードやユースケースに必要なアクセス許可を検討しながら、大まかなアクセス許可から始めるとよいでしょう。ユースケースが成熟してきたら、最小特権になるように付与する権限を減らしていくことができます。IAM を使用してアクセス許可を適用する方法については、「IAM でのポリシーとアクセス許可」を参照してください。

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, accounts, and IAM guardrails」(AWS Organizations、アカウント、および IAM ガードレール) を参照してください。

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

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