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

ハンズラボ株式会社

• 情シス部⾨Ø 東急ハンズの各種システムの内製開発と運⽤保守

• 外販Ø ⾃社開発の経験を活かした受託開発、内製⽀援

東急ハンズのシステム⼦会社


APNArchitectureoftheYear 2015受賞

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


東急ハンズポイントシステム

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


AWSSamurai2015をCEO⻑⾕川が受賞

• AWSのユーザーコミュニティに貢献した方が選ばれる


今⽇お話する内容




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



の紹介ではなく

東急ハンズの考え⽅「ここは、ヒント・マーケット」

何を売るところですか？とたずねられたら、「それはヒントです！」と言い切りたい。

そう、ここには「できあいの答え」は、ひとつも置いてありません。

全フロアが、何かをつくりたい人、はじめたい人にとっての

「きっかけ売り場」であり、「発想の一歩目」である。

モノ・コト・ヒトのすべてが出会い、すべての新しい価値がそこから生み出される、うれしい場所へ。

東急ハンズHP 「ここは、ヒント・マーケット」とは？https://www.tokyu-hands.co.jp/saiyo/shinsotsu/about/

そんな思いを Serverless Meetup Tokyo にも



Serverless AWS構成でセキュアなSPAを作成する様⼦を

順を追っていきます！


ちなみに過去に作成した Serverless PointSystem


それは唐突に起こった

ねぇねぇ加藤くん。ちょっといいかい？

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-OriginResourceSharing) 設定を忘れずに

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 ）とする


DeveloperAuthenticatedIdentityの仕組み

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


Cognitoの登録

nFederated identitiesよりidentity poolを作成l Authentication providersはcustumでユニークな

provider nameにするl 認証済みのRole auhenticated identitesをデフォルト

で作成


ユーザー登録Lambda

n ID/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データそのもの

３ SignatureHeaderと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を目指す

Software