Efficient Platform for Security and Compliance

「セキュリティとコンプライアンスを保ちつつ生産性の高い開発を実現するためのプラットフォーム」

Talk at Platform Engineering Kaigi 2024 https://www.cnia.io/pek2024/sessions/2a367e04-9c4a-4784-a659-f3bbcbf12998/

Efficient Platform for Security and Compliance

Transcript

1. © 2024 Finatext Holdings Ltd. セキュリティとコンプライアンスを保ちつつ 生産性の高い開発を実現するためのプラットフォーム Taiki Ono, 株式会社Finatext
2. © 2024 Finatext Holdings Ltd. Two-Person Integrity (TPI): 重要なデータへのアクセスや、リスクの高いオペレーションに関して、単独での実 行を不可にし、2人以上の関与を必須とするアクセス管理の手法。別名Two-Person Rule。相互牽制の力学 TARP: 本番環境のAWSリソースをマニュアル操作できる強い権限のロールにAssumeRoleする際に、本人以外のメ ンバーによる承認があれば一時的に権限を付与する仕組みを構築することで実現。Slackなどでリクエストして、 本人以外のメンバーがCLIコマンドを実行するのみで、裏側でLambda functionなどが動作する Temporary AssumeRole Policy (TARP) 1
3. © 2024 Finatext Holdings Ltd. Taiki Ono @taiki45 2
5. © 2024 Finatext Holdings Ltd. Finatextはマルチドメインな会社 4 フィンテックソリューション 事業領域 証券事業領域 データ事業領域 保険事業領域 クレジット事業領域 データ＆AIソリューション 事業領域
6. © 2024 Finatext Holdings Ltd. 証券事業領域 Finatextはマルチドメイン・マルチプロダクトな会社 5 BaaS (Brokerage as a Service) プラットフォーム パートナーサービス A パートナーサービス B パートナーサービス C ・・・
7. © 2024 Finatext Holdings Ltd. Finatextは分散プラットフォームチーム型 6 国内メンバー数: 200人超 ソフトウェアエンジニアロールのメンバー: 約100人 メンバーの約6割がプロダクト開発に携わる 海外込みメンバー数: 300人超 フルタイムのプラットフォームチームのメンバー: 1人 兼務やパートタイムも換算すると実質2人(?) 代わりに各ドメイン(事業領域)にプラットフォームチームを構成しつつある Central Platform Team Data Domain Platform Team Brok Domain Platform Team
8. © 2024 Finatext Holdings Ltd. • Temporary AssumeRole Policy • Active Secrets Scanning • Open-souce GitHub Organization-wide Workflows 今日の内容 7
9. © 2024 Finatext Holdings Ltd. モダンな技術で相互牽制の実現 Temporary AssumeRole Policy 8
10. © 2024 Finatext Holdings Ltd. 重要なデータへのアクセスや、リスクの高いオペレーションに関して、単独での実行を不可にし、2人以上の関与 を必須とするアクセス管理の手法。別名Two-Person Rule。相互牽制の力学を利用する Two-Person Integrity (TPI) 9
11. © 2024 Finatext Holdings Ltd. • Terraformを使って構成管理 • runatlantis/atlantisを使ってGitHubのPR上でapply • GitHubの "Require approvals" 設定を使用してTPIを実現 ◦ AWSリソースを変更するのには他メンバーの承認が必要 ◦ 重要なリソースの変更はコードオーナーの承認が必要 AWSリソース管理でのTPIの実現 10
12. © 2024 Finatext Holdings Ltd. ほとんどのケースでは自動化しているが極一部マニュアル操作が必要なケースが存在 →マニュアル操作する際もTPIを実現するためにTemporary AssumeRole Policy (TARP)という仕組みを構築 一部のマニュアル操作でのTPIの実現 11
13. © 2024 Finatext Holdings Ltd. 前提: • GatewayとなるAWSアカウントを各本番環境のAWSアカウントとは分離して用意している • 本番環境のリソースを操作できるような権限はIAM Roleとして用意して、各開発者がgatewayアカウントか らAssumeRoleして利用する • 普段はgatewayアカウントの各開発者用のIAMユーザーにはAssumeRoleできるポリシーを付与していない Temporary AssumeRole Policy (TARP) 12
14. © 2024 Finatext Holdings Ltd. 開発者がSlackなどでリクエストして他メンバーがCLIコマンドを実行する 裏側でLambda functionが動作してAssumeRoleできるポリシーをその開発者のIAMユーザーに付与 ポリシーのcondition式で有効期限を制御し一時性を実現 Lambda functionが自動的に不要になったポリシーを削除 Temporary AssumeRole Policy (TARP) 13
15. © 2024 Finatext Holdings Ltd. TARPは2021年に開発・運用開始していて当時は他の選択肢は存在しなかった →今は https://github.com/aws-samples/aws-iam-temporary-elevated-access-broker のような参照実装が ある →今後各クラウドの機能として実装されそう https://cloud.google.com/iam/docs/temporary-elevated-access 他の選択肢 14
16. © 2024 Finatext Holdings Ltd. 秘匿値がソースコードに混入することを早期に防ぐ Active Secrets Scanning 15
17. © 2024 Finatext Holdings Ltd. Secrets scanningの対象は多様だが、ここではソースコードに対するsecrets scanning 金融領域は外部接続が多い。なので、扱う秘匿値の数・種類が多い。さらにクリティカルなデータを扱っている →ソースコードに秘匿値が混ざらないように管理したいモチベーションが強い →人間の努力以外に機械的にサポートする仕組みがほしい →外部サービス数が多いので、未知のフォーマットの秘匿値も可能なら検知したい 過去も不定期の一括secrets scanningは中央のプラットフォームチームが実施していた →事業規模の拡大によって作業量の増大。コンテキストをより理解している各開発者に委譲できる仕組みが必要 →そもそもより早期に検知・対応できた方がリスクを低減できるので望ましい Motivation 16
18. © 2024 Finatext Holdings Ltd. Pros: • "push protection" 機能によってリポジトリへのプッシュ前に防止できる • マネージドサービスである ◦ UIやワークフローもいい感じ Cons: • 必要な機能が足りない ◦ GitHubが対応している外部サービス以外の秘匿値は正規表現でのスキャンで、誤検知(false positive) を無視するルールの定義もできない ◦ さらにユーザー定義のルールはpush protectionの対象外 ◦ (調査当時時点) • 料金が高い ◦ GitHub Enterpise planかつGitHub Advanced Securityの契約が必要。Team planからのジャンプだ と約17倍のコストアップ。Finatextではシート数が多いのでコスト増も大きい 将来的にGitHub Advanced Securityの機能が進化して、さらに価格がこなれてきて、プランもEnterpiseを利用 していくようになった後に移行したいので、それまでの間を埋める軽量なソリューションがほしい Secret Scanning Alerts in GitHub Advanced Security 17
19. © 2024 Finatext Holdings Ltd. • リポジトリへのプッシュ前に検知はしなくても、そのくらい早期に検知できるようにしたい • 未知のサービスの秘匿値も検知したい • 誤検知(false positive)を無視するルールの表現力がほしい ◦ 未知のフォーマットの秘匿値も検知するので誤検知が大量に起きる • 将来的なGitHub Advanced Security移行のつなぎなので既存のツールを使って構築したい gitleaks/gitleaksを使ってPRに対してsecrets scanをかける方針に ツールのその他の候補としてはtrivy, git-secrets, Yelp/detect-secrets, trufflehog サービスのその他の候補としてはGitGuardian 内製する軽量なソリューションの方向性 18
20. © 2024 Finatext Holdings Ltd. • カバー率 vs 誤検知率のトレードオフ • 検知ジョブのパフォーマンス • セルフサービス化 出てきた課題 19
21. © 2024 Finatext Holdings Ltd. 未知の秘匿値を検知する場合、誤検知との戦いになる。誤検知を制すものがsecrets scanningを制す →検知ルールと誤検知を無視するルールの両方の開発が必要 →それぞれの組織で利用している外部サービスも許容するリスクも異なるのでルールは一般化できない カバー率を上げたい vs 誤検知率の増加 20
22. © 2024 Finatext Holdings Ltd. 誤検知対策のために、gitleaksの機能を補うCLIツールを開発 https://github.com/Finatext/gls 検知した秘匿値を無視するルールを拡張する。この「無視するルール」はgitleaksでは "allowlist" と呼ぶ ルール開発: • `gls review`: 複数のリポジトリでの「検知結果」「無視された検知結果」をまとめたりフィルターしたりす る • `gls diff`: ルールの変更前後でのdiffを出す CIジョブ: • `gls apply`: gitleaksの検知結果を拡張allowlistでフィルターする gls: gitleaks-support 21
23. © 2024 Finatext Holdings Ltd. gls: Summary View 22
24. © 2024 Finatext Holdings Ltd. gls: Confirmed Findings View 23
25. © 2024 Finatext Holdings Ltd. gls: Allowed Findings View 24
26. © 2024 Finatext Holdings Ltd. 検知ジョブのパフォーマンス問題 →gitleaksはデフォルトだとGitリポジトリの全履歴をスキャンするのでクローンもスキャンも遅い →スキャン対象をプッシュされた差分のみに プラットフォームチームが全ての検知結果をハンドルするのはスケールしない Finatextでは、開発チームがより広範囲のレイヤーにオーナーシップを持って、機動的に開発できるのが望ましい 状態としてプラットフォームの開発を行ってきた。Secrets scanningも認知不可を上げず、開発効率を落とさ ず、開発チームがドライブできるべき →検知結果の見せ方とハンドリングをより良い形で設計しセルフサービス化 Active Secrets Scanningにおける誤検知以外の課題 25
27. © 2024 Finatext Holdings Ltd. • CIジョブ実行時にリポジトリはtree-less fetchを利用してコミットオブジェクトのみダウンロードする ◦ `git fetch --filter=tree:0` ◦ Blobもtreeもダウンロードしないので速い • GitHubのpull requestには `before`, `after` というフィールドがあり、これを利用してプッシュされた差分 のみ追加でダウンロードする ◦ `before`, `after` にはプッシュされる前のHEADとされた後のHEADのコミットSHAが入っている • gitleaksの `--log-opts` オプションを利用して差分のみスキャンするようにする パフォーマンス問題: スキャン対象を差分のみにする 26
28. © 2024 Finatext Holdings Ltd. • デフォルトでは目立つPRコメントで「該当箇所」、「取るべきアクションを解説している社内wikiページへ のリンク」の両方を通知 • GitHub Checks APIによる控えなUIもオプションでできるように ◦ PRコメントは良くも悪くも目立つので邪魔になることもありそう ◦ Checks API経由だとPRの "Checks" タブか "Files changed" タブを開かないと見えないのがデメリッ ト セルフサービス: 検知結果の見せ方 27
29. © 2024 Finatext Holdings Ltd. 検知時のUI: Pull Request Comment 28
30. © 2024 Finatext Holdings Ltd. 検知時のUI: Checks API 29
31. © 2024 Finatext Holdings Ltd. • CIジョブがOpsgenieというアラート管理サービスにアラートを作成 ◦ アラートは優先度低めに設定 • OpsgenieのSlackインテグレーションによってSlackにアラート通知 ◦ プラットフォームチームはアラートが流れてくるチャンネルを監視している • 開発者はSlackに通知されているアラートをまずはackして検知結果が問題ないかの確認と対応 ◦ PRコメントのアクションガイドから辿れる社内wikiページに「Slackに通知されているアラートを見て ackして対応する」内容が書いてありゼロ知識でもアクションできるように • 開発者は対応が終わったらアラートをクローズ • プラットフォームチームは対応が漏れているアラートを定期的に拾って確認・対応とクローズ セルフサービス: 検知結果のハンドリング 30
32. © 2024 Finatext Holdings Ltd. セルフサービス: 検知結果のハンドリング 31 Pull request Developer CI job Opsgenie Slack Trigger alert Notify Ack/Close alert Feedback via comment Create comment Ack/Close alert Create Trigger
33. © 2024 Finatext Holdings Ltd. Secrets scanningをいい感じにできるようにしたぞ！公開ベータ中のGitHub "organization-wide required workflows" を利用していて、secrets scanningのジョブもこの上で全リポジトリで動かすぞ！！ →2023年10月に公開ベータ卒業に伴いFinatextでは利用できない状態に リポジトリは700以上あるのでうまい方法を取る必要がある CIジョブどこで動かすか問題 32
34. © 2024 Finatext Holdings Ltd. GitHub org内の全てのリポジトリに対してCIジョブを実行し続ける Open-souce GitHub Organization-wide Workflows 33
35. © 2024 Finatext Holdings Ltd. Secrets scanningのようなCIジョブはGitHubのorganization内の全てのリポジトリに対して実行し続けたい マルチドメイン・マルチプロダクトな事業ポートフォリオの関係もあり、GitHubのリポジトリ数が多い →初期のアーキテクチャがマイクロサービスに寄りすぎていたためリポジトリ数が多かったが、現在はその教訓を 活かし必要程度の分散アーキテクチャを採用しているが、それでも事業の成長に従って増えている →アーカイブを除いたリポジトリ数で700超で現在も増加中。うち半分程度は毎月アクティビティがある Motivation 34
36. © 2024 Finatext Holdings Ltd. GitHubに過去公開ベータとして存在していた "Organization-wide Required Workflows" という機能があり、 特定のリポジトリに置いたワークフロー定義から、他のリポジトリで直接ワークフローを実行できた →ワークフローファイルを配布・メンテする必要がない →あるリポジトリをジョブの対象にするのも設定ですぐにできる この機能は公開ベータ卒業後に "Rulesetset Workflows" と名称を変えてリリース Organization-wide Required Workflows and Ruleset Workflows 35 Workflow file repository Product A repository Product B repository Job Job Job Job Job Job Job Job
37. © 2024 Finatext Holdings Ltd. Organization-wide required workflowsはGitHubのチームプランでも利用できていたが、公開ベータ卒業後の rulesetset workflowsではエンタープライズプラン以上専用に... GitHubは重点的に活用していて開発者以外でも利用していたりでライセンス数が多く、チームプランとエンター プライズプランの料金のギャップが大きい 2021年までと現在ではコストへの意識が変化 →金利上昇・高止まり局面 →日本はさらに円安トレンド Post-zero Interest Rate Policy (post-ZIRP) 36
38. © 2024 Finatext Holdings Ltd. GitHub Actionsには "Reusable workflows" という仕組みがあり、ワークフロー定義の本体を特定のリポジトリ に置いて、別のリポジトリからそのワークフローを参照して実行できる →参照するリポジトリにもワークフローファイルは置く必要があるので、定義本体ではなくても全てのリポジトリ にワークフローファイルは置く必要がある Reusable Workflowでのアプローチ 37 Workflow file repository Product A repository Product B repository Job Job Job Job Job Job Job Job
39. © 2024 Finatext Holdings Ltd. ワークフローファイルに限らず複数のリポジトリにある共通したファイルを起きたいモチベーションは別である。 例えばコードオーナーファイルやPRテンプレートファイル →特定のファイルを自動で複数リポジトリに同期するソフトウェアはすでに開発・運用している リポジトリをサンプリングしてこの方式を試した時に課題が出てきた →ワークフローの大規模リファクタリングでプロダクト開発者がうっかりワークフローファイルを削除してしまう ケースがあった →リポジトリのオーナーが自らファイルを同期するのと、プラットフォームチームのような横断的チームが同期を かける違い。全てのリポジトリを細かく把握できるわけではなく、自動デプロイなどが障壁に Reusable Workflowsでの課題 38
40. © 2024 Finatext Holdings Ltd. • AWS Lambdaや他のプラットフォームで動作するorganization-wide workflows ◦ GitHub AppのwebhookとChecks APIを利用 ◦ ワークフローファイルの配布が不要に • AWS Lambdaの場合1ミリ秒単位での切り上げ課金 ◦ GitHub Actions GitHub-hosted runnersは1分単位での切り上げ課金 ◦ 全リポジトリに対して実行する高頻度なジョブでは重要 • GitHubのRuleset Workflowsと違い "required" ではないジョブも動かせる • リポジトリのメタデータに基づいて一部のリポジトリ群を対象にもできる ◦ メタデータは "custom properties" という機能を使って管理している OSSとして公開: https://github.com/Finatext/orgu ブログ記事: https://medium.com/finatext/orgu-e3a3ad0219a8 orgu: Open-source Organization-wide Workflows 39
41. © 2024 Finatext Holdings Ltd. Architecture 40 Computing Platform orgu-runner orgu-front secrets scan job orgu-runner gosec job GitHub Webhook orgu-runner actionlint job Event Queue Pull Request comments Opsgenie Checks API HTTP POST GitHub App enqueue dequeue dequeue dequeue Job feedbacks
42. © 2024 Finatext Holdings Ltd. orgu-runner Job Execution Sequence 41
43. © 2024 Finatext Holdings Ltd. Filtering CheckRequest 42 Computing Platform orgu-runner orgu-front secrets scan job orgu-runner gosec job GitHub Webhook orgu-runner actionlint job Event Queue Pull Request comments Opsgenie Checks API HTTP POST GitHub App enqueue dequeue dequeue dequeue Job feedbacks
44. © 2024 Finatext Holdings Ltd. Filtering Based On Repository Metadata 43 https://github.com/Finatext/orgu/blob/v0.1.0/src/events.rs
45. © 2024 Finatext Holdings Ltd. Filtering Based On Repository Metadata 44
46. © 2024 Finatext Holdings Ltd. Easy To Try in a Local Machine 45
47. © 2024 Finatext Holdings Ltd. まとめ Wrap-up 46
48. © 2024 Finatext Holdings Ltd. セキュリティやコンプライアンスの領域でも、セルフサービスやゼロ知識ですぐに使えるものにするのが大事 他の領域と違い最も重要なのが、こぼれてしまった問題をプラットフォームチームが回収できる仕組みを作ること でエンフォースメントをたしかにする Wrap-up 47