Реквизиты прокси в компании: выдача, ротация и отзыв доступа
Компания должна управлять реквизитами в пределах функций, которые реально поддерживает сервис. Если для аренды доступен только один общий комплект, команда документирует круг получателей и меняет его при утечке или изменении состава. Если платформа поддерживает раздельную выдачу, доступ разделяют по интеграциям и владельцам.
Главное за минуту
- Реестр получателей обязателен даже тогда, когда сервис выдаёт один общий комплект реквизитов.
- При увольнении или завершении проекта доступ отзывают поддерживаемым способом и проверяют старую конфигурацию.
- Область доступа документируют по фактическим возможностям выдачи и отзыва.
- Уход сотрудника завершён только после проверяемого удаления его доступа.
Назначьте владельца и область доступа
Для каждого комплекта укажите аренду или систему, делового и технического владельцев, получателей, дату выдачи и доступный способ отзыва. Не обещайте отдельные профили или выборочные права, если такой функции нет в платформе.
В реестре храните назначение, владельцев, список получателей, дату выдачи, срок пересмотра и поддерживаемый способ отзыва. Отдельный комплект для интеграции используйте только там, где платформа действительно умеет его выдавать; иначе явно документируйте область общего комплекта и последствия его смены.
Передавайте и храните безопасно
Передавайте реквизиты только авторизованному получателю по защищённому каналу и храните в предназначенном для секретов средстве. Не помещайте пароль в адрес страницы, параметры запроса, фрагмент URL, обычную почту, тикет, историю команд или снимок экрана.
Показывайте значение только авторизованному получателю и по возможности один раз, после чего оставляйте маску и поддерживаемое действие смены. Событие копирования не должно передавать само значение в аналитику. Не рекомендуйте URL-фрагмент как хранилище секрета: применяйте короткоживущий одноразовый канал выдачи с аутентификацией и не передавайте реквизиты через обычную почту, тикеты или скриншоты.
Свяжите ротацию с изменениями команды
При увольнении, завершении проекта, подозрении на утечку или изменении списка получателей выполните поддерживаемый отзыв либо смену общего комплекта. До изменения составьте список зависимых систем, а после него подтвердите новую конфигурацию и отказ старой.
Если платформа допускает безопасное перекрытие, сначала проверьте новый комплект на утверждённых зависимостях, затем отключите старый. При подозрении на утечку действуйте по аварийному порядку: немедленно закройте поддерживаемый доступ, уведомите владельцев и восстановите зависимости с новыми реквизитами. Не обещайте параллельную работу двух комплектов без подтверждения такой функции.
Проверьте завершение отзыва
Журналируйте выдачу, изменение круга получателей, смену и отзыв без записи самого значения. Отзыв считается завершённым только после проверки, что старая конфигурация получает отказ, а все утверждённые зависимости работают с новыми реквизитами.
В аудите достаточно безопасного идентификатора комплекта, автора действия, цели, канала, результата и причины отказа. Не записывайте само значение, его префикс или пригодный для подбора хэш. Просмотр реквизитов администратором должен быть исключением с явным основанием и отдельным событием.
Практический чек-лист
- 1Назначьте владельцев и ведите список получателей.
- 2Зафиксируйте поддерживаемый способ отзыва.
- 3Исключите реквизиты из URL, журналов и аналитики.
- 4Проверьте одноразовую выдачу и отсутствие секрета в аналитике.
- 5Отрепетируйте аварийный отзыв и восстановление зависимостей.
Источники и документы
Материал подготовлен по первичным, официальным и техническим источникам. Формулировки статьи являются самостоятельным изложением.