【事前知識】
- クレデンシャル
IDやパスワードをはじめとする、ネットワーク上でユーザ等の認証に用いられるセキュリティ情報の総称。
- SCIM
（System for Cross-domain Identity Management）
様々なドメイン間でユーザID情報のやりとりを自動化する。
複数のクラウドサービスやシステム間でユーザーIDの整合性を取るように管理するプロトコル。
- 認証(AUTH)トークン
アクセス制御に用いられるデジタルトークン。一般的に、ユーザーがアプリケーションやサービスにアクセスする際に、ユーザー名とパスワードを入力することで認証が行われる。
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公式] |
| MFA | Multi-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 Simulator | IAMのポリシー設定をテストできる。アイデンティティベースのポリシー、IAMアクセス許可の境界、組織のサービスコントロールポリシー、リソースベースのポリシーをテストおよびトラブルシューティングできる。 |
| DryRun (プール値) | 実際に要求を行うことなく、アクションに必要な権限があるかどうかを確認し、エラー応答を提供する。必要な権限がある場合、エラー応答はDryRunOperationとなる。 |
IAMロール
【作業権限】
（EC2インスタンスからのアクセスのみ）
一時的なセキュリティ認証情報を取得してAWSリソース（サービス）へアクセスができる。
【使用例】
EC2インスタンス上で稼働するアプリケーションに一時的にAWSのリソースへのアクセス権を与えたい
➡EC2インスタンス作成時にロールを付与することで可能
- インスタンスプロファイル
【EC2のためのロール】
IAM ロールのコンテナ。
インスタンスの起動時に EC2 インスタンスにロール情報を渡すために使用できる。EC2インスタンスに紐づいたIAMロールが作成される。
- Assume Role
【ロールの代行】
別アカウントのリソースにアクセスしたい時、使用するロール。
「アカウントAがアカウントBのS3バケットにアクセスしたい」などのシチュエーションで役に立つ。
※実行権限を持つロールは作成元リソースが存在するアカウントに存在する必要があるため
●外部ID（専用）
【ロールの使用ID】
IAMロールの信頼ポリシー。
オプションの情報として使用することで、ロールを引き受けることが可能なユーザーを指定できる。
指定することで、ロールの使用権限が第三者に漏れたとしても、外部IDが一致しないと使用できない。
ID プロバイダー (IdP)
【一般ユーザー向け】
・外部ユーザー ID にアカウント内の AWS リソースに対するアクセス許可を与えることができる。
※外部ユーザー＝よく知られた IdP[事業者] (例: Login with Amazon、Facebook、Google)
・会社に既に企業ユーザーディレクトリなどの独自の ID システムがある場合に便利
・AWS リソースへアクセスが必要なモバイルアプリやウェブアプリケーションを作成する場合に便利
※プロバイダーとは…
回線をインターネットと繋げる役割を担う接続事業者のこと。
➡外部の人向けにトークンを発行してくれる事業者さん
【大まかな付与プロセス】
既にユーザーIDをAWSの外で管理している（外部ユーザー）は、、、
①IAM ID プロバイダーエンティティを作成して、AWS アカウント と IdP の間に信頼関係を確立。
②AWS アカウント に IAM ユーザーを作成する代わりにトークンを作成（得る）。
③外部 IdP は、OpenID Connect または SAML 2.0 のいずれかを使用して ID 情報を AWS に提供する。
④以降から外部idPを使用してサインインする。
[参考公式サイト：ID プロバイダーとフェデレーション]
AWS SSO
【IdPを使った認証】
※SSO：Single Sign ON
SSOトークンを発行して、1組の「ID・パスワード」による認証を1度行うだけで複数のサービスにログインできるようにする仕組み。
・システムを利用する際に、ユーザー側が1組のID・パスワードを覚えておけばいい
・複数のAWSアカウントへのアクセスを行う際に、Single-Sign-Onを提供→本番環境、開発環境にアクセスするときにも有効。
【IdPとの関係性】
SSOとIdPは分離されているが、SSOプロバイダーがユーザーのログイン時にIdPでユーザーIDを確認するSSOのプロセスがある。
〇フェデレーション
複数のインターネット サービス間のユーザ認証連携の意味。
【フェデレーションの方法】
シングルサインオン（SSO）を実現させるためには４つの方式があり、「フェデレーション方式」はその一つである。
[参考サイト]
一度の認証で複数のシステムを使ったり、複数のサービス（クラウドなど）、リソースやアプリケーションへのアクセスを受けられるようにするための仕組み。
- Web ID フェデレーション
【パブリックなトークン】
AmazonやSNS、Google(IdP：IDプロバイダー)がユーザーのトークンを発行することでサインインできる。
その時に外部サービスのユーザー情報とIAMロールを紐づけて一時的にアクセス権限を付与する。
- その他外部 ID フェデレーション
【内部組織のトークン】
IAM ロールを使用して、ID が組織または第三者のプロバイダー (IdP) からフェデレーションされたユーザーのアクセス許可を指定できる。
・社内のディレクトリなど、AWS 以外の ID をユーザーに有効。
〇プロトコル
【フェデレーションを実現させる技術】
フェデレーションを実現させるためのプロトコルの種類。フェデレーション認証の業界標準。
- OpenID Connect
【トークン発行処理の標準仕様】
サービス間で利用者の同意に基づきID情報を流通するための標準仕様。
利用者がOpenID提供サイトに登録したID情報を使って、ほかのOpenID対応サイトにログインすることが可能になる。
※ベース：OAuth 2.0プロトコル
[参考サイト]
- SAML 2.0
【異なるプロトコルの通信方法】
外部のアプリケーションおよびサービスにユーザーが本人であることを伝える標準化された方法のこと。（※異なるインターネットドメインの通信を実現するための通信プロトコル）
ユーザーを一度認証してから認証を複数のアプリケーションに伝える方法を提供し、シングルサインオン（SSO）技術を可能にする。誰が誰かを示すための標準化された方法。身元特定しなくても、身分証を見るだけで済む。
[参考サイト]
※SAML：Security Assertion Markup Language
※ベース：XML SAMLフォーマット
【解釈】
idPがトークン発行 ➡ フェデレーション機能（SSO）だけでサインインできるけど、ロールと紐づけることで安全性が確保されるよ。これが基本（？）
【認証・認可サービス】
【認証・認可の違い】
●認証：その人が誰であるかを判別すること。
●認可：その人が何を許可されているかを判別すること。
【SSOとCognitoの違い】
●SSO：
一度ユーザーを識別すると、その後アクセスできるようになる
●Cognito：
アクセス要求を検証し、検証済みのユーザーのみを許可する
➡安全性の違いとして、Cognitoの方が良い
[参考サイト]
Cognito
【ユーザー検証】
AWSなどに構築した、Web・モバイルアプリケーションに認証・認可機能を提供するサービス。
モバイルアプリなどに素早く簡単にユーザーのサインアップ/サインイン、アクセスコントロールの機能を追加できる。
・「認証」、「許可」、「ユーザ管理」をサポートしており、ユーザー名とパスワードを使用して直接サインインする方法もある
・ユーザーは Google、Facebook、Amazon、Apple などの外部IDプロバイダー、および SAML ベースの ID プロバイダー経由でユーザープールに認証、サインインすることもできる。
・開発者が更新された同期されたデータとしてイベントを受信できるようにKinesisストリームを設定できる
【Cognito ワークフロー】
①ユーザーにパスワード、Emailを入力させてCognitoへリクエスト。
②ユーザープールトークン(認証トークン)を取得。
③ユーザープールトークンをIDプールトークン(認可トークン)と交換。
④認証もしくは認可トークンをヘッダーに設定し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） | (レベル：高)ドメイン認証・会社実在認証・電話実在認証 |
AWS 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 オペレーションを使用して、古い組織から各開発者アカウントを削除。
③各開発者に自分のアカウントにサインインして、新しい開発組織への参加確認をしてもらう。
〇アクセス周り
- 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で使用される。
〇コスト周り
【簡単追跡】
複数のアカウントでの料金を追跡し、コストと使用状況の統合データをダウンロードできる。
【追加料金なし】
一括請求は追加コストなしで提供される。
- AWS Consolidated Billing
【使用状況の結合 / 一括請求機能】
複数アカウントを親アカウントと子アカウントの関係性にして親アカウントが子アカウントの分もまとめて一括支払い（一本化）ができるサービス。
・複数アカウントで無料枠を使用していても１アカウント分しか無料枠は適用されない。
・一括請求機能のレポートは指定されたS3バケットに受信するように設定する必要がある。
・対象のバケットは管理アカウントによって所有されるため、メンバーアカウントが所有するS3バケットに受信されることはない。
【割引の共有】
全アカウントの利用料にボリューム割引が適用される。料金のボリューム割引、リザーブドインスタンスの割引、 Savings Plans を共有できる。（会社、部門、またはプロジェクトでの料金が個々のスタンドアロンアカウントと比較して低くなる）
No responses yet