Роли и права в SSP Enterprise
Вопрос, который решает, работает ли общее хранение на самом деле, — не «кто главный?». Это «кто может двигать деньги?» — и в хорошо построенной системе это разные вопросы с разными ответами.
SSP Enterprise отвечает на них в двух отдельных местах. Административные полномочия живут в записях организации, где их можно выдавать и отзывать, как любое другое право. Полномочия на расходование живут в адресе хранилища, где так нельзя. Эта статья — полная карта и того и другого, включая случаи, в которых люди удивляются чаще всего.
Если вы не читали обзор того, как складываются организации и хранилища, SSP Enterprise: мультиподписные хранилища для команд — материал, предшествующий этому.
Две системы, намеренно
Роль организации управляет рабочим пространством: приглашение людей, создание хранилищ, изменение настроек, чтение аудиторского журнала. Это запись в базе данных. Измените её — и изменение действует немедленно.
Роль хранилища управляет одним конкретным хранилищем, и одно из её трёх значений — подписант — означает, что ваш публичный ключ входит в то, как был выведен адрес этого хранилища. Это нельзя изменить, отредактировав что-либо. Изменить это можно только созданием другого хранилища по другому адресу и переносом средств.
Практический вывод и самая важная фраза этой статьи: владелец организации, не являющийся подписантом хранилища, не может тратить из этого хранилища. Ни с доступом к панели, ни с доступом к базе данных, ни при содействии SSP. Адрес не знает, что такое владелец.
Роли организации, точно
Четыре роли, строго упорядоченные.
| Возможность | Владелец | Администратор | Участник | Наблюдатель |
|---|---|---|---|---|
| Читать хранилища, активность, аудиторский журнал | Да | Да | Да | Да |
| Приглашать новых людей | Да | Да | Только если организация это разрешает | Нет |
| Менять роль участника или наблюдателя | Да | Да | Нет | Нет |
| Менять роль другого администратора | Да | Нет | Нет | Нет |
| Менять настройки организации | Да | Да | Нет | Нет |
| Передать владение, удалить организацию | Да | Нет | Нет | Нет |
| Покинуть организацию | Нет — сначала передайте | Да | Да | Да |
Три детали из этой таблицы стоит вынести отдельно.
Администраторы не могут трогать других администраторов. Администратор может повышать, понижать и удалять участников и наблюдателей, но в момент, когда целью становится другой администратор, операция отклоняется. Это сделано намеренно: один скомпрометированный аккаунт администратора не сможет тихо разобрать остальной административный слой.
Приглашения от участников — переключатель на уровне организации. По умолчанию приглашать — возможность администратора. Организация может разрешить это и участникам: полезно для больших команд, где онбординг не должен стоять в очереди за двумя людьми, и лучше оставить выключенным, если вам нужен узкий периметр.
Владелец не может уйти. Владелец ровно один, и выход — сначала передать владение кому-то другому. Это предотвращает режим отказа, при котором в организации не остаётся никого, способного выполнять операции, доступные только владельцу.
Роли хранилища, точно
Три роли, и их область — одно хранилище, а не организация.
Администратор хранилища управляет хранилищем: его политиками, настройками уведомлений, его наблюдателями. Администратор хранилища не обязательно подписант, и администратор хранилища, не являющийся подписантом, не может одобрить предложение.
Подписант держит один из ключей в схеме M-из-N хранилища. Подписанты составляют предложения и одобряют их. Их публичный ключ находится в адресе.
Наблюдатель хранилища видит балансы, предложения и историю, не имея возможности что-либо составить или одобрить. Полезно для аудиторов, бухгалтеров и всех, кому нужна видимость без полномочий.
Поскольку роли хранилища назначаются на хранилище, один человек может быть подписантом операционного хранилища и лишь наблюдателем казначейского. Это нормальная и здоровая схема: она даёт повседневные права на расходование тем, кому они нужны, оставляя резерв за другим, меньшим комитетом.
Приглашения идут к идентичностям, а не в почтовые ящики
Приглашение в SSP Enterprise адресовано WK-идентичности — мультиподписной идентичности 2-из-2, выведенной из чьих-то SSP Wallet и SSP Key, — а не адресу электронной почты.
Это свойство безопасности, а не неудобство. Адрес электронной почты может быть скомпрометирован, переслан или набран с опечаткой и попасть в чужие руки. WK-идентичность может предъявить только тот, у кого есть оба устройства этого человека, а значит, приглашение не примет тот, кто случайно прочёл сообщение.
Отсюда два следствия. Во-первых, приглашаемому нужен настроенный SSP, прежде чем он сможет присоединиться; пути «зарегистрируйтесь из письма-приглашения» нет по замыслу. Во-вторых, приглашения аудируемы так, как почтовые приглашения не бывают, потому что принятие — подписанное действие.
Истёкшие приглашения не удаляются. Они хранятся бессрочно, потому что «кого пригласили и кто так и не присоединился» — именно тот вопрос, который аудит задаёт месяцы спустя. Ни у чего в аудиторском следе нет срока жизни.
Что требует повторной подписи
Некоторые операции слишком весомы, чтобы авторизовать их сессионной cookie. Тринадцать из них требуют повторной подписи двумя вашими устройствами в момент действия, в том числе:
- Передача владения организацией
- Удаление организации
- Исключение участника
- Смена корпоративной почты в аккаунте
Здесь важна механика. Челлендж для подписи генерирует сервер — никогда клиент, — и челлендж привязан к конкретному действию, конкретной цели и метке времени. Подпись, перехваченная в одной операции, не может быть воспроизведена в другой.
Каждая попытка логируется навсегда, включая неудачные. Череда неудачных попыток критических действий сама по себе является сигналом, который стоит иметь в записях.
Где фиксируются изменения ролей
Каждое изменение прав пишется в аудиторский журнал организации: выдача и отзыв ролей, приглашения выданные, принятые, отклонённые и отозванные, присоединения и уходы участников, исключения и передачи владения. Изменения на уровне хранилища получают собственные события — добавленные или удалённые подписанты и наблюдатели, правки политик, смены статуса хранилища.
Аудиторские записи постоянны. Нет ни срока хранения, ни задачи очистки, потому что ценность аудиторского следа целиком в тех частях, потребность в которых никто не предвидел. Организация, обнаружившая проблему в ноябре, хочет запись за март.
Как спроектировать раскладку ролей
Несколько схем, которые держатся на практике.
Отделите администратора от подписантов. Пусть руководитель операций держит администрирование организации, чтобы управлять людьми и настройками хранилищ, не помещая свой ключ в казначейский адрес. Тогда административное удобство не несёт риска хранения.
Щедро выдавайте роли наблюдателя финансовой функции. Доступ на чтение дешёв и делает сверку возможной, не расширяя круг тех, кто может тратить. Нет причин, чтобы бухгалтер был подписантом.
Держите казначейский комитет меньше операционного. Резерв 3-из-5 и операционное хранилище 2-из-3 — распространённое и разумное разделение: у денег, которых вы касаетесь ежедневно, планка одобрения ниже, чем у тех, которых вы касаетесь раз в год. 2-из-2 против 2-из-3 и m-из-n разбирает, как думать о числах.
Определите порядок ухода до того, как кто-нибудь уйдёт. Убрать человека из организации — это смена роли; убрать его как подписанта — это новое хранилище и миграция средств. Запишите, что вы будете делать, и подтвердите, что оставшийся набор подписантов всё ещё берёт порог. Что будет, если один из ваших ключей скомпрометирован проходит по смежному сценарию.
Не считайте политики правами. Белые списки, временные блокировки и правила одобрения формируют то, что предлагается, но порог — единственное, что обеспечивает сеть. Проектируйте роли так, будто движка политик не существует, а затем добавляйте политики как улучшения процесса поверх.
Иерархию ролей легко выстроить правильно, если держать впереди один вопрос: какие из этих изменений требуют нового адреса, а какие — просто записи? Всё в слое организации — запись. Адресом является только набор подписантов.
