Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kameikki
September 08, 2020

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

kameikki

September 08, 2020
Tweet

Other Decks in Technology

Transcript

  1. ZOZOにおける

    ID基盤のk8sへのリプレイスと

    セキュリティの取り組み


    株式会社ZOZOテクノロジーズ

    SRE部

    リーダー 瀬尾 直利

    エンジニア 亀井 宏幸

    Copyright © ZOZO Technologies, Inc.

    View Slide

  2. © ZOZO Technologies, Inc.
    瀬尾 直利 (そのっつ)

    株式会社ZOZOテクノロジーズ
    2019年1月入社 SREスペシャリスト
    SRE部 ML-SRE リーダー 兼
    SRE部 プラットフォームSRE リーダー 兼
    CSIRT
    Twitter/GitHub: @sonots
    CRuby、Fluentd コミッタ
    2

    View Slide

  3. © ZOZO Technologies, Inc.
    https://zozo.jp/

    ● 日本最大級のファッション通販サイト

    ● 1,300以上のショップ、7,400以上のブランドの取り扱い(ともに2019年12
    月末時点)

    ● 常時73万点以上の商品アイテム数と毎日平均3,200点以上の新着 商
    品を掲載

    ● 即日配送サービス

    ● ギフトラッピングサービス

    ● ツケ払い など

    3

    View Slide

  4. © ZOZO Technologies, Inc.
    アジェンダ

    ● ZOZOTOWNリプレイスの全体感 (そのっつ)

    ● ID基盤の概要 (以降、亀井)

    ● 更新系ワークロードのリプレイス方法

    ● AWS/EKSで実施したセキュリティへの取り組み

    ● 課題と今後

    4

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. © ZOZO Technologies, Inc.
    改めて目的を再確認。なぜリプレイスするのか
    ZOZOTOWNの成長のため
    スピード
    をあげる
    コスト
    をさげる
    人材
    をふやす
    これらを達成できる組織にする
    15

    View Slide

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

    View Slide

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

    View Slide

  18. © 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レプリ
    クラウド

    View Slide

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

    View Slide

  20. © ZOZO Technologies, Inc.
    アーキテクチャを反映した、開発しやすい組織体制に移行
    新フレームワーク
    ロジック
    (Web表示のみ)
    ユーザー
    サービス
    RO
    お気に入り
    サービス
    RW
    商品
    サービス
    RW
    API Gateway
    ID認証
    サービス
    RW
    20

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

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

    24

    View Slide

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

    View Slide

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

    View Slide

  27. ZOZOにおける

    ID基盤のk8sへのリプレイスと

    セキュリティの取り組み (後半)


    株式会社ZOZOテクノロジーズ

    SRE部

    リーダー 瀬尾 直利

    エンジニア 亀井 宏幸

    Copyright © ZOZO Technologies, Inc.

    View Slide

  28. © ZOZO Technologies, Inc.
    株式会社ZOZOテクノロジーズ

    SRE部

    亀井 宏幸

    2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN
    のオンプレサーバ運用を経て

    2019年9月にPF-SREチームへ、

    パブリッククラウド・k8sを初体験しながら

    ZOZOリプレイスに携わっている。

    28

    View Slide

  29. © ZOZO Technologies, Inc.
    株式会社ZOZOテクノロジーズ

    SRE部

    亀井 宏幸

    2017年9月にZOZOテクノロジーズに中途入社。ZOZOTOWN
    のオンプレサーバ運用を経て

    2019年9月にPF-SREチームへ、

    パブリッククラウド・k8sを初体験しながら

    ZOZOリプレイスに携わっている。

    29

    View Slide

  30. © ZOZO Technologies, Inc.
    アジェンダ

    ● ZOZOTOWNリプレイスの全体感 (そのっつ)

    ● ID基盤の概要 (以降、亀井)

    ● 更新系ワークロードのリプレイス方法

    ● AWS/EKSで実施したセキュリティへの取り組み

    ● 課題と今後

    30

    View Slide

  31. © ZOZO Technologies, Inc.
    お話ししないこと

    ● アプリケーションの説明

    ● k8sクラスタの構築内容

    ● IaC、CI/CDの手法

    31

    View Slide

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

    32

    View Slide

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

    33

    View Slide

  34. © ZOZO Technologies, Inc.
    API Gateway

    ● API の Gateway となるマイクロサービス

    ● マイクロサービス化にあたりID基盤に先行してリリース済み

    ● API コントローラー、SSL終端 などの役割をもつ


    34
    新フレームワーク
    ロジック
    (Web表示のみ)
    ユーザー
    サービス
    RO
    お気に入り
    サービス
    RW
    商品
    サービス
    RW
    API Gateway
    ID認証
    サービス
    RW
    これ

    View Slide

  35. © ZOZO Technologies, Inc.
    API Gatewayは自前で実装

    ● AWS にはマネージドサービスの API Gateway がある

    ● 複雑な要求に柔軟に対応するために自前実装

    ○ エンドポイントを複数もつサービス(マルチクラウド/マルチクラスタ)に対し、

    エラーやタイムアウト時に別エンドポイントへのリトライ

    ○ ヘッダー (Client-Token) によるクライアント認証機能

    など

    ● AWS/EKSで構築

    35

    View Slide

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

    36

    View Slide

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

    ● ZOZOTOWN は ZOZO ID という認証システムがある

    ● ID基盤は ZOZO ID のモダン化リプレイスプロジェクト

    ● PF-SRE のマイクロサービス第二弾 (話せば長くなる)

    37

    View Slide

  38. © ZOZO Technologies, Inc.
    ID基盤の特徴

    ● 更新系ワークロードを扱う

    ○ 更新系 : 会員登録/更新/退会()
    ○ 参照系 : ログイン/トークン発行/トークンリフレッシュ
    など

    ● 個人情報も扱う

    ○ email

    ○ password

    ○ phone

    38

    View Slide

  39. © ZOZO Technologies, Inc.
    ID基盤の特徴

    ● 更新系ワークロードを扱う

    ○ 更新系 : 会員登録(insert)/更新(update)/退会(delete )
    ○ 参照系 : ログイン/トークン発行/トークンリフレッシュ
    など

    ● 個人情報も扱う

    ○ email

    ○ password

    ○ phone

    39
    ZOZOTOWNにおける

    更新系ワークロードの

    リプレイス第一弾


    View Slide

  40. © ZOZO Technologies, Inc.
    ID基盤の特徴

    ● 更新系ワークロードを扱う

    ○ 更新系 : 会員登録/更新/退会()
    ○ 参照系 : ログイン/トークン発行/トークンリフレッシュ
    など

    ● 個人情報も扱う

    ○ email

    ○ password

    ○ phone

    40
    高セキュリティの

    インフラが求められる


    View Slide

  41. © ZOZO Technologies, Inc.
    求められた要件

    ● クラウドネイティブ化

    ● マイクロサービス化

    ● CI/CD (Continuous Integration / Continuous Delivery) 化

    ● IaC (Infrastructure as Code) 化

    ● 開発ガイドライン(社内ガイドライン)のセキュリティ要件の遵守

    41

    View Slide

  42. © ZOZO Technologies, Inc.
    従来のアーキテクチャ

    ● オンプレミスで構成されていた

    42
    FW / WAF
    Load Balancer
    オンプレミス
    Web Server
    (IIS)
    DB Server
    (SQL Server)
    ● 巨大でモノリシック

    ● Web Server は Classic ASP で実装さ
    れ 多数の細かいサービスが混在

    ● DB Server は 用途ごとに物理的にイ
    ンスタンスが分割されているものの、
    多数の細かいサービス用のテーブル
    が混在

    ※簡易的なアーキテクチャ図です

    TCP : xxx

    View Slide

  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

    View Slide

  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

    View Slide

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

    ● AWS のフルマネージド型の Kubernetes (以後 k8s) サービス

    ● コントロールプレーンの管理は不要

    ● EC2マネージドノードグループを採用することで、

    ワーカーノードの構築、運用負荷も最小限

    ● k8s のメリットを享受できる

    ○ オートスケールや自動修復

    ○ コントローラーによる高い拡張性・柔軟性


    クラウドのメリットを最大限活用するため、EKSを採用

    45

    View Slide

  46. © ZOZO Technologies, Inc.
    Aurora MySQL

    ● フルマネージド型でMySQL互換のRDSサービス

    ● 高い可用性

    ○ データは99.99%の可用性

    ○ レプリカへのフェイルオーバーは約30秒程度

    ● LTS (Long Time Support) バージョンが用意されており

    最低限のバージョンアップ頻度としダウンタイムを最小化できる



    MySQL互換であり高い可用性から、Aurora MySQLを採用


    46

    View Slide

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

    ● ID基盤 = 新 ZOZO ID

    ● オンプレ→クラウドへ、初の更新系リプレイス

    ● マイクロサービス 第二弾

    ● AWS/EKS/Aurora で構築

    ● API Gateway と AWS アカウントを分離(後述)

    47

    View Slide

  48. © ZOZO Technologies, Inc.
    更新系ワークロードの

    リプレイス方法

    48

    View Slide

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

    View Slide

  50. © ZOZO Technologies, Inc.
    今までのリプレイス方法

    ● 参照系ワークロードの例

    ○ SQL Server to SQL Server

    ○ サービス停止はしない

    ○ SQL Server レプリケーションでデータを移行


    50

    View Slide

  51. © ZOZO Technologies, Inc.
    今までのリプレイス方法

    ● 参照系ワークロードの例

    ○ SQL Server to SQL Server

    ○ サービス停止はしない

    ○ SQL Server レプリケーションでデータを移行


    ● ID基盤では今までの方法は使えなかった

    ○ to MySQLのため、SQL Server レプリケーションは使えない

    ○ 再実装でテーブル構造が異なる

    51

    View Slide

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

    View Slide

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

    View Slide

  54. © ZOZO Technologies, Inc.
    ダブルライト

    ● ID基盤でユーザー登録/更新/削除を行うダブルライトAPIを実装

    ● 更新ワークロードを行うクライアント (ASP)で

    ZOZO ID 更新時にダブルライトAPIを叩いてもらうリリース

    ● ダブルライト開始後のデータは新・旧DBで同一となる状態

    ● ダブルライトAPIはUPSERT (レコードが存在しなければINSERT、存在すればUPDATE) で実装

    ○ ダブルライトのデータ更新が常に正となる

    ○ 次のデータ移行 (backfill) 時に必要となる実装



    54

    View Slide

  55. © ZOZO Technologies, Inc.
    データ移行(bulkload)

    ● SQL Serverのデータを抽出し、MySQLの一時テーブルへ移行

    ○ ダブルライト中でデータがたまり始めた本番テーブルでなく、

    ID基盤内に用意した一時テーブルへ

    ● Embulkを使った

    ○ データ転送ツール

    ○ SQL Server to MySQL のプラグインあり

    ○ 社内実績あり

    ○ データを加工し、テーブル構造の差分も解決

    ■ データ抽出時のSQLで “ごにょごにょ” 加工する

    55

    View Slide

  56. © ZOZO Technologies, Inc.
    データ移行(backfill)

    ● MySQLの一時テーブルから、本番テーブルへ過去データの穴埋め

    ○ 既存データは上書きしない (duplicate entry は諦める)

    ○ ダブルライトとバッティングする可能性が考えられたため、

    ダブルライトは UPSERT を実装

    (もしバッティングしても、ダブルライトでUPDATE され最新データを取り込むことができる)

    ● Golangで実装した

    ○ アプリケーションに合わせて Golang

    ○ 高速化のため、1000件程度の bulk insert し

    失敗したら1件ずつ insert する

    56

    View Slide

  57. © ZOZO Technologies, Inc.
    結果

    ● 大変だったこと

    ○ 旧DBに重複したデータが存在していた

    → データを確認し、必要なデータのみ移行

    ○ 移行データの整合性チェック

    → validateを用意 (Golang)

    ○ 退会時のデータ削除が、旧DBは論理削除、新DBは物理削除

    backfillにてユーザが復活してしまうことが懸念された

    → 移行後に復活した削除ユーザを抽出、削除した


    ● 約2千万件の移行で約 25 min (bulkload 10min、backfill 15min)


    57

    View Slide

  58. © ZOZO Technologies, Inc.
    AWS/EKSで実施した

    セキュリティへの取り組み

    58

    View Slide

  59. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    59
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    開発ガイドラインから下記のセキュリティ要件が求められた


    View Slide

  60. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    60
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    下記4項目の取り組みについてお話します


    View Slide

  61. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    61
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    ※WAFは、課題と今後 にて後ほどお話します


    View Slide

  62. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    62
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    下記4項目の取り組みについてお話します

    ① 個人情報を扱わない Pod が、

    Aurora の個人情報を参照できないよう制限する取り組み

    View Slide

  63. © ZOZO Technologies, Inc.
    Auroraアクセス制限 案1

    Pod に IAMロール をつけ、権限を分離する方法


    ● 概要

    ○ IRSA (IAM Roles for Service Accounts) を使う

    ○ IAMロールを k8s の Service Account に関連付ける

    ○ Pod ごとに Service Account を分離し、アクセスを制限する


    63

    View Slide

  64. © ZOZO Technologies, Inc.
    Auroraアクセス制限 案1

    Pod に IAMロール をつけ、権限を分離する方法


    ● 問題

    ○ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい
    IAM データベース認証は 200接続/秒 の制約があるため
    ● 結論

    ○ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない

    64

    View Slide

  65. © ZOZO Technologies, Inc.
    Auroraアクセス制限 案1

    Pod に IAMロール をつけ、権限を分離する方法


    ● 問題

    ○ Aurora MySQL の認証は ID/PW のネイティブ認証を使いたい
    IAM データベース認証は 200接続/秒 の制約があるため
    ● 結論

    ○ Aurora が ID/PWの認証なので、IAMレベルの分離をしても意味がない
    65
    NG

    View Slide

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


    ● 概要

    ○ k8s の NetworkPolicy を使う

    ○ 送信、受信の制御ルールを Pod ごとに定義する

    ○ ネットワークを分離することでアクセス制限ができる

    ○ ルールの宛先は CIDR で記述する

    ○ 送信の制御ルールを定義する場合、どちらかが考えられる

    ■ 全トラフィックを拒否し、許可する通信先を Allow List 化

    ■ 全トラフィックを許可し、拒否する通信先を Block list 化


    Auroraアクセス制限 案2

    66

    View Slide

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


    ● 問題

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

    67

    View Slide

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


    ● 問題

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

    68
    NG

    View Slide

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


    ● 概要

    ○ Pod にセキュリティグループをつける

    ○ Aurora は許可したいセキュリティグループからの通信を許可

    ○ セキュリティグループを分離することでアクセス制限ができる

    Auroraアクセス制限 案3

    69

    View Slide

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


    ● 問題

    ○ まだ機能として存在しない

    ロードマップには存在するが開発中

    ○ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり

    ノードグループごとにセキュリティグループを分けることも不可能


    ● 結論

    ○ 一番シンプルで現実的な方法だが、今はできない

    Auroraアクセス制限 案3

    70

    View Slide

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


    ● 問題

    ○ まだ機能として存在しない

    ロードマップには存在するが開発中

    ○ マネージドノードグループは、セキュリティグループの設定がクラスタ単位となり

    ノードグループごとにセキュリティグループを分けることも不可能


    ● 結論

    ○ 一番シンプルで現実的な方法だが、今はできない

    Auroraアクセス制限 案3

    71
    NG

    View Slide

  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

    View Slide

  73. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    73
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    下記4項目の取り組みについてお話します

    ② コンテナイメージの脆弱性を速やかに検知する取り組み


    View Slide

  74. © ZOZO Technologies, Inc.
    コンテナイメージ脆弱性の検知

    ● 脆弱性は日々増える

    ○ 新たに発見される

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


    74

    View Slide

  75. © ZOZO Technologies, Inc.
    コンテナイメージ脆弱性の検知

    ● 脆弱性は日々増える

    ○ 新たに発見される

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

    ● イメージ脆弱性スキャンツールを導入

    ○ 脆弱性ソースが多く、検知精度の高い Trivy を採用

    75

    View Slide

  76. © ZOZO Technologies, Inc.
    コンテナイメージ脆弱性の検知

    ● 脆弱性は日々増える

    ○ 新たに発見される

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

    ● イメージ脆弱性スキャンツールを導入

    ○ 脆弱性ソースが多く、検知精度の高い Trivy を採用

    ● 確実に検知できるよう、GitHub Actions で自動実行

    ○ 1日一回実行

    ○ Pull Request の push 都度実行

    76

    View Slide

  77. © ZOZO Technologies, Inc.
    Trivyスキャン導入の効果

    ● 結果

    ○ 2件の脆弱性を検知、修正

    ■ CVE-2020-13777 (libgnutls30)

    ■ CVE-2020-10878 (perl)


    ● 参考情報も一緒に出力され、すぐに修正に取りかかれる点がGood!

    77

    View Slide

  78. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    78
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    下記4項目の取り組みについてお話します

    ③ k8s manifest の秘密情報を、隠匿しつつコード管理する取り組み


    View Slide

  79. © ZOZO Technologies, Inc.
    ● k8s の秘密情報管理といえば、Secrets リソース
    ○ base64 でデコード可能なため、そのままコード管理するべきでない


    ● 解決するツールはいくつかあった

    ○ godaddy/kubernetes-external-secrets
    ○ bitnami-labs/sealed-secrets
    など

    k8sの秘密情報管理

    79

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  83. © ZOZO Technologies, Inc.
    運用後直面した課題と解決

    ● 課題

    ○ 更新した Secrets を Pod にリロードさせる必要がある

    ○ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない

    ■ 自動更新である external-secrets と Deployment の更新を合わせることは難しい



    83

    View Slide

  84. © ZOZO Technologies, Inc.
    運用後直面した課題と解決

    ● 課題

    ○ 更新した Secrets を Pod にリロードさせる必要がある

    ○ Secrets と Deployment (Podのコンテナイメージ)を同時に更新できない

    ■ 自動更新である external-secrets と Deployment の更新を合わせることは難しい


    ● 解決

    ○ Controller の Polling を OFF にし、自動更新を停止する

    ○ ExternalSecrets リソースは更新でなく毎回 name を変え、新規作成する

    ■ Secrets リソースも毎回新規作成される

    ○ Deployment は毎回新しい Secrets リソースを指定する

    84

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  88. © ZOZO Technologies, Inc.
    求められたセキュリティ要件

    88
    分類 要件
    アカウント管理 ログインアカウントを共有してはならない

    アカウントは最小限の原則に基づいて権限設定をする

    個人情報管理 高度なアクセス管理のできない場所に個人情報を保存してはならない

    アプリケーション管理 セキュリティアップデートを速やかに取り入れる
    アクセス管理 WAF (Web Application Firewall / L7 Firewall) を設定する
    秘密情報管理 秘密情報を平文で保存してはならない
    ログ管理 本番環境の設定変更/操作ログを取得・永続化
    パブリッククラウドの監査ログを取得・永続化

    下記4項目の取り組みについてお話します

    ④ kubectl exec で Pod にログインした際の

    Pod 上でのコマンド実行ログを取得する取り組み


    View Slide

  89. © ZOZO Technologies, Inc.
    Pod上でのコマンド実行ログ

    ● 設定した一般的な EKS のログ








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

    ● CloudWatch Agent

    ● Fluentd CloudWatch


    View Slide

  90. © ZOZO Technologies, Inc.
    Pod上でのコマンド実行ログ

    ● 設定した一般的な EKS のログ









    ● kubectl exec で Pod ログイン後のコマンド実行ログは別途実装する必要があった

    ○ 調査のために Pod にログインすることはある

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

    ● CloudWatch Agent

    ● Fluentd CloudWatch


    View Slide

  91. © ZOZO Technologies, Inc.
    Pod上でのコマンド実行ログ

    ● Falco を使う

    ○ コンテナアプリケーションやホスト、ネットワークの

    異常検知を行うコンテナランタイムセキュリティツール

    ○ できること

    ■ システムコールを解析する

    ■ rule に従ってアクティビティを検知し、outputする


    91

    View Slide

  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

    View Slide

  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

    View Slide

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


    94

    View Slide

  95. © ZOZO Technologies, Inc.
    リプレイス半ばである

    ● ID基盤を使うクライアントは2つ

    ○ フロントエンドWebサーバ ASP(社内)

    ○ iOS/Androidアプリ

    ● リプレイスのフェーズと現状 

    ○ Phase1 : ダブルライト

    ○ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint)

    ○ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint)

    ○ Phase4 : 更新ワークロードの切り替え

    95

    View Slide

  96. © ZOZO Technologies, Inc.
    リプレイス半ばである

    ● ID基盤を使うクライアントは2つ

    ○ フロントエンドWebサーバ ASP(社内)

    ○ iOS/Androidアプリ

    ● リプレイスのフェーズと現状 

    ○ Phase1 : ダブルライト

    ○ Phase2 : フロントエンドWebサーバ ASP 参照ワークロード切り替え (Private Endpoint)

    ○ Phase3 : iOS/Androidアプリ 参照ワークロード切り替え (Public Endpoint)

    ○ Phase4 : 更新ワークロードの切り替え


    現状は Phase2 まで完了

    96

    View Slide

  97. © ZOZO Technologies, Inc.
    Phase3から求められる要件

    ● Phase3 : iOS/Androidアプリ 参照ワークロード切り替え

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

    97

    View Slide

  98. © ZOZO Technologies, Inc.
    Phase3から求められる要件

    ● Phase3 : iOS/Androidアプリ 参照ワークロード切り替え

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

    ● オンプレミスで実施している攻撃対策

    ○ ログイン異常の検知

    ○ 悪意あるユーザの (SourceIP/User-Agent などで) Block

    ○ DDoS対策

    など


    98

    View Slide

  99. © ZOZO Technologies, Inc.
    Phase3から求められる要件

    ● Phase3 : iOS/Androidアプリ 参照ワークロード切り替え

    ○ Public なエンドポイントを用意するため、

    エンドポイントに対する攻撃対策が必要になってくる

    ● オンプレミスで実施している攻撃対策

    ○ ログイン異常の検知

    ○ 悪意あるユーザの (SourceIP/User-Agent などで) Block

    ○ DDoS対策

    など


    ID基盤版の対策検討中

    検討中の内容を一部紹介します

    99

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  103. © ZOZO Technologies, Inc.
    まとめ

    103

    View Slide

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

    104

    ● ZOZOTOWNの成長のためリプレイスを加速させている


    ● 2020年度、まずは 変更しやすく するため 2つの施策を進めている

    ● DB接続のAPI化(ストアドはがし)

    ● マイクロサービスの立ち上げ


    ● 2020年度、マイクロサービスの完成形テンプレートを作る

    そのために組織も変えた


    View Slide

  105. © ZOZO Technologies, Inc.
    ID基盤のリプレイスと取り組み

    105

    ● 従来のオンプレモノリシックなアーキテクチャから

    マイクロサービスアーキテクチャへと作り変えている


    ● ダブルライト、bulkload、backfill という手法で

    メンテナンスを設けずデータの移行を行った


    ● セキュリティ向上のため、AWS/EKSで様々な取り組みを行っている



    これを基準として、ZOZOTOWN のリプレイスを加速させていきます!


    View Slide

  106. View Slide