Блог компании Cisco
Cisco
Сетевые технологии
29 августа 2016

Как реализуется контроль сетевого доступа внутри компании 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).
+20
17,4k 87
Комментарии 32
Похожие публикации
Популярное за сутки