【事前知識】

  • クレデンシャル
    IDやパスワードをはじめとする、ネットワーク上でユーザ等の認証に用いられるセキュリティ情報の総称。

  • SCIM
    (System for Cross-domain Identity Management)
    様々なドメイン間でユーザID情報のやりとり自動化する。
    複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するプロトコル
  • 認証(AUTH)トークン
    アクセス制御に用いられるデジタルトークン。一般的に、ユーザーがアプリケーションやサービスにアクセスする際に、ユーザー名とパスワードを入力することで認証が行われる。

【認証・認可の違い】

認証:その人が誰であるかを判別すること。
認可:その人が何を許可されているかを判別すること。

【SSOとCognitoの違い】
SSO:一度ユーザーを識別すると、その後アクセスできるようになる
Cognito:アクセス要求を検証し、検証済みのユーザーのみを許可する

➡安全性の違いとして、Cognitoの方が良い
[参考サイト]

IAM
【アカウント管理】

※正式名:Identity and Access Management

「IDの管理・認証・認可」を主とする。企業が利用するシステムごとに設定された複数のIDを統合管理し、同時にアクセス権限の適切な管理を行う。

〇権限レベル

ルートアカウント
【強】
管理者権限
(IAMユーザー)
【中】
パワーユーザー
(IAMユーザー)
【弱】
・AWSルートアカウントのメールアドレスやパスワードの変更
・IAMユーザーの課⾦情報へのアクセスに関するactivate/deactivate
・他のAWSアカウントへのRoute53のドメイン登録の移⾏
・AWSサービス(サポート等)のキャンセル
・AWSアカウントの停⽌
・コンソリデイテッドビリングの設定
・脆弱性診断フォームの提出
・逆引きDNS申請
ルートアカウントと同等の権限はないIAMの操作権限なし

〇認証まわり

【方式】

AWSアクセスキーアクセスキーID/シークレットアクセスキーのセット。
IAMユーザまたはAWSアカウントの長期的認証情報を指す。
S3やEC2といったAWSの各サービスに対してプログラムにおけるアクセスを認証するために作成される認証キー。
X509 Certificate[参考:AWS公式]
MFAMulti-Factor Authentication 多要素認証。ユーザーのスマートフォンからのコード、秘密の質問の答え、指紋、顔認識などを要求する。
  • 認証情報レポート(Credential Report)
    【監査向け情報】
    特定のIAMアイデンティティ(ユーザー、グループ、ロール)のIAM認証情報のレポートファイル。

    ※AWS Management Console、AWS SDK、コマンドラインツール、または IAM API から取得できる

    【取得できる情報】
    ●認証情報
    パスワード、アクセスキー、MFA デバイスなど認証情報のローテーション。

    ●認証情報ステータス
    MFA、最終ログイン時間、パスワード利用有無など。

    【監査向け対応】
    監査やコンプライアンスの作業支援。また、外部の監査人にレポートとして提供できる。

    ・監査人はレポートをダウンロードできる。4 時間ごとに 1 回生成できる。
    ・レポートをリクエストすると、IAM はまず AWS アカウント について過去 4 時間以内にレポートが生成されたかどうかを確認する。

  • IAMデータベース認証
    【DB接続用】
    アプリケーションがインスタンス で実行されている場合、インスタンスプロファイル認証情報を使用してデータベースにアクセスできる。

    ※RDSが立ち上げたMySQLなどにアクセスする際(通常はユーザー名とパスワードを利用してアクセス)

    本機能を有効化すると下記を使用して、RDS DB インスタンスまたはクラスターに接続。
    IAM ユーザー」または「ロール認証情報
    ● 認証トークン
    有効期間は 15 分。AWS アクセスキーを使用して生成。

    ・データベースユーザーのパスワードなど資格情報の保存は不要
    SSL 接続が必要で、DB インスタンスとの間で送受信されるデータは暗号化される。

〇ポリシー

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

    【JSON形式で定義】
    ・Action(どのサービスの)
    ・Resource(どういう機能や範囲を)
    ・Effect(許可/拒否)

    ●Condition要素
    IAMポリシーのCondition要素内で、特定のタグと値を持つリソースへのアクセス制御できる。

【APIアクセスの設定】
ユーザーが呼び出すことができる API オペレーションを指定できる。

  • MFA認証の固定化 [参考サイト]
    ●「Get-Session-Token」を呼び出す方法。
    ●「Assumelore」を使用する方法。


場合によっては、ユーザーが特に重要なアクションを実行することを許可する前に、このユーザーに AWS 多要素認証 (MFA) で認証することを求める追加のセキュリティが必要となることもある。

【IAMポリシーの種類】

AWS管理ポリシー
(マネージド)
予めAWSによって用意されている管理ポリシー。「ポリシー」単体として存在できて、複数のプリンシパルエンティティにアタッチして利用可能。
ポリシーを変更するとアタッチされている全てのプリンシパルエンティティが変更適用。バージョニング、ロールバック可能。
カスタマー管理ポリシーユーザー(お客様)自身が管理できる管理ポリシー。
インラインポリシー特定のIAMユーザやIAMロール専用に作成されるポリシー。(使いまわしができない) 「ポリシー」単体では存在できず、プリンシパルエンティティ(1つのIAMユーザ)など、1対1でのアタッチしかできない。

【アクセス許可の境界】

IAMの高度な機能。
管理ポリシー(AWS管理ポリシー / カスタマー管理ポリシー)を使ってアイデンティティベースのポリシーをIAMエンティティ(ユーザーやロール)に付与できるアクセス許可の最大限度を設定できる。

・エンティティはアイデンティティベースのポリシーとそのアクセス許可の境界の両方で許可されているアクションのみを実行できる。

【ポリシーの検証・テスト】

Policy Validator文法に基づいていないポリシーを検出し、修正を求める。
IAMPolicy SimulatorIAMのポリシー設定をテストできる。アイデンティティベースのポリシー、IAMアクセス許可の境界、組織のサービスコントロールポリシー、リソースベースのポリシーをテストおよびトラブルシューティングできる。
DryRun
(プール値)
実際に要求を行うことなく、アクションに必要な権限があるかどうかを確認し、エラー応答を提供する。必要な権限がある場合、エラー応答はDryRunOperationとなる。

IAMロール
【作業権限】

EC2インスタンスからのアクセスのみ
一時的なセキュリティ認証情報を取得してAWSリソース(サービス)へアクセスができる。

【使用例】
EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへのアクセス権を与えたい
EC2インスタンス作成時にロールを付与することで可能

  • インスタンスプロファイル
    【EC2のためのロール】
    IAM ロールのコンテナ。
    インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できる。EC2インスタンスに紐づいたIAMロールが作成される。
  • Assume Role
    【ロールの代行
    別アカウントのリソースにアクセスしたい時、使用するロール。
    「アカウントAがアカウントBのS3バケットにアクセスしたい」などのシチュエーションで役に立つ。

    ※実行権限を持つロールは作成元リソースが存在するアカウントに存在する必要があるため

    ●外部ID(専用)
    【ロールの使用ID】
    IAMロールの信頼ポリシー。
    オプションの情報として使用することで、ロールを引き受けることが可能なユーザーを指定できる。
    指定することで、ロールの使用権限が第三者に漏れたとしても、外部IDが一致しないと使用できない。
  • IAM Roles Anywhere
    オンプレミスなどAWS外部のサーバーに、IAMロールを使って一時的な認証情報(クレデンシャル)を取得し、AWSサービスにアクセスできる。
    ・AWS環境からアクセスキーやシークレットアクセスキーを払い出す必要がなくなり、
    ・長期間有効な証明書ベースの認証を必要とするユースケースに適している

ID プロバイダー×フェデレーション

AWS のアカウント管理の仕組みである(IAM ユーザー)でユーザー認証をして AWS を利用できるようにするのではなく外部の ID プロバイダー(IdP)で管理されている ID を使って認証して AWS を利用できるようにする仕組み(AWS が認証をするのではなく、AWS は認証後に渡されるもの= ID トークンなどをみて AWS にアクセスする事を許可する)

[引用元]

〇フェデレーション

一度の認証で複数のシステムを使ったり、複数のサービス(クラウドなど)、リソースやアプリケーションへのアクセスを受けられるようにするための仕組み。

【フェデレーションの方法】
シングルサインオン(SSO)を実現させるためには4つの方式があり、「フェデレーション方式」はその一つである。
[参考サイト]

Web ID フェデレーション【パブリックなトークン】
AmazonやSNS、Google(IdP:IDプロバイダー)がユーザーのトークンを発行することでサインインできる。
その時に外部サービスのユーザー情報とIAMロールを紐づけて一時的にアクセス権限を付与する。
その他外部 ID フェデレーション【内部組織のトークン】
IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できる。
・社内のディレクトリなど、AWS 以外の ID をユーザーに有効。

【IAMフェデレーションのタイプ】
IAMフェデレーションとは
組織内の既存のIDシステム (IDプロバイダー) を利用して、AWSやその他のクラウドサービスへのアクセスを許可する仕組み。IDプロバイダーとフェデレーションを使用して、各リソースへのアクセスをユーザーに求める。

※IdP を直接 IAM にリンクするには、ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立する。IAMは、OpenID Connect (OIDC) または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポート

フェデレーション
タイプ
アカウントの種類アクセス管理対象サポートされている
IDソース(プロトコル)
IAM単一のスタンドアロンアカウント・短期間の小規模デプロイにおける人間ユーザー
・マシンユーザー
・SAML 2.0
・OIDC
IAM Identity CenterOrganizations によって管理される複数のアカウントワークフォースの人間ユーザー・SAML 2.0
・マネージド Active Directory
・Identity Center ディレクトリ
Cognitoいずれかリソースへのアクセスに IAM 認可を必要とするアプリのユーザー・SAML 2.0
・OIDC
・OAuth 2.0 ソーシャル ID プロバイダーの選択

IAM Identity Centerを有効にせず、AWS アカウントを 1 つだけ使用する場合は、OpenID Connect (OIDC) または SAML 2.0 を使用して ID 情報を AWS に提供する外部 IdP で IAM を使用できる。
※OIDC は、GitHub Actions など、AWS 上で実行しないアプリケーションを AWS リソースに接続できる

  • OIDC プロバイダー
    AWSアカウントとOIDCをサポートする外部IdPとの信頼関係を確立するためのIAMエンティティ。OIDC 互換 IdP と AWS アカウント の間で信頼性を確立するときに IAM OIDC ID プロバイダーを使用する。

[引用元サイト]

○ID プロバイダー (IdP)
【一般ユーザー】

※プロバイダーとは…
回線をインターネットと繋げる役割を担う接続事業者のこと。
➡外部の人向けにトークンを発行してくれる事業者さん

外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができる。
 ※外部ユーザー=よく知られた IdP[事業者] (例: Login with Amazon、Facebook、Google)
・会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利
・AWS リソースへアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合に便利

【大まかな付与プロセス】
既にユーザーIDをAWSの外で管理している(外部ユーザー)は、、、

  1. IAM ID プロバイダーエンティティを作成して、AWS アカウントIdP の間に信頼関係を確立。
  2. AWS アカウント に IAM ユーザーを作成する代わりトークンを作成(得る)。
  3. 外部 IdP は、OpenID Connect または SAML 2.0 のいずれかを使用して ID 情報を AWS に提供する。
  4. 以降から外部idPを使用してサインインする。

[参考公式サイト:ID プロバイダーとフェデレーション]

〇プロトコル

【フェデレーションを実現させる技術】
フェデレーションを実現させるためのプロトコルの種類。フェデレーション認証の業界標準。

OpenID Connect 【トークン発行処理の標準仕様】
サービス間で利用者の同意に基づきID情報を流通するための標準仕様。
利用者がOpenID提供サイトに登録したID情報を使って、ほかのOpenID対応サイトにログインすることが可能になる。
※ベース:OAuth 2.0プロトコル
[参考サイト]
SAML 2.0 【異なるプロトコルの通信方法】
外部のアプリケーションおよびサービスにユーザーが本人であることを伝える標準化された方法のこと。
(※異なるインターネットドメインの通信を実現するための通信プロトコル)
ユーザーを一度認証してから認証を複数のアプリケーションに伝える方法を提供し、シングルサインオン(SSO)技術を可能にする。誰が誰かを示すための標準化された方法。身元特定しなくても、身分証を見るだけで済む。
[参考サイト]
※SAML:Security Assertion Markup Language
※ベース:XML SAMLフォーマット

プロトコルの違いについて参考サイト

【解釈】
idPがトークン発行 ➡ フェデレーション機能(SSO)だけでサインインできるけど、ロールと紐づけることで安全性が確保されるよ。これが基本(?)

【その他サービス知識】

  • GitHub Actions
    GitHubが提供するワークフロー自動化サービスで、コードをビルド、テスト、デプロイするCI/CDパイプラインを自動化できる。

AWS SSO
【IdPを使った認証】

※SSO:Single Sign ON

SSOトークンを発行して、1組の「ID・パスワード」による認証を1度行うだけで複数のサービスにログインできるようにする仕組み。

・複数のAWSアカウントへのアクセスを行う際に、Single-Sign-Onを提供→本番環境、開発環境にアクセスするときにも有効。

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

Cognito
【ユーザー検証

AWSなどに構築した、Web・モバイルアプリケーションに認証・認可機能を提供するサービス。
モバイルアプリなどに素早く簡単にユーザーのサインアップ/サインイン、アクセスコントロールの機能を追加できる。

・「認証」、「許可」、「ユーザ管理」をサポートしており、ユーザー名とパスワードを使用して直接サインインする方法もある

・ユーザーは Google、Facebook、Amazon、Apple などの外部IDプロバイダー、および SAML ベースの ID プロバイダー経由でユーザープールに認証、サインインすることもできる。

・開発者が更新された同期されたデータとしてイベントを受信できるようにKinesisストリームを設定できる

【Cognito ワークフロー】

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

〇ユーザープール【認証】

アクセスできる認証トークン発行窓口。サインアップおよびサインインサービス。

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

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

    ・ユーザーディレクトリとユーザープロファイルの管理

〇IDプール【認可】

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

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

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

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

【ID プールがサポートする ID プロバイダー】

パブリックプロバイダー:
Login with Amazon(ID プール)、Facebook(ID プール)、Google(ID プール)、Apple でサインイン(ID プール)
Cognito ユーザープール
Open ID Connect プロバイダー (ID プール)
SAML ID プロバイダー (ID プール)
デベロッパーが認証したアイデンティティ (ID プール)

  • STS(Security Token Service)
    【一時的なセキュリティキー】

    一時的なセキュリティキーを作成することで、信頼するユーザーへ操作・管理を許可する(アクセスキー)。

    ・認証情報として、「アクセスキー」、「シークレットキー」、「セッショントークン」の3つ(セキュリティ認証情報セット)を発行する。
    ・「有効期限」を設定して一時的な許可が可能な点と、リクエストに応じてその都度動的に作成される(AWSIDを発行しない)ため、一時的でユーザーに紐づかない。

    (IDフェデレーション)

  • Decode Authorization Message
    エンコードされたエラーメッセージのデコードに役立つ。

〇その他 Cognito機能

  • プッシュ機能通知
    自動的にIDとデバイス間の関連付けを追跡する。
    IDデータが変更された時、特定のIDのすべてのインスタンスにプッシュ通知をする。
    また、特定のIDの同期ストアデータが変更されるたびに、そのIDに関連付けられているすべてのデバイスが通知を受け取る。

  • Cognito ストリーム
    すべてのSyncデータをKinesisに移動して、分析するためにDWHにストリーミング処理ができる。

  • Cognito Sync
    認証したデータを共有することができるようになる。ログインしたユーザーデータやアプリケーションデータを複数のデバイス間で共有することができる機能を提供。

  • Cognito イベント
    Cognitoにおける重要なイベントに応じてLambda関数を実行できる。

  • Cognito コールバック
    データセットの同期に関するアクティビティのコールバックイベントを処理する。

ACM (AWS Certificate Manager)
【認証局】

AWS自身が認証局となり、AWSサービスとユーザーの内部接続リソースで使用するパブリックまたはプライベートのSSL/TLS 証明書を作成・登録・集中管理できる。

・無料
・有効期限は13か月で自動更新される
・SHA-256のSSL/TLSサーバ証明書の作成・管理を行う
・SSL/TLS 証明書の購入、アップロード、更新プロセスを手動で行う必要がなくなる

  • パブリック or プライベート
    プライベート証明書はプライベート認証局で作成をしなくてはいけない、高額な証明書である。
    コスト面では不適切

    ・ACMはパブリック証明書をエクスポートできない

  • SSL/TLS
    (Secure Sockets Layer/Transport Layer Security)
    インターネットで情報を送受信する際の仕組み(プロトコル)の一種で、サーバ〜PC間の通信を暗号化して安全を担保してくれる。

    【利用方法】
    クライアントに説明して、CSR(Certificate Signing Request)ファイルと呼ばれる証明書の発行申請書を作成。
    認証局にお金を支払い証明書を発行してもらい、サーバへインストールするなどの手続きが必要になる。

    証明書接続エラーは基本的にSSLエラーとして確認されることが多い。
  • DNS検証
    このデータベースに追加する必要がある 1 つ以上の CNAME レコードが ACM から提供される。
    これらのレコードには、ドメインを制御する証拠となる一意のキーと値のペアが含まれている。

【SSL証明書の種類】

ドメイン認証型SSLサーバ証明書
(DV: Domain Validation)
(レベル:低)ドメイン認証
組織認証型SSLサーバ証明書
(OV: Organization Validation)
(レベル:中)ドメイン認証・会社実在認証
EV SSL証明書
(Extended Validation)
(レベル:高)ドメイン認証・会社実在認証・電話実在認証

Organization
【組織管理】

アカウントの作成・複数アカウントに適用するポリシーを管理できる。

マスターアカウントを使用して、組織で使用したAWSの費用を統合して支払うことができる。

・グループを作成し、そのグループに対して、アクセス制御OU(組織単位) や SCP(サービスコントロールポリシー)を適応することでサービスへの使用を制限する。

(※管理アカウントは組織のルートアカウントであり、OUに含めることはできない)
(※OUにはデフォルトでFullAWSAccess SCP がアタッチされている)
▲異なる組織ユニット(OU)間でのアカウントの移動のみをサポートしている

・Organization(SCP)AWS Organizationsを使用すれば、APIから新規アカウントを作成・グループに追加を行い、すぐに使用管理できる。
(※従来はAWSのアカウントを作る際、カード番号の入力や電話認証などの対応が必要だった)

  • タグポリシー
    組織のアカウント内のリソース間でタグを標準化できる。リソースのタグ付けの際に適用されるタグ付けルールを指定する。

【一括請求にメンバーアカウントを追加する】

管理アカウントの所有者が、追加するアカウントリクエストを送信する。

  • SCP(サービスコントロールポリシー)
    組織のすべてのアカウントで使用可能な最大アクセス許可を一元的に制御できる組織ポリシーの一種。
    AWSアカウント、組織単位(OU)内のアカウントのグループに対してAWSサービスへの権限境界を設定できる。

    SCP自体は権限を与えるものではなく、「ここまでは許可できる」という境界を設定。SCPを使用するにはすべての機能を使用する許可が必要。

    組織内でサービスコントロールポリシー (SCP) を、次のうちいずれかとして機能設定できる。

    ●拒否リスト(戦略)
    アクションはデフォルトで許可され、禁止するサービスとアクションを指定できる。
    ※戦略⇒許可しないアクセスを明示すること

    ●許可リスト(戦略)
    アクションはデフォルトで禁止され、許可するサービスとアクションを指定できる。
    ※戦略⇒許可するアクセスを明示すること

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

【アカウントの別組織への移動方法】
①新しい開発組織の管理アカウントから Oranizations API の InviteAccountToOrganization オペレーションを呼びだして開発者アカウントに招待状を送信。

②管理アカウントからOrganizations API の RemoveAccountFromOrganization オペレーションを使用して、古い組織から各開発者アカウントを削除。

③各開発者に自分のアカウントにサインインして、新しい開発組織への参加確認をしてもらう。

〇機能セット

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

  • すべての機能(おすすめ)
    一括請求機能が含まれている。(デフォルト)
    サポートされているAWSサービスとの統合、組織管理ポリシーなど高度なアカウント管理機能が利用できる。
  • 一括請求機能
    Consolidated Billing
    複数アカウントを親アカウントと子アカウントの関係性にして親アカウントが子アカウントの分もまとめて一括支払い(一本化)ができるサービス。

    ・複数アカウントで無料枠を使用していても1アカウント分しか無料枠は適用されない。

    ・一括請求機能のレポートは指定されたS3バケットに受信するように設定する必要がある。

    ・対象のバケットは管理アカウントによって所有されるため、メンバーアカウントが所有するS3バケットに受信されることはない。

    ・一括請求は追加コストなしで提供される。

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

〇アクセス周り

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

    効率よく組織内のAWSアカウントに関連付けられたIAM プリンシパル (ユーザーとロール) のみにリソースのアクセス制限を実行できる。
  • IAM Identity Center
    SSO組織版みたいな感じ】
    すべての AWS アカウント とクラウドアプリケーションのためのシングルサインオンサービスを提供する。
    複数アカウントを運用している環境で各ユーザを集約管理し、各アカウントへの一元的なアクセスとユーザーアクセス許可を簡単に行えるようにするためのサービス。

    【仕組み】
    ①AWS Directory Service を通じて Microsoft Active Directory に接続される。

    ②そのディレクトリのユーザーは、既存の Active Directory のユーザー名とパスワードを使用して、パーソナライズされた AWS ポータルにサインインできるようになる。

    ③AWS アクセスポータルから、ユーザーは権限を持つすべての AWS アカウント およびクラウド アプリケーションにアクセスできる。

    [参考]

    アクセス権限(許可)セット
    【ポリシーの集合体】
    管理者定義のポリシーの集合であり、ユーザーおよびグループが持つアクセスレベルを定義する。

    ・権限セットは IAM Identity Center に保存され、1 つ以上にプロビジョニングできる。

    ・AWS アカウント複数のアクセス権限セットを 1 人のユーザーに割り当てることができる。

    ・特定のAWSアカウントに対するユーザーのアクセス許可が有効か判断するためにSSOで使用される。

〇コスト周り

【簡単追跡】
複数のアカウントでの料金を追跡し、コストと使用状況の統合データをダウンロードできる。

No responses yet

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

error: Content is protected !!