Какой должна быть успешная стратегия организации практической безопасности инфраструктуры, применимая к компании любого размера? Рекомендации, указанные в статье, вендоронезависимые и не нацелены на удовлетворение конкретного набора стандартов безопасности (например, удовлетворение ЗПД, КИИ или PCI DSS), а являются общеприменимыми и собраны из практического опыта работы автора с разного уровня системами.
- Введение
- Проектирование безопасной инфраструктуры
- Шаг 1. Выделить подклассы ресурсов
- Шаг 2. Отсортировать ресурсы по базовым критериям ИБ
- Шаг 3. Выбрать дизайн сети с учетом полученных подклассов данных
- Шаг 4. Выбрать средства защиты
- Шаг 5. Проработать вопрос взаимодействия информационных систем
- Пример концепции инфраструктуры
- Выводы
Введение
По результатам исследования Anti-Malware.ru, 27% организаций, преимущественно малого и среднего бизнеса, не имеют выделенных специалистов по информационной безопасности (далее — ИБ), порядка 60% организаций выделяют на ИБ незначительный годовой бюджет. И, как следствие этих факторов, руководство не вкладывается в развитие компетенций своих специалистов в области ИБ.
На практике много компаний действительно не до конца осознает, каким образом выстроить безопасную и гибкую архитектуру сети. Но надо учитывать, что как только вы подключаете в свой коммутатор шнур провайдера, вы становитесь объектом сетевых атак — случайных, преднамеренных или направленных.
Настоящая статья не является руководством по ИБ, скорее это предложение варианта стратегии организации качественного дизайна безопасной и масштабируемой среды функционирования для информационных систем. Причем информационная безопасность инфраструктуры не может быть стационарной сущностью, архитектура ИБ должна регулярно анализироваться на предмет слабых мест и пересматриваться. Что-то вроде agile-метода в ИБ, где требования диктуются текущими тенденциями атак и уязвимостей, критичностью данных и моделью угроз.
Такого рода анализ автоматизируется с помощью средств анализа сети типа Tufin, Algosec, Skybox, Redseal и др. Данный класс решений позволяет анализировать риски ИБ в привязке к сетевой инфраструктуре, строить векторы атак, анализировать политики средств защиты информации и выявлять в них уязвимые места.
Сформировать и придерживаться безопасного подхода к инфраструктуре можно и нужно сразу, так как даже миграция сетевого (IP) адреса для некоторых бизнес-приложений может стать существенной проблемой для ИТ.
Проектирование безопасной инфраструктуры
Имеет смысл сформировать и придерживаться одной стратегии при проектировании дизайна инфраструктуры. Стратегия должна коррелировать с принятой в компании политикой ИБ, возможно, являться ее частью, но включать конкретные технические решения и выводы. В планировании дизайна инфраструктуры в качестве шагов можно ориентироваться на следующие:
Шаг 1. Выделить подклассы ресурсов
Выписать все информационные системы (далее — ИС) — задача не всегда в принципе выполнимая, ресурсы динамичны, и не все будущие ресурсы предсказуемы. Но можно выделить подклассы, например:
- Ресурсы с внешним доступом. Причем желательно отделять ресурсы предоставляющие сервис для внешних клиентов от внутренних сервисов, например, веб-сервер клиентский, портал для сотрудников, сервер публикации для работающих удаленно сотрудников.
- Ресурсы с чувствительными данными:
- данные, подходящие под стандарты ИБ, например персональные данные, PCI DSS серверы, уровень государственной тайны,
- данные, признанные в компании конфиденциальными, — база клиентов, данные серверов метеорасчетов, геодезии, серверы 1С, и т. п.,
- разработка и тестовая среда разработки,
- серверы резервирования, обеспечения ИБ, например антивирусный сервер, серверы мониторинга и другие.
- Ресурсы менее чувствительные — например, сервисы Microsoft, принт-серверы и пользовательские сегменты.
- Технологические ресурсы: АСУ ТП, СКУД и так далее.
- IoT (Internet of Things), системы видеонаблюдения и др.
Шаг 2. Отсортировать ресурсы по базовым критериям ИБ
Критерии могут быть и общепринятыми, и персонализированными под специфику предприятия, например:
- необходим ли к ресурсу удаленный доступ,
- необходим ли доступ к внешним ресурсам (и речь не идет об обновлениях, обновления рекомендуется делать централизованно, кроме исключительных случаев),
- требования по доступности ресурса, возможном времени даунтайма,
- требования конфиденциальности.
На данном этапе появляется пул подклассов данных. Почти наверняка полный перечень ИС составить не удастся, но в этом нет необходимости. Достаточно понимать базовые категории сервисов и их свойства.
Если выстроить достаточно гибкую архитектуру инфраструктуры, то дополнительные ИС будут встраиваться в нее без больших трудностей. Кроме того, если вы планируете реализовать SDN, то в данном случае внедрение новых ИС будет максимально простым.
Шаг 3. Выбрать дизайн сети с учетом полученных подклассов данных
На данном этапе формируется базовый набор сегментов:
- DMZ,
- внутренние сегменты ЛВС,
- технологические сегменты,
- сегменты конфиденциальных данных,
- сегменты управления и резервного копирования и так далее.
В проектировании начинают фигурировать такие сущности, как сервер, клиент, база данных и другие компоненты ИС. Проектируются сервисы виртуализации. Если на текущий момент сложилась ситуация, когда один физический сервер является одновременно, например, принт-сервером и сервером базы геодезии, или сервер БД один для многих систем — от таких конфигураций лучше избавляться. Существует много вариантов виртуализации или контейнеризации: Microsoft HyperV, VMWare, Docker, KVM. Сразу возможно продумать вопрос выделения конфиденциальных данных близкой категории (например, серверы ИСПДн) на виртуальные серверы в рамках отдельных физических серверов для каждой категории.
Дизайн сети зависит от множества общих и частных факторов: масштаба проектируемого филиала, централизации или децентрализации ядра, использования SDN или TrustSec, необходимости в растягивании L2 между территориальными ЦОД и так далее. Но независимо от выбранного дизайна сети можно выделить основные принципы ИБ:
- разделять концептуально разный трафик на сегменты, разделять трафик по критериям безопасности, причем трафик необходимо экранировать и фильтровать;
- минимизировать включение технологического трафика в общую сетевую инфраструктуру, если есть возможность не подключать его — не подключать;
- не превращать безопасность в паранойю, соблюдать баланс рисков и бизнеса. Например, если клиентская часть используемого приложения при запуске выполняет объемный запрос из БД (например, одна из старых версий 1С), но вы приняли политику ИБ, требующую размещения БД в отдельном сегменте и строгую фильтрацию трафика к и от них — то пользователи будут вынуждены терпеть острый дискомфорт. В данном случае серверы БД 1С лучше разместить в одном сегменте с серверами программного обеспечения, убрав узкое горлышко в виде межсетевого экрана, и рассмотреть вариант перехода на более современную версию 1С.
Шаг 4. Выбрать средства защиты
Имея уже продуманный дизайн с реализованной сегментацией, виртуализацией, с пониманием необходимых доступов (концептуально, а не попротокольно), проанализировать дизайн средств защиты будет достаточно просто. Базовые средства, которые необходимы сразу при запуске инфраструктуры:
- Межсетевое экранирование. Учитывая рост объемов сетевого трафика, тенденции в решении по фильтрации трафика для достаточно крупного филиала заключаются в выделении UTM-функций (URL-фильтрация, Application Control, Anti-virus, Anti-bot, 0-day защита и виртуал патчинг) на уровень периметра, на ядре осуществление фильтрации трафика уровня NGFW (Firewall, некоторые проверки IPS), возможно, реализацию концепции TrustSec.
- Предотвращение вторжений. Учитывая объемы передаваемого трафика, часто целесообразно выделение функции предотвращения вторжений на отдельный класс устройств. Кроме того, в таком варианте качество проверки трафика также выше, плюс можно обеспечить такие полезные функции, как by-pass.
- Криптографическая защита трафика при передаче по неконтролируемым каналам (включая ISP).
- Защита почтового трафика (+Sandbox).
- Своевременное обновление систем и антивирусная защита.
- Защита web-трафика. В случае критичности доступности web-сервиса имеет смысл сразу использовать DDoS-защиту либо в виде сервиса, либо on-premise, а также Web Application Firewall (WAF).
- Защита Wi-Fi. Если в кампусе используется Wi-Fi-сеть, ее необходимо запускать как минимум с использованием аутентификации и криптографии (WPA2), с функциями wIPS.
- В достаточно крупной архитектуре имеет смысл в проектировании сразу закладывать использование средств централизованного снятия трафика для анализа средствами мониторинга — решения типа Ixia, Gigamon, Big Switch Networks, Brocade, Cisco Stealhthwatch.
- Средства защиты среды виртуализации.
- Центр мониторинга и реагирования на инциденты ИБ (SOC/SIEM/SOAR).
В логично выстроенной сети внедрение продвинутых средств анализа и защиты, в частности средств Network Forensics (Flow Collector and Behavior Analysis), Database Firewall (DBF) или Network Access Control, концепции Cisco Trusted Security или других будет несложным и более качественным.
Шаг 5. Проработать вопрос взаимодействия информационных систем
Важен вопрос качества внедрения СЗИ. Установить дорогое и мощное средство защиты в инфраструктуру без его качественной интеграции — это зря потраченные вложения и усилия. К сожалению, даже в крупных и продуманных компаниях, даже на таком базовом средстве защиты, как межсетевой экран, можно встретить правила типа Any-Any-Accept. Эксплуатация менее наглядных средств защиты может происходить вообще без полного осознания настроек специалистами ИБ.
Разработка правил взаимодействия систем — это трудоемкая процедура, и для чувствительных сегментов данный шаг потребует тщательной проработки, поэтому необходимо четко понимать свою стратегию действий. Тем более если настройка происходит уже на живой сетевой среде. Есть несколько принципов, которых стоит придерживаться:
- не изменять несколько настроек в одну итерацию, особенно если нет уверенности в результате изменений;
- если нет возможности выписать все разрешенные способы взаимодействия — сконцентрируйтесь на запрещенных;
- использовать журналирование, но без фанатизма: если в части настройки уже есть уверенность, то нет смысла засорять этими событиями журнал (если нет специальных требований к журналированию, конечно). Скажем, правила МЭ, касающиеся Microsoft-взаимодействий, например netbios — не слишком информативны, а вот журнал событий заполняют данными в геометрической прогрессии;
- стоит «есть слона по частям»: всегда есть набор очевидных взаимодействий, которые можно настроить сразу. Более тонкие настройки уже нужно прорабатывать поэтапно и пошагово, использую плотную работу с журналом событий.
Вопрос взаимодействия систем в принципе необходимо продумывать в направлении: нужно ли оставлять именно такой вариант работы или можно рассмотреть что-то более актуальное, гарантированное и безопасное?
Пример концепции инфраструктуры
Ниже представлен пример простого в реализации, но в то же время достаточно безопасного и масштабируемого дизайна инфраструктуры. Схему можно реализовать на одном физическом сервере, с одним массивом NAS, маршрутизатором с функциями безопасности, коммутатором. Схема легко масштабируется, все компоненты можно зарезервировать.
Ввод в дизайн средств информационной безопасности достаточно прозрачен и не требует миграций или переосмысления структуры сети. Фактически ниже приведен домашний вариант качественной инфраструктуры, те же средства антивирусной защиты используются автономные без общих сетевых компонентов, тем не менее этот дизайн в целом может быть полезен и для небольшого офиса. А с учетом логичности масштабирования, возможно расширение и до промышленных масштабов или абстрагирование на SDN или NFV.
Рисунок 1. Вариант дизайна небольшой инфраструктуры
Рисунок 2. Вариант базовых СЗИ для предложенного дизайна
Выводы
Информационная безопасность в текущем информационном поле давно перешла в разряд необходимостей. Громкие утечки конфиденциальной информации разного рода уже не являются сенсацией, а практически становятся рутиной. Причем и репутационные, и финансовые потери от таких инцидентов становятся все более ощутимыми для бизнеса. Стремительный рост технологий при этом провоцирует рост и смещение фокуса рисков информационной безопасности.
В связи с этим становится сложно коррелировать все актуальные тенденции в защите информации в рамках одной инфраструктуры даже для опытного специалиста по ИБ. Тем не менее, если придерживаться основных принципов, возможно повысить уровень защищенности компании до приемлемого с умеренными вложениями.
