Безопасность корпоративного сайта: минимальный обязательный набор

Выдавайте сотрудникам только необходимые разрешения, а административные доступы защищайте многофакторной аутентификацией.

После завершения работы подрядчика отзывайте ненужные ключи и проверяйте владельцев сервисов.

Проверяйте входные данные на сервере, ограничивайте частоту запросов и не доверяйте данным из браузера.

Секреты и токены не должны попадать в клиентский JavaScript или публичный репозиторий.

Следите за исправлениями безопасности фреймворка, библиотек и серверного окружения.

Проводите обновления через тестирование, а не только после обнаружения инцидента.

Определите, какие данные резервируются, как часто и кто проверяет возможность восстановления.

Резервная копия без проверенного восстановления не является надёжным планом.

Назначьте ответственных, порядок отключения скомпрометированных доступов и каналы уведомления.

Ведите журналы технических событий с учётом требований к защите персональных данных.

Начинайте не с перечня модных защитных сервисов, а с карты: где хранятся заявки, кто может редактировать контент, какие API доступны извне, какие внешние сервисы получают данные. Выделите наиболее чувствительные объекты и потенциальные последствия их потери. Для корпоративного сайта это часто личные данные из форм, административный доступ, домен и инфраструктурные секреты.

Опишите простые сценарии риска: злоумышленник получает доступ к учётной записи редактора, внешний API отвечает поддельными данными, форма подвергается массовой отправке или при обновлении ломается сайт. Для каждого риска определите ответственную меру: ограничение доступа, журналирование, резервирование, проверку данных или процедуру восстановления.

Не выдавайте всем сотрудникам роль администратора. Редактору достаточно управления материалами, менеджеру — чтения заявок, разработчику — необходимых технических доступов. Важные изменения должны фиксироваться в журнале. При уходе сотрудника доступы нужно отзывать, а общие пароли заменять отдельными учётными записями.

Включайте многофакторную аутентификацию там, где она поддерживается. Храните ключи API и секреты вне репозитория и клиентского JavaScript. Даже если интерфейс скрывает административную кнопку, сервер обязан самостоятельно проверять права перед выполнением действия. Клиентская проверка удобна, но не является защитой.

Проверяйте входящие данные на сервере, ограничивайте размер запросов и не доверяйте значениям из браузера. Для публичных форм полезны контроль частоты отправки, защита от автоматизированного спама и понятная реакция на ошибки. Интеграции с CRM и почтой должны обрабатывать таймауты, повторные уведомления и сбои без случайной потери информации.

Избегайте вывода чувствительных данных в аналитические события и диагностические логи. Заявка может содержать номер телефона, адрес, внутренние данные компании или документы. Настройте сроки хранения, роли чтения и безопасный способ удаления в соответствии с реальным контекстом бизнеса и действующими требованиями.

Регулярно отслеживайте сообщения о серьёзных уязвимостях используемых библиотек, обновляйте зависимости контролируемо и проверяйте работу сайта после изменения версий. Необязательно автоматически ставить каждую новую версию в производство без тестирования, но и оставлять критичные исправления на месяцы рискованно. Поддерживайте отдельную проверяемую ветку или тестовый контур.

Резервная копия полезна только тогда, когда из неё можно восстановиться. Проверьте сценарий восстановления файлов, данных и конфигураций; зафиксируйте, кто имеет доступ к резервам и как защищено их хранение. Для сайта с CRM-интеграциями отдельно подумайте, как избежать повторной отправки заявок после восстановления.

Подготовьте короткий план: кто узнаёт об ошибке, кому сообщает, как временно отключить опасную функцию, как сохраняются технические следы и когда можно возвращать сайт в эксплуатацию. Если произошла утечка, могут возникнуть обязанности по уведомлению заинтересованных сторон или регуляторов; их нужно определить в рамках применимых законов, а не импровизировать.

После устранения проблемы проведите разбор без поиска виноватого: какая защита не сработала, какие журналы помогли, что нужно автоматизировать и как сократить время реакции. Сильная безопасность опирается на регулярные практики команды, а не на одну иконку замка на главной.

У корпоративного сайта есть контактная форма и редактор статей. Публичная форма принимает данные из любого браузера, а редактор доступен ограниченной группе сотрудников. Эти части требуют разных мер: валидации и контроля частоты отправок для формы, аутентификации и разграничения прав для кабинета.

Если сообщение отправляется в CRM, интеграция должна проверять ошибки и не терять данные при временной недоступности сервиса. Нельзя считать заявку успешно принятой лишь потому, что браузер показал красивую анимацию. Для административной части полезен журнал изменений и процедура отзыва доступов при смене сотрудников.

Отдельно проверьте конфигурацию: секретные ключи не должны попадать в клиентский код или репозиторий, резервные копии должны восстанавливаться, а зависимости — получать критичные обновления после тестирования. Безопасность складывается из процессов, а не из одного плагина.

Разделите обязанности: кто управляет доменом, кто отвечает за хостинг, кто обновляет зависимости и кто имеет право читать заявки. Для каждого доступа определите владельца и способ отзыва. Не используйте один общий административный пароль на всю команду.

Настройте резервное копирование и периодически проверяйте восстановление. Процедура должна включать не только файлы, но и содержимое базы, настройки окружения и связанные сервисы. Зафиксируйте, какой объём данных может быть потерян при сбое и сколько времени допустимо на восстановление.

Подготовьте короткий сценарий реакции на инцидент: остановить опасную функцию, сохранить технические следы, ограничить доступ, восстановить работу и проверить последствия. Если затронуты персональные данные, действия нужно соотнести с применимыми юридическими требованиями.