NAC перестал быть экзотикой: сегодня он определяет, кто и что попадает в корпоративную сеть, куда и на каких условиях. Эксперты ведущих российских вендоров обсудили, какие задачи решает эта технология, почему она стала актуальна, как измерять эффективность и с чего начать внедрение.
- 1. Введение
- 2. Что такое NAC и какие задачи он решает?
- 3. Почему технология стала актуальной?
- 4. Кейс: подключение личного ноутбука
- 5. Открытый код против коммерческого решения
- 6. Какие метрики важны при использовании NAC?
- 7. Синергия с другими классами решений и границы применимости
- 8. Какие три шага нужно сделать до конца года, чтобы улучшить управление доступом?
- 9. Выводы
Введение
Корпоративная сеть усложняется: помимо классических рабочих станций и серверов в ней появляются личные устройства сотрудников, оборудование подрядчиков, IoT, видеокамеры и промышленное оборудование. На всё это не всегда можно поставить хостовую защиту, обновить системы и построить мониторинг, при этом количество подключений продолжает расти.
Network Access Control перестал быть экзотикой и стал инструментом, который определяет, кто и что попадает в сеть, куда и на каких условиях. При этом NAC — не самостоятельное решение: он работает в связке с сетевым оборудованием, системами посчеринга, каталогами и файрволами, а его эффективность зависит от того, насколько правильно выстроены карантинный сегмент, политики доступа и процессы реагирования.
Рисунок 1. Эксперты в студии AM Live
Участники эфира:
- Максим Хаванкин, руководитель продукта DECK AUTH, DECK.
- Станислав Калабин, главный сетевой архитектор решения AxelNAC, Axel PRO.
- Александр Черных, генеральный директор, Blazar.
- Максим Ефремов, руководитель направления САКУРА, ИТ-Экспертиза.
Ведущий и модератор эфира — Максим Хараск, директор по развитию, UDV Group.
Что такое NAC и какие задачи он решает?
Максим Хараск отметил, что корпоративная сеть разрастается и становится сложнее: помимо классических рабочих станций и серверов появляются личные устройства сотрудников, оборудование внешних подрядчиков и контрагентов, а также IoT — видеокамеры и промышленное оборудование.
На всё это нет возможности поставить хостовую защиту, системно обновлять, построить мониторинг и реагирование. Именно поэтому важно разобраться, какое место технология NAC занимает на рынке ИБ, как она развивается и как взаимодействует с другими решениями.
Максим Хараск, директор по развитию, UDV Group
Максим Хаванкин назвал NAC гигиеническим минимумом: нужно знать, кто заходит в сеть и кто подключается. NAC не останавливается на принятии решения пустить или не пустить — он продолжает мониторить состояние устройства, следит за тем, что оно находится в состоянии комплаенса, и управляет подключением от начала до конца. Ключевой аспект — сегментация.
Станислав Калабин согласился и добавил, что NAC всегда работает в комплексе с сетевым оборудованием и не может быть самостоятельным решением. Контекст, который собирается о клиенте, важно передавать другим системам, иначе не будет синергии и пользы.
Александр Черных:
«NAC — это один из самых эффективных инструментов, который позволяет достичь того, чтобы внутри нашего периметра находились только те пользователи и устройства, которым мы доверяем».
Максим Ефремов добавил, что главная задача — защититься от внутренних угроз, как умышленных, так и неумышленных. Пользователь может принести ноутбук, на котором вечером играли дети, подключиться к Wi-Fi, и компьютер начнёт разрушительные действия. Хорошо бы поймать это на ранних этапах и изолировать в отдельный сегмент. Здесь и нужна синергия NAC со смежными системами, которые быстро находят нарушение и изолируют устройство.
Максим Ефремов, руководитель направления САКУРА, ИТ-Экспертиза
Почему технология стала актуальной?
Александр Черных отметил, что 10–20 лет назад инфраструктура тоже была непредсказуемой, но была проще: локальная сеть, однородные устройства. С ростом технологий, типов оборудования и форматов работы, включая удалённый и гибридный, границы предсказуемости растянулись. Появились разнородные устройства и несколько видов подключений, которые нужно контролировать, и без централизованного инструмента, который даёт картину и позволяет управлять, мониторить и реагировать, уже сложно.
Максим Ефремов назвал главным сдвигом мобильность: 10 лет назад рабочее место было стационарным компьютером, который тяжело было подключить к другой сети. Сейчас компьютер носят с собой, он не имеет сетевых портов. Контролировать оборудование нужно было и раньше, механизмы были, но не такие интеллектуальные. В ответ на эти изменения появилась более продуманная технология, которая обеспечивает видимость, сажает рабочее место в нужный сегмент и отслеживает, что оно не нарушает установленные правила.
Максим Хаванкин добавил, что устройств стало больше в десятки и сотни раз: в офисе есть пылесосы, умные колонки, проекторы, у каждого есть IP-подключение. Количество подключений растёт, их возможности — регламентированные и недокументированные — тоже растут, а контролировать их продолжают не всегда. Проблема не новая: Port Security появился ещё в начале двухтысячных. Есть заказчики, которые до сих пор используют Port Security, и при миграции на современный NAC вздыхают с облегчением.
Максим Хаванкин, руководитель продукта DECK AUTH, DECK
Станислав Калабин напомнил, что все начинали с Port Security, когда MAC-адрес жёстко привязывался к порту. Когда устройств 10, это можно отследить вручную; когда их 10 тысяч и они постоянно меняются — невозможно. Он привёл кейс, когда клиент не хотел отказываться от Port Security, и пришлось внутри продукта реализовать эту логику, хотя NAC обычно про свободу доступа в каждой розетке.
В первом опросе зрители ответили, насколько хорошо они видят устройства, подключённые к корпоративной сети:
- Видят подключения, но не всегда понимают владельца и тип устройства — 37%.
- Централизованной картины нет — 28%.
- Затрудняются оценить — 13%.
- Видят управляемые рабочие станции, но не весь IoT и BYOD — 12%.
- Видят все устройства, пользователей и их состояние — 7%.
- Есть значительное число неизвестных устройств — 3%.
Рисунок 2. Насколько хорошо вы видите устройства, подключённые к корпоративной сети?
Кейс: подключение личного ноутбука
Максим Хараск предложил разобрать базовый кейс: сотрудник пришёл с личным ноутбуком и пытается подключиться к сети. Какова цепочка действий?
Максим Хаванкин объяснил: если сетевой инженер, ИБ-специалист или ИИ-скрипт, управляющий конфигурацией сетевого оборудования, активировал 802.1X или MAB на порту, коммутатор, точка доступа или контроллер беспроводной сети отправляют запрос в систему NAC и начинают взаимодействовать с ней по протоколу RADIUS. В этот момент сетевой инженер отвечает себе на вопрос, хочет ли он аутентифицировать подключение с этого порта.
Далее можно криптографически надёжным методом проверить, что компьютер известен: на него доставлен сертификат. Проверка выполняется с помощью EAP-TLS или TEAP. После успешной машинной аутентификации NAC принимает решение о доступе. Как только NAC принял решение, начинается всё самое интересное: взводится сессия, и с ней дальше работают — либо разрешают ей жить дальше, либо прерывают.
Станислав Калабин продолжил: сначала выполняется машинная аутентификация, после чего устройство получает минимальный предварительный доступ, чтобы система могла идентифицировать пользователя, а тот — войти в неё. Для сбора контекста необходим доступ: одного сертификата недостаточно, чтобы определить, что это за устройство. Это может быть телефон, принтер или другое устройство.
Станислав Калабин, главный сетевой архитектор решения AxelNAC, Axel PRO
Максим Ефремов уточнил тонкий момент: как увидеть устройство в первый раз, если на него уже положили сертификат? Сертификат может быть разлит в другой сети или храниться в образе операционной системы, и его можно скопировать на другую машину, даже домашнюю. Поэтому после машинной аутентификации нужно собрать как можно больше контекста для взвешенного решения.
Максим Хаванкин подчеркнул важность карантинного сегмента: его может не быть, и тогда сетевое оборудование и файрвол разрешают доступ ко всему. Перед запуском NAC нужно создать этот сегмент и изолировать всё, что к нему подключается, от ценных активов.
Александр Черных добавил, что если устройство не новое, в системе может быть слепок его предыдущего состояния, но что происходило с ним, пока не было активной сессии, неизвестно. Запускать его сразу на основании контекста суточной давности — плохая идея. Нужно быть уверенным, что это всё ещё то же устройство, и проверить контекст заново.
Во втором опросе зрители поделились, какие устройства сложнее всего контролировать (мультивыбор):
- Личные устройства сотрудников — 73%.
- Удалённые рабочие места — 59%.
- Устройства подрядчиков — 58%.
- Устройства руководителей и VIP-сотрудников — 44%.
- Гостевые устройства — 41%.
- Промышленное или специализированное оборудование — 27%.
- Принтеры, камеры и другой IoT — 16%.
Рисунок 3. Какие устройства сложнее всего контролировать?
Открытый код против коммерческого решения
Максим Ефремов рассказал, что заказчики периодически приходят с идеей взять решение на вайб-коде, но пока ни одного такого случая не было. Решения строятся на живых запросах, полученных от заказчиков. САКУРА — третья реинкарнация продукта, и от первой версии осталось только название и концепция. Путь от нуля до MVP очень короткий, а оставшиеся 80% времени уходят на то, чтобы продукт работал так, как нужно. Дальше начинается вопрос поддержки: в одно лицо с одним агентом — это нерабочая схема.
Александр Черных добавил, что промышленные решения рождаются на основании потребностей рынка — это не про open source. Речь о надёжности, отказоустойчивости, функциональных возможностях и наличии вендора, который слышит, разговаривает, поддерживает и сопровождает.
Александр Черных, генеральный директор, Blazar
Станислав Калабин отметил, что рынок изолирован: вендоры мирового рынка сетевого оборудования недоступны, развиваются собственные вендоры, и никакой open source не будет их поддерживать — для мирового сообщества этот рынок слишком маленький, нет заинтересованного энтузиаста. Кроме того, open source рассчитан на что-то маленькое и простое, а NAC — это чаще всего большие инсталляции, где производительность критична.
Александр Черных назвал NAC бизнес-критической системой: всё, что связано с управлением доступом, — Business Critical.
Какие метрики важны при использовании NAC?
Александр Черных назвал главным показателем способность системы обрабатывать большое количество одновременных подключений: утром сотни человек приходят на работу с ноутбуками, планшетами, телефонами и часами, и нагрузка на сервер аутентификации и сервер политик возрастает. Нужно обработать эти события и одновременно сделать так, чтобы пользователь не ждал полчаса в карантине. Плюс отказоустойчивость и надёжность.
Станислав Калабин назвал важной метрикой производительность, измеряемую количеством сессий в секунду, причём как при пиковой, так и при длительной нагрузке. Одно дело выдержать один пик, другое — постоянно работать под нагрузкой, когда клиент реаутентифицирует каждые две минуты. Вторая метрика — надёжность: что будет, если одного ЦОДа не станет. Третья — функциональность: у вендоров разные подходы к профилированию и посчерингу, и здесь больше вкусовщина.
Максим Хаванкин добавил метрику длительности: сколько времени проходит с момента первого подключения до попадания в продуктивный сегмент. Также важна задержка в рамках TACACS-сессии: скрипты заказчиков, которые бегают по оборудованию, генерируют сотни тысяч сессий за рабочий день на небольшом количестве сетевых устройств.
В третьем опросе выяснилось, что сильнее всего мешает внедрить или полноценно использовать NAC (мультивыбор):
- Нехватка специалистов — 56%.
- Непонятный экономический эффект — 53%.
- Риск ошибочных блокировок и простоя — 38%.
- Зрелость заказчиков — 32%.
- Несовместимость с сетевым оборудованием — 27%.
- Сложность политик и интеграций — 24%.
- Legacy и IoT-устройства без поддержки 802.1X — 21%.
Рисунок 4. Что сильнее всего мешает внедрить или полноценно использовать NAC?
Синергия с другими классами решений и границы применимости
Максим Ефремов отметил, что интеграций должно быть много и разных. У заказчика, который понимает, что и как хочет защищать, накопилось много оборудования, каталогов и средств защиты, и без интеграции не обойтись. У САКУРЫ порядка девяти интеграций с решениями класса VPN и порядка пяти — с различными LDAP-каталогами, плюс появляются механизмы универсальных интеграций.
Есть ли границы, где NAC становится неэффективен? Александр Черных ответил, что устройства есть везде, и их безопасность и соответствие политикам никуда не деваются, в какой бы среде ни работал пользователь. Сценарии, которые можно закрыть NAC, будут существовать в любой инфраструктуре.
Станислав Калабин уточнил, что сценарии будут распространяться не на всю инфраструктуру. В облачной инфраструктуре или большом VDI не получится перераспределить доступ так же, как в сети: когда-то была технология виртуального свитча с поддержкой 802.1X, но сейчас на рынке такого нет. В облаке сложно различать сессии, нет этого сегмента, и управлять сессией на уровне сети не получится. Он упомянул запросы на pxGrid и SGT-метки, но для их реализации нужно оборудование, которое это поддерживает.
Максим Хаванкин возразил, что у DECK AUTH есть Cloud First заказчик с облачной инфраструктурой, и история начиналась с OpenVPN. В Community Edition добавили свой плагин и возможность загружать ACL в систему, чтобы контролировать, что видит подключившийся к VPN. Следующий шаг — передать контекст подключения в файрвол, который стоит в облаке: пока есть активное VPN-подключение, есть IP-адрес из пула, который передаётся в security-группы файрвола.
В каких случаях NAC не решает проблему и может усложнить архитектуру?
Максим Хаванкин ответил коротко: серверная инфраструктура. Виртуальные машины перемещаются между портами, контейнеры зажигаются и гасятся, и желание контролировать это плохо заканчивается: машина переехала, нужна реаутентификация, а серверная инфраструктура не может позволить себе эти единицы секунд простоя. Для неё NAC использовать не нужно.
Станислав Калабин уточнил, что нежелательно, но иногда это вынужденная мера, например, когда серверы расположены не в серверной, а в ящике под столом в аэропорту, куда может попасть посетитель. Максим Ефремов добавил, что в таком случае разные информационные системы функционируют на одном железе, и нужно быстро и динамично назначать им сегменты VLAN, и здесь NAC буксует. Иногда приходится мириться с зазором в несколько секунд.
Какие три шага нужно сделать до конца года, чтобы улучшить управление доступом?
Максим Ефремов:
«Прийти к осознанию, что это нужно; провести пилот с любым вендором, чтобы понять, чего конкретно хочешь; сформировать чёткое техническое задание».
Александр Черных:
«Аналитика и видимость; если появились вопросы — формулирование базовых политик; автоматизация этих политик».
Станислав Калабин:
«Оценить сетевое оборудование, на которое будет распространяться NAC — сможет ли оно это реализовать или где-то придётся заменить оборудование или перестроить архитектуру».
Максим Хаванкин:
«Начать с сетевого оборудования, сформировать подъёмный план с простой политикой “свой-чужой”; затем прийти к вендору, взять систему, которая разворачивается быстро, и пробовать».
Финальный опрос показал, планируют ли зрители усиливать контроль сетевого доступа после этого эфира:
- Возможно, но пока это не в приоритете — 38%.
- Будут развивать существующие политики и интеграции — 32%.
- Планируют внедрение или крупное расширение NAC — 21%.
- Не видят необходимости в NAC — 6%.
- Текущая архитектура западного решения устраивает — 3%.
Рисунок 5. Планируете ли вы усиливать контроль сетевого доступа после этого эфира?
Выводы
Network Access Control перестал быть экзотикой и стал гигиеническим минимумом для корпоративной сети, которая разрастается и усложняется. Устройств становится в десятки и сотни раз больше, контролировать их классическими средствами уже невозможно, а Port Security не масштабируется на большие инфраструктуры. NAC не останавливается на решении пустить или не пустить: он продолжает мониторить состояние устройства, управляет подключением от начала до конца и передаёт контекст другим системам.
Ключевой элемент архитектуры — карантинный сегмент. Без него запускать NAC бессмысленно: всё, что подключается, нужно изолировать от ценных активов до того, как будет собран контекст. Профилирование помогает, но не является панацеей: ложные срабатывания случаются, а устройства могут мимикрировать под другие. Поэтому контекст нужно проверять заново при каждом подключении.
NAC работает в синергии с другими классами решений: VPN, посчерингом, каталогами, файрволами. В облачной инфраструктуре и серверной среде NAC не всегда применим: в облаке сложно различить сессии, а в серверной реаутентификация недопустима из-за простоев. Иногда это вынужденная мера, и тогда приходится мириться с зазором в несколько секунд.
Начать стоит с того, чтобы признать потребность в контроле, понять, какие возможности есть у сетевого оборудования, и определить простую границу между доверенными и недоверенными подключениями. После этого имеет смысл запустить пилот с вендором и сформировать реалистичный план, не пытаясь охватить всё сразу.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
