Serverless AWS構成でセキュアなSPAを目指す

Copyright© 2016.All rights reserved.
Copyright© 2017 All rights reserved.
2017/01/17 ハンズラボ株式会社
Serverless Meetup Tokyo #2
Serverless AWS構成で
セキュアなSPAを⽬指す！

⾃⼰紹介
• 名前：加藤雅之
• 所属：ハンズラボ株式会社
• 担当：「AWSチームリーダー」
東急ハンズ
- AWSインフラ、IT統制
ハンズラボ外販
- AWS構築運⽤⽀援

Copyright© 2017 All rights reserved.3
ハンズラボ株式会社
• 情シス部⾨
Ø 東急ハンズの各種システムの内製開発と運⽤保守
• 外販
Ø ⾃社開発の経験を活かした受託開発、内製⽀援
東急ハンズのシステム⼦会社

APN Architecture of the Year 2015 受賞
• AWS Partner Networkの利用アーキテクチャが
「最も先進的、または実用的、チャレンジングなもの」
が選ばれる

東急ハンズポイントシステム
• ミッションクリティカルなポイントシステムを、
AWSクラウドネイティブにて構築

AWS Samurai 2015をCEO⻑⾕川が受賞
• AWSのユーザーコミュニティに貢献した方が選ばれる

今⽇お話する内容

過去に作成したSPAなServerlessシステムの知⾒をベースに、
よりセキュリティを意識した、別バージョンのシステム

の紹介ではなく
東急ハンズの考え⽅「ここは、ヒント・マーケット」
何を売るところですか？とたずねられたら、
「それはヒントです！」と言い切りたい。
そう、ここには「できあいの答え」は、ひとつも置いてありません。
全フロアが、何かをつくりたい人、はじめたい人にとっての
「きっかけ売り場」であり、「発想の一歩目」である。
モノ・コト・ヒトのすべてが出会い、
すべての新しい価値がそこから生み出される、うれしい場所へ。
東急ハンズHP 「ここは、ヒント・マーケット」とは？
https://www.tokyu-hands.co.jp/saiyo/shinsotsu/about/
そんな思いを Serverless Meetup Tokyo にも

セキュアなSPAを作成する様⼦を
順を追っていきます！

ちなみに過去に作成した Serverless Point System

それは唐突に起こった
ねぇねぇ加藤くん。
ちょっといいかい？
n開発・テストも落ち着きつつある2015年年末頃
忍び寄る大きな影

それは唐突に起こった
ねぇねぇ加藤くん。
ちょっといいかい？
このプロジェクト
中止ね
n開発・テストも落ち着きつつある2015年年末頃

⼤⼈の事情により、
使われる事がないポイントシステムが完成

システムに罪はない

気を取り直して
Let's cook !
そんなノウハウが詰まった

まずはSPAのベースとなる静的サイト
nHTMLやJavascript、画像ファイル等をS3へ設置
nより多くのアクセスに耐えられるようにCloudfrontで
CDN化。同時にS3へのアクセスはCloudfrontからしか
取得出来ない様に

ドメインの取得とSSL証明書の設置
nRoute 53を使⽤してドメインの取得とDNS登録
nAWS Certificate Managerにて証明書の作成と
Cloudfront への設置

静的なServerless の完成
これも⽴派なServerless！

次は動的な情報をJSONで返すAPIの⼊り⼝
nAPI GatewayからAPIを作成
nCORS(Cross-Origin Resource Sharing) 設定を忘れずに
l SPAとは異なるドメインになるのでCORSの有効化を
⾏う

動的な情報を処理するFunction
nAPI Gatewayから呼び出されるバックエンドにはみん
なが⼤好きなLambda
n実⾏権限（Role）は必要最低限

動的な情報を保持しているデータストア
nDynamoDBのテーブル作成
nLambdaの実⾏RoleにDynamoDBへのRead/Write権
限を付与
nDynamoDBからデータ取得するLambda、データを保
存するLambdaをそれぞれ作成。

API Gateway 周りをちまちまと
nAPI Gateway に適切なリソースやメソッドでLambda
を紐づけ
l RESTful APIな思想にて
nデプロイを⾏いJavascript のSDK⽣成を⾏う
l SDKはSPAのS3へ保存
nSPA側でAPI呼び出しと⾮同期処理

XSS対策のためにAWS WAF
nAWS WAF をAPI Gateway の前に挟む
※AWS WAFはAPI Gatewayに直接つかないので、
Cloudfront経由になる

動的でセキュアなServerless SPAの完成
らしくなって参りました

いよいよ個別ユーザー機能
nCognito で⽤意されているUser Pools（ユーザー認証基
盤）を使⽤しても良いが、今回はFederated Identitiesに
ついて
nFederated Identitiesには認証機能は付いておらず認可を
⾏う。認可元はOpenIDやSAML等を選べるが、今回は⾃
分で作成するCustum Provider（通称Developer
authenticated identities ）とする

Developer Authenticated Identityの仕組み
n認証フローは複数あるが拡張認証フローを使⽤する。
⾃作ユーザーとCognitoのユニークなIdentityが対になっ
ていて、ユーザーは受け取ったTokenを使⽤してAWS
STS からAWSリソースに対するCredentialを受け取る。

Cognitoの登録
nFederated identitiesよりidentity poolを作成
l Authentication providersはcustumでユニークな
provider nameにする
l 認証済みのRole auhenticated identitesをデフォルト
で作成

ユーザー登録Lambda
nID/PASSのユーザー登録Lambdaを作る
l DynamoDB ユーザーTableへIDとPassを保存

ユーザー認証Lambda
n登録ユーザーの認証を⾏うログイン処理Lambdaを作る
l ID/Passの検証し、作成したCognito identity pool へ
getOpenIdTokenForDeveloperIdentityを⾏う。

クライアント処理とセンシティブなAPIの保護
n返却されたCognito Tokenをクライアントに保存
ngetCredentialsForIdentityを使⽤して、AWS STSから
Credential（accessKey / secretKey / sessionToken）
の取得して、apigClient.credentialに保存
nセンシティブなAPIのメソッドに対してAWS_IAMの認証
設定
nCognitoのAuthenticateRoleに上記のメソッドarmを許
可設定

ユーザー認証付きのセキュアなServerless
しかし問題が。。。

有効期限に注意
nSTSのCredential有効期限は最⼤１時間
l Cognito Tokenで再取得
nCognito Tokenの有効期限は最⼤24時間
l ID とパスワードを送れば再取得可能だが、クライアン
トに保管するわけにはいかない
nログインをそれ以上維持させたい場合
l 独⾃認証部分の永続の為にToken化

ならば Json Web Token
nHeaderとPayloadとSignatureという3つのセグメントか
ら構成される Token
１ Header
署名アルゴリズムなどを含むJSON
２ Payload
実際に送信したいJSONデータそのもの
３ Signature
HeaderとPayloadをBase64エンコードしたのちに、
“.” で連結した文字列に対して、
Headerに指定されたアルゴリズムで署名

JWTの何が良いのか？
nセッションや単なるTokenとの⼤きな違いは、 Payloadに
クライアントに渡しても良いデータ（ユーザーID等）を
記載するので、疎結合となっているServerlessにとっては
データ使い回しの勝⼿が良い。
nクライアントとAPI側でTokenのやり取りがあるが、もし悪
意あるユーザーが書き換えを⾏なっても、 Signature部分
にてチェックを⾏える。
- 復号できなければ不正なTokenとなる
nCognitoのTokenもJWTで構成されている
l クライアント側でのTokenの取り回しが共通化

実際のJWT(Cognito)

独⾃ Json Web Tokenの準備
nPayloadはユーザーに渡しても良い使い回す情報を⾃由
（JSON形式）に記載
nHeaderはtyp:JWTのalg:HS512（ SHA-512 hash ）
nSignatureに使うキーは可能であれば別々にしたい
l 漏れた場合に別のユーザーになり済ませてしまう
- KMS（Key Management Service）を使⽤

Key Management Service
nマスターキーとデータキーがある
l 実際のデータを暗号/復号化するのはデータキーだが、
データキー⾃体の⽣成と復号化をできるのはマスター
キーとなっている。マスターキーの⽣データは取得す
る事が出来ない。
nマスターキーはIDしか無いので、暗号/復号化する
LambdaのRoleだけにデータキー操作の権限を付与すれ
ば、マスターキーIDがあっても開発者でさえ復号化する
事が出来ない。
- データキーをJWTのsignatureで使⽤するハッシュ
キーとする

暗号化:ログイン処理LambdaにJWT作成追加
nマスターキーIDを元にgenerateDataKeyで、⽣データ
キーと暗号化データキーを取得する。
n準備していたJWTのHeaderとPayloadを、それぞれBase64
エンコードしてピリオドでつなぎ、取得した⽣データ
キーをsha2ハッシュ値としてして暗号化したものが
signatureとなり独⾃JWTが完成
n該当Lambda RoleにKMSの実⾏権限を付与
n最終的にCognito Tokenと独⾃JWTが返却となる。
独⾃JWTの有効期限についてはAPI側とクライアント側で
⾃由に合わせる。
n⽣データキーは即時に削除し、暗号化データキーをユー
ザーと紐付けてDynamoDBに保存する

復号化：独⾃JWTの検証Lambdaの作成
n独⾃JWTの正当性を検証する為に、KMSへの復号化権限
を持ったRoleがついたLambdaを作成
nTokenの有効期限内であれば、マスターキーIDとユーザー
に紐付いている暗号化データーキーを元にkms.decryptを
⾏い、⽣データキーを取得する。
nJWTの HeaderとPayloadを、それぞれBase64エンコードし
てピリオドでつなぎ、取得した⽣データキーをハッシュ値
としてして暗号化したものが、signatureと⼀致すれば正
当なTokenとなる

認証を⾏いたいAPIへ実装
nAPI GatewayにてオーソライザーとしてLambdaを登録し、
検証を⾏いたいメソッドにて認証として選択
n認証が必要なAPIを呼び出す際には、クライアントで保管
している独⾃JWTをヘッダーに組み込んでコールする

セキュアなSPA で良い感じなServerless

Cognitoでこんなセキュアな事も
n⾃分のデータにはアクセス出来るが、他の⼈のデータへ
はアクセス出来ない
nS３プレフィックスやDynamoDB ファイングレインアク
セスにて、${cognito-identity.amazonaws.com:sub} 変数が可
能になる

ありがとうござました
何かのきっかけやヒントになればうれしいです

エンジニア募集中！
求むエンジニア！
ハンズラボは積極的に技術者採用中です。

Serverless AWS構成でセキュアなSPAを目指す

More Related Content

Serverless AWS構成でセキュアなSPAを目指す