Команда и доступы
Работа большой организации
Enterprise помогает организовать доступ для нескольких команд, продуктов и окружений.
Базовая модель
Организация объединяет участников, оплату и лимиты.
Рабочие пространства отделяют проекты.
Ключи API привязаны к рабочим пространствам.
Роли помогают разделить, кто может управлять настройками, ключами, участниками и оплатой.
Роли
Owner управляет всей организацией, участниками, оплатой, рабочими пространствами, ключами, аудитом и логами.
Admin управляет командой, рабочими пространствами, ключами, аудитом, использованием и логами, но не управляет оплатой.
Developer видит только выданные рабочие пространства и может управлять своими личными ключами.
Finance видит выданные рабочие пространства, оплату, использование и аудит, но не управляет ключами и не читает подробные запросы.
Владельцы и администраторы видят все рабочие пространства. Для Developer и Finance доступ к рабочим пространствам задаётся отдельно.
Приглашения и offboarding
Владелец или администратор создаёт приглашение по email и выбирает роль.
Для Owner и Admin рабочие пространства не выбираются: эти роли видят всю организацию.
Для Developer и Finance владелец или администратор выбирает рабочие пространства. По умолчанию выбран текущий workspace, чтобы случайно не выдать доступ ко всем проектам.
Gateway отправляет письмо со ссылкой приглашения. Если SMTP временно недоступен, приглашение всё равно создаётся, а ссылку можно скопировать и отправить вручную. Ссылка показывается один раз, а принять её может только пользователь с тем же email.
Перед принятием приглашения пользователь видит название организации, роль и назначенные рабочие пространства. После принятия дашборд переключается на приглашённую организацию.
При удалении участника Gateway отзывает его личные ключи, убирает доступ к рабочим пространствам и снимает владельца с сервисных ключей. Историческая аналитика по уже выполненным запросам сохраняет снимок владельца ключа на момент запроса.
Аудит и аналитика
События управления командой, приглашениями, рабочими пространствами и ключами попадают в аудит организации. В таблице аудита Gateway показывает email участника, если пользователь известен системе; технический id остаётся запасным вариантом.
Аналитика по участникам строится по личным ключам. Сервисные ключи отображаются отдельно, потому что они принадлежат приложению, а не конкретному человеку.
Рекомендации
- Создавайте отдельное пространство на крупный продукт или клиента.
- Не используйте один ключ для всех приложений.
- Используйте личные ключи для разработки и отладки.
- Используйте сервисные ключи для production-приложений.
- Давайте ключам понятные имена.
- Отзывайте доступ при уходе сотрудника или закрытии проекта.
- Разделяйте боевые и тестовые окружения.
Большая команда
Для большой команды обычно заранее договариваются:
- кто владелец организации;
- кто управляет оплатой;
- кто создаёт ключи;
- кто разбирает логи;
- кто отвечает за безопасность.
Так меньше риск случайно удалить ключ, открыть лишний доступ или потерять источник нагрузки.