Делегированный доступ
Пригласите разработчика, передайте выставление счетов бухгалтеру, откройте клиенту доступ только для чтения к его собственным сайтам или позвольте нашей службе поддержки изучить проблему. Каждое предоставление доступа представляет собой роль с четко определенными правами, ограниченную рамками организации, обеспечиваемую на уровне базы данных и фиксируемую в журнале аудита с защитой от изменения.
Совместное использование одного логина — это путь к проблемам с доступом к аккаунту. В Zinn Digital® у каждого пользователя есть собственная учетная запись, а доступ представляет собой членство (пользователь, организация и роль), которое можно предоставлять, изменять или отзывать независимо.
Каждый соавтор входит под своей учетной записью через Keycloak, наш уровень идентификации. Никто не вводит ваш пароль, никто не использует общую сессию браузера, а удаление участника выполняется одним действием, избавляя от необходимости менять пароль и срочно выяснять, кто еще его знал.
Учетные записи имеют иерархическую структуру: организацией реселлера управляются клиентские организации, а клиентскими организациями — сайты. Членство распространяется на организацию и все подчиненные ей элементы, поэтому вы можете предоставить клиенту-агентству контроль над его собственной организацией, не открывая доступ к остальным вашим клиентам.
Изоляция клиентов — это не фильтр в коде приложения, который можно случайно пропустить из-за ошибки. Функция Row-Level Security в Postgres ограничивает каждый запрос деревом организации вызывающего объекта, поэтому запросу за пределами вашей зоны видимости просто нечего возвращать.
Запросите организацию или сайт за пределами вашей зоны ответственности, и API ответит обычной ошибкой отсутствия, а не ошибкой доступа. Ошибка доступа подтвердила бы существование записи; ошибка отсутствия ничего не говорит постороннему лицу.
Права доступа представляют собой детальные ключи — модуль плюс действие, такие как sites.restart или billing.refund, а роли объединяют их. Четыре роли охватывают потребности реальных команд, и каждая из них является данными, которые мы заносим в базу, а не логикой, скрытой в коде.
Полный контроль: создание дочерних организаций, приглашение и удаление участников, изменение ролей, управление ключами API, создание, перезапуск, очистка, приостановка и удаление сайтов, управление биллингом и выставлением счетов, создание тикетов и чтение журнала аудита. Роль, которую вы оставляете за собой.
Видит организацию, ее участников и каталог планов, а также управляет счетами, способами оплаты и начислениями. Не имеет доступа к созданию, изменению или удалению отдельных сайтов — именно то, что нужно внешнему бухгалтеру.
Просматривает и создает сайты, перезапускает службы, очищает кэш, управляет ключами API и работает с тикетами. Намеренно исключено: выставление счетов, счета-фактуры, способы оплаты, управление участниками, приостановка и удаление сайтов. Подрядчик может заниматься разработкой, не имея возможности выставлять вам счета или что-либо уничтожать.
Видит организацию, ее участников, ее сайты, ее выставление счетов, каталог тарифов, тикеты, статус перевода и журнал аудита — но ничего из этого не может изменить. Подходящие права для клиента, которому нужна прозрачность, аудитора или заинтересованного лица, которому требуется только просмотр.
Делегирование доступа безопасно только в том случае, если учетные записи, которым вы делегируете права, надежно защищены от взлома. Аутентификация для каждого пользователя в аккаунте и на любой платформе осуществляется через Keycloak.
Работа службы поддержки иногда требует заглянуть внутрь вашего аккаунта. Этот доступ регулируется той же моделью разрешений, что и все остальное: сотрудники просто состоят в организации персонала, распределенной по отделам с ограниченными правами.
Сотрудники распределены по категориям: Поддержка, Биллинг и финансы, Злоупотребления и доверие с безопасностью, Продажи, Ввод в курс дела, Инженерия и операции, Маркетинг и Управление. Каждая роль предоставляет доступ к определенным модулям и действиям, поэтому агент видит только ту часть панели администратора, которая необходима для его работы, и ничего лишнего.
Роль агента поддержки предоставляет именно это: просмотр клиентов, просмотр тикетов и ответы на них, просмотр сайтов, перезапуск сайта и очистка его кэша. Она не включает настройку биллинга, возврат средств, изменение планов и управление парком серверов. Действия по устранению неполадок, которые может выполнять агент, ограничены этой ролью, а не его добрыми намерениями.
Раз разрешение customer.impersonate не входит в роль Менеджера, оно доступно только Суперпользователю. Когда сеанс запущен от вашего имени, в панели управления отображается постоянный баннер олицетворения, поэтому всегда очевидно, кто именно выполняет действия.
Каждое действие с привилегиями или правами администратора заносится в неизменяемый журнал аудита, в котором фиксируются исполнитель, действие, объект, вспомогательные метаданные, IP-адрес и метка времени. В рабочей среде данные журнала разделяются по времени. Владельцы и участники с правами только для чтения могут самостоятельно просматривать журнал своей организации.
Выполнение конфиденциальных и потенциально опасных действий сотрудниками может требовать дополнительной аутентификации или одобрения двумя лицами перед их запуском, а создание новых отделов и ролей настраивается в конфигурации, а не требует изменения кода.
Скрипты, CI-пайплайны, интерфейс командной строки (CLI), провайдер Terraform и ИИ-агенты проходят аутентификацию по той же модели разрешений, что и люди: без общих учетных данных пользователей и без долгоживущих секретов, вставленных в сборку.
Ключи принадлежат организации и имеют детальные области видимости, привязанные к тем же правам RBAC: только чтение, выставление счетов, инициализация. Предоставьте конвейеру необходимую узкую область видимости вместо всей учетной записи участника.
Ключи тестового режима и рабочего режима различаются, поэтому интеграция на этапе разработки не сможет случайно получить доступ к рабочим данным из-за ошибки или скопированной переменной окружения.
Мы сохраняем SHA-256 хеш секретного ключа и префикс для поиска — сам ключ никогда не сохраняется. Ключ отображается только один раз при создании. Для каждого ключа отслеживается время его последнего использования, и его можно отозвать отдельно, не затрагивая остальные.
Наш сервер MCP позволяет любому агенту с поддержкой MCP управлять вашим хостингом на естественном языке, с аутентификацией по протоколу OAuth 2.1, с ограничением доступа в рамках вашей организации и роли RBAC, с токенами с возможностью отзыва для каждого инструмента, подтверждением деструктивных действий, лимитами расходов и полным журналом аудита.
Доступ к аккаунту и доступ к серверу — это разные задачи. Учетные данные на уровне сайта управляются в панели управления, выдаются по принципу наименьших привилегий и изолируются так, чтобы оболочка одного соавтора ограничивалась оболочкой одного сайта.
Одиночный оператор сохраняет одну организацию и одно членство владельца, а когда для работы над проектом привлекается подрядчик, добавляет роль разработчика. Когда проект завершается, членство удаляется, и вход в систему для него сразу же прекращается — не остается никаких общих учетных данных, которые нужно было бы ротировать.
Агентство использует иерархию организаций. Для каждого клиента создается дочерняя организация, содержащая его сайты, а сотрудники клиента получают в ней членство: с правами только для чтения для заинтересованного лица, которому нужна видимость, или владельца для клиента, предпочитающего самообслуживание. Ваши сотрудники имеют членство выше по дереву и видят портфолио целиком, в то время как клиент видит только свою ветку, и безопасность на уровне строк гарантирует это на практике, а не на словах.
Реселлер работает точно так же, но на уровень выше: организация-реселлер содержит клиентские организации, каждая из которых имеет собственные учетные записи участников, представление биллинга и сайты. Тот же базовый принцип лежит в основе субаккаунтов, команд агентств и иерархий реселлеров — для них не существует отдельного, урезанного механизма.
Всё доступно в течение 14-дневного пробного периода без привязки карты. Зарегистрируйтесь без ввода платежных данных, пригласите коллегию, посмотрите, к чему у каждой роли есть доступ, а к чему нет, и изучите собственный журнал аудита.
Сегодня членство предоставляет свою роль во всей организации и во всем, что находится ниже нее в иерархии, поэтому способ разделить наборы сайтов заключается в разделении организаций — поместите эти сайты в их собственную дочернюю организацию и предоставьте членство там. Это понятная модель для агентств и реселлеров, где у каждого клиента уже есть свои границы. Ограничение ресурсов на уровне членства, привязка конкретного членства к определенным сайтам в рамках одной организации, является запланированным доработкой, а не доступной в настоящее время функцией.
Роль разработчика не включает удаление или приостановку сайтов — эти ключи принадлежат роли владельца. Она предоставляет права на просмотр и создание сайтов, перезапуск служб, очистку кэша, управление ключами API и работу с тикетами. Права на развертывание и перенос в реальный режим также не входят в набор разработчика, поэтому продвижение в продакшн остается за владельцем аккаунта. Совместите это со стaging-средой, чтобы работы по сборке изначально выполнялись вне активного сайта.
Это полностью зависит от роли сотрудника, и каждая роль представляет собой узкий набор ключей разрешений. Служба поддержки, например, может просматривать вашу учетную запись и сайты, просматривать ваши тикеты и отвечать на них, перезапускать сайт и очищать его кэш, но не имеет доступа к настройкам биллинга, возвратам средств, тарифам или парку серверов. Вход в систему в качестве клиента — это отдельное разрешение, которым обладает только Супер-администратор, и в этом случае на панели управления отображается постоянный баннер олицетворения. каждое привилегированное действие записывается в журнал аудита с указанием субъекта, действия, цели, IP-адреса и метки времени, и вы можете самостоятельно просматривать журнал вашей организации.
Удалите участника, и его доступ к этой организации прекратится: у него сохранится собственная учетная запись, но в вашем аккаунте не останется ролей и прав. Ключи API отзываются по отдельности, поэтому ключ пайплайна можно отключить, не затрагивая ничего остального. Если вы используете единый вход SAML, девизионирование в вашем поставщике удостоверений управляет входом централизованно. Учетные данные уровня сайта, такие как ключи SSH, отзываются в панели управления, а сам процесс удаления фиксируется в журнале аудита.
Нет, но стоит чётко понимать почему. Ключи API принадлежат организации, а не отдельному участнику, и имеют собственные детально настраиваемые области видимости, привязанные к тому же каталогу разрешений. Поэтому вместо того, чтобы выдавать ключ конкретному человеку, вы создаете ключ для выполняемой задачи с минимально необходимыми для этой задачи правами и отзываете его по завершении работы. Сохраняется только хэш секретного ключа, а каждый ключ фиксирует время последнего использования, благодаря чему неиспользуемые ключи легко обнаружить и аннулировать.
Да. Наш MCP-сервер выполняет аутентификацию агентов с помощью OAuth 2.1, ограничивая их рамками вашей организации и вашей роли RBAC с помощью токенов с возможностью отзывания для каждого отдельного инструмента, поэтому вы предоставляете конкретную возможность, а не полный доступ. Для деструктивных действий требуется подтверждение, действуют лимиты расходов, а каждое действие попадает в тот же журнал аудита, что и действия людей.
Безопасность на уровне строк в Postgres ограничивает запросы поддеревом организации вызывающего объекта непосредственно в самой базе данных, причем фильтр на уровне приложения используется в качестве эшелонированной защиты, а не единственного рубежа. Запросы на получение записей вне зоны видимости возвращают статус «не найдено» вместо ошибки доступа, поэтому никакой информации о существовании объекта не раскрывается. На стороне сервера изоляция для каждого сайта с помощью CageFS ограничивает оболочку и файлы каждого арендатора пределами его собственного сайта.
Да. 14-дневный пробный период не требует привязки карты — никаких платежных реквизитов и обязательств — и распространяется на тариф Footprint-Free Hosting с возможностью размещения до пяти сайтов. Этого достаточно, чтобы пригласить коллегу, назначить роль и убедиться, что ограничения работают так, как вам нужно, до принятия окончательного решения.
Начните бесплатную 14-дневную пробную версию без привязки карты, пригласите коллегу и посмотрите, как работает модель разрешений: настраиваемые роли, отменяемые уровни доступа и журнал аудита, в котором четко указано, кто и что сделал.
Начать бесплатно