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

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

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 3 終了後に狙う状態
論理面 - コンテナセキュリティの概要が理解できる - Gunosyでのセキュリティツール選択の観点が理解できる - セキュリティ対策を現場に適用して、理想的な運用状態になるまでに発生する・した課題が理解できる感情面 - セキュリティ対策に興味を持ってやってみようと思える

（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号

（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、企業理念「情報を世界中の人に最適に届ける」

（C） Gunosy Inc. All Rights Reserved. PAGE | 8 アジェンダ
話すこと • コンテナセキュリティの概要 • デプロイフローへの組み込み • まとめ

（C） Gunosy Inc. All Rights Reserved. PAGE | 12 AWSの責任共有モデル（ECS
on EC2）

（C） Gunosy Inc. All Rights Reserved. PAGE | 13 AWSの責任共有モデル（ECS
on Fargate）

（C） Gunosy Inc. All Rights Reserved. PAGE | 15 実際にコンテナセキュリティに求められる領域
コンテナより低レイヤでセキュリティが適切に担保されていることの方が大事だったりします

（C） Gunosy Inc. All Rights Reserved. PAGE | 17 コンテナへの攻撃経路
出典：コンテナセキュリティ P.23

（C） Gunosy Inc. All Rights Reserved. PAGE | 18 コンテナへの攻撃経路
出典：コンテナセキュリティ P.23-25 ▪ 脆弱なアプリケーション ▪ コンテナイメージの設定不備 ▪ ビルドマシン攻撃 ▪ サプライチェーン攻撃 ▪ コンテナの設定不備 ▪ 脆弱なホスト ▪ 公開されたシークレット ▪ 安全でないネットワーキング ▪ コンテナエスケープの脆弱性

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

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

（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

（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 全てのレイヤでなんらかのリスク軽減対策が必要（多層防御）

（C） Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 26
Gunosyのデプロイパイプラインの一例オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS EC2 Fargate

デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者開発者の手元でスキャン（コード、OSS、ライセンス、Dockerfile、マニュフェスト）

デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ PR作成時に差分スキャン（コード、OSS、ライセンス、Dockerfile）定期的自動的にスキャン（コード、OSS、ライセンス、Dockerfile）

デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions Argo CD ビルドした成果物をスキャン（コード、OSS、ライセンス、Dockerfile、マニュフェスト）

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

デプロイパイプラインでのセキュリティ対応オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS マニュフェストをスキャン使用Imageをスキャン

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 37 Security系利用サービスの移り変わり
フェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入

フェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入この時は何も使用していません

フェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector GuardDuty Security Hub Inspector できるだけAWSに寄せる感じで選定とりあえずスキャンしてみた感じ CIS Benchmark準拠 Security Hubに送れる

フェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector Inspector GuardDuty Security Hub reviewdog＋OSSでのスキャンを試したが、 Snykの標準機能のPR チェックで充足できた WebUIで全社統一ルールを作れる

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

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

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

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

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

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

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

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

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

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

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

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

情報を世界中の人に最適に届ける

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

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

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript

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

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