Главный вызов удалённой работы — выход сотрудников за пределы контролируемого ИТ-периметра. Как в этих условиях защитить корпоративные приложения? Консервативное решение «запрещать всё, кроме VPN» — это не выход. Лучший вариант — многофакторная аутентификация (Multi-factor Authentication, MFA), считает Дмитрий Грудинин, системный архитектор компании «Аванпост». Однако не все решения класса Identity and Access Manager (IAM) одинаково полезны. Разбираемся, как выбрать самое подходящее.

Почему именно сейчас это важно?

В классических 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-системы в новых условиях работы компаний, связанных с удалённой работой, покажут себя с лучшей стороны и смогут помочь решить поставленные задачи в случае адекватного соотнесения функциональности конкретного продукта и задач бизнеса.

Многообразие приложений, свойственное практике современных компаний, новые локации подключения пользователей, включение в корпоративный ИТ-периметр новых устройств — всё это требует перехода к стратегии адаптивной многофакторной аутентификации. И корпоративный ИТ-администратор должен иметь возможность опереться в работе по её реализации на правильный инструмент.