【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リソースは、アタッチされているポリシーが許可する範囲内でのみ操作を実行できます。ポリシーで許可されていない操作は実行できません。


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

【ユーザーの種類】
AWSで利用する代表的なユーザーには、「AWSアカウントのルートユーザー」と「IAMユーザー」があります。


■AWSアカウントのルートユーザー
AWSアカウントを作成すると、そのアカウントに対して最初に存在する特権ユーザーとして、AWSアカウントのルートユーザーが作成されます。ルートユーザーは、アカウント内のすべてのAWSサービスとリソースに対して完全なアクセス権限を持つため、非常に強力な権限を持つユーザーです。そのため、ルートユーザーは日常的な操作には使用せず、ルートユーザーのみに実行権限がある操作に限定して使用することがAWSのベストプラクティスで推奨されています。
以下はルートユーザーのみに実行権限がある操作の例です：
・AWSアカウントの解約
・ルートユーザーのアクセスキーの作成および管理
・S3バケットに対するMFA Deleteの設定
・Organizationsで組織の作成

ルートユーザーの運用においては、強力なパスワードにするなど、厳格なセキュリティ対策が必要です。また、ルートユーザーのアクセスキーは、不正利用防止のため作成しないことが推奨されています。

■IAMユーザー
IAMユーザーは、AWSアカウント内で作成するユーザーです。IAMユーザーには、IAMポリシーを使用して必要な権限を付与できます。IAMユーザーは複数人で共有せず、利用者ごとに個別に作成します。
人間のユーザーがAWSへアクセスする方法には、IAMユーザーを使用する方法のほか、IAM Identity Center（複数のAWSアカウントやアプリケーションへのアクセスを一元管理するサービス）やIDプロバイダーとのフェデレーション（外部の認証システムと連携してAWSへアクセスする仕組み）を利用する方法もあります。IAM Identity Centerやフェデレーションを利用すると、一時的な認証情報を使用してAWSへアクセスできます。
AWSへのアクセス権限を付与する際は、利用する方法にかかわらず、最小権限の原則に基づいて必要な操作だけを許可します。最小権限の原則とは、ユーザーやプログラムが作業を遂行するために必要な最小限のアクセス権限を付与することです。

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

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


○SCP（サービスコントロールポリシー）
SCP（サービスコントロールポリシー）は、組織のルート、OU（Organizational Unit）、AWSアカウントに対して、AWSサービスへのアクセス権限や利用可能なリソースを制限できる機能です。例えば、特定のアカウントが利用できるサービスの制限や、利用可能なリージョンの制限ができます。

○一括請求
Organizations内の各AWSアカウントへの請求情報を一括にまとめることで、コストの一元管理ができます。各アカウントの利用量が合計されるので、組織全体に対してボリュームディスカウントが適用されます。また、管理アカウントで割引共有を有効化することで、メンバーアカウントが購入したリザーブドインスタンスやCompute Savings Plansの割引をOrganizations内のすべてのアカウントに適用できます。

■IAMグループ（複数のIAMユーザーの管理）
複数のIAMユーザーが所属するグループを「IAMグループ」といいます。IAMグループは、同一アカウント内の複数のIAMユーザーのアクセス権限をまとめて管理するために使用します。なお、IAMユーザーは複数のIAMグループに所属できますが、IAMグループは別のIAMグループに所属できないので、IAMグループを用いた階層的な権限管理は実現できません。


【認証情報】
AWSサービスへアクセスする際は、利用方法に応じてパスワード、アクセスキー、一時的なセキュリティ認証情報などを使用します。

○パスワード
パスワードは、主にマネジメントコンソールにサインインするときに使用します。ルートユーザーは、AWSアカウントの作成時に登録したメールアドレスとパスワードを使用してサインインします。IAMユーザーはアカウントIDまたはアカウントエイリアス、IAMユーザー名、パスワードを使用してサインインします。アカウントIDは、AWSアカウントを識別する12桁の番号です。アカウントエイリアスは、アカウントIDの代わりに使用できる覚えやすい名前です。IAMユーザー名は、AWSアカウント内で各IAMユーザーを識別するための名前です。

○アクセスキー
アクセスキーは、アクセスキーIDとシークレットアクセスキーで構成される認証情報です。AWS CLIやAWS SDKなどを使用して、AWSサービスにプログラムでアクセスするときに使用します。
アクセスキーは長期的な認証情報であるため、不要なアクセスキーは削除し、使用する場合も適切に管理する必要があります。可能な限りアクセスキーのような長期的な認証情報ではなく、IAMロールなどによる一時的なセキュリティ認証情報を使用することが推奨されています。やむを得ず使用する場合は、定期的にローテーション（更新）を行う必要があります。

○STSによる一時的なセキュリティ認証情報
AWS STS（AWS Security Token Service）は、一時的なセキュリティ認証情報を発行するサービスです。一時的なセキュリティ認証情報には有効期限があり、アクセスキーID、シークレットアクセスキー、セッショントークンで構成されます。IAMロールを引き受ける場合などに使用され、長期的なアクセスキーを保存せずにAWSリソースへアクセスできます。

【IAMロール】
IAMロールは、AWSサービス、アプリケーション、他のAWSアカウントなどに対して、AWSリソースへのアクセス権限を一時的に付与する際に利用します。IAMロール自体は長期的な認証情報を持たず、ロールを引き受けたエンティティ（AWSリソースへアクセスするユーザー、AWSサービス、アプリケーションなどの主体）に対して一時的なセキュリティ認証情報が発行されます。
IAMロールを作成する際は、まず信頼されたエンティティ（そのロールを引き受ける対象）を指定します。その後、そのエンティティに付与するアクセス権限を設定します。


■AWSサービスやアプリケーションに対してアクセス権限を付与
AWSリソースは、ユーザーからアクセスされるほか、AWSサービスやアプリケーションからもアクセスされます。例えば、EC2インスタンス上で実行されるアプリケーションがS3バケットにアクセスする場合、アクセスキーをアプリケーションコードや設定ファイルに直接保存する方法は、認証情報漏洩のリスクがあるため推奨されません。
このような場合は、EC2インスタンスにIAMロールを関連付け、アプリケーションが一時的なセキュリティ認証情報を使用してS3バケットへアクセスできるようにします。一時的なセキュリティ認証情報には有効期限があるため、長期的なアクセスキーを保存する場合と比べて、認証情報漏洩時のリスクを抑えられます。


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


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


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


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

AWS管理ポリシーでは必要な権限を付与できない場合に、カスタマー管理ポリシーを作成して使用します。
インラインポリシーは、特定のIAMユーザー、IAMグループ、IAMロールに直接埋め込むポリシーです。特定の対象に強く紐づくため、管理が煩雑になりやすく、通常はカスタマー管理ポリシーの利用が推奨されます。

○リソースベースのポリシー
リソースベースのポリシーは、S3バケットなど一部のAWSリソースに直接アタッチするポリシーです。リソース自体にアクセス制御を定義できます。

「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アカウントやパブリックからのアクセス許可が存在するかを検出し、可視化するツールです。これにより、意図しないアクセスによるセキュリティリスクを早期に発見でき、リソースやデータへの不正なアクセスを防ぐことができます。さらに、実際のアクセスログに基づいて、アプリケーションに必要な最小限の権限のみを付与するポリシーを自動生成したり、既存のポリシーが安全かつ適切に機能しているかを検証する機能も備えており、セキュリティと運用の効率化を実現できます。