Как реализуется контроль сетевого доступа внутри компании Cisco?

    Знаете ли вы что из себя представляет сеть компании Cisco? Вот несколько цифр, показывающих масштаб стоящих перед нашими ИТ- и ИБ-службами задач:

    • 3 миллиона IP-адресов
    • 40 тысяч маршрутизаторов
    • 215 тысяч инфраструктурых устройств
    • 120 тысяч пользователей
    • 275 тысяч узлов, из которых 135 тысяч лэптопы и десктопы и 68 тысяч — мобильные устройства на платформах iOS, Android, BlackBerry, Windows и других
    • Офисы в 170 странах мира
    • 26 тысяч домашних офисов
    • 1350 лабораторий
    • 300 бизнес-партнеров, имеющих доступ к нашей инфраструктуре (логистика, производство, разработка, тестирование и т.п.)
    • свыше 700 облачных провайдеров услуг, которыми мы пользуемся в своей повседневной деятельности.

    Очевидно, что столь масштабная и распределенная сеть, да еще и с нечетким периметром, нуждается в адекватной защите и контроле доступа. Будь у нас одна точка выхода в Интернет, отсутствие внешних подключений, запрет корпоративных и собственных мобильных устройств (BYOD), а также гарантия отсутствия случайных или умышленных подключений к посторонним Wi-Fi-точкам или использования 3G/4G-модемов, мы бы могли сконцентрироваться на защите периметра и жить припеваючи. Но увы… Cisco давно ушла от периметрового подхода и не только размыла свои границы, дав сотрудникам мобильные устройства, переведя их на работу с лэптопами и обеспечив «домашними офисами», но и предоставила доступ к своей инфраструктуре своим бизнес-партнерам, которые наполняют наши склады, забирают готовую продукцию, занимаются разработкой отдельных компонент наших решений, обеспечивают производство и т.п. Но и это не все. С целью оптимизации ресурсов компании и ИТ-службы мы ушли в облака, заключив договора с более чем 700 различными облачными провайдерами, предоставляющими нам широкий спектр услуг — телеконференции, CRM, хранение файлов, корпоративные социальные сети, кадровый и бухгалтерский учет, BI и т.п. Наконец не стоит забывать про периферийное оборудование типа принтеров, IP-телефонов и персональных систем TelePresence, а также различные Интернет-“вещи” — термостаты, освещение, пожарная сигнализация, системы контроля физического доступа и т.п. Все это СЕТЬ компании Cisco, доступ к которой нужно контролировать.

    Пытаться решить задачу контроля такой разнообразной инфраструктуры в лоб, прописывая правила на каждом инфраструктурном устройстве (точке доступа, коммутаторе или маршрутизаторе) по принципу “узлу А разрешить доступ к узлу Б”, можно но уже на 10-м устройстве мы поймем, что погорячились (при описанном выше количестве устройств в сети Cisco). Это не только займет время на прописывание и проверку списков контроля доступа, но и снизит производительность сетевых устройств, которые будут вынуждены проверять каждый пришедший фрейм или пакет на соответствие ACL. А если вспомнить еще про мобильность наших сотрудников, которые могут находиться в разных местах корпоративной сети или за ее пределами (и все это в течение одного дня), то задание статических правил не только неэффективно, но и невозможно. В конечном итоге все правила превратятся в классическое “всем разрешено все и всюду”, которое явно не является примером того, к чему стоит стремиться.

    Поэтому мы стали решать проблему по частям и сверху вниз. Сначала была определена политика “по крупному”, используя всего два атрибута, — уровень доверия и возможности по доступу. Получилась высокоуровневая матрица, которая позволила сгруппировать все вышеупомянутые типы устройств и пользователей всего в 4 больших блока. Данная матрица позволила нам определиться с ответом на вопрос “кого/что пускать в нашу сеть”.

    Высокоуровневая матрица доступа

    Однако ограничиваться банальной аутентификацией пользователей или устройств мы не стали (хотя это уже немало). Все-таки при том уровне мобильности сотрудников Cisco, возможна ситуация, когда находясь неделю-другую (а бывают и месячные командировки) в отлучке от корпоративной сети, сотрудник может подхватить какую-либо заразу на свой ноутбук или планшет. Поэтому помимо аутентификации надо было проверять еще и состояние устройства — наличие необходимых средств защиты, антивируса, актуальных антивирусных баз, патчей, а для смартфонов или планшетников еще и наличие джейлбрейка, включенного шифрования, установленного PIN-кода определенной длины и т.д.

    Часть политики доступа

    Выбрав на первом этапе в качестве атрибута политики доверие, мы определились для себя, что, например:

    • подключение из внутренней сети является более доверенным, чем из внешней,
    • подключение через VPN более надежно, чем из Интернет,
    • доступ по Wi-Fi должен проверяться не так, как проводное подключение,
    • гостевое мобильное устройство менее доверенно мобильного устройства сотрудника,
    • и т.п.

    Иными словами, ответив на вопрос “кто подключается и что”, мы также включили в нашу политику сетевого доступа ответ на вопрос “как осуществляется подключение к сети Cisco?”.

    Часть политики доступа

    Достаточно ли ответов на эти три вопроса для защиты сетевого доступа? Для защиты возможно и да, но не для решения всех вопросов, стоящих перед различными подразделениями Cisco. Ведь помимо службы ИБ в контроле сетевого доступа заинтересованы и другие структуры нашей компании. Например, ИТ, которое хотело бы знать о том, какие типы устройств используют сотрудники чаще всего? Это позволило бы оптимизировать внутренние приложения для работы с наиболее активно используемым ПО. Служба безопасности хотела бы знать, кем и в какое время осуществлялась та или иная попытка доступа и, при необходимости, ограничивать ее. Например, гости не могут находиться в наших офисах вне рабочего времени (то есть с 9.30 до 18.30 в Москве или с 8.00 до 17.00 в США). А значит и доступ к нашей гостевой беспроводной сети им в “ночное” время не нужен (в отличие от сотрудников, которые могут работать и ночью).

    Часть политики доступа

    Департамент разработки выставил требования по использованию географических атрибутов в качестве элемента политики доступа. Не секрет, что у Cisco разработка ПО ведется не в каждом офисе, а сосредоточена всего в нескольких точках земного шара. Поэтому сотрудникам офиса в австралийском Брисбене врядли нужен доступ к серверам, расположенным в индийском Бангалоре, и хранящим исходные коды нашего ПО. Compliance-служба, следящая за соблюдением различных нормативных требований, имеет свои требования к сетевому доступу. Например, для выполнения определенных договоров требуется привлечение ограниченного количества сотрудников и только имеющих определенное гражданство (да, и такое бывает). Или, например, для выполнения требований отечественного 242-го закона о локализации баз данных персональных данных российских граждан.

    Наконец, каждое подразделение имеет свой набор используемых в работе данных, к которым должны иметь доступ сотрудники только этого подразделения и никто иной. Например, отдел кадров работает с персональными данными сотрудников, бухгалтерия — с зарплатными ведомостями, ИТ — с Active Directory, безопасность — с видеонаблюдением, разработчики — с системами контроля версий исходных кодов и с системами их динамического или статического анализа. То есть в политике должно быть учтено и роль субъекта доступа в оргштатной структуре компании.

    Иными словами политика сетевого доступа в Cisco опирается не на один атрибут (кто/что), а учитывает множество факторов, отвечающих на следующие вопросы:

    • КТО подключается?
    • ЧТО подключается?
    • КАК осуществляется подключение?
    • ГДЕ находится подключаемые устройство или пользователь?
    • ОТКУДА осуществляется доступ?
    • КОГДА осуществляется доступа?
    • КАКИЕ УСЛОВИЯ должны быть соблюдены для предоставления доступа?

    Атрибуты политики сетевого доступа

    Сразу скажу, что мы не сразу реализовали такую политику. Было бы лукавством утверждать такое. Мы долго шли к ней. Ключевым фактором успеха явилось не столько понимание необходимости реализовать гибкие сценарии доступа, зависящие от комбинации разных атрибутов (а не только КТО + КУДА + КОГДА), сколько возможность ответить на каждый из перечисленных выше вопросов. Без этого политику сетевого доступа в Cisco было бы реализовать невозможно. Тут пришлось покорпеть, чтобы составить списки ролей и имеющих ресурсов, сопоставить их с конкретными сотрудниками, увязать ИТ-сервисы с HR-службой, и выполнить ряд других, так нелюбимых и часто называемых «бумажной безопасностью» действий. Ну и, конечно, хорошим подспорьем стал выход системы Cisco ISE (Identity Service Engine), которая и помогла автоматизировать процесс создания, внедрения и контроля политики сетевого доступа в сетевой инфраструктуре Cisco. Без него (мы пару лет назад про него на Хабре уже писали) все наши благие намерения по динамичному и гибкому доступу людей и устройств к нашим ресурсам так и остались бы красивой идеей, не вышедшей за пределы доски, на которой это все было нарисовано. ISE помог нам это все воплотить в жизнь.

    Пример расширенной политики доступа

    Сейчас стало модно использовать термин “agile”. Так вот могу сказать, что нам удалось реализовать сетевой доступ именно в стиле agile. Динамичная среда с постоянно изменяющимися условиями доступа — это и есть сеть Cisco, в которой доступ должен предоставляться оперативно (и без кучи бумажек и заявок) и автоматически, без постоянно привлечения сотрудников разных служб, дающих “добро” на доступ. Такое работает в сети из одного коммутатора, одного администратора и десяти сотрудников. Когда число контролируемых субъектов и объектов доступа измеряется сотнями тысяч, то только agile или иными словами динамический контроль сетевого доступа способен помочь решить поставленную задачу. И в Cisco нам это удалось сделать.

    ЗЫ. Да, предвосхищая возможный вопрос о том, на каком оборудовании построена сеть Cisco, отвечаю — на оборудовании Cisco (как это ни странно :-) Однако описанные принципы не зависят от того, что лежит в основе сети, — они универсальны. А вот решение, реализующее политику, основанные на этих принципах, уже является вендор-зависимым. В случае с Cisco ISE он работает с сетевым оборудованием Cisco, HP, Ruckus, Aruba, Motorola, Brocade. Не уверен, но схема должна работать и на других вендорах, например, китайских, если они поддерживают тот же 802.1x и стандартные механизмы управления (SSH, Telnet, SNMP).
    Cisco 81,93
    Cisco – мировой лидер в области сетевых технологий
    Поделиться публикацией
    Комментарии 32
    • 0
      А какой тип фильтрации используется? DACL или SGT?
      • 0
        Все варианты применяем. Технология SGT в процессе внедрения во всей нашей
    • 0
      Я правильно понимаю, что у вас несколько несвязанных между собой ISE доменов? Как происходит деление? По региону? И синхронизируются ли правила?
      • 0
        Раньше было несколько кластеров. Сейчас ISE один, но мы не всю сеть еще закрыли и поэтому в потолок 250 тысяч активных устройств и до 1 миллиона зарегистрированных устройств пока не уперлись.
        • 0
          А как вы собираетесь жить с ограничением в 65536 SGT с таким количеством EndPoints? =) и сколько у вас сейчас правил авторизации?
          И еще момент — по вашим же рекомендациям, между ADM-нодой и PSN должен быть RTT <= 100-150 ms. Как вы планируете это обходить, если вам нужно накрывать, считай, весь шарик? Размещать PSN централизованно в HQ, например?
          • 0
            А зачем каждому endpoint свой SGT? Я же выше обрисовал, что мы активно группируем устройства и пользователей по атрибутам
            • 0
              ну допустим. А по остальным вопросам? ;) и сколько времени занимает авторизация endpoint?
              • 0
                28 слайд http://www.cisco.com/assets/global/RU/events/cisco-connect/presentation/kon1/18/18_00_19_00.pdf
                Авторизация endpoint укладывается в разумные рамки даже для самых дальних офисов. Равно как и аутентификация (как показывает опыт, беспроводные клиенты более толерантны к задержкам, чем проводные).
            • 0
              Матрица безопасности относительно небольшая — несколько десятков групп пользователей и около двух десятков ресурсов. Уж чего чего, а меток — более чем достаточно ;)
          • 0
            Проще всего посмотреть мою презентацию с прошлогоднего Cisco Connect — ответы на большинство вопросов там даны.
            Если коротко — есть две независимые сети, гостевая (Cisco ION — Internet Only Network) и сеть для сотрудников. Это два независимых кластера ISE. Оба развёрнуты глобально. Политики отличаются.
            • 0
              Это на которые ссылки ниже? Спасибо, посмотрю.
              • 0
                http://www.cisco.com/assets/global/RU/events/cisco-connect/presentation/kon1/18/18_00_19_00.pdf
        • 0
          А как контора относится к публикации таких обзоров?
          • 0
            А мы всегда делимся собственным опытом использования собственных продуктов в своей сети. На Cisco Live даже более детальная информация дана по внедрению Cisco ISE у нас внутри — https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=89384&tclass=popup
            • 0
              Есть целый поток на глобальных Cisco конференциях — Cisco Live, он так и называется, Cisco on Cisco. Наши коллеги из IT на нём и делятся опытом эксплуатации.
              • 0
                http://www.ciscolive.com/us/learn/sessions/session-catalog/?search=BRKCOC&search.sessiontype=breakoutsession
            • +1
              >>Поэтому помимо аутентификации надо было проверять еще и состояние устройства — наличие необходимых средств защиты, антивируса, актуальных антивирусных баз, патчей
              Возникают ли при этом проблемы у сотрудников, работающих с не-Windows десктопов?
              • 0
                Ага, интересно про Linux в частности, с OS X проблем, по идее, быть не должно.
                • 0
                  На Linux работает не весь функционал проверки состояния устройства, но у нас таких машин мало — их загоняют в отдельную группу с дополнительной политикой.
                  • 0
                    Мало, это сколько в процентном соотношении? Что за дополнительная политика?
                    • +1
                      По состоянию на январь Linux у нас 10107 машин (Винда — 87864, Мак — 37103) с незначительной тенденцией к сокращению. Все зависит от того, что делает машина с Linux. Им может быть прописана жесткая политика доступа после аутентификации и автоматического профилирования. Либо ISE работает с установленным на Linux агентом MDM, который и отдает нам информацию о статусе
                • 0
                  Нет, не возникает. Но все зависит от платформы. На MacOS проблем никаких.
                • 0
                  А как реализован доступ в сеть с рабочих мест девелоперов/тестировщиков. Не знаю как у вас в Cisco, но у нас типичное рабочее место выглядит следующим образом:
                  На рабочее место выведена розетка с коммутатора уровня доступа. В эту розетку включен SOHO-роутер в который уже включен свич, уже за которым сотрудник разворачивает свое окружение для разработки (специфика такова, что у девелопера на рабочем месту куча устройств требующих сетевое подключение с доступом в интернет + нужна изоляция от соседних рабочих мест). У тестировщиков — еще сложнее, т.к. количество устройств намного больше чем у девелоперов.
                  802.1x использовать не удасться, других вариантов придумать не можем. Может поделитесь своими наработками в этом направлении?
                  • 0
                    А что не так с 802.1x?
                    • 0
                      На роутер ведь не поставить суппликант…
                      • 0
                        У нас внутри вся инфраструктура на Cisco, так что проблем с поддержкой 802.1x и TrustSec на сетевых устройствах нет
                        • 0
                          Вот по этому я и спрашивал как организованы рабочие места девелоперов/тестировщиков… Ведь не поставишь на 300+ рабочих мест на каждое рабочее место по роутеру cisco пусть даже младшей модели. Роутер используется для изоляции рабочего места от внешней сети а так-же для эмуляции окружения работы оборудования а не для расширения сети самой компании. Самими роутерами рулят девелоперы/тестировщики, конфигуря его каждый раз под текущие задачи. Опорная сеть компании построена исключительно на оборудовании Cisco.
                          Как реализовать разграничение доступа в таком случае — ума приложить не можем.
                          • +2
                            У нас это зависит от того, что разрабатывается/тестируется. У нас активно используется виртуализация и поэтому в тестовом окружении мы на базе Cisco UCS можем оперативно нарезать нужные нам сервера и строить на базе виртуальных свитчей (Nexus 1000v) и рутеров (CSR) нужную нам инфраструктуру для тестирования. А Nexus и CSR поддерживают SGT.

                            Если речь идет о тестировании железа, то вот тут — http://www.cisco.com/c/en/us/about/cisco-on-cisco/enterprise-networks/separate-network-alpha-testing-web.html — чуть больше деталей о том, как у нас реализована схема с тестовым окружением.
                  • 0
                    Кстати еще вопрос о лицензировании — в лицензии учитываются все endpoints, или конкурентные?
                    • 0
                      Конкурентные — https://supportforums.cisco.com/sites/default/files/legacy/8/9/0/15367098-ISE%20Ordering%20Guide.pdf

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое