AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた知識の整理 IDフェデレーションとDDoS対策
概要
AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた小ネタ集。
今回は全然関連性がないですが、IDフェデレーションとDDoS対策に関する整理です。
[2020年10月追記]
2回目の受験でついにプロフェッショナル試験に合格しました!
合格体験記/勉強法を以下で投稿しているので良かったら読んでください。
試験受ける予定がある方の少しでも役に立てればと思います(^^)
AWS初心者がAWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に合格した時の勉強法
IAM
- いきなりIDフェデレーションにいく前にまずは仕組みの基礎となるIAMです
- IAM > IAMロール > IDフェデレーション といった体系的な理解が必要です
- そもそもIAMには聞きなれない言葉がいくつかでてくるのでそれらは以下を参照
- 例えば、エンティティ
AWS によって認証に使用される IAM リソースオブジェクト。例えば、IAM ユーザー、フェデレーションユーザー、引き受ける IAM ロールです。
- プリンシパル
AWS にサインインし、リクエストを作成するために AWS アカウントのルートユーザー、IAM ユーザー、または IAM ロールを使用する人またはアプリケーション。
日本語訳は「主要な」、、、具体的に例えば、
"Principal": {"AWS": "123456789012"} // ← AWSアカウントを信頼
と、いった表現をして別のAWSアカウントからスイッチロールできるクロスアカウントロールを作成する
具体的な使い方として、IAMポリシーの書き方を見た方がわかりやすいので、
IAMポリシーサンプル 投稿しました。
「AssumeRoleを利用した様々な外部アクセスの許可」部を見るとイメージが湧くと思います。
IAMロール
- IAMロールの一般的なシナリオの説明が以下にあります。
- この中の1つに「外部で認証された(ID フェデレーション)ユーザーにアクセスを許可する」があり、この部分が今回の本題のID フェデレーションです。
IDフェデレーション
- 一言で言うと外部で管理されたIDを使って認証して、AWSのサービスの使用許可を制御(認可)しよう。ということです。
- まず概念的に以下の三つがあることを頭に入れる必要があります。
- パブリック ID サービスプロバイダーまたは OpenID Connect を使用したユーザーのフェデレーション
- SAML 2.0 を使用したユーザーのフェデレーション
- カスタム ID ブローカーアプリケーションを作成するユーザーのフェデレーション
- OpenID/SAML以外がこのカスタムIDブローカーに分類されます
- この3種類のフェデレーションの実現のために、AWSでは、
- Amazon Cognito
- IAM(の中のAWS STS)
の2つがあるということを上記URLの「外部で認証された(ID フェデレーション)ユーザーにアクセスを許可する」で言っています。(Cognitoの説明が最初に出てくるのが非常に混乱する^^;)
ちなみにAWSとしては他のマネジメントサービス同様、基本的にはCognitoを使うことを推奨しています。より高度なシナリオの場合にAWS STSを使用する。
Cognitoを使う場合のわかりやすい解説があったのでこちらも参考に。
https://qiita.com/YamaguchiKenya/items/a8bb71c94dca49f1802b
AWS STS
- Cognito推奨ではあるものの、AWS STS の API 試験的に頻出な気がします。
- 良く出てくるのは以下のAPIです。
- AssumeRoleWithWebIdentity — ウェブベースの ID プロバイダーを(OpenID Connect (OIDC) 互換の IdP)経由したフェデレーション
- AssumeRoleWithSAML — SAML 2.0 と互換性のあるエンタープライズ ID プロバイダーを経由するフェデレーション
- AssumeRole — クロスアカウントの委任とカスタム ID ブローカーを経由したフェデレーション
- GetFederationToken — カスタム ID ブローカーを経由したフェデレーション
- GetSessionToken — 信頼されていない環境にあるユーザー向けの一時的認証情報
IDプロバイダーとフェデレーション
- ここからは、OpenID Connectベース、SAML2.0ベースのフェデレーションに焦点をあてていきます。なぜならカスタム ID ブローカーは基本的にAWS STS APIで頑張るから^^;
- このあたりの説明があるのが以下です。
- IAMは、OpenID ConnectベースのウェブIDフェデレーションとSAML2.0ベースのフェデレーションの2パターンをサポート
- ユーザー ID を AWS の外で管理している場合、AWS アカウントに IAM ユーザーを作成する代わりに、IAM ID プロバイダー(IdP)を利用
- IdP を使用するには、IAM ID プロバイダーエンティティを作成して、AWS アカウントと IdP の間に信頼関係を確立します。IAM は、OpenID Connect または SAML 2.0 (Security Assertion Markup Language 2.0) と互換性のある IdP をサポート
ウェブIDフェデレーション
- ウェブIDフェデレーション:モバイルデバイスでAWSの外の認証情報を使って認証しAWSサービスを使うタイプ
- ウィブIDフェデレーションをAWS STSを使って実現するイメージは以下の通り。
Amazon Cognitoを使用する場合
- 顧客はモバイルデバイスでアプリを起動します。アプリはユーザーにサインインするように求めます。
- アプリは Login with Amazon を使用して、ユーザーの認証情報を承認します。
- アプリは Cognito API オペレーションを使用して、Login with Amazon ID トークンを Cognito トークンに置き換えます。
- アプリは AWS STS に一時的なセキュリティ証明書をリクエストして、Cognito トークンを渡します。
- アプリは一時的なセキュリティ証明書を使用して、アプリの動作に必要ないずれの AWS リソースにもアクセスできます。一時的なセキュリティ証明書に関連付けられたロールとその割り当てられたポリシーによって、アクセス可能なリソースが決まります。
APIベースだと以下が参考になりそう。
- GetId:Cognito で新しいIDを確立するために必要な最初の呼び出し
- GetOpenIdToken:アイデンティティIDを確立した後での呼び出し
SAML2.0ベースのフェデレーション
- SAML2.0ベースのフェデレーション:外部のLDAP等のIDプロバイダーを利用するタイプ
- SAML2.0ベースのフェデレーションをAWS STSを使って実現するイメージは以下の通り。
- 組織のユーザーが、クライアントアプリを使用して、組織の IdP に認証を要求します。
- IdP がユーザーを組織の ID ストアに対して認証します。
- IdP はユーザーに関する情報を使用して SAML アサーションを構築し、クライアントアプリにアサーションを送信します。
- クライアントアプリが、AWS STS AssumeRoleWithSAML API を呼び出して、SAML プロバイダーの ARN、引き受けるロールの ARN、および IdP からの SAML アサーションを渡します。
- API は一時的なセキュリティ認証情報を含むレスポンスをクライアントアプリに返します。
- クライアントアプリでは、一時的なセキュリティ証明書を使用して Amazon S3 API オペレーションを呼び出します。
SAML 2.0 フェデレーティッドユーザーが AWS マネジメントコンソール にアクセス可能にする
- コンソールへのSSOとなるとまたちょっと違います。
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html
- ユーザーは組織のポータルにアクセスして、AWS マネジメントコンソール に移動するオプションを選択します。一般的に、組織のポータルは、組織と AWS 間の信頼の交換を処理する IdP の機能です。たとえば、Active Directory フェデレーションサービスでは、ポータル URL は次のようになります。
https://{ADFSServiceName}/adfs/ls/IdpInitiatedSignOn.aspx
- ポータルが組織内のユーザーの ID を確認します。
- ポータルは、ユーザーを識別するアサーションを含む SAML アサーションレスポンスを生成し、ユーザーの属性を含めます。コンソールセッションが有効な期間を指定する SessionDuration という SAML アサーションの属性を含むよう IdP を設定できます。セッションタグとして属性を渡すように IdP を設定することもできます。ポータルはこのレスポンスをクライアントブラウザに送信します。
- クライアントブラウザは AWS のシングルサインオンエンドポイントにリダイレクトされ、SAML アサーションを投稿します。
- エンドポイントは、ユーザーの代わりに一時的なセキュリティ認証情報をリクエストし、コンソールのサインイン URL を作成します。
- AWS は、サインイン URL をクライアントにリダイレクトとして送信します。
- クライアントのブラウザは AWS マネジメントコンソールにリダイレクトされます。複数の IAM ロールに対応付けられた属性を SAML 認証レスポンスが含む場合は、最初にコンソールへのアクセスするためのロールを選択する画面が表示されます。
AWS Single Sign-On (AWS SSO)
- ちょっと飛躍しますが、SSOがでてきたので、AWS SSOのサービスも載せておきます。
- オンプレとのSAML認証連携によるシングルサインオンとMFA認証が可能になります。
- AWS Organizations サービスを設定し、[すべての機能] を有効化する必要があります。
- SSOとオンプレのActiveDirectoryとの連携に AD Connector(またはAWSDirectoryService for Microsoft ActiveDirectory)が必要です。
- イメージ図は以下の通り。
長くなりましたが、IDフェデレーションについては以上です。
IDフェデレーションは広く深い知識の分野になり、今回の投稿がきれいにまとまっているとは言い難いですが、誰かの役に立てば幸いです(^^)
DDoS対策
- 基本的にはAWS Shield Standard/AWS Shied Advanced/AWS WAFの3対策
- AWS Shield Standard:Route 53またはCloudFrontで使用する。無料。L3/L4の防御。
- AWS Shield Advanced:Route 53、CloudFront、ELB、EC2、AWS Global Acceleratorで使用する。有料。L7、ネットワークACLを使った防御。
- AWS WAF:CloudFront、ALB、APIGatewayで使用。有料。IPアドレス、HTTP、クエリ文字列でのアクセス制限に加え、SQLインジェクション、クロスサイトスクリプティングにも有効。
AWS Shield:https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/ddos-overview.html
AWS WAF:https://docs.aws.amazon.com/ja_jp/waf/latest/developerguide/waf-chapter.html
その他参考
アソシエイト資格の勉強法は以下を参照
AWS初心者がAWS 認定ソリューションアーキテクト – アソシエイト資格試験に合格した時の勉強法
プロフェッショナル資格の勉強法は以下を参照
AWS初心者がAWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に合格した時の勉強法
その他の小ネタは以下を参照
Author And Source
この問題について(AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた知識の整理 IDフェデレーションとDDoS対策), 我々は、より多くの情報をここで見つけました https://qiita.com/fkooo/items/a6d71407b2bed42332cc著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .