概要

SRE チームでは、去年からクラウドセキュリティとコンテナセキュリティの開発チームへの導入に取り組んできました。

その過程を AWS Summit Tokyo 2023 や JAWS-UG、SRE Lounge で発表してきました。現在の Gunosy のステータスは DevSecOps の導入が完了して、定常的な運用への道筋が見えてきた段階です。

導入過程をふりかえると、こんな感じで導入すると良かったかもというのが見えてきたので、今回はコンテナセキュリティの導入について共有します。

外部発表資料

全体的な導入の流れ

まず初めに本番環境の穴埋めから着手しましょう。ShiftLeft は大事ですが、効率的にリスク軽減することを考えると本番環境の穴埋めから着手することをお勧めします。コンテナセキュリティだけ導入しても本番環境が穴だらけだとリスクの軽減にはなりません。

下の図は Gunosy でセキュリティを導入したときの流れです。

それぞれのフェーズごとに、事前調整、PoC、導入・初期対応、運用を繰り返していきます。

特に有償ツールを利用するときは、費用が高額になりがちなこともあり念押しの確認が重要です。

コンテナセキュリティ対応ツールの選定

各ツールを試験的に導入し、少し運用してみてツールの評価を行いました。

以下のような星取表を作成して評価を行いました。

重要なのは脆弱性をスキャンする観点だけではなく、検知された脆弱性を継続的に潰していく運用が負担感なく回していけるか？という観点を入れることです。

そこで Gunosy では脆弱性を修正するための情報が得られるか？という観点と、修正すべき脆弱性が絞り込んで表示できるか？という観点を入れました。

結果として以下の項目を重視して Snyk の導入を決定しました。

トリアージする SRE 視点
- ダッシュボードがあり、ダッシュボードで修正すべき脆弱性が存在するイメージやリポジトリを確認しやすい
- Tag でスキャン対象イメージを絞り込める
  - 本番環境で利用しているイメージだけをスキャンしてトリアージできる
修正する開発者視点
- どう修正したらいいかの Suggest が表示され、それがわかりやすい

以下は Snyk のダッシュボードの表示です。

導入フェーズ

スキャンツールで網羅的にスキャンしていない環境だと、初期導入時に大量に脆弱性が検知されます。

最終的には対応が必要な脆弱性は全て対応する必要があるのですが、大量に検出されるので優先順位をつけて対応していく必要があります。

優先順位付け（トリアージ）

Gunosy では以下の基準でトリアージを行いましたが、必要に応じて SSVC*1 等を参考にしてください。

攻撃面（internet-facing / internal）
攻撃コードの有無・成熟度
脆弱性の重大度（Critical、High）

対応期日を含めて表にするとこんな感じです。対応期日は開発チームの余力や、対象システムの性質によって変わってきますので事前調整が必要です。

	Critical + 攻撃コードが Mature	それ以外(Critical、High)
Internet-facing	できるだけ早く対応	四半期を目処に対応
Internal	1 ヶ月以内を目処に対応	任意のタイミングで対応

導入開始前の合意が大事

想像以上に大量の脆弱性が検知されるので、導入前に開発チームとの合意が大切です。

セキュリティ対策が大事なこと
全社的にセキュリティに取り組むこと
できるだけ負担なく導入していきたいこと

コスト（ツールのコスト、対応工数）もかかります。こちらは幹部レベルに対して念押ししての合意が大事です。

最初からゼロ（完璧）を目指すと息切れします。頑張りすぎないのが大事。

受容可能な範囲にリスクを軽減することを目指しましょう。どのあたりをラインとするかは、対象とするシステムや保有するデータの性質によって変わってきます。

Gunosy では導入していませんが、セキュリティチャンピオン制度も有効だと思います。*2

Snyk の Organizaton 設定

基本は開発チーム単位で Snyk Organization を作成します。

しかし、Snyk は Organization 単位で AWS Integration を設定する必要があるので、複数の AWS アカウントに ECR リポジトリを持つチームについては、ECR をスキャンする必要がある AWS アカウント単位で Snyk Organaization を作成します。

例外として、IaC コードが格納されている GitHub リポジトリに関しては、全社統一ルールを設定する関係で IaC 専用の Organization に Import しています。

このようにすることで開発チームが関係する Organization のみを確認すれば良い状況となり、認知負荷の軽減にもなっています。

運用フェーズ

一定量、初期導入で検出された脆弱性の対応ができたら運用フェーズに移行していきます。

定期的な棚卸しで検出された脆弱性の対応をしていきましょう。スクラムに組み込んだり、セキュリティ対応 Day 的な対応日を設定したり、継続的にセキュリティ対応できる体制を開発チームと作りましょう。

運用フェーズでもトリアージが必須なので、マンパワーに応じてトリアージ対象を絞る等の対策が必要です。トリアージがボトルネックにならないようにしましょう。

期日を決めないと対応されずに塩漬けにされがちなので、期日を決めてプッシュしましょう。対応が進んでいない状況が確認されたら開発チームの余力を確認して、対応する脆弱性を絞る方向にトリアージ基準を変更することも大事です。継続的にセキュリティ対応できる体制を作りましょう。

まとめ

検知された脆弱性に対応するまでがセキュリティ対応です。ツールを導入するだけ、検知するだけでは完了しません。

銀の弾丸はありませんが、高速道路には乗れます。ツールを導入してうまく高速道路に乗りましょう

ツールの導入にはお金がかかります。脆弱性対応・セキュリティ対応にも工数がかかります。事前調整が大事です（コスト、工数）。

導入前から開発チームを巻き込みましょう。セキュリティを自分ごとにしてもらうのが大事です。セキュリティはみんなの責任です。セキュリティチャンピオン制度も有効なので検討してください。

明日は koizumi さんが CircleCI から Github Actions に大引っ越しした話について書くそうです！どんな話になのかとても楽しみです！

*1:2019 年にカーネギーメロン大学ソフトウェア工学研究所により提案された、「脆弱性管理でのアクションの優先順位付け(prioritizing actions during vulnerability management)」をする為のフレームワークです。https://insights.sei.cmu.edu/library/prioritizing-vulnerability-response-a-stakeholder-specific-vulnerability-categorization-version-20/

*2:Gunosy では開発メンバー全員でセキュリティを担保する文化となっています。