Почему именно сейчас это важно?
В классических on-premise инфраструктурах безопасность строится на основе защищённого периметра безопасности. Удалённая работа предполагает, что внутренние корпоративные ресурсы становятся доступны сотрудникам из любого места через интернет. Поэтому цель, к которой стремятся руководители и специалисты по ИТ и ИБ – обеспечение прежнего уровня защиты корпоративных систем и данных в условиях появления массового доступа для сотрудников «снаружи».
«Первый удар» в результате перехода на удалёнку принимает на себя ИТ-департамент. Его специалисты создают учётные записи для VPN и VDI, выдают соответствующие права и раздают сотрудникам пароли. Последние, надёжно сохранённые на стикерах под офисными клавиатурами, чаще вызывают улыбку, чем беспокойство. В ситуации с удалённым доступом, когда любой желающий, обнаруживший интересный сетевой порт на именитом домене, может провести собственный удалённый анализ уязвимостей, уже не до шуток.
Вторая проблема связана со спецификой инфраструктуры и задач, выполняемых сотрудниками. VPN и VDI сегодня применимы не для всех ситуаций и приложений. Для некоторых сотрудников – взять тех же разработчиков – зачастую приходится открывать «наружу» дополнительные интерфейсы приложений для отладки, публиковать репозитории и т.д. По мере работы в удалённом режиме число таких открытых сетевых интерфейсов неизменно растёт, а ИТ и ИБ-специалисты постепенно теряют контроль над обслуживаемой инфраструктурой.
Консервативное решение «запрещать всё, кроме VPN» конфликтует с окружающей действительностью, в которой гибридные ИТ-инфраструктуры (где есть SaaS/PaaS/IaaS) – уже не завтрашний, а сегодняшний день. Доказать это легко: к примеру, если вы и ваши коллеги используете в работе любые решения видеоконференцсвязи – Zoom, Microsoft Teams, Google Meet – значит, в вашей организации уже есть гибридная инфраструктура.
LDAP и все-все-все
В корпоративной среде для хранения информации о пользователях и их учётных данных преимущественно используют LDAP-каталоги (например, Active Directory). LDAP позволяют использовать одни учётные данные сотрудника в большинстве систем, что очень удобно.
Сотрудник преимущественно пользуется одной корпоративной учётной записью в том же Active Directory. Поэтому её компрометации достаточно для получения несанкционированного доступа к обширному перечню приложений организации, в которых есть доступ через учётную запись LDAP.
По своей архитектуре учётные данные LDAP-каталога в случае использования LDAP-аутентификации весьма слабо защищены, так как приложение непосредственно запрашивает у пользователя его доменный логин и пароль в открытом виде. При наличии уязвимостей в приложении, подключенном к LDAP, под угрозой может оказаться вся корпоративная инфраструктура.
Это не повод, конечно же, отказываться от LDAP – он прекрасно справляется с задачами хранения информации о пользователях и инфраструктуре. Но это повод как минимум пересмотреть практику обширного использования классической LDAP-аутентификации.
Шерше ля IAM
На смену LDAP-аутентификации пришли решения, специализированные на выполнении роли провайдера аутентификации (Identity Provider, IdP). Ключевым преимуществом технологии IdP является то, что учётные данные пользователя передаются напрямую от пользователя к сервису, играющему роль провайдера аутентификации. При этом существенно снижается риск компрометации учётных данных из-за уязвимостей приложения, что было характерно для LDAP-аутентификации. Такой подход себя отлично зарекомендовал и стал де-факто отраслевым стандартом. В качестве средства для его реализации были разработаны IdP-протоколы SAML 2.0, OAuth 2.0 и OpenID Connect.
Identity Provider в чистом виде (каковыми являются, к примеру, Open Source-решения KeyCloak, Gluu Server и ряд коммерческих решений) прекрасно подходят для инфраструктур, в которых есть возможность реализации полномасштабной поддержки IdP-протоколов для всех без исключения систем. В реальной же корпоративной среде встречается огромное разнообразие корпоративных информационных систем и интерфейсов. Поэтому «чистый IdP» как единое средство входа во все системы зачастую так и остаётся на уровне благого намерения. К сожалению, реальные потребности корпоративных инфраструктур не могут быть в полной мере удовлетворены классическими Identity Provider.
Намного ближе к задачам корпоративной аутентификации являются решения класса Identity and Access Manager (IAM). В их число попадает обширный ряд систем с различным предназначением, и не всегда то, что выглядит как IAM, действительно является подходящим IAM с точки зрения корпоративных потребностей. Поэтому давайте определим характеристики «правильного» корпоративного IAM.
Вернёмся к нашим VPN
Если ещё раз взглянуть на VPN и VDI, которые являются первым рубежом защиты для удалёнщиков, то окажется, что процесс аутентификации в нем достаточно уязвим. Связано это опять-таки с повсеместным применением пароля, в роли которого выступает тот самый доменный пароль. Да, в некоторых VPN и VDI можно сделать аутентификацию по сертификатам штатными средствами, но такое решение вызывает вопросы с точки зрения удобства для пользователей, а особенно с точки зрения удобства сопровождения. На практике второй фактор для VPN является единственным разумным компромиссом между удобством и защищённостью УЗ для VPN: в роли второго фактора наиболее удобны пользовательские аутентификаторы, например, TOTP, мобильное приложение или мессенджер.
Правильный корпоративный IAM, помимо наличия функций Identity Provider, должен поддерживать аутентификацию в VPN и VDI с предоставлением для них дополнительных факторов. Поэтому требование к IAM для VPN/VDI – наличие встроенной поддержки протокола RADIUS, так как чаще всего аутентификация в VPN реализуется посредством RADIUS.
Infrastructure as a Problem
В любой зрелой корпоративной инфраструктуре присутствуют приложения, в которых нет поддержки протоколов IdP и RADIUS, а применяется аутентификация по логину-паролю, в том числе по доменному. При этом таковыми могут быть как веб-приложения, так и десктопные.
Если в каждое такое приложение сотрудник должен входить с использованием отдельной учётной записи, то при переходе пользователей между рабочими местами обостряется проблема забытых паролей, что существенно нагружает заявками ИТ-департамент. Если используется общая УЗ в LDAP – возникает риск компрометации единой УЗ.
При работе в режиме удалёнки, когда сотрудник может подключиться к приложению из любого места, возникает потребность в дополнительных мерах контроля доступа к таким приложениям, чтобы можно было отследить, под какой учётной записью выполнялся вход, из какого сетевого расположения, с какого устройства и т.д. Некоторые приложения собирают такую информацию самостоятельно, но наиболее правильный способ сбора информации о фактах доступа – подключение приложения к централизованному средству аутентификации. При этом модификация таких приложений для поддержки технологии IdP зачастую невозможна по ряду причин, в числе которых технические ограничения, нехватка или отсутствие ресурсов.
Для унаследованных десктопных приложений в таком случае подходит классическая технология Enterprise SSO (ESSO), а для унаследованных веб-приложений – Web Access Manager (который также называется Reverse Proxy). При таком подходе учётные данные пользователя в приложениях хранятся централизованно на стороне IAM-решения и подставляются им самостоятельно. Пользователь при этом не знает фактические пароли в приложениях, а выполняет аутентификацию только на стороне IAM.
Для использования Enterprise SSO в режиме удалённой работы настройка компонента, обеспечивающего ESSO, должна быть максимально простой и масштабируемой. А аутентификация в унаследованные веб-приложения посредством Web Access Manager должна осуществляться с использованием любого стандартного браузера без необходимости установки каких-либо плагинов. В идеале – Web Access Manager должен функционировать режиме Reverse Proxy на стороне сервера.
Рабочие станции пользователей
Правильные корпоративные IAM-решения должны обеспечивать вход пользователя на рабочие станции и терминалы под управлением Windows и Linux-платформ. Для удалённых рабочих мест это требование может казаться избыточным. Но риск компрометации устройства пользователя, содержащего корпоративные сведения, сохраняется вне зависимости от того, используется ли устройство в офисе или дома.
Для того, чтобы сохранить управляемость аутентификацией в ОС, она должна осуществляться стандартными механизмами операционных систем. Поэтому наиболее современными и простыми средствами для обеспечения этого являются штатные API и механизмы ОС. В Microsoft Windows это механизм Windows Credential Provider (ранее был механизм GINA, но он устарел и уже не применяется), в системах семейства Linux/UNIX – PAM Linux или OpenPAM (например, для MacOS X). Для Windows-систем, функционирующих в режиме удалёнки, а также для отдельных Windows-серверов Credential Provider должен поддерживать не только аутентификацию в доменные УЗ, но и в УЗ, локально настроенные администратором.
Облака
Сегодня к списку требований к IAM добавляется также требование к наличию поддержки интеграции с облачными средами, поскольку всё чаще компании выбирают вариант размещения ощутимой части своей инфраструктуры (от 10% и более) в облаке, по модели IaaS или PaaS. Поэтому обеспечение бесшовной кросс-аутентификации сотрудников в гибридных ИТ – важнейшее требование. То есть сотрудники должны иметь возможность пройти аутентификацию не в инфраструктуру, а в приложение вне зависимости от расположения приложения в гибридной инфраструктуре. Для пользователя этот процесс должен быть бесшовным, что максимально важно в режиме удалённого доступа.
IAM в случае гибридных ИТ разделяется на несколько экземпляров с синхронизацией или репликацией данных. Классический подход для обмена между экземплярами – Identity Brokering, при котором экземпляры IAM устанавливают доверие в рамках IdP-протоколов OAuth/OpenID Connect и SAML. Данный подход имеет свои плюсы, но в случае работы в доверенной среде может быть затратным с точки зрения ресурсов и времени для выполнения полной репликации узлов системы. Намного более простым с точки зрения администрирования распределённой системы является реализация синхронизации сведений о сеансах пользователей между узлами системы штатными средствами самой IAM-системы. Поэтому наличие такой возможности в корпоративном IAM будет существенным плюсом при построении гибридного кластера корпоративной системы аутентификации.
С точки зрения факторов
Конечно же, подключение приложений к корпоративной IAM-системе выполняется с целью обеспечения надёжной, удобной и безопасной аутентификации. А это невозможно без развитых средств многофакторной аутентификации на стороне IAM.
При этом нужно помнить, что сами по себе факторы не бывают чрезмерно «сильными» или «слабыми», а само по себе наличие второго фактора аутентификации не является панацеей. Ключевая задача MFA заключается в построении из одного или нескольких дополнительных факторов гибкой схемы аутентификации, учитывающей специфику приложения, особенности работы пользователей этого приложения, бизнес-процессов организации и т.д.
В этом смысле корпоративное IAM-решение должно не просто позволять добавить дополнительный фактор к аутентификации в приложение, но и построить правильную схему, которая согласуется с видением ИТ и ИБ. Для удалённой работы первым требованием является возможность разделения сценариев аутентификации в приложения в зависимости от сети, из которой выполняет аутентификацию пользователь. Очевидно, что офисная сеть является более защищённой и управляемой, поэтому в ней некоторые проверки могут быть опущены с целью повышения удобства аутентификации.
Второй вызов – это разделение правил аутентификации для простых и привилегированных пользователей. IAM должен обеспечивать возможность настройки сценариев аутентификации для различных групп. При выдаче сотруднику административных полномочий посредством включения его УЗ в группу IAM-решение автоматически «усилит» его аутентификацию по предварительно настроенному сценарию без лишних действий со стороны администратора.
Конечно же, IAM-решение должно учитывать специфику приложений. Многие из них поддерживают взаимодействие с пользователем в режиме диалога. Но некоторые, например, Microsoft RDP/RDGW, технически не позволяют обмениваться дополнительными аутентификационными сведениями. Поэтому для таких решений корпоративный IAM должен доставлять дополнительный фактор по альтернативному каналу связи – например, через мобильное приложение или мессенджер.
Для внедрения корпоративной аутентификации в условиях удалённой работы IAM должен максимально автоматизировать задачи настройки УЗ сотрудников, привязки аутентификаторов и т.д. Так как лучше сотрудника с этой задачей никто не справится, средство должно обладать развитыми средствами самообслуживания в части инициализации УЗ в IAM. Поэтому такие задачи, как получение доступа к УЗ в IAM, её настройка, привязка мобильного приложения, подтверждение E-mail и номера телефона – должны происходить без участия администратора.
Выводы
При удалённой работе некоторые, казалось бы, не критичные в on-premise окружении нюансы начинают играть ведущую роль. И если IAM-решение, которому доверили обеспечение корпоративной аутентификации, не обладает этими функциями, то уже в процессе внедрения и эксплуатации возникнет ряд проблем, которые придётся решать альтернативными средствами. Корпоративные IAM-системы в новых условиях работы компаний, связанных с удалённой работой, покажут себя с лучшей стороны и смогут помочь решить поставленные задачи в случае адекватного соотнесения функциональности конкретного продукта и задач бизнеса.
Многообразие приложений, свойственное практике современных компаний, новые локации подключения пользователей, включение в корпоративный ИТ-периметр новых устройств – всё это требует перехода к стратегии адаптивной многофакторной аутентификации. И корпоративный ИТ-администратор должен иметь возможность опереться в работе по её реализации на правильный инструмент.
Каждый шестой (15%) работник сталкивался с попыткой взлома рабочего пароля, у 3% попытка взлома увенчалась успехом хакеров. 67% респондентов не взламывали и не пытались взломать. Такие данные приводит hh.ru по итогам исследования.
В конце 2019 года в Федеральный закон № 63-ФЗ «Об электронной подписи» были внесены изменения. Многие оценили их неоднозначно, и в первую очередь — игроки рынка удостоверяющих центров.