[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 橋本 和宏
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 …
3. © SQUARE ENIX スクエニ ITエンジニアブログ
4. © SQUARE ENIX お話すること • セキュリティ対策とビルドフロー • ビルドフローを作る＆脆弱性を検知する • 脆弱性対策を回す
5. © SQUARE ENIX 今回のお話のシステムについて HDゲーム スマートフォン MMO 商用サービス・インフラ (Online Service Infrastructure) Game Projects Game Projects Game Projects Game Projects Backend Platform
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”から使用
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. の登録商標または商標です
8. © SQUARE ENIX コンテナのビルドフロー 1. コンテナイメージのビルド - アプリケーションビルド → Docker build 2. コンテナレジストリへのpush 3. コンテナ起動 Container Registry GKE Processes
9. © SQUARE ENIX VMのビルドフロー VMはアプリビルドフローは絡まない（ Datastore系サーバしかないため） - VMイメージのプロビジョニング - カスタムイメージ - インスタンス起動 ブログ記事へのURL Processes Disk Image VM Instance
10. © SQUARE ENIX どこで脆弱性を検知するか（コンテナ） Container Registry GKE Processes コンテナ・スキャナー 言語パッケージのスキャナー レジストリ・スキャナー ランタイム・スキャナー
11. © SQUARE ENIX どこで脆弱性を検知するか（VM） ランタイム・スキャナー Processes Disk Image VM Instance
12. © SQUARE ENIX どんな検知がされるのか？ 例) GCP レジストリスキャナの結果 例) Sysdig ホストスキャナの結果
13. © SQUARE ENIX どんな検知がされるのか？ 例) Sysdig ホストスキャナの結果
14. © SQUARE ENIX 脆弱性検知の大変さ • 「見つける」までの大変さ • 「見つけた」あとの大変さ スキャン 対応 集約 分析 (トリアージ) 〜見つける 見つけた〜 • スキャンツールの導入・維持 ◦ 対応OSパッケージ・言語パッケージ ◦ CVEのマッチング ◦ ビルドフローへの組み込み • 集約する仕組み ◦ 自前で作ろうとすると結構大変 • 「見つける」までの大変さ • 「見つけた」あとの大変さ • 分析 ◦ 沢山でてくる脆弱性に溺れる • 対応 ◦ 適用をし続けていく大変さ
15. © SQUARE ENIX 当環境での脆弱性検知とSysdig スキャン 対応 集約 分析 (トリアージ)
16. © SQUARE ENIX コンテナのビルドフローとSysdig脆弱性検知 Container Registry GKE Processes 当環境では未使用 事前に検知 “Shift Left” 稼働中コンテナの検査 Buildせず直接使うコンテナの検査 ※inUse判定
17. © SQUARE ENIX コンテナのビルドフローとSysdig脆弱性検知 ① ① ベースイメージのビルド ② push前にスキャン ③ 脆弱性がなければpush ④ アプリイメージのビルド ⑤ push前にスキャン ⑥ 脆弱性がなければpush ② ③ ④ ⑤ ⑥ ④
18. © SQUARE ENIX helmでsysdig-agent etc.をinstall agentがdaemon-setとして起動 containerやnodeに対してスキャン Sysdigによる脆弱性検知の仕組み（コンテナ） Kubernetes Cluster Namespace Application Node Namespace Namespace Node Node nodeに対しても検査
19. © SQUARE ENIX Sysdigを使った脆弱性検知の仕組み（VM） Processes Disk Image VM Instance (OS)
20. © SQUARE ENIX 脆弱性を”見つける”まで - コンテナ・VMホストからの脆弱性検知はSysdig Cloud(SaaS)へ集約される
21. © SQUARE ENIX 例) あるコンテナのスキャン結果 (overview)
22. © SQUARE ENIX 例) あるコンテナのスキャン結果 (vulnerability)
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以外のユーザか？などのポ リシーも追加可能
24. © SQUARE ENIX 見つけたあとの対応 - Sysdigで集約までは楽に行うことができた - 分析してトリアージ（優先度をつけて分類）が必要 😯
25. © SQUARE ENIX ツール / バッチ周 辺系 トリアージの考え方 - 2つの要素で考える - システム（≒ サーバ）の位置 - 脆弱性の状態 位置 状態 インターネット (外部) バックエンド (DB等) フロント &着信するもの 高 中〜低 AttackVector etc. Exploit 可能？ 修正版 リリース？ AV: Network の場合は優先 可能な場合は 優先 リリースなけれ ば他の緩和策 CVSS Severity
26. © SQUARE ENIX トリアージの考え方 例 • CVSS: 9.8 • Severity: Critical • AttackVedctor: Network • Server: Front Application • CVSS: 9.8 • Severity: Critical • AttackVedctor: Local • Server: Backend Batch 完全に正しい対応をすることは難しい 全ての脆弱性に対して対応することも難しい
27. © SQUARE ENIX 対応 - 大きなテーマ & 本筋ではないので省略するものの - 素早く適用できるようにするには課題が多い - できれば”勝手に上がって良い”ところは”勝手に上げる” - Application / Microservices - リリースはk8sの為 比較的容易 - 量が多いので伝播に時間がかかる - DB(特にMySQL) - 気軽には再起動できない - 量が多い...
28. © SQUARE ENIX トリアージや対応が完全ではなくても 事前対策 （防御・検知） 事後対策 （監査・検知） ソフトウェアの脆弱性 ✔ 設定不備（クラウド・サーバ等） 権限の設定不備 ゼロデイ攻撃 情報持ち出し・スパイウェア等 - 脆弱性対策はセキュリティ対策の数あるうちの一つである - “多重防御” のうちの一つであり、ここだけ完璧にする必要はないと考える
29. © SQUARE ENIX まとめ • 脆弱性対策の運用は難しい ◦ 検知する仕組みを作る大変さ ◦ 検知した結果をもとに対応していく大変さ • ツールの力を使って大変なフローを回すことに力を入れる ◦ 運用をはじめることが大事 ◦ 複雑な仕組みになるので自作よりも統合的なツールを使うのが現実的 • 1つの対策で全て完璧にやろうとしない ◦ 脆弱性対策は多層防御の一つでしかない ◦ 他の対策との合せ技で強固にしていく
30. © SQUARE ENIX ご清聴ありがとうございました。 本日の資料はこちらのQRコードからアンケート回答いただけるとダウンロードいただけ ます