Управление доступами к сайту и бизнес-системам
Практическая инструкция по ревизии учётных записей, ролей, MFA, сервисных ключей и прекращению доступа сотрудников.
Задача — понимать, кто и почему может войти в каждую систему, менять данные и пользоваться административными функциями. Контроль доступа проверяют не только по настройкам кабинета, но и по реальным сценариям.
1. Составьте реестр учётных записей
Видны должны быть и сотрудники, и технические интеграции.
- Перечислите CMS, серверы, панели хостинга, DNS, почту, CDN, CRM, облако, Git и интеграции — вместе с ответственным владельцем.
- Запишите для каждой учётной записи роль, систему, владельца, основание доступа и дату последнего подтверждения.
- Выделите технические аккаунты, API-токены, SSH-ключи, доступы подрядчиков и аварийные учётные записи.
- Не включайте в реестр пароли, приватные ключи, резервные коды MFA и другие секреты: храните лишь ссылку на защищённое хранилище.
2. Ограничьте полномочия по задачам
Роль «администратор» не должна быть настройкой по умолчанию.
- Составьте матрицу: кто читает данные, кто редактирует, кто публикует, кто меняет пользователей и настройки.
- Разделите личные рабочие аккаунты и привилегированные доступы; исключите общие пароли для всей команды.
- Проверьте ограничения на стороне сервера и API, а не только скрытие кнопок в интерфейсе.
- Для подрядчика задайте необходимый минимум прав и плановую дату пересмотра; лишние полномочия удаляйте.
3. Укрепите вход и восстановление доступа
Особенно защищайте владельца системы, DNS, почту и администраторов.
- Включите MFA для привилегированных и удалённых доступов; где возможно, предпочтите устойчивые к фишингу методы.
- Проверьте, кто может сбрасывать пароль и отключать MFA и какие дополнительные подтверждения требуются.
- Для критических действий настройте повторную проверку личности, безопасные сроки сессий и прекращение сессии после выхода.
- Заранее определите аварийный порядок восстановления, проверьте его и не храните резервные коды рядом с основными данными входа.
4. Управляйте жизненным циклом доступа
Самый частый организационный пробел — права после смены роли или увольнения.
- При приёме сотрудника доступ выдаётся по заявке и согласованной роли, а не копируется без проверки с другого пользователя.
- При переводе на новую должность прежние роли удаляются, а не только добавляются новые.
- При увольнении или завершении работ подрядчика отключите сессии, токены, ключи, групповые приглашения и переадресации, которые больше не нужны.
- Фиксируйте владельца решения и подтверждение закрытия доступа, а для общих секретов выполняйте замену, если они могли быть известны ушедшему сотруднику.
5. Проверяйте интеграции и сервисные ключи
API и автоматизации требуют такого же контроля, как люди.
- Каждому интеграционному ключу назначьте владельца, назначение, область действия и безопасное место хранения.
- Ограничьте срок жизни и права токенов там, где это поддерживается, настройте безопасную ротацию и отзыв.
- Разделяйте рабочие и тестовые среды, не переносите продуктивные секреты в открытые репозитории или отчёты.
- Проверяйте события использования сервисных ключей и заранее планируйте отмену доступа при компрометации.
6. Проведите контрольную ревизию
Ценность проверки — в списке закрытых рисков и подтверждённых действий.
- Выберите периодичность пересмотра в зависимости от риска и изменений команды; универсальный срок для всех систем не существует.
- На тестовой роли проверьте, что недоступная операция действительно запрещается сервером, а закрытый доступ нельзя обойти прямым URL.
- Отдельно проверьте доступы без владельца, давно не использовавшиеся привилегии и учётные записи бывших сотрудников.
- Результат оформите как: объект → владелец → обнаруженный избыток прав → ответственный → дата исправления → повторная проверка.
- OWASP ASVS 5.0.0 — управление аутентификацией и сессиями
- CISA — рекомендации по MFA, правам и защите малого бизнеса
Редакционный материал, октябрь 2026 года. Конкретные параметры и применимость рекомендаций определяются риском, договором и требованиями к вашей системе.