【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の機能について説明します：
・ユーザーの種類（AWSアカウント、IAMユーザー）
・IAMロール
・ポリシー

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

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

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

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

【IAMロール】
IAMロールは、AWSサービスやアプリケーション、他のAWSアカウントに対してAWSリソースへのアクセス権限を付与する際に利用します。
IAMロールを作成する際に、信頼されたエンティティとして、まず権限を付与する対象を指定します。その後、そのエンティティに付与するアクセス権限を設定します。


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

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

・インスタンスプロファイル
マネジメントコンソールからEC2のIAMロールを作成すると、「インスタンスプロファイル」が自動的に作成されます。インスタンスプロファイルとはIAMロールを格納する入れ物のようなもので、EC2インスタンスは起動時にインスタンスプロファイルを読み込み、設定されたIAMロールの権限で動作します。

マネジメントコンソールでIAMロールを作成した場合は同名のインスタンスプロファイルが作成されるため、通常は意識する必要はありません。AWS CLIなどからEC2のIAMロールを作成する場合は、「インスタンスプロファイルを作成し、作成したIAMロールをインスタンスプロファイルへアタッチ（格納）する」という作業が必要になります。

【ポリシー】
ポリシーは、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アドレス範囲からのアクセス）

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

Effect、Action、Resource ごとに、複数ある場合は "[]" のブロックで指定します。また、任意の値を示す場合は「*（アスタリスク）」で指定できます。上の図の「bucket-pingt/*」は「bucket-pingt」バケット配下の全てのオブジェクトが対象となります。全てのリソースを対象にする場合は「"Resource":"*"」と指定し、あらゆる書き込みアクションを指定したい場合は「PutObject*」と指定します。（「PutObject」に加えて「PutObjectAcl」「PutObjectTagging」なども含むようになります）

下記は代表的なアクションの例です。
・Amazon EC2

・Amazon S3


Resourceの記述はARN（Amazon Resource Name）形式で記述します。

階層表示が可能なリソースはスラッシュ（/）で区切って指定します（例：S3バケットの場合「bucket/folder/file」など）。また、S3バケット名などグローバルに一意なリソースは、リージョンやアカウントIDを省略できます。

Conditionは必須の要素ではありませんが、使用することでポリシーを適用する条件を指定できます。Conditionは下記の形式で記述します。


以下は代表的な条件の例です。


■Permissions Boundary（アクセス許可境界）
Permissions Boundary（アクセス許可境界）は、IAMユーザーやIAMロールの操作可能範囲を限定し、「指定された範囲内でのみ操作が可能」という制約を設ける機能です。この制約により、設定された範囲とIAMポリシーによって許可されたアクションのみが実行可能となります。


Permissions Boundaryの使用例として、開発者がEC2インスタンス上のアプリケーションに関わる作業を行う際には、必要なリソースへのアクセス権を柔軟に設定できるようにしたい場合があります。一方で、開発者が自身のアクセス権を変更することは望ましくありません。Permissions Boundaryを適用することで、開発者に必要な作業権限は与えつつも、組織のセキュリティポリシーに反する権限の乱用を防止できます。これにより、管理者の介入なしに開発者が作業を進められると同時に、セキュリティリスクも抑えられます。