【AWS IAM（Identity and Access Management）】
AWS IAM（Identity and Access Management）は、AWSリソースへのアクセスを管理するためのサービスです。IAMでは「誰が」「どのリソースに対して」「どの操作を許可または制限するか」を定義し、認証と認可のプロセスを提供します。適切なIAM設定と運用により、認証情報の漏洩による被害を最小限に抑えることや、ユーザー操作によるEC2インスタンスの誤削除などの事故を防ぐことが可能です。AWSはIAMの機能を無料で提供しています。
なお、AWSサービスとは「Amazon EC2」や「Amazon S3」などサービス自体のことを指し、AWSリソースとは「EC2インスタンス」や「S3バケット」などサービス内で動作するリソースのことを指します。

IAMでは、AWSリソースへのアクセス権限を「ポリシー」として定義します。ポリシーは、IAMユーザー（IAMグループ）やIAMロール、一部のAWSリソースにアタッチ（付与）やデタッチ（剥奪）が可能です。IAMユーザーやAWSリソースは、アタッチされているポリシーが許可する範囲内でのみ操作を実行できます。ポリシーで許可されていない操作は実行できません。


本項では、IAMの各機能について説明します：
・ユーザーの種類
・ユーザーの管理
・IAMロール
・ポリシー
・認証情報レポート
・AWS IAM Access Analyzer
・AWS Security Token Service（STS）

【ユーザーの種類】
AWSには「AWSアカウント（ルートユーザー）」「IAMユーザー」という2種類のユーザーがあります。


AWSアカウントやIAMユーザーは、AWSサービスへのアクセスに「ユーザー名とパスワード」または「アクセスキーとシークレットアクセスキー」を使用して認証します。これにより、AWSサービスへのアクセスをセキュアに保ち、適切な権限が与えられたユーザーのみがサービスを利用できるようになります。
○ユーザーIDとパスワード ... 任意のIDと自分で設定したパスワードを用いた認証方法です。マネジメントコンソールにログインするときに使用します。
○アクセスキーとシークレットアクセスキー ... AWSによって作成されるアクセスキーIDと、対になるシークレットアクセスキーを用いた認証方法です。AWS CLIやAWS SDKなどを使用してAWSサービスにプログラムでアクセスするときに使用します。アクセスキーとシークレットアクセスキーは、不正利用を防止するため定期的にローテーション（更新）することが推奨されています。
シークレットアクセスキーは作成したときにしか確認できません。そのためシークレットアクセスキーを紛失した場合は、アクセスキーとシークレットアクセスキーをローテーション（更新）します。その後、キーを利用していたプログラムなどに新しいアクセスキーとシークレットアクセスキーを組み込みます。

■AWSアカウント（ルートユーザー）
AWSアカウントは非常に強力な権限を持つので、日常的なAWSリソース操作にはIAMユーザーを使用し、極力AWSアカウントを使用しないことがAWSベストプラクティスで推奨されています。ただし、AWSアカウントでしか実施できない操作も存在するため、そのような操作が必要な場合には一時的にAWSアカウントを使用します。
以下はその一例です：
・AWSアカウントの解約
・AWSアカウントのアクセスキーの作成および管理
・S3バケットに対するMFA Deleteの設定
・Organizationsで組織の作成

AWSアカウントは可能な限り構築する環境（例えば本番環境、開発環境など）ごとに作成します。複数のアカウントで各環境のリソースを分離することで、管理対象のリソースを把握しやすくなり、リソース管理が効率化されます。また、ある環境でセキュリティ問題が発生しても、他の環境への影響を最小限に抑えられるため、全体的なセキュリティが向上します。

AWSアカウントの運用においては、強力なパスワードの使用や定期的なパスワード変更に加え、MFA（多要素認証※）を有効化するなど、厳格なセキュリティ対策が必要です。また、AWSアカウントのアクセスキーとシークレットアクセスキーは、不正利用防止のために無効化もしくは削除することが推奨されています。
（※）MFA（Multi-Factor Authentication：多要素認証）とは、ユーザーIDとパスワードでの認証の際に、追加でワンタイムパスワードや指紋などのバイオメトリクスを使用する認証方法です。MFAを有効にするには、MFAデバイスを入手してマネージメントコンソールもしくはAWS CLIでMFAデバイスをアクティブ化します。

■IAMユーザー
AWSリソースを操作する際は基本的にIAMユーザーで行います。IAMユーザーに適用するIAMポリシーには最小権限の原則を実装し、AWSリソースの使用に適切な認可をします。最小権限の原則とは、ユーザーやプログラムが作業を遂行するために必要な最小限のアクセス権限を付与することです。 IAMユーザーは複数人で共有せず、個々にIAMユーザーを作成します。

【ユーザーの管理】
AWSアカウントとIAMユーザーには、それぞれ複数のユーザーを一括して管理できる機能があります。

■複数のAWSアカウントの管理（AWS Organizations）
「AWS Organizations」は、複数のAWSアカウントを一元的に管理するためのサービスです。AWS Organizationsを使用することで、管理対象のAWSアカウントに対する権限の設定や、各アカウントの請求情報を集約した一括請求が利用できます。
AWS OrganizationsではOU（Organizational Units）を利用して、AWSアカウントを階層的な構造で整理・管理します。


〇サービスコントロールポリシー（SCP）
サービスコントロールポリシー（SCP）は、組織のルート、OU（Organizational Unit）、AWSアカウントに対して、AWSサービスへのアクセス権限や利用可能なリソースを制限できる機能です。例えば、組織に所属しているアカウントにMFA（多要素認証）を強制したり、特定のアカウントが利用できるサービスを制限したりできます。

〇一括請求
一括請求では複数のAWSアカウントにまたがった従量制割引が適用されます。例えば、購入したリザーブドインスタンス（RI）は、同じリージョン内・同じインスタンスファミリーであれば、Organizations内の他のアカウントでも割引を適用できます。RIは最初に購入アカウント内のインスタンスに適用され、その後、余ったRIの枠があれば、組織内の他のアカウントにも適用されます。

■複数のIAMユーザーの管理（IAMグループ）
複数のIAMユーザーが所属するグループを「IAMグループ」といいます。IAMグループは、同一アカウント内の複数のIAMユーザーのアクセス権限を一元的に管理できます。

個々のIAMユーザーに対してIAMポリシーを設定するのではなく、IAMグループを活用することで権限管理を効率的に行えます。AWSベストプラクティスでもIAMグループを活用することが推奨されており、不必要な権限の設定や権限不足によるミスを防ぐことができます。
なお、IAMユーザーは複数のIAMグループに所属できますが、IAMグループは別のIAMグループに所属できないので、IAMグループを用いた階層的な権限管理は実現できません。

【IAMロール】
IAMロールは、AWSサービスやアプリケーション、他のAWSアカウントに対してAWSリソースへのアクセス権限を付与する際に利用します。


■AWSサービスやアプリケーションに対してアクセス権限を付与
AWSリソースはユーザーからアクセスされる他、AWSサービスやアプリケーションからもアクセスされます。例えば、EC2インスタンス上で実行されるアプリケーションがS3バケットにアクセスする場合、通常はアクセスキーとシークレットアクセスキーを用いて認証が行われます。しかし、アプリケーションコードに認証情報を直接埋め込むことは、セキュリティリスクが高いため推奨されません。
IAMロールの使用により、このようなリスクを軽減できます。IAMロールは一時的なアクセスキーを生成・利用して認証を行い、アプリケーションはこの一時的なキーを用いてAWSリソースにアクセスします。生成されるアクセスキーは有効期限が設定されており、もし漏洩した場合でもリスクは比較的低く抑えられます。

EC2インスタンスにIAMロールを付与することにより、一時的なアクセスキーを使ってS3バケットへアクセスします。

■他のAWSアカウントに対してアクセス権限を付与
IAMロールでは「クロスアカウントアクセス」を利用することで、他のAWSアカウントにアクセス権限を付与できます。例えば、AWSリソースの保守を協力会社に委託したい場合、委託先のAWSアカウント内のIAMユーザーに対してIAMロールで権限を付与します。これにより、委託先は一時的なアクセスキーを使用してAWSリソースにアクセスできます。クロスアカウントアクセスで利用されるアクセスキーには有効期限が設定されているため、もし漏洩してもリスクは比較的低く抑えられます。


■Microsoft Active Directory（AD）との連携（IDフェデレーション）
IAＭロールとMicrosoft Active Directory（AD）の認証情報を連携することにより、ADの既存アカウントを利用してAWSリソースにアクセスできるようになります。IAMユーザーを個別に作成する必要がないので、認証情報の管理が簡潔になります。このようにAWSリソースへのアクセスに外部のIDプロバイダー（Microsoft Active Directory、Googleなど）の認証情報を使用する方法を「IDフェデレーション」といいます。


【ポリシー】
ポリシーは、AWSリソースへのアクセスに対する権限を定義したものです。ポリシーはJSON形式のテキストで定義され、ユーザーやグループ、ロール、AWSリソースに対して、必要なアクセス権限の付与や制限ができます。ポリシーを適切に設定することで、AWSリソースへのセキュアなアクセス制御を実現できます。


主なポリシーのタイプ
・IDベースのポリシー（IAMポリシー）... IAMユーザー、IAMグループ、IAMロールにアタッチするポリシー
・リソースベースのポリシー... AWSリソースにアタッチするポリシー

〇IDベースのポリシー（IAMポリシー）
IDベースのポリシーは、IAMユーザー、IAMグループ、IAMロールにアタッチするポリシーです。
IDベースのポリシーには以下の種類があります。

AWS管理ポリシーでは必要な権限を付与できない場合に、カスタマー管理ポリシーを作成して使用します。
インラインポリシーは特定の対象に限定したポリシーなので管理が煩雑になりやすく、AWSベストプラクティスでは推奨されていません。（後述のリソースベースのポリシーを除く）

〇リソースベースのポリシー
リソースベースのポリシーは、一部のAWSリソース（S3バケットなど）に対してアタッチするインラインポリシーです。例えば、S3のバケットポリシーがリソースベースのポリシーに該当し、S3バケットへのアクセスを特定のユーザーや特定のIPアドレスだけに許可する場合などに利用します。

「IDベースのポリシー（IAMポリシー）」と「リソースベースのポリシー」には次のような違いがあります。


■ポリシーは主に次の要素で構成されます。
・Effect：許可または拒否の指定
・Action：AWSリソースに対して実行できる操作（例：s3:PutObject）
・Resource：Actionの対象とするAWSリソース（例：特定のS3バケット）
・Principal：権限のリクエスト元（例：特定のIAMユーザー）
・Condition：ポリシーが適用される条件（例：特定のIPアドレス範囲からのアクセス）

[リソースベースのポリシーの記述例]


【認証情報レポート】
IAMの認証情報レポートとは、AWSアカウント内に存在するIAMユーザーの一覧と各種認証情報のステータスが出力されたCSVファイルのことです。認証情報レポートは、アカウントのセキュリティ状態を監査、検証、および改善する際に役立ちます。

IAMの認証情報レポートに出力される情報には、主に以下の項目があります。
・ユーザーが作成された日時
・パスワードが使用された直近の日時
・パスワードが更新された直近の日時
・多要素認証（MFA）が有効または無効
・アクセスキーが有効または無効
・アクセスキーが使用された直近の日時
・アクセスキーが更新された直近の日時

【AWS IAM Access Analyzer】
AWS IAM Access Analyzerは、AWSリソースに設定されたポリシー（例：S3バケットポリシーなど）を解析し、他のAWSアカウントやパブリックからのアクセス許可が存在するかを検出し、可視化するツールです。これにより、意図しないアクセスによるセキュリティリスクを早期に発見でき、リソースやデータへの不正なアクセスを防ぐことができます。さらに、実際のアクセスログに基づいて、アプリケーションに必要な最小限の権限のみを付与するポリシーを自動生成したり、既存のポリシーが安全かつ適切に機能しているかを検証する機能も備えており、セキュリティと運用の効率化を実現できます。

【AWS Security Token Service（STS）】
AWS Security Token Service（STS）は、AWSユーザーやアプリケーションに対して、AWSリソースへアクセスするための一時的なセキュリティ認証情報を発行するサービスです。認証情報には有効期限が設定されており、期限が切れると自動的に無効化されます。これによりセキュリティが強化され、認証情報の不正利用のリスクを低減できます。
STSは、複数アカウント間のクロスアカウントアクセスや、オンプレミスのLDAPディレクトリなど既存の認証基盤を利用したAWSへのアクセスなどに利用されます

[STSを使用したクロスアカウントアクセスの例]