Перед запуском сайта многие компании сосредотачиваются на визуальном оформлении и полноте контента, а вопросы безопасности часто отходят на второй план. На самом деле, после запуска сайт постоянно находится в открытом доступе, и если базовая конфигурация безопасности не выполнена, дальнейшее обслуживание будет сопровождаться частыми проблемами. Вот базовый чек-лист безопасности, подходящий для корпоративных сайтов, разделенный на три этапа: подготовка, выполнение и проверка.
1. Подготовительный этап: инвентаризация ресурсов и прав доступа
Перед началом проверки определите все точки входа и учетные записи сайта. Обычно это включает админ-панель, панель управления сервером, инструменты управления базой данных, FTP или SSH-доступ. Составьте таблицу с адресами, способами входа и текущими правами для каждой точки входа, чтобы можно было проверить их по очереди.
Что касается прав учетных записей, разграничьте роли: администратор, редактор, загрузчик контента и т.д. Каждая должность должна иметь только необходимые права. Например, обычному редактору не нужны права на управление сервером, а сотруднику поддержки — доступ к базе данных. Если ранее уволившиеся сотрудники или внешние подрядчики имели доступ к системе, их учетные записи должны быть удалены или сброшены перед запуском.

2. Этап выполнения: проверка ключевых аспектов безопасности
2.1 Защита адреса админ-панели и входа
Не используйте стандартный путь для входа в админ-панель (например, /admin). Измените его на менее очевидный. Также проверьте, включена ли капча или двухфакторная аутентификация для защиты от перебора паролей. Если система поддерживает, рекомендуется ограничить количество неудачных попыток входа и временно блокировать IP-адрес после превышения лимита.
2.2 Загрузка файлов и права на каталоги
Проверьте, запрещено ли выполнение скриптов в каталогах загрузки. Например, каталог для загрузки изображений должен быть доступен только для чтения и не должен позволять запуск PHP или ASP-скриптов. Если на сайте есть функция управления файлами, убедитесь, что обычные пользователи не могут получить доступ к системным конфигурационным файлам.
2.3 База данных и стратегия резервного копирования
Не используйте root или admin в качестве учетной записи базы данных, пароль должен быть достаточно сложным. Также проверьте план резервного копирования: настроено ли автоматическое резервирование? Хранятся ли резервные копии вне каталога сайта? Рекомендуется хранить резервные копии как минимум за последние 7 дней и регулярно тестировать процедуру восстановления.

2.4 Проверка распространенных уязвимостей
Проверьте, использует ли сайт плагины или компоненты с известными уязвимостями, особенно если это открытые CMS (например, WordPress, Drupal и т.д.). Обновите их до последних версий и удалите неиспользуемые плагины и темы. Также проверьте наличие SQL-инъекций и XSS-уязвимостей, вводя специальные символы в формы, но будьте осторожны, чтобы не повлиять на реальные данные.
2.5 HTTPS и защита конфиденциальной информации
Убедитесь, что сайт использует HTTPS, особенно для страниц входа и оплаты. Проверьте, принудительно ли используется HTTPS для входа в админ-панель, чтобы избежать передачи паролей в открытом виде. Также просмотрите исходный код сайта на предмет утечки информации о подключении к базе данных, API-ключей и других конфиденциальных данных.
3. Этап проверки: подтверждение эффективности проверок и резервного копирования
После завершения проверок проведите практические тесты. Например, войдите в админ-панель с учетной записью не-администратора и убедитесь, что доступны только функции в рамках прав; попробуйте перейти по адресу админ-панели и проверьте, что доступ заблокирован или требуется дополнительная проверка. Кроме того, выполните ручную тренировку восстановления из резервной копии, чтобы убедиться, что файлы резервных копий пригодны и процедура восстановления понятна.

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





