Знаете ли вы что из себя представляет сеть компании 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).