10倍すごいRBACは存在しない

最近、ほとんどの顧客が決して気づかないかもしれない、複雑なエンジニアリングの一部であるシンプルな機能を構築しました。Infisicalユーザーは、単一のフォルダへのアクセスを付与/拒否できるようになりました。これは、オールハンズミーティングで軽く触れられ、チェンジログに1行だけ記載されるような類のものです。 RBAC、パーミッション、認可は、請求、スキーママイグレーション、監査ログと同じクラスのエンジニアリングプロジェクトです。それらは、ユーザーができるだけ時間をかけずに済ませたい、期待されるユーティリティです。それらは、シンプルに見えても、トリッキーなエンジニアリングプロジェクトです。最良のケースは、苦情がなく、システムが正しいことです。決して際立つことはありません。Twitterで人々が絶賛するような10倍すごいRBACシステムは存在しません。アクセス制御は、製品がチェックを入れるボックスですが、キラー機能ではありません。だからといって、それらが重要でないわけではありません。エンタープライズバイヤーは、それなしでは注文書に署名しません。そして、Infisicalが属するカテゴリの1つであるシークレット管理において、アクセスを間違えると、誰かが本来見えないはずの認証情報を見てしまったり、サービスがシークレットへのアクセスを失ったために顧客のデプロイメントが深夜3時に失敗したりします。TailscaleとOsoは、なぜ認可が予想以上に難しいのかについて書いています。フォルダベースのアクセスを構築したことで、私も異なる方向から同じことを学びました。 なぜフォルダアクセスを構築したのか 概念的には、RBACはシンプルです。人間または機械の各IDは、パーミッションを伴うロール（例: 管理者、メンバー、ゲスト）を持ちます。 アクション: 何ができるか サブジェクト: そのアクションを何に対して実行できるか。 CASLを使用しており、ロールにアタッチされた基本的なパーミッションは次のようになります。 JSON { "action": ["readValue", "create"], "subject": "secrets", "conditions": { "environment": "staging" } } このIDは、ステージング環境でシークレットを読み取り、作成できます。CASLは、明示的に許可されていないものはすべて自動的に拒否します。上記のパーミッションを持つロールは、本番環境のシークレットに決して触れることはできません。 ロールベースのアクセスが人気があるのは、人間が直感的に理解できるからです。RBACのロールは、チーム内のロールとマッピングされ、権限を一括で付与/拒否することは、各チームメンバーのパーミッションを手動で設定するよりも時間を節約します。これにより、アクセス制御がフルタイムの仕事になってしまいます。しかし、すべてのアクセス制御の変更がロールと完全に一致するわけではありません。フォルダベースのアクセスを構築した理由には、2つの特別なケースがあります。 チーム内で唯一Netsuiteの経験を持つエンジニアを考えてみてください。彼はNetsuiteインテグレーションを構築するという特権を与えられています。彼はエンジニアロールの認証情報とNetsuiteの認証情報が必要です。他のケースでは、特定のロールから権限を剥奪する必要があります。AWS Lambda関数をリファクタリングするために連れてこられた専門の契約者は、エンジニアリングの認証情報が必要ですが、彼に財務データを見せる理由はありません。彼はエンジニアロールの認証情報が必要ですが、請求データの認証情報は不要です。これらの両方のケースで、誰かのロールは変更されませんが、そのアクセス要件は変更されます。 従来のRBACでこれを解決すると、2つの不満な選択肢が得られます。 エンジニアロールを編集すると、不要なアクセスが付与されるか、必要なアクセスが削除されます。 エンジニアに基づいた変更されたカスタムロールを作成すると、1回限りのユースケースのために並列構成が作成され、ドリフトにつながる可能性があります。 Infisicalでは、「追加権限」と呼ばれる3番目のオプションがありました。これはフォルダベースのRBACが現在置き換えているものです。これはロールの上に座る、個人ごとの付与でした。それは機能しましたが、複雑すぎました（付与できるすべての可能なパーミッションが表示されました）し、権限を減らすことはできませんでした。これは強力でしたが、直感的ではありませんでした。Infisicalのすべての概念、データ階層、および特定のインスタンスの設定を理解する必要がありました。すべてのユーザーにこれを期待することはできないため、追加権限は2つの失敗モードのリスクがありました。 ユーザーは、プロビジョニングしたい権限を誤設定し、過剰または過小なアクセスを提供する可能性があります。 ユーザーは、「そんな時間はない」と言って、より広範なアクセスを付与し、セキュリティ体制を危険にさらす可能性があります。 追加権限はパスを文字列として格納しており、フォルダの名前を変更すると壊れていました。フォルダにはfolderID UUIDがあるため、フォルダの名前を変更したり、別の環境に移動したりしても、フォルダベースのアクセス付与は壊れません。 ユーザーにとって直感的なソリューションが必要でした。フォルダは適切な場所でした。なぜなら、デフォルトのフォルダ構造を一切出荷しないからです。フォルダが存在する場合、ユーザーはその理由と中身を知っています。なぜなら、彼らがそれを置いたからです。フォルダベースのRBACは、ユーザーの心の中でのアクセス問題をInfisicalの設定に変換することを簡素化します。 ユーザー側の結果はシンプルですが、既存のモデルを拡張するだけでは済まなかったため、エンジニアリング作業は複雑でした。 なぜRBACシステムが拡張するには複雑すぎたのか フォルダにのみ機能する別のアクセス付与方法を追加することはできませんでした。なぜなら、シークレットへのアクセス方法がすでに多数存在するからです。Infisicalでアクセスを定義するいくつかの方法を次に示します。 ユーザーはプロジェクトに直接メンバーになることができ、機械IDも同様です。 グループがメンバーシップを保持し、人間と機械の両方のIDを含めることができます。これらはしばしばSCIM、SAML、OIDC、またはLDAPから到着します。 ロールは組み込みまたはカスタムで構築できます。 非推奨のサービストークンは、まだ評価中の別のスコープモデルを持っています。 これは乱雑に見えるかもしれませんが、ほとんどのRBACシステムは、顧客からの多くの「はい」の要求の後に複雑さを蓄積します。Infisicalはオープンソースであるため、自己ホスト型インスタンスで問題を引き起こす可能性なしに、これらを非推奨にすることはできません。 シークレットもミッションクリティカルであるため、間違いはダウンタイムを引き起こしたり、エンジニアリング組織を停止させたりする可能性があります。また、SpiceDBやOpenFGAのようなZanzibarスタイルのシステムに移行しなかったためでもあります。それらを採用することは、すべてのパーミッションチェックを書き直し、すべての自己ホスト型顧客に別のステートフルサービスを実行させ、破壊的な変更を導入することを意味します。 私たちが構築するどのようなアクセスシステムも、すでに存在するすべてのものと連携する必要がありました。それは、このプロジェクトを2つのフェーズで取り組む必要があったことを意味します。 まず、パーミッションを標準化する必要がありました。次に、正しいパーミッションを適用するロジックです。後者の方が難しいエンジニアリング問題でしたが、前者はそのための基盤でした。 構築した5つの標準パーミッションティア まず、5つのティアのパーミッションのリストを構築しました。これらは、一般的な読み取りおよび書き込みパーミッションよりもカスタムですが、非常に直感的です。 ティア | 追加するもの ---|--- List | シークレットの値や名前を表示するだけで、それらが存在することを確認できます。 Read | 値を読み取り、コミット履歴を表示し、動的シークレットのリースを取得します。 Edit | シークレットやインポートの作成、編集、削除を行います。 Manage | ローテーション、動的シークレット、同期、ハニートークンを設定します。 Full Access | 他の人にフォルダへのアクセスを付与します。 これらのパーミッションは、フォルダベースのアクセスの実装のビルディングブロックです。技術的には、フォルダベースのRBACは追加権限として保存されます。それらはadditional_privilegesテーブルの行として存在し、ユーザーのIDや付与が一時的であるかどうかなどの一部の列を再利用します。この機能は2つの新しい列を導入します。 roleは上記のテーブルからの権限ティアです。 folderIDは、付与が付与されるフォルダです。 レガシーな追加権限では、どちらかの新しい列がnullになり、新しいフォルダベースの付与と区別されます。これにより、追加権限は既存のユーザーに対して引き続き機能しますが、一部のチェックにより、いずれかのモデルを使用しようとする行がないことが保証されます。 これにより、フォルダベースの権限が設定されました。次に、それらの権限を適用するために必要なロジックが来ました。 フォルダベースのアクセスを「勝たせる」こと フォルダに明示的にアクセスを設定することは、ロール、グループ、その他の権限から継承されたすべてを上書きします。これは簡単ではありませんでした。なぜなら、それを構築する理由全体が、IDのロールが付与するアクセスと、それが持つべきアクセスとの衝突だからです。IDは、オブジェクトへのアクセスが複数の場所で構成されている可能性があるため、フォルダベースのアクセス付与が常に優先されるようにする必要がありました。 CASLチェックでは、最後に一致したルールが勝ち、拒否は許可よりも優先されます。そのため、すべての既存システムを機能させ続けるために、フォルダアクセスを分離しました。