Cisco ISE — инструмент для создания системы контроля доступа в корпоративной сети.
То есть мы контролируем, кто, где и как подключается.
Мы можем определить клиентское устройство, насколько оно соответствует нашим политикам безопасности и так далее.
Cisco ISE — мощный механизм, позволяющий четко контролировать, кто находится в сети и какие ресурсы они используют. Мы решили рассказать о наших самых интересных проектах на базе Cisco ISE и заодно вспомнить пару необычных решений из нашей практики.
Что такое Cisco ISE
Cisco Identity Services Engine (ISE) — это контекстно-зависимое решение для контроля доступа к корпоративной сети.Решение сочетает в себе услуги аутентификации, авторизации и учета событий (AAA), оценки работоспособности, профилирования и управления гостевым доступом на одной платформе.
Cisco ISE автоматически идентифицирует и классифицирует конечные точки, обеспечивает необходимый уровень доступа путем аутентификации пользователей и устройств, а также обеспечивает соответствие конечных точек корпоративным политикам безопасности, оценивая состояние их безопасности перед предоставлением доступа к корпоративной ИТ-инфраструктуре.
Платформа поддерживает гибкие механизмы контроля доступа, включая группы безопасности (SG), теги групп безопасности (SGT) и списки управления доступом групп безопасности (SGACL).
Мы поговорим об этом ниже.
Немного нашей статистики
90% наших развертываний включают безопасность беспроводной сети.Наши клиенты очень разные.
Некоторые покупают новое топовое оборудование Cisco, а другие используют то, что есть, поскольку бюджет ограничен.
А вот для защищенного проводного доступа самые простые модели не подходят; необходимы определенные переключатели.
Но не у всех они есть.
Беспроводные контроллеры, созданные на основе решений Cisco, обычно требуют обновления только для поддержки Cisco ISE. Для беспроводного доступа обычно используется один контроллер и несколько точек.
А поскольку мы берёмся за беспроводной доступ, то большинство заказчиков — около 80% — хотят реализовать гостевой доступ, потому что удобно использовать одну и ту же инфраструктуру и для пользовательского, и для гостевого доступа.
Хотя отрасль движется в сторону виртуализации, половина наших клиентов выбирают аппаратные решения, чтобы избежать зависимости от среды виртуализации и предоставления ресурсов.
Устройства уже сбалансированы, имеют необходимое количество оперативной памяти и процессоров.
Клиентам не нужно беспокоиться о распределении виртуальных ресурсов; многие по-прежнему предпочитают занимать место в стойке, но при этом быть уверенными, что решение оптимизировано именно под данную аппаратную реализацию.
Наш стандартный проект
Каков наш типичный проект? Скорее всего это безопасность беспроводной сети и гостевой доступ.Мы все любим брать с собой на работу свои устройства и выходить с них в Интернет. Но даже сегодня не все гаджеты имеют GSM-модули.
Чтобы не снижать безопасность за счет подключения персональных устройств к корпоративной сети, предусмотрена инфраструктура BYOD, позволяющая автоматически или полуавтоматически регистрировать личное устройство.
Система поймет, что это ваш гаджет, а не корпоративный, и предоставит вам только доступ в Интернет. Как здесь это делается? Если вы возьмете с собой телефон и подключитесь через Wi-Fi, вам будет разрешено только онлайн.
Если вы подключите рабочий ноутбук по Wi-Fi, он также будет разрешен к сети офиса и ко всем ресурсам.
Это технология BYOD. Часто для защиты от поднесенных устройств мы также реализуем технологию EAP-chaining, которая позволяет аутентифицировать не только пользователей, но и рабочие станции.
То есть мы можем определить, доменный ноутбук или чей-то личный подключается к сети, и в зависимости от этого применить некоторые политики.
То есть помимо «аутентифицированный/неаутентифицированный» появляются критерии «домен/недомен».
На основе пересечения четырех критериев можно установить различные политики.
Например, доменная машина, а не доменный пользователь: это значит, что администратор пришел что-то настроить локально.
Скорее всего, ему потребуются специальные права в сети.
Если это доменная машина и доменный пользователь, то даем стандартный доступ в соответствии с привилегиями.
А если доменный пользователь, а не доменная машина, то этот человек принес свой личный ноутбук и его права доступа должны быть ограничены.
Мы также настоятельно рекомендуем всем использовать профилирование IP-телефонов и принтеров.
Профилирование — это процесс определения по косвенным признакам, какое устройство подключено к сети.
Почему это важно? Возьмем принтер.
Обычно он располагается в коридоре, то есть рядом находится розетка, которая зачастую не видна камере наблюдения.
Этим часто пользуются пентестеры и злоумышленники: они подключают небольшое устройство с несколькими портами к розетке, размещают его за принтером, и устройство может месяц серфить в сети, собирать данные и получать доступ.
Более того, принтеры не всегда ограничены в правах; в лучшем случае их перекинут в другой VLAN. Это часто приводит к угрозе безопасности.
Если мы настроим профилирование, то как только это устройство попадет в сеть, мы об этом узнаем, придем, вытащим его из розетки и выясним, кто его здесь оставил.
Наконец, мы регулярно используем позерство — проверяем пользователей на соответствие требованиям информационной безопасности.
Обычно мы применяем это к удаленным пользователям.
Например, кто-то подключился через VPN из дома или в командировке.
Часто ему нужен критический доступ.
Но нам очень сложно понять, хорошая ли у него информационная безопасность на личном или мобильном устройстве.
А позерство позволяет нам проверить, например, есть ли у пользователя актуальный антивирус, запущен ли он или есть ли у него обновления.
Таким образом, если не устранить ее, то хотя бы снизить риски.
Сложная задача
Теперь поговорим об интересном проекте.Один из наших клиентов купил 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 я делать не буду.
Мы написали продавцу.
Они взяли MAC-адрес от другого экземпляра этой конференц-станции, который отличался от нашего всего на несколько цифр — он был профилирован правильно.
Оказалось, что нам просто не повезло с адресом именно этой станции, и в результате Cisco чуть не выпустила для нее патч, после чего клиент тоже стал корректно профилироваться.
сержант
И напоследок хотелось бы рассказать об одном из самых интересных проектов последнего времени.Но сначала нужно напомнить о технологии под названием SGT (Security Group Tag).
Технология тегов группы безопасности Классический метод сетевого экранирования основан на IP-адресах источника и назначения хостов и их портах.
Но этой информации слишком мало, и при этом она жестко привязана к VLAN. В Cisco пришла очень простая хорошая идея: давайте присвоим метки SGT всем отправителям и получателям на нашем оборудовании и применим политику фильтрации устройств, согласно которой возможен обмен данными по протоколам A, B и C между метками 11 и 10 и между 11 и 20, а между 10 и 20 - невозможно.
То есть получается матрица разрешенных и запрещенных путей обмена данными.
Более того, в этой матрице мы можем использовать простые списки доступа.
Никаких IP-адресов у нас не будет, только порты.
Это позволяет проводить более атомарную и детализированную политику.
Архитектура 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-адресов .
- Обмен тегами .
Нам необходимо перенести назначенные метки туда, где они будут использоваться.
Для этого используется протокол SXP.
- Политика SGT .
Это матрица, о которой мы говорили выше; в нем указывается, какие взаимодействия можно использовать, а какие нет.
- Обеспечение соблюдения SGT .
Это то, что делают переключатели.
Интересный проект на базе SGT
Сейчас мы настроили сопоставление между IP и SGT для одного из наших клиентов, что позволило нам идентифицировать 13 сегментов.Они во многом перекрываются, но благодаря детализации, которая всегда выбирает наименьшее вхождение вплоть до конкретного хоста, мы смогли сегментировать все это.
ISE используется как единое хранилище для меток, политик и данных о соответствии IP и SGT. Сначала мы определили метки: 12 — разработка, 13 — производство, 11 — тестирование.
Далее определили, что между 12 и 13 можно общаться только по протоколу HTTPS, между 12 и 11 взаимодействия быть не должно и так далее.
Результатом стал список сетей и хостов с соответствующими метками.
А вся система реализована на четырёх Nexus 7000 в дата-центре заказчика.
Какие преимущества получил клиент? Атомная политика теперь доступна ему.
Бывает, что в одной из сетей администраторы по ошибке разворачивают сервер из другой сети.
Например, хост из производства затерялся в сети разработки.
В результате вам потом придется перемещать сервер, менять IP и проверять, не нарушены ли соединения с соседними серверами.
Но теперь можно просто микросегментировать «чужой» сервер: объявить его частью производства и применить к нему другие правила, в отличие от участников остальной сети.
И при этом хост будет защищен.
Кроме того, теперь клиент может хранить политики и управлять ими централизованно и отказоустойчиво.
Но было бы действительно здорово использовать ISE для динамического присвоения меток пользователям.
Мы сможем сделать это не только на основе IP-адреса, но и в зависимости от времени, местоположения пользователя, его домена и учетной записи.
Можно констатировать, что если этот пользователь сидит в головном офисе, то у него есть только привилегии и права, а если он приходит в филиал, то он уже в командировке и имеет ограниченные права.
Еще хотелось бы посмотреть логи самого ISE. Теперь при использовании четырех Nexus и ISE в качестве централизованного хранилища приходится обращаться к самому коммутатору для просмотра логов, ввода запросов в консоль и фильтрации ответов.
Если мы будем использовать Dynamic Mapping, то ISE начнет собирать логи, и мы сможем централизованно увидеть, почему определенный пользователь не попал в определенную структуру.
Но пока эти возможности не реализованы, поскольку заказчик решил защитить только дата-центр.
Соответственно, пользователи приходят извне и они не подключены к ISE.
История развития Cisco ISE
Верификационный центр Это важное нововведение появилось в версии 1.3 в октябре 2013 года.Например, у одного из наших клиентов были принтеры, которые работали только с сертификатами, то есть могли аутентифицироваться не по паролю, а только по сертификату в сети.
Клиент расстроился, что не может подключить устройства из-за отсутствия ЦС, а разворачивать его ради пяти принтеров он не хотел.
Далее с помощью встроенного API мы смогли выдавать сертификаты и подключать принтеры стандартным способом.
Поддержка изменения авторизации Cisco ASA (CoA) С момента внедрения поддержки CoA в Cisco ASA мы можем отслеживать не только пользователей, которые приходят в офис и подключаются к сети, но и удаленных пользователей.
Конечно, мы могли сделать это и раньше, но для этого требовалось отдельное устройство узла IPN для применения политик авторизации, которые проксировали трафик.
То есть помимо того, что у нас есть межсетевой экран, терминирующий VPN, нам пришлось использовать еще одно устройство просто для применения правил в Cisco ISE. Это было дорого и неудобно.
В версии 9.2.1 в декабре 2014 года вендор наконец-то добавил поддержку смены авторизации в Cisco ASA, в результате стал поддерживаться весь функционал Cisco ISE. Несколько наших клиентов вздохнули от радости и смогли использовать освободившийся узел IPN для большей выгоды, чем просто терминация VPN-трафика.
ТАКАКС+ Мы все очень долго ждали реализации этого протокола.
TACACS+ позволяет аутентифицировать администраторов и регистрировать их действия.
Эти возможности очень часто востребованы в проектах PCI DSS для мониторинга администраторов.
Раньше для этого существовал отдельный продукт Cisco ACS, который медленно умирал, пока Cisco ISE наконец не взяла на себя его функциональность.
Положение AnyConnect Появление этой функциональности в AnyConnect стало одной из прорывных особенностей Cisco ISE. Особенность можно увидеть на следующем фото.
Как выглядит процесс постуринга: пользователь проходит аутентификацию (по логину, паролю, сертификату или MAC), а в ответ Cisco ISE получает политику с правилами доступа.
Если необходимо проверить пользователя на соответствие, ему отправляется редирект — специальная ссылка, которая перенаправляет весь или часть трафика пользователя на определенный адрес.
В этот момент у клиента установлен специальный агент для позирования, который время от времени выходит в интернет и ждет. Если его перенаправить на сервер ISE, он возьмет политику оттуда, с ее помощью проверит рабочую станцию на соответствие и сделает какие-то выводы.
Раньше агент проверял URL-адрес раз в пять минут. Это было долго, неудобно и в то же время захламляло сеть пустым трафиком.
Наконец, этот механизм был включен в AnyConnect. Он на сетевом уровне понимает, что с ней что-то случилось.
Допустим, мы подключились или переподключились к сети, или подключились к Wi-Fi, или построили VPN — AnyConnect узнает обо всех этих событиях и послужит триггером для агента.
Благодаря этому время ожидания начала позы изменилось с 4-5 минут до 15 секунд.
Исчезновение функции
Был интересный случай с функционалом, который сначала пропал в одной из версий, а через некоторое время его вернули.Cisco ISE имеет учетные записи гостевого доступа: сеть, в которой даже секретари могут выдавать пароли.
И есть очень удобная функция, когда системный администратор может создать кучу гостевых аккаунтов, запечатать их в конверты и передать ответственному лицу.
Эти аккаунты будут действительны в течение строго определенного времени.
Например, в нашей компании с момента первого входа в систему проходит неделя.
Пользователю дают конверт, он его распечатывает, заходит, и счетчик начинает тикать.
Удобно и практично.
Эта функциональность изначально присутствовала при появлении Cisco ISE, но исчезла в версии 1.4. А через несколько лет в версии 2.1 его вернули.
Из-за отсутствия гостевого доступа мы более двух лет даже не обновляли версию Cisco ISE в нашей компании, поскольку не были готовы перестраивать под это наши бизнес-процессы.
* * *
Забавная ошибка
На прощание я вспомнил забавную историю.Помните, мы говорили о клиенте с очень строгой политикой безопасности? Он расположен на Дальнем Востоке, и однажды часовой пояс там изменился - вместо GMT+10 стало GMT+11. А так как у заказчика была только настройка «Азия/Сахалин», он обратился к нам с просьбой реализовать точное отображение времени.
Написали в Cisco, они ответили, что в ближайшее время не будут обновлять часовые пояса, потому что это занимает слишком много времени.
Они предложили использовать стандартную зону GMT+11. Мы его настроили, и оказалось, что Cisco недостаточно протестировала свой продукт: пояс стал GMT-11. То есть время клиента истекло на 12 часов.
Что забавно, в GMT+11 — Камчатка и Сахалин, а в GMT-11 — два американских острова.
То есть Cisco просто не предполагала, что кто-то из этих часовых поясов будет покупать у них продукт, и не проводила тесты.
Они потратили довольно много времени, исправляя эту ошибку и принося извинения.
Станислав Калабин, эксперт отдела службы инженерного обеспечения и информационной безопасности, «Инфосистемы Джет» Теги: #информационная безопасность #cisco #cisco #cisco ise
-
Преимущества Колокейшн В Мичигане
19 Oct, 24 -
Как Работает Массив В Swift
19 Oct, 24 -
Бытовой Компьютер Atari 520Stf
19 Oct, 24 -
Гугл = Анб 2.0?
19 Oct, 24
