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

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

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

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

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

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

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

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

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

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

39. Copyright© 2017 All rights reserved.39 暗号化:ログイン処理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に保存する

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

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

Masayuki Kato

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