SSP Enterprise の役割と権限
共同カストディが実際に機能するかどうかを決める問いは、「誰が責任者か」ではありません。「誰が資金を動かせるか」です——そして、よく作られたシステムではこの二つは別の問いであり、別の答えを持ちます。
SSP Enterprise はそれらを二つの別々の場所で答えます。管理上の権限は組織のレコードに宿り、他のあらゆる権限と同じように付与・剥奪できます。支払いの権限は Vault のアドレスに宿り、そちらはできません。この記事は両方の完全な地図です——人がもっとも驚きがちな場面も含めて。
組織と Vault がどう噛み合うかの概観をまだ読んでいなければ、SSP Enterprise：チームのためのマルチシグ Vault がこの前に来る記事です。
二つのシステム、意図的に
組織の役割はワークスペースを統べます。人を招待し、Vault を作り、設定を変え、監査ログを読む。これはデータベースのレコードです。変えれば、変更は即座に効きます。
Vault の役割は特定の Vault を統べます。そしてその三つの値のうち一つ——署名者——は、あなたの公開鍵がその Vault のアドレスの導出方法の一部であることを意味します。これは何かを編集して変えられるものではありません。別のアドレスに別の Vault を作り、資金を移すことによってのみ変わります。
実務上の帰結、そしてこの記事でもっとも重要な一文。ある Vault の署名者ではない組織オーナーは、その Vault から支払えません。 ダッシュボードへのアクセスがあってもできず、データベースへのアクセスがあってもできず、SSP の協力があってもできません。アドレスは「オーナー」が何かを知らないのです。
組織の役割、正確に
四つの役割、厳密な序列で。
| できること | オーナー | 管理者 | メンバー | ビューア |
|---|---|---|---|---|
| Vault・アクティビティ・監査ログの閲覧 | 可 | 可 | 可 | 可 |
| 新しい人の招待 | 可 | 可 | 組織が許可した場合のみ | 不可 |
| メンバーやビューアの役割変更 | 可 | 可 | 不可 | 不可 |
| 他の管理者の役割変更 | 可 | 不可 | 不可 | 不可 |
| 組織設定の変更 | 可 | 可 | 不可 | 不可 |
| 所有権の移転・組織の削除 | 可 | 不可 | 不可 | 不可 |
| 組織からの離脱 | 不可——先に移転を | 可 | 可 | 可 |
この表の中で三つの細部は取り出しておく価値があります。
管理者は他の管理者に手を出せません。 管理者はメンバーとビューアを昇格・降格・除名できますが、対象が別の管理者になった瞬間に操作は拒否されます。これは意図的です。ひとつの侵害された管理者アカウントが、管理層の残りを静かに解体できないということです。
メンバーによる招待は組織レベルのスイッチです。 既定では招待は管理者の権能です。組織はメンバーにも許可することを選べます——受け入れ作業が二人の後ろに行列を作るべきでない大きめのチームには有用で、境界を狭く保ちたいならオフのままにする価値があります。
オーナーは去れません。 オーナーはちょうど一人であり、退出は先に所有権を他の誰かへ移転することです。これは、オーナー限定の操作を実行できる人が誰もいなくなるという障害を防ぎます。
Vault の役割、正確に
三つの役割。適用範囲は組織ではなく単一の Vault です。
Vault 管理者は Vault を管理します。ポリシー、通知設定、ビューアの管理です。Vault 管理者は必ずしも署名者ではなく、署名者でない Vault 管理者は提案を承認できません。
署名者は Vault の M-of-N のうち一本の鍵を保持します。署名者は提案を起草し、承認します。その公開鍵はアドレスの中にあります。
Vault ビューアは残高・提案・履歴を見られますが、起草も承認もできません。監査人、経理、そして権限なしに可視性を必要とするすべての人に有用です。
Vault の役割は Vault ごとなので、同じ人が運用 Vault では署名者、トレジャリー Vault ではビューアだけ、ということができます。これは正常で健全な配置です。日々の支払い権限を必要な人に与えつつ、準備金を別の、より小さな委員会の背後に置けます。
招待はメールボックスではなくアイデンティティへ届く
SSP Enterprise の招待は、メールアドレスではなく WK アイデンティティ——誰かの SSP Wallet と SSP Key から導出される 2-of-2 マルチシグのアイデンティティ——に宛てられます。
これは不便ではなくセキュリティ上の性質です。メールアドレスは侵害されうるし、転送されうるし、打ち間違いで他人の手に渡りうる。WK アイデンティティは、その人の 2 台の端末を持つ者だけが提示できます。つまり、招待はたまたまメッセージを読んだ人には受諾できません。
二つの帰結が生じます。第一に、招待する相手は参加する前に SSP を設定しておく必要があります。「招待メールからサインアップ」という経路は、意図的に存在しません。第二に、招待はメール招待にはない形で監査可能です。受諾が署名された行為だからです。
期限切れの招待は削除されません。無期限に保持されます。「誰が招待され、参加しなかったのか」は、まさに監査が数か月後に問う類の質問だからです。監査証跡の中に寿命を持つものはありません。
何が再署名を要するのか
一部の操作は、セッション Cookie で認可するには重すぎます。そのうち 13 の操作は、実行するその瞬間に 2 台の端末での再署名を要求します。たとえば次のものです。
- 組織の所有権の移転
- 組織の削除
- メンバーの除名
- アカウントの企業メールアドレスの変更
ここでは仕組みが重要です。署名すべきチャレンジを生成するのはサーバーであり、決してクライアントではありません。しかもチャレンジは、特定の操作、特定の対象、そしてタイムスタンプに結び付けられています。ある操作から取得された署名を別の操作へ再生することはできません。
あらゆる試行が恒久的に記録されます。失敗も含めてです。失敗した重要操作の試行が連続するパターンは、それ自体、記録に残しておく価値のあるシグナルです。
役割の変更はどこに記録されるのか
権限のあらゆる変更は組織の監査ログに書かれます。役割の付与と剥奪、発行・受諾・拒否・取り消しされた招待、メンバーの参加と離脱、除名、そして所有権の移転。Vault レベルの変更は独自のイベントを持ちます——署名者やビューアの追加と削除、ポリシーの編集、Vault のステータス変更。
監査記録は恒久的です。有効期限も掃除ジョブもありません。監査証跡の価値は、必要になると誰も予想しなかった部分に丸ごと宿るからです。11 月に問題を発見した組織が欲しいのは、3 月の記録です。
自分の役割配置を設計する
実務で持ちこたえるいくつかの型。
管理者と署名者を分けてください。 運用リーダーに組織管理者を持たせて人と Vault 設定を管理させ、その鍵はトレジャリーのアドレスに入れない。そうすれば管理上の便益はカストディのリスクを伴いません。
財務機能にはビューア役割を惜しみなく渡してください。 読み取りアクセスは安価で、支払える人の集合を広げずに照合を可能にします。経理担当者が署名者である理由はありません。
トレジャリーの委員会は運用の委員会より小さく保ってください。 3-of-5 の準備金と 2-of-3 の運用 Vault は、よくある理にかなった分け方です。毎日触るお金は、年に一度触るお金より承認のハードルが低くてよい。2-of-2、2-of-3、m-of-n の比較が数字の考え方を扱います。
誰かが去る前に離脱手順を決めてください。 誰かを組織から外すのは役割の変更です。署名者から外すのは新しい Vault と資金の移行です。どちらを行うかを書き出し、残る署名者の集合が依然としてしきい値を満たすことを確認してください。鍵の 1 本が侵害されたらどうなるかが隣接するシナリオをたどります。
ポリシーを権限として扱わないでください。 許可リスト、タイムロック、承認規則は「何が提案されるか」を形づくりますが、チェーンが強制する唯一のものはしきい値です。ポリシーエンジンが存在しないものとして役割を設計し、その上にプロセス改善としてポリシーを載せてください。
役割の階層は、ひとつの問いを頭の前に置いておけば簡単に正しく決まります。これらの変更のうち、どれが新しいアドレスを必要とし、どれが単なるレコードなのか。組織レイヤーにあるものはすべてレコードです。アドレスであるのは署名者の集合だけです。
