グループウォレットアプリ6gramの運用をはじめてみた / 6gram SRE NEXT 2020

by ryosan470

Slide 1

Slide 1 text

グループウォレットアプリ 6gram の運⽤をはじめてみた SRE NEXT 2020 株式会社ミクシィ ID・ペイメント事業部佐藤良祐 2020/01/25

Slide 2

Slide 2 text

⾃⼰紹介佐藤良祐 (@ryosan-470 / @jtwp470) 株式会社ミクシィ ID・ペイメント事業部 2017年4⽉⼊社 ‣ ~ 2019/04 モンスターストライク⽇本版SRE ‣ 2019/04 ~ 新規の決済系サービス「6gram」や社内決済基盤の開発と運⽤

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

「6gram」サービス紹介ひとりでも、グループでも使うことのできるウォレットサービスグループに⼊れたお⾦をシェアしたり、インスタントに発⾏したプリペイドカードに残⾼を割り付けたりといろんな使い⽅ができる ‣ JCB プリペイドカードを1アカウントで複数枚発⾏できる ‣ ApplePay / GooglePay と連携して QUICPay+ 決済 ‣ iOS ではコンタクトレス決済に対応 ‣ リアルカードも発⾏予定 2019年11⽉にAndroid版を先⾏リリース ‣ 現在は完全招待制

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

iOSは審査中 (もうしばらくお待ちください)

Slide 7

Slide 7 text

今⽇は配布物の中に招待コードあります！ QRコードを読み取って是⾮使ってくださいー

Slide 8

Slide 8 text

もくじ決済サービスの基礎的な概念 PCI DSS 完全準拠の⼯夫 6gram システム構成開発、運⽤体制課題

Slide 9

Slide 9 text

決済サービスの基礎的な概念 (出⾦ / カード発⾏、管理) ユーザー加盟店アクワイアラ国際ブランドクレジットカード決済イシュアカード発⾏業務加盟店管理 VISA / JCBなど ISO8583形式の電⽂でやりとり ISO8583形式の電⽂でやりとり

Slide 10

Slide 10 text

決済サービスの基礎的な概念 (⼊⾦ / 決済代⾏) ユーザーアクワイアラ国際ブランドクレジットカードによる⼊⾦加盟店管理 VISA / JCBなど ISO8583形式の電⽂でやりとり ISO8583形式の電⽂でやりとりイシュア決済代⾏

Slide 11

Slide 11 text

決済サービスの基礎的な概念 (まとめ) 「出⾦」と「⼊⾦」の両⽅とも⾃社でシステムを実装「出⾦」では、プリペイドカードの発⾏、管理「⼊⾦」では、ユーザーが⼊⾦するために必要なカード情報を保持 ⇨ これらをサポートするためには、「PCI DSS」に準拠しなければならない

Slide 12

Slide 12 text

PCI DSS とは? クレジットカード業界のセキュリティ基準これに準拠することにより、カード番号などの情報を保持することができる 12要件、約400項⽬数年に⼀度、基準が改訂される

Slide 13

Slide 13 text

PCI DSS 完全準拠の⼯夫

Slide 14

Slide 14 text

アカウント要件要件8 コンピュータにアクセスできる各ユーザーに⼀意のIDを割り当てる ‣ 8.2.3 パスワードは以下を満たす必要がある ‣ パスワードに7⽂字以上含まれる ‣ 数字と英⽂字を両⽅含む ‣ 8.2.4 パスワードは少なくとも90⽇ごとに変更する ‣ 8.2.5 これまで使⽤した最後の4つのパスワードのいずれかで同じである新しいパスワードを許可しない

Slide 15

Slide 15 text

アカウント要件パスワード管理めんどくさいなぁ

Slide 16

Slide 16 text

セキュリティ要件要件5 すべてのシステムをマルウェアから保護する ⇨ 稼働中のサーバーにウイルスチェックなどが必要要件11 セキュリティシステムおよびプロセスを定期的にテストする ‣ 11.4 侵⼊検知/侵⼊防⽌システムを使⽤して警告する ‣ 11.5 変更検出メカニズムを導⼊してファイル変更を監視、警告する

Slide 17

Slide 17 text

セキュリティ要件ウイルス検知ソフトウェア、侵⼊検知ソフトウェアが落ちてもインシデント

Slide 18

Slide 18 text

われわれの⼤⽅針 ⇨ 運⽤負荷をできるだけさげたい

Slide 19

Slide 19 text

インスタンスを使わない

Slide 20

Slide 20 text

インスタンスを使わない

Slide 21

Slide 21 text

インスタンスを使わないことで何が嬉しいかアカウント管理をIAMに集約しやすい 90⽇に1回のパスワード変更祭り (しかも4回分は使えない) をしなくてすむ管理すべきコンポーネントを減らすことができる運⽤負荷を下げるために重要

Slide 22

Slide 22 text

さらに

Slide 23

Slide 23 text

コンテナをRead Only で動かす

Slide 24

Slide 24 text

Slide 25

Slide 25 text

インスタンスレス + Read Only で何が嬉しいか侵⼊検知の仕組みを導⼊する必要がないリモートコンソールが存在しないためそもそも侵⼊できないファイル変更検出ソフトウェアが不要になる Read Only なのでそもそも書き換えができない

Slide 26

Slide 26 text

コンテナをRead Only で動かす⼯夫コンテナはAWS Fargate上で動かしているコンテナは Read Only で稼働させている ‣ 具体的には、ECSタスク定義の readonlyRootFileSystem を true にしている⼯夫点 ‣ ログはファイルを作成せず、標準出⼒に ‣ 起動時に作成されるディレクトリはあらかじめ作成しておく

Slide 27

Slide 27 text

クレジットカード情報の保有についての制約要件3 保存されるクレジットカード情報を保護する ‣ 3.4 クレジットカード情報は暗号化などの仕組みを⽤いて保存する ‣ 3.5.2 クレジットカード情報へのアクセスを必要最低限に制限する ‣ 3.5.3 暗号化に使⽤される鍵の保存要件7 クレジットカード情報へのアクセスを制限する要件10 クレジットカード情報へのアクセスを追跡、監視する

Slide 28

Slide 28 text

クレジットカード情報の保有についてクレジットカード情報をはじめとするすべてのデータをDynamoDBに保存 AWSには ‣ IAMをベースとした細かいアクセス制御 ‣ KMSによるテーブルの透過的暗号化さらにスケーリングや管理をすべてAWSにお任せできる運⽤をはじめて、DynamoDBを起因とする障害は今の所ない

Slide 29

Slide 29 text

その他の⼯夫点

Slide 30

Slide 30 text

定時実⾏処理バッチ処理には CodeBuild を使⽤売上データを取得、オーソリゼーション業務などの定時処理をすべてCodeBuildで採⽤理由 ‣ AWS Batch は裏でEC2が爆誕するからだめ ‣ Lambdaは実⾏時間が短すぎる ‣ Fargate で「タスクを動かす」は⼀部やっていたがリトライなどを⼿動でやるのが⼤変だった ‣ さらに「読み取り専⽤」環境では動かないソフトウェアがあった

Slide 31

Slide 31 text

リリースパイプラインの⾃動化 CodePipeline と CodeBuild を組み合わせたリリースパイプラインの構築リリースの障壁をできる限り下げ、アジリティーを確保コンテナイメージのビルドと ECRへのプッシュコンテナイメージウイルススキャン Fargateへのブルーグリーンデプロイ要件5 のウイルススキャンを満たす

Slide 32

Slide 32 text

「6gram」システム構成図

Slide 33

Slide 33 text

「6gram」システム構成 ‣ 開発⾔語: Elixir ‣ ⼀部 DynamoDB Streams を経由した NodeJS や解析環境で Python など ‣ インフラ: AWS ‣ データベース: DynamoDB ‣ コンピュート: Fargate ‣ 監視: CloudWatch、Rollbar ほぼすべてのコンポーネント (⼊出⾦処理、カード会社とのやりとり) は内製 ‣ なぜ内製しているのか、Elixir採⽤理由などは、Developer Boost 2019の「Elixirで決済サービスを作ってみた」を！ https://speakerdeck.com/enerick/elixir-dejue-ji-sabisuwotukututemita

Slide 34

Slide 34 text

PCI DSS 完全準拠の⼯夫まとめ少⼈数で運⽤していくためにできる限り運⽤負荷を減らす努⼒をしているフルマネージドサービスを使うことで簡単に⾼い信頼性を確保できるアプリケーションの改善に注⼒できる

Slide 35

Slide 35 text

開発、運⽤体制

Slide 36

Slide 36 text

開発、運⽤体制チーム構成エンジニアリングマネージャ 1名サーバーサイドエンジニア 5名クライアントエンジニア 2名 SRE といった専⾨職ロールは存在せず、全員で開発、運⽤を⾏っている

Slide 37

Slide 37 text

運⽤の⼯夫 (エラーの通知) Rollbar を⽤いて、対処する必要があるものに対してはSlack通知具体的に responder が何をすればいいか記載しておくことで素早い対処が可能

Slide 38

Slide 38 text

運⽤の⼯夫 (インシデント対応計画) インシデント対応計画シミュレーションの実施 (年に1回程度) サイバー攻撃、セキュリティに関連するバグ、インフラストラクチャのバグなどの条件を机上でシミュレーションするインシデントハンドリングを経験、改善点などの気づきが得られる

Slide 39

Slide 39 text

課題

Slide 40

Slide 40 text

課題可観測性が低い現状では細かいトレーシングやログなどを取りきれていない分散トレースなどがほしい⾃動化を突き詰めていく⼈間の判断をできるかぎり減らす開発環境をより本番環境に近づけていく決済ネットワークとのつなぎこみを含め開発環境だけで再現できる領域を増やしていきたい

Slide 41

Slide 41 text

No content