RBACに10倍の革新はない——Infisicalがフォルダ単位の権限管理を再構築した方法

There is no 10x RBAC

RBACに10倍の革新はない——Infisicalがフォルダ単位の権限管理を再構築した方法

Infisicalは、ユーザーが個別のフォルダへのアクセスを許可・拒否できるフォルダベースのRBACを導入した。既存のロール、グループ、追加権限が複雑に絡み合う中、Zanzibar系システムへの移行なしに、5段階の権限階層とCASLのdenyルールを組み合わせて実現。フォルダ名変更や移動でも壊れないよう、プロジェクト単位のバージョンカウンタでキャッシュ無効化も解決した。

RBAC、権限、認可は、課金、スキーママイグレーション、監査ログと同じクラスのエンジニアリングプロジェクトだ。それらは期待されるユーティリティであり、ユーザーはできるだけ時間をかけたくない。そして、見た目が単純でも厄介なエンジニアリングプロジェクトなのだ。
  1. sandeepkd

    私が見てきた限りでは、この問題はもっと注目されるべきです。現実には、ほとんどの場所でアクセスルールが内部から見るとかなりオープンになっています。これは、集中化(AuthZedのようなソリューションを使う)と分散化(ビジネスドメインに基づいてローカルでチェックをスキップする)が健全な緊張関係を生む領域であり、効率的に機能させるにはビジネスドメインの専門知識を持つ人が必要です。

  2. jzelinskie

    このような記事を読むのが大好きです。なぜなら、認可がかつてほどニッチではないことを示しているからです。また、オンプレミスで動作するエンタープライズソフトウェアを出荷する際に依存関係を避けることにも共感します。AuthZed/SpiceDBを設立する前、Quayでエンタープライズ顧客にサービスを提供していたとき、私たちはPostgresを大いに乱用していました。エンジニアとして、専用システムを使うべき適切なタイミングや、自社開発への投資を続けるべきかを判断するのはあなたの仕事です。

    彼らの設計がZanzibar/SpiceDBの概念と類似していることに気づかずにはいられません。それは素晴らしいことです!また、既存のシステムがもはや実行可能でなくなった状況(エンジニアが去るか、新しい設計制約により再考が必要になる)に遭遇した場合、専用ソリューションに簡単に移行できることも意味します。

    この記事で認められていないトレードオフの1つは、ツールチェーンの犠牲です。専用ソリューションには、CI/CDに統合できるデバッグと正確性を証明するためのツールチェーンがあり、自家製ソリューションは通常、自分たちのために素晴らしいツールチェーンを構築する時間を割くことができません。

  3. bbkane

    私はRBACの専門家ではないからかもしれませんが、フォルダのデータモデルを理解するのに苦労しました。フォルダは主体(subject)なのでしょうか?そして、レイヤーが互いに上書きする階層化されたCASLがあるのでしょうか?そしてユーザーはアクターなのでしょうか?

この日のほかの記事

2026-09-11