freeeにおけるSecurity Championの仕事

freee技術の日 2024 https://freee-tech-day.freee.co.jp/2024/ にて発表した資料です。

以下抜粋。
プロダクトが日々進化していく中で、その速度を止めないようにしながら堅牢にしていくことは独立したSecurityチームだけでは困難なことがあります。freeeではOWASPでも提唱されているSecurity Championを開発チーム内に置くことで、開発プロセスの中でSecurityを意識できるようにしています。このセッションではChampion自身がその運用について紹介します

Transcript

1. freeeにおけるSecurity Championの仕事 otyamura 2024年6⽉1⽇
2. 2 otyamura
 鈴木伶哉
 セキュリティキャンプ2020年度修了
 2023年4月に新卒入社。
 開発をしながらSecurityを担保するため にSecurity Championとして活動。
 freee会計開発エンジニア
3. みなさん
4. 開発段階から継続してSecurityを意識できていますか？
5. • 開発などが終わってから脆弱性診断を⾏ってSecurityの対応をすることが前までは 主流だった • 設計段階からSecurityの対応をしていくことで⼿戻りが減り、継続的に監視などを ⾏っていくことで脆弱性対応が素早くなるため、Securityに関することを開発サイ クルに含めることが主流となってきた ◦ Shift Left ◦ Secure by design ◦ DevSecOps Security意識の変化
6. Design Phase Development Phase QA Phase Operation Phase freeeでのSecurityを考慮した開発フロー 要件定義, 設計段階 での相談 SecurityDesignReview (PSIRT) 脆弱性診断 ※他で品質が担保できてい ればリリース後に実施 センサー監視 各種脆弱性管理 SAST セキュアコーディング Release !
7. 実際には… Design Phase Development Phase QA Phase Operation Phase 気づいたら拾う PSIRTへのReview依頼 がないこともある リリース間際に 気づいて脆弱性診断 センサー監視 各種脆弱性管理 SAST 脆弱性がスキャンされ ても対応するオーナー がいない
8. 実際には… Design Phase Development Phase QA Phase Operation Phase 気づいたら拾う PSIRTへのReview依頼 がないこともある リリース間際に 気づいて脆弱性診断 センサー監視 各種脆弱性管理 SAST 脆弱性がスキャンされ ても対応するオーナー がいない 脆 弱 性 発 ⾒
9. 実際には… Design Phase Development Phase QA Phase Operation Phase 気づいたら拾う PSIRTへのReview依頼 がないこともある リリース間際に 気づいて脆弱性診断 センサー監視 各種脆弱性管理 SAST 脆弱性がスキャンされ ても対応するオーナー がいない 脆 弱 性 発 ⾒ 診断で重篤なセキュリティ‧リスクが⾒つ かった場合、リリースギリギリで⼿戻りし、 修正せざるを得ない
10. では、なぜSecurityが後⼿に回ってしまうのでしょうか？
11. 多くの プロダクト開発チーム セキュリティチーム freeeの開発体制
12. 多くの プロダクト開発チーム freeeの開発体制 • 最速でプロダクトを届けたい • 機能開発を優先したい • Securityは後回し • そもそも何したらいいかわか らない
13. セキュリティチーム freeeの開発体制 • 機能開発を遅らせたいわけでは ない • ⼿戻り防⽌のために早い段階か ら相談して欲しい • 進化していくプロダクトの数が 多く捌ききれない • ドメイン知識が複雑なため キャッチアップに時間がかかる
14. セキュリティチーム freeeの開発体制 多くの プロダクト開発チーム Security Champions
15. • プロダクト開発が⽬まぐるしい速度で進んでいく中、Securityチームが全ての開発 に対して⽬を向けるのはとても困難 • そこで、開発者の中にSecurity担当者であるSecurity Championを配置すること でプロダクト開発チームとSecurityチームの橋渡し役になってもらうことができ、 開発チームのSecurity意識の浸透へと繋げることが可能 開発者を通したSecurity意識の浸透
16. • どのように決まるか？ ◦ OWASPでは「Security Champions should be nominated」とありトップダウン ◦ freeeではバックエンド委員会などボトムアップで様々な活動が⾏われているため Security Championsも⽴候補制 • ランク制 ◦ Bronze, Silver, Gold ◦ Silver以上になるとDesignDocのSecurity reviewが必須かどうか判断することが可能 • ステッカー ◦ ymrl⽒による⼒作 ◦ 最⾼の仕上がり freeeでのSecurity Champions制度
17. freeeではどのようにSecurity Championsを運⽤しているか
18. Design Phase Development Phase QA Phase Operation Phase freeeでのSecurityを考慮した開発フロー 要件定義, 設計段階 での相談 SecurityDesignReview (PSIRT) 脆弱性診断 ※他で品質が担保できてい ればリリース後に実施 センサー監視 各種脆弱性管理 SAST セキュアコーディング Release !
19. Design Phase Development Phase QA Phase Operation Phase freeeでのSecurityを考慮した開発フロー 要件定義, 設計段階 での相談 SecurityDesignReview (PSIRT) DesignDocReview (Security Champions) 脆弱性診断 ※他で品質が担保できてい ればリリース後に実施 センサー監視 各種脆弱性管理 脆弱性対応 (Security Champions) SAST スキャンされた 脆弱性の対応 (Security Champions) Release !
20. • プロダクト内のSecurity対応 ◦ DesignDocのSecurity Champions Review ◦ ツールによって検出された脆弱性の対処 ◦ セキュリティインシデントの対応 • 知⾒共有など ◦ 他のSecurity Championsとの定期共有会 ◦ セキュリティLT⼤会 実際にSecurity Championとして⾏っていること
21. • プロダクトの内情に精通していることを活かしたDesignDocレビュー • 権限の実装はどのように⾏うか？ ◦ まだ権限周りの実装は⼀部共通化されておらず、古くからあるプロダクトには開 発者でないと気づけない落とし⽳が存在している • 返される情報から推測されることはないか？ ◦ 複数の情報から組み合わせることで推測されるようになっていないか ◦ ex. 複数の仕訳情報から⼝座に⼊っている⾦額や売り上げなどがわかる DesignDocのSecurity Champions Review
22. Security Champions セキュリティチーム ツールによって検出された脆弱性の対処 • CodeQLの設定 • Championsからの相談 22 • CodeQLの対処‧トリアージ • 不明なものについては相談 • 実装に精通したChampionsによる素早い対処が可能 • セキュリティに精通したチームへの相談をいつでもすることが可能
23. • 顧客情報が関わる場合のインシデントなどは基本的にCSIRT/PSIRTが対処 • しかしながら、プロダクト開発チームでの対処が必要な場⾯もある • その際の対応役としてSecurity Championsを⽤いている セキュリティインシデントの対応 • 実例 ◦ プロダクトに誤って登録されてしまったデータの削除 ▪ S3 bucket名や、DB上のカラム名などを実装上のコードから調査 ▪ 削除するためのタスクなどを実装 ◦ ログに流れてしまったSensitiveな情報のマスキング ▪ ログに流してもいい情報は決まっているが、設定ミスなどから流れることがある ▪ Championsがマスキングするための設定を追加
24. • Security Championsによる2週間に1度の定期共有会 • 共有会では ◦ DesignDocのレビュー内容の共有‧質問 ◦ CodeQLのスキャン結果の確認 ◦ セキュリティインシデントの共有 • 知識の共有をしながらプロダクトのセキュリティの最新状況を常に把握している Security Champions同⼠の定期共有会
25. • Security Championsだけでなく、PSIRTやCSIRTといったセキュリティ専⾨チーム とも交流を深めながら知⾒を⾼めるためにセキュリティに関するLT⼤会を開催 • 脅威モデリングやsalesforceの権限など様々なセキュリティ分野について発表 • ⾃分はCodeQLのスキャン結果に対して、TaintTrackingしていく⽅法について解説 セキュリティLT⼤会
26. Security Championsという制度がもたらしたこと
27. • freeeでは開発⽂化として「何でもやれる、何でもやる」があり、アプリだけでなく インフラなども含めてフルスタックに活躍したいエンジニアが多い • そこからさらにSecurityも含めたフルスタックエンジニアになることが可能 Security Championを通した開発者としてのスキル向上 2.何でもやれる、何でもやる 「特定の技術や領域に固執せず オールラウンドに取り組む」 そんな姿勢を、守備も攻撃も応援 もこなしちゃう野球選⼿で表現。 範囲を超えて⾏動できる姿は頼り 甲斐を感じさせます。
28. • 社内のDesignDocレビューのコスト削減 ◦ 200を超える数のDesignDocをレビュー ◦ 深いドメイン知識を活かしてSecurity teamの理解を助ける • 脆弱性対応の分業 ◦ セキュリティチームがCodeQLの設定を管理し、Security Championsがそれらの トリアージを⾏っていく ◦ freee会計では約100個のスキャン結果の対応 • Championsを通して、プロダクト開発チームへ知⾒の共有をしたりセキュリティ チームへの相談が活発になったりした Security Championsによる成果
29. • これまでは、開発チームとSecurityチームとの連携がうまく取れていなかった • 対策として、Security Champions制度を導⼊ • Championsによる ◦ ドメイン知識を活かしたDesignDocレビュー ◦ 脆弱性対処 ◦ セキュリティインシデント対応 • その結果、チーム間の連携が上⼿く取れるようになり、開発チームの中でも Securityについて意識が向くようになった まとめ