→認証技術
→Amazon Web Service
→AWS その他のサービス
→SSO関連 ←AWS SSO/IAM Identity Center についてはこちら
- IAMは認証だけでなくリソースの権限管理の機能も併せ持つ
- API KEY(プログラムからAWS各種サービスを操作できる
- MFA…多要素認証
- ARN…AWS上のリソースを一意に特定するID
- プリンシパル…認証してエンティティを使う主体のこと。以下のいずれか
- 人(ユーザ、もしくはフェデレーテッドユーザ)
- アプリケーション
- IAMの管理単位
- IAMグループ…フラットな階層でしか管理できず、階層構造は持てない
- IAMユーザ
- IAMロール…EC2上で実行されるプログラムに実行権限を割り当てるのに使う、API KEYが要らなくなる
- プリンシパルエンティティ…プリンシパルがポリシーを付与する対象となるエンティティのことか?
- IAMエンティティ…プリンシパルエンティティと一部被っている?
IAMロール†
IAMユーザ管理†
- IAM ユーザーのパスワードの管理 - AWS Identity and Access Management
- AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
- ナビゲーションペインで [Users] (ユーザー) を選択します。
- パスワードを変更するユーザーの名前を選択します。
- [認証情報] タブを選択してから、[サインイン認証情報] で [Console password (コンソールパスワード)] の横の [パスワードの管理] を選択します。
- [Manage console access (コンソールアクセスの管理)] の [Console access (コンソールアクセス)] で、[Enable (有効化)] を選択します (まだ選択していない場合)。コンソールアクセスが無効になっている場合、パスワードは不要です。
- [Set password (パスワードの設定)] で、IAM によってパスワードを自動的に生成するか、カスタムパスワードを作成するかを選択します。
- ユーザーに初回サインイン時に新しいパスワードの作成を求めるには、[Require password reset (パスワードのリセットが必要)] を選択します。次に、[Apply (適用)] を選択します。
重要
- [Require password reset (パスワードのリセットが必要)] オプションを選択した場合は、ユーザーが自分のパスワードを変更するアクセス許可を持っていることを確認します。詳細については、「IAM ユーザーに自分のパスワードを変更する権限を付与する」を参照してください。
IAMポリシー†
- メモ(2023.1)
- 1つのIAMグループに対して管理ポリシーやインラインポリシーはそれぞれ最大10までしか付与できない。
- 10以上の管理ポリシーを付与したい場合は、複数のIAMグループを作り、それらのグループにポリシーを分散して付与した上で、ユーザを両方のグループに所属させるとよい。
- このような使い方を踏まえ、IAMグループは単なる「ユーザの組織単位での集まり」としてよりも付与するポリシーの分類を意識したグルーピングにした方が良さそう。
- ポリシータイプ…参照:IAM でのポリシーとアクセス許可 - AWS Identity and Access Management 2022.4
- アイデンティティベースのポリシー…ユーザーやロールなどのアイデンティティにアタッチするポリシー。管理ポリシーとインラインポリシーがある。
- リソースベースのポリシー…インラインポリシーをリソースにアタッチするポリシー。
- セッションポリシー…AWS CLI または AWS API を使用してロールまたはフェデレーティッドユーザーを引き受ける場合に使うポリシー
- アクセス許可の境界…アイデンティティベースのポリシーが IAM エンティティに付与できるアクセス許可の上限
- サービスコントロールポリシー(SCP)…組織または組織単位 (OU) のメンバーアカウントのアクセス許可の上限
- アクセスコントロールリスト(ACL)…ACL がアタッチされているリソースにアクセスすることができる他のアカウントのプリンシパルを制御。クロスアカウントのアクセス許可
- ※分類軸がぐちゃぐちゃでわかりづらいが、本当にポリシーのタイプという感じなのは最初の3つで、あとの3つは上限値と他アカの制御
- IAMポリシーは何を対象にアタッチするポリシーかで2つに分かれる
- アイデンティティベースポリシー…ユーザ/グループ/ロールにアタッチするポリシー
- リソースベースポリシー…リソースとは主にAWSの個々のサービス(例えばS3)を指す
- アイデンティティベースポリシーはスタンドアロンかどうかで別れ、さらにスタンドアロンポリシーは管理主体によって2つに分かれる
- リソースベースポリシーはインラインポリシーしかない
- リソースベースのポリシーとして最も一般的な例
- Amazon S3 バケットポリシー
- IAM ロールの信頼ポリシー
- JSON ポリシー 2022.4
- Version – 使用するポリシー言語のバージョン。2012-10-17
- Statement – このポリシーのメイン要素であり、以下の要素のコンテナになります。ポリシーには、複数のステートメントを含めることができます。
- Sid (オプション) – 複数のステートメントを区別するための任意のステートメント ID が含まれます。
- Effect – Allow / Deny
- Principal (一部の状況でのみ必須)
- リソースベースのポリシーを作成する場合は、アクセスを許可または拒否するアカウント、ユーザー、ロール、またはフェデレーティッドユーザーを指定する必要があります。
- ユーザーまたはロールにアタッチする IAM アクセス許可ポリシーを作成する場合は、この要素を含めることはできません。プリンシパルは、そのユーザーまたはロールを暗黙に示しています。
- Action – ポリシーで許可または拒否するアクションのリストが含まれます。(Resource 一部の状況でのみ必須)
- IAM アクセス許可ポリシーを作成する場合は、アクションが適用されるリソースのリストを指定する必要があります。
- リソースベースのポリシーを作成する場合は、この要素はオプションです。この要素を含めない場合、アクションが適用されるリソースは、ポリシーがアタッチされているリソースです。
- Condition (オプション) ポリシーでアクセス許可を付与する状況を指定します。
フェデレーション†
- IDフェデレーション…使用頻度の低いユーザにアカウントを与えるのではなく一時的な認証を与え、短時間のみサービスへのアクセスを許す仕組み
- AWS Security Token Service (STS) と AWS フェデレーションは、どちらも一時的な権限付与の仕組みですが、使用用途や方法が異なる。
- STSは、AWSアカウントの代理人として操作を行うために使用されます。STSを使用すると、一時的なセキュリティトークンを取得して、アクセスキー、シークレットアクセスキー、セッショントークンを使用してAWSサービスにアクセスすることができる。
- AWS フェデレーションは、組織内のユーザーやシステムからAWSにアクセスするために使用する。
- AWS フェデレーションを使用すると、組織内の認証システムとAWSアカウントを連携させることができ、組織内のユーザーやシステムがAWSサービスにアクセスするために必要なアクセスキーやシークレットアクセスキーを取得することができる。
- ID プロバイダーとフェデレーション
- すでにユーザー ID を AWS の外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダーを利用できます。
- ID プロバイダー (IdP) を使用すると、AWS の外部のユーザー ID を管理して、これらの外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができます。
これは、会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利です。
- また、AWS リソースへのアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合にも便利です。
- フェデレーション(英:federation)とは、一度認証を通ればその認証情報を使って許可されているすべてのサービスを使えるようにする仕組み
MFA†
- 簡単に言うと、スマホなどにOTPツールを入れてそのパスワードを入れるような仕組みにする