Закрываем дыры в безопасности: тотальное управление IAM
Все дело в Identity...
Если вы читаете СМИ или каналы, посвященные вопросам безопасности, то сами можете рассказать, что нас постоянно атакуют, а кража корпоративных данных давно является приоритетом для злоумышленников. При этом далеко не всегда люди знают о том, что усредненный вектор атаки, так или иначе, направлен на учетные записи. По данным Verizon Data Breach Investigations Report, за 2022 год 67% атак в мире начиналось с компрометации учетных данных. Исследователи из Identity Defined Security Alliance отмечают, что 84% компаний фиксировали проблемы уязвимостей ИБ, связанные с учётными данными (identity-related security breaches). И, к сожалению, как бы мы ни говорили пользователям о необходимости следить за паролями, по данным DigiCert, 73% пользователей по-прежнему используют везде один и тот же пароль.
Когда кто-то, кто не должен этого делать, попадает в вашу сеть, все начинается с скомпрометированных УД, а уже дальше идет использование кэшей, выявление ценных данных, запросы к СУБД и прочие действия.
Если постараться в целом описать такую сущность как Identity, то можно определить их как цифровые учётные данные («цифровые субъекты»), которые используются для доступа к данным в процессах идентификации аутентификации, авторизации и контроля. Они включают в себя как минимум:
Персональные (для человека) и машинные идентификаторы и атрибуты;
Средства верификации, используемые для подтверждения «личности» субъекта;
Сведения о геолокации и сетевых признаках;
Полномочия и разрешения на доступ;
Устройства, сервера и т.д., с которых разрешено выполнение операций;
Исторические сведения о ранее выполненных операциях.
Цифровым Identity нужен тщательный присмотр
Поскольку данные являются самым ценным ресурсом любой информационной системы, поэтому цель информационной безопасности — защитить данные и доступ к данным.
Дело в том, что любой запрос к данным происходит через много слоев инфраструктуры. И это справедливо как для внутреннего, так и для внешнего субъекта, запрашивающего этот доступ. В любом случае цепочка взаимодействий включает в себя как пользовательские устройства, так и сетевой уровень, серверы и серверные приложения, а также сами хранилища данных. И на каждом из этих уровней идут какие-то процессы, которые для полного понимания картины необходимо как минимум сопоставлять с идентифицированными субъектами.
Ситуация осложняется тем, что сегодня практически в любой организации наблюдается сложно контролируемый рост числа устройств, учётных данных и элементов инфраструктур за счёт дальнейшего распространения облачных сервисов. Число взаимодействий с данными за пределами классического on-premise-контура контроля со стороны ИТ и ИБ постоянно растет, а работа в гибридном и удаленном режиме за пределами корпоративного периметра только «подливает масла в огонь». Я уже не говорю о сложностях контроля взаимодействий с контрагентами, партнерами и так далее.
Взять, например, пользовательское устройство — оно само по себе является кладезью полезной информации. Как минимум оно работает в фоновом режиме с корпоративной почтой, может синхронизировать какие-то файлы или загружать обновленные данные в хранилище. Именно поэтому устройство тоже нужно идентифицировать — как и самого пользователя. То же самое касается уровней сети, сервера и серверного приложения. Проблема заключается в том, что чаще всего сотрудники работают с личных устройств, и любые попытки взять их под минимальный контроль встречают сопротивление со стороны сотрудников. Попробуйте, к примеру, установить на ноутбуки пользователей антивирус с централизованно закупленной лицензией — практически 50-60% сотрудников будут саботировать эту инициативу, что потребует принятия дополнительных организационных мер.
В реальности в компаниях обычно ограничиваются тем, что следят основном за внешним периметром. Чаще всего для этого используют VPN и/или VDI, а также прикручивают двухфакторную аутентификацию. Но если злоумышленник каким-то образом проникает через него (а злоумышленником может оказаться не только человек, но и устройство или даже процесс, управляемый ИИ), дальше он может беспрепятственно обращаться к любым данным. И если в сети появилось какое-то устройство, по факту мы уже не знаем, что это за устройство, кто им владеет, и зачем он здесь. То есть преодоление одного барьера может стать причиной получения доступа к критически важной информации. А преодолеть его проще всего, взломав Identity на том или ином уровне.
Почему так сложно сделать все правильно?
Причина сложившейся ситуации в том, что приложения корпоративной инфраструктуры используют очень разные схемы работы с Identity. Они имеют различные возможности интеграции. Поэтому поддержка современных технологий аутентификации и авторизации, которые позволяют централизовать контроль учетных данных, оказывается ограничена.
Мы в Avanpost провели собственное исследование, в котором оценили, насколько распространены на различных уровнях разные технологии аутентификации, включая подключение к сети (VPN, VDI, Wi-Fi или просто вход в сеть), системы корпоративных коммуникаций, включая почту и ВКС, системы класса ERP или электронного документооборота, средства разработки, АРМ и серверы, служба поддержки Service Desk.
Результаты оказались интересными. Да, простой пароль работает везде. Но даже для доменной аутентификации через каталог поддержка оказывается ниже: например, они используются далеко не во всех средствах разработки (70%). Более того, стандартные протоколы аутентификации почти не используются в ERP-системах и средствах коммуникации, а RADIUS не очень распространен среди большинства отечественных сетевых решений (20%). Если же мы решим воспользоваться OpenID Connect, то он не доступен штатно для большинства коробочных продуктов как отечественного производства, так и зарубежного. Несколько устаревший SAML же по факту вытеснил OIDC в качестве протокола аутентификации для SaaS/PaaS-решений, интегрируемых с корпоративной инфраструктурой. То есть мы имеем классные протоколы, но на текущий момент мы не имеем достаточной их поддержки в большинстве прикладных решений. В связи с этим возникает необходимость комбинировать различные протоколы, технологии и методы интеграции, что позволяет хотя бы частично реализовать принципы Zero Trust.
Таким образом, чтобы добиться сквозной и повсеместной аутентификации, необходимо провести немалую дополнительную работу. Взять и все подключить сразу просто не получится. Для каждого устройства характерны свои приложения, для каждого типа пользователя — свои сценарии работы. И все это нужно учитывать, чтобы не допустить доступа к данным, даже если кто-то взял и украл Identity одного из сотрудников.
Когда мы только начинали разрабатывать наши решения класса IAM в Avanpost, нам сразу было понятно, что такой «зоопарк» — это реальность, в которой мы живем. Чтобы обеспечить безопасность приходится использовать все имеющиеся и поддерживаемые технологии аутентификации. Нужно постоянно аутентифицировать, какое приложение, человек или устройство делает запрос и реализовывать концепцию Zero Trust на базе тех протоколов, которые поддерживаются.
Что делать?
Чтобы навести порядок в сфере Identity и все-таки не допустить доступа злоумышленников к ценным данным, необходимо централизовать работу с учетными данными и подчинить главному хранилищу все средства аутентификации и идентификации на каждом из уровней доступа.
Что даёт централизация работы с учётными данными?
Во-первых, у каждой операции в инфраструктуре от устройства пользователя и вплоть до хранилища данных с данной операцией сопоставляется идентификатор пользователя, а также могут быть переданы и зафиксированы дополнительно признаки доверия. Используя эти сведения каждый из элементов инфраструктурной цепочки доступа к данным может выполнить дополнительный контроль и отклонить не верифицированный или неавторизованный запрос до того, как он доберётся до данных.
Во-вторых, появляется возможность вести не только учётные записи пользователей, но и внести в централизованное хранилище также и машинные учётные записи — УЗ серверов, приложений, пользователей БД, микросервисов и так далее. Это позволит управлять доступом в том числе и на уровне внутренних процессов, которые не видны «снаружи».
В-третьих, ощутимо повышается качество журналирования всех действий в инфраструктуре за счёт дополнительных сведений для корреляции SIEM-системами, системами класса Incident Response и многого другого.
Для построения централизованного хранилища учётных данных я рекомендую начать с обследования и определить:
Перечень различных цифровых субъектов, взаимодействующих с данными;
Границы прав доступа к данным у каждой категории субъектов;
Все источники и хранилища цифровых субъектов (их будет много).
После выяснения ситуации первый нужно организационными и техническими мерами добиваться подчинения всех хранилищ учетных записей главному хранилищу, а также стремиться к сквозной идентифицируемости всех Identity на всех уровнях вплоть до доступа к данным.
Понятно, что на каждом из уровней доступа к данным могут быть свои специфические подходы к хранению цифровых удостоверений, порой напрямую не совместимые друг с другом. Но если учётные данные во всех этих хранилищах синхронизируются и актуализируются из единого главного источника — это существенно упрощает задачу по контролю.
Помимо этого, на каждом из уровней приняты свои технологические и технические подходы. К примеру, для контроля за работой серверов и рабочих станций принято использовать решения класса Directory Services. Для строгой верификации запросов на уровне инфраструктуры — решения класса Certificate Authority. При этом нельзя сказать, что какой-то из классов решений позволяет полностью закрыть все уровни — скорее на каждом уровне следует применять те решения, которые наиболее полно способны интегрироваться с имеющимися приложениями, системами и серверами.
В качестве основы для построения защиты цифровых удостоверений, той самой концепции Identity Security, следует, в первую очередь, рассмотреть решения класса Identity & Access Management. Это связано с несколькими аспектами:
- IAM-решение наиболее тесно и плотно взаимодействует с пользователями и системами, поскольку является входной точкой для большинства систем и сервисов; это позволяет именно IAM-системе получать максимально возможный набор сведений для принятия решения о доверии тому или иному субъекту;
- IAM может позволить объединить как решения класса DS, так и CA, сглаживая все особенности интеграции различных элементов инфраструктуры;
- IAM позволяет централизованно предотвратить все взаимодействия из «единого окна» в случае компрометации учётной записи пользователя;
- IAM позволяет совместить несовместимые приложения и встроить их в тот самый Zero Trust-ландшафт компании.
При таком подходе у вас появляется возможность контролировать полномочия даже после аутентификации. Если мы знаем, кто и на каком уровне запрашивает доступ, то имеем возможность запретить его на любом из этапов.
Отклонить авторизацию можно, например, на уровне сервера, если субъект использует странный VPN или нетипичные сертификаты. Можно сделать это на уровне сети, на уровне хранилища и так далее. Получается эшелонированная защита, пройти которую на практике во много раз сложнее.