「10倍の生産性を出すRBAC」なんて存在しないという現実

RBAC（ロールベースアクセス制御）において、魔法のように開発速度を10倍に引き上げるような銀の弾丸は存在しません。複雑な権限管理を設計する際、過度に最適化を追い求めるよりも、運用負荷とセキュリティのトレードオフを正しく理解し、シンプルに保つことがエンジニアにとっての唯一の正攻法です。

この記事、すごく楽しめたよ。冒頭にある通り、RBACは必要だけど地味な存在だよね。Infiscalは使ってないけど、この記事はかなり勉強になった。シェアしてくれてありがとう！

https://casl.js.org/v7/en/ (https://casl.js.org/v7/en/) のリンクが切れてるよ。

追記：直ったみたいだね

セキュリティ機能、ひいてはセキュリティチーム全般に言えることだと思う。結局、いざという時にいないと気づかれる存在っていうか。

こういう記事を読むのが大好きだ。認可というものが、昔ほどニッチじゃなくなったことを示してるからね。オンプレミスのエンタープライズ向けソフトウェアを出荷する際、依存関係を避けたくなる気持ちもよくわかる。Quayでエンタープライズ顧客にサービスを提供していた頃、AuthZed/SpiceDBを創業する前は、Postgresを散々こき使っていたよ。エンジニアの仕事は、専用システムを導入すべきタイミングと、自前で投資を続けるべきタイミングを見極めることだ。

設計思想がZanzibarやSpiceDBのコンセプトに似ているのは間違いないね。それは素晴らしいことだよ！つまり、もし将来的に既存のシステムが立ち行かなくなったとしても（エンジニアが去ったり、設計上の制約で作り直しが必要になったりした場合）、専用ソリューションへ簡単に移行できるということだから。

ただ、この記事で触れられていないトレードオフが一つある。それはツールの犠牲だね。専用ソリューションにはCI/CDに統合できるデバッグや正当性証明用のツールチェーンがあるけれど、自作のソリューションでそこまで作り込む時間を捻出するのはなかなか難しいから。

で、なんでZanzibarを使わないの？