More than 3 years have passed since last update.

AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた知識の整理 IDフェデレーションとDDoS対策

Last updated at 2020-12-11Posted at 2020-02-11

概要

AWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に向けた小ネタ集。
今回は全然関連性がないですが、IDフェデレーションとDDoS対策に関する整理です。

[2020年10月追記]
2回目の受験でついにプロフェッショナル試験に合格しました！
合格体験記／勉強法を以下で投稿しているので良かったら読んでください。
試験受ける予定がある方の少しでも役に立てればと思います(^^)

AWS初心者がAWS 認定ソリューションアーキテクト – プロフェッショナル資格試験に合格した時の勉強法

IAM

いきなりIDフェデレーションにいく前にまずは仕組みの基礎となるIAMです
IAM　＞　IAMロール　＞　IDフェデレーション　といった体系的な理解が必要です
そもそもIAMには聞きなれない言葉がいくつかでてくるのでそれらは以下を参照
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/intro-structure.html
例えば、エンティティ

AWS によって認証に使用される IAM リソースオブジェクト。例えば、IAM ユーザー、フェデレーションユーザー、引き受ける IAM ロールです。

プリンシパル

AWS にサインインし、リクエストを作成するために AWS アカウントのルートユーザー、IAM ユーザー、または IAM ロールを使用する人またはアプリケーション。
日本語訳は「主要な」、、、具体的に例えば、

"Principal": {"AWS": "123456789012"} // ← AWSアカウントを信頼
と、いった表現をして別のAWSアカウントからスイッチロールできるクロスアカウントロールを作成する

具体的な使い方として、IAMポリシーの書き方を見た方がわかりやすいので、
IAMポリシーサンプル投稿しました。
「AssumeRoleを利用した様々な外部アクセスの許可」部を見るとイメージが湧くと思います。

IAMロール

IAMロールの一般的なシナリオの説明が以下にあります。
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_common-scenarios.html
この中の１つに「外部で認証された（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 試験的に頻出な気がします。
- https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp_request.html
良く出てくるのは以下の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で頑張るから^^;
このあたりの説明があるのが以下です。
ID プロバイダーとフェデレーション
IAMは、OpenID ConnectベースのウェブIDフェデレーションとSAML2.0ベースのフェデレーションの２パターンをサポート
ユーザー 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を使用する場合

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_providers_oidc_cognito.html

顧客はモバイルデバイスでアプリを起動します。アプリはユーザーにサインインするように求めます。
アプリは Login with Amazon を使用して、ユーザーの認証情報を承認します。
アプリは Cognito API オペレーションを使用して、Login with Amazon ID トークンを Cognito トークンに置き換えます。
アプリは AWS STS に一時的なセキュリティ証明書をリクエストして、Cognito トークンを渡します。
アプリは一時的なセキュリティ証明書を使用して、アプリの動作に必要ないずれの AWS リソースにもアクセスできます。一時的なセキュリティ証明書に関連付けられたロールとその割り当てられたポリシーによって、アクセス可能なリソースが決まります。

APIベースだと以下が参考になりそう。

https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/authentication-flow.html

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のサービスも載せておきます。
- https://aws.amazon.com/jp/blogs/news/introducing-aws-single-sign-on/
オンプレとのSAML認証連携によるシングルサインオンとMFA認証が可能になります。
AWS Organizations サービスを設定し、[すべての機能] を有効化する必要があります。
SSOとオンプレのActiveDirectoryとの連携に AD Connector（またはAWSDirectoryService for Microsoft ActiveDirectory）が必要です。
イメージ図は以下の通り。

長くなりましたが、IDフェデレーションについては以上です。
IDフェデレーションは広く深い知識の分野になり、今回の投稿がきれいにまとまっているとは言い難いですが、誰かの役に立てば幸いです(^^)

DDoS対策

DDoS対策（英語）

基本的にはAWS Shield Standard/AWS Shied Advanced/AWS WAFの３対策
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