Всем привет! Опыт защиты веб-сервисов, в том числе на базе 
1С-Битрикс показывает, насколько критичным с точки зрения обеспечения безопасности веб-приложения является настройка его системного окружения. Защита такого приложения - это не только включение подсистем защиты и своевременные обновления, а комплексный подход, охватывающий все слои ИТ-инфраструктуры. Недостаток в любой ее точке может свести на нет все усилия разработчиков по написанию безопасного кода и привести к серьезным последствиям: от утечки конфиденциальных данных до деградации связанных бизнес-процессов с финансовыми и репутационными потерями.

Данный чек-лист будет полезен при формировании внутренних правил безопасного конфигурирования компонентов системного окружения классических веб-приложений, включая продукты 1С-Битрикс. Очевидно, что все предлагаемые рекомендации, реализованные в конкретных настройках, должны быть гармонизированы с эксплуатационной документацией вендоров и протестированы в вашем ИТ-ландшафте.

1. Общие рекомендации для всех типов компонентов

• Для каждого системного администратора настроена персонифицированная учетная запись; 

• Учетные записи по умолчанию и/или не персонифицированные запрещены настройками либо их использование строго регламентировано  и логируется;

• Пароли по умолчанию изменены;

• Настроены политики сложных паролей;

• Доступы к оборудованию, к системному ПО, к инструментам управления настроены только тем работникам, которые администрируют их в соответствии с должностями обязанностями;

• Установлено и настроено антивирусное ПО, пакеты поиска руткитов и зловредного ПО;

• Настроено журналирование событий, включая логирование доступа, различных запросов/ответов, событий запуска/остановки процессов, изменений настроек, действий администраторов;

• Установлена и настроена SIEM. Осуществляется централизованный сбор и анализ событий журналов системных компонентов, обеспечивающих функционирование веб-приложения;

• Формализованы процедуры обновлений и резервирования;

• Настроено обновление системного программного обеспечения с проверкой в тестовой зоне и/или с разработанной процедурой отката.

2. Безопасность сетевого оборудования и периметра

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

• Формализован перечень сетевого оборудования, обеспечивающего функционирование веб-приложения, включая оборудование связи облачных и локальных инфраструктур;

• Разработана сетевая схема взаимодействия с указанием используемого сетевого оборудования, основных серверных компонентов, соответствующих портов и протоколов;

• Сетевая схема дополнена информацией о потоках данных, соответствующих портах и протоколах;

• Реализована сегментация сети средствами межсетевого экрана с настройкой демилитаризованной зоны для системных компонентов, доступных для внешних подключений, включая Интернет;

• Настроены ACL (Access Control Lists) для ограничения административного доступа только с доверенных IP-адресов;

• Назначен нестандартный порт для SSH (не панацея, но все равно полезно) и ограничение доступа к нему по IP;

• Отключены неиспользуемые сервисы и порты (Telnet, HTTP-интерфейс, неиспользуемые порты);

• Базовая настройка ограничения количества запросов в единицу времени на уровне сетевого оборудования;

• Для серьезной защиты используется специализированный Anti-ddos сервис;

• Установлен и настроен WAF;

• Установлена и настроена система обнаружения вторжений;

• Для удаленных подключений к инфраструктуре настроен VPN.

3. Безопасность инструментов контейнеризации и виртуализации

Docker:

• Запуск контейнеров от root пользователя запрещен;

• Используется .dockerignore для исключения попадания конфиденциальных файлов (.env, .git) в контекст сборки;

• Используется Docker Content Trust (DCT) для проверки цифровой подписи образов;

• Docker socket не монтируется во внутрь контейнеров;

• Проводится регулярное сканирование образов на уязвимости с помощью инструментов (например, trivy или docker scan).

Оркестраторы:

• Настроена модель управления доступом для процессов и объектов (поды, ноды, сервисы, ConfigMaps, Secrets, Deployments, StatefulSets, API-объекты) в кластере;

• Настроены политики безопасности подов (Pod Security Admission);

• Реализована изоляция трафика между подами (например, с помощью плагина Calico);

• Запрещен запуск привилегированных контейнеров без необходимости;

• Используются механизмы защиты секретов (например, Sealed Secrets);

• Реализованы дополнительные настройки безопасности, например, политика использования ресурсов среды контейнеризации, настройки аутентификации процессов и пользователей, конфигурация API-сервера и т.п.

Виртуализация:

• Реализовано разделение сети управления гипервизором с сетями виртуальных машин;

• Настроен контроль/фильтрация трафика для средств управления виртуальной инфраструктурой;

• Настроен контроль/фильтрация трафика для виртуальных машин;

• Реализован контроль настроек виртуальных машин (их шаблонов).

4. Безопасность операционных систем

• Настроена модель управления доступом на уровне ОС, включая запрет доступа к критичных каталогам веб-приложения для всех, кроме администраторов, ограничение и/или запрет на редактирование критичных конфигурационных файлов;

• Реализован запрет прямого входа под root. Используется sudo;

• Реализована аутентификации по SSH с помощью 2 факторов с использованием ключей;

• Настроен нестандартный порт SSH;

• Реализован регулярный аудит и отключение неактивных пользователей;

• Настроена блокировка IP при множественных неудачных попытках входа;

• При использовании SNMP заменена community-строка, установленная производителем по умолчанию;

• Установлено время разрыва сеанса при неактивности пользователя;

• Используются только необходимые службы, протоколы, утилиты, пакеты и прикладное ПО. Все неиспользуемые/небезопасные службы, протоколы, утилиты, пакеты и прикладное ПО отключены и/или удалены;

• Для критичных приложений созданы профили, чтобы ограничить их возможности (например, доступ к файлам и сетям);

• Настроен контроль целостности для критичных конфигурационных файлов системы.

5. Безопасность веб-серверов

• Удалены все веб-приложения, установленные по умолчанию, и не используемые;

• Системные веб-приложения, которые служат для управления сервером переименованы;

• Отключена публикация версии сервера в сообщениях об ошибках, в заголовках ответов;

• Отключены все неиспользуемые порты и протоколы;

• Настроен контроль целостности для критичных конфигурационных файлов;

• Настроено обязательное использование HTTPS (Strict-Transport-Security);

• Настроен TLS 1.2, 1.3;

• SSL, TLS 1.0, 1.1 отключены;

• Используются надежные алгоритмы шифрования с достаточной длиной ключа (AES-256, ГОСТ);

• Установлен запрет выполнения PHP в upload-директориях;

• Настроено ограничение размера загружаемых файлов;

• Настроены ограничения (limit_conn и limit_req) для защиты от перегрузки и брутфорса;

• Настроена защита на стороне сервера от кликджекинга (X-Frame-Options: DENY/SAMEORIGIN);

• Настроен запрет браузеру определять MIME-тип не по заголовку;

• По возможности настроена блокировка нежелательных скриптов и ресурсов.

6. Безопасность систем управления базами данных

• Созданы отдельные пользователи для приложения с различными привилегиями обращения к БД;

• Настроено ограничение прослушиваемых адресов, необходимых для функционирования СУБД;

• Настроено ограничение сетевого доступа к СУБД;

• Настроен контроля целостности файлов для всех исполняемых и конфигурационных файлов СУБД;

• Настроено использование TLS для соединений между приложением и СУБД при использовании не доверенных каналов связи;

• Настроено шифрование полей БД с чувствительной информацией.

7. Безопасность API и сторонних интеграций

• Настроено ограничение доступа на сетевом уровне при взаимодействии с внешними сервисами, в частности, разрешены только IP/доменные имена  доверенных облачных сервисов 

• Настроена аутентификация по одному из стандартных протоколов (OAuth 2.0, OpenID, SAML и т.п.);

• Токены доступа имеют ограничение времени действия;

• Использование API-ключей ограничено областью их действия;

• Реализована строгая проверка для всех входящих и выходящих данных по реализованной схеме данных;

• Реализованы параметризованные запросы для защиты от инъекций;

• Настроены лимиты запросов на пользователя, IP-адрес или API-ключ.

8. Рекомендации для систем резервного копирования и восстановления

• Формализован план резервного копирования и восстановления с процедурами тестирования;

• Реализовано правило: 3 копии данных, 2 разных типа носителей (например, облако + локальное хранение), 1 копия в другом географическом месте;

• Все резервные копии, содержащие персональные или критичные данные зашифрованы;

• Используются инструменты защиты бэкапов от удаления или шифрования зловредами (Immutable Storage или Write Once Read Many).

9. Обеспечение физической безопасности и контроль сервис-провайдеров

• Доступ в серверные помещения предоставляется ограниченному количеству работников и в соответствии с их должностными обязанностями;

• Доступ в серверные помещения ограничен СКУД;

• Вход в серверные помещения контролируется системой видеонаблюдения со сроком хранения записей не менее 30 дней.

• Формализован и проводится регулярный аудит разрешений, которые вы предоставили сторонним провайдерам;

• Настроено обязательное использование двухфакторной аутентификации (2FA) на всех аккаунтах, имеющих доступ к вашей инфраструктуре;

• Реализовано строгое следование принципу наименьших привилегий для работников сервис-провайдеров и использование ролей доступа с краткосрочным периодом доступа.

В заключении отмечу, что веб-приложение само по себе – программное обеспечение, являющееся частью информационной системы. Именно последняя должна быть спроектирована, внедрена и эксплуатироваться в безопасном ключе. Правильные настройки всей системы на сетевом уровне, уровнях веб-серверов, ОС, СУБД и других при совместном применении наложенных средств защиты информации дают высокую итоговую защищённость веб-приложения. Помните, что только комплексный подход к безопасности позволяет создать такие условия, при которых стоимость взлома системы значительно превысит потенциальную выгоду для злоумышленника.