コンテナセキュリティの概要とデプロイフローに組み込んだ後の課題

by Takashi Yamaguchi

Slide 1

Slide 1 text

株式会社 Gunosy テクノロジー本部プロダクト開発部 SREチームマネージャー山口隆史 2024年2月16日(金) コンテナセキュリティの概要とデプロイフローに組み込んだ後の課題

Slide 2

Slide 2 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 2 エレベーターピッチ［セキュリティに興味がある人］、［セキュリティをこれから始めたい人］向けに発表する［コンテナセキュリティの概要とデプロイフローに組み込んだ後の課題］は［現場にセキュリティを適用した後の話］ですこれは［大きくない開発組織でのセキュリティ対応の現場での実践に基づいて構成しているため、現実感］がありこれまでの成功事例やベンダーのセールス資料とは違って［コンテナセキュリティの全体像と定常運用した時の課題に焦点をあてている］

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 5 自己紹介氏名：山口隆史(やまぐちたかし) 所属：株式会社Gunosy テクノロジー本部プロダクト開発部 SREチームマネージャー業務：コンサルティング SREとしての活動略歴：フリーランス、SIer等を渡り歩く→現職（2022/01〜）自称：Security Hub芸人好きなAWSサービス：Security Hub、GuardDuty、サポート他：AWS Community Builder(Security & Identity)、JAWS-UG千葉支部運営、　　Snyk Ambassador 第022587号

Slide 6

Slide 6 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 6 株式会社Gunosy ギリシャ語で「知識」を意味する「Gnosis（グノーシス）」＋「u(“you”)」「”Gnosis” for “you”」あなたのための知識　＝情報を届けるサービスを提供し続ける、という意味 ■ 2012年11月創業 ■ 2015年4月東証マザーズ上場 ■ 2017年12月東証第一部に市場変更 ■ 2022年4月東京証券取引所の市場一部からプライム市場に移行 ■ 従業員数 252名（2023年5月末現在連結ベース） ■ 事業内容 – 情報キュレーションサービスその他メディアの開発及び運営 ■ 提供サービス　グノシー、ニュースパス、 auサービスToday、企業理念「情報を世界中の人に最適に届ける」

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 20 セキュリティの原則出典：コンテナセキュリティ P.32-33 ■ 最小権限 – 処理を実行するのに最小の権限に制限する ■ 多層防御 – 攻撃者がある防御を突破できても別のレイヤー防ぐ ■ 攻撃対象領域の縮小（アタックサーフェースの縮小） – システムの複雑さを解消することで、攻撃しにくくする ■ 影響範囲の制限 – 小さなコンポーネントに分割して、最悪の事態発生時の影響を限定的にする ■ 職務分掌 – 異なるコンポーネントに対して、可能な限り最小限の権限のみを与える

Slide 21

Slide 21 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 21 セキュリティの原則出典：コンテナセキュリティ P.32-33 ■ 最小権限 – 処理を実行するのに最小の権限に制限する ■ 多層防御 – 攻撃者がある防御を突破できても別のレイヤー防ぐ ■ 攻撃対象領域の縮小（アタックサーフェースの縮小） – システムの複雑さを解消することで、攻撃しにくくする ■ 影響範囲の制限 – 小さなコンポーネントに分割して、最悪の事態発生時の影響を限定的にする ■ 職務分掌 – 異なるコンポーネントに対して、可能な限り最小限の権限のみを与えるここを深堀りします

Slide 22

Slide 22 text

Slide 23

Slide 23 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 23 クラウド環境でのレイヤー別のセキュリティレイヤーテスト内容手法ツールアプリケーションコードの脆弱性 SAST Snyk Code OSSライブラリの脆弱性 SCA Snyk OSS, Trivy, dependabot Base Image OSSライブラリの脆弱性 SCA Snyk Container, Trivy, Aqua Dockerfile 機密情報、特権等 Snyk Container, Dockle, Trivy, Aqua オーケストレーターミスコンフィグ CWPP Snyk Cloud, Aqua ランタイムセキュリティ DAST Falco, Sysdig, GuardDuty ホストOS ハードニング、OS脆弱性 CWPP Inspector, Security Hub クラウド環境ミスコンフィグ CSPM Security Hub 出典： https://owasp.org/www-community/Source_Code_Analysis_Tools

Slide 24

Slide 24 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 24 クラウド環境でのレイヤー別のセキュリティレイヤーテスト内容手法ツールアプリケーションコードの脆弱性 SAST Snyk Code OSSライブラリの脆弱性 SCA Snyk OSS, Trivy, dependabot Base Image OSSライブラリの脆弱性 SCA Snyk Container, Trivy Dockerfile 機密情報、特権等 Snyk Container, Dockle, Trivy, Aqua オーケストレーターミスコンフィグ CWPP Snyk Cloud, Aqua ランタイムセキュリティ DAST Falco, Sysdig, GuardDuty ホストOS ハードニング、OS脆弱性 CWPP Inspector, Security Hub クラウド環境ミスコンフィグ CSPM Security Hub 全てのレイヤでなんらかのリスク軽減対策が必要（多層防御）

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

（C） Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 32 デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub 定期的自動的にスキャン（コード、OSS、ライセンス、Dockerfile）

Slide 33

Slide 33 text

（C） Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 33 デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS マニュフェストをスキャン使用Imageをスキャン

Slide 34

Slide 34 text

（C） Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 34 デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS EC2 Fargate ワークロード保護ランタイム保護ミスコンフィグの検知、修正

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 39 Security系利用サービスの移り変わりフェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector GuardDuty Security Hub Inspector できるだけAWSに寄せる感じで選定とりあえずスキャンしてみた感じ CIS Benchmark準拠 Security Hubに送れる

Slide 40

Slide 40 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 40 Security系利用サービスの移り変わりフェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector Inspector GuardDuty Security Hub reviewdog＋OSSでのスキャンを試したが、 Snykの標準機能のPR チェックで充足できた WebUIで全社統一ルールを作れる

Slide 41

Slide 41 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 41 Security系利用サービスの移り変わりフェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector GuardDuty Security Hub Security Lake Tagでの絞り込みができないので Snykを採用 VSCode拡張強力なサジェスト機能 PRチェック Security Hubのダッシュボードが使いにくいので Security Lake+QuickSight で自作 InspectorのダッシュボードでトリアージができなかったのでSnykを採用 Snykのダッシュボードがいい感じだったのでクラウドセキュリティも Snykにしようかと検討したが、コスト面で断念

Slide 42

Slide 42 text

（C） Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 42 デプロイパイプラインで実施しているセキュリティオーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS EC2 Fargate 開発中の Scanと修正 PRチェック定期スキャン差分をスキャン定期スキャンミスコンフィグのチェックマニュフェストスキャン、 Image Scan

Slide 43

Slide 43 text

Slide 44

Slide 44 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 44 Shift-leftしてもright側のスキャンと対応も必要 ■ 対象 – 現在動いている本番環境 ■ 目的 – 本番環境でのセキュリティリスク確認ホスト・基盤オーケストレーターレジストリ CI/CD 開発 ■ 対象 – 本番環境にデプロイするアプリ・環境 ■ 目的 – 本番環境に脆弱性があるアプリ・環境がデプロイされないようにする Shift-Left 現実世界これから起きる未来

Slide 45

Slide 45 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 45 Shift-leftしてもright側のスキャンと対応も必要 ■ 対象 – 現在動いている本番環境 ■ 目的 – 本番環境でのセキュリティリスク確認ホスト・基盤オーケストレーターレジストリ CI/CD 開発 ■ 対象 – 本番環境にデプロイするアプリ・環境 ■ 目的 – 本番環境に脆弱性があるアプリ・環境がデプロイされないようにする Shift-Left 現実世界これから起きる未来目的も対象も異なるので両方必要！

Slide 46

Slide 46 text

Slide 47

Slide 47 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 47 本番環境とソースリポジトリで指摘が違う ■ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ■ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – （ここまで本番環境の脆弱性は検知されたままの状態） – 本番環境にデプロイ – （ここまでくると本番環境の脆弱性は検知されなくなる）

Slide 48

Slide 48 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 48 本番環境とソースリポジトリで指摘が違う ■ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ■ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – （ここまで本番環境の脆弱性は検知されたままの状態） – 本番環境にデプロイ – （ここまでくると本番環境の脆弱性は検知されなくなる） ■ つまり本番環境にデプロイされるまでは以下の状況が発生する – ソースリポジトリ上のスキャン結果は脆弱性なし – 本番環境のスキャン結果には脆弱性あり

Slide 49

Slide 49 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 49 本番環境とソースリポジトリで指摘が違う ■ ソースリポジトリで脆弱性を修正しても、本番環境の脆弱性は指摘される ■ どういうことかというと – 本番環境で脆弱性が検知される – ソースコードを修正してコミット・マージ – 開発環境・ステージング環境にデプロイして確認 – （ここまで本番環境の脆弱性は検知されたままの状態） – 本番環境にデプロイ – （ここまでくると本番環境の脆弱性は検知なくなる） ■ つまり本番環境にデプロイされるまでは以下の状況が発生する – ソースリポジトリ上のスキャン結果は脆弱性なし – 本番環境のスキャン結果には脆弱性あり ■ 対応としては、リスク評価は本番環境スキャンで、修正確認はソースコードスキャンで行うように使い分ける

Slide 50

Slide 50 text

Slide 51

Slide 51 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 51 トリアージが手間 ■ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間がかかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていないから対応しなくてヨシ！ – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応しなくてヨシ！ ■ 対応の考え方としては – やらない理由をこねくり回すよりは、脆弱性指摘があれば対応する方が前向きで健康的 ● 重要なのは、Base Image、ライブラリをシュッと差し替えられるCI/CDを整備したり、テストを回せる開発体制を作ること

Slide 52

Slide 52 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 52 トリアージが手間 ■ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間がかかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていないから対応しなくてヨシ！ – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応しなくてヨシ！ ■ 対応の考え方としては – やらない理由をこねくり回すよりは、脆弱性指摘があれば対応する方が前向きで健康的 ● 重要なのは、Base Image、ライブラリをシュッと差し替えられるCI/CDを整備したり、テストを回せる開発体制を作ること ■ CI/CD、テスト周りは開発生産性の文脈でも大事になってくるので、普段からの足回り整備がセキュリティ対応にも効いてきます

Slide 53

Slide 53 text

Slide 54

Slide 54 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 54 脆弱性を修正してもゼロにならない ■ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロになりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ■ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さなくても達成可能 ● 軽減策がとれる場合は積極的にとりましょう

Slide 55

Slide 55 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 55 脆弱性を修正してもゼロにならない ■ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロになりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ■ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さなくても達成可能 ● 軽減策がとれる場合は積極的にとりましょう ■ 具体的には、以下のような対応を段階的に行う – BaseImageを更新する ● マイナーバージョンアップだと影響が少ない – Critical（＋攻撃コードあり）の脆弱性だけ対応する

Slide 56

Slide 56 text

Slide 57

Slide 57 text

（C） Gunosy Inc. All Rights Reserved. PAGE | 57 まとめ ■ セキュリティ対策はリスク管理 – リスク管理は本番環境のスキャンから始めましょう ■ セキュリティ対応に銀の弾丸はありません – セキュリティ対応の目的は受容可能な範囲にリスクを抑えること ● ゼロは目指さない – 脆弱性を減らすには結局はマンパワーと事前調整が必要です ■ コンテナセキュリティはコンテナだけのセキュリティ対応で終わらないですし終わらせないことが大事 – ツールをうまく利用しましょう – ツールに踊らされないのも大事 ● Shift-leftは大事だけどright側が不要になるわけではない ■ 前向きで健康的なセキュリティ対応をしましょう – 普段からのCI/CD、テスト周りの整備が効いてきます