参考

【AWS IAM（Identity and Access Management）】
AWS IAMとは、AWSにおいて「どのユーザーが」「どのAWSリソースに対して」「どのような操作ができるか（できないか）」を定義する、「認証」「認可」の仕組みを提供するサービスです。IAMを適切に運用することにより、例えばユーザーの操作ミスによりEC2インスタンスを削除してしまう事故を防げたり、アカウントが乗っ取られた際の影響を限定することができます。AWSではIAMの機能を無料で提供しています。

以下はIAMの概要です。

IAMでは、AWSのリソースに対する権限を「IAMポリシー」として定義します。定義したIAMポリシーは、「IAMユーザー（IAMグループ）」やAWSリソースに対してアタッチ（付与）・デタッチ（剥奪）することができます。IAMユーザーやAWSリソースはアタッチされているIAMポリシーの範囲で操作を行うことができ、IAMポリシーによって許可されていない操作は実行できません。

本項では、IAMの以下の機能について解説します：
・アカウントの種類（AWSアカウント、IAMユーザー、IAMグループなど）
・IAMロール
・IAMポリシー

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


これらのユーザーは「ユーザーIDとパスワード」または「アクセスキーとシークレットアクセスキー」を用いて認証することで、WebやコマンドなどからAWSリソースへアクセスします。
○ユーザーIDとパスワード ... 任意のIDと自分で設定したパスワードを用いた認証方法。マネジメントコンソールにログインする際に使用する。
○アクセスキーとシークレットアクセスキー ... AWSによって作成されるアクセスキーID（例：AKIA3MQXZYKOAYRZ33OR）と、対になるシークレットアクセスキーを用いた認証方法。AWS CLIやAWS APIからAWSリソースにアクセスする際に使用する。

AWSアカウントは非常に強力な権限を持つため、AWSではAWSアカウントを極力使用しないことを推奨しています。AWSアカウントの運用は、強力なパスワードの採用や定期的なパスワード変更に加えてMFA（多要素認証）を有効にするなど、厳重なセキュリティ対策を取る必要があります。
なお、多要素認証とは、パスワードやアクセスキーによる認証に加えて認証コードやワンタイムパスワードなどの複数の要素を使う認証方式です。AWSでは、AWSアカウントのほかIAMユーザーにも多要素認証を有効にできます。
また、AWSアカウントはIAMユーザーに対するパスワードポリシーも設定できます。パスワードポリシーとは、パスワードの文字列長や大文字・数字・記号を含むか、パスワードの有効期限などの設定のことで、IAMユーザーをセキュアに運用するために使用します。ただし、IAMユーザーに対するパスワードポリシーはAWSアカウントには適用されません。

■複数のAWSアカウントの管理（AWS Organizations）
複数のAWSアカウントをまとめて管理する機能に「AWS Organizations」があります。AWS Organizationsでは、管理するAWSアカウントに対して権限を設定したり、管理するAWSアカウントへの請求情報をひとまとめにすることができます。
Organizationsでは複数の組織を階層構造で管理します。


Organizationsに属している個々のアカウントや組織（OU）に対して、利用できるAWSサービスやアクションを制限する「サービスコントロールポリシー（Service Control Policy：SCP）」を設定することもできます。SCPを用いると、例えばテスト用のアカウント（群）は特定のサービスにしかアクセスできないようにしたり、全てのアカウントに対してMFA（多要素認証）を強制するように設定することなどができます。

■IAMグループ
IAMグループは複数のIAMユーザーをまとめたもののことです。複数のIAMユーザーに対してまとめてアクセス制御を行う際に使用します。

個別のユーザーに一つ一つポリシーを設定すると、不要な権限を設定してしまったり必要な権限が不足しているなどのミスが発生しやすいですが、IAMグループを使用することにより組織的に権限の設定ができるようになります。
ただし、グループにグループを所属させることはできませんので、IAMグループを使った階層的な管理はできません。

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


AWSのリソースはユーザーが利用するものだけではなく、AWSサービスやアプリケーションが使用するものもあります。例えばEC2インスタンス上で動作するアプリケーションがS3バケットを利用する場合、アプリケーションはアクセスキーおよびシークレットアクセスキーを使用して認証したのちにS3バケットへアクセスします。しかしアプリケーションプログラムに認証情報を埋め込むのはセキュリティリスクが高く危険です。
IAMロールを使用すると、このようなリスクを回避できます。IAMロールでは一時的なアクセスキーを生成・使用することにより認証します。生成したアクセスキーは短時間で使用できなくなるため、漏洩してもリスクは高くありません。

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

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

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

【IAMポリシー】
IAMポリシーとはAWSリソースに対する権限を定義したものです。Resource（どのAWSリソースに対して）、Action（どのAWSサービスのどの操作を）、Effect（許可または拒否）の3つの要素で定義します。
例えば「S3バケットMyBucketに対する書き込み・読み込みを許可する」というIAMポリシーを作成しIAMユーザーにアタッチすることで、対象のユーザーはMyBucketのオブジェクトを読み書きできるようになります。一方、許可されていない削除等のアクションは実行できません。

以下は実際にIAMポリシーを定義する際の画面の例です。

さらに、ポリシーを適用する条件（送信元IPアドレスの指定など）も加えることができます。

IAMポリシーには「アイデンティティ（ユーザー）ベースのポリシー」と「リソースベースのポリシー」があります。
アイデンティティベースのポリシーは、IAMユーザー、IAMグループ、IAMロールにアタッチするポリシーのことをいいます。
アイデンティティベースのポリシーには以下の種類があります。


それぞれのポリシーには以下のような違いがあります。


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

■インラインポリシーの記述例
IAMポリシーはマネジメントコンソールのビジュアルエディタのほか、JSON形式で定義することもできます。以下はJSON形式の定義例です。

Effect、Action、Resource ごとに、複数ある場合は "[]" のブロックで指定します。また、任意の値を示す場合は「*（アスタリスク）」で指定することができます。全てのリソースを対象にする場合は「"Resource":"*"」とすることや、あらゆる書き込みアクションを指定したい場合は「PutObject*」とすることも可能です（「PutObject」のほか、「PutObjectAcl」「PutObjectTagging」なども含まれます）。
以下は代表的なアクションの例です。
・Amazon EC2

・Amazon S3


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

リージョンやアカウントは省略できます。また、階層表示が可能なリソースはスラッシュ（/）で区切って指定します。上図のS3バケットの例の「bucket-pingt/*」は、バケット配下の任意のオブジェクトを意味します。

■Permissions Boundary（アクセス許可境界）
IAMでは、IAMユーザーやIAMロールに対して「ここまでの範囲内であれば自由に操作を行える」という境界を設定できます。これを「Permissions Boundary（アクセス許可境界）」と呼びます。アクセス許可境界が設定されたユーザーは、境界で許可された範囲とIAMポリシーの両方で許可されている範囲でアクションを行えます。


アクセス許可境界は、例えばLambda関数の作成をしている開発者に対して、必要なリソースへのアクセス権は都度自由に設定できるようにしておきたいが、開発者自身のアクセス権を操作させたくないようなケースで有用です。開発者にある程度の権限を与えておくことにより、アクセス権が必要になった際にいちいち管理者が対応する必要がなくなります。一方、権限を超えた操作をしないようにアクセス許可境界を設定しておけば、セキュリティリスクも抑えられます。