Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題
Search
Takashi Yamaguchi
December 14, 2023
Technology
0
5.3k
クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題
セキュリティ対応を始めた背景とクラウドセキュリティの技術選択
セキュリティ対応していく中で出て来た課題と解決方法
こんな感じで導入すればいいのではというふりかえり
最後にまとめ
Takashi Yamaguchi
December 14, 2023
Tweet
Share
More Decks by Takashi Yamaguchi
See All by Takashi Yamaguchi
CodeCatalyst in Action: Automating PR Creation for Route 53 and IAM Identity Center Management
yamaguchitk333
0
16
DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策 / Considering Sustainable Security Measures in DevSecOps: Left Loop and Right Loop Perspectives
yamaguchitk333
1
1.3k
DevSecOpsの内回りと外回りで考える持続可能なセキュリティ対策 | Sustainable security measures for DevSecOps inside and outside the DevSecOps system.
yamaguchitk333
4
2.2k
コスト削減のハードスキルとソフトスキル / Hard and Soft skills for cost reduction
yamaguchitk333
0
73
クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た課題
yamaguchitk333
0
130
コンテナセキュリティの概要と デプロイフローに組み込んだ後の課題
yamaguchitk333
1
1k
JAWS-UG SRE支部 #7 Security Hubは俺の姑
yamaguchitk333
0
580
JAWS-UG コンテナ支部 × JAWS-UG 千葉支部 #1 コンテナセキュリティ対応でSnykを導入中に 発生した・発生中のいろんなこと
yamaguchitk333
0
1.1k
JAWS-UG千葉 #20 AWS Security Lakeを試してみたら 最高の運用者体験だった
yamaguchitk333
2
3.8k
Other Decks in Technology
See All in Technology
セキュリティ監視の内製化 効率とリスク
mixi_engineers
PRO
4
640
contenteditableと向き合う
kikuchikakeru
2
140
技術力あげたい
hisaichi5518
2
2.8k
Javaにおける関数型プログラミンへの取り組み
skrb
5
110
開発者体験を意識した開発チームの生産性向上の取り組み
ham0215
3
650
Namespace, Now and Then
tagomoris
0
170
New Relicで実践する外形監視
aeonpeople
1
120
GraphQLとスキーマファーストで切り開く ライドシェアの未来
ku0522a
0
490
Binary Authorizationと友達になろう / Let's be friends with Binary Authorization
iselegant
2
130
2024年版 運用者たちのLLM
nwiizo
3
290
エンジニアリングマネージャーが紐解く、事業視点から組織文化まで、包括的アプローチの探求 / READYFOR
9ma3r
13
2.2k
AWSを始めた頃に陥りがちなポイントをまとめてみた
oshanqq
1
1.7k
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
22
1.7k
Build your cross-platform service in a week with App Engine
jlugia
228
18k
The Mythical Team-Month
searls
218
43k
A Modern Web Designer's Workflow
chriscoyier
690
190k
Building an army of robots
kneath
302
42k
Teambox: Starting and Learning
jrom
131
8.7k
Designing for Performance
lara
604
68k
How GitHub Uses GitHub to Build GitHub
holman
472
290k
Building Applications with DynamoDB
mza
89
5.9k
Side Projects
sachag
451
42k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
Designing the Hi-DPI Web
ddemaree
278
34k
Transcript
株式会社 Gunosy テクノロジー本部 プロダクト開発部 SREチーム マネージャー 山口 隆史 <YAMAGUCHI Takashi>
2023年12月14日(水) クラウドセキュリティの技術選択と、セキュリティ対応してい く中で出て来た課題
(C) Gunosy Inc. All Rights Reserved. PAGE | 2 エレベーターピッチ
[セキュリティに興味がある人]、 [セキュリティをこれから始めたい人]向けに発表する [クラウドセキュリティの技術選択と、セキュリティ対応していく中で出て来た 課題]は [現場の泥臭い話]です これは[大きくない開発組織でのセキュリティ対応の現場での実践に基づい て構成しているため、現実感]があり これまでの成功事例やベンダーのセールス資料とは違って [ツールの限界と、ツールを導入してから定常運用に至るまでの活動に焦 点をあてている]
(C) Gunosy Inc. All Rights Reserved. PAGE | 3 終了後に狙う状態
論理面 - セキュリティ対策を現場に適用して、理想的な運用状態になるまでに発生 する・した課題が理解できる - セキュリティツールを導入したら解決できる問題、解決できない問題が理解 できる 感情面 - セキュリティ対策に興味を持ってやってみようと思える
(C) Gunosy Inc. All Rights Reserved. 本題に入る前に自己紹介
(C) Gunosy Inc. All Rights Reserved. PAGE | 5 自己紹介
氏名:山口隆史(やまぐちたかし) 所属:株式会社Gunosy テクノロジー本部 プロダクト開発部 SREチーム マネージャー 業務:Pure SREとしての活動 略歴:フリーランス、SIer等を渡り歩く→現職(2022/01〜) 自称:Security Hub芸人 好きなAWSサービス:Security Hub、GuardDuty、サポート 他:AWS Community Builder(Security & Identity)、JAWS-UG千葉支部運営 第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、YOU IN 企業理念「情報を世界中の人に最適に届ける」
(C) Gunosy Inc. All Rights Reserved. ここから本題
(C) Gunosy Inc. All Rights Reserved. PAGE | 8 アジェンダ
話すこと • Gunosyがセキュリティ対応を始めた背景 • クラウドセキュリティ対応で求められる内容とは • セキュリティツールの技術選定 — Snykのダッシュボードのいい感じなところをご紹介 • どんな感じで導入していったか • セキュリティ対応で出てきた課題と脆弱性への向き合い方 • こうやればうまく導入できそう • 今後の展望 • まとめ
(C) Gunosy Inc. All Rights Reserved. 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. みなさんWebP問題の時はどうでしたか?
(C) Gunosy Inc. All Rights Reserved. PAGE | 13 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. Gunosyの開発体制
(C) Gunosy Inc. All Rights Reserved. PAGE | 15 Gunosyの組織体制
グノシー ニュースパス au サービス Today 広告配信 グノシー 開発チーム 機械学習チーム ニュースパス 開発チーム au サービス Today 開発チーム 広告配信 開発チーム SREチーム
(C) Gunosy Inc. All Rights Reserved. PAGE | 16 Gunosyの組織体制
グノシー ニュースパス au サービス Today 広告配信 グノシー 開発チーム 機械学習チーム ニュースパス 開発チーム au サービス Today 開発チーム 広告配信 開発チーム SREチーム それぞれ 6名前後 10名規模 2名
(C) Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 17
Gunosyでの開発チームとSREとの責任分担 アプリ開発 アプリ運用 オンコール対応 セキュリティ・脆弱性対応 CI/CD運用 障害対応(ポストモーテム) 自動化・標準化 全社的なガードレール運用 SLOふりかえりの実施 開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化 ができている状態 SRE 「開発チームが 新たなプロ ダクト価値の創造 に集中 できる状態を作る」がミッ ション セキュリティ環境整備 セキュリティ・脆弱性のトリアージ モニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理
(C) Gunosy Inc. All Rights Reserved. PAGE | インフラ運用 18
Gunosyでの開発チームとSREとの責任分担 アプリ開発 アプリ運用 オンコール対応 セキュリティ・脆弱性対応 CI/CD運用 障害対応(ポストモーテム) 自動化・標準化 全社的なガードレール運用 SLOふりかえりの実施 開発チーム CI/CD、監視、EKS/ECS 等を含むインフラの民主化 ができている状態 SRE 「開発チームが 新たなプロ ダクト価値の創造 に集中 できる状態を作る」がミッ ション セキュリティ環境整備 セキュリティ・脆弱性のトリアージ モニタリング設定 ECS・EKS運用 EKS VersionUP コスト管理
(C) Gunosy Inc. All Rights Reserved. PAGE | 19 Gunosyでの開発チームとSREとの責任分担
チーム 責任範囲 開発チーム • セキュリティ・脆弱性への対応 SREチーム • セキュリティ環境整備 • セキュリティ・脆弱性のトリアージ (と対応依頼(チケット起票))
(C) Gunosy Inc. All Rights Reserved. クラウドセキュリティ対策で求められる内容とは
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 21
Gunosyのデプロイパイプラインの一例 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate
(C) Gunosy Inc. All Rights Reserved. パイプラインのどこでセキュリティ対策を 実施する必要があるか?
(C) Gunosy Inc. All Rights Reserved. パイプラインの全ての段階で 対策が必要です!
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 24
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 開発者の手元でスキャ ン (コード、OSS、ライセ ンス、Dockerfile、マ ニュフェスト)
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 25
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ PR作成時に差分スキャ ン (コード、OSS、ライセン ス、Dockerfile) 定期的自動的にスキャ ン (コード、OSS、ライセン ス、Dockerfile)
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 26
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions Argo CD ビルドした成果物をス キャン (コード、OSS、ライセン ス、Dockerfile、マニュ フェスト)
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 27
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub 定期的自動的にスキャ ン (コード、OSS、ライセン ス、Dockerfile)
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 28
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS マニュフェストを スキャン 使用Imageをス キャン
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 29
コンテナセキュリティ対策で求められる内容 オーケスト レーター レジストリ CI/CD 開発 開発者 Gitリポジトリ CircleCI GitHub Actions ECR (Private Registry) Argo CD Docker Hub EKS ECS EC2 Fargate ワークロード保護 ランタイム保護 ミスコンフィグの検知、 修正
(C) Gunosy Inc. All Rights Reserved. ツールを導入して自動化しないと 定常的な運用は無理!
(C) Gunosy Inc. All Rights Reserved. セキュリティツールの技術選定
(C) Gunosy Inc. All Rights Reserved. PAGE | 32 Security系利用サービスの移り変わり
フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入
(C) Gunosy Inc. All Rights Reserved. PAGE | 33 Security系利用サービスの移り変わり
フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 この時は何も使 用していません
(C) Gunosy Inc. All Rights Reserved. PAGE | 34 Security系利用サービスの移り変わり
フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector GuardDuty Security Hub Inspector できるだけAWSに 寄せる感じで選定 とりあえずスキャン してみた感じ CIS Benchmark準拠 Security Hubに送れる
(C) Gunosy Inc. All Rights Reserved. PAGE | 35 Security系利用サービスの移り変わり
フェーズ 開発 CI/CD コンテナレジスト リ オーケストレー ター ホスト・基盤 Security対応開 始前 本番環境への 導入完了 IaCスキャン 導入 Codeスキャン導 入 Inspector Inspector GuardDuty Security Hub reviewdog+OSSでの スキャンを試したが、 Snykの標準機能のPR チェックで充足できた WebUIで全社統一 ルールを作れる
(C) Gunosy Inc. All Rights Reserved. PAGE | 36 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にしようかと検討したが、コス ト面で断念
(C) Gunosy Inc. All Rights Reserved. PAGE | 37 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にしようかと検討したが、コス ト面で断念 ダッシュボード大事です!
(C) Gunosy Inc. All Rights Reserved. PAGE | 38 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. Snykのダッシュボードのいい感じな ところをご紹介
(C) Gunosy Inc. All Rights Reserved. PAGE | 40 脆弱性の一覧表示
▪ ダッシュボードで脆弱性の一覧表示が できる – Severity毎の件数 • リポジトリ単位 • パッケージマネージャ単位 – CVE単位での検索
(C) Gunosy Inc. All Rights Reserved. PAGE | 41 Snykの修正方法サジェスト
▪ 脆弱性の修正方法のSuggest – Base Imageを更新したらどれくら い脆弱性が減るか – 脆弱性の修正方法 イチオシ機能
(C) Gunosy Inc. All Rights Reserved. PAGE | 42 修正PR
▪ 脆弱性の修正PRが出せる – 手動でPRが出せる – AutoFixでPRも出せる
(C) Gunosy Inc. All Rights Reserved. ここまで7分が目安
(C) Gunosy Inc. All Rights Reserved. ここから導入フェーズ以降の話
(C) Gunosy Inc. All Rights Reserved. どんな感じで導入していったか
(C) Gunosy Inc. All Rights Reserved. PAGE | 46 セキュリティ対策ツール導入の流れ
▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月
(C) Gunosy Inc. All Rights Reserved. PAGE | 47 セキュリティ対策ツール導入の流れ
▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月 PoCから運用までを、それぞれの導入フェーズで繰り返していく 本番環境への導入 IaCの導入 Codeスキャンの導入
(C) Gunosy Inc. All Rights Reserved. PAGE | 48 セキュリティ対策ツール導入の流れ
▪ ツールの調査 – 対応できる範 囲・制限 – 料金体系 – 見積もり交渉 ▪ 社内調整 – 導入範囲 – ツールと対策 の必要性を幹 部に理解しても らう ▪ 1チームに導入して PoC – トレーニング – 検証 – 課題の確認 ▪ 対応優先度のルー ルを決める – 全リポジトリの 優先度を決め る ▪ 全チーム・リポジトリ に展開 – 優先順位に従っ て脆弱性を対応 していく ▪ 並行してトリアージ の省力化に取り組む ▪ (通知+)定期棚卸 し運用に切り替え 運用 導入・初期対応 3ヶ月〜10ヶ月 PoC 1ヶ月 事前調査と社内調整 1ヶ月 有償ツールを使用している場合、 コスト削減を求められるタイミングで ツールを削ることを求められるので、 役員レベルに念押ししておくことが大事!
(C) Gunosy Inc. All Rights Reserved. セキュリティ対応で出てきた課題 と 脆弱性への向き合い方
(C) Gunosy Inc. All Rights Reserved. 導入フェーズ
(C) Gunosy Inc. All Rights Reserved. PAGE | 51 初期導入時の大量の脆弱性への対応
▪ 初期導入時に脆弱性が大量に検出される
(C) Gunosy Inc. All Rights Reserved. PAGE | 52 初期導入時の大量の脆弱性への対応
▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していくしかない • internet-facing / internal(攻撃面) • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響 引用 米カーネギーメロン大学ソフトウェア工学研究所公開のオリジナル論文より https://resources.sei.cmu.edu/asset_files/WhitePaper/2021_019_001_653461.pdf
(C) Gunosy Inc. All Rights Reserved. PAGE | 53 初期導入時の大量の脆弱性への対応
▪ 初期導入時に脆弱性が大量に検出される – 優先順位を付けて順次対応していく必要がある (これは初期導入後の運用時も必要) • internet-facing / internal • 攻撃コードの公開有無 • 脆弱性の重大度 • 攻撃された際の業務影響 ▪ なぜ必要なのか? – 全部対応してくださいだと拒絶が先に来てしまう • 優先順位をつけて対応していくことで、開発チーム側の理 解を得やすい
(C) Gunosy Inc. All Rights Reserved. PAGE | 54 脆弱性へ優先順位付けはどうやるか(クラウド)
▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要
(C) Gunosy Inc. All Rights Reserved. PAGE | 55 脆弱性へ優先順位付けはどうやるか(クラウド)
▪ クラウドセキュリティの場合は、基本的にCritical、High指摘は対応が必要 ▪ しかし指摘全てを対応する必要はない – 自社の運用に合わない指摘もあるので、指摘の内容とそのリスクを理解し た上で対応しない判断(リスクを軽減した上での受容)も必要になる – この辺りの判断がつかないときは利用しているクラウドベンダーのセキュリ ティに詳しいパートナー等への相談が良さそう
(C) Gunosy Inc. All Rights Reserved. PAGE | 56 脆弱性へ優先順位付けはどうやるか(コンテナ)
▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すご い便利)
(C) Gunosy Inc. All Rights Reserved. PAGE | 57 脆弱性へ優先順位付けはどうやるか(コンテナ)
▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すごい 便利) ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者 へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響
(C) Gunosy Inc. All Rights Reserved. PAGE | 58 脆弱性へ優先順位付けはどうやるか(コンテナ)
▪ Scan対象のGitHubリポジトリ・ECRにタグをつけて管理することはできる ▪ 攻撃コードの公開有無、脆弱性の重大度もダッシュボードで確認できる(すごい 便利) ▪ しかし – リポジトリ・Imageが以下のどれに該当するかはアーキテクチャ図、関係者 へのヒアリング等であらかじめ把握しておく必要がある • Internet-facing / Intenal • 攻撃された際の業務影響 ▪ 上記の情報を一覧表で整理した上で、Snyk WebUIかREST APIでタグをつけて いく
(C) Gunosy Inc. All Rights Reserved. PAGE | 59 脆弱性への対応の追跡がつらい(コンテナ)
▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票 する – Snykの機能でサポートされているのは脆弱性単位のJIRAチケット起票
(C) Gunosy Inc. All Rights Reserved. PAGE | 60 脆弱性への対応の追跡がつらい(コンテナ)
▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチケットを起票 する – Snykの機能でサポートされているのは脆弱性単位のJIRAチケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと大量にJIRAチ ケットが発生する • 開発チームの拒絶反応に直結してしまう
(C) Gunosy Inc. All Rights Reserved. PAGE | 61 脆弱性への対応の追跡がつらい(コンテナ)
▪ 導入後の脆弱性消し込み段階ではリポジトリ・Image単位でJIRAチ ケットを起票する – Snykの機能でサポートされているのは脆弱性単位のJIRAチ ケット起票 ▪ Why – 特に初期導入時の脆弱性消し込み段階だと、脆弱性単位だと 大量にJIRAチケットが発生する – 開発チームの拒絶反応に直結してしまう ▪ 脆弱性が消し込み終わった段階で、脆弱性単位のJIRAチケット起 票に切り替える (まだできてません)
(C) Gunosy Inc. All Rights Reserved. 運用フェーズ
(C) Gunosy Inc. All Rights Reserved. PAGE | 63 脆弱性検知時に通知するとうるさい(クラウド)
▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る
(C) Gunosy Inc. All Rights Reserved. PAGE | 64 脆弱性検知時に通知するとうるさい(クラウド)
▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない
(C) Gunosy Inc. All Rights Reserved. PAGE | 65 脆弱性検知時に通知するとうるさい(クラウド)
▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeの ダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認 これくらいのゆるい運用をしています
(C) Gunosy Inc. All Rights Reserved. PAGE | 66 脆弱性検知時に通知するとうるさい(クラウド)
▪ Security Hubは毎日同じ脆弱性を検知するので、制御しないと(ステータスで制 御可能)毎日通知が来る ▪ というかそもそも通知は不要 – 通知運用するよりもIaCの段階でのチェックを入れて新しい脆弱性が発生し にくい状況を構築したほうがいい – 加えて対応までの追跡が必要なので通知だけで運用が終わらない ▪ Gunosyの場合は、CIでのIaCチェック運用をした上で週次でSecurity Lakeの ダッシュボードを確認 – 新しい脆弱性があればリソースを確認 – 既知の脆弱性で対応されていないものはSLOふりかえりで確認 これくらいのゆるい運用をしています ▪ GuardDutyは通知運用が必要で、通知された場合は即時調査・対応が基本で す!
(C) Gunosy Inc. All Rights Reserved. PAGE | 67 トリアージが手間(コンテナ)
▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを 判断 Critical+攻撃コードあ り それ以外 Internet-f acing できるだけ早く対応 四半期を目処に対 応 それ以外 1ヶ月以内を目処に 対応 任意のタイミング で対応
(C) Gunosy Inc. All Rights Reserved. PAGE | 68 トリアージが手間(コンテナ)
▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判 断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった
(C) Gunosy Inc. All Rights Reserved. PAGE | 69 トリアージが手間(コンテナ)
▪ 当初は、Internet-facingかどうか、Severity(Critical、Highを対象)、攻撃コード の有無で対応の緊急度を判断 – 加えてFixされたライブラリがリリースされているかで、対応依頼するかを判 断 ▪ トリアージはSREの責務 – SREは2名 – Highレベルまで追跡すると数が多すぎてトリアージが回らなくなった ▪ トリアージ対象をCritical(+攻撃コードあり)に絞り込んだ – セキュリティリスクとトリアージ工数を検討して決断
(C) Gunosy Inc. All Rights Reserved. PAGE | 70 脆弱性を修正してもゼロにならない(コンテナ)
▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性
(C) Gunosy Inc. All Rights Reserved. PAGE | 71 脆弱性を修正してもゼロにならない(コンテナ)
▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ▪ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さな くても達成可能 • 軽減策がとれる場合は積極的にとりましょう
(C) Gunosy Inc. All Rights Reserved. PAGE | 72 脆弱性を修正してもゼロにならない(コンテナ)
▪ 脆弱性を修正しても新しい脆弱性が公表されると検知される脆弱性は永遠にゼロ になりません – BaseImage更新、ライブラリ更新したら更新後に違う脆弱性が混入 – Fixがなかったり、孫依存ライブラリの脆弱性 ▪ 向き合い方としては、デプロイ完了時点で検出がゼロになることを目指さない – 受容可能な範囲までリスクを軽減するのが目的なので、検出ゼロを目指さな くても達成可能 • 軽減策がとれる場合は積極的にとりましょう ▪ 具体的には、以下のような対応を段階的に行う – BaseImageを更新する • マイナーバージョンアップだと影響が少ない – Critical(+攻撃コードあり)の脆弱性だけ対応する
(C) Gunosy Inc. All Rights Reserved. ここまで15分が目安
(C) Gunosy Inc. All Rights Reserved. こうやればうまく導入できそう
(C) Gunosy Inc. All Rights Reserved. PAGE | 75 導入フェーズ
▪ 継続的にコスト(セキュリティツール、対応コスト)が発生することの承認とセキュリ ティ対策の必要性の理解を幹部レベルで得ておく – リスク軽減のメリット訴求も忘れない – なにかの拍子に別の幹部からコスト削減要請がきます ▪ 想像以上に大量の脆弱性指摘が発生するので、開発チームと合意しておく ▪ 導入当初から開発チームを巻き込む – セキュリティチャンピオン制度は有効 ▪ 脆弱性対応は最初からがんばりすぎない – 対応する脆弱性・対応しない脆弱性の振り分けから始める – リスクの高いものから対応する
(C) Gunosy Inc. All Rights Reserved. PAGE | 76 運用フェーズ
▪ GuardDutyの通知運用は必須 – 他はお好みで大丈夫 • 通知をチケット化する運用まで持っていければ有用 ▪ トリアージが必須なので、トリアージする対象の量、マンパワーに応じてトリアー ジ対象を絞る – トリアージがボトルネックになると運用が回らなくなる – 開発チームに委譲していくことを織り込んでいく • ex:セキュリティチャンピオン
(C) Gunosy Inc. All Rights Reserved. PAGE | 77 運用フェーズ
▪ 対応の優先順位付けと期日設定をする – 優先付けしないと拒否反応がでる – 期日を設定しないと結局対応されない Critical+攻撃コードあ り それ以外 Internet-f acing できるだけ早く対応 四半期を目処に対 応 それ以外 1ヶ月以内を目処に 対応 任意のタイミングで 対応
(C) Gunosy Inc. All Rights Reserved. PAGE | 78 運用フェーズ
▪ 普段の開発にセキュリティを織り込んでいく – ゆとりを作ってセキュリティと技術負債の解消をねらったり – 改善Day的にセキュリティ対応する日を決めて対応したり この辺はチームと開発プロセスによってやり方はいろいろありますが、 大事なのはセキュリティを後回しにしないこと!
(C) Gunosy Inc. All Rights Reserved. 今の運用
(C) Gunosy Inc. All Rights Reserved. PAGE | 80 定常的な運用フロー
[定期・自動] スキャン DBとの照合 ダッシュボードで 確認 or 通知で確認 トリアージ 脆弱性対応 無影響確認 ・テスト デプロイ 網羅的なス キャン 強力な修正 Suggest 一覧で確認しや すいダッシュ ボード Security Hub Security Lake GuardDuty
(C) Gunosy Inc. All Rights Reserved. PAGE | ホスト・基盤 81
デプロイパイプラインでのセキュリティ対応フロー オーケスト レーター レジストリ 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. 今後の展望
(C) Gunosy Inc. All Rights Reserved. PAGE | 83 トリアージとチケット起票の自動化
▪ モチベーション – トリアージルールは決まっていて、チケット起票ルールも決まっている – SREは2名なので手動だとスケールしないことは確定している – なので、自動化したい ▪ こんな仕組みでいけそう – Snykの検出結果がCSVでアウトプットできるので、それを解析してJIRAを起 票 – JIRAとリポジトリ・ECRの紐付けはDB管理 – StepFunction等で定期実行
(C) Gunosy Inc. All Rights Reserved. まとめ
(C) Gunosy Inc. All Rights Reserved. PAGE | 85 まとめ
▪ セキュリティ対応に銀の弾丸はない – セキュリティ対応の目的は受容可能な範囲にリスクを抑えること • ゼロは目指さない – 脆弱性を減らすには結局はマンパワーと事前調整が必要です ▪ セキュリティ対応ツールをうまく利用すれば高速道路に乗れます – リスクを可視化し、リスクを効率的に減らすことが可能 – 少ない人数でも運用はできる ▪ セキュリティを後回しにしない、プロセスに織り込む – 当たり前品質にセキュリティを加えましょう
情報を世界中の人に最適に届ける