Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Efficient Platform for Security and Compliance

taiki45
July 09, 2024

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

taiki45

July 09, 2024
Tweet

More Decks by taiki45

Other Decks in Technology

Transcript

  1. © 2024 Finatext Holdings Ltd. Two-Person Integrity (TPI): 重要なデータへのアクセスや、リスクの高いオペレーションに関して、単独での実 行を不可にし、2人以上の関与を必須とするアクセス管理の手法。別名Two-Person

    Rule。相互牽制の力学 TARP: 本番環境のAWSリソースをマニュアル操作できる強い権限のロールにAssumeRoleする際に、本人以外のメ ンバーによる承認があれば一時的に権限を付与する仕組みを構築することで実現。Slackなどでリクエストして、 本人以外のメンバーがCLIコマンドを実行するのみで、裏側でLambda functionなどが動作する Temporary AssumeRole Policy (TARP) 1
  2. © 2024 Finatext Holdings Ltd. Finatextはマルチドメインな会社 4 フィンテックソリューション 事業領域 証券事業領域

    データ事業領域 保険事業領域 クレジット事業領域 データ&AIソリューション 事業領域
  3. © 2024 Finatext Holdings Ltd. 証券事業領域 Finatextはマルチドメイン・マルチプロダクトな会社 5 BaaS (Brokerage

    as a Service) プラットフォーム パートナーサービス A パートナーサービス B パートナーサービス C ・・・
  4. © 2024 Finatext Holdings Ltd. Finatextは分散プラットフォームチーム型 6 国内メンバー数: 200人超 ソフトウェアエンジニアロールのメンバー:

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

    Active Secrets Scanning • Open-souce GitHub Organization-wide Workflows 今日の内容 7
  6. © 2024 Finatext Holdings Ltd. • Terraformを使って構成管理 • runatlantis/atlantisを使ってGitHubのPR上でapply •

    GitHubの "Require approvals" 設定を使用してTPIを実現 ◦ AWSリソースを変更するのには他メンバーの承認が必要 ◦ 重要なリソースの変更はコードオーナーの承認が必要 AWSリソース管理でのTPIの実現 10
  7. © 2024 Finatext Holdings Ltd. 前提: • GatewayとなるAWSアカウントを各本番環境のAWSアカウントとは分離して用意している • 本番環境のリソースを操作できるような権限はIAM

    Roleとして用意して、各開発者がgatewayアカウントか らAssumeRoleして利用する • 普段はgatewayアカウントの各開発者用のIAMユーザーにはAssumeRoleできるポリシーを付与していない Temporary AssumeRole Policy (TARP) 12
  8. © 2024 Finatext Holdings Ltd. Secrets scanningの対象は多様だが、ここではソースコードに対するsecrets scanning 金融領域は外部接続が多い。なので、扱う秘匿値の数・種類が多い。さらにクリティカルなデータを扱っている →ソースコードに秘匿値が混ざらないように管理したいモチベーションが強い

    →人間の努力以外に機械的にサポートする仕組みがほしい →外部サービス数が多いので、未知のフォーマットの秘匿値も可能なら検知したい 過去も不定期の一括secrets scanningは中央のプラットフォームチームが実施していた →事業規模の拡大によって作業量の増大。コンテキストをより理解している各開発者に委譲できる仕組みが必要 →そもそもより早期に検知・対応できた方がリスクを低減できるので望ましい Motivation 16
  9. © 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
  10. © 2024 Finatext Holdings Ltd. • リポジトリへのプッシュ前に検知はしなくても、そのくらい早期に検知できるようにしたい • 未知のサービスの秘匿値も検知したい •

    誤検知(false positive)を無視するルールの表現力がほしい ◦ 未知のフォーマットの秘匿値も検知するので誤検知が大量に起きる • 将来的なGitHub Advanced Security移行のつなぎなので既存のツールを使って構築したい gitleaks/gitleaksを使ってPRに対してsecrets scanをかける方針に ツールのその他の候補としてはtrivy, git-secrets, Yelp/detect-secrets, trufflehog サービスのその他の候補としてはGitGuardian 内製する軽量なソリューションの方向性 18
  11. © 2024 Finatext Holdings Ltd. • カバー率 vs 誤検知率のトレードオフ •

    検知ジョブのパフォーマンス • セルフサービス化 出てきた課題 19
  12. © 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
  13. © 2024 Finatext Holdings Ltd. 検知ジョブのパフォーマンス問題 →gitleaksはデフォルトだとGitリポジトリの全履歴をスキャンするのでクローンもスキャンも遅い →スキャン対象をプッシュされた差分のみに プラットフォームチームが全ての検知結果をハンドルするのはスケールしない Finatextでは、開発チームがより広範囲のレイヤーにオーナーシップを持って、機動的に開発できるのが望ましい

    状態としてプラットフォームの開発を行ってきた。Secrets scanningも認知不可を上げず、開発効率を落とさ ず、開発チームがドライブできるべき →検知結果の見せ方とハンドリングをより良い形で設計しセルフサービス化 Active Secrets Scanningにおける誤検知以外の課題 25
  14. © 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
  15. © 2024 Finatext Holdings Ltd. • デフォルトでは目立つPRコメントで「該当箇所」、「取るべきアクションを解説している社内wikiページへ のリンク」の両方を通知 • GitHub

    Checks APIによる控えなUIもオプションでできるように ◦ PRコメントは良くも悪くも目立つので邪魔になることもありそう ◦ Checks API経由だとPRの "Checks" タブか "Files changed" タブを開かないと見えないのがデメリッ ト セルフサービス: 検知結果の見せ方 27
  16. © 2024 Finatext Holdings Ltd. • CIジョブがOpsgenieというアラート管理サービスにアラートを作成 ◦ アラートは優先度低めに設定 •

    OpsgenieのSlackインテグレーションによってSlackにアラート通知 ◦ プラットフォームチームはアラートが流れてくるチャンネルを監視している • 開発者はSlackに通知されているアラートをまずはackして検知結果が問題ないかの確認と対応 ◦ PRコメントのアクションガイドから辿れる社内wikiページに「Slackに通知されているアラートを見て ackして対応する」内容が書いてありゼロ知識でもアクションできるように • 開発者は対応が終わったらアラートをクローズ • プラットフォームチームは対応が漏れているアラートを定期的に拾って確認・対応とクローズ セルフサービス: 検知結果のハンドリング 30
  17. © 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
  18. © 2024 Finatext Holdings Ltd. Secrets scanningをいい感じにできるようにしたぞ!公開ベータ中のGitHub "organization-wide required workflows"

    を利用していて、secrets scanningのジョブもこの上で全リポジトリで動かすぞ!! →2023年10月に公開ベータ卒業に伴いFinatextでは利用できない状態に リポジトリは700以上あるのでうまい方法を取る必要がある CIジョブどこで動かすか問題 32
  19. © 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
  20. © 2024 Finatext Holdings Ltd. Organization-wide required workflowsはGitHubのチームプランでも利用できていたが、公開ベータ卒業後の rulesetset workflowsではエンタープライズプラン以上専用に...

    GitHubは重点的に活用していて開発者以外でも利用していたりでライセンス数が多く、チームプランとエンター プライズプランの料金のギャップが大きい 2021年までと現在ではコストへの意識が変化 →金利上昇・高止まり局面 →日本はさらに円安トレンド Post-zero Interest Rate Policy (post-ZIRP) 36
  21. © 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
  22. © 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
  23. © 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
  24. © 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
  25. © 2024 Finatext Holdings Ltd. Filtering Based On Repository Metadata

    43 https://github.com/Finatext/orgu/blob/v0.1.0/src/events.rs