Efficient Platform for Security and Compliance

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 2024 Finatext Holdings Ltd. Two-Person Integrity (TPI): 重要なデータへのアクセスや、リスクの高いオペレーションに関して、単独での実行を不可にし、2人以上の関与を必須とするアクセス管理の手法。別名Two-Person Rule。相互牽制の力学 TARP: 本番環境のAWSリソースをマニュアル操作できる強い権限のロールにAssumeRoleする際に、本人以外のメンバーによる承認があれば一時的に権限を付与する仕組みを構築することで実現。Slackなどでリクエストして、本人以外のメンバーがCLIコマンドを実行するのみで、裏側でLambda functionなどが動作する Temporary AssumeRole Policy (TARP) 1

Slide 3

Slide 3 text

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© 2024 Finatext Holdings Ltd. Finatextは分散プラットフォームチーム型 6 国内メンバー数: 200人超ソフトウェアエンジニアロールのメンバー: 約100人メンバーの約6割がプロダクト開発に携わる海外込みメンバー数: 300人超フルタイムのプラットフォームチームのメンバー: 1人兼務やパートタイムも換算すると実質2人(?) 代わりに各ドメイン(事業領域)にプラットフォームチームを構成しつつある Central Platform Team Data Domain Platform Team Brok Domain Platform Team

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2024 Finatext Holdings Ltd. ● Terraformを使って構成管理 ● runatlantis/atlantisを使ってGitHubのPR上でapply ● GitHubの "Require approvals" 設定を使用してTPIを実現 ○ AWSリソースを変更するのには他メンバーの承認が必要 ○ 重要なリソースの変更はコードオーナーの承認が必要 AWSリソース管理でのTPIの実現 10

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© 2024 Finatext Holdings Ltd. 前提: ● GatewayとなるAWSアカウントを各本番環境のAWSアカウントとは分離して用意している ● 本番環境のリソースを操作できるような権限はIAM Roleとして用意して、各開発者がgatewayアカウントからAssumeRoleして利用する ● 普段はgatewayアカウントの各開発者用のIAMユーザーにはAssumeRoleできるポリシーを付与していない Temporary AssumeRole Policy (TARP) 12

Slide 14

Slide 14 text

© 2024 Finatext Holdings Ltd. 開発者がSlackなどでリクエストして他メンバーがCLIコマンドを実行する裏側でLambda functionが動作してAssumeRoleできるポリシーをその開発者のIAMユーザーに付与ポリシーのcondition式で有効期限を制御し一時性を実現 Lambda functionが自動的に不要になったポリシーを削除 Temporary AssumeRole Policy (TARP) 13

Slide 15

Slide 15 text

© 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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2024 Finatext Holdings Ltd. Secrets scanningの対象は多様だが、ここではソースコードに対するsecrets scanning 金融領域は外部接続が多い。なので、扱う秘匿値の数・種類が多い。さらにクリティカルなデータを扱っている →ソースコードに秘匿値が混ざらないように管理したいモチベーションが強い →人間の努力以外に機械的にサポートする仕組みがほしい →外部サービス数が多いので、未知のフォーマットの秘匿値も可能なら検知したい過去も不定期の一括secrets scanningは中央のプラットフォームチームが実施していた →事業規模の拡大によって作業量の増大。コンテキストをより理解している各開発者に委譲できる仕組みが必要 →そもそもより早期に検知・対応できた方がリスクを低減できるので望ましい Motivation 16

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

© 2024 Finatext Holdings Ltd. ● リポジトリへのプッシュ前に検知はしなくても、そのくらい早期に検知できるようにしたい ● 未知のサービスの秘匿値も検知したい ● 誤検知(false positive)を無視するルールの表現力がほしい ○ 未知のフォーマットの秘匿値も検知するので誤検知が大量に起きる ● 将来的なGitHub Advanced Security移行のつなぎなので既存のツールを使って構築したい gitleaks/gitleaksを使ってPRに対してsecrets scanをかける方針にツールのその他の候補としてはtrivy, git-secrets, Yelp/detect-secrets, truﬄehog サービスのその他の候補としてはGitGuardian 内製する軽量なソリューションの方向性 18

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

© 2024 Finatext Holdings Ltd. 誤検知対策のために、gitleaksの機能を補うCLIツールを開発 https://github.com/Finatext/gls 検知した秘匿値を無視するルールを拡張する。この「無視するルール」はgitleaksでは "allowlist" と呼ぶルール開発: ● `gls review`: 複数のリポジトリでの「検知結果」「無視された検知結果」をまとめたりフィルターしたりする ● `gls diﬀ`: ルールの変更前後でのdiﬀを出す CIジョブ: ● `gls apply`: gitleaksの検知結果を拡張allowlistでフィルターする gls: gitleaks-support 21

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© 2024 Finatext Holdings Ltd. 検知ジョブのパフォーマンス問題 →gitleaksはデフォルトだとGitリポジトリの全履歴をスキャンするのでクローンもスキャンも遅い →スキャン対象をプッシュされた差分のみにプラットフォームチームが全ての検知結果をハンドルするのはスケールしない Finatextでは、開発チームがより広範囲のレイヤーにオーナーシップを持って、機動的に開発できるのが望ましい状態としてプラットフォームの開発を行ってきた。Secrets scanningも認知不可を上げず、開発効率を落とさず、開発チームがドライブできるべき →検知結果の見せ方とハンドリングをより良い形で設計しセルフサービス化 Active Secrets Scanningにおける誤検知以外の課題 25

Slide 27

Slide 27 text

© 2024 Finatext Holdings Ltd. ● CIジョブ実行時にリポジトリはtree-less fetchを利用してコミットオブジェクトのみダウンロードする ○ `git fetch --filter=tree:0` ○ Blobもtreeもダウンロードしないので速い ● GitHubのpull requestには `before`, àfter` というフィールドがあり、これを利用してプッシュされた差分のみ追加でダウンロードする ○ `before`, àfter` にはプッシュされる前のHEADとされた後のHEADのコミットSHAが入っている ● gitleaksの `--log-opts` オプションを利用して差分のみスキャンするようにするパフォーマンス問題: スキャン対象を差分のみにする 26

Slide 28

Slide 28 text

© 2024 Finatext Holdings Ltd. ● デフォルトでは目立つPRコメントで「該当箇所」、「取るべきアクションを解説している社内wikiページへのリンク」の両方を通知 ● GitHub Checks APIによる控えなUIもオプションでできるように ○ PRコメントは良くも悪くも目立つので邪魔になることもありそう ○ Checks API経由だとPRの "Checks" タブか "Files changed" タブを開かないと見えないのがデメリットセルフサービス: 検知結果の見せ方 27

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© 2024 Finatext Holdings Ltd. ● CIジョブがOpsgenieというアラート管理サービスにアラートを作成 ○ アラートは優先度低めに設定 ● OpsgenieのSlackインテグレーションによってSlackにアラート通知 ○ プラットフォームチームはアラートが流れてくるチャンネルを監視している ● 開発者はSlackに通知されているアラートをまずはackして検知結果が問題ないかの確認と対応 ○ PRコメントのアクションガイドから辿れる社内wikiページに「Slackに通知されているアラートを見て ackして対応する」内容が書いてありゼロ知識でもアクションできるように ● 開発者は対応が終わったらアラートをクローズ ● プラットフォームチームは対応が漏れているアラートを定期的に拾って確認・対応とクローズセルフサービス: 検知結果のハンドリング 30

Slide 32

Slide 32 text

© 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

Slide 33

Slide 33 text

© 2024 Finatext Holdings Ltd. Secrets scanningをいい感じにできるようにしたぞ！公開ベータ中のGitHub "organization-wide required workﬂows" を利用していて、secrets scanningのジョブもこの上で全リポジトリで動かすぞ！！ →2023年10月に公開ベータ卒業に伴いFinatextでは利用できない状態にリポジトリは700以上あるのでうまい方法を取る必要がある CIジョブどこで動かすか問題 32

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© 2024 Finatext Holdings Ltd. Secrets scanningのようなCIジョブはGitHubのorganization内の全てのリポジトリに対して実行し続けたいマルチドメイン・マルチプロダクトな事業ポートフォリオの関係もあり、GitHubのリポジトリ数が多い →初期のアーキテクチャがマイクロサービスに寄りすぎていたためリポジトリ数が多かったが、現在はその教訓を活かし必要程度の分散アーキテクチャを採用しているが、それでも事業の成長に従って増えている →アーカイブを除いたリポジトリ数で700超で現在も増加中。うち半分程度は毎月アクティビティがある Motivation 34

Slide 36

Slide 36 text

© 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

Slide 37

Slide 37 text

© 2024 Finatext Holdings Ltd. Organization-wide required workﬂowsはGitHubのチームプランでも利用できていたが、公開ベータ卒業後の rulesetset workﬂowsではエンタープライズプラン以上専用に... GitHubは重点的に活用していて開発者以外でも利用していたりでライセンス数が多く、チームプランとエンタープライズプランの料金のギャップが大きい 2021年までと現在ではコストへの意識が変化 →金利上昇・高止まり局面 →日本はさらに円安トレンド Post-zero Interest Rate Policy (post-ZIRP) 36

Slide 38

Slide 38 text

© 2024 Finatext Holdings Ltd. GitHub Actionsには "Reusable workﬂows" という仕組みがあり、ワークフロー定義の本体を特定のリポジトリに置いて、別のリポジトリからそのワークフローを参照して実行できる →参照するリポジトリにもワークフローファイルは置く必要があるので、定義本体ではなくても全てのリポジトリにワークフローファイルは置く必要がある Reusable Workﬂowでのアプローチ 37 Workflow file repository Product A repository Product B repository Job Job Job Job Job Job Job Job

Slide 39

Slide 39 text

© 2024 Finatext Holdings Ltd. ワークフローファイルに限らず複数のリポジトリにある共通したファイルを起きたいモチベーションは別である。例えばコードオーナーファイルやPRテンプレートファイル →特定のファイルを自動で複数リポジトリに同期するソフトウェアはすでに開発・運用しているリポジトリをサンプリングしてこの方式を試した時に課題が出てきた →ワークフローの大規模リファクタリングでプロダクト開発者がうっかりワークフローファイルを削除してしまうケースがあった →リポジトリのオーナーが自らファイルを同期するのと、プラットフォームチームのような横断的チームが同期をかける違い。全てのリポジトリを細かく把握できるわけではなく、自動デプロイなどが障壁に Reusable Workﬂowsでの課題 38

Slide 40

Slide 40 text

© 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

Slide 41

Slide 41 text

© 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

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 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