Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)
kameikki
September 08, 2020
Technology
9
4.7k
ZOZOにおけるID基盤のk8sへのリプレイスとセキュリティの取り組み / Authentication service replacement and security efforts of zozotown(CNDT2020)
kameikki
September 08, 2020
Tweet
Share
Other Decks in Technology
See All in Technology
AKIBA.SaaS資料
yasumuusan
0
160
WebLogic Server for OCI 概要
oracle4engineer
PRO
3
850
2年で10→70人へ! スタートアップの 情報セキュリティ課題と施策
miekobayashi
1
210
Optimizing your Swift code
kateinoigakukun
0
1.3k
ステート管理を超えるRecoil運用の考え方
uhyo
7
5.5k
OpenShift.Run2023_create-aro-with-terraform
ishiitaiki20fixer
1
180
cdk deployに必要な権限ってなんだ?
kinyok
0
140
証明書って何だっけ? 〜AWSの中間CA移行に備える〜
minorun365
3
2k
グローバルチームことはじめ / Bootstrapping a global team
tasshi
1
650
日経電子版だけじゃない! 日経の新規Webメディアの開発 - NIKKEI Tech Talk #3
sztm
0
140
OpenShiftのリリースノートを整理してみた
loftkun
2
250
ECテックカンファレンス2023 EC事業部のモバイル開発2023
tatsumi0000
0
180
Featured
See All Featured
A Modern Web Designer's Workflow
chriscoyier
689
180k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
24
4.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
224
50k
Making the Leap to Tech Lead
cromwellryan
116
7.7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
643
54k
What's in a price? How to price your products and services
michaelherold
233
9.7k
Pencils Down: Stop Designing & Start Developing
hursman
114
10k
The Language of Interfaces
destraynor
149
21k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
29
7.8k
Debugging Ruby Performance
tmm1
67
11k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
2
390
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
32
6.7k
Transcript
ZOZOにおける ID基盤のk8sへのリプレイスと セキュリティの取り組み 株式会社ZOZOテクノロジーズ SRE部 リーダー 瀬尾 直利 エンジニア 亀井 宏幸
Copyright © ZOZO Technologies, Inc.
© ZOZO Technologies, Inc. 瀬尾 直利 (そのっつ) 株式会社ZOZOテクノロジーズ 2019年1月入社 SREスペシャリスト
SRE部 ML-SRE リーダー 兼 SRE部 プラットフォームSRE リーダー 兼 CSIRT Twitter/GitHub: @sonots CRuby、Fluentd コミッタ 2
© ZOZO Technologies, Inc. https://zozo.jp/ • 日本最大級のファッション通販サイト • 1,300以上のショップ、7,400以上のブランドの取り扱い(ともに2019年12 月末時点)
• 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商 品を掲載 • 即日配送サービス • ギフトラッピングサービス • ツケ払い など 3
© ZOZO Technologies, Inc. アジェンダ • ZOZOTOWNリプレイスの全体感 (そのっつ) • ID基盤の概要
(以降、亀井) • 更新系ワークロードのリプレイス方法 • AWS/EKSで実施したセキュリティへの取り組み • 課題と今後 4
© ZOZO Technologies, Inc. ZOZOTOWNリプレイス 5
© ZOZO Technologies, Inc. 6 2004年 ZOZOTOWN オープン
© ZOZO Technologies, Inc. 7 ZOZOTOWNはアーキテクチャを変えずに規模を拡大してきた
© ZOZO Technologies, Inc. IIS (Web) RO iOS Android ブラウザ
PC/SP リプレイス開始前: 〜2017年 ストアド ストアド ストアド 8 IIS (API) ロジックがDBに載ってい る(ストアド) 成功 • データの近くで処理を行うため高速(特に2005年 当時はネットワークが細い) • ロジックをDBに載せることでDRYにできる 課題 • ストアドをスケールさせづらい • ストアドのテストが書きづらい • レガシー VBScript • Windows Server の構築自動化が難しい • 現実問題、ASPレイヤーで2重管理になっている ロジックは存在する
© ZOZO Technologies, Inc. 9 2017年4月
© ZOZO Technologies, Inc. 10 2017年当時のリプレイス計画
© ZOZO Technologies, Inc. Java API Read Only SQL ストアドをら
はがしてAPI に移設 第1フェーズ: 2017年〜2020年 参照系ロジックのストアド剥がし 11 IIS (Web) RO iOS Android ブラウザ PC/SP ストアド ストアド ストアド Read Only IIS (API) DBレプリ 課題 • ASPレイヤーのロジックがそのまま • 更新系のリプレイスが未計画 • オンプレIISが入り口のままであるためオ ンプレを卒業できない設計 Read Only 成功 • ストアドロジックが減った • クラウドに移設したことでスケーラビリティ を手にいれた (ECサイトは参照リクエスト が圧倒的に多い) ZOZO DC クラウド
© ZOZO Technologies, Inc. 既存の課題解決と ZOZOTOWNリプレイスを加速させるため 新アーキテクチャと新体制 の計画をスタート 12 2020年1月
そのっつ参画
© ZOZO Technologies, Inc. リプレイスプロジェクト加速にあたって必要なこと • リプレイスの目的の統一 • 最終的なアーキテクチャのイメージの刷新 •
リプレイス作業への開発リソース確保 13
© ZOZO Technologies, Inc. 改めて目的を再確認。 なぜリプレイスするのか 14
© ZOZO Technologies, Inc. 改めて目的を再確認。なぜリプレイスするのか ZOZOTOWNの成長のため スピード をあげる コスト をさげる
人材 をふやす これらを達成できる組織にする 15
© ZOZO Technologies, Inc. 2020年度、リプレイスプロジェクトで進めること まず、変更しやすくしたい。 1. ストアドはがし(継続) 2. マイクロサービスの立ち上げ
16
© ZOZO Technologies, Inc. 新フレームワーク ロジック (Web表示のみ) 商品 サービス RO
お気に入り サービス RW メンバー サービス RW ネイティブアプリはAPI 直呼び出し ブラウザ PC/SP iOS Android WebのUIに 新技術が使える ようになる それぞれのAPIが 独立したサービスに = マイクロサービス化 API Gateway ID認証 サービス RW 17 第2フェーズ: 目指す姿
© ZOZO Technologies, Inc. 商品 サービス RO お気に入り サービス RW
メンバー サービス RW API Gateway ID認証 サービス RW 18 IIS (Web) RO ブラウザ PC/SP ストアド ストアド ストアド IIS (API) ZOZO DC 第2フェーズ (2020年〜進行中) 切り替え方法 (ストラングラーパターン) iOS Android 切り替え 切り替え DBレプリ クラウド
© ZOZO Technologies, Inc. この1年でマイクロサービスの完成形テンプレートを作る 19
© ZOZO Technologies, Inc. アーキテクチャを反映した、開発しやすい組織体制に移行 新フレームワーク ロジック (Web表示のみ) ユーザー サービス
RO お気に入り サービス RW 商品 サービス RW API Gateway ID認証 サービス RW 20
© ZOZO Technologies, Inc. 組織 21 「マイクロサービスは組織論である」
© ZOZO Technologies, Inc. ECプラットフォーム部 / プラットフォームSREの設立 (4月) EC開発本部 ZOZOTOWN
フロントエンド バックエンド アプリ ZOZO 技術開発本部 ECプラットフォーム部 基幹 MSP USED CHINA SRE部 検索 マイグレーション API基盤 推薦基盤 サービス MLOps MA BtoB USED PF-SRE グロース EC開発本部と一緒にマイクロサービス化を進めていく 22
© ZOZO Technologies, Inc. • 我々は、ZOZOTOWNがこれからも成長を続けるために、開発効率・運用性・ 堅牢性・柔軟性・回復性の確保を見据えて、技術面でも環境面でもクラウドネイ ティブに刷新するための取り組みを進めます。 • 巨大でピーク性のある大規模ECシステムを、最適なアーキテクチャをチームで
思い描きながら設計・構築・リリース・運用まで一環して行い ZOZOTOWN の 成長を加速させることがミッションです。 23 23 プラットフォームSREのミッション
© ZOZO Technologies, Inc. • マイクロサービスプラットフォーム Kubernetes クラスタの設計 • API
Gateway 経由のアーキテクチャに変更 • ID基盤のリリース (更新系リプレイス第一弾) • 第一弾として検索機能を Front API から切り出してマイクロサービス化 24 プラットフォームSRE今期 (2020年4月〜9月) 24
© ZOZO Technologies, Inc. 25 25 2020年3月
© ZOZO Technologies, Inc. 26 26 *マルチクラウドやめました 今期目標
ZOZOにおける ID基盤のk8sへのリプレイスと セキュリティの取り組み (後半) 株式会社ZOZOテクノロジーズ SRE部 リーダー 瀬尾 直利 エンジニア 亀井
宏幸 Copyright © ZOZO Technologies, Inc.
© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部 亀井 宏幸 2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN のオンプレサーバ運用を経て
2019年9月にPF-SREチームへ、 パブリッククラウド・k8sを初体験しながら ZOZOリプレイスに携わっている。 28
© ZOZO Technologies, Inc. 株式会社ZOZOテクノロジーズ SRE部 亀井 宏幸 2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN のオンプレサーバ運用を経て
2019年9月にPF-SREチームへ、 パブリッククラウド・k8sを初体験しながら ZOZOリプレイスに携わっている。 29
© ZOZO Technologies, Inc. アジェンダ • ZOZOTOWNリプレイスの全体感 (そのっつ) • ID基盤の概要
(以降、亀井) • 更新系ワークロードのリプレイス方法 • AWS/EKSで実施したセキュリティへの取り組み • 課題と今後 30
© ZOZO Technologies, Inc. お話ししないこと • アプリケーションの説明 • k8sクラスタの構築内容 •
IaC、CI/CDの手法 31
© ZOZO Technologies, Inc. ID基盤の概要 32
© ZOZO Technologies, Inc. の前に、API Gateway について 33
© ZOZO Technologies, Inc. API Gateway • API の Gateway
となるマイクロサービス • マイクロサービス化にあたりID基盤に先行してリリース済み • API コントローラー、SSL終端 などの役割をもつ 34 新フレームワーク ロジック (Web表示のみ) ユーザー サービス RO お気に入り サービス RW 商品 サービス RW API Gateway ID認証 サービス RW これ
© ZOZO Technologies, Inc. API Gatewayは自前で実装 • AWS にはマネージドサービスの API
Gateway がある • 複雑な要求に柔軟に対応するために自前実装 ◦ エンドポイントを複数もつサービス(マルチクラウド/マルチクラスタ)に対し、 エラーやタイムアウト時に別エンドポイントへのリトライ ◦ ヘッダー (Client-Token) によるクライアント認証機能 など • AWS/EKSで構築 35
© ZOZO Technologies, Inc. 改めて、ID基盤とは 36
© ZOZO Technologies, Inc. ZOZOTOWN におけるID基盤 • ZOZOTOWN は ZOZO
ID という認証システムがある • ID基盤は ZOZO ID のモダン化リプレイスプロジェクト • PF-SRE のマイクロサービス第二弾 (話せば長くなる) 37
© ZOZO Technologies, Inc. ID基盤の特徴 • 更新系ワークロードを扱う ◦ 更新系 :
会員登録/更新/退会() ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など • 個人情報も扱う ◦ email ◦ password ◦ phone 38
© ZOZO Technologies, Inc. ID基盤の特徴 • 更新系ワークロードを扱う ◦ 更新系 :
会員登録(insert)/更新(update)/退会(delete ) ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など • 個人情報も扱う ◦ email ◦ password ◦ phone 39 ZOZOTOWNにおける 更新系ワークロードの リプレイス第一弾
© ZOZO Technologies, Inc. ID基盤の特徴 • 更新系ワークロードを扱う ◦ 更新系 :
会員登録/更新/退会() ◦ 参照系 : ログイン/トークン発行/トークンリフレッシュ など • 個人情報も扱う ◦ email ◦ password ◦ phone 40 高セキュリティの インフラが求められる
© ZOZO Technologies, Inc. 求められた要件 • クラウドネイティブ化 • マイクロサービス化 •
CI/CD (Continuous Integration / Continuous Delivery) 化 • IaC (Infrastructure as Code) 化 • 開発ガイドライン(社内ガイドライン)のセキュリティ要件の遵守 41
© ZOZO Technologies, Inc. 従来のアーキテクチャ • オンプレミスで構成されていた 42 FW /
WAF Load Balancer オンプレミス Web Server (IIS) DB Server (SQL Server) • 巨大でモノリシック • Web Server は Classic ASP で実装さ れ 多数の細かいサービスが混在 • DB Server は 用途ごとに物理的にイ ンスタンスが分割されているものの、 多数の細かいサービス用のテーブル が混在 ※簡易的なアーキテクチャ図です TCP : xxx
© 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
© 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
© ZOZO Technologies, Inc. EKS (Elastic Kubernetes Service) • AWS
のフルマネージド型の Kubernetes (以後 k8s) サービス • コントロールプレーンの管理は不要 • EC2マネージドノードグループを採用することで、 ワーカーノードの構築、運用負荷も最小限 • k8s のメリットを享受できる ◦ オートスケールや自動修復 ◦ コントローラーによる高い拡張性・柔軟性 クラウドのメリットを最大限活用するため、EKSを採用 45
© ZOZO Technologies, Inc. Aurora MySQL • フルマネージド型でMySQL互換のRDSサービス • 高い可用性
◦ データは99.99%の可用性 ◦ レプリカへのフェイルオーバーは約30秒程度 • LTS (Long Time Support) バージョンが用意されており 最低限のバージョンアップ頻度としダウンタイムを最小化できる MySQL互換であり高い可用性から、Aurora MySQLを採用 46
© ZOZO Technologies, Inc. ID基盤概要 のまとめ • ID基盤 = 新
ZOZO ID • オンプレ→クラウドへ、初の更新系リプレイス • マイクロサービス 第二弾 • AWS/EKS/Aurora で構築 • API Gateway と AWS アカウントを分離(後述) 47
© ZOZO Technologies, Inc. 更新系ワークロードの リプレイス方法 48
© 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 ...
© ZOZO Technologies, Inc. 今までのリプレイス方法 • 参照系ワークロードの例 ◦ SQL Server
to SQL Server ◦ サービス停止はしない ◦ SQL Server レプリケーションでデータを移行 50
© ZOZO Technologies, Inc. 今までのリプレイス方法 • 参照系ワークロードの例 ◦ SQL Server
to SQL Server ◦ サービス停止はしない ◦ SQL Server レプリケーションでデータを移行 • ID基盤では今までの方法は使えなかった ◦ to MySQLのため、SQL Server レプリケーションは使えない ◦ 再実装でテーブル構造が異なる 51
© 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 差分が発生
© 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 ...
© ZOZO Technologies, Inc. ダブルライト • ID基盤でユーザー登録/更新/削除を行うダブルライトAPIを実装 • 更新ワークロードを行うクライアント (ASP)で
ZOZO ID 更新時にダブルライトAPIを叩いてもらうリリース • ダブルライト開始後のデータは新・旧DBで同一となる状態 • ダブルライトAPIはUPSERT (レコードが存在しなければINSERT、存在すればUPDATE) で実装 ◦ ダブルライトのデータ更新が常に正となる ◦ 次のデータ移行 (backfill) 時に必要となる実装 54
© ZOZO Technologies, Inc. データ移行(bulkload) • SQL Serverのデータを抽出し、MySQLの一時テーブルへ移行 ◦ ダブルライト中でデータがたまり始めた本番テーブルでなく、
ID基盤内に用意した一時テーブルへ • Embulkを使った ◦ データ転送ツール ◦ SQL Server to MySQL のプラグインあり ◦ 社内実績あり ◦ データを加工し、テーブル構造の差分も解決 ▪ データ抽出時のSQLで “ごにょごにょ” 加工する 55
© ZOZO Technologies, Inc. データ移行(backfill) • MySQLの一時テーブルから、本番テーブルへ過去データの穴埋め ◦ 既存データは上書きしない (duplicate
entry は諦める) ◦ ダブルライトとバッティングする可能性が考えられたため、 ダブルライトは UPSERT を実装 (もしバッティングしても、ダブルライトでUPDATE され最新データを取り込むことができる) • Golangで実装した ◦ アプリケーションに合わせて Golang ◦ 高速化のため、1000件程度の bulk insert し 失敗したら1件ずつ insert する 56
© ZOZO Technologies, Inc. 結果 • 大変だったこと ◦ 旧DBに重複したデータが存在していた →
データを確認し、必要なデータのみ移行 ◦ 移行データの整合性チェック → validateを用意 (Golang) ◦ 退会時のデータ削除が、旧DBは論理削除、新DBは物理削除 backfillにてユーザが復活してしまうことが懸念された → 移行後に復活した削除ユーザを抽出、削除した • 約2千万件の移行で約 25 min (bulkload 10min、backfill 15min) 57
© ZOZO Technologies, Inc. AWS/EKSで実施した セキュリティへの取り組み 58
© ZOZO Technologies, Inc. 求められたセキュリティ要件 59 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 開発ガイドラインから下記のセキュリティ要件が求められた
© ZOZO Technologies, Inc. 求められたセキュリティ要件 60 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 下記4項目の取り組みについてお話します
© ZOZO Technologies, Inc. 求められたセキュリティ要件 61 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 ※WAFは、課題と今後 にて後ほどお話します
© ZOZO Technologies, Inc. 求められたセキュリティ要件 62 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 下記4項目の取り組みについてお話します ① 個人情報を扱わない Pod が、 Aurora の個人情報を参照できないよう制限する取り組み
© ZOZO Technologies, Inc. Auroraアクセス制限 案1 Pod に IAMロール をつけ、権限を分離する方法
• 概要 ◦ IRSA (IAM Roles for Service Accounts) を使う ◦ IAMロールを k8s の Service Account に関連付ける ◦ Pod ごとに Service Account を分離し、アクセスを制限する 63
© ZOZO Technologies, Inc. Auroraアクセス制限 案1 Pod に IAMロール をつけ、権限を分離する方法
• 問題 ◦ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい IAM データベース認証は 200接続/秒 の制約があるため • 結論 ◦ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない 64
© ZOZO Technologies, Inc. Auroraアクセス制限 案1 Pod に IAMロール をつけ、権限を分離する方法
• 問題 ◦ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい IAM データベース認証は 200接続/秒 の制約があるため • 結論 ◦ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない 65 NG
© ZOZO Technologies, Inc. Pod のネットワークを分離する方法 • 概要 ◦
k8s の NetworkPolicy を使う ◦ 送信、受信の制御ルールを Pod ごとに定義する ◦ ネットワークを分離することでアクセス制限ができる ◦ ルールの宛先は CIDR で記述する ◦ 送信の制御ルールを定義する場合、どちらかが考えられる ▪ 全トラフィックを拒否し、許可する通信先を Allow List 化 ▪ 全トラフィックを許可し、拒否する通信先を Block list 化 Auroraアクセス制限 案2 66
© ZOZO Technologies, Inc. Pod のネットワークを分離する方法 • 問題 ◦
Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的 ◦ Block List はDB追加都度リスト追加をする必要があり、運用が辛い • 結論 ◦ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない Auroraアクセス制限 案2 67
© ZOZO Technologies, Inc. Pod のネットワークを分離する方法 • 問題 ◦
Allow List は外部APIなど通信をすべて把握、設定する必要があり非現実的 ◦ Block List はDB追加都度リスト追加をする必要があり、運用が辛い • 結論 ◦ CIDR で記述する NetworkPolicy ルールの管理は非効率でできればやりたくない Auroraアクセス制限 案2 68 NG
© ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法 • 概要 ◦
Pod にセキュリティグループをつける ◦ Aurora は許可したいセキュリティグループからの通信を許可 ◦ セキュリティグループを分離することでアクセス制限ができる Auroraアクセス制限 案3 69
© ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法 • 問題 ◦
まだ機能として存在しない ロードマップには存在するが開発中 ◦ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり ノードグループごとにセキュリティグループを分けることも不可能 • 結論 ◦ 一番シンプルで現実的な方法だが、今はできない Auroraアクセス制限 案3 70
© ZOZO Technologies, Inc. Pod にセキュリティグループをつけ、ネットワークを分離する方法 • 問題 ◦
まだ機能として存在しない ロードマップには存在するが開発中 ◦ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり ノードグループごとにセキュリティグループを分けることも不可能 • 結論 ◦ 一番シンプルで現実的な方法だが、今はできない Auroraアクセス制限 案3 71 NG
© 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
© ZOZO Technologies, Inc. 求められたセキュリティ要件 73 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 下記4項目の取り組みについてお話します ② コンテナイメージの脆弱性を速やかに検知する取り組み
© ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知 • 脆弱性は日々増える ◦ 新たに発見される ◦
ライブラリの追加で、イメージに混入する 74
© ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知 • 脆弱性は日々増える ◦ 新たに発見される ◦
ライブラリの追加で、イメージに混入する • イメージ脆弱性スキャンツールを導入 ◦ 脆弱性ソースが多く、検知精度の高い Trivy を採用 75
© ZOZO Technologies, Inc. コンテナイメージ脆弱性の検知 • 脆弱性は日々増える ◦ 新たに発見される ◦
ライブラリの追加で、イメージに混入する • イメージ脆弱性スキャンツールを導入 ◦ 脆弱性ソースが多く、検知精度の高い Trivy を採用 • 確実に検知できるよう、GitHub Actions で自動実行 ◦ 1日一回実行 ◦ Pull Request の push 都度実行 76
© ZOZO Technologies, Inc. Trivyスキャン導入の効果 • 結果 ◦ 2件の脆弱性を検知、修正 ▪
CVE-2020-13777 (libgnutls30) ▪ CVE-2020-10878 (perl) • 参考情報も一緒に出力され、すぐに修正に取りかかれる点がGood! 77
© ZOZO Technologies, Inc. 求められたセキュリティ要件 78 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 下記4項目の取り組みについてお話します ③ k8s manifest の秘密情報を、隠匿しつつコード管理する取り組み
© ZOZO Technologies, Inc. • k8s の秘密情報管理といえば、Secrets リソース ◦ base64
でデコード可能なため、そのままコード管理するべきでない • 解決するツールはいくつかあった ◦ godaddy/kubernetes-external-secrets ◦ bitnami-labs/sealed-secrets など k8sの秘密情報管理 79
© 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
© 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
© 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 コードで管理
© ZOZO Technologies, Inc. 運用後直面した課題と解決 • 課題 ◦ 更新した Secrets
を Pod にリロードさせる必要がある ◦ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない ▪ 自動更新である external-secrets と Deployment の更新を合わせることは難しい 83
© ZOZO Technologies, Inc. 運用後直面した課題と解決 • 課題 ◦ 更新した Secrets
を Pod にリロードさせる必要がある ◦ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない ▪ 自動更新である external-secrets と Deployment の更新を合わせることは難しい • 解決 ◦ Controller の Polling を OFF にし、自動更新を停止する ◦ ExternalSecrets リソースは更新でなく毎回 name を変え、新規作成する ▪ Secrets リソースも毎回新規作成される ◦ Deployment は毎回新しい Secrets リソースを指定する 84
© 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
© 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
© 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
© ZOZO Technologies, Inc. 求められたセキュリティ要件 88 分類 要件 アカウント管理 ログインアカウントを共有してはならない
アカウントは最小限の原則に基づいて権限設定をする 個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない アプリケーション管理 セキュリティアップデートを速やかに取り入れる アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する 秘密情報管理 秘密情報を平文で保存してはならない ログ管理 本番環境の設定変更/操作ログを取得・永続化 パブリッククラウドの監査ログを取得・永続化 下記4項目の取り組みについてお話します ④ kubectl exec で Pod にログインした際の Pod 上でのコマンド実行ログを取得する取り組み
© ZOZO Technologies, Inc. Pod上でのコマンド実行ログ • 設定した一般的な EKS のログ
89 対象 ログ (CloudWatch Logs) 取得方法 コントロールプレーン • k8s API サーバーコンポーネントログ • 監査ログ • 認証システムログ • コントローラーマネージャーログ • スケジューラーログ マネージメントコンソールで設定 ワーカーノード • コンテナログ • Nodeのサーバログ • Nodeのk8s系サービスのjornalログ Daemonsetをインストール • CloudWatch Agent • Fluentd CloudWatch
© ZOZO Technologies, Inc. Pod上でのコマンド実行ログ • 設定した一般的な EKS のログ
• kubectl exec で Pod ログイン後のコマンド実行ログは別途実装する必要があった ◦ 調査のために Pod にログインすることはある 90 対象 ログ (CloudWatch Logs) 取得方法 コントロールプレーン • k8s API サーバーコンポーネントログ • 監査ログ • 認証システムログ • コントローラーマネージャーログ • スケジューラーログ マネージメントコンソールで設定 ワーカーノード • コンテナログ • Nodeのサーバログ • Nodeのk8s系サービスのjornalログ Daemonsetをインストール • CloudWatch Agent • Fluentd CloudWatch
© ZOZO Technologies, Inc. Pod上でのコマンド実行ログ • Falco を使う ◦ コンテナアプリケーションやホスト、ネットワークの
異常検知を行うコンテナランタイムセキュリティツール ◦ できること ▪ システムコールを解析する ▪ rule に従ってアクティビティを検知し、outputする 91
© 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
© 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
© ZOZO Technologies, Inc. 課題と今後 94
© ZOZO Technologies, Inc. リプレイス半ばである • ID基盤を使うクライアントは2つ ◦ フロントエンドWebサーバ ASP(社内)
◦ iOS/Androidアプリ • リプレイスのフェーズと現状 ◦ Phase1 : ダブルライト ◦ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint) ◦ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint) ◦ Phase4 : 更新ワークロードの切り替え 95
© ZOZO Technologies, Inc. リプレイス半ばである • ID基盤を使うクライアントは2つ ◦ フロントエンドWebサーバ ASP(社内)
◦ iOS/Androidアプリ • リプレイスのフェーズと現状 ◦ Phase1 : ダブルライト ◦ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint) ◦ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint) ◦ Phase4 : 更新ワークロードの切り替え 現状は Phase2 まで完了 96
© ZOZO Technologies, Inc. Phase3から求められる要件 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え
◦ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる 97
© ZOZO Technologies, Inc. Phase3から求められる要件 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え
◦ Public なエンドポイントを用意するため、サイバー攻撃対策が必要になってくる • オンプレミスで実施している攻撃対策 ◦ ログイン異常の検知 ◦ 悪意あるユーザの (SourceIP/User-Agent などで) Block ◦ DDoS対策 など 98
© ZOZO Technologies, Inc. Phase3から求められる要件 • Phase3 : iOS/Androidアプリ 参照ワークロード切り替え
◦ Public なエンドポイントを用意するため、 エンドポイントに対する攻撃対策が必要になってくる • オンプレミスで実施している攻撃対策 ◦ ログイン異常の検知 ◦ 悪意あるユーザの (SourceIP/User-Agent などで) Block ◦ DDoS対策 など ID基盤版の対策検討中 検討中の内容を一部紹介します 99
© 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
© 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
© 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攻撃
© ZOZO Technologies, Inc. まとめ 103
© ZOZO Technologies, Inc. ZOZOTOWNリプレイス 104 • ZOZOTOWNの成長のためリプレイスを加速させている
• 2020年度、まずは 変更しやすく するため 2つの施策を進めている • DB接続のAPI化(ストアドはがし) • マイクロサービスの立ち上げ • 2020年度、マイクロサービスの完成形テンプレートを作る そのために組織も変えた
© ZOZO Technologies, Inc. ID基盤のリプレイスと取り組み 105 • 従来のオンプレモノリシックなアーキテクチャから マイクロサービスアーキテクチャへと作り変えている
• ダブルライト、bulkload、backfill という手法で メンテナンスを設けずデータの移行を行った • セキュリティ向上のため、AWS/EKSで様々な取り組みを行っている これを基準として、ZOZOTOWN のリプレイスを加速させていきます!
None