Гибкое управление межсетевым экраном и прокси-сервером оптимизирует безопасность вашей сети, сводит к минимуму уязвимости и ускоряет реализацию проектов.

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

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

Управление движением по направлению Север-Юг, Восток-Запад

Типичная корпоративная сеть состоит из нескольких зон для рабочих пространств, серверов приложений, баз данных и т. д. Внешние брандмауэры контролируют трафик между этими зонами и Интернетом, обычно называемый «северо-южным трафиком».

Напротив, «трафик восток-запад» представляет собой поток между внутренними зонами, управляемыми внутренними брандмауэрами (см. Рисунок 1). В то время как прокси-серверы в основном управляют исходящим трафиком из рабочих зон в Интернет, более крупные организации могут также использовать их для трафика сервера.

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

Зачем нужен контроль исходящего трафика?

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

Управление изменениями прокси-сервера и брандмауэра

Управление брандмауэром и прокси-сервером следует простому правилу: блокируйте все порты по умолчанию и разрешайте только необходимый трафик. Признавая, что разработчики лучше всего понимают свои приложения, почему бы не предоставить им возможность управлять изменениями брандмауэра и прокси-сервера в рамках стратегии «сдвига безопасности влево»? На практике, однако, сжатые сроки часто приводят к тому, что разработчики реализуют слишком широкое подключение — открывая весь Интернет — с планами по его дальнейшему совершенствованию. Временные исправления, если их не проверить, могут перерасти в серьезные уязвимости.

Каждый специалист по безопасности понимает, что происходит на практике. Когда сроки поджимают, разработчики могут поддаться соблазну пойти на уступки. Вместо того чтобы выяснить точный необходимый диапазон IP-адресов, они открывают подключение ко всему интернету с намерением исправить это позже. Решения, которые должны были быть временными, часто накапливаются, создавая со временем значительные уязвимости безопасности.

Чтобы снизить этот риск, зрелые организации обычно применяют две практики:

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

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

Аудит набора правил после внедрения

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

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

Более плавный и быстрый поток: автоматизация утверждений

Одной из самых больших проблем является баланс скорости и безопасности. Каждое ожидаемое изменение брандмауэра или прокси может задержать критически важные проекты. Возможные улучшения зависят от уровня риска изменения:

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

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

Затем команда облачной платформы может реализовать API изменений брандмауэра и прокси-сервера, как показано на рисунке 2. Когда команда приложения запрашивает изменение, API проверяет, имеет ли этот запросчик необходимую роль, например, на основе тегов ресурсов.

Затем API проверяет, соответствует ли изменение критериям организации для изменений с низким уровнем риска (например, JDBC для базы данных). Если да, API немедленно развертывает изменение, хотя то, как быстро изменение вступит в силу, зависит от поставщика облачных услуг.

Другой подход заключается в разделении ответственности за компоненты сетевой безопасности путем создания двух дополнительных элементов управления, как показано на рисунке 3.

Например, два дополнительных элемента управления могут быть брандмауэром сетевой зоны концентратора и брандмауэром зоны Spice – или Azure Firewall против Azure Network Security Groups (NSGs). Если обе стороны открывают порт, трафик возможен.

Идея внедрения разделения заключается в том, что только центральная команда управляет портами среднего и высокого риска (всегда открытыми с другой стороны), тогда как команды приложений контролируют настройки для портов низкого риска.  
Как подход на основе API, так и модель разделения ответственности требуют интеграции с процессами управления изменениями для поддержания всеобъемлющих аудиторских следов.

Послание, которое нужно взять домой

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

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