Как Cisco уже 20 лет работает в режиме удаленного доступа и отсутствующего периметра?
Вот уже около 20 лет Cisco живет без привычного периметра, а ее сотрудники пользуются всеми преимуществами удаленной работы. Помню, когда я пришел в 2004-м году в Cisco, я получил на руки корпоративный ноутбук с установленным Cisco VPN Client и получил право работать из… да откуда угодно. За это время я работал из дома и гостиницы, из электрички и такси, из самолета на высоте 10000 метров и в метро. По сути у нас реализован принцип «работа там, где я», а не «я там, где работа». Как нам удалось это сделать? Как мы реализовали концепцию «доверенного предприятия», которая вот уже много лет помогает нам не замечать неприятных событий, заставляющих многих из нас безвылазно сидеть по домам (разумеется, есть ряд процессов, которые требуют физического присутствия, например, производство оборудования)?
Начну я с того, что большинство сотрудников Cisco живет по принципу «волка ноги кормят», то есть находится постоянно в движении. Кто-то ездит по заказчикам, кто-то по партнерам, кто-то по контрагентам и поставщикам, кто-то выступает на различных конференциях. Разумеется, есть и те, кто работает преимущественно в офисе, но и эти сотрудники имеют возможность работать не из офиса. Такой подход, принятый много лет назад, заставил нас пересмотреть традиционную ИТ-архитектуру, подразумевающую наличие периметра, опоясывающего компанию и ее ценные ИТ-активы, и одну-две контролируемые точки пересечения этой границы. Сегодня в Cisco данным можно перемещаться между любыми пользователями, любыми устройствами, любыми приложениями, расположенных в любых местах. Разумеется, речь идет о контролируемом перемещении. Но в любом случае мы уже не скованы понятием «периметр», отказавшись от него еще тогда, когда термин «депериметризация» (с первого раза и не произнесешь, да?) еще не был в ходу, а концепция Zero Trust даже не появилась на свет.
Тогда наша ИТ-служба вместе со службой кибербезопасности задумались о том, как сделать так, что, с одной стороны, сотрудники компании могли работать, не буду скованными требованием находится большую часть времени внутри корпоративного периметра, а, с другой стороны, данные и приложения компании были надежно защищены от широкого спектра угроз. Мы перепробовали много различных вариантов, но все они имели определенные изъяны, так как самым слабым звеном в них был ноутбук удаленно работающего сотрудника, который не находился под сенью корпоративных средств защиты и мог стать точкой входа в нашу сеть злоумышленникам. А попытки заставить пользователей всегда работать в VPN, чтобы «заворачивать» весь трафик на периметр, где и проверять его, не давали должно эффекта, так как при активном перемещении по миру и переходе в облачную модель работы, «гонять» весь трафик даже через установленные в разных регионах VPN-шлюзы было очень неудобно, так как вносило задержки в работу пользователей и их приложений. В итоге мы пришли к концепции «доверенного устройства», которая позже трансформировалась в то, что мы назвали «доверенным предприятием». Согласно этой концепции мы живем и сейчас.
Идея доверенного предприятия довольно-таки проста и зиждется на 4 столпах:
- Доверенная идентичность (извините, англоязычное Trust Identity достаточно непросто кратко перевести на русский язык), подразумевающая, что перед любой попыткой доступа мы идентифицируем и аутентифицируем любого пользователя и устройство (а позже и приложения), которые хотят получить доступ к корпоративным ресурсам, размещенным внутри компании или во внешних облачных провайдерах.
- Доверенная инфраструктура, включая в себя такие компоненты, как доверенное устройство, доверенный сервер и доверенная сеть. Этот столп позволяет нам быть уверенными, что все, что подключается (включая и Интернет-вещи) и все, к чему подключается, не было скомпрометировано злоумышленниками.
- Доверенный доступ, который позволяет обеспечить нам безопасное подключение независимо от того, как, откуда и куда это подключение организуется. Я могу подключиться из самолета (хотя в условиях сокращения авиаперевозок об этом можно на время забыть) к облачной инфраструктуре Amazon AWS минуя корпоративный периметр и при этом наша служба безопасности все равно будет контролировать такой доступ, отслеживая любые нарушения политик безопасности и аномалии в поведении сотрудника или его устройства.
- Доверенные сервисы и приложения, которые позволяют гарантировать, что не только пользователи и устройства, но и приложения, размещенные в чужих облачных средах, соответствуют нашим требованиям безопасности и не повышают риски несанкционированного доступа к данным компании, ее клиентов и партнеров.
Первый стол, доверенная идентичность, строится нами, опираясь на три ключевые технологии:
- Microsoft Active Directory, корпоративный справочник, являющийся точкой входа для идентификации и аутентификации пользователей, работающих под управлением Windows, macOS, Linux и даже мобильных платформ.
- Протокол 802.1x, позволяющий нам добавить к идентификации и аутентификации пользователей еще и устройства, тем более, чем число последних у нас в несколько раз превышает число сотрудников или работников по контракту. Например, к нашей инфраструктуре подключены все сетевые принтеры и сканеры, системы видеонаблюдения, системы «умного здания» (термостаты, освещение и т.п.), системы контроля доступа и т.п. Решение Cisco ISE, а я уже писал о том, как мы контролируем доступ во внутренней инфраструктуре Cisco, позволяет нам централизованно управлять сотнями тысяч субъектов доступа к нашей сети, даже в том случае, если за тем или иным устройством нет пользователя или если пользователь является не сотрудником Cisco, а гостем.
- Завершает эту тройку многофакторная аутентификация (MFA), которая позволяет снизить риски кражи или подбора пароля пользователя или сервиса, добавляя к классической паре «логин-пароль» дополнительные факторы, позволяющие нам убедиться, что мы общаемся с нужным нам пользователем, приложением или устройством. По статистике в 81% инцидентов используются слабые или украденные пароли. Поэтому внедрение многофакторной аутентификация, а мы используем Cisco Duo, позволило нам сильно уменьшить число возможных инцидентов и облегчить жизнь пользователей, которые вольны выбирать различные типы для второго фактора — аппаратный токен YubiKey, пуш на смарт-часах, биометрию TouchID и т.п. Это же решение, за счет поддержки протокола SAML, мы используем и для аутентификации в облачных сервисах, развернутых Cisco (а я напомню, что мы являемся клиентами более 700 различных облачных провайдеров). От себя отмечу, что Duo позволяет не только проводить идентификацию и аутентификацию пользователя, но и проверяет статус защищенности устройства, а также может быть задействовано как решение MFA для персональных сервисов (я его, например, использую при аутентификации в Facebook, Dropbox, сервисах Google и ряде российских облачных провайдеров).
Доверенная инфраструктура означает, что все ее компоненты, рабочие станции, сервера, мобильные устройства и даже само сетевое оборудование, соответствуют требованиям политик безопасности — на них установлено последняя версия ПО, ПО пропатчено и правильно настроено, включена аутентификация и т.п.
Если не вдаваться по понятным причинам в глубокие детали, то у нас есть так называемый стандарт доверенного пользовательского устройства, который применяется к любому ноутбуку, смартфону или планшету, который подключается к нашей инфраструктуре. Независимо от того, является это устройство корпоративным или выданным. При отказе или невозможности выполнения данного стандарта, устройство просто не подключается к корпоративной сети, независимо от того, подключается пользователь извне или пробует это сделать в офисе, воткнувшись в свободную Ethernet-розетку. За соблюдением требований у нас могут следить Cisco ISE (основной инструмент), Cisco ASA (при удаленном доступе), Cisco Firepower (за счет инвентаризации по сетевому трафику) и Cisco Duo (для мобильных платформ).
Для серверов, физических или виртуальных, контейнеров, в наших ЦОДах или в облаках, применяется свой стандарт. Около 80% требований в нем совпадают с тем, что входит в стандарт для пользовательских устройств, но есть, конечно, и отличия. Например, для серверов, виртуальных машин и контейнеров, выполняющих вполне конкретные задачи, список которых ограничен, мы используем замкнутую программную среду, недопускающую запуска каких-либо посторонних приложений и сервисов. Еще одним обязательным требованием является обязательное управление уязвимостями прикладного и системного ПО, порядок которого отличается от того, что делается на рабочих станциях и мобильных устройствах.
Понятно, что требования для тех же серверов Windows или Linux отличаются друг от друга, как и требования к ИБ виртуальных машин, расположенных в Amazon AWS или Microsoft Azure, но отличия скорее касаются особенностей настройки, чем самих требований. При этом мы брали за основу уже готовые Hardeining Guide от CIS и дополняли их рядом присущих нам нюансов. Поэтому, предвосхищая вопрос «А где взять ваши стандарты доверенных устройств?», могу просто перенаправить вас на сайт CIS, на котором вы найдете соответствующие руководства не только по операционным системам, но и различным приложениям; разве что по отечественному ПО таких стандартов там нет.
Наконец, свой стандарт есть у нас и для сетевого оборудования — коммутаторов, маршрутизаторов (в том числе и виртуальных), точек беспроводного доступа и межсетевых экранов. Очевидно, что абсолютное большинство из этого перечня нашего производства, но в случае с приобретенными нами компаниями бывают и некоторые исключения (как мы контролируем поглощаемые активы можно почитать на Хабре). В основу этого стандарта доверенного сетевого устройства положены наши же собственные рекомендации по защите оборудования на базе операционных систем IOS, NX-OS, IOS XR и т.п. Их можно найти не только на сайте CIS, но и у нас на сайте (ссылки на них вы найдете в конце этого материала).
Третий столп доверенного предприятия — доверенный доступ, реализация которого сильно зависит от того, какой способ доступа и куда у нас обеспечивается. Устройство во внутренней сети может пытаться получить доступ к устройству также во внутренней сети. Пользователь с устройства во внешней сети может пытаться подключиться к облаку без использования VPN. Приложение может пытаться получить доступ к данным, расположенным в определенной географической локации и которые не могут его покидать (например, персональные данные россиян). И таких примеров может быть достаточно много.
Поэтому в основе доверенного доступа лежит сегментация, которая ограничивает любые несанкционированные попытки и, даже если злоумышленник или вредоносный код все-таки скомпрометируют один из сегментов, остальные останутся в безопасности. При этом, говоря о сегментации, я имею ввиду не только и не столько сегментацию сетевую (по IP- или MAC-адресам). Это может быть сегментация приложений или контейнеров, это может быть сегментация данных, это может быть сегментация пользователей.
Все эти варианты реализуются в нашей инфраструктуре с помощью технологии SD-Access, которая унифицирует как проводной, так и беспроводной доступ, в том числе и с точки зрения безопасности. В случае объединения разных офисов мы используем SD-WAN, а в ЦОДах и облаках применяется гибридный вариант, в зависимости от того, доступ чего и к чему мы хотим контролировать.
Важный момент, о котором часто забывают при реализации сегментации и контроле доступа. Мы применяем не статистические, а динамические правила доступа, которые зависят не только от того, кто и куда подключается, но и от контекста этого доступа — как осуществляется подключение, как ведет себя пользователь, узел или приложение, чем они обмениваются в рамках предоставленного доступа, есть ли уязвимости у общающихся субъектов и объектов и т.п. Именно это позволяет нам уйти от дискретных правил политики ИБ, из-за которых часто и происходят многие инциденты. Система защиты просто не умеет контролировать то, что происходит между проверками. У нас же реализуется по сути непрерывная верификация доступа, каждой его попытки, устройства, пользователя или приложения. В качестве основных решений для такой непрерывной верификации применяется уже упомянутый ранее Cisco ISE (для внутренней сети предприятия), Cisco Tetration (для ЦОДов и облаков) и Cisco APIC (для ЦОДов), которые интегрированы между собой и могут обмениваться сквозными политиками безопасности.
Но мало установить правила доступа, необходимо контролировать их соблюдение, для чего мы применяем наши же решения — упомянутый выше Cisco Tetration (для ЦОДов и облаков), а также Cisco Stealthwatchh Enterprise (для внутренней сети) и Cisco Stealthwatch Cloud (для облаков). О том, как мы мониторим нашу инфраструктуру, я уже тоже писал на Хабре.
А что с облаками? Если Cisco пользуется услугами 700 облачных провайдеров, то как в этом случае обеспечить безопасную работу с ними? Особенно в условиях, когда сотрудник может подключиться к облаку, минуя корпоративный периметр, да еще и со своего личного устройства. На самом деле в реализации этой задачи нет ничего сложного, если изначально правильно продумать соответствующую архитектуру и требования к ней. С этой целью достаточно давно мы разработали соответствующий фреймворк, получивший название CASPR (Cloud Assessment and Service Provider Remediation). В нем установлено свыше 100 различных требований безопасности, разбитых на блоки, которые предъявляются любому облачному провайдеру, который хочет с нами работать. Разумеется, требования CASPR не одинаковы для всех облаков, а зависят от того, какую информацию, какого уровня конфиденциальности, мы хотим там обрабатывать. Есть у нас требования как юридического характера, например, в части GDPR или ФЗ-152, так и технического, например, наличие возможности отдавать нам логи событий безопасности в автоматическом режиме (я про это уже писал на Хабре).
В зависимости от типа облачной среды (IaaS, PaaS или SaaS) мы «навешиваем» на предоставляемые провайдером механизмы защиты свой собственный инструментарий (например, Cisco Tetration, Cisco ASAv, Cisco ISE и т.п.) и мониторим его использование с помощью уже упомянутых Cisco Duo, Cisco Tetration. Cisco Stealthwatch Cloud, а также с помощью Cisco CloudLock, решения класса CASB (Cloud Access Security Broker). О ключевых моментах, связанных с мониторингом безопасности облаков, я уже писал (и вторая часть) на Хабре.
Четвертый стол концепции «доверенного предприятия» Cisco, является «доверенное приложения», для которых у нас также разработан свой стандарт, а точнее набор стандартов, сильно отличающихся в зависимости от того, является приложения покупным или разработанным нами, размещается оно в облаке или в нашей инфраструктуре, обрабатывает оно персональные данные или нет и т.п. Подробно расписывать этот столп я не планировал в данной заметке, но ключевые блоки требований отображены на иллюстрации ниже.
Понятно, что пришли мы к этой концепции не сразу и не одномоментно. Это был итерационный процесс, который отражал те задачи, которые ставил перед службами ИТ и ИБ бизнес, теми инцидентами, с которыми мы сталкивались, с той обратной связью, которую мы получали от сотрудников. Думаю, что не ошибусь, если скажу, что как и все мы начинали с политик безопасности на базе IP/MAC-адресов и местоположения пользователя (удаленный доступ был реализован еще на этом этапе). Затем мы расширили их за счет добавления контекстной информации от Cisco ISE, а также привязав к бизнес-целям отдельных подразделений и проектов компании. По мере открытия границ нашей инфраструктуры гостям, контрагентам, контракторам, партнерам, возникли новые задачи и их решения с точки зрения контроля доступа. Активный уход в облака привел к тому, что нам понадобилось разработать и реализовать единую концепцию обнаружения угроз во внутренней сети, в облаках и на пользовательских устройствах. Тут, как нельзя кстати, оказалась покупка нами компаний Lancope и Umbrella, которые позволили нам начать более эффективно мониторить внутреннюю инфраструктуру и внешних пользователей. Наконец, покупка компании Duo позволила нам плавно начать переход к последнему уровню условной модели зрелости, обеспечивающей нам непрерывную верификацию на разных уровнях.
Понятно, что если вы хотите повторить наш путь, то слона надо есть по частям. Далеко не все наши заказчики схожи с нами по масштабу и решаемым задачами. Но многие из наших шагов и идей будут применимы любой компанией. Поэтому можно постепенно начать реализовывать описанную выше идею «доверенного предприятия». Концепция малых шагов как нельзя лучше поможет это сделать. Начните с идентификации пользователей и устройств, которые подключаются к вам как изнутри, так и снаружи. Затем добавьте контроль доступа на основе состояния устройств и его контекста. Я не зря вначале упомянул, что в Cisco нет как такого периметра и защита строится вокруг каждого устройства, делая его, по сути, независимым от нашей инфраструктуры. Обеспечив контроль подключаемых устройств, в том числе и в рамках удаленного доступа, можно плавно переходить к сегментации внутренней сети и ЦОДа. Это непростая задача, но вполне подъемная. Ключом к ее реализации является автоматизация управления политиками доступа. Карантин стал, а для кого-то станет, толчком для возврата к теме BYOD, возможности применения сотрудниками личных устройств для доступа к корпоративным или ведомственным ресурсам. Но решив первые две задачи, вы легко транслируете их и на персональные ноутбуки, смартфоны и планшеты ваших сотрудников. Решив задачи с сетевым доступом, вам надо будет начать подниматься выше — на уровень приложений, реализуя для них сегментацию, разграничение и контроль доступа, интегрировав их с политиками сетевого доступа. Финальным аккордом может стать политика контроля доступа к данным. На этом этапе вы уже будете знать, кто и откуда вас подключается, каким приложениям и к каким данным нужен доступ. Вам останется только применить это знание к вашей инфраструктуре и автоматизировать работу с данными. Тут, кстати, уже можно подумать и о DLP. Тогда вы сможете попасть в те 20% проектов внедрения DLP, которые Gartner считает удачными. Все остальное провально, так как компании зачастую даже не знают границ своей инфраструктуры и точек входа в нее, чтобы можно было говорить об их контроле, не говоря уже о контроле данных.
А реализовав все это, вы поймете, что красивая концепция Zero Trust (нулевое доверие), о которой сегодня говорят многие производители и аналитики, в вашем случае превратилась в реально работающую систему. По крайней мере у нас это было именно так. Как я уже писал в самом начале, концепцию доверенного предприятия мы стали реализовывать в Cisco в начале 2000-х годов, когда такого термина как «Zero Trust» еще никто не слышал (его предложила компания Forrester только в 2010-м году). Зато сейчас, опираясь на наш собственный опыт, мы смогли внедрить эту идею и в наше портфолио (мы его применяем и для собственной безопасности), назвав это все красивым маркетинговым словосочетанием «Cisco Trusted Access».
В завершении я бы хотел отметить, что реализация удаленного доступа заставляет нас совершенно по иному смотреть на то, как должна строиться система защиты. Кто-то говорит, что удаленный доступ приводит к потере периметра. Нет, это не так. Просто периметр у вас размывается и его границы проходит по каждому устройству, с которого осуществляется доступ к вашим данным и приложениям, расположенным внутри инфраструктуры и снаружи ее. А это в свою очередь позволяет вам реализовать архитектуру, которая очень гибко и оперативно реагирует на все те изменения, которые от ИТ и ИБ требует бизнес. Cisco столкнулась с этим давно, когда еще не было проблемы с коронавирусом и у нас была возможность постепенно, без спешки реализовывать концепцию доверенного предприятия. Но это не значит, что наш опыт неприменим в нынешних реалиях. Наоборот. Можно опираясь на него, набивать меньше шишек и делать меньше ошибок.
Перефразируя известный советский фильм »17 мгновений весны»: «Верить в наше время нельзя никому, порой даже самому себе. Cisco — можно!» Наш подход, и отсутствие крупных и серьезных инцидентов в нашей инфраструктуре (а у нас несколько десятков тысяч сотрудников и еще столько же внешних пользователей партнеров и контрагентов имеют удаленный доступ внутрь), доказал, что он не только имеет право на жизнь, но и позволяет решать бизнесу его задачи наиболее удобным ему, бизнесу, а также надежным для ИТ и безопасным для ИБ, способом.
Дополнительная информация:
PS. Если вам интересно, как технически устроен удаленный доступ в самой Cisco, то 23-го апреля мы проводим вебинар на эту тему. Точнее уже завершаем серию вебинаров про удаленный доступ, которые проходят каждый четверг. 2-го числа вебинар был посвящен модели угроз удаленного доступа (видеозапись и презентация). 9-го мы будем рассказывать про то, как защитить рабочее место удаленного работника, а 16-го — как выстроить периметр при удаленном доступе.
