Control Plane 部 認証認可グループ（※1）のエンジニアリングマネージャーをしている先山(@ksakiayma134)です。
現在キャディは、CADDi Drawer と CADDi Quote といった複数のアプリケーションをお客様へ提供する「コンパウンド戦略（マルチプロダクト化）」を推し進めています。
こうした複数アプリケーションを展開するアプリケーションアーキテクチャでは、共通利用する機能をプラットフォームレイヤーとして切り出すことが一般的です。私たちも認証・認可機能をプラットフォーム化し、各アプリ開発者へ提供しています。
本記事では、現在のキャディの認証認可を支えているシステム群についてご紹介します。
Control Plane 部について
一般的な説明
まず、「Control Plane」という言葉について簡単に触れておきます。
一般的に SaaS アーキテクチャにおける Control Plane とは、AWS のホワイトペーパー等でも定義されている通り、「テナント（顧客）の管理」と「アプリケーションの機能」を分離した管理層のことを指します。
具体的には、テナントのライフサイクル管理（作成・削除）、認証・認可、課金、メトリクス集計など、すべてのテナントに横断的に適用される運用機能を担うシステム群です。これらをアプリケーション層（Application Plane）から切り出すことで、各アプリチームは純粋な機能開発に集中できるようになります。
認証認可グループの位置づけ
認証認可グループは、現在この Control Plane 部に所属しています。
これは「逆コンウェイの法則」を意識した組織設計です。つまり、システムの「ありたい姿（認証認可が独立したプラットフォームである状態）」を先に定義し、それに合わせて人員配置や組織構造を決定しました。
もともと認証認可グループは、CADDi Drawer の認証認可のみを責務としていました。しかし、コンパウンド戦略を遂行するにあたり、CADDi Drawer と密結合だったシステムを切り離し、独立して運用する必要があります。 すでに切り離しが完了したものもあれば、まだ密結合で疎になっていないものもあり、現在進行系で鋭意分離を進めているフェーズです。
Control Plane を支えるシステムたち
認証プラットフォーム
CADDi Drawer や CADDi Quote 等、全アプリの認証を支える共通基盤です。
以前は、すべてのアプリケーションが個別に nextjs-auth0 SDK を組み込み、それぞれが OIDC Client として機能する構成をとっていました。
この方法でもスケーラビリティは担保できますが、組織が拡大するにつれて以下のような課題が目立ってきました。
- 変更容易性の低下: 認証認可グループ側で基盤的な修正を入れたい場合、各アプリ側の設定変更やデプロイまで面倒を見なければならない。
- コミュニケーションコストの増大: 新規アプリの立ち上げ時、開発者が OIDC/OAuth2 のパラメータ（Callback URL や Scope 等）を深く理解していないと設定が完了せず、都度認証認可グループのサポートが必要になる。
- ライブラリ依存のリスク: 例えば nextjs-auth0 v4 のような破壊的な変更が入った際、各アプリチーム側でのバージョンアップ対応負荷が高く、統制が取りづらい。
そこで私たちは、各アプリが個別に OIDC フローをハンドリングするアーキテクチャをやめ、認証フローそのものを中央でコントロールする仕組み（Gateway/Proxy パターン）に切り替えました。 アーキテクチャのイメージとしては、OSS の oauth2-proxy に近いです。
また、この刷新に合わせて、システム内部では Auth0 のトークンではなく、CADDi 独自の Internal Token を利用するよう変更しました。これは、JWT の Claim（情報）を自分たちで柔軟にコントロールするためです。 外部 IDaaS である Auth0 に内部ロジックやデータを依存させると見通しが悪くなるため、Auth0 は「認証」に特化させ、複雑な「認可」情報は Internal Token へ寄せる判断をしました。
M2M Token Issuer
ユーザーの操作を介さないシステム間通信（System-to-System Call）や、バッチ処理などのワークロードに向けた仕組みです。
先の認証プラットフォーム刷新により、システム内部の API 認証は Internal Token に統一されました。そのため、ユーザー操作を伴わないワークロードであっても、同様に Internal Token を取得できる手段が必要になります。
そこで、OAuth2 の Client Credentials Flow を用いた、社内専用のトークン発行システム「M2M (Machine to Machine) Token Issuer」を開発しました。
現在はシンプルに client_id / client_secret を各ワークロードに配布して運用していますが、将来的にはこのような手動での鍵配布（アウトオブバンド運用）が不要な方式への移行を展望しています。 例えば OAuth 界隈でも OAuth SPIFFE Client Authentication がドラフトとして存在しているように、ワークロードの Identity をどう証明・管理するかという課題にも、認証認可グループとして積極的に向き合っていく予定です。
Tenant Platform
Control Plane の中核である「テナント管理」も、認証認可グループの重要な責務です。 現在、私たちはテナント情報（どの顧客が何のプランを利用しているか、どの機能オプションが有効か等）を Tenant Platform というシステムにて保管しています。
以前これらの情報は CADDi Drawer のデータベース内に格納されていましたが、独立したサービスとして分離し、CADDi Quote 等の他システムからも統一されたインターフェースで参照できる状態にしています。 こうしてデータを中央に集約することで、各アプリ開発チームが個別に似たような管理データを持つ必要がなくなります。
また重要な点として、ここには「マルチテナント SaaS を制御するための管理データ（Metadata）」のみを保存しており、お客様の業務データ（図面データ等）は保存していません。このように責務を明確に分離することで、お客様の保存するデータ領域（Data Plane / Application Plane）との境界線を明確に引くアーキテクチャを実現しています。
顧客のテナント管理UIシステム
お客様側の管理者（Administrator）のみが実行可能な操作を提供するフロントエンドアプリケーションです。 ユーザーの招待、権限（ロール）変更、アカウントブロックなどを行える画面等をホスティングしています。 このような管理画面は各アプリチームが独自に開発するのではなく、認証認可グループが提供する UI を利用することとしています。
まだ公開できないシステムたち
ここで紹介したもの以外にも、鋭意開発中のシステムや、まだ公開できないプロジェクトが複数動いています。
正直に申し上げますと、システムの分離はまだ完全ではありません。今でもレガシーな構成で残っているシステムは存在します。 切り離しを確実かつ安全に進めていけるような体制やプロジェクトを、着実に組成していく予定です。
また R&D の一環として、Google Zanzibar や昨今の認可技術の潮流（※2）を参考に、社内で利用可能な「汎用的な認可制御システム」の検証なども行っています。
We're hiring!
Control Plane 部では、現在バックエンドエンジニア、および認証認可エンジニアを絶賛募集中です！
現時点で OIDC や OAuth の深い知識がなくても、入社後にキャッチアップしていただければ問題ありません。 特定のプロトコルに詳しいことよりも、「スケーラブルなプラットフォームをどう設計・構築するか」という視点や、バックエンドエンジニアとしての汎用的な設計力を重視しています。
また、認証認可エンジニアの方にとっては、「自分たちで OIDC をスクラッチ実装できないから退屈」と思われるかもしれません。しかし、逆に言えば、認証のコアを Auth0 に任せることで、より高度な認可制御やプラットフォーム全体のアーキテクチャ設計にレバレッジを効かせられる環境でもあります。
技術スタックとしては、バックエンドでは Go を積極的に採用しており、サービスメッシュ層での認証制御なども行っています。
SaaS を支える共通基盤（Control Plane）という、攻めがいのある領域に興味がある方、ぜひ一度お話ししましょう。
カジュアル面談はこちらから！
- ※1: 社内では IAM (Identity and Access Management) Group という名称で活動しています。
- ※2: AWS の Cedar や SpiceDB などが台頭してきている印象を持っています。
