Практика внедрения Cisco ISE. Взгляд инженера
Cisco ISE — это инструмент для создания системы управления доступом к корпоративной сети. То есть мы контролируем, кто подключается, откуда и как. Можем определить клиентское устройство, насколько оно соответствует нашим политикам безопасности, и прочее. Cisco ISE — мощный механизм, который позволяет четко контролировать, кто находится в сети и какими ресурсами он пользуется. Мы решили рассказать о наших наиболее интересных проектах на основе Cisco ISE и заодно вспомнить парочку необычных решений из своей практики.
Что такое Cisco ISE
Cisco Identity Services Engine (ISE) представляет собой решение для контроля доступа к корпоративной сети с учетом контекста доступа. Решение объединяет сервисы аутентификации, авторизации и учета событий (AAA), оценки состояния, профилирования и управления гостевым доступом в рамках единой платформы. Cisco ISE автоматически выявляет и классифицирует оконечные устройства, обеспечивает нужный уровень доступа, проводя аутентификацию как пользователей, так и устройств, а также обеспечивает соответствие оконечных устройств корпоративной политике ИБ путем оценки их состояния защищенности перед предоставлением доступа к корпоративной ИТ-инфраструктуре. Платформа поддерживает гибкие механизмы контроля доступа, включая группы безопасности (SGA), метки групп безопасности (SGT) и списки контроля доступа групп безопасности (SGACL). Об этом поговорим ниже.
Немного нашей статистики
90% наших внедрений содержат в себе защиту беспроводного доступа. Заказчики у нас очень разные. Кто-то скупает новое топовое оборудование Cisco, а кто-то использует то, что есть, потому что бюджет ограничен. Но для безопасного проводного доступа самые простые модели не подходят, нужны определенные коммутаторы. А они есть не у всех. Контроллеры беспроводного доступа, если он построен на базе решений Cisco, как правило требует только обновления для поддержки Cisco ISE.
Для беспроводного доступа обычно используется один контроллер и куча точек. А раз мы беремся за беспроводной доступ, то большинство заказчиков — около 80% — хотят реализовать и гостевой доступ, потому что удобно использовать одну и ту же инфраструктуру и для пользовательского доступа, и для гостевого.
Хотя индустрия движется в сторону виртуализации, половина наших заказчиков выбирает аппаратные решения, чтобы не зависеть от среды виртуализации и выделения ресурсов. Устройства уже сбалансированы, в них есть нужное количество оперативной памяти и процессоров. Клиентам можно не беспокоиться о выделении виртуальных ресурсов, многие до сих пор предпочитают занять место в стойке, но при этом быть спокойными, что решение оптимизировано именно под эту аппаратную реализацию.
Наш типовой проект
Что собой представляет наш типовой проект? С высокой вероятностью это защита беспроводного доступа и гостевой доступ. Все мы любим приносить на работу свои собственные устройства и выходить с них в интернет. Но даже сегодня не во всех гаджетах есть GSM-модули. Чтобы не снижать безопасность из-за подключения к корпоративной сети личных устройств, выделяется инфраструктура BYOD, которая позволяет в автоматическом или полуавтоматическом режиме зарегистрировать личное устройство. Система будет понимать, что это ваш гаджет, а не корпоративный, и будет предоставлять вам только доступ в интернет.
Как сделано у нас? Если вы принесете свой телефон и подключитесь по Wi-Fi, вас выпустят только в интернет. Если вы подключите по Wi-Fi рабочий ноутбук, его будут пускать еще и в офисную сеть и ко всем ресурсам. Это и есть технология BYOD.
Зачастую для защиты от принесенных устройств мы также реализуем технологию EAP-chaining, которая позволяет аутентифицировать не только пользователей, но и рабочие станции. То есть мы можем определить, подключается ли к сети доменный ноутбук или чей-то личный, и в зависимости от этого применять какие-то политики.
То есть кроме «аутентифицированный/не аутентифицированный» появляются критерии «доменный/не доменный». На основе пересечения четырех критериев можно задавать разные политики. Например, доменная машина, но не доменный пользователь: значит, администратор пришел что-то локально настроить. Скорее всего, ему будут нужны особенные права в сети. Если же это доменная машина и доменный пользователь, значит, даем стандартный доступ в соответствии с привилегиями. А если доменный пользователь, но не доменная машина, это человек принес свой личный ноутбук и его надо ограничить в правах доступа.
Также мы обязательно рекомендуем всем использовать профилирование для IP-телефонов и принтеров. Профилирование — это определение по косвенным признакам, что же за устройство подключилось к сети. Почему это важно? Возьмем принтер. Обычно он стоит в коридоре, то есть поблизости есть розетка, на которую зачастую не смотрит камера наблюдения. Этим часто пользуются пентестеры и злоумышленники: подключают к розетке небольшое устройство с несколькими портами, кладут за принтером, и девайс может месяц гулять по сети, собирать данные, получать доступы. Тем более что принтеры не всегда ограничивают в правах, в лучшем случае закинут в другой VLAN. Зачастую это приводит к возникновению угрозы безопасности. Если же настроить профилирование, то, как только это устройство войдет в сеть, мы об этом узнаем, придем, вынем из розетки и разберемся, кто же его здесь оставил.
Наконец, мы регулярно используем posturing — проверяем пользователей на соответствие требованиям информационной безопасности. Обычно мы применяем это к удаленным пользователям. Например, кто-то подключился по VPN из дома или командировки. Часто ему нужен критичный доступ. Но нам очень сложно понять, хорошо ли у него с информационной безопасностью на личном или мобильном устройстве. И posturing позволяет нам проверить, например, актуальный ли у пользователя антивирус, запущен ли он, есть ли у него обновления. Так можно если не исключить, то хотя бы снизить риски.
Хитрая задача
А сейчас расскажем о любопытном проекте. Один из наших клиентов еще много лет назад купил Cisco ISE. Политика информационной безопасности в компании очень жесткая: зарегламентировано всё, что можно, не допускается подключение к сети чужих устройств, то есть никакого вам BYOD. Если пользователь отключил свой компьютер из одной розетки и подключил в соседнюю, это уже инцидент информационной безопасности. Антивирус с максимальным уровнем эвристики, локальный файрвол запрещает любые входящие соединения.
Заказчик очень хотел получать информацию о том, какие корпоративные устройства подключаются к сети, какая там версия ОС, и прочее. На основе этого он формировал политику безопасности. Нашей системе для определения устройств требовались разные косвенные данные. Самым хорошим вариантом являются DHCP-пробы: для этого нам нужно получать копию DHCP-трафика, либо копию DNS-трафика. Но заказчик категорически отказался передавать нам трафик из своей сети. А других эффективных проб в его инфраструктуре не было. Стали думать, как же нам определить рабочие станции, на которых стоит файрвол. Просканировать снаружи мы не можем.
В конце концов решили использовать протокол LLDP, аналог протокола Cisco CDP, по которому сетевые устройства обмениваются информацией о себе. Например, коммутатор отсылает другому коммутатору сообщение: «я коммутатор, у меня 24 порта, есть вот такие VLAN, вот такие настройки».
Нашли подходящий агент, поставили его на рабочую станцию, и он отсылал нашим коммутаторам данные о подключенных компьютерах, их ОС и составе оборудования. При этом нам очень повезло, что ISE позволил создавать кастомные политики профилирования на основе получаемых данных.
С тем же заказчиком вышел и не самый приятный случай. В компании была конференц-станция Polycom, которая обычно ставится в переговорках. Cisco купила Polycom несколько лет назад, и поэтому станция должна была профилироваться из коробки, необходимые встроенные политики содержались в Cisco ISE. ISE ее видел и поддерживал, но у заказчика станция профилировалась неправильно: определялась как IP-телефон без указания конкретной модели. А заказчик хотел определять, в каком конференц-зале какая модель стоит.
Начали выяснять. Первичное профилирование устройства выполняется на основе MAC-адреса. Как вы знаете, первые шесть цифр MAC уникальны для каждой компании и зарезервированы в блоке. В ходе профилирования этой конференц-станции мы включили режим отладки и увидели в журнале очень простое событие: ISE брал MAC и говорил, что это Polycom, а не Cisco, поэтому никаких опрашиваний по CDP и LLDP я делать не буду.
Мы написали вендору. От другого экземпляра этой конференц-станции они взяли МАС-адрес, который лишь считанными цифрами отличался от нашего — профилировалось корректно. Оказалось, что нам просто не повезло с адресом этой конкретной станции, и в результате Cisco чуть ли не под нее выпустила патч, после которого у клиента тоже стало профилироваться корректно.
SGT
И напоследок хочется рассказать об одном из самых интересных проектов последнего времени. Но сначала нужно напомнить о технологии под названием SGT (Security Group Tag).
Архитектура SGT состоит из четырех компонентов.
- Метки. В первую очередь нам нужно присвоить SGT-метки. Это можно сделать четырьмя способами.
- На основе IP-адресов. Мы говорим, что такая-то сеть является внутренней, а дальше на основе конкретных IP-адресов можем конкретизировать: например, сеть 10.31.10.0/24 — серверный сегмент, к нему одни правила применять. Внутри этого серверного сегмента у нас есть сервер, который отвечает за PCI DSS — к нему применяем более строгие правила. При этом не нужно выносить сервер из сегмента.
Почему это полезно? Когда мы хотим где-то внедрить сетевой экран, сделать более строгие правила, нам нужно разместить сервер в инфраструктуре заказчика, которая часто развивается не вполне управляемо. О том, что серверу не стоит общаться с соседним сервером, что лучше выделить его в отдельный сегмент, никто не подумал. И когда мы внедряем межсетевой экран, больше всего времени уходит на перенос серверов по нашим рекомендациям из одних сегментов в другие. А в случае с SGT это не требуется.
- На основе VLAN. Можно задать, что VLAN1 — это метка 1, VLAN10 — метка 10, и так далее.
- На основе портов коммутатора. То же самое можно сделать и применительно к портам: к примеру, все данные, приходящие с порта 24 коммутатора, помечать меткой 10.
- И последний, самый интересный способ — динамическое присвоение меток с помощью ISE. То есть Cisco ISE может не только присваивать ACL, отправлять на редирект и прочее, но и назначать SGT-метку. В результате мы можем динамически определять: этот пользователь пришел из этого сегмента, в такое время, у него такая доменная учетная запись, такой IP-адрес. И уже на основе этих данных мы присваиваем метку.
- На основе IP-адресов. Мы говорим, что такая-то сеть является внутренней, а дальше на основе конкретных IP-адресов можем конкретизировать: например, сеть 10.31.10.0/24 — серверный сегмент, к нему одни правила применять. Внутри этого серверного сегмента у нас есть сервер, который отвечает за PCI DSS — к нему применяем более строгие правила. При этом не нужно выносить сервер из сегмента.
- Обмен метками. Назначенные метки нам нужно передать туда, где они будут применяться. Для этого используется протокол SXP.
- SGT-политика. Это матрица, о которой мы говорили выше, в ней прописано, какие взаимодействия можно использовать, а какие нельзя.
- Принудительное применение SGT. Этим занимаются коммутаторы.
Наш первый проект на основе SGT
Сейчас у одного из заказчиков мы настроили сопоставление IP и SGT, что позволило выделить 13 сегментов. Они во многом пересекаются, но благодаря гранулярности, при которой всегда выбирается самое нижнее вхождение вплоть до конкретного хоста, мы смогли все это сегментировать. ISE используется как единое хранилище для меток, политик и данных о соответствии IP и SGT. Сначала мы определили метки: 12 — разработка, 13 — это production, 11 — тестирование. Далее определили, что между 12 и 13 можно взаимодействовать только по протоколу HTTPS, между 12 и 11 не должно быть взаимодействия, и так далее. В результате получился перечень сетей и хостов с соответствующими им метками. И вся система реализована на четырех Nexus 7000 в ЦОД заказчика.
Какие выгоды получил заказчик?
Теперь ему доступны атомарные политики. Бывает, что в одной из сетей администраторы по ошибке развертывают сервер из другой сети. Например, в сети разработки затерялся хост из production. В результате потом приходится переносить сервер, менять IP, проверять, не нарушились ли связи с соседними серверами. Но теперь можно просто микросегментировать «чужеродный» сервер: объявить его частью production и применять к нему другие правила, в отличие от участников остальной сети. И при этом хост будет защищен.
Кроме того, теперь заказчик может централизованно и отказоустойчиво хранить политики и управлять ими.
Но было бы по-настоящему круто применять ISE для динамического присвоения меток пользователям. Мы сможем делать это не только на основе IP-адреса, но и в зависимости от времени, от местоположения пользователя, от его доменной и учетной записи. Сможем прописать, что если этот пользователь сидит в головном офисе, то он имеет одни привилегии и права, а если он приехал в филиал, то он уже командированный и у него ограниченные права.
Еще хотелось бы смотреть логи на самом ISE. Сейчас при использовании четырех Nexus и ISE в качестве централизованного хранилища приходится для просмотра логов обращаться к самому коммутатору, вбивая в консоли запросы и фильтруя ответы. Если же воспользоваться Dynamic Mapping, то ISE начнет собирать логи, и мы сможем централизованно посмотреть, почему же какой-то пользователь не попал в определенную структуру.
Но пока что эти возможности не реализованы, потому что заказчик решил защитить только ЦОД. Соответственно, пользователи приходят снаружи, и они не подключены к ISE.
История развития Cisco ISE
Удостоверяющий центр
Это важное нововведение появилось в версии 1.3 в октябре 2013 года. К примеру, у одного из наших клиентов были принтеры, которые работали только с сертификатами, то есть умели аутентифицироваться не по паролю, а только по сертификату в сети. Клиент был расстроен, что не мог подключить устройства из-за отсутствия УЦ, а ради пяти принтеров развёртывать его не хотелось. Тогда мы при помощи встроенного API смогли выпустить сертификаты и подключить принтеры штатным способом.
Поддержка Cisco ASA CoA
С момента появления поддержки COa на Cisco ASA мы можем контролировать не только пользователей, которые приходят в офис и подключаются к сети, но и удаленных пользователей. Конечно, мы могли это делать и раньше, но для этого нужно было отдельное устройство IPN node для применения политик авторизации, которое проксировало трафик. То есть помимо того, что у нас есть сетевой экран, который терминирует VPN, приходилось использовать ещё одно устройство только для применения правил в Cisco ISE. Это было дорого и неудобно.
В версии 9.2.1 в декабре 2014 вендор, наконец, добавил в Cisco ASA поддержку change of authorization, в результате стала поддерживаться вся функциональность Cisco ISE. Несколько наших клиентов радостно вздохнули и смогли использовать высвободившиеся IPN node с большей пользой, чем просто терминировать трафик VPN.
TACACS+
Все мы очень долго ждали внедрения этого протокола. TACACS+ позволяет аутентифицировать администраторов и журналировать их действия. Эти возможности очень часто востребованы в проектах PCI DSS по контролю за администраторами. Раньше для этого был отдельный продукт Cisco ACS, который потихоньку умирал, пока Cisco ISE не забрал себе наконец его функционал.
AnyConnect Posture
Появление этой функциональности в AnyConnect стало одной из прорывных фич Cisco ISE. В чем особенность видно на следующем слайде. Как выглядит процесс posturing«а: пользователь аутентифицируется (по логину, паролю, сертификату либо MAC), а ему в ответ от Cisco ISE прилетает политика с правилами доступа.
Если нужно проверить пользователя на соответствие, ему присылается redirect — специальная ссылка, которая весь или часть трафика пользователя перенаправляет на определенный адрес. У клиента в этот момент для posturing«а установлен агент, который время от времени выходит в интернет и ждет. Если его перенаправят на сервер ISE, то он заберет оттуда политику, с её помощью проверит рабочую станцию на соответствие и сделает какие-то выводы.
Раньше агент ходил и проверял URL раз в пять минут, это было долго, неудобно и при этом захламляло пустым трафиком сеть. Наконец этот механизм включили в AnyConnect. Он на уровне сети понимает, что с ней что-нибудь произошло. Допустим, мы подключились или переподключились к сети, или подключились к Wi-Fi, или построили VPN — обо всех этих событиях AnyConnect узнает и сработает как триггер для агента. Благодаря этому время ожидания начала posturing«а изменилось с 4–5 минут до 15 секунд.
Исчезновение фичи
Был интересный случай с функциональностью, которая сначала исчезла в одной из версий, а спустя некоторое время её вернули.
В Cisco ISE есть учетные записи для гостевого доступа: сеть, в которой пароли могут выдавать даже секретари. И есть очень удобная функция, когда администратор системы может наделать пачку учетных записей, запечатать в конверты и отдать ответственному. Действовать эти учетные записи будут строго определенное время. Например, у нас в компании это неделя с момента первого входа. Пользователю дают конверт, он его распечатывает, заходит, счетчик начинает тикать. Удобно и практично.
Изначально эта функциональность была с момента появления Cisco ISE, но в версии 1.4 исчезла. И через несколько лет, в версии 2.1 её вернули. Из-за отсутствия гостевого доступа мы даже больше двух лет не обновляли Cisco ISE, потому что не готовы были ради этого перестраивать свои бизнес-процессы.
* * *
Забавный баг
На прощание вспомнилась забавная история. Помните, мы рассказывали про клиента с очень строгой политикой безопасности? Он находится на Дальнем Востоке, и однажды там поменялся часовой пояс — вместо GMT+10 стал GMT+11. А поскольку у заказчика было настроено просто «Asia/Sakhalin», он обратился к нам, чтобы мы реализовали точное отображение времени.
Мы написали в Cisco, там ответили, что в ближайшее время не будут обновлять часовые пояса, потому что слишком долго. Предложили использовать стандартную зону GMT+11. Мы ее настроили, и выяснилось, что в Cisco недостаточно тестировали свой продукт: пояс стал GMT-11. То есть у клиента время уехало на 12 часов. Что самое забавное, в GMT+11 находится Камчатка и Сахалин, а в GMT-11 — два американских острова. То есть в Cisco просто не предполагали, что у них кто-нибудь будет покупать продукт из этих часовых поясов, и не провели тесты. Они еще довольно долго исправляли этот баг, извинялись.
Станислав Калабин, эксперт инженерной поддержки и сервиса ИБ, «Инфосистемы Джет»
