約9分で読めます
チームでアイデンティティを共有する：1 つのアイデンティティ、複数の人
チームは Identity Seed を共有することで CardanoWall のアイデンティティを共有できます。ただしそれは、保有する全員に完全な署名権と復号権を渡すことを意味し、部分的な無効化も個人単位の無効化もできません。
チームは CardanoWall のアイデンティティを共有できますが、アイデンティティを共有するということは Identity Seed（アイデンティティの種）を共有するということです。それより軽いやり方は存在しません。
シードを渡すのは、完全な委任です。これを保有する人は誰でも、そのアイデンティティとしてレコードに署名でき、そのアイデンティティ宛ての封印付きレコードを復号できます。CardanoWall は、別々のアカウントをまたいでもこのワークフローをスムーズに使えるようにできますが、1 つのシードを部分的・無効化可能・個人単位の権限へ変えることはできません。暗号の仕組みは、そのようにはできていないからです。
ですから、共有されたアイデンティティは、共有された権限こそが望むものである場合にだけ使ってください。
チームで共有するアイデンティティとは何か
それは、1 つの Label 309 アイデンティティを 2 人以上の人、または 2 つ以上のアカウントが使うことです。
Label 309 のアイデンティティは、単一の 32 バイトの Identity Seed を根としています。そのシードをインポートした人は誰でも、どのアカウントでも、どの互換ツールでも、同じ署名鍵と同じ受信鍵を再構築します。アイデンティティは 1 つの CardanoWall アカウントに結び付いていません。シードだけがそれを定義するからです。
報道機関なら、この方法で「Press Team」というアイデンティティを運用するかもしれません。上級編集者がアイデンティティを作成し、シードを保存し、信頼できるチャネルを通じて選ばれた同僚と共有します。各同僚はそのシードを自分のアカウントにインポートし、自分のパスキーで解錠します。その時点から、全員が同じ暗号的アイデンティティを保有することになります。
シードを保有する人は何ができるか
そのアイデンティティができることすべてです。シードは根であって、限定された権限ではありません。
保有する人は誰でも、次のことができます。
- そのアイデンティティとして新しい Label 309 レコードに署名する
- そのアイデンティティ宛ての封印付きレコードを復号する
- 解錠した後に、届いた封印付きレコードを読む
- シードを再びエクスポートして、さらに先へ共有する
- オープンソースの CLI など、別の互換ツールへアイデンティティをインポートする
- そのアイデンティティの受信アドレスをどこにでも公開する
これは、限定された権限と無効化ボタンを付けて誰かをワークスペースに招待するのとは違います。「読み取り専用」や「公開はできるが復号はできない」といった階層はありません。シードを保有することは、アイデンティティ全体を保有することです。
共有されたアイデンティティはどんなときに意味があるか
外の世界に、人ではなく役割を表す 1 つのアイデンティティを見せたいときです。
妥当なケースには、次のようなものがあります。
- 報道機関の受付アドレス
- 法務部門の証拠アイデンティティ
- セキュリティ開示の連絡先
- 監査委員会のアイデンティティ
- コンプライアンスチームのアイデンティティ
- 会社の記録用アイデンティティ
- 小規模プロジェクトの共有アイデンティティ
これらのいずれでも、外部に見えるアイデンティティは機能やチームを表しており、複数の人がその背後にいるという事実こそが要点です。
共有されたアイデンティティのリスクは何か
帰属が共有され、それとともに露出も共有されます。
複数の人が同じアイデンティティとして署名できる場合、外部の検証者に見えるのは 1 つの Ed25519 公開鍵だけです。どの人間がシードを使ったかは、チェーンには記録されません。それはチームが望むものそのものである場合もあれば、状況によっては実際の説明責任上の問題になる場合もあります。
ほかのリスクも、同じ根から生まれます。
- いずれか 1 人のメンバーが、意図的にであれ偶然にであれ、シードを漏らし得る
- 1 台の侵害された端末が、アイデンティティ全体を侵害し得る
- 退職したメンバーが、去った後もコピーを保持し続け得る
- そのアイデンティティに送られた封印付きレコードは、シードを保有する全員が読める
- 鍵のローテーションは用意されていない。鍵を変えることは、新しいアイデンティティへ移ることを意味する
共有された権限は機能しますが、その周囲には運用上の規律が必要です。
CardanoWall はこれをアカウントをまたいでどう扱うか
各アカウントが、共有されたアイデンティティの暗号化されたコピーを自前で保持します。
2 人（仮に Alice と Bob とします）が同じシードをインポートした場合、各アカウントは独自のアカウント・アイデンティティ間リンクと、独自の暗号化された保管庫を得ます。Alice のパスキーは Alice の保管庫を解錠し、Bob のパスキーは Bob の保管庫を解錠します。同じ暗号的アイデンティティが両方のアカウントに現れるだけで、両者の間にサーバー側で共有される状態はありません。
すでに存在するアイデンティティを紐付けるには、インポートする側が実際にシードを保有していることを証明しなければなりません。プロフィールやチェーンから誰でも読み取れる公開鍵を知っているだけでは足りません。リンクが作成される前に、アカウントはシードから導出された鍵で、一度きりのサーバーチャレンジに署名します。これにより、公開鍵を知っているだけのアイデンティティを誰かが紐付けることは防がれ、本物のシード保有者によるリンクは引き続き許されます。
表示ラベルは各アカウント内で非公開のままです。Alice はそのアイデンティティに「Press Team」というラベルを付け、Bob は「Intake」と付けるかもしれません。それらのラベルは各アカウントの暗号化された保管庫の中にあり、公開されるアイデンティティには決して現れません。ですからどちらのアカウントも相手のラベルを見ることはできず、データベースが侵害されてもそれらは一切明らかになりません。
課金もアカウント単位のままです。Alice が自分のアカウントから公開すれば、Alice のアカウントが支払います。共有の残高はありません。シードを持つ人なら誰でも公開できる以上、どんな残高も暗号的に強制できないからです。
共有されたアイデンティティを 1 人から無効化できるか
暗号的にはできません。相手がすでにシードを知ってしまった後は、なおさらです。
CardanoWall は、あるアカウントの保管庫からアイデンティティを削除すること、パスキーを削除すること、または特定のアカウントでアイデンティティを無効化することができます。これらは実際のサービス層の制御であり、ご自分が管理するアカウントにとっては意味があります。
しかしそのいずれも、誰かのパスワードマネージャー、印刷物、記憶、バックアップ、デスクトップツール、あるいは 2 つ目のアカウントにすでに存在するシードのコピーには届きません。32 バイトの知識は、取り消せないのです。
ですから、シードを保有していた誰かがもはや権限を持つべきでない場合、正直な対応は、新しいアイデンティティを作成して古いものを引退させることです。古いシードを再び秘密にできるかのように振る舞うことではありません。
共有されたアイデンティティの良い手順とは何か
シードを、その実態どおり、価値の高い共有秘密として扱ってください。
誰かが共有する前に、チームは次のことについて合意しておくべきです。
- 誰がシードを保有してよいか
- シードをどのように受け渡すか（対面か、エンドツーエンド暗号化か）
- 正本となるバックアップのコピーがどこにあるか
- 誰がアイデンティティをアカウントに追加してよいか
- どのパスキーが各アカウントの保管庫を解錠するか
- 誰がそのアイデンティティの下で公開してよいか
- 誰かが去ったときに何が起きるか
- いつアイデンティティを差し替えなければならないか
- 新しい公開鍵をどこで告知するか
インシデントや人事異動が、プレッシャーの下でその決断を迫る前に、これを書き留めておいてください。
チームはすべてに 1 つの共有アイデンティティを使うべきか
たいていの場合、そうではありません。
アイデンティティを分けておくと、ワークフローが整理され、被害が封じ込められます。ある会社は、セキュリティ開示用に 1 つ、法的証拠用に別の 1 つ、公開リリース用にもう 1 つ、内部監査用にさらに 1 つ、というようにアイデンティティを運用するかもしれません。
その分離は、影響範囲を限定します。1 つのアイデンティティが侵害されても、ほかのアイデンティティが自動的にその侵害を引き継ぐことはありません。また、各アイデンティティが明確で狭い目的を持つため、アドレス帳やホワイトリストモードについても考えやすくなります。
チームのメンバーが入れ替わるときはどうするか
新しいアイデンティティを作成してください。古いシードの知識は無効化できないため、きれいに区切ることだけが本当の解決策です。
共有されたアイデンティティが侵害されたとき、または以前の保有者がアクセスを失うべきときの手順は、次のとおりです。
- 新しいアイデンティティを作成し、その新しいシードを保存する
- その新しいシードを、引き続き保有すべきメンバーにだけ共有する
- 公開プロフィール、受信アドレス、連絡先を新しい鍵で更新する
- ご自分が管理するアカウントで古いアイデンティティを無効化する
- 古い受信アドレスの使用をやめる
- 必要に応じて、古いものを置き換える（
supersedes）レコードを新しいアイデンティティの下で公開する
古い鍵宛てにすでに送られた封印付きレコードは、かつて古いシードを保有したことのある全員（ローテーションで外そうとしているまさにその相手を含みます）が引き続き読める状態のままです。これは長期的な公開鍵に対して暗号化することの性質であって、パッチで直せるバグではありません。これを前提に計画してください。古いシードの共有を取り消せるかのように振る舞ってはいけません。
要点
チームで共有するアイデンティティは、強力であり、かつ大ざっぱです。
これにより、チームは複数のアカウントと端末をまたいで、1 つの公開された Label 309 アイデンティティを運用できます。しかしシードを持つ全員が完全な署名権と復号権を持ち、その権限を部分的に付与することも、ひそかに無効化することもできません。
本当に共有された権限を必要とする役割には、共有されたアイデンティティを使ってください。説明責任、分離、ローテーションのほうが重要な場合には、いつでも別々のアイデンティティを使ってください。