[SRE NEXT 2023] プラットフォームSREによる脆弱性対策を意識したコンテナビルドフロー構築

SRE NEXT 2023
https://sre-next.dev/2023/

[Speaker]
株式会社スクウェア・エニックス 情報システム部 オンラインサービス・インフラストラクチャー クラウドエンジニア(SRE)
橋本 和宏

[Description]
株式会社スクウェア・エニックスのとあるシステムでフロンエンドのアプリケーション・サーバーがコンテナ化されるにあたり、コンテナビルド時の脆弱性検知/対策ができるビルドフローの構築を進めていました。この仕組みの概観についてお話したいと思います。
インフラ寄りの視点であることとsysdigのcli-scannerという特定製品の脆弱性検知の仕組みの説明になりますが、コンテナ/Kubernetes環境での脆弱性対策のフロー構築の参考になるように説明できればと思います。

Transcript

1. © SQUARE ENIX
   プラットフォームSREによる
   脆弱性対策を意識した
   コンテナビルドフロー構築
   株式会社スクウェア・エニックス Online Service Infrastructure, SRE 橋本 和宏
   

   View Slide

2. © SQUARE ENIX
   自己紹介
   ● 2020年1月〜JOIN
   ● 担当システム
   ○ グローバルゲームインフラ 2020〜
   ○ ソーシャルゲームバックエンドシステム 2021〜
   ● クラウドエンジニア Site Reliability Engineering
   ○ LinkedIn: https://www.linkedin.com/in/sqex-kaz/
   ○ GCP, IaC(Terraform, Ansible), セキュリティ, チームビルド/採用
   ● 好きなゲーム:
   ○ FF14/FF11(MMO), FF Tactics, FF16 ← New!
   ○ AC6, Starfield, Cities: Skylines II …
   

   View Slide

3. © SQUARE ENIX
   スクエニ ITエンジニアブログ
   

   View Slide

4. © SQUARE ENIX
   お話すること
   ● セキュリティ対策とビルドフロー
   ● ビルドフローを作る＆脆弱性を検知する
   ● 脆弱性対策を回す
   

   View Slide

5. © SQUARE ENIX
   今回のお話のシステムについて
   HDゲーム
   スマートフォン
   MMO
   商用サービス・インフラ
   (Online Service Infrastructure)
   Game
   Projects
   Game
   Projects
   Game
   Projects
   Game
   Projects
   Backend
   Platform
   

   View Slide

6. © SQUARE ENIX
   今回のお話のシステムについて
   Cloud Load
   Balancing
   Application Servers
   Kubernetes Cluster
   GKE
   Multiple Instances
   Datastore Servers
   Virtual Machines
   Compute Engine
   Multiple Instances
   ● フロントエンドのサーバ
   ○ コンテナ
   ○ Kubernetes(GKE)にデプロイ
   ● バックエンドのデータストアサーバ(MySQL, Redis等)
   ○ VM
   ○ Ansibleでプロビジョニング/Terraformで起動
   RedisはRedis Labs Ltd.の登録商標です
   KafkaはApache Software Foundationの登録商標です
   MySQLはOracleおよび/またはその関連会社の登録商標です
   GCPアイコンは”Google Cloud Official Icons and Solution Architectures”から使用
   

   View Slide

7. © SQUARE ENIX
   システム・ライフサイクル
   - ビルドフローはコンテナイメージ と VMイメージ それぞれ
   - ソフトウェアはいくつかの言語 と OSパッケージ(deb, rpm etc.)
   k8s Pods VM Instances
   Cloud Load
   Balancing
   Application Servers
   Kubernetes Cluster
   GKE
   Multiple Instances
   Datastore Servers
   Virtual Machines
   Compute Engine
   Multiple Instances
   Custom Image
   Provisioning
   Docker
   Build
   App Build
   PackerはHashiCorpの登録商標です
   GitHub は、GitHub Inc.の商標または登録商標です
   Ansible®のアイコンはAnsibleコミュニティ(https://www.ansible.com/logos)提供のものを使用
   Docker は、米国およびその他の国で登録された Docker, Inc. の登録商標または商標です
   

   View Slide

8. © SQUARE ENIX
   コンテナのビルドフロー
   1. コンテナイメージのビルド
   - アプリケーションビルド → Docker build
   2. コンテナレジストリへのpush
   3. コンテナ起動
   Container
   Registry
   GKE Processes
   

   View Slide

9. © SQUARE ENIX
   VMのビルドフロー
   VMはアプリビルドフローは絡まない（
   Datastore系サーバしかないため）
   - VMイメージのプロビジョニング
   - カスタムイメージ
   - インスタンス起動
   ブログ記事へのURL
   Processes
   Disk Image VM
   Instance
   

   View Slide

10. © SQUARE ENIX
    どこで脆弱性を検知するか（コンテナ）
    Container
    Registry
    GKE Processes
    コンテナ・スキャナー
    言語パッケージのスキャナー
    レジストリ・スキャナー
    ランタイム・スキャナー
    

    View Slide

11. © SQUARE ENIX
    どこで脆弱性を検知するか（VM）
    ランタイム・スキャナー
    Processes
    Disk Image VM
    Instance
    

    View Slide

12. © SQUARE ENIX
    どんな検知がされるのか？
    例) GCP レジストリスキャナの結果
    例) Sysdig ホストスキャナの結果
    

    View Slide

13. © SQUARE ENIX
    どんな検知がされるのか？
    例) Sysdig ホストスキャナの結果
    

    View Slide

14. © SQUARE ENIX
    脆弱性検知の大変さ
    ● 「見つける」までの大変さ
    ● 「見つけた」あとの大変さ
    スキャン 対応
    集約 分析
    (トリアージ)
    〜見つける 見つけた〜
    ● スキャンツールの導入・維持
    ○ 対応OSパッケージ・言語パッケージ
    ○ CVEのマッチング
    ○ ビルドフローへの組み込み
    ● 集約する仕組み
    ○ 自前で作ろうとすると結構大変
    ● 「見つける」までの大変さ
    ● 「見つけた」あとの大変さ
    ● 分析
    ○ 沢山でてくる脆弱性に溺れる
    ● 対応
    ○ 適用をし続けていく大変さ
    

    View Slide

15. © SQUARE ENIX
    当環境での脆弱性検知とSysdig
    スキャン 対応
    集約 分析
    (トリアージ)
    

    View Slide

16. © SQUARE ENIX
    コンテナのビルドフローとSysdig脆弱性検知
    Container
    Registry
    GKE Processes
    当環境では未使用
    事前に検知
    “Shift Left”
    稼働中コンテナの検査
    Buildせず直接使うコンテナの検査
    ※inUse判定
    

    View Slide

17. © SQUARE ENIX
    コンテナのビルドフローとSysdig脆弱性検知
    ①
    ① ベースイメージのビルド
    ② push前にスキャン
    ③ 脆弱性がなければpush
    ④ アプリイメージのビルド
    ⑤ push前にスキャン
    ⑥ 脆弱性がなければpush
    ②
    ③
    ④
    ⑤ ⑥
    ④
    

    View Slide

18. © SQUARE ENIX
    helmでsysdig-agent etc.をinstall
    agentがdaemon-setとして起動
    containerやnodeに対してスキャン
    Sysdigによる脆弱性検知の仕組み（コンテナ）
    Kubernetes Cluster
    Namespace
    Application
    Node
    Namespace Namespace
    Node
    Node
    nodeに対しても検査
    

    View Slide

19. © SQUARE ENIX
    Sysdigを使った脆弱性検知の仕組み（VM）
    Processes
    Disk Image VM Instance
    (OS)
    

    View Slide

20. © SQUARE ENIX
    脆弱性を”見つける”まで
    - コンテナ・VMホストからの脆弱性検知はSysdig Cloud(SaaS)へ集約される
    

    View Slide

21. © SQUARE ENIX
    例) あるコンテナのスキャン結果 (overview)
    

    View Slide

22. © SQUARE ENIX
    例) あるコンテナのスキャン結果 (vulnerability)
    

    View Slide

23. © SQUARE ENIX
    スキャン・ポリシー
    - sysdig-cli-scannerは発見した”脆弱性等”の条件（Policy）によりnon-zero終了する
    - PolicyはSysdig Cloud側で定義されている
    - 脆弱性の”あるなし”だけでは判定していない
    vulns
    ?
    non-zero exit
    Default Rule Bundle
    ● 脆弱性のSeverityがCritical, High以上
    ● 修正版がリリース済かどうか
    ● Attack VectorがNetworkかどうか
    上記の組み合わせ＋ αのルール（詳細割愛）
    ※ 脆弱性検知とは違う観点でroot以外のユーザか？などのポ
    リシーも追加可能
    

    View Slide

24. © SQUARE ENIX
    見つけたあとの対応
    - Sysdigで集約までは楽に行うことができた
    - 分析してトリアージ（優先度をつけて分類）が必要
    😯
    

    View Slide

25. © SQUARE ENIX
    ツール / バッチ周
    辺系
    トリアージの考え方
    - 2つの要素で考える
    - システム（≒ サーバ）の位置
    - 脆弱性の状態
    位置
    状態
    インターネット
    (外部)
    バックエンド
    (DB等)
    フロント
    &着信するもの
    高 中〜低
    AttackVector
    etc.
    Exploit
    可能？
    修正版
    リリース？
    AV: Network
    の場合は優先
    可能な場合は
    優先
    リリースなけれ
    ば他の緩和策
    CVSS
    Severity
    

    View Slide

26. © SQUARE ENIX
    トリアージの考え方
    例
    ● CVSS: 9.8
    ● Severity: Critical
    ● AttackVedctor: Network
    ● Server: Front Application
    ● CVSS: 9.8
    ● Severity: Critical
    ● AttackVedctor: Local
    ● Server: Backend Batch
    完全に正しい対応をすることは難しい
    全ての脆弱性に対して対応することも難しい
    

    View Slide

27. © SQUARE ENIX
    対応
    - 大きなテーマ & 本筋ではないので省略するものの
    - 素早く適用できるようにするには課題が多い
    - できれば”勝手に上がって良い”ところは”勝手に上げる”
    - Application / Microservices
    - リリースはk8sの為 比較的容易
    - 量が多いので伝播に時間がかかる
    - DB(特にMySQL)
    - 気軽には再起動できない
    - 量が多い...
    

    View Slide

28. © SQUARE ENIX
    トリアージや対応が完全ではなくても
    事前対策
    （防御・検知）
    事後対策
    （監査・検知）
    ソフトウェアの脆弱性 ✔
    設定不備（クラウド・サーバ等）
    権限の設定不備
    ゼロデイ攻撃
    情報持ち出し・スパイウェア等
    - 脆弱性対策はセキュリティ対策の数あるうちの一つである
    - “多重防御” のうちの一つであり、ここだけ完璧にする必要はないと考える
    

    View Slide

29. © SQUARE ENIX
    まとめ
    ● 脆弱性対策の運用は難しい
    ○ 検知する仕組みを作る大変さ
    ○ 検知した結果をもとに対応していく大変さ
    ● ツールの力を使って大変なフローを回すことに力を入れる
    ○ 運用をはじめることが大事
    ○ 複雑な仕組みになるので自作よりも統合的なツールを使うのが現実的
    ● 1つの対策で全て完璧にやろうとしない
    ○ 脆弱性対策は多層防御の一つでしかない
    ○ 他の対策との合せ技で強固にしていく
    

    View Slide

30. © SQUARE ENIX
    ご清聴ありがとうございました。
    本日の資料はこちらのQRコードからアンケート回答いただけるとダウンロードいただけ
    ます
    

    View Slide