クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

株式会社 Gunosy テクノロジー本部プロダクト開発部 SREチームマネージャー山口隆史 <YAMAGUCHI Takashi>
2024年2月21日(水) クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

（C） Gunosy Inc. All Rights Reserved. PAGE | 2 エレベーターピッチ
［セキュリティに興味がある人］、［セキュリティをこれから始めたい人］向けに発表する［クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題］は［現場の泥臭い話］ですこれは［大きくない開発組織でのセキュリティ対応の現場での実践に基づいて構成しているため、現実感］がありこれまでの成功事例やベンダーのセールス資料とは違って［ツールの限界と、ツールを導入してから定常運用に至るまでの活動に焦点をあてている］

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

（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 アジェンダ
話すこと • Gunosyがセキュリティ対応を始めた背景 • Gunosyの開発体制 • クラウドセキュリティ対応で求められる内容とは • セキュリティツールの技術選定 • どんな感じで導入していったか • セキュリティ対応で出てきた課題と脆弱性への向き合い方 • こうやればうまく導入できそう • 今後の展望 • まとめ

（C） Gunosy Inc. All Rights Reserved. PAGE | 10 セキュリティ対策に対する優先度が上がった
キッカケはLog4j問題での対応 - ヤバめの脆弱性情報は個人がTwitter等で拾ってくる体制だった - Log4jはこれで拾えたが取りこぼしがあると致命的 - 調査が人力総力戦だったので、もうやりたくない定期的・自動的にスキャンして継続的に潰していくサイクルにしたい - セキュリティの設計への組み込みはベストプラクティスに従って対応していたが、レビュワー、実装者の個人のスキル任せになっていた

（C） Gunosy Inc. All Rights Reserved. PAGE | 11 自動でスキャンして継続的に潰すサイクルを回したい
[定期･自動] スキャン DBとの照合トリアージ対応なんかやばいぞってなる急いで調査対応 As-Is To-Be

（C） Gunosy Inc. All Rights Reserved. PAGE | 14 WebP問題の時のGunosyの対応状況
▪ 9/28 20時 – SnykさんからWebPの0-Day攻撃の案内あり – blog記事を確認して、Gunosyでの影響範囲を軽く確認 ▪ 9/29 – 30分くらいでSnykダッシュボードでCVEを検索してスプシで対応リストを作成 – チーム別に担当を振り分けして全体アナウンス • 各チームでスプシから使用していないリポジトリをフィルタ ▪ 10/13 – 2週間くらいで主要な範囲について対応完了

（C） Gunosy Inc. All Rights Reserved. PAGE | 15 WebP問題の時のGunosyの対応状況
▪ 9/28 20時 – SnykさんからWebPの0-Day攻撃の案内あり – blog記事を確認して、Gunosyでの影響範囲を軽く確認 ▪ 9/29 – 30分くらいでSnykダッシュボードでCVEを検索してスプシで対応リストを作成 – チーム別に担当を振り分けして全体アナウンス • 各チームでスプシから使用していないリポジトリをフィルタ ▪ 10/13 – 2週間くらいで主要な範囲について対応完了ここがものすごく早くなりました

（C） Gunosy Inc. All Rights Reserved. PAGE | 17 Gunosyの組織体制
グノシーニュースパス au サービス Today 広告配信グノシー開発チーム機械学習チームニュースパス開発チーム au サービス Today 開発チーム広告配信開発チーム SREチームストリームアラインドコンプリケイテッドサブシステムイネイブリング

（C） Gunosy Inc. All Rights Reserved. PAGE | 18 Gunosyの組織体制
グノシーニュースパス au サービス Today 広告配信グノシー開発チーム機械学習チームニュースパス開発チーム au サービス Today 開発チーム広告配信開発チーム SREチームそれぞれ 5名前後 10名規模 2名

（C） Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 19
Gunosyでの開発チームとSREとの責任分担アプリ開発アプリ運用オンコール対応セキュリティ・脆弱性対応 CI/CD運用障害対応（ポストモーテム）自動化・標準化全社的なガードレール運用 SLOふりかえりの実施開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化ができている状態 SRE 「開発チームが新たなプロダクト価値の創造に集中できる状態を作る」がミッションセキュリティ環境整備セキュリティ・脆弱性のトリアージモニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理

（C） Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 20
Gunosyでの開発チームとSREとの責任分担アプリ開発アプリ運用オンコール対応セキュリティ・脆弱性対応 CI/CD運用障害対応（ポストモーテム）自動化・標準化全社的なガードレール運用 SLOふりかえりの実施開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化ができている状態 SRE 「開発チームが新たなプロダクト価値の創造に集中できる状態を作る」がミッションセキュリティ環境整備セキュリティ・脆弱性のトリアージモニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理

（C） Gunosy Inc. All Rights Reserved. PAGE | 21 Gunosyでの開発チームとSREとの責任分担
チーム責任範囲開発チーム • セキュリティ・脆弱性への対応 SREチーム • セキュリティ環境整備 • セキュリティ・脆弱性のトリアージ　（と対応依頼（チケット起票））

（C） Gunosy Inc. All Rights Reserved. PAGE | 22 Gunosyでの開発チームとSREとの責任分担
チーム責任範囲開発チーム • セキュリティ・脆弱性への対応 SREチーム • セキュリティ環境整備 • セキュリティ・脆弱性のトリアージ　（と対応依頼（チケット起票））お膳立てしてケツ叩く係

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

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 28 クラウド環境でのレイヤー別のセキュリティ
レイヤーテスト内容手法ツールアプリケーションコードの脆弱性 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 | 29 クラウド環境でのレイヤー別のセキュリティ
レイヤーテスト内容手法ツールアプリケーションコードの脆弱性 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 | ホスト・基盤 31
Gunosyのデプロイパイプラインの一例オーケストレーターレジストリ CI/CD 開発開発者 Gitリポジトリ CircleCI GitHub Actions ECR （Private Registry） Argo CD Docker Hub EKS ECS EC2 Fargate

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 | 42 Security系利用サービスの移り変わり
フェーズ開発 CI/CD コンテナレジストリオーケストレーターホスト・基盤 Security対応開始前本番環境への導入完了 IaCスキャン導入 Codeスキャン導入 Inspector GuardDuty Security Hub Inspector Inspector Inspector GuardDuty Security Hub Inspector GuardDuty Security Hub Security Lake

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 49 脆弱性の一覧表示
▪ ダッシュボードで脆弱性の一覧表示ができる – Severity毎の件数 • リポジトリ単位 • パッケージマネージャ単位 – CVE単位での検索

（C） Gunosy Inc. All Rights Reserved. PAGE | 50 Snykの修正方法サジェスト
▪ 脆弱性の修正方法のSuggest – Base Imageを更新したらどれくらい脆弱性が減るか – 脆弱性の修正方法イチオシ機能

（C） Gunosy Inc. All Rights Reserved. PAGE | 51 修正PR
▪ 脆弱性の修正PRが出せる – 手動でPRが出せる – AutoFixでPRも出せる

（C） Gunosy Inc. All Rights Reserved. PAGE | 52 PRチェック
▪ SnykにImportして一括設定するだけで自動PRチェックができる – requiredにするとSnykが止まったらMergeできなくなるので注意

（C） Gunosy Inc. All Rights Reserved. PAGE | 55 セキュリティ対策ツール導入の流れ
▪ ツールの調査 – 対応できる範囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策の必要性を幹部に理解してもらう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルールを決める – 全リポジトリの優先度を決める ▪ 全チーム・リポジトリに展開 – 優先順位に従って脆弱性を対応していく ▪ 並行してトリアージの省力化に取り組む ▪ （通知＋）定期棚卸し運用に切り替え運用導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月事前調査と社内調整 1ヶ月

（C） Gunosy Inc. All Rights Reserved. PAGE | 56 セキュリティ対策ツール導入の流れ
▪ ツールの調査 – 対応できる範囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策の必要性を幹部に理解してもらう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルールを決める – 全リポジトリの優先度を決める ▪ 全チーム・リポジトリに展開 – 優先順位に従って脆弱性を対応していく ▪ 並行してトリアージの省力化に取り組む ▪ （通知＋）定期棚卸し運用に切り替え運用導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月事前調査と社内調整 1ヶ月 PoCから運用までを、それぞれの導入フェーズで繰り返していく本番環境への導入 IaCの導入 Codeスキャンの導入

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 58 セキュリティ対策ツール導入の流れ　大事なこと！
▪ ツールの調査 – 対応できる範囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策の必要性を幹部に理解してもらう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルールを決める – 全リポジトリの優先度を決める ▪ 全チーム・リポジトリに展開 – 優先順位に従って脆弱性を対応していく ▪ 並行してトリアージの省力化に取り組む ▪ （通知＋）定期棚卸し運用に切り替え運用導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月事前調査と社内調整 1ヶ月有償ツールを使用している場合、コスト削減を求められるタイミングでツールを削ることを求められるので、役員レベルに念押ししておくことが大事！

（C） Gunosy Inc. All Rights Reserved. PAGE | 61 導入フェーズの課題
▪ 初期導入時の大量の脆弱性への対応 ▪ 脆弱性へ優先順位付けはどうやるか（クラウド） ▪ 脆弱性へ優先順位付けはどうやるか（コンテナ） ▪ 脆弱性への対応の追跡がつらい（コンテナ）

（C） Gunosy Inc. All Rights Reserved. PAGE | 62 初期導入時の大量の脆弱性への対応
▪ 初期導入時に脆弱性が大量に検出される

▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していくしかない • internet-facing / internal（攻撃面） • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響引用　米カーネギーメロン大学ソフトウェア工学研究所公開のオリジナル論文より https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf 

▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していく必要がある（これは初期導入後の運用時も必要） • internet-facing / internal • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響 ▪ なぜ必要なのか？ – 全部対応してくださいだと拒絶が先に来てしまう • 優先順位をつけて対応していくことで、開発チーム側の理解を得やすい – リスク✖業務影響で影響が大きいところから対応するのがコスパが良い

（C） Gunosy Inc. All Rights Reserved. PAGE | 65 脆弱性へ優先順位付けはどうやるか（クラウド）
▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要

（C） Gunosy Inc. All Rights Reserved. PAGE | 66 脆弱性へ優先順位付けはどうやるか（クラウド）
▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要 ▪ しかし指摘全てを対応する必要はない – 自社の運用に合わない指摘もあるので、指摘の内容とそのリスクを理解した上で対応しない判断（リスクを軽減した上での受容）も必要になる – この辺りの判断がつかないときは利用しているクラウドベンダーのセキュリティに詳しいパートナー等への相談が良さそう

（C） Gunosy Inc. All Rights Reserved. PAGE | 67 脆弱性へ優先順位付けはどうやるか（コンテナ）
▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる（すごい便利）

▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる（すごい便利） ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響

▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる（すごい便利） ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響 ▪ 上記の情報を一覧表で整理した上で、Snyk WebUIかREST APIでタグをつけていく

（C） Gunosy Inc. All Rights Reserved. PAGE | 70 脆弱性への対応の追跡がつらい（コンテナ）
▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票

▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと大量にJIRAチケットが発生する • 開発チームの拒絶反応に直結してしまう

▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票する – しかしSnykの機能でサポートされているのは脆弱性単位のJIRAチケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと大量にJIRAチケットが発生する – 開発チームの拒絶反応に直結してしまう ▪ 脆弱性が消し込み終わった段階で、脆弱性単位のJIRAチケット起票に切り替える（まだできてません）

（C） Gunosy Inc. All Rights Reserved. PAGE | 73 導入フェーズの課題（再掲）
▪ 初期導入時の大量の脆弱性への対応 ▪ 脆弱性へ優先順位付けはどうやるか（クラウド） ▪ 脆弱性へ優先順位付けはどうやるか（コンテナ） ▪ 脆弱性への対応の追跡がつらい（コンテナ）

（C） Gunosy Inc. All Rights Reserved. PAGE | 75 運用フェーズの課題
▪ 脆弱性検知時に通知するとうるさい（クラウド） ▪ トリアージが手間（コンテナ） ▪ トリアージが手間（コンテナ）その2 ▪ 脆弱性を修正してもゼロにならない（コンテナ） ▪ Shift-leftしてもright側のスキャンと対応も必要 ▪ 本番環境とソースリポジトリで指摘が違う

（C） Gunosy Inc. All Rights Reserved. PAGE | 76 脆弱性検知時に通知するとうるさい（クラウド）
▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと（ステータスで制御可能）毎日通知が来る

▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと（ステータスで制御可能）毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生しにくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない

▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと（ステータスで制御可能）毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生しにくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeのダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認これくらいのゆるい運用をしています

▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと（ステータスで制御可能）毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生しにくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeのダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認これくらいのゆるい運用をしています ▪ GuardDutyは通知運用が必要で、通知された場合は即時調査・対応が基本です！

（C） Gunosy Inc. All Rights Reserved. PAGE | 80 トリアージが手間（コンテナ）
▪ 当初は、Internet-facingかどうか、Severity（Critical、Highを対象）、攻撃コードの有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判断 Critical＋攻撃コードありそれ以外 Internet-f acing できるだけ早く対応四半期を目処に対応それ以外 1ヶ月以内を目処に対応任意のタイミングで対応

▪ 当初は、Internet-facingかどうか、Severity（Critical、Highを対象）、攻撃コードの有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった

▪ 当初は、Internet-facingかどうか、Severity（Critical、Highを対象）、攻撃コードの有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった ▪ トリアージ対象をCritical（＋攻撃コードあり）に絞り込んだ – セキュリティリスクとトリアージ工数を検討して決断

（C） Gunosy Inc. All Rights Reserved. PAGE | 83 トリアージが手間（コンテナ）その2
▪ 対応しない方向に倒す目的で、CVEの詳細まで確認してトリアージすると手間がかかりすぎる – このCVEは攻撃条件がXXXで、このライブラリをそういう使い方はしていないから対応しなくてヨシ！ – ライブラリの脆弱性指摘はあるけどアプリケーションで使ってないから対応しなくてヨシ！

▪ 対応しない方向に倒す目的で、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 | 89 Shift-leftしてもright側のスキャンと対応も必要
▪ 対象 – 現在動いている本番環境 ▪ 目的 – 本番環境でのセキュリティリスク確認ホスト・基盤オーケストレーターレジストリ CI/CD 開発 ▪ 対象 – 本番環境にデプロイするアプリ・環境 ▪ 目的 – 本番環境に脆弱性があるアプリ・環境がデプロイされないようにする Shift-Left 現実世界これから起きる未来

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

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

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

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

（C） Gunosy Inc. All Rights Reserved. PAGE | 95 運用フェーズの課題（再掲）
▪ 脆弱性検知時に通知するとうるさい（クラウド） ▪ トリアージが手間（コンテナ） ▪ トリアージが手間（コンテナ）その2 ▪ 脆弱性を修正してもゼロにならない（コンテナ） ▪ Shift-leftしてもright側のスキャンと対応も必要 ▪ 本番環境とソースリポジトリで指摘が違う

（C） Gunosy Inc. All Rights Reserved. PAGE | 97 導入フェーズ
▪ 継続的にコスト（セキュリティツール、対応コスト）が発生することの承認とセキュリティ対策の必要性の理解を幹部レベルで得ておく – リスク軽減のメリット訴求も忘れない – なにかの拍子に別の幹部からコスト削減要請がきます ▪ 想像以上に大量の脆弱性指摘が発生するので、開発チームと合意しておく ▪ 導入当初から開発チームを巻き込む – セキュリティチャンピオン制度は有効 ▪ 脆弱性対応は最初からがんばりすぎない – 対応する脆弱性・対応しない脆弱性の振り分けから始める – リスクの高いものから対応する

（C） Gunosy Inc. All Rights Reserved. PAGE | 98 運用フェーズ
▪ GuardDutyの通知運用は必須 – 他はお好みで大丈夫 • 通知をチケット化する運用まで持っていければ有用 ▪ トリアージが必須なので、トリアージする対象の量、マンパワーに応じてトリアージ対象を絞る – トリアージがボトルネックになると運用が回らなくなる – 開発チームに委譲していくことを織り込んでいく • ex：セキュリティチャンピオン

▪ 対応の優先順位付けと期日設定をする – 優先付けしないと拒否反応がでる – 期日を設定しないと結局対応されない Critical＋攻撃コードありそれ以外 Internet-f acing できるだけ早く対応四半期を目処に対応それ以外 1ヶ月以内を目処に対応任意のタイミングで対応

▪ 普段の開発にセキュリティを織り込んでいく – ゆとりを作ってセキュリティと技術負債の解消をねらったり – 改善Day的にセキュリティ対応する日を決めて対応したり – CI/CD、テスト周りの整備がセキュリティ対応にも効きますこの辺はチームと開発プロセスによってやり方はいろいろありますが、大事なのはセキュリティを後回しにしないこと！

デプロイパイプラインでのセキュリティ対応フローオーケストレーターレジストリ 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 | 105 トリアージとチケット起票の自動化
▪ モチベーション – トリアージルールは決まっていて、チケット起票ルールも決まっている – SREは2名なので手動だとスケールしないことは確定している – なので、自動化したい ▪ こんな仕組みでいけそう – Snykの検出結果がCSVでアウトプットできるので、それを解析してJIRAを起票 – GASでも実装できそう

（C） Gunosy Inc. All Rights Reserved. PAGE | 107 まとめ
▪ セキュリティ対応に銀の弾丸はありません – セキュリティ対応の目的は受容可能な範囲にリスクを抑えること • ゼロは目指さなくてよい – 脆弱性を減らすには結局はマンパワーと事前調整が必要です ▪ セキュリティ対応ツールをうまく利用すれば高速道路に乗れます – 少ない人数でも運用できます ▪ セキュリティを後回しにしない、プロセスに織り込む – 当たり前品質にセキュリティを加えましょう ▪ 前向きで健康的なセキュリティ対応をしましょう – 普段からのCI/CD、テスト周りの整備が効いてきます

https://jawsdays2024.jaws-ug.jp/ 告知：3/2（土） JAWS Days at 池袋サンシャイン

https://sre-next.dev/2024/ 告知：8/3〜4 （土〜日）SRE NEXT 2024 at Abema Towers

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

クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題

More Decks by Takashi Yamaguchi

Other Decks in Technology

Featured

Transcript