AWS Black Belt Online Seminar · 認証・認可をメソッド単位で制御可能 •...

アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト辻義一

2017.10.10

【AWS Black Belt Online Seminar】AWSにおけるアプリ認証パターン

AWS Black Belt Online SeminarとはAWSJのTechメンバがAWSに関する様々な事を紹介するオンラインセミナーです

【火曜 12:00〜13:00】主にAWSのソリューションや業界カットでの使いどころなどを紹介(例：IoT、金融業界向け etc.)

【水曜 18:00〜19:00】主にAWSサービスの紹介やアップデートの解説(例：EC2、RDS、Lambda etc.)

※開催曜日と時間帯は変更となる場合がございます。最新の情報は下記をご確認下さい。オンラインセミナーのスケジュール＆申し込みサイトhttps://aws.amazon.com/jp/about-aws/events/webinars/

内容についての注意点

• 本資料では2017年10月10日時点のサービス内容および価格についてご説明しています。最新の情報はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。

• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違があった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。

• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税をご請求させていただきます。

• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at http://aws.amazon.com/agreement/. Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

Agenda

用語について

本Webinarでの想定ユースケース３パターン

登場するサービスの概要紹介

AWS上での実現パターン

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

用語について

用語の確認（1/2）統一されておらず曖昧な用語もあるが、本ウェビナーでは以下の通りとする。

認証 = Authentication (AuthN)相手が本当に申告された人であるかを確認すること。

認可 = Authorization (AuthZ)特定の条件で特定のリソースへのアクセスを許可すること。

認証連携 = Federated Authentication, Federated Identity, ID Federation, Federationサードパーティで行われた認証情報を受け取って、認証を実施する代わりにすること。アプリにとって認証を委譲していることになる。別の用語例：実現方法の例：SAML, OpenID, OpenID Connect

代理アクセス = Delegated Acccessユーザ合意の上で、サード−パーティがユーザの代わりにリソースへのアクセスを許可すること。ユーザにとって認可されている一部をサードパーティに委譲することになる。実現方法の例：OAuth

用語の確認（2/2）認証情報 = Credential認証をパスするために必要な情報のこと。具体例：ユーザ名とパスワード、IAMユーザのアクセスキーとシークレットアクセスキー

トークン = Token, Ticket認証をパスするために必要な情報で、一定期間のみ有効な情報のこと。具体例：IAMロールで割り当てられるアクセスキーとシークレットアクセスキーとトークン、

SAMLで認証後に発行されるSAML Assertion、JWT (Json Web Token)


本Webinarでの想定ユースケース３パターン

勝手に3分類

①コンシューマ向けWebサイト

典型的なWebサイト構成

WebのHTML生成はサーバサイドで実施

初回ユーザ認証後は、Cookieベースでの認証

ユーザの状態をセッションストアに保持

user001

********

login

ブラウザ

□□□Web+ 認証機能

ID/Passwodでの認証・Cookie発行

Cookieベースでの認証Cookie ユーザレポジトリ

＆セッションストア

Webサイト

①コンシューマ向けWebサイト初回認証、その後Cookieベース認証のイメージ

ID/Passwordでまず認証し、その後の通信ではCookie内のセッションIDを常に確認する。

初回アクセス、ID/Password認証ブラウザ： HTMLのフォームでID/Passwordを送信する。Webサーバ：ユーザストアにID/Passwordを確認するWebサーバ：セッションにログイン情報を反映する。Webサーバ：セッションIDが入ったCookieを含めて

HTMLコンテンツを返す。

2回目以降のアクセス、Cookieベースの認証ブラウザ：セッションIDが入ったCookieを含めてリクエストを送る。Webサーバ：セッションIDがログイン済みかセッションストアに確認する。Webサーバ：ログイン済みであればHTMLコンテンツを返す。

ブラウザ Webサーバ

user001

********

login

ユーザレポジトリ

セッションストア

1

4

5

1

7

2

3

6

234

567

Cookie


典型的なWebサイト構成

WebのHTML生成はサーバサイドで実施

初回ユーザ認証後は、Cookieベースでの認証

ユーザの状態をセッションストアに保持

user001

********

login

ブラウザ



Cookieベースでの認証Cookie ユーザレポジトリ

＆セッションストア

Webサイト

バックエンドシステムアプリの認証情報

でアクセス

API

サードパーティWebサイト

a f t g

サードパーティとの認証連携

SAML

○○○Web


内部や外部への認証連携


AWSのマネージドサービス

AWSリソースに直接アクセス

代理アクセスできるトークン発行

OAuth

トークンでAPIにアクセス

API



a f t g


OAuth


トークンでAPIにアクセス代理アクセスできる

トークン発行

バックエンド

SAMLバックエンドシステムアプリの認証情報

でアクセス

API

外部への認証連携


モバイルアプリ

ID/Passwodでの認証・トークン発行

トークンベースでの認証

API

API

トークン

シングルページ

アプリケーション

○○○ API

□□□ API+ 認証機能


②モバイルアプリやシングルページアプリケーションサーバサイドはAPIで実現

サーバサイドはステートレスな構成

モバイルアプリなどクライアントサイドの画面はJavaScriptで構成

初回ユーザ認証後は、トークンベースでの認証

②モバイルアプリやシングルページアプリケーション初回認証、その後トークンベース認証のイメージ

ID/Passwordでまず認証し、その後の通信ではトークンを付けてリクエストを行う。

初回アクセス、ID/Password認証アプリ：ユーザの入力したID/Passwordを取り出し

て認証APIに送信する。APIサーバ：ユーザストアにID/Passwordを確認する。APIサーバ：トークンを返す。

2回目以降のアクセス、Cookieベースの認証アプリ：トークンを付けてリクエストを送る。

APIサーバ：トークンを公開鍵暗号方などで検証する。APIサーバ：リクエストに応じてレスポンスを返す。

APIサーバ

ユーザレポジトリ1

3

4

1

6

2

23

456




5

③エンタープライズ企業の社内システム

SAML

user001

********

login

社員PC

Active DirectoryFederation Service(ADFS, IdP)

Acitve Directory

Linux/Unix系Webサーバ

インターネット

サードパーティSaaS


SAML対応Webサーバ

Webサーバ


SSO製品

社内での認証連携

Webサーバ

ID/Passwodでの認証

統合Windows認証/ Kerberos認証

SSOやパスワード同期を実現

複数パスワード管理の煩雑さやログインの手間を軽減する

PCやサーバにWindowsが多数使われるため、Windowsの認証機能を活用

認証連携はSAMLで実現

登場するサービスの概要紹介

AWS IAM (Identity and Access Management)

ユーザやロールに、何を行ってよいか記載されたポリシーを割り当てて制御する。

APIにアクセスする際に使用する認証情報は• アクセスキー• シークレットアクセスキー• トークン（有効期限ありの場合のみ）で構成されている。

AWSのサービスは認証情報をSigV4という方法で署名をAPIリクエストに毎回付けてアクセスする。

AWSのサービスへの認証と認可を管理するサービス

EC2起動、停止

S3アップロードダウンロード

ManagementConsole

ユーザ名・パスワード

AWS管理者・オペレータ

SDK

アクセスキー・シークレットアクセスキー

AWS CLI

>API

IAMユーザ

IAMロール

ユーザ、アプリ、

サービスなど

アクセスキー・シークレットアクセスキー・トークン

Amazon Cognito

Cognito User Poolアプリケーションにユーザー登録やサインイン機能を追加できる。

• パスワードやMFAを使ったユーザ認証、フェデレーションして認証

• 認証後に独自のアプリケーションでも検証可能なJWT形式のトークンが得られる

Cognito Federated IdentitiesIDプロバイダと認証連携して、ロールを使った一時的なAWS認証情報を得られる。

主にモバイル向けに認証機能を提供するサービス

Cognito Syncアプリケーションにデバイス間でユーザ出たの同期を実現できるサービスとライブラリ。

Amazon API Gateway

REST APIを実現するリバースプロキシとして動作

OS、キャパシティ等インフラの管理不要

認証・認可をメソッド単位で制御可能

• 標準：AWS認証情報

• カスタム：Lambdaで任意に実装可

APIに必要なスロットリング、キャッシュの機能を提供

バックエンドとしてLambda、既存Webシステムを利用可能

Web APIの作成・保護・運⽤と公開を簡単に


Webサイト

サービス

API Gatew

ay Lambda

API Gatewayキャッシュ

EC2 / Elastic Beanstalk

Webサービス

CloudWatchモニタリング

Lambdaカスタムオーソライザー


AWS上での実現パターン

user001

********

login

ブラウザ



Cookieベースでの認証

Cookie ユーザレポジトリ＆セッションストア

Webサイト

バックエンドシステムアプリの認証情報で

アクセス

API


a f t g


SAML

○○○Web







OAuth


API

①コンシューマ向けWebサイトID/Passwodでの認証・Cookie発行


→

user001

********

login

ブラウザ





認証はAWS上でも実装方法に違いは無し。ユーザレポジトリには以下のものが使用可。• Amazon DynamoDB• Amazon RDS

ユーザレポジトリ＆セッションストア

user001

********

login

ブラウザ





Webサイト


アクセス

API


a f t g


SAML

○○○Web







OAuth


API

①コンシューマ向けWebサイトブラウザからAWSリソースへのアクセス

→

S3とCloudFrontは認証の要否を設定でき、認証方法の１つとして署名付きURLを利用できる。

生成されたURLは、長いパラメータが付いていますが単なるURLのため、HTML内にリンク先やイメージのURL、ファイルのアップロード先に使用できる。

この方法は、Webサーバの負荷軽減、Webサーバのステートレス化に役立つ。

user001

********

login

ブラウザ



署名付きURLをサーバサイド生成することで直接アクセス• Amazon S3• Amazon CloudFront

例: https://s3-ap-northeast-1.amazonaws.com/tsujiy-

share/blackbelt.pdf?Signature=3qU6GYLrhaqUsAOZZs3%2BnkqEMFM%3D&Expires=1509937417&AWSAccessKeyId=AKIAI5WBYZZKWLQO7XVA

署名付きURLをリンク先に

■署名機能の違い

※ダウンロード回数制限や署名URLの失効はできない。URLの有効期限をかなり短くして、都度URLを生成する仕組みで対応するのがおすすめ。


S3 CloudFront ( + S3)

署名に必要な鍵 AWS認証情報（IAMユーザ、IAMロール）

CloudFrontキーペア

署名時に独自ドメイン名利用可（HTTPのみ）利用可（HTTPSも）

署名時に行える制限有効期限有効期限、開始日時、IPアドレス

署名時のスケーラビリティ

キーを適切に分散させればスケーラビリティが得られる

キャッシュによりさらに高いスケーラビリティが得られる（認証情報でURLが異なっていてもキャッシュ有効）

その他 - Cookieでも認証が可能で特定パス以下全体を許可するなどが可能

user001

********

login

ブラウザ





Webサイト


アクセス

API


a f t g


SAML

○○○Web







OAuth


API

①コンシューマ向けWebサイトアプリの認証情報でアクセス

→

EC2 インスタンスプロファイルを使うと EC2 インスタンス内で、AWS 認証情報を入手できる。パラメータストアでは、パスワードやDB接続文字列など任意の文字列を入手できる。

アプリケーションプログラムと認証情報を

分離できるため、パスワードなどの流出を防ぎやすくなる。

アプリと認証情報を分離し、安全に管理

• EC2 インスタンスプロファイル• EC2 Systems Manager パラメータストア


アクセス

API


user001

********

login

ブラウザ





Webサイト


アクセス

API


a f t g


SAML

○○○Web







OAuth


API

①コンシューマ向けWebサイトサードパーティとの認証連携

内部との認証連携

代理アクセス

→ AWS上でも実装方法に違いは無し。

user001

********

login

ブラウザ


a f t g


SAML




OAuth


API

SAML



a f t g



②モバイルアプリやシングルページアプリケーション



OAuth


トークンでAPIにアクセス AWSリソースに

直接アクセス


アクセス

API

バックエンド


API

API

トークン

○○○ API






API

トークン

○○○ API

API






ブラウザからAWSリソースへのアクセス

→ ユーザ認証・ユーザレポジトリ・トークン発行をサービスで実現• Amazon Cognito

Cognito


認証に関連する内容を一通りサービスで実現できるため、実装コストや期間を減らすことができる。

Eメールや携帯電話番号へのSMSを使ったMFAも可能。


Cognito User Poolを使用した場合のユーザ認証のおおまかな流れ

標準ではSecure Remote Passwordプロトコルという仕組みでユーザ名とパスワードが検証される。

アプリ：InitiateAuth APIを呼び出す。認証フローとしてUSER_SRP_AUTHを指定。

Cognito ：チャレンジを返す。チャレンジの種類としてPASSWORD_VERIFIERを返し、パスワードの検証を求める。

アプリ：RespondToAuthChallenge APIを呼び出す。パスワードを使って生成したチャレンジレスポンスを送る。

Cognito ：3種類トークンを返す。・IDトークン（JWT形式、クレーム情報と認証用）・アクセストークン（JWT形式、認証用）・更新トークン（他トークン更新依頼時用）

JWTトークン

CognitoUser PoolAPI (JSON)

http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html

初回アクセス、ID/Password認証

JWTトークン




user001

********

login

SDKiOS, Android, JavaScript

12

34

1

2

3

4

アプリ：独自のAPIを呼び出す。Cognitoから受け取ったJWTトークンをAPIサーバへの呼び出しに含める。

APIサーバ：JWTセットをダウンロードする。

APIサーバ：トークンを検証して、結果を返す。JWTセットに含まれる公開鍵でユーザから受け取ったJWTトークンの署名を検証して、OKであれば、リクエストされたAPIを処理して結果を返す。



API

http://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html#amazon-cognito-identity-user-pools-using-id-and-access-tokens-in-web-api

2回目以降のアクセス、独自APIサーバへのトークンベースの認証

APIサーバ




user001

********

login


JWTセット

JWTトークン

CognitoUser Pool

JWTトークンの検証は注意して実装

14

2 3

1

24

3

アプリ：API Gatewayを呼び出す。Cognitoから受け取ったJWTトークンをAPI Gatewayへの呼び出しに含める。

API Gateway：JWTトークンを検証して、Lambdaを呼び出す。

API Gateway ：結果を返す。JWTセットに含まれる公開鍵でユーザから受け取ったJWTトークンの署名を検証して、OKであれば、リクエストされたAPIを処理して結果を返す。



API

http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html

2回目以降のアクセス、API Gatewayへトークンベースの認証

API Gateway




user001

********

login


JWTトークン

13

1

2

3

2

Lambda



API

http://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-integrating-user-pools-with-identity-pools.html

2回目以降のアクセス、AWSリソースへの認証





user001

********

login


AWS認証情報

API

JWTトークン

アプリ：GetCredentialsForIdentity APIを呼び出す。Cognito User Poolから受け取ったJWTトークンをCognito Federated Identitiesに渡す。

Cognito ：AWS認証情報を返す。認証情報は一時的なもので、アクセスキー、シークレットアクセスキー、トークンで構成されている。

アプリ：AWS認証情報を使ってAWSの他のサービスにアクセスする。

AWSサービス：結果を返す。

CognitoFederated Identities

12

34

1

2

3

4



a f t g



②モバイルアプリやシングルページアプリケーションサードパーティとの認証連携

→



OAuth



直接アクセス


アクセス

API

バックエンド


API

API

トークン

○○○ API





トークン


a f t g

SAML

Amazon, Facebook, Google, SAMLとの認証連携をサービスで実現• Amazon Cognito

Cognitoサードパーティとの

認証連携

ユーザ認証に使用できるCognito User Poolで認証連携も行える。

※Cognito User PoolはOpenID Connect、Twitterには現時点で未対応。Cognito Federated IdentitiesはOpenID Connect、Twitterに対応しており、AWS認証情報を得られる。

SAML



a f t g






OAuth



直接アクセス


アクセス

API

バックエンド


API

API

トークン

○○○ API





トークン

API





ブラウザからAWSリソースへのアクセス

Cognitoで対応できない方法で実現したい場合→

以下のような場合、独自で認証を実現する事が考えられる。• クライアント証明書認証• 独自のMFA• 独自ポリシーのパスワード認証

独自に認証してAWSの認証情報を発行• AWS Security Token Service (STS)



a f t g



②モバイルアプリやシングルページアプリケーショントークンベースの認証

→



OAuth



直接アクセス


アクセス

API

バックエンド


API

API

トークン

○○○ API





標準でAWSの認証情報に対応しており、認証・認可をパスしたアクセスのみEC2やLambdaなどに送ることができる。

Custom Authorizerで独自のトークンにも対応できる。


API

API

AWSの認証情報を使った認証・認可をサービスで実現• Amazon API Gateway


a f t g

SAML




a f t g



②モバイルアプリやシングルページアプリケーション代理アクセス

→



OAuth



直接アクセス


アクセス

API

バックエンド


API

API

トークン

○○○ API





ユーザ認証に使用できるCognito User Poolで代理アクセスを実現できるOAuthプロコルに対応して、トークンをサードパーティWebサイトに提供も行える。


OAuth


API


OAuthを使った代理アクセス機能を実現• Amazon Cognito

Cognito

SAML

user001

********

login

社員PC


Acitve Directory






Webサーバ


SSO製品


Webサーバ



Acitve Directory


Active Directory (AD)

→

認証を利用するリソースをAWS上に配置するなどのユースケースでDirectory ServiceのMicrosoft ADを利用できる。

ただし、既存のADを完全にAWS上に置き換えたいなどの場合は、移行コストを考えるとEC2上のWindows Serverで実現する方が良い。

ADの構築運用をサービスで実現• AWS Directory Service• Amazon EC2 Systems Manager Config

user001

********

login

社員PC

Webサーバ統合Windows認証/ Kerberos認証

インスタンス作成時にドメインの自動参加

SAML

user001

********

login

社員PC


Acitve Directory






Webサーバ


SSO製品


Webサーバ




ID/Passwordでの認証



→ AWS上でも実装方法に違いは無し。

SAML

user001

********

login

社員PC








SSO製品


Webサーバ


組み合わせ: API Gateway + CloudFrontの署名Cookie認証あり静的Webサイトを実現• Amazon CloudFront + Amazon S3

Cookie


CloudFront S3

API Gateway Lambda

トークンでの認証・Cookie発行

トークン


Cognito

user001

********

login

ブラウザ

認証部分のみHTML+JavaScriptでクライアント部分を実装し、認証後はCookieを元に単純な静的Webサイトを提供できる。


a f t g


SAML

最後に

認証機能はセンシティブでユーザエクスペリエンスにも影響する。

マネージドサービスを使える所は使おう。

の組み合わせは特におすすめ。

Cognito APIGateway

参考URLS3 署名付きURLを使ったダウンロード/アップロード:http://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/ShareObjectPreSignedURL.htmlhttp://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/PresignedUrlUploadObject.html

CloudFront署名付きURL/Cookie:http://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.htmlhttp://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-cookies.html

EC2 インスタンスプロファイル:http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html

EC2 Systems Manager パラメータストア:https://aws.amazon.com/jp/ec2/systems-manager/parameter-store/http://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/systems-manager-paramstore.html

AWS re:Invent 2016: Serverless Authentication and Authorization (MBL306)https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-serverless-authentication-and-authorization-identity-management-for-serverless-architectures-mbl306

AWS re:Invent 2016: Add User Sign-In, User Management, and Security to your Mobile and Web Applications with Amazon Cognito (MBL310)https://www.slideshare.net/AmazonWebServices/aws-reinvent-2016-add-user-signin-user-management-and-security-to-your-mobile-and-web-applications-with-amazon-cognito-mbl310

オンラインセミナー資料の配置場所

AWSクラウドサービス活用資料集• http://aws.amazon.com/jp/aws-jp-introduction/

AWS Solutions Architect ブログ• 最新の情報、セミナー中のQ&A等が掲載されています• http://aws.typepad.com/sajp/

@awscloud_jp

検索

最新技術情報、イベント情報、お役立ち情報、お得なキャンペーン情報などを日々更新しています！

もしくはhttp://on.fb.me/1vR8yWm

公式Twitter/FacebookAWSの最新情報をお届けします

AWSの導入、お問い合わせのご相談AWSクラウド導入に関するご質問、お見積り、資料請求をご希望のお客様は以下のリンクよりお気軽にご相談くださいhttps://aws.amazon.com/jp/contact-us/aws-sales/

※「AWS 問い合わせ」で検索してください

AWS Well Architected 個別技術相談会のお知らせWell Architectedフレームワークに基づく数十個の質問項目を元に、お客様がAWS上で構築するシステムに潜むリスクやその回避方法をお伝えする個別相談会https://pages.awscloud.com/well-architected-consulting-2017Q4-jp.html

参加無料

毎週火曜・木曜開催

ご参加ありがとうございました

AWS Black Belt Online Seminar · 認証・認可をメソッド単位で制御可能 •...

Documents

Transcript of AWS Black Belt Online Seminar · 認証・認可をメソッド単位で制御可能 •...