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

by kameikki

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 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 クラウド

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© ZOZO Technologies, Inc. 新フレームワークロジック（Web表示のみ）商品サービス RO お気に入りサービス RW メンバーサービス RW ネイティブアプリはAPI 直呼び出しブラウザ PC/SP iOS Android WebのUIに新技術が使えるようになるそれぞれのAPIが独立したサービスに = マイクロサービス化 API Gateway ID認証サービス RW 17 第２フェーズ: 目指す姿

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

© ZOZO Technologies, Inc. ● 我々は、ZOZOTOWNがこれからも成長を続けるために、開発効率・運用性・堅牢性・柔軟性・回復性の確保を見据えて、技術面でも環境面でもクラウドネイティブに刷新するための取り組みを進めます。 ● 巨大でピーク性のある大規模ECシステムを、最適なアーキテクチャをチームで思い描きながら設計・構築・リリース・運用まで一環して行い ZOZOTOWN の成長を加速させることがミッションです。 23 23 プラットフォームSREのミッション 

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© ZOZO Technologies, Inc. ID基盤の特徴  ● 更新系ワークロードを扱う  ○ 更新系 : 会員登録(insert)/更新(update)/退会(delete ) ○ 参照系 : ログイン/トークン発行/トークンリフレッシュなど  ● 個人情報も扱う  ○ email  ○ password  ○ phone  39 ZOZOTOWNにおける  更新系ワークロードの  リプレイス第一弾 

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

© 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

Slide 44

Slide 44 text

© 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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

© ZOZO Technologies, Inc. Aurora MySQL  ● フルマネージド型でMySQL互換のRDSサービス  ● 高い可用性  ○ データは99.99%の可用性  ○ レプリカへのフェイルオーバーは約30秒程度  ● LTS (Long Time Support) バージョンが用意されており  最低限のバージョンアップ頻度としダウンタイムを最小化できる      MySQL互換であり高い可用性から、Aurora MySQLを採用    46

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 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 ...

Slide 50

Slide 50 text

Slide 51

Slide 51 text

© ZOZO Technologies, Inc. 今までのリプレイス方法  ● 参照系ワークロードの例  ○ SQL Server to SQL Server  ○ サービス停止はしない  ○ SQL Server レプリケーションでデータを移行    ● ID基盤では今までの方法は使えなかった  ○ to MySQLのため、SQL Server レプリケーションは使えない  ○ 再実装でテーブル構造が異なる  51

Slide 52

Slide 52 text

© 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 差分が発生

Slide 53

Slide 53 text

© 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 ...

Slide 54

Slide 54 text

© ZOZO Technologies, Inc. ダブルライト  ● ID基盤でユーザー登録/更新/削除を行うダブルライトAPIを実装  ● 更新ワークロードを行うクライアント (ASP)で  ZOZO ID 更新時にダブルライトAPIを叩いてもらうリリース  ● ダブルライト開始後のデータは新・旧DBで同一となる状態  ● ダブルライトAPIはUPSERT (レコードが存在しなければINSERT、存在すればUPDATE) で実装  ○ ダブルライトのデータ更新が常に正となる  ○ 次のデータ移行 (backfill) 時に必要となる実装      54

Slide 55

Slide 55 text

© ZOZO Technologies, Inc. データ移行(bulkload)  ● SQL Serverのデータを抽出し、MySQLの一時テーブルへ移行  ○ ダブルライト中でデータがたまり始めた本番テーブルでなく、  ID基盤内に用意した一時テーブルへ  ● Embulkを使った  ○ データ転送ツール  ○ SQL Server to MySQL のプラグインあり  ○ 社内実績あり  ○ データを加工し、テーブル構造の差分も解決  ■ データ抽出時のSQLで “ごにょごにょ” 加工する  55

Slide 56

Slide 56 text

© ZOZO Technologies, Inc. データ移行(backfill)  ● MySQLの一時テーブルから、本番テーブルへ過去データの穴埋め  ○ 既存データは上書きしない (duplicate entry は諦める)  ○ ダブルライトとバッティングする可能性が考えられたため、  ダブルライトは UPSERT を実装  (もしバッティングしても、ダブルライトでUPDATE され最新データを取り込むことができる)  ● Golangで実装した  ○ アプリケーションに合わせて Golang  ○ 高速化のため、1000件程度の bulk insert し  失敗したら1件ずつ insert する  56

Slide 57

Slide 57 text

© ZOZO Technologies, Inc. 結果  ● 大変だったこと  ○ 旧DBに重複したデータが存在していた  → データを確認し、必要なデータのみ移行  ○ 移行データの整合性チェック  → validateを用意 (Golang)  ○ 退会時のデータ削除が、旧DBは論理削除、新DBは物理削除  backfillにてユーザが復活してしまうことが懸念された  → 移行後に復活した削除ユーザを抽出、削除した    ● 約2千万件の移行で約 25 min (bulkload 10min、backfill 15min)    57

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

© ZOZO Technologies, Inc. Auroraアクセス制限案1  Pod に IAMロールをつけ、権限を分離する方法    ● 概要  ○ IRSA (IAM Roles for Service Accounts) を使う  ○ IAMロールを k8s の Service Account に関連付ける  ○ Pod ごとに Service Account を分離し、アクセスを制限する    63

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

© ZOZO Technologies, Inc. Pod のネットワークを分離する方法    ● 問題  ○ Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的 ○ Block List はDB追加都度リスト追加をする必要があり、運用が辛い ● 結論 ○ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない Auroraアクセス制限案2  67

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Slide 72

Slide 72 text

© 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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

© ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知  ● 脆弱性は日々増える  ○ 新たに発見される  ○ ライブラリの追加で、イメージに混入する  ● イメージ脆弱性スキャンツールを導入  ○ 脆弱性ソースが多く、検知精度の高い Trivy を採用  ● 確実に検知できるよう、GitHub Actions で自動実行  ○ 1日一回実行  ○ Pull Request の push 都度実行  76

Slide 77

Slide 77 text

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Slide 80

Slide 80 text

© 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

Slide 81

Slide 81 text

© 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

Slide 82

Slide 82 text

© 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 コードで管理

Slide 83

Slide 83 text

Slide 84

Slide 84 text

© ZOZO Technologies, Inc. 運用後直面した課題と解決  ● 課題  ○ 更新した Secrets を Pod にリロードさせる必要がある  ○ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない  ■ 自動更新である external-secrets と Deployment の更新を合わせることは難しい    ● 解決  ○ Controller の Polling を OFF にし、自動更新を停止する  ○ ExternalSecrets リソースは更新でなく毎回 name を変え、新規作成する  ■ Secrets リソースも毎回新規作成される  ○ Deployment は毎回新しい Secrets リソースを指定する  84

Slide 85

Slide 85 text

© 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

Slide 86

Slide 86 text

© 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

Slide 87

Slide 87 text

© 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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

© ZOZO Technologies, Inc. Pod上でのコマンド実行ログ  ● 設定した一般的な EKS のログ                89 対象ログ (CloudWatch Logs) 取得方法コントロールプレーン ● k8s API サーバーコンポーネントログ ● 監査ログ ● 認証システムログ ● コントローラーマネージャーログ ● スケジューラーログマネージメントコンソールで設定ワーカーノード ● コンテナログ ● Nodeのサーバログ ● Nodeのk8s系サービスのjornalログ Daemonsetをインストール  ● CloudWatch Agent  ● Fluentd CloudWatch 

Slide 90

Slide 90 text

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

Slide 91

Slide 91 text

Slide 92

Slide 92 text

© 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

Slide 93

Slide 93 text

© 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

Slide 94

Slide 94 text

Slide 95

Slide 95 text

© ZOZO Technologies, Inc. リプレイス半ばである  ● ID基盤を使うクライアントは2つ  ○ フロントエンドWebサーバ ASP(社内)  ○ iOS/Androidアプリ  ● リプレイスのフェーズと現状   ○ Phase1 : ダブルライト  ○ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint)  ○ Phase3 : iOS/Androidアプリ参照ワークロード切り替え (Public Endpoint)  ○ Phase4 : 更新ワークロードの切り替え  95

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

© ZOZO Technologies, Inc. Phase3から求められる要件  ● Phase3 : iOS/Androidアプリ参照ワークロード切り替え  ○ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる  ● オンプレミスで実施している攻撃対策  ○ ログイン異常の検知  ○ 悪意あるユーザの (SourceIP/User-Agent などで) Block  ○ DDoS対策  など    98

Slide 99

Slide 99 text

© ZOZO Technologies, Inc. Phase3から求められる要件  ● Phase3 : iOS/Androidアプリ参照ワークロード切り替え  ○ Public なエンドポイントを用意するため、  エンドポイントに対する攻撃対策が必要になってくる  ● オンプレミスで実施している攻撃対策  ○ ログイン異常の検知  ○ 悪意あるユーザの (SourceIP/User-Agent などで) Block  ○ DDoS対策  など    ID基盤版の対策検討中  検討中の内容を一部紹介します  99

Slide 100

Slide 100 text

© 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

Slide 101

Slide 101 text

© 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

Slide 102

Slide 102 text

© 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攻撃

Slide 103

Slide 103 text

Slide 104

Slide 104 text

Slide 105

Slide 105 text

© ZOZO Technologies, Inc. ID基盤のリプレイスと取り組み  105   ● 従来のオンプレモノリシックなアーキテクチャから  マイクロサービスアーキテクチャへと作り変えている    ● ダブルライト、bulkload、backfill という手法で  メンテナンスを設けずデータの移行を行った    ● セキュリティ向上のため、AWS/EKSで様々な取り組みを行っている      これを基準として、ZOZOTOWN のリプレイスを加速させていきます！ 

Slide 106

Slide 106 text

No content