Почему защита айдентити стала точкой напряжения между бизнесом, ИТ и ИБ
Учетные данные становятся ключевой точкой риска. В статье для РБК Игорь Тюкачев рассказывает, почему это происходит и как выстроить защиту без лишнего напряжения
В современном мире учетная запись сотрудника — это не просто логин и пароль, а цифровой профиль, через который человек получает доступ к системам, данным и бизнес-процессам. Такой профиль может влиять на финансовые операции, клиентский сервис, репутацию и устойчивость компании. Поэтому защита учетных данных и управление доступом постепенно становятся одной из центральных тем кибербезопасности.
При этом главные сложности лежат не только в технологической плоскости. Защита айдентити находится на пересечении интересов сразу нескольких функций. Бизнесу нужны быстрые изменения и минимальные барьеры для пользователей. ИТ отвечает за стабильность систем и непрерывность сервисов. Информационная безопасность настаивает на контроле и повышении уровня защиты доступа. Именно на этом стыке часто возникает напряжение.
По мере размывания классического периметра безопасности логины и пароли от внутренних сервисов, рабочих станций, облачных приложений и информационных систем становятся ключевой областью контроля. Получить или подобрать учетные данные для злоумышленника часто проще, чем искать сложные уязвимости. Завладев айдентити пользователя, атака может развиваться уже изнутри, от имени легитимного сотрудника.
Когда компания начинает выстраивать систему защиты учетных данных, она неизбежно сталкивается с «треугольником сил»: бизнесом, которому важны скорость и эффективность процессов, ИТ-функцией, отвечающей за стабильность и бесперебойную работу инфраструктуры, и ИБ, которая стремится усилить контроль над доступом. Понимание мотивации каждой стороны становится необходимым условием для построения действительно рабочей стратегии в области Identity Security (безопасности личных данных).
От инцидента до требований регуляторов: как запускаются проекты по защите учетных данных
Распространенное представление о том, что зрелая система защиты учетных данных появляется по инициативе службы ИБ в спокойный период, редко совпадает с практикой. Чаще импульсом становится конкретное событие: инцидент безопасности, утечка данных, новые требования регулятора, аудит или рост стоимости потенциального ущерба для бизнеса.
В разных отраслях и юрисдикциях набор таких стимулов может отличаться. Где-то на решение сильнее влияют требования к обработке персональных данных, киберстрахование и риск судебных разбирательств. В других случаях основным фактором становятся регуляторные требования, внутренний аудит, необходимость подтвердить зрелость процессов или последствия уже произошедшего инцидента.
Для бизнеса вопрос защиты учетных данных является предметным тогда, когда риски переводятся на язык понятных последствий: простой сервисов, утечка клиентской базы, нарушение договорных обязательств, снижение продаж, репутационный ущерб или дополнительные расходы на восстановление. В такой ситуации инициатором проекта может выступать не только директор по информационной безопасности. Запрос нередко приходит от коммерческого блока, ИТ, операционного руководства или правления.
Отдельно стоит учитывать различия между государственным сектором, критической инфраструктурой и коммерческими компаниями. В одних случаях требования к защите уже формализованы: есть регуляторные документы, методики, процедуры аттестации и понятный контур ответственности. В других компания самостоятельно определяет приемлемый уровень риска и соотносит его с бюджетом, удобством пользователей и потенциальным ущербом от атаки. Именно здесь особенно заметна роль директора по ИБ: ему необходимо не просто предложить набор средств защиты, а убедительно показать, какие бизнес-риски закрывает проект.
Дорожная карта: чей приоритет окажется сильнее
Формирование дорожной карты в области защиты учетных данных почти всегда связано с конкуренцией за ресурсы и приоритеты. Одним подразделениям важно быстрее запускать новые сервисы, другим — обеспечить надежную работу инфраструктуры, третьим — снизить вероятность несанкционированного доступа и усилить контроль над действиями пользователей.
Зрелый подход строится не на противостоянии функций, а на согласовании рисков и ответственности. Дорожная карта должна показывать, какие сценарии доступа защищаются в первую очередь, какие системы относятся к критичным, где необходимо внедрять многофакторную аутентификацию, где требуется управление привилегированным доступом, а где достаточно регламентов и регулярного контроля.
В крупных компаниях такую работу часто помогают выстроить внешний аудит и независимая оценка зрелости процессов. Аудиторы фиксируют текущее состояние, выявляют слабые места и помогают сформировать стратегию на два-три года. После этого дорожная карта утверждается уже на уровне руководства, потому что затрагивает не только ИБ, но и ИТ-архитектуру, операционные процессы и пользовательский опыт.
Главная сложность заключается не в том, чтобы подготовить план, а в том, чтобы сохранить его жизнеспособность при реализации. ИТ ожидает, что внедрение PAM, MFA или других средств защиты не нарушит соглашения об уровне услуг для бизнес-приложений. Бизнес рассчитывает, что новый партнер, подрядчик или сотрудник получит доступ к нужным системам без затяжных согласований. ИБ, в свою очередь, не может бесконечно расширять список исключений, потому что именно исключения часто становятся слабым местом всей модели защиты.
Особенно показательная зона — пользователи с высоким статусом или критичными ролями. На практике встречаются ситуации, когда для отдельных сотрудников отключают второй фактор аутентификации или периодическую смену пароля, потому что стандартные механизмы кажутся неудобными. Формально система защиты внедрена, но фактически ее эффективность снижается. В этот момент вопрос выходит за рамки технологий и становится вопросом управленческой дисциплины.
Техническая реализация: совместимость, наследие и фрагментарность решений
Когда компания переходит от стратегии к внедрению, сложности начинают быстро накапливаться. В большинстве крупных инфраструктур есть технический долг, унаследованные системы, устаревшие протоколы аутентификации, сервисные учетные записи, приложения с нестандартной логикой доступа и корпоративные системы, которые сложно менять без риска для непрерывности бизнеса.
Дополнительную нагрузку создает рост числа машинных айдентити: учетных записей сервисов, приложений, интеграций, API-ключей, сертификатов и других цифровых идентификаторов, которые используются без участия человека. Их количество растет вместе с автоматизацией и развитием цифровых сервисов. При этом управление такими айдентити часто остается менее прозрачным, чем управление доступом сотрудников.
Еще один фактор — технологическая совместимость. Компании используют разные классы решений: DLP для предотвращения утечек данных, PAM для управления привилегированным доступом, MFA для дополнительной проверки личности, средства классификации данных, системы мониторинга и управления событиями. Если эти инструменты плохо интегрируются между собой, значительная часть ресурсов уходит не на усиление защиты, а на согласование разрозненных продуктов и процессов.
Для бизнеса это выглядит как рост затрат без очевидного прироста эффективности. Для ИТ — как усложнение архитектуры и повышение требований к сопровождению. Для ИБ — как необходимость доказывать ценность каждого нового инструмента и одновременно отвечать за результат всей системы защиты.
Поэтому при выборе решений на первый план выходит не только функциональность, но и устойчивость при их эксплуатации. Например, в случае с MFA второй фактор аутентификации должен приходить быстро и стабильно в режиме 24/7. Сбой при доступе к ноутбуку, почте, удаленному серверу, CRM или другой критичной системе превращается не в простую техническую деталь, а в целую бизнес-проблему. Заявления поставщиков о стабильности важны, но реально оценить решение можно только через пилотирование, нагрузочные сценарии и дальнейшую эксплуатацию.
Человеческий фактор как постоянная переменная
Даже самая продуманная архитектура защиты сталкивается с человеческим фактором. Бизнесу нужно быстро нанимать людей под конкретные задачи, ИТ оперативно открывает доступы, а ИБ затем возвращает процесс в управляемый контур. Чем выше темп изменений, тем больше вероятность, что часть процедур будет восприниматься как лишняя бюрократия.
Если сотрудникам не объяснять, зачем нужна многофакторная аутентификация, почему опасны слабые пароли и чем рискованно использование общих учетных записей, меры защиты начинают восприниматься как помеха работе. В результате правила формально существуют, но в реальных процессах появляются обходные пути: доступы выдаются на больший срок, чем требуется, права не пересматриваются, исключения становятся привычной практикой.
Решить эту проблему только техническими средствами невозможно. Компании необходимо сочетать контроль, обучение и понятные правила. Пользователь должен понимать, что защита доступа нужна не для усложнения работы, а для сохранения устойчивости процессов, данных клиентов и доверия к компании. Руководители подразделений, в свою очередь, должны видеть связь между дисциплиной доступа и операционными рисками.
Как снизить напряжение между бизнесом, ИТ и ИБ
Защита учетных данных становится точкой напряжения тогда, когда каждая функция смотрит на нее только через свою задачу. Для бизнеса это скорость. Для ИТ — стабильность. Для ИБ — это контроль. Рабочая модель появляется там, где эти цели переводятся в общий язык рисков, приоритетов и измеримых результатов.
На практике этому помогают несколько принципов:
- начинать с критичных систем и наиболее рискованных сценариев доступа,
- заранее согласовывать допустимые исключения и порядок их пересмотра,
- оценивать решения не только по функциональности, но и по устойчивости в эксплуатации,
- вовлекать бизнес в принятие решений о рисках,
- регулярно проверять, как меры защиты работают в реальных процессах.
Для начала компании стоит провести инвентаризацию критичных точек доступа: кто подключается к ключевым системам, какие права используются постоянно, где есть привилегированные учетные записи, сервисные пользователи, подрядчики и исключения из стандартных правил. Такая карта помогает увидеть не только технические уязвимости, но и организационные разрывы: где доступ выдается вручную, где права сохраняются дольше необходимого, где отсутствует единый владелец процесса.
Следующий шаг — перевести защиту учетных данных в управляемый цикл. Для этого полезно закрепить правила выдачи и пересмотра прав, определить сценарии обязательной многофакторной аутентификации, отдельно описать порядок работы с привилегированным доступом и регулярно проверять, как эти меры выполняются на практике. Чем понятнее критерии и ответственность, тем проще бизнесу, ИТ и ИБ договариваться: не обсуждать каждое ограничение как отдельный спор, а опираться на заранее согласованную модель защиты.
Еще один практический ориентир — идти от сценариев, а не от перечня инструментов. Сначала стоит определить, какие доступы создают наибольший риск для бизнеса: вход в финансовые системы, подключение подрядчиков, администрирование серверов, доступ к персональным данным, работа с сервисными учетными записями. После этого проще выбрать меры защиты для каждого сценария, где будет достаточно многофакторной аутентификации, где необходим контроль привилегированных сессий, а где требуется регулярный пересмотр прав и владельцев доступа.
Отдельное внимание стоит уделить измеримым показателям. Защита учетных данных становится понятнее для бизнеса, когда ее можно описать не только через внедренные системы, но и через результаты: сколько критичных учетных записей находится под контролем, как быстро закрывается доступ у уволенных сотрудников и подрядчиков, какая доля привилегированных сессий записывается и анализируется, сколько исключений из правил действует в компании и как часто они пересматриваются. Такие метрики помогают обсуждать безопасность предметно, без абстрактных формулировок и взаимных претензий.
Наконец, полезно заранее договориться о правилах принятия решений. У каждого критичного процесса должен быть владелец со стороны бизнеса, технический ответственный со стороны ИТ и понятные требования со стороны ИБ. Если требуется исключение, оно должно иметь срок действия, обоснование и ответственного за пересмотр. Такой подход снижает количество ручных договоренностей, делает доступы более прозрачными и помогает сохранить баланс между скоростью работы, устойчивостью инфраструктуры и уровнем защиты.
Identity Security (безопасность личных данных) постепенно становится не отдельным техническим проектом, а частью управления компанией. Чем больше процессов завязано на цифровые профили сотрудников, подрядчиков, сервисов и приложений, тем выше цена ошибки в управлении доступом. Поэтому зрелая защита учетных данных строится не на запретах ради запретов, а на согласованной модели, в которой безопасность помогает бизнесу работать устойчиво, а не становится для него постоянным барьером.
