大規模データを扱うクラウドセキュリティプラットフォームのアーキテクチャ変遷

Findy社のアーキテクチャカンファレンス2024での登壇資料です。

Transcript

1. ©Cloudbase Inc. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 大規模データを扱う クラウドセキュリティプラットフォームの アーキテクチャ変遷 Cloudbase株式会社 CTO Miyagawa Ryotaro
2. 00 PROLOGUE 目次 ©Cloudbase Inc. 01 My Self 自己紹介 02 About Cloudbase Cloudbaseについて 03 Current Architecture 現在のアーキテクチャ 04 Architecture History アーキテクチャの変遷 05 Recruiting 採用情報
3. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 01 My Self 02 About Cloudbase 03 Current Architecture 04 Architecture History 05 Recruiting 自己紹介 ©Cloudbase Inc.
4. CTO 新卒で株式会社サイバーエージェントに入社 2022年3月 Levetty株式会社（現Cloudbase株式会社）入社 Cloudbaseの立ち上げから従事し、現在はプロダクト組織の統括 （マネジメント・採用・技術戦略）等を主に担当。 趣味は、クラフトビール、日本酒、焼酎 宮川 竜太朗（Miyagawa Ryotaro） 01 My Self 自己紹介 ©Cloudbase Inc.
5. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 01 My Self 02 About Cloudbase 03 Current Architecture 04 Architecture History 05 Recruiting Cloudbaseについて ©Cloudbase Inc.
6. 日本企業が 世界を変える 時代をつくる。 インターネットとクラウドの時代に、 日本のモノづくりは世界と戦えているだろうか。 クラウドネイティブな開発を阻害する、セキュリティリスクの問題。 この大きなカベを取り除くことによって、 日本企業は、本来のポテンシャルを解き放つことができると、私たちは考える。 その先にあるのは、日本の技術やサービスが世界をリードする未来だ。 この国を再び、世界の技術大国へ。 Cloudbaseは、そんな新しい時代のベースとなることを、ここに約束する。 02 About Cloudbase Our Mission ©Cloudbase Inc.
7. 会社名 Cloudbase株式会社 創業 2019年11年05日 代表者 代表取締役 岩佐晃也 社員数 約40名（2024年9月） 所在地 〒108-0073 東京都港区三田3-2-8 THE PORTAL MITA 2F 02 About Cloudbase 会社概要 ©Cloudbase Inc.
8. 誰でもセキュリティ高度人材並みのアウトプットを実現 人材不足・育成の課題を解消 包括的な継続監視 包括的な継続監視 危険なリスクを抽出 危険なリスクを抽出 即時対応が必要なリスク(β) 詳細を見る エクスポート エクスポート 即時対応リスク 178 -14 180 160 140 120 100 80 60 40 20 0 2024/01/07 01/14 01/21 01/28 02/04 02/11 02/18 02/25 03/03 設定ミス 詳細を見る エクスポート エクスポート CRITICAL 290 2 HIGH 1,254 35 MEDIUM 4,478 -120 LOW 1,578 0 1600 1400 1200 1000 800 600 400 200 0 2024/01/07 01/14 01/21 01/28 02/04 02/11 02/18 02/25 03/03 誰でも簡単にリスク修復 誰でも簡単にリスク修復 CVE-2022-22965 spring-framework: RCE via Data Binding on JDK 9+ 公開日 2021/12/10 19:15 最終更新日 2023/11/07 12:39 未解決 非対応にする 詳細 直し方 根拠 Cloudbaseによる脆弱性の解説 脆弱性解説ドキュメントを見る 修復が必要なリソース jmp-server リソースタイプ EC2 Instance クラウドアカウント aws-sandbox リージョン ap-northeast-1 リソースの詳細を見る AWSコンソールを開く 修復方法 下記のコマンドはスキャン結果から推測されたものです。お使いの環境によっては正常に動 作しない場合があります。事前にご確認の上、修復作業を実施してください。なお、アップ デートによる影響については保証いたしかねます。 パッケージを切り替える org.springframework:spring-beans org.springframework:spring-beans の修復方法 検出された脆弱性はOSパッケージ管理ツールである によって管理されているパッケージで あると推測されました。この脆弱性はEC2インスタンスで検出されているため、EC2インスタン スに接続して操作する必要があります。以下の手順に従って操作することで胎弱性を解消できま す。 apt 1 EC2インスタンスに接続します SSMを使用可能な場合は以下のコマンドで接続します（推奨） $ aws ssm start-session --target i-0786fab668c76f18b SSHを使用する場合は以下のコマンドで接続します $ ssh -i 鍵ファイルへのパス ec2-user@13.115.24.93 2 実際のパッケージのバージョンが検出されたバージョンと一致していることを 確認します 以下のコマンドを実行し、結果が 2.39-6.amzn2023.0.7 であることを確認してくださ い。 2.39-6.amzn2023.0.7 org.springframework:spring-beans の修復方法 検出された脆弱性はOSパッケージ管理ツールである によって管理されているパッケージで あると推測されました。この脆弱性はEC2インスタンスで検出されているため、EC2インスタン スに接続して操作する必要があります。以下の手順に従って操作することで胎弱性を解消できま す。 1 EC2インスタンスに接続します SSMを使用可能な場合は以下のコマンドで接続します（推奨） $ aws ssm start-session --target i-0786fab668c76f18b SSHを使用する場合は以下のコマンドで接続します $ ssh -i 鍵ファイルへのパス ec2-user@13.115.24.93 2 実際のパッケージのバージョンが検出されたバージョンと一致していることを 確認します 以下のコマンドを実行し、結果が 2.39-6.amzn2023.0.7 であることを確認してくださ い。 $ dpkg -l | grep binutils | awk '{print $3}' 3 パッケージをアップデートします 以下のコマンドを実行してください。 $ apt update && apt install --only-upgrade binutils 4 脆弱性が修正されているバージョンにアップデートされたことを確認します 以下のコマンドを実行し、結果が 2.39-6.amzn2023.0.9 以 上のバージョンであることを 確認してください。 02 About Cloudbase 提供サービス ©Cloudbase Inc.
9. 02 About Cloudbase 対応領域 ©Cloudbase Inc. クラウドセキュリティ 資産管理 設定ミス OSS脆弱性 アプリケーション脆弱性 WAF クラウド上のVMやID等を一元的に管理 言語パッケージに含まれる脆弱性 例: Log4Shell, regreSSHion 公開してはいけないサービスを公開していないか 例: 公開してはいけないS3を公開
10. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 01 My Self 02 About Cloudbase 03 Current Architecture 04 Architecture History 05 Recruiting 現在のアーキテクチャ ©Cloudbase Inc.
11. 03 Current Architecture アーキテクチャの外観 ©Cloudbase Inc. Scanner Guild „ 非同期Jobの実行基“ „ API経由でお客様環境にアクセスしクラウド上の
 リソースを取b „ 取得したデータからセキュリティリスクを検l „ Webのコンポーネントにデータを受け渡す Scanner 技術的な特性の違いによりGuildが構成されている。 Web Web Guild „ SaaSのUIを提供する基“ „ Scannerのコンポーネントで取得・検出されたデータ を表示す¼ „ タスク管理機能やチャット機能、通知機能なども提供
12. ©Cloudbase Inc. Cloudbaseのシステム特性
13. 03 Current Architecture データ品質 ©Cloudbase Inc. Scanner Guild お客様環境から取得するデータが少しでも不整合を起こすと セキュリティリスクの偽陽性・偽陰性が発生してしまう。 また複数種類のスキャンが実施される。 お客様環境から取得するデータが少しでも不整合を起こすと セキュリティリスクの偽陽性・偽陰性が発生してしまう。 また複数種類のスキャンが実施される。 Scanner Web Web Guild
14. 03 Current Architecture DB負荷 ©Cloudbase Inc. Scanner Guild Scanner Web ここのデータの書き込みがスキャンごとに発生する。 大きなデータが書き込まれることがあるので、スケールする必要がある。 ここのデータの書き込みがスキャンごとに発生する。 大きなデータが書き込まれることがあるので、スケールする必要がある。 Web Guild
15. 資産管理 設定ミス OSS脆弱性 ？？？ ・ ・ ・ 資産管理 設定ミス OSS脆弱性 ？？？ ・ ・ ・ 資産管理 設定ミス OSS脆弱性 ？？？ ・ ・ ・ 資産管理 設定ミス OSS脆弱性 ？？？ ・ ・ ・ 機能幅の拡充 対応クラウドの拡充 AWS Google Cloud Azure OCI 03 Current Architecture 機能幅 ©Cloudbase Inc.
16. 03 Current Architecture Scannerのjobのイメージ ©Cloudbase Inc. 03 Current Architecture Scannerのjobのイメージ ©Cloudbase Inc.
17. 03 Current Architecture プロダクトのシステム特性 ©Cloudbase Inc. データ品質 r お客様のクラウド環境から取得するデータが最重G r 取得するデータの種類が膨大 DB負荷 r セキュリティスキャンごとに数千件のデータ書き込‚ r アクセス数はSaaSのため多くない 機能幅 r マルチクラウド × 幅の広いセキュリティ分} r 今後さらなる拡張の可能性大
18. 03 Current Architecture プロダクトのシステム特性 ©Cloudbase Inc. データ品質 r お客様のクラウド環境から取得するデータが最重G r 取得するデータの種類が膨大 Webアプリケーションと連携しながら動作する 信頼性の高いデータパイプライン DB負荷 r セキュリティスキャンごとに数千件のデータ書き込s r アクセス数はSaaSのため多くない 書き込みのスパイクに耐えるスケーラビリティ 機能幅 r マルチクラウド × 幅の広いセキュリティ分² r 今後さらなる拡張の可能性大 マルチクラウド・多機能に対応できる スケーラビリティ
19. ©Cloudbase Inc. 組織体制・技術スタック
20. 03 Current Architecture 組織体制 ©Cloudbase Inc. Scanner Guild Web Guild Application Team Stream Aligned Team1 Stream Aligned Team2 QA Platform Team
21. 03 Current Architecture 技術スタック ©Cloudbase Inc. Scanner Guild Web Guild
22. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 01 My Self 02 About Cloudbase 03 Current Architecture 04 Architecture History 05 Recruiting アーキテクチャの変遷 ©Cloudbase Inc.
23. 04 Architecture History アーキテクチャの変遷 ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
24. 04 Architecture History アーキテクチャの変遷 ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
25. 04 Architecture History 〜4人時代の意思決定 ©Cloudbase Inc. Web Scanner 現在の原型となるアーキテクチャが整った
26. 04 Architecture History 〜4人時代の意思決定 ©Cloudbase Inc. アーキテクチャ d SaaS部分（現: Web）とセキュリティスキャン（現: Scanner）のシステム特性が大きく異なるため最初から分‘ d 人が少なくデプロイ独立性の担保が必要なかったので、スキャンからDBへのロードまでを一つのworkflowとして設計 → 当時はもっとシンプルだったが、この構成が今の原型となって引き継がれている 技術選定 d Web:Ÿ d Scanner: 垣根なく開発できるようにTypeScriptを選定。DBはRLSを加味してPostgreSQLに。 平行処理や複数のjobを組み合わせた構成が必要だったためgoを選択。 クラウドのメインはAWSを利用。job基盤は監視の観点からStepFunctionsを利用。 チーム d （当たり前だが）分けるほどの人数がいなかったので1チームで d なんとなくの暗黙の役割分担は一部あったが、基本全員で開発し全員でレビューを実施 全員野R
27. 04 Architecture History アーキテクチャの変遷 ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
28. 04 Architecture History 8人時代の課題 ©Cloudbase Inc. アーキテクチャ ‘ SaaS部分（現: Web）とセキュリティスキャン（現: Scanner）のシステム特性が大きく異なるため最初から分‚ ‘ 人が少なくデプロイ独立性の担保が必要なかったので、スキャンからDBへのロードまでを一つのworkflowとして設計 → 順調にjob基盤は拡大していったが大きな課題はなかった 組織 ‘ （当たり前だが）分けるほどの人数がいなかったので1チームで全員野 ‘ なんとなくの暗黙の役割分担は一部あったが、基本全員で開発し全員でレビューを実施 ‘ CTO1人で なり、取りまとめの方法の模索が必要になっB ‘ チーム内のコミュニケーションパスが増え、 ‘ 要求されるドメインやコンポーネントの知識が増え、 ‘ 各コンポーネントに対する になってきた 8人分の状況等を把握するのが困難に コミュニケーションが取りにくくなっB 認知負荷が高くなっB オーナーシップが不明瞭
29. 04 Architecture History 8人時代の意思決定 ©Cloudbase Inc. Scanner Team Web Team EM Scanner Web EM PdM SaaS部分（現: Web）とセキュリティスキャン（現: Scanner）の コンポーネントの境界で2チームに分割
30. 04 Architecture History 8人時代の意思決定 ©Cloudbase Inc. CTO1人で8人分の状況等を把握するのが困難になり、取りまとめの方法が必要になった → 各チームにEMと全体のPdMを配置することで情報の集約と意思決定のデリゲーションを実現 チーム内のコミュニケーションパスが増え、コミュニケーションが取りにくくなった → 日常的に話す人数が半分（4人程度）に 要求されるドメインやコンポーネントの知識が増え、認知負荷が高くなった 各コンポーネントに対するオーナーシップが不明瞭になってきた → ドメインやコンポーネントのオーナーが明確になりスコープが一定狭まったため、当時の課題はクリアできた SaaS部分（現: Web）とセキュリティスキャン（現: Scanner）の コンポーネントの境界で2チームに分割
31. 04 Architecture History アーキテクチャの変遷 ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
32. 04 Architecture History 15人時代の課題 ©Cloudbase Inc. 認知負荷 r さらに人数が増えてドメインが拡大し、再び認知負荷の課題が発生しU r 特にScannerチームで顕著に 事業フェーズの変化 r これまでは競合に追いつくフェーズだったためある程度作るものが決まっていU r 一定足りない機能が追いつき、機能の探索をすることになり、 r コミュニケーションコストが増大し、コンポーネントごとの分け方を することに チーム横断の仮説検証の機会が増えU 再度議論
33. 04 Architecture History 15人時代の課題と解決策 ©Cloudbase Inc. Scanner Guild Web Guild Application Team Stream Aligned Team1 Stream Aligned Team2 QA Platform Team 2チームから4チームへ。元のチームのつながりはGuildとして継続。
34. 04 Architecture History 15人時代の課題の解決策 ©Cloudbase Inc. 認知負荷 † さらなるチーム分割を実` † Scannerの認知負荷を下げることと品質の向上を目指してPlatformチームも組成 事業フェーズの変化 † Team Topologiesの考えを導入し技術領域を横断した体験にオーナーを持てるチームを組‹ † コンウェイの法則には従わずSaaS部分（現: Web）とセキュリティスキャン（現: Scanner）の大枠は変えない方針 スケールの仕組み化 † コンウェイの法則には従わない代わりに、各Guildで実装の標準化を実` † ガイドラインの策定、開発キットの実装、ボイラーテンプレートの共通Ô † 非機能面でのレビューは引き続きGuildで実施することでGuild内の品質を担保 → 結果論だがコンポーネントごとのチーム体制を取ったからこそ、ナレッジの蓄積と標準化まで実施できた
35. 04 Architecture History 15人時代の課題の解決策 ©Cloudbase Inc. 認知負荷 ƒ さらなるチーム分割を実f ƒ Scannerの認知負荷を下げることと開発生産性の向上を目指してPlatformチームも組成 事業フェーズの変化 ƒ Team Topologiesの考えを導入し技術領域を横断した体験にオーナーを持てるチームを組Ž ƒ コンウェイの法則には従わずSaaS部分（現: Web）とセキュリティスキャン（現: Scanner）の大枠は変えない方針 スケールの仕組み化 ƒ コンウェイの法則には従わない代わりに、各Guildで実装の標準化を実f ƒ ガイドラインの策定、開発キットの実装、ボイラーテンプレートの共通& ƒ 非機能面でのレビューは引き続きGuildで実施することでGuild内の品質を担保 → 結果論だがコンポーネントごとのチーム体制を取ったからこそ、ナレッジの蓄積と標準化まで実施できた 結果、元々の課題は解決され、大きな問題なくチームが機能している。 結果、元々の課題は解決され、大きな問題なくチームが機能している。
36. 04 Architecture History アーキテクチャの変遷 ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
37. 04 Architecture History ワークフローの分割とマイクロサービス化 ©Cloudbase Inc. すべてのワークフローの一元管理から キューを用いた非同期なアーキテクチャへ
38. Scanner Guild Web Guild Platform Team Stream Aligned Team2 Stream Aligned Team1 Application Team QA ・フロントエンドのガイドライン策定・デザインシステムの実装 ・バックエンドとフロントエンドの型の共通化 ・QAポリシーの策定 ※ モジュラーモノリス化やマイクロサービス化の予定はない ・開発キットの整備 ・QAポリシーの策定 ・品質クリティカルなコンポーネントのプラットフォーム化 ストリームアラインドチームが開発に集中できるように仕組みを整備中。まだまだこれからやっていき！ 04 Architecture History 実装の共通化など ©Cloudbase Inc.
39. 04 Architecture History 既存の体制の課題 ©Cloudbase Inc. デプロイ依存性 人数増加でデプロイ頻度が増えているが、それぞれのコン ポーネントを独立してデプロイできない ワークフローの分割とマイクロサービス化 非機能品質の担保 人数が増えコードの品質やシステムの信頼性を画一的に担保 することが難しくなってきた プラットフォーム化・実装の共通化・ガイドライン策定
40. ©Cloudbase Inc. 思考実験
41. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. 〜4人時代 全員で全部作る！ 8人時代 チーム構造を試行錯誤 15人時代 事業・組織フェーズにアジャスト これから アーキテクチャの進化
42. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. Ž ドメインや技術領域の難しさ故、当時はStream Alignedなチームにしなかっ‘ Ž 今思うとあるコンポーネントに対してチームが必ず責任を負うべきだという思想が強すぎたのかもしれなu Ž ストリームアラインドを2本作っても2つもやりたいことがなかった（どっちかが雑用係になった可能性がある） なぜStream Alignedにしなかったのか？
43. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. Scanner Team Web Team EM Scanner Web EM Platform Team Stream Aligned Team EM Platform Stream Aligned EM 実 際 仮 定
44. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. Scanner Team Web Team EM Scanner Web EM Platform Team Stream Aligned Team EM Platform Stream Aligned EM どちらのチームがどこまで加工するかが曖昧なため Loaderの責務が曖昧に・一気通貫の体験が作れない どちらのチームがどこまで加工するかが曖昧なため Loaderの責務が曖昧に・一気通貫の体験が作れない Platformは最低限の加工のみ Stream Alignedはより体験を最初から最後まで担当 Platformは最低限の加工のみ Stream Alignedはより体験を最初から最後まで担当 実 際 仮 定
45. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. Scanner Team Stream Aligned Guild? EM EM Platform Stream Aligned Stream Aligned EM Steam Alignedが早期に拡大していた可能性大 横軸施策を打つ意思決定ができずに独自の進化をしていた可能性も？ Steam Alignedが早期に拡大していた可能性大 横軸施策を打つ意思決定ができずに独自の進化をしていた可能性も？
46. 04 Architecture History what if: Scanner/Application以外の体制を取っていたら、、？ ©Cloudbase Inc. 起こりそうなこと q Platform/Stream Alignedに分l q Stream Alignedがどんどん人が増 え、Platformは増えて2人程j q Stream Alignedは分割の論点がより 早期に訪れそう メリット q 一気通貫の体験は実現しやす€ q Loaderの所有者が曖昧にならない デメリット q Stream Alignedの境界を早期に決 める必要があり失敗しそ³ q モノリスが共通認識なく独自に拡張 されてカオスを生むか、モジュラー モノリスなどを早期に検討する必要 があったかも
47. ©Cloudbase Inc. まとめ
48. 04 Architecture History まとめ ©Cloudbase Inc. u 正直ここまでの道のりが最適だったのかは分からないし、誰も正解を知ることはできなˆ u ちなみに15人の体制はこれ以上に良い形を思いついてなく、正解に近い自信があd u 結局は悩みながらもスピード感を持って決めて、
 選んだ道を組織みんなで正解にするための覚悟と実行、そして学習こそが正義 This is ！ 組織・アーキテクチャもプロダクトのように 。 意思決定 アジャイルに
49. Copyright ©Cloudbase Co., Ltd ALL Rights Reserved. 01 My Self 02 About Cloudbase 03 Current Architecture 04 Architecture History 05 Recruiting 採用情報 ©Cloudbase Inc.
50. 資産管理 ？？？ ・・・ 設定ミス OSS脆弱性 ？？？ ・ ・ ・ セキュリティドメインの拡充 クラウド利活用のための機能拡充 05 Recruiting 今後の展望 ©Cloudbase Inc. 今後さらなる事業拡大を計画中！
51. 05 Recruiting We’re hiring!! ©Cloudbase Inc. Entrance Bookにて 開発チームの詳細を公開中！
52. 05 Recruiting ブースのご紹介 ©Cloudbase Inc. ぜひブースに遊びに来てください！ クイズ実施中！ 問題 下記のAWSのアーキテクチャで発生しうるリスク についてマルバツで回答するクイズです！ 高得点者には先着で豪華景品が、、！？