Общие командные идентичности: одна идентичность, много людей

Команда может пользоваться общей идентичностью CardanoWall, но поделиться идентичностью значит поделиться Identity Seed (сидом идентичности). Более лёгкого варианта здесь не бывает.

Передать сид — это полное делегирование. Любой, кто им владеет, может подписывать записи от лица этой идентичности и расшифровывать запечатанные записи, адресованные ей. CardanoWall может сделать работу с несколькими отдельными аккаунтами удобной, но не может превратить один сид в частичные, отзываемые, привязанные к конкретному человеку полномочия. Криптография так не гнётся.

Поэтому используйте общую идентичность только тогда, когда общие полномочия — это именно то, что вам нужно.

Что такое общая командная идентичность?

Это одна идентичность Label 309, которой пользуется больше одного человека или аккаунта.

Идентичность Label 309 укоренена в едином 32-байтовом Identity Seed. Любой, кто импортирует этот сид, восстанавливает тот же ключ подписи и те же ключи получателя — в любом аккаунте и в любом совместимом инструменте. Идентичность не привязана к одному аккаунту CardanoWall, потому что её определяет один лишь сид.

Редакция может вести так идентичность «Пресс-служба». Главный редактор создаёт идентичность, сохраняет сид и передаёт его выбранным коллегам по доверенному каналу. Каждый коллега импортирует сид в свой аккаунт и разблокирует его своими passkey (ключами доступа). С этого момента все они владеют одной и той же криптографической идентичностью.

Что может делать каждый держатель сида?

Всё, что может делать идентичность. Сид — это корень, а не ограниченное право.

Каждый держатель может:

• подписывать новые записи Label 309 от лица идентичности;
• расшифровывать запечатанные записи, адресованные идентичности;
• читать входящие запечатанные записи после их разблокировки;
• снова экспортировать сид и передавать его дальше;
• импортировать идентичность в другой совместимый инструмент, например в открытый CLI;
• публиковать адреса получателя этой идентичности где угодно.

Это не похоже на приглашение в рабочее пространство с ограниченными правами и кнопкой отзыва. Здесь нет уровня «только чтение» или «публиковать, но не расшифровывать». Владеешь сидом — владеешь всей идентичностью.

Когда общая идентичность имеет смысл?

Когда внешний мир должен видеть одну идентичность, представляющую роль, а не человека.

Разумные случаи:

• адрес приёма обращений редакции;
• идентичность для свидетельств юридического отдела;
• контакт для раскрытия уязвимостей;
• идентичность аудиторского комитета;
• идентичность команды комплаенса;
• идентичность для корпоративных записей;
• общая идентичность небольшого проекта.

В каждом из них публичная идентичность представляет функцию или команду, и то, что за ней стоит несколько человек, — это и есть смысл.

В чём риски общей идентичности?

Атрибуция становится общей, а вместе с ней — и уязвимость.

Если несколько человек могут подписывать от лица одной идентичности, сторонний верификатор всегда видит лишь один открытый ключ Ed25519. Блокчейн не фиксирует, кто из людей воспользовался сидом. Это может быть ровно тем, чего команда и хочет, — или реальной проблемой подотчётности, в зависимости от ситуации.

Остальные риски следуют из того же корня:

• любой участник может слить сид — намеренно или случайно;
• одно скомпрометированное устройство способно скомпрометировать всю идентичность;
• бывший участник может сохранить копию после ухода;
• каждую запечатанную запись, отправленную идентичности, может прочитать любой держатель сида;
• ротации ключей здесь нет: сменить ключи — значит перейти к новой идентичности.

Общие полномочия работают, но требуют операционной дисциплины вокруг них.

Как CardanoWall справляется с этим между аккаунтами?

Каждый аккаунт хранит свою зашифрованную копию общей идентичности.

Если два человека — назовём их Алиса и Боб — импортируют один и тот же сид, каждый аккаунт получает свою связку «аккаунт — идентичность» и своё зашифрованное хранилище. Passkey Алисы разблокируют хранилище Алисы; passkey Боба — хранилище Боба. Одна и та же криптографическая идентичность просто появляется в обоих аккаунтах, без общего состояния на стороне сервера между ними.

Чтобы привязать уже существующую идентичность, тот, кто её импортирует, должен доказать, что действительно владеет сидом, — а не просто что знает открытые ключи, которые любой может прочитать из профиля или из блокчейна. Аккаунт подписывает одноразовый серверный запрос-вызов ключом, производным от сида, прежде чем связка будет создана. Это не даёт привязать идентичность тому, кто знает только её открытые ключи, и при этом позволяет связать её настоящему держателю сида.

Отображаемые метки остаются приватными для каждого аккаунта. Алиса может пометить идентичность как «Пресс-служба»; Боб — как «Приём обращений». Эти метки живут внутри зашифрованного хранилища каждого аккаунта, а не в публичной идентичности, поэтому ни один аккаунт не видит метку другого, а утечка базы данных не раскроет ни одной из них.

Биллинг тоже остаётся отдельным для каждого аккаунта. Если Алиса публикует из своего аккаунта, платит аккаунт Алисы. Общего баланса нет, потому что никакой баланс нельзя было бы обеспечить криптографически, когда публиковать всё равно может любой, у кого есть сид.

Можно ли отозвать общую идентичность у одного человека?

Криптографически — нет, по крайней мере после того, как он уже узнал сид.

CardanoWall может удалить идентичность из хранилища аккаунта, удалить passkey или деактивировать идентичность в конкретном аккаунте. Это реальные средства управления на уровне сервиса, и они важны для тех аккаунтов, которыми вы управляете.

Но ни одно из них не достанет копию сида, которая уже лежит в чьём-то менеджере паролей, на распечатке, в памяти человека, в резервной копии, в десктопном инструменте или во втором аккаунте. Знание 32 байт нельзя отозвать.

Поэтому, если человек, владевший сидом, больше не должен иметь полномочий, честный ход — создать новую идентичность и вывести старую из обращения, а не делать вид, что старый сид можно снова сделать секретным.

Какова хорошая процедура для общей идентичности?

Относитесь к сиду как к ценному общему секрету, которым он и является.

Прежде чем кто-либо им поделится, команде стоит договориться о том:

• кому разрешено владеть сидом;
• как сид передаётся (лично или со сквозным шифрованием);
• где находится авторитетная резервная копия;
• кто может добавлять идентичность в аккаунт;
• какие passkey разблокируют хранилище каждого аккаунта;
• кому разрешено публиковать от лица идентичности;
• что происходит, когда кто-то уходит;
• когда идентичность необходимо заменить;
• где объявляются новые открытые ключи.

Запишите это до того, как инцидент или кадровые перемены вынудят принимать решение под давлением.

Стоит ли команде использовать одну общую идентичность для всего?

Обычно нет.

Отдельные идентичности держат рабочие процессы в чистоте и ограничивают ущерб. Компания может вести одну идентичность для раскрытия уязвимостей, другую — для юридических свидетельств, третью — для публичных релизов, четвёртую — для внутренних аудитов.

Такое разделение ограничивает радиус поражения. Если одна идентичность скомпрометирована, остальные не наследуют компрометацию автоматически. Оно также облегчает понимание адресной книги и режима белого списка, поскольку у каждой идентичности есть ясное, узкое назначение.

Что делать при ротации команды?

Создать новую идентичность. Знание старого сида нельзя отозвать, поэтому чистый разрыв — единственное настоящее решение.

Когда общая идентичность скомпрометирована или когда бывший держатель должен лишиться доступа, порядок действий такой:

1. создайте новую идентичность и сохраните её новый сид;
2. поделитесь новым сидом только с теми участниками, у кого он по-прежнему должен быть;
3. обновите публичные профили, адреса получателя и контакты новыми ключами;
4. деактивируйте старую идентичность в аккаунтах, которыми вы управляете;
5. прекратите использовать старые адреса получателя;
6. при желании опубликуйте от лица новой идентичности запись, которая замещает старую.

Запечатанные записи, уже адресованные старому ключу, остаются читаемыми для всех, кто когда-либо владел старым сидом, — включая того, от кого вы уходите при ротации. Это свойство шифрования на долгоживущий открытый ключ, а не баг, который можно залатать. Планируйте с учётом этого; не делайте вид, что старый сид можно «забрать обратно».

Коротко

Общие командные идентичности — мощный, но грубый инструмент.

Они позволяют команде вести одну публичную идентичность Label 309 в нескольких аккаунтах и на нескольких устройствах. Но каждый, у кого есть сид, обладает полным правом подписи и расшифровки, и это право нельзя выдать частично или тихо отозвать.

Используйте общую идентичность для ролей, которым действительно нужны общие полномочия. Используйте отдельные идентичности всякий раз, когда подотчётность, разделение или ротация важнее.

Что почитать дальше

• Ваша идентичность — это сид
• Активна, деактивирована, удалена: жизненный цикл идентичности
• Как CardanoWall хранит вашу идентичность
• Идентичности для деликатной работы: свидетельства информатора
• Стандарт, в открытом доступе: label309.org и открытый исходный код на github.com/cardanowall