Cerbos、散在する認可ロジックを一つのpolicy layerへ移した理由

認可を毎回つくり直す問題

Cerbosは2021年、Emre Baran、Alex Olivier、Charith Ellawalaによって創業された。

3人は各社でauthorizationを繰り返し実装してきた経験から、「一度、properlyに作れば、他のチームは同じ苦労をしなくてよい」という方向へ進んだ。

これは公式の創業説明に基づく要約である。出典

OSSのPDPからCloudへ

最初の賭けは、認可をアプリケーションコードから外し、policyとdecision pointとして切り出すことだった。

CerbosはGo製のPDP、YAMLで記述するpolicy、多言語のPEP integrationを組み合わせ、self-hostedでも動かせる土台を作った。出典

商用化の転機

2023年、CerbosはCerbos Cloudを立ち上げ、OMERS Ventures主導で$7.5Mのextended seedを調達した。

OSSのruntimeを配るだけでなく、policyの管理・配布とdecision logsを企業向けに扱う転機だった。出典

AI agent時代の認可へ

現在のCerbosは、人間だけでなくserviceとAI agentのactionをauthorizeするplatformとして位置づけられている。

公式サイトは、cloudからair-gappedまでの運用と、月20億件超のauthorization decisionsを説明する。

創業時の「散在した認可を一つの層へ移す」という選択が、agentの権限境界にもつながっている。出典

CerbosのPMFは、認可を各サービスのif文やidentity providerの設定に分散させたくない、セキュリティ・platform・IAMチームにある。

policyをアプリケーションから外出しし、ユーザー、service、AI agentの文脈を含むdecisionを一つのPDPで返すため、変更をコードdeployではなくpolicy更新として扱える。出典

特に監査と複雑な権限モデルが同時に必要な企業ほど、判断ログと自社運用の選択肢が効く。

公式サイトはcloud、self-hosted、on-premise、air-gappedを挙げており、規制産業にも導入余地がある。出典

Moatは、policy engineそのものより、複雑な認可をproductionで運用するためのpolicy model、decision logs、integration、標準対応の組み合わせにある。

AuthZENや多言語SDKを積み重ねるほど、既存policyの移行コストが参入障壁になる。出典

ネットワーク効果は中程度以下。

利用企業が増えてもpolicy decisionの価値は基本的に各社内に閉じるため、二面市場のような直接効果は弱い。

一方、OSS contributor、integration、policyの実例が増えるほど導入リスクが下がる間接効果はある。出典

主な対象は、複数サービス・tenant・roleを持つSaaSのplatform engineer、security engineer、IAM担当、そしてAI agentのaction境界を設計するチームだ。

単純なログインだけが必要な小規模アプリには過剰で、認可の監査可能性と変更頻度が高い組織に向く。出典

第一はauthorizationを独立したlayerとして設計したこと。

第二はGo製のopen-source PDPと複数言語のPEP integrationで、導入時の摩擦を下げたこと。

第三はCerbos Hubでpolicyの管理・配布を商用化し、OSS adoptionとenterprise運用を接続したことだ。出典

この分離により、開発者は認可判定を呼び出し、securityチームはpolicyをレビューできる。

役割を分けながら同じdecisionを見られる点が再現可能な強みになる。出典

最大のリスクは、認可基盤を追加すること自体が既存アプリの設計変更を要求する点だ。

policy language、PDPの可用性、identity情報の品質を同時に整えないと、中央集約が新しい運用負荷になる。出典

また、公式に大規模利用の数値は示されているが、売上・顧客数・有料conversionは公開されていない。

OPA、provider組み込み機能、商用authorization製品との比較で、Hubの差別化を継続的に証明する必要がある。出典

成長戦略は、OSS PDPをdeveloper workflowに置き、docsとGitHubで導入を始めてもらい、policyの共同管理や監査を必要とする段階でCerbos Hubへ広げるland-and-expand型だ。

2023年のCloudローンチとseed調達は、OSSからmanaged serviceへ進む意思を示した。出典

AI agentやMCPの認可を前面に出す現在の訴求は新しい需要を取り込めるが、従来のIAM・security文脈との一貫性が必要になる。出典

主要チャネル: open_source, developer_docs, GitHub, community, content_marketing, sales

認可は機能の一部として散らすより、独立したdecision layerにした方が変更と監査を扱いやすい。

重要なのは中央集約そのものではなく、policyを誰が読めて、どうtestし、どのdecisionを後から説明できるかまでを製品境界に含めることだ。出典

OSSを入口にする場合も、企業が最後に買うのはruntimeだけではない。

運用、配布、監査、責任分界を狭いworkflowに落とせるかが商用化の分岐になる。出典

日本では、金融・製造・医療など、組織階層と監査要件が重なる領域でexternalized authorizationの説明がしやすい。

roleだけでなく部署、契約、データ区分、端末状態を組み合わせるpolicyを、既存の認証基盤と分離して示すのが入口になる。

一方で、英語のpolicy運用と新しいPDP導入は障壁になる。

日本語の導入例、SIer向けのreference architecture、air-gapped環境の運用資料があれば、OSS採用から企業展開への距離を縮められる。出典