Ошибки людей: как настроить роли и запреты, чтобы “не удалить прод”

Надежность системы — это не только код, но и то, как люди с ней работают. Даже идеальная разработка не спасет, если любой сотрудник может удалить данные, поменять статусы “массово” или зайти в прод с правами администратора.

1) Принцип минимальных прав (least privilege)

Каждой роли — только нужные действия.
Типовой ориентир: менеджер не должен удалять данные, менять системные настройки, управлять правами и интеграциями.

2) Запреты на необратимые действия

Лучше “не удалять”, а “архивировать/отменять”:

• запрет прямого удаления критичных сущностей;
• мягкое удаление (пометка) + возможность восстановления;
• ограничение массовых операций.

3) Подтверждения и “двухшаговые” действия

Для опасных операций:

• подтверждение с вводом слова/кода;
• повторное подтверждение для массовых изменений;
• отдельные права на “массовое”.

4) Разделение обязанностей

Критичные действия не должны быть у одного человека:

• один создает правило/настройку, другой утверждает/включает;
• доступ к прод-инфраструктуре — у ограниченного круга;
• “боевые” ключи и платежи — отдельно от разработчиков/операторов.

5) Журнал действий (audit log) и ответственность

Должно быть видно:

• кто сделал действие;
• когда;
• что изменилось (до/после, хотя бы для ключевых полей).

Это не “контроль ради контроля”, а способ быстро понять причину и восстановить нормальную работу.

6) Регламент изменений

Даже короткое правило помогает:

• изменения в прод — только через задачу и окно релиза;
• экстренные — фиксируются постфактум;
• доступы выдаются на срок и отзываются после работ.

Такая настройка ролей и запретов предотвращает самые дорогие ошибки: потерю данных, остановку процессов и “пожары” из-за случайного действия в прод.