IAMとは
「ユーザーに対してAWSのアクセスを制御する仕組み」のことです。
※CloudFrontやRoute 53と同様、グローバルサービスなのでリージョンを気にする必要がありません。
IAM初回利用時の流れ
IAMユーザー / IAMグループの登録
ルートユーザーを使用し最初のIAMユーザーを作成します。
IAMユーザーはユーザーまたはアプリケーションの実体で、構成要素は「名前」「認証情報(コンソールPW, アクセスキー)」です。
※ここで作成したアクセスキーは共有してはいけません。もしセキュリティの侵害があった場合、IAMユーザーの削除 / PW変更などを行います。
このIAMユーザーやIAMグループ（IAMユーザーの集合）を用いることで、実際にユーザーがAWSサービスを利用することができます。
IAMポリシーで権限を付与
IAMユーザーやIAMグループは作成直後には権限が付与されていないため、IAMポリシーをAWSリソースへ関連付ける必要があります。
IAMポリシーでIAMユーザーに直接権限を付与することも可能ですが、人数が多い場合にはIAMグループを利用して一元的に管理すると楽です。
※IAMユーザーが所属できるグループは最大10個です。
[例] ①ユーザーがIAMユーザーでログイン→②IAMポリシーでアクセス権を確認→③AWSの各種サービスへアクセス (S3など)
※こちらのIAMポリシーでは、AWSアカウント（id: 123456789012）のIAMユーザー（yonaha）以外の操作を拒否しています。具体的な対象は、S3バケット（exture-test-buketおよびその配下）に対するすべての操作です。
許可と拒否
IAMユーザーではデフォルトだと何も許可されていません。
そのためIAMポリシーで明示的に許可を設定しない限り、すべての操作が拒否されます。(暗示的な拒否)
上で示したようにIAMポリシーのJSONファイルで明示的に許可/拒否を記述することで、ユーザーは対象の操作を行えるようになるというわけです。(明示的な許可/拒否)
IAMポリシーの権限の優先度：
「明示的な拒否 > 明示的な許可 > 暗示的な拒否」
（つまり、権限を付与するには明示的に許可する必要がありますが、他のポリシーで明示的に拒否されているとその操作は行えません）
IAMポリシーの種類
AWS管理ポリシー
AWSで事前に定義されたポリシーのテンプレート群です。
代表的なものとしてはAdministratorAccess（すべてのアクセス権を提供）, PowerUserAccess（IAM以外のアクセス権を提供）などが挙げられ、ユーザーはこのようなポリシーを選択するだけで利用できます。
カスタマー管理ポリシー
ユーザー自身が作成・カスタマイズできるポリシーです。
AWS管理ポリシーでは自社のセキュリティ要件を満たせない場合などに使われます。
インラインポリシー
IAMユーザー / IAMグループ / IAMロールに埋め込まれているポリシーに対し、個別に設定を反映させるポリシーです。
※インラインポリシーは複数のIAMユーザー / IAMグループ間で共有できません。
IAMによる認証方式
IAMユーザー名とPW
ブラウザのAWSマネジメントコンソールからIAMを利用するために、IAMユーザー名とPWを利用するという方式です。
MFA(多要素認証)
前述したIAMユーザー名とPWに加えて、MFAデバイスなどで認証コードを利用するという方式です。
IAMロール
AWSサービスなどに対して操作権限を付与する仕組みです。
IAMユーザーやIAMグループとは紐付いておらず、IAMポリシーからIAMロールへ直接権限を付与します。
IAMロールは各種サービス (EC2やLambdaなど) に紐づけるもので、ユーザーには直接紐付けされません。
[例] ①EC2インスタンスにIAMロールを直接割りあてる→②EC2インスタンス上で稼働するアプリからAWS SDK経由で操作できるようになる
（EC2からS3への読み書きを許可, LambdaからDynamoDBへの書き込みを許可など）
キーペア
キーペア（アクセスキーIDとシークレットアクセスキー）を使って認証する方式です。
前述したAWS CLIやAWS SDKなどで利用されますが、キー流出によるリスクがあることから現在は推奨されていません。
現在はキーペアの代わりに「IAMロールを使用する」という方法が推奨されています。
IAMでAWSを操作する３つの方法
ブラウザからAWSマネジメントコンソールにログイン
IAMユーザーのユーザー名とPWを用いてブラウザからログインする方法です。
AWS CLIでWindowsやLinuxからログイン
操作先のリージョンやIAMユーザーごとに作成できる「アクセスキーID」「シークレットアクセスキー」を事前に作成し、ログインする方法です。
AWS SDKでプログラムからAPIを利用
例えばJavaのようなプログラムからAWS SDKでAPIを指定し、AWSの各種サービスを利用するという方法です。
SDKでAPIを利用する場合、前述したAWS CLI同様２つのキーペアによる認証が必要となります。
ただセキュリティの観点では、キーペアではなくIAMロールを利用する方が良いでしょう。
IAMによるIDフェデレーション（SSO）
IAMと組織で利用されている認証の仕組みと連携させるという方式です。
IDフェデレーションでSSO機能を利用することで、IAMで全員分の認証情報を登録するという手間を省け、楽にAWSサービスを利用できます。
SAML2.0 / Open ID Connect
IAMでは、SAML2.0やOpen ID ConnectといったSSOを実現でき、認証したユーザーごとに一時的なアクセスキーが発行されます。
このAWSの一時的なアクセスキーを管理 / 発行するのが STS (Amazon Security Token Service) です。
[例] ①ユーザーが組織の認証基盤で認証→②その基盤からSTSへ認証を連携→③STSから一時的なトークンが発行される→④ユーザーがAWSにアクセスできるようになる
Web IDフェデレーション
例えばFacebookのように、OpenID ConnectをサポートしているSNSをIDフェデレーションで連携させることでAWSへのSSOが可能です。(Web ID フェデレーション)
ちなみにAmazon Congnitoというサービスを利用すれば、Webやモバイルアプリからの認証をSNSと連携させることができます。
Directory Service
Microsoft ADと認証連携を行うことができるサービスです。
Directory ServiceのAD Connectorを利用することで、組織の既存ADと認証連携を行うことができます。
