ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)

Transcript

1. ZOZOにおける
 ID基盤のk8sへのリプレイスと
 セキュリティの取り組み
 
 株式会社ZOZOテクノロジーズ
 SRE部
 リーダー　瀬尾 直利
 エンジニア　亀井 宏幸


   Copyright © ZOZO Technologies, Inc.

2. © ZOZO Technologies, Inc. 瀬尾 直利 (そのっつ)
 株式会社ZOZOテクノロジーズ 2019年1月入社 SREスペシャリスト

   SRE部 ML-SRE リーダー 兼 SRE部 プラットフォームSRE リーダー 兼 CSIRT Twitter/GitHub: @sonots CRuby、Fluentd コミッタ 2

3. © ZOZO Technologies, Inc. https://zozo.jp/
 • 日本最大級のファッション通販サイト
 • 1,300以上のショップ、7,400以上のブランドの取り扱い（ともに2019年12 月末時点）


   • 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など
 3

4. © ZOZO Technologies, Inc. アジェンダ
 • ZOZOTOWNリプレイスの全体感 (そのっつ)
 • ID基盤の概要

   (以降、亀井)
 • 更新系ワークロードのリプレイス方法
 • AWS/EKSで実施したセキュリティへの取り組み
 • 課題と今後
 4

5. © ZOZO Technologies, Inc. ZOZOTOWNリプレイス 5

6. © ZOZO Technologies, Inc. 6 2004年 ZOZOTOWN オープン

7. © ZOZO Technologies, Inc. 7 ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた

8. © ZOZO Technologies, Inc. IIS (Web) RO iOS Android ブラウザ

   PC/SP リプレイス開始前: 〜2017年 ストアド ストアド ストアド 8 IIS (API) ロジックがDBに載ってい る（ストアド） 成功 • データの近くで処理を行うため高速（特に2005年 当時はネットワークが細い) • ロジックをDBに載せることでDRYにできる 課題 • ストアドをスケールさせづらい • ストアドのテストが書きづらい • レガシー VBScript • Windows Server の構築自動化が難しい • 現実問題、ASPレイヤーで２重管理になっている ロジックは存在する

9. © ZOZO Technologies, Inc. 9 2017年4月

10. © ZOZO Technologies, Inc. 10 2017年当時のリプレイス計画

11. © ZOZO Technologies, Inc. Java API Read Only SQL ストアドをら

    はがしてAPI に移設 第１フェーズ: 2017年〜2020年 参照系ロジックのストアド剥がし 11 IIS (Web) RO iOS Android ブラウザ PC/SP ストアド ストアド ストアド Read Only IIS (API) DBレプリ 課題 • ASPレイヤーのロジックがそのまま • 更新系のリプレイスが未計画 • オンプレIISが入り口のままであるためオ ンプレを卒業できない設計 Read Only 成功 • ストアドロジックが減った • クラウドに移設したことでスケーラビリティ を手にいれた (ECサイトは参照リクエスト が圧倒的に多い) ZOZO DC クラウド

12. © ZOZO Technologies, Inc. 既存の課題解決と ZOZOTOWNリプレイスを加速させるため 新アーキテクチャと新体制 の計画をスタート 12 2020年1月

    そのっつ参画

13. © ZOZO Technologies, Inc. リプレイスプロジェクト加速にあたって必要なこと • リプレイスの目的の統一 • 最終的なアーキテクチャのイメージの刷新 •

    リプレイス作業への開発リソース確保 13

14. © ZOZO Technologies, Inc. 改めて目的を再確認。 なぜリプレイスするのか 14

15. © ZOZO Technologies, Inc. 改めて目的を再確認。なぜリプレイスするのか ZOZOTOWNの成長のため スピード をあげる コスト をさげる

    人材 をふやす これらを達成できる組織にする 15

16. © ZOZO Technologies, Inc. 2020年度、リプレイスプロジェクトで進めること まず、変更しやすくしたい。 1. ストアドはがし（継続） 2. マイクロサービスの立ち上げ

    16

17. © ZOZO Technologies, Inc. 新フレームワーク ロジック （Web表示のみ） 商品 サービス RO

    お気に入り サービス RW メンバー サービス RW ネイティブアプリはAPI 直呼び出し ブラウザ PC/SP iOS Android WebのUIに 新技術が使える ようになる それぞれのAPIが 独立したサービスに = マイクロサービス化 API Gateway ID認証 サービス RW 17 第２フェーズ: 目指す姿

18. © ZOZO Technologies, Inc. 商品 サービス RO お気に入り サービス RW

    メンバー サービス RW API Gateway ID認証 サービス RW 18 IIS (Web) RO ブラウザ PC/SP ストアド ストアド ストアド IIS (API) ZOZO DC 第２フェーズ (2020年〜進行中) 切り替え方法 (ストラングラーパターン) iOS Android 切り替え 切り替え DBレプリ クラウド

19. © ZOZO Technologies, Inc. この1年でマイクロサービスの完成形テンプレートを作る 19

20. © ZOZO Technologies, Inc. アーキテクチャを反映した、開発しやすい組織体制に移行 新フレームワーク ロジック （Web表示のみ） ユーザー サービス

    RO お気に入り サービス RW 商品 サービス RW API Gateway ID認証 サービス RW 20

21. © ZOZO Technologies, Inc. 組織 21 「マイクロサービスは組織論である」

22. © ZOZO Technologies, Inc. ECプラットフォーム部 / プラットフォームSREの設立 (4月) EC開発本部 ZOZOTOWN

    フロントエンド バックエンド アプリ ZOZO 技術開発本部 ECプラットフォーム部 基幹 MSP USED CHINA SRE部 検索 マイグレーション API基盤 推薦基盤 サービス MLOps MA BtoB USED PF-SRE グロース EC開発本部と一緒にマイクロサービス化を進めていく 22

23. © ZOZO Technologies, Inc. • 我々は、ZOZOTOWNがこれからも成長を続けるために、開発効率・運用性・ 堅牢性・柔軟性・回復性の確保を見据えて、技術面でも環境面でもクラウドネイ ティブに刷新するための取り組みを進めます。 • 巨大でピーク性のある大規模ECシステムを、最適なアーキテクチャをチームで

    思い描きながら設計・構築・リリース・運用まで一環して行い ZOZOTOWN の 成長を加速させることがミッションです。 23 23 プラットフォームSREのミッション


24. © ZOZO Technologies, Inc. • マイクロサービスプラットフォーム Kubernetes クラスタの設計 • API

    Gateway 経由のアーキテクチャに変更 • ID基盤のリリース (更新系リプレイス第一弾) • 第一弾として検索機能を Front API から切り出してマイクロサービス化 24 プラットフォームSRE今期 (2020年4月〜9月)
 24

25. © ZOZO Technologies, Inc. 25 25 2020年3月

26. © ZOZO Technologies, Inc. 26 26 ＊マルチクラウドやめました 今期目標

27. ZOZOにおける
 ID基盤のk8sへのリプレイスと
 セキュリティの取り組み (後半)
 
 株式会社ZOZOテクノロジーズ
 SRE部
 リーダー　瀬尾 直利
 エンジニア　亀井

    宏幸
 Copyright © ZOZO Technologies, Inc.

28. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 SRE部
 亀井 宏幸
 2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN のオンプレサーバ運用を経て


    2019年9月にPF-SREチームへ、
 パブリッククラウド・k8sを初体験しながら
 ZOZOリプレイスに携わっている。
 28

29. © ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ
 SRE部
 亀井 宏幸
 2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN のオンプレサーバ運用を経て


    2019年9月にPF-SREチームへ、
 パブリッククラウド・k8sを初体験しながら
 ZOZOリプレイスに携わっている。
 29

30. © ZOZO Technologies, Inc. アジェンダ
 • ZOZOTOWNリプレイスの全体感 (そのっつ)
 • ID基盤の概要

    (以降、亀井)
 • 更新系ワークロードのリプレイス方法
 • AWS/EKSで実施したセキュリティへの取り組み
 • 課題と今後
 30

31. © ZOZO Technologies, Inc. お話ししないこと
 • アプリケーションの説明
 • k8sクラスタの構築内容
 •

    IaC、CI/CDの手法
 31

32. © ZOZO Technologies, Inc. ID基盤の概要
 32

33. © ZOZO Technologies, Inc. の前に、API Gateway について
 33

34. © ZOZO Technologies, Inc. API Gateway
 • API の Gateway

    となるマイクロサービス
 • マイクロサービス化にあたりID基盤に先行してリリース済み
 • API コントローラー、SSL終端 などの役割をもつ
 
 34 新フレームワーク ロジック （Web表示のみ） ユーザー サービス RO お気に入り サービス RW 商品 サービス RW API Gateway ID認証 サービス RW これ

35. © ZOZO Technologies, Inc. API Gatewayは自前で実装
 • AWS にはマネージドサービスの API

    Gateway がある
 • 複雑な要求に柔軟に対応するために自前実装
 ◦ エンドポイントを複数もつサービス(マルチクラウド/マルチクラスタ)に対し、
 エラーやタイムアウト時に別エンドポイントへのリトライ
 ◦ ヘッダー (Client-Token) によるクライアント認証機能
 など
 • AWS/EKSで構築
 35

36. © ZOZO Technologies, Inc. 改めて、ID基盤とは
 36

37. © ZOZO Technologies, Inc. ZOZOTOWN におけるID基盤
 • ZOZOTOWN は ZOZO

    ID という認証システムがある
 • ID基盤は ZOZO ID のモダン化リプレイスプロジェクト
 • PF-SRE のマイクロサービス第二弾 (話せば長くなる)
 37

38. © ZOZO Technologies, Inc. ID基盤の特徴
 • 更新系ワークロードを扱う
 ◦ 更新系 :

    会員登録/更新/退会() ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など
 • 個人情報も扱う
 ◦ email
 ◦ password
 ◦ phone
 38

39. © ZOZO Technologies, Inc. ID基盤の特徴
 • 更新系ワークロードを扱う
 ◦ 更新系 :

    会員登録(insert)/更新(update)/退会(delete ) ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など
 • 個人情報も扱う
 ◦ email
 ◦ password
 ◦ phone
 39 ZOZOTOWNにおける
 更新系ワークロードの
 リプレイス第一弾


40. © ZOZO Technologies, Inc. ID基盤の特徴
 • 更新系ワークロードを扱う
 ◦ 更新系 :

    会員登録/更新/退会() ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など
 • 個人情報も扱う
 ◦ email
 ◦ password
 ◦ phone
 40 高セキュリティの
 インフラが求められる


41. © ZOZO Technologies, Inc. 求められた要件
 • クラウドネイティブ化
 • マイクロサービス化
 •

    CI/CD (Continuous Integration / Continuous Delivery) 化
 • IaC (Infrastructure as Code) 化
 • 開発ガイドライン(社内ガイドライン)のセキュリティ要件の遵守
 41

42. © ZOZO Technologies, Inc. 従来のアーキテクチャ
 • オンプレミスで構成されていた
 42 FW /

    WAF Load Balancer オンプレミス Web Server (IIS) DB Server (SQL Server) • 巨大でモノリシック
 • Web Server は Classic ASP で実装さ れ 多数の細かいサービスが混在
 • DB Server は 用途ごとに物理的にイ ンスタンスが分割されているものの、 多数の細かいサービス用のテーブル が混在
 ※簡易的なアーキテクチャ図です
 TCP : xxx

43. © ZOZO Technologies, Inc. ID基盤の全体アーキテクチャ
 • AWS で構成している
 43 API

    Gateway ID基盤 VPC1 VPC2 Peering ALB ALB EKS Cluster2 EKS Cluster1 • マイクロサービスアーキテクチャ
 • 極力マネージドサービスを利用
 ◦ ALB
 ◦ EKS
 ◦ Aurora MySQL
 • API Gateway と
 AWSアカウントを分離(後述)
 Account1 Account2 Aurora MySQL ※簡易的なアーキテクチャ図です
 HTTP

44. © ZOZO Technologies, Inc. ID基盤のソフトウェアスタック
 44 • アプリケーション
 ◦ Golang


    • インフラ(AWS)
 ◦ Route 53
 ◦ Application Load Balancer (ALB)
 ◦ Elastic Kubernetes Service (EKS)
 ◦ Aurora MySQL
 Route 53 ALB EKS Aurora MySQL CloudFormation CloudWatch APM slim

45. © ZOZO Technologies, Inc. EKS (Elastic Kubernetes Service)
 • AWS

    のフルマネージド型の Kubernetes (以後 k8s) サービス
 • コントロールプレーンの管理は不要
 • EC2マネージドノードグループを採用することで、
 ワーカーノードの構築、運用負荷も最小限
 • k8s のメリットを享受できる
 ◦ オートスケールや自動修復
 ◦ コントローラーによる高い拡張性・柔軟性
 
 クラウドのメリットを最大限活用するため、EKSを採用
 45

46. © ZOZO Technologies, Inc. Aurora MySQL
 • フルマネージド型でMySQL互換のRDSサービス
 • 高い可用性


    ◦ データは99.99%の可用性
 ◦ レプリカへのフェイルオーバーは約30秒程度
 • LTS (Long Time Support) バージョンが用意されており
 最低限のバージョンアップ頻度としダウンタイムを最小化できる
 
 
 MySQL互換であり高い可用性から、Aurora MySQLを採用
 
 46

47. © ZOZO Technologies, Inc. ID基盤概要 のまとめ
 • ID基盤 = 新

    ZOZO ID
 • オンプレ→クラウドへ、初の更新系リプレイス
 • マイクロサービス 第二弾
 • AWS/EKS/Aurora で構築
 • API Gateway と AWS アカウントを分離(後述)
 47

48. © ZOZO Technologies, Inc. 更新系ワークロードの
 リプレイス方法
 48

49. © ZOZO Technologies, Inc. やりたかったこと
 • サービス停止はしない
 ◦ データ更新が継続したままでのリプレイス
 •

    オンプレSQL Serverのデータを、ID基盤のAurora MySQLへ移行
 • 再設計されたテーブル構造に対応した形に変換しデータ移行
 
 
 49 FW / WAF Load Balancer オンプレミス Web Server (IIS) DB Server (SQL Server) API Gateway ID基盤 VPC1 VPC2 Peering ALB ALB EKS Cluster2 EKS Cluster1 Account1 Account2 id, email, pasword ...

50. © ZOZO Technologies, Inc. 今までのリプレイス方法
 • 参照系ワークロードの例
 ◦ SQL Server

    to SQL Server
 ◦ サービス停止はしない
 ◦ SQL Server レプリケーションでデータを移行
 
 50

51. © ZOZO Technologies, Inc. 今までのリプレイス方法
 • 参照系ワークロードの例
 ◦ SQL Server

    to SQL Server
 ◦ サービス停止はしない
 ◦ SQL Server レプリケーションでデータを移行
 
 • ID基盤では今までの方法は使えなかった
 ◦ to MySQLのため、SQL Server レプリケーションは使えない
 ◦ 再実装でテーブル構造が異なる
 51

52. © ZOZO Technologies, Inc. ダメなリプレイス方法
 1. データ移行 (bulkload&restore)
 2. クライアント切り替え


    
 サービス停止はしないため、
 1と2の間にデータ更新が合った場合、差分が発生してしまう
 52 オンプレミス DB Server (SQL Server) データ加工 id, email, pasword ... クライアント 1 2 AAA BBB CCC DDD EEE AAA BBB CCC DDD EEE 差分が発生

53. © ZOZO Technologies, Inc. 採用したリプレイス方法
 1. 更新ワークロードを行うクライアント (ASP) でダブルライト
 2.

    データ移行 (bulkload&backfill)
 3. クライアント切り替え
 
 ダブルライトし新規データの整合性を担保した後、データ移行
 この方法を採用(詳細を後述)
 53 オンプレミス DB Server (SQL Server) 更新 クライアント (ASP) 1 AAA BBB CCC DDD EEE EEE AAA BBB CCC DDD EEE 3 EEE EEE 2 データ加工 id, email, pasword ...

54. © ZOZO Technologies, Inc. ダブルライト
 • ID基盤でユーザー登録/更新/削除を行うダブルライトAPIを実装
 • 更新ワークロードを行うクライアント (ASP)で


    ZOZO ID 更新時にダブルライトAPIを叩いてもらうリリース
 • ダブルライト開始後のデータは新・旧DBで同一となる状態
 • ダブルライトAPIはUPSERT (レコードが存在しなければINSERT、存在すればUPDATE) で実装
 ◦ ダブルライトのデータ更新が常に正となる
 ◦ 次のデータ移行 (backfill) 時に必要となる実装
 
 
 54

55. © ZOZO Technologies, Inc. データ移行(bulkload)
 • SQL Serverのデータを抽出し、MySQLの一時テーブルへ移行
 ◦ ダブルライト中でデータがたまり始めた本番テーブルでなく、


    ID基盤内に用意した一時テーブルへ
 • Embulkを使った
 ◦ データ転送ツール
 ◦ SQL Server to MySQL のプラグインあり
 ◦ 社内実績あり
 ◦ データを加工し、テーブル構造の差分も解決
 ▪ データ抽出時のSQLで “ごにょごにょ” 加工する
 55

56. © ZOZO Technologies, Inc. データ移行(backfill)
 • MySQLの一時テーブルから、本番テーブルへ過去データの穴埋め
 ◦ 既存データは上書きしない (duplicate

    entry は諦める)
 ◦ ダブルライトとバッティングする可能性が考えられたため、
 ダブルライトは UPSERT を実装
 (もしバッティングしても、ダブルライトでUPDATE され最新データを取り込むことができる)
 • Golangで実装した
 ◦ アプリケーションに合わせて Golang
 ◦ 高速化のため、1000件程度の bulk insert し
 失敗したら1件ずつ insert する
 56

57. © ZOZO Technologies, Inc. 結果
 • 大変だったこと
 ◦ 旧DBに重複したデータが存在していた
 →

    データを確認し、必要なデータのみ移行
 ◦ 移行データの整合性チェック
 → validateを用意 (Golang)
 ◦ 退会時のデータ削除が、旧DBは論理削除、新DBは物理削除
 backfillにてユーザが復活してしまうことが懸念された
 → 移行後に復活した削除ユーザを抽出、削除した
 
 • 約2千万件の移行で約 25 min (bulkload 10min、backfill 15min)
 
 57

58. © ZOZO Technologies, Inc. AWS/EKSで実施した
 セキュリティへの取り組み
 58

59. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 59 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 開発ガイドラインから下記のセキュリティ要件が求められた


60. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 60 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 下記4項目の取り組みについてお話します
 


61. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 61 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 ※WAFは、課題と今後 にて後ほどお話します
 


62. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 62 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 下記4項目の取り組みについてお話します
 ①　個人情報を扱わない Pod が、
 Aurora の個人情報を参照できないよう制限する取り組み

63. © ZOZO Technologies, Inc. Auroraアクセス制限 案1
 Pod に IAMロール をつけ、権限を分離する方法


    
 • 概要
 ◦ IRSA (IAM Roles for Service Accounts) を使う
 ◦ IAMロールを k8s の Service Account に関連付ける
 ◦ Pod ごとに Service Account を分離し、アクセスを制限する
 
 63

64. © ZOZO Technologies, Inc. Auroraアクセス制限 案1
 Pod に IAMロール をつけ、権限を分離する方法


    
 • 問題
 ◦ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい IAM データベース認証は 200接続/秒 の制約があるため • 結論
 ◦ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない
 64

65. © ZOZO Technologies, Inc. Auroraアクセス制限 案1
 Pod に IAMロール をつけ、権限を分離する方法


    
 • 問題
 ◦ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい IAM データベース認証は 200接続/秒 の制約があるため • 結論
 ◦ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない 65 NG

66. © ZOZO Technologies, Inc. Pod のネットワークを分離する方法
 
 • 概要
 ◦

    k8s の NetworkPolicy を使う
 ◦ 送信、受信の制御ルールを Pod ごとに定義する
 ◦ ネットワークを分離することでアクセス制限ができる
 ◦ ルールの宛先は CIDR で記述する
 ◦ 送信の制御ルールを定義する場合、どちらかが考えられる
 ▪ 全トラフィックを拒否し、許可する通信先を Allow List 化
 ▪ 全トラフィックを許可し、拒否する通信先を Block list 化
 
 Auroraアクセス制限 案2
 66

67. © ZOZO Technologies, Inc. Pod のネットワークを分離する方法
 
 • 問題
 ◦

    Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的 ◦ Block List はDB追加都度リスト追加をする必要があり、運用が辛い • 結論 ◦ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない Auroraアクセス制限 案2
 67

68. © ZOZO Technologies, Inc. Pod のネットワークを分離する方法
 
 • 問題
 ◦

    Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的 ◦ Block List はDB追加都度リスト追加をする必要があり、運用が辛い • 結論 ◦ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない Auroraアクセス制限 案2
 68 NG

69. © ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法
 
 • 概要
 ◦

    Pod にセキュリティグループをつける
 ◦ Aurora は許可したいセキュリティグループからの通信を許可
 ◦ セキュリティグループを分離することでアクセス制限ができる
 Auroraアクセス制限 案3
 69

70. © ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法
 
 • 問題
 ◦

    まだ機能として存在しない
 ロードマップには存在するが開発中
 ◦ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり
 ノードグループごとにセキュリティグループを分けることも不可能
 
 • 結論
 ◦ 一番シンプルで現実的な方法だが、今はできない
 Auroraアクセス制限 案3
 70

71. © ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法
 
 • 問題
 ◦

    まだ機能として存在しない
 ロードマップには存在するが開発中
 ◦ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり
 ノードグループごとにセキュリティグループを分けることも不可能
 
 • 結論
 ◦ 一番シンプルで現実的な方法だが、今はできない
 Auroraアクセス制限 案3
 71 NG

72. © ZOZO Technologies, Inc. • 同一 EKS クラスタ内の Pod で、


    Aurora アクセスを分離し制限することは難しいと判断
 • AWS アカウント自体分離し、
 個人情報を扱う Pod とそうでない Pod を完全に分離する方針を取った
 
 Auroraアクセス制限 結果
 72 API Gateway ID基盤 VPC1 VPC2 Peering ALB ALB EKS Cluster2 EKS Cluster1 Account1 Account2

73. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 73 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 下記4項目の取り組みについてお話します
 ②　コンテナイメージの脆弱性を速やかに検知する取り組み


74. © ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知
 • 脆弱性は日々増える
 ◦ 新たに発見される
 ◦

    ライブラリの追加で、イメージに混入する
 
 74

75. © ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知
 • 脆弱性は日々増える
 ◦ 新たに発見される
 ◦

    ライブラリの追加で、イメージに混入する
 • イメージ脆弱性スキャンツールを導入
 ◦ 脆弱性ソースが多く、検知精度の高い Trivy を採用
 75

76. © ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知
 • 脆弱性は日々増える
 ◦ 新たに発見される
 ◦

    ライブラリの追加で、イメージに混入する
 • イメージ脆弱性スキャンツールを導入
 ◦ 脆弱性ソースが多く、検知精度の高い Trivy を採用
 • 確実に検知できるよう、GitHub Actions で自動実行
 ◦ 1日一回実行
 ◦ Pull Request の push 都度実行
 76

77. © ZOZO Technologies, Inc. Trivyスキャン導入の効果
 • 結果
 ◦ 2件の脆弱性を検知、修正
 ▪

    CVE-2020-13777 (libgnutls30)
 ▪ CVE-2020-10878 (perl)
 
 • 参考情報も一緒に出力され、すぐに修正に取りかかれる点がGood!
 77

78. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 78 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 下記4項目の取り組みについてお話します
 ③　k8s manifest の秘密情報を、隠匿しつつコード管理する取り組み


79. © ZOZO Technologies, Inc. • k8s の秘密情報管理といえば、Secrets リソース ◦ base64

    でデコード可能なため、そのままコード管理するべきでない
 
 • 解決するツールはいくつかあった
 ◦ godaddy/kubernetes-external-secrets ◦ bitnami-labs/sealed-secrets など 
 k8sの秘密情報管理
 79

80. © ZOZO Technologies, Inc. • k8s の秘密情報管理といえば、Secrets リソース ◦ base64

    でデコード可能なため、そのままコード管理するべきでない
 
 • 解決するツールはいくつかあった
 ◦ godaddy/kubernetes-external-secrets ◦ bitnami-labs/sealed-secrets など • godaddy/kubernetes-external-secrets を採用 ◦ コード上の秘密情報関連の情報が少なく、セキュアだと判断した ▪ sealed-secrets は公開鍵で暗号化した秘密情報を保存する ▪ external-secrets は AWS Secrets Manager に保存した秘密情報の Key を指定するのみ 
 k8sの秘密情報管理
 80

81. © ZOZO Technologies, Inc. external-secrets概要
 • ExternalSecrets カスタムリソースを登録することで、
 Controller が

    Secrets Manager に Polling を行い、
 秘密情報を自動で Secrets リソースに格納できる
 81 Secrets Manager External Secrets Controller Name: db/info Key Value username xxx password yyy External Secrets (CustomResource) ExternalSecrets apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: sample spec: backendType: secretsManager data: - key: db/info property: username name: db-username - key: db/info property: password name: db-password namespace Secrets Mame: sample Key Value db-username xxx db-password yyy 1. Get ExternalSecrets 2. Fetch Secrets (Polling) 3. Upsert Secrets

82. © ZOZO Technologies, Inc. external-secrets概要
 • ExternalSecrets カスタムリソースを登録することで、
 Controller が

    Secrets Manager に Polling を行い、
 秘密情報を自動で Secrets リソースに格納できる
 82 Secrets Manager External Secrets Controller Name: db/info Key Value username xxx password yyy External Secrets (CustomResource) ExternalSecrets apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: sample spec: backendType: secretsManager data: - key: db/info property: username name: db-username - key: db/info property: password name: db-password namespace Secrets Mame: sample Key Value db-username xxx db-password yyy 1. Get ExternalSecrets 2. Fetch Secrets (Polling) 3. Upsert Secrets コードで管理

83. © ZOZO Technologies, Inc. 運用後直面した課題と解決
 • 課題
 ◦ 更新した Secrets

    を Pod にリロードさせる必要がある
 ◦ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない
 ▪ 自動更新である external-secrets と Deployment の更新を合わせることは難しい
 
 
 83

84. © ZOZO Technologies, Inc. 運用後直面した課題と解決
 • 課題
 ◦ 更新した Secrets

    を Pod にリロードさせる必要がある
 ◦ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない
 ▪ 自動更新である external-secrets と Deployment の更新を合わせることは難しい
 
 • 解決
 ◦ Controller の Polling を OFF にし、自動更新を停止する
 ◦ ExternalSecrets リソースは更新でなく毎回 name を変え、新規作成する
 ▪ Secrets リソースも毎回新規作成される
 ◦ Deployment は毎回新しい Secrets リソースを指定する
 84

85. © ZOZO Technologies, Inc. 同時更新フロー
 1. Secrets Manger を更新
 85

    Secrets Manager Key Value password yyy zzz External Secrets (CustomResource) ExternalSecrets apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: sample-20200818 spec: backendType: secretsManager data: - key: db/info property: password name: db-password Secrets Name: sample-2020818 Key Value db-password yyy Name: db/info Deployment template: spec: containers: - name: id image: ecr/id:v1 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: sample-20200818 key: db-password

86. © ZOZO Technologies, Inc. Deployment template: spec: containers: - name:

    id image: ecr/id:v2 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: sample-20200819 key: db-password 同時更新フロー
 1. Secrets Manger を更新
 2. ExternalSecrets リソースを新規作成し、Deployement の Secrets リソースを変更する
 (コンテナイメージの更新がある場合は、Deployment の image を更新する)
 86 Secrets Manager Key Value password zzz External Secrets (CustomResource) ExternalSecrets apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: sample-20200819 spec: backendType: secretsManager data: - key: db/info property: password name: db-password Secrets Name: sample-2020819 Name: db/info Key Value db-password zzz

87. © ZOZO Technologies, Inc. 同時更新フロー
 1. Secrets Manger を更新
 2.

    ExternalSecrets リソースを新規作成し、Deployement の Secrets リソースを変更する
 (コンテナイメージの更新がある場合は、Deployment の image を更新する)
 3. manifest を apply し 新しい Secrets で Deployment が起動する
 87 Secrets Manager Key Value password zzz External Secrets (CustomResource) ExternalSecrets apiVersion: kubernetes-client.io/v1 kind: ExternalSecret metadata: name: sample-20200819 spec: backendType: secretsManager data: - key: db/info property: password name: db-password Secrets Name: sample-2020819 Name: db/info Key Value db-password zzz Deployment template: spec: containers: - name: id image: ecr/id:v2 env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: sample-20200819 key: db-password

88. © ZOZO Technologies, Inc. 求められたセキュリティ要件
 88 分類 要件 アカウント管理 ログインアカウントを共有してはならない


    アカウントは最小限の原則に基づいて権限設定をする
 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない
 アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化
 下記4項目の取り組みについてお話します
 ④　kubectl exec で Pod にログインした際の
 Pod 上でのコマンド実行ログを取得する取り組み


89. © ZOZO Technologies, Inc. Pod上でのコマンド実行ログ
 • 設定した一般的な EKS のログ
 


    
 
 
 
 
 
 89 対象 ログ (CloudWatch Logs) 取得方法 コントロールプレーン • k8s API サーバーコンポーネントログ • 監査ログ • 認証システムログ • コントローラーマネージャーログ • スケジューラーログ マネージメントコンソールで設定 ワーカーノード • コンテナログ • Nodeのサーバログ • Nodeのk8s系サービスのjornalログ Daemonsetをインストール
 • CloudWatch Agent
 • Fluentd CloudWatch


90. © ZOZO Technologies, Inc. Pod上でのコマンド実行ログ
 • 設定した一般的な EKS のログ
 


    
 
 
 
 
 
 
 • kubectl exec で Pod ログイン後のコマンド実行ログは別途実装する必要があった
 ◦ 調査のために Pod にログインすることはある
 90 対象 ログ (CloudWatch Logs) 取得方法 コントロールプレーン • k8s API サーバーコンポーネントログ • 監査ログ • 認証システムログ • コントローラーマネージャーログ • スケジューラーログ マネージメントコンソールで設定 ワーカーノード • コンテナログ • Nodeのサーバログ • Nodeのk8s系サービスのjornalログ Daemonsetをインストール
 • CloudWatch Agent
 • Fluentd CloudWatch


91. © ZOZO Technologies, Inc. Pod上でのコマンド実行ログ
 • Falco を使う
 ◦ コンテナアプリケーションやホスト、ネットワークの


    異常検知を行うコンテナランタイムセキュリティツール
 ◦ できること
 ▪ システムコールを解析する
 ▪ rule に従ってアクティビティを検知し、outputする
 
 91

92. © ZOZO Technologies, Inc. Pod上でのコマンド実行ログ
 • 導入方法
 ◦ Daemonset をインストールする


    ◦ コマンド実行ログを取る Rule を ConfigMap で作成する
 ▪ デフォルトでいくつかの Rule が用意されているが、
 すべてのコマンド実行ログの取得は無いので作成が必要
 92 出力されるログ : command=ls pid=xxx user=root k8s.ns=xxx k8s.pod=xxx container=xxx image=xxx parent_process=bash ワーカーノード OS コンテナ アプリPod ls cd ... Falco Pod システムコール execve コンテナで、 execveがコールされたら (新しいプロセスが生成されたら ) stdout に output する Rule 2 1

93. © ZOZO Technologies, Inc. Pod上でのコマンド実行ログ
 • 導入方法
 ◦ Daemonset をインストールする


    ◦ コマンド実行ログを取る Rule を ConfigMap で作成する
 ▪ デフォルトでいくつかの Rule が用意されているが、
 すべてのコマンド実行ログの取得は無いので作成が必要
 ◦ stdout のログは Fluentd CloudWatch で CloudWatch Logs へ転送
 ◦ S3へ定期的に格納することで永続化
 93 ワーカーノード OS アプリPod ls cd ... Falco Pod システムコール execve コンテナで、 execveがコールされたら (新しいプロセスが生成されたら ) stdout に output する Rule 2 1 出力されるログ : command=ls pid=xxx user=root k8s.ns=xxx k8s.pod=xxx container=xxx image=xxx parent_process=bash Fluentd Pod コンテナ CloudWatch Logs S3

94. © ZOZO Technologies, Inc. 課題と今後
 
 94

95. © ZOZO Technologies, Inc. リプレイス半ばである
 • ID基盤を使うクライアントは2つ
 ◦ フロントエンドWebサーバ ASP(社内)


    ◦ iOS/Androidアプリ
 • リプレイスのフェーズと現状 
 ◦ Phase1 : ダブルライト
 ◦ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint)
 ◦ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint)
 ◦ Phase4 : 更新ワークロードの切り替え
 95

96. © ZOZO Technologies, Inc. リプレイス半ばである
 • ID基盤を使うクライアントは2つ
 ◦ フロントエンドWebサーバ ASP(社内)


    ◦ iOS/Androidアプリ
 • リプレイスのフェーズと現状 
 ◦ Phase1 : ダブルライト
 ◦ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint)
 ◦ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint)
 ◦ Phase4 : 更新ワークロードの切り替え
 
 現状は Phase2 まで完了
 96

97. © ZOZO Technologies, Inc. Phase3から求められる要件
 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え


    ◦ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる
 97

98. © ZOZO Technologies, Inc. Phase3から求められる要件
 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え


    ◦ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる
 • オンプレミスで実施している攻撃対策
 ◦ ログイン異常の検知
 ◦ 悪意あるユーザの (SourceIP/User-Agent などで) Block
 ◦ DDoS対策
 など
 
 98

99. © ZOZO Technologies, Inc. Phase3から求められる要件
 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え


    ◦ Public なエンドポイントを用意するため、
 エンドポイントに対する攻撃対策が必要になってくる
 • オンプレミスで実施している攻撃対策
 ◦ ログイン異常の検知
 ◦ 悪意あるユーザの (SourceIP/User-Agent などで) Block
 ◦ DDoS対策
 など
 
 ID基盤版の対策検討中
 検討中の内容を一部紹介します
 99

100. © ZOZO Technologies, Inc. ログイン異常の検知
 100 • ログイン失敗率の増加を検知することで、異常なログインを検知する
 • 必要データの取得方法


     ◦ アクセスログを Pod で出力し、CloudWatch Logs へ転送
 ◦ MetricsFilter で Totalログイン数、Failedログイン数を Count
 • 異常の検知、通知方法
 ◦ CloudWatch Alarm で数式メトリクス失敗率を算出し、しきい値を上回った場合に
 SNS Topic から、Slackなどに通知
 EKS CloudWatch Logs SNS Topic CloudWatch Metrics Filter CloudWatch Alarm

101. © ZOZO Technologies, Inc. 悪意のあるユーザのblock
 101 • ログイン異常の検知などで、悪意のあるユーザが見つかったら block する


     • ALB に AWS WAF をアタッチ、悪意のあるユーザを block するルールを追加
 ◦ 悪意のあるユーザを block するルール追加
 ◦ その中でも許可する条件を、前段にルール追加
 
 WebACL Rule Condition Action Allow List 特定のUser-Agent 許可 Block List 悪意のあるユーザー (パブリッククラウドの IP Rangeなど) ブロック デフォルト 許可 善良なユーザ 悪意のあるユーザ EKS ALB WAF

102. © ZOZO Technologies, Inc. DDoS対策
 102 • WAF に RateLimit

     を超えるリクエストのあった IP を block するルールを追加
 ◦ Rate-base rule で RateLimit を超えたら block するルールを追加
 
 
 WebACL Rule Condition Action Allow List 特定のUser-Agent 許可 Block List 悪意のあるユーザー (パブリッククラウドの IP Rangeなど) ブロック Rate Limit RateLimit を超えるリクエストのあった IP ブロック デフォルト 許可 善良なユーザ 悪意のあるユーザ EKS ALB WAF DDoS攻撃

103. © ZOZO Technologies, Inc. まとめ
 103

104. © ZOZO Technologies, Inc. ZOZOTOWNリプレイス
 104 
 • ZOZOTOWNの成長のためリプレイスを加速させている
 


     • 2020年度、まずは 変更しやすく するため 2つの施策を進めている
 • DB接続のAPI化（ストアドはがし）
 • マイクロサービスの立ち上げ
 
 • 2020年度、マイクロサービスの完成形テンプレートを作る
 そのために組織も変えた


105. © ZOZO Technologies, Inc. ID基盤のリプレイスと取り組み
 105 
 • 従来のオンプレモノリシックなアーキテクチャから
 マイクロサービスアーキテクチャへと作り変えている


     
 • ダブルライト、bulkload、backfill という手法で
 メンテナンスを設けずデータの移行を行った
 
 • セキュリティ向上のため、AWS/EKSで様々な取り組みを行っている
 
 
 これを基準として、ZOZOTOWN のリプレイスを加速させていきます！

106. None