Оценка защищённости ИТ-инфраструктуры: проверка сегментации сети

Оценка защищённости ИТ-инфраструктуры должна отвечать на более точный вопрос, чем «сеть разделена на сегменты?». Нужно показать, может ли конкретный источник установить конкретное соединение с конкретным сервисом по тому пути, который реально используется в эксплуатации. Для этого отдельно рассматривают IPv4 и IPv6, новые и уже установленные соединения, прямые и проксируемые пути, а также отличают сетевую блокировку от отказа сервиса или приложения.

IPv4 и IPv6 — разные семейства адресов; для них могут действовать разные маршруты и фильтры. Межсетевой экран с отслеживанием состояния запоминает соединение и может пропускать ответный трафик, не оценивая его как новое соединение. Поэтому отказ по IPv4 ничего не доказывает для IPv6, а сохранившийся после изменения правила сеанс может говорить о состоянии соединения, а не о том, разрешено ли открыть новый сеанс.

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

Утверждение о сегментации должно называть обе стороны

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

Учётную запись пользователя или сервиса указывают в матрице, даже если межсетевой экран сопоставляет только адреса. Ноутбук пользователя, агент резервного копирования в той же подсети и администратор через управляемый бастион могут иметь разные права. Сетевая достижимость и авторизация на ресурсе — разные средства контроля: разрешённый TCP-путь может завершиться отказом аутентификации, а прокси с проверкой личности может дать доступ к приложению без прямой сетевой достижимости.

Нужно зафиксировать и назначение. «Сервер резервного копирования обращается к базе» лучше развернуть так: «указанный агент в согласованное окно начинает TLS-сеанс с выделенной точкой резервного копирования; интерактивное администрирование и прямое подключение клиентом БД запрещены». Из такой формулировки получаются проверяемые строки, а не общее обещание на уровне зоны.

Основой области работ служит матрица пар

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

Ниже показан шаблон, а не результаты реальной проверки. Синтетические имена подчёркивают эту границу.

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

Сначала выясняют путь и видимую контролю идентичность

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

Трансляция адресов и прокси меняют то, что видит следующий контроль. Входной облачный фильтр может оценивать частный адрес уже после трансляции назначения, а исходящий — частный адрес до трансляции источника. Исходящий прокси сам начинает новое соединение со своего адреса, сохраняя пользователя или рабочую нагрузку на прикладном уровне. В AWS путь через промежуточное устройство может требовать частных адресов или диапазонов CIDR: одной ссылки на группу безопасности другой стороны недостаточно. Это особенности продукта и топологии, поэтому в доказательствах указывают кортеж и идентичность на каждом участке.

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

Пять шагов связывают проектное правило с фактом

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

1. Определитьзафиксировать пары, ожидаемые решения, владельцев и исключения
2. Собратьвыгрузить маршруты, эффективные политики, трансляции, DNS и локальные фильтры без изменений
3. Подготовитьпроверить тестовые клиенты, тестовые сервисы, время и положительные контроли
4. Выполнитьпровести ограниченные проверки разрешений и запретов для семейств, направлений и состояний
5. Сопоставитьсвязать источник, контроль и цель, присвоить статус и назначить повторную проверку

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

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

Результаты классифицируют без догадок

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

Используют пять итоговых статусов:

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

Непосредственный эффект хранят отдельно от статуса и сначала устанавливают его источник. TCP-сброс может прийти от закрытого сервиса на цели или от промежуточного контроля с действием reject. Сбой DNS означает, что именованный путь не проверен. Подтверждённый ответ конечной точки 401 или 403, отказ SSH либо отклонённый клиентский сертификат доказывают достижимость только этого ответившего узла и последующий отказ на прикладном или TLS-уровне. Ответ прокси не доказывает обращение к частному серверу за ним.

Новые и установленные соединения проверяют отдельно

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

Поведение разных продуктов нельзя обобщать. AWS указывает, что учтённые группой безопасности соединения могут сохраняться до истечения состояния, тогда как некоторые широкие неотслеживаемые потоки обрываются сразу после изменения разрешающего правила. Группы сетевой безопасности Azure применяют новые правила к новым соединениям и могут не прерывать существующий поток. Azure Firewall, хотя пропускает ответный трафик по состоянию, при изменении правила на запрет, согласно документации, разрывает относящиеся к нему сеансы. Само слово «stateful» не предсказывает результат.

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

IPv4 и IPv6 получают независимое покрытие

Узел с двумя стеками создаёт две поверхности политик. Для имени отдельно запрашивают A и AAAA, сохраняют адреса и контекст времени жизни записи, затем выполняют назначенные строки для каждого применимого семейства. Результата «по имени подключились» мало: клиент мог выбрать только одно семейство или перейти к нему после сбоя другого.

Для каждого семейства отдельно записывают выбранный адрес, исходный интерфейс, маршрут, объект политики, привязку сервиса, идентификатор теста, сборку клиента и время событий. IPv6 может идти через другой шлюз или миновать NAT, используемый IPv4. Для атрибуции адрес сопоставляют с таблицей соседей, портом коммутатора и событиями идентичности, не ограничиваясь журналом выдачи адресов DHCPv6.

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

Управление, резервное копирование и обратное направление — отдельные пути

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

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

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

Отчёт должен поддерживать решение и точный повтор

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

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

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

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

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