●アクセス許可の境界
IAMの高度な機能。管理ポリシー（AWS管理ポリシー / カスタマー管理ポリシー）を使って、アイデンティティベースのポリシーをIAMエンティティ（ユーザーやロール）に付与することで、IAM ユーザーやロールに対して「最大限許可できる操作の範囲」を制限するための仕組み。

・エンティティはアイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できる。
（実際のアクセス許可は、IAM ポリシーとアクセス許可の境界の両方で許可されている操作のみが有効になる（AND条件））

AWSサービスやAWSリソース(リソース間の連携)に対する操作権限を定義して、IAMユーザやIAMグループにアタッチ。

●認証情報レポート（Credential Report）
監査向け情報。特定のIAMアイデンティティ（ユーザー、グループ、ロール）のIAM認証情報のレポートファイル。
※AWS Management Console、AWS SDK、コマンドラインツール、または IAM API から取得できる

[取得できる情報]

●IAMデータベース認証
DB接続用。IAMのデータベース接続に認証機能を付与する。

[主なメリット]

• 認証情報の一元管理: IAM によって DB ユーザーの管理が可能（DBにユーザー情報を保存しなくてもよい）
• ネットワークセキュリティ: SSL/TLS による暗号化通信を使用
• EC2 連携: EC2 インスタンスに割り当てられた IAM ロールを使えば、パスワードなしで DB にアクセス可能

すべての AWS サービスで共通して使用できるポリシー条件キー。これらは IAM ポリシーの Condition 要素で利用され、リクエストのコンテキストに基づいて、アクセス許可の条件を指定する。アクセス制御をより細かく設定するために使われる。

（※AWS SSOの後継サービス）
SSOが組織版に対応した感じ。すべての AWS アカウント とクラウドアプリケーションのためのシングルサインオンサービスを提供する。複数アカウントを運用している環境で各ユーザを集約管理し、各アカウントへの一元的なアクセスとユーザーアクセス許可を簡単に行えるようにするためのサービス。

※SSO：Single Sign ON

●アクセス権限(許可)セット
ポリシーの集合体。管理者定義のポリシーの集合であり、ユーザーおよびグループが持つアクセスレベルを定義する。
・権限セットは IAM Identity Center に保存され、1 つ以上にプロビジョニングできる。
・AWS アカウント複数のアクセス権限セットを 1 人のユーザーに割り当てることができる。
・特定のAWSアカウントに対するユーザーのアクセス許可が有効か判断するためにSSOで使用される。

[仕組み]

1. AWS Directory Service を通じて Microsoft Active Directory に接続される。
2. そのディレクトリのユーザーは、既存の Active Directory のユーザー名とパスワードを使用して、パーソナライズされた AWS ポータルにサインインできる。
3. AWS アクセスポータルから、ユーザーは権限を持つすべての AWS アカウント およびクラウド アプリケーションにアクセスできる。

[参考]

[IdPとの関係性]
SSOとIdPは分離されているが、SSOプロバイダーがユーザーのログイン時にIdPでユーザーIDを確認するSSOのプロセスがある。

※サービスコントロールポリシー
組織のIAMユーザーとIAMロールで使用可能な最大アクセス許可を一元的に制御できる。しかし権限を付与するのではなく、OU（組織単位）内のIAMユーザーやIAMロールが実行できるアクションに対してアクセス許可ガードレールを定義、制限するものである。
※許可ではなく明示的な拒否を指定することで効果的に制限をかける仕組み。

上記より、アクセス許可を付与するにはIAMユーザーとIAMロールにアタッチされたアイデンティティベースのポリシーやアカウントリソースにアタッチされたリソースベースのポリシーなどのアクセスを制御するポリシーをアタッチすること。
[参考サイト]

[利用条件]
・機能セットの「すべての機能」が有効になっている組織でのみ使用できる。

[戦略]

※「FullAWSAccess」アカウントに対し、拒否形式（ブラックリスト形式）を設定する場合
「FullAWSAccess」にブラックリスト形式で特定の操作を拒否すると、対象リソースの操作が拒否されるものの、その他のリソースについては「FullAWSAccess」が維持された状態となる。

[アカウントの別組織への移動方法]

1. 新しい開発組織の管理アカウントから Oranizations API の InviteAccountToOrganization オペレーションを呼びだして開発者アカウントに招待状を送信。
2. 管理アカウントからOrganizations API の RemoveAccountFromOrganization オペレーションを使用して、古い組織から各開発者アカウントを削除。
3. 各開発者に自分のアカウントにサインインして、新しい開発組織への参加確認をしてもらう。

Organization には利用可能な2つの機能セットがある。

・すべての機能（おすすめ）
一括請求機能が含まれている。(デフォルト)サポートされているAWSサービスとの統合、組織管理ポリシーなど高度なアカウント管理機能が可能。

・一括請求機能
※Consolidated Billing
複数アカウントを親アカウントと子アカウントの関係性にして親アカウントが子アカウントの分もまとめて一括支払い（一本化）できるサービス。

・複数アカウントで無料枠を使用していても１アカウント分しか無料枠は適用されない。
・一括請求機能のレポートは指定されたS3バケットに受信するように設定する必要がある。
・対象のバケットは管理アカウントによって所有されるため、メンバーアカウントが所有するS3バケットに受信されることはない。
・一括請求は追加コストなしで提供される。

[割引の共有]
全アカウントの利用料にボリューム割引が適用される。料金のボリューム割引、リザーブドインスタンスの割引、 Savings Plans を共有できる。（会社、部門、またはプロジェクトでの料金が個々のスタンドアロンアカウントと比較して低くなる）

・aws:PrincipalOrgID
グローバル条件キー。指定する組織に属するアカウントのみアクセスできるように設定できる。組織内のすべてのAWSアカウントのアカウントリストIDリストのように扱える。

効率よく組織内のAWSアカウントに関連付けられたIAM プリンシパル (ユーザーとロール) のみにリソースのアクセス制限を実行できる。

認証機能。アクセスできる認証トークン発行窓口。サインアップおよびサインインサービス。
ユーザーディレクトリとユーザープロファイルを管理する。

1. ユーザープールにユーザーが作成されると、Cognitoが一意のIDを割り振る。
2. IDトークン(JSON Web トークン (JWT) を発行し、IDプールへつなげる。

●ユーザーディレクトリ
認証情報保存。アプリ内部の領域でありIDやパスワードの認証情報を保存し、その情報を利用してアプリの「認証（アイデンティティの検証）」を行う。

認可機能。認証トークンに対して一時的な権限(Credetials＝認可トークン)を発行する。
外部のIDプロバイダーによって認証されたIDに対して、STSと連携し、AWSへのアクセス権限（認可トークン）を払い出す。

※事前にIAMロールとSTSの紐づけが必要になる

・Webアプリケーションなどを想定し、認証されていないゲストユーザーにも一部のアクセス権を付与できる機能を持つ。
・フロントエンドからの各種 AWS サービスへのリクエストに、認可を提供することが可能。

[Credentials の実体]
IDプール に事前に設定された IAM ロール を、AWS STS がユーザーのリクエスト毎に発行するIAMロールと同等の権限を持った一時的な認証情報を指す。

[ID プールがサポートする ID プロバイダー]

[Cognito ワークフロー]

1. ユーザーにパスワード、Emailを入力させてCognitoへリクエスト。
2. ユーザープールトークン(認証トークン)を取得。
3. ユーザープールトークンをIDプールトークン(認可トークン)と交換。
4. 認証もしくは認可トークンをヘッダーに設定しAWSの各サービスへリクエスト。

このデータベースに追加する必要がある 1 つ以上の CNAME レコードが ACM から提供される。
これらのレコードには、ドメインを制御する証拠となる一意のキーと値のペアが含まれている。

インターネットからアクセスするようなサービスの場合は、パブリック証明書で、組織内などのプライベートネットワークの場合は、プライベート証明書という使い分け。
[引用サイト]