Круглый стол «Методы защиты систем управления базами данных: как предотвратить атаки на СУБД и обеспечить безопасность хранения и обработки информации»

В рамках третьего круглого стола совместного проекта Global Digital Space и Cyber Media эксперты обсудили методы защиты систем управления базами данных: как предотвратить атаки на СУБД и обеспечить безопасность хранения и обработки данных.

Специалисты поделились практическим опытом построения безопасных процессов работы с данными. В обсуждении приняли участие:

• Иван Манюк, бизнес-партнер по информационной безопасности (BISO) в банке Точка;
• Юрий Осипов, менеджер по продукту СУБД Jatoba компании Газинформсервис.

Эксперты рассказали порталу Cyber Media, почему пентесты СУБД — редкость, как меняется защита данных в условиях импортозамещения и что мешает бизнесу выстроить надежную безопасность вокруг одной из самых ценных активов — корпоративной базы данных.

Посмотреть видеоверсию интервью можно в Rutube, VK, YouTube и Дзен.

Cyber Media: По данным недавнего исследования, 65% российских компаний не проводят регулярные пентесты своих СУБД и систем хранения данных. Как вы думаете, что это — беспечность, экономия или особенность бизнес-модели?

Иван Манюк, банк Точка: Думаю, в исследовании имелось в виду скорее общее тестирование на проникновение, а не специфические пентесты именно СУБД. Честно говоря, о такой узкой практике я не слышал. Возможно, речь идет о тестировании в рамках сертификационных процедур или о каком-то изолированном анализе конкретного продукта СУБД.

Если говорить про финансовую отрасль, в которой я работаю, то у нас с пентестами все довольно строго и системно. ЦБ как мегарегулятор уже не первый год формирует эту культуру, и сейчас все банки и другие финансовые организации обязаны регулярно проводить тестирование на проникновение, как правило, ежегодно. Возможно, для МФО это происходит чуть реже, например, раз в два года.

Что касается других отраслей — не готов судить, там, наверное, все по-разному.

Юрий Осипов, Газинформсервис: Думаю, причина в том, что протестировать именно СУБД на проникновение не так просто. Сами по себе базы данных почти никогда не существуют изолированно. Они работают в связке с бизнес-приложениями, и именно эти приложения чаще всего становятся объектами атак. Основная поверхность атаки — это веб-приложения, которые используют данные из СУБД.

Сама база данных — это, по сути, лишь механизм хранения и обработки информации с набором стандартных интерфейсов подключения и команд. Поэтому атакуют не ее напрямую, а через уязвимости в логике бизнес-приложений: перехватывают пароли, получают повышенные привилегии и уже затем выходят на СУБД.

Да, есть класс атак вроде SQL-инъекций, но они тоже реализуются через оболочку, через приложение. Провести прямой пентест базы данных технически сложно. Проверить можно другое: избыточные привилегии, отсутствие паролей у пользователей, конфигурационные ошибки. Но провести «в лоб» пентест СУБД — это редкость. Цифры отражают не столько беспечность, сколько объективную техническую сложность такого тестирования.

Cyber Media: Как бы вы оценили текущий уровень защиты данных? Понятно, что финтех, скорее всего, опережает другие отрасли, но ведь остаются типовые проблемы и болевые точки. Какие из них вы бы выделили?

Иван Манюк, банк Точка: Могу говорить только про финансовые организации. В этой сфере я работаю уже более 15 лет. И это только мой опыт, и он не охватывает всю индустрию. Уровень защиты сильно варьируется даже внутри финтеха, не говоря уже о других отраслях. Чтобы объективно оценить ситуацию, нужна широкая статистика, например, по соответствию требованиям вроде ГОСТ 57580, но у меня такой задачи сейчас нет.

А вот что касается типовых проблем, тут все предельно ясно. Во-первых, это недостаточно эффективный контроль доступа. Во-вторых, сложности с защитой чувствительных данных: будь то персональные данные, банковская или коммерческая тайна, платежная информация. Основной способ обеспечить конфиденциальность — это шифрование. Причем наиболее эффективная реализация — это прозрачное шифрование данных (transparent data encryption).

Суть в том, что данные в расшифрованном виде существуют только в оперативной памяти и только в момент обработки. На диске и в передаче по сети они всегда зашифрованы. Это надежно, но имеет свои минусы: шифрование, даже симметричное, все равно влияет на производительность. А в финтехе задержки недопустимы: если клиент открывает приложение, и оно тормозит — это сразу проблема.

Еще одна трудность — доступность решений. Некоторые вендоры, которые раньше предоставляли удобные инструменты для такой защиты, сейчас недоступны. А в open source-сегменте аналогов пока немного, и с качеством там все непросто.

Юрий Осипов, Газинформсервис: Согласен, финтех действительно долгое время активно использовал продукты зарубежных вендоров, которые вкладывали значительные ресурсы в развитие своих решений, в том числе в части безопасности. Шифрование было одной из обязательных функций. Сейчас на российском рынке появились свои решения по СУБД, включая встроенное шифрование, в том числе и в нашей компании.

Но есть серьезная проблема с производительностью. Полное шифрование всех таблиц в базе данных может привести к колоссальным просадкам по скорости, вплоть до 40-кратного замедления. Более того, технически невозможно зашифровать все, например, шифрование первичных индексов либо недоступно, либо крайне затруднено. Поэтому сейчас на практике применяются более гибкие подходы — шифрование отдельных таблиц или полей. Это работает, но также дает нагрузку, и требует взвешенного подхода.

Вторая большая проблема — на уровне разработки. Многие разработчики бизнес-приложений вообще не задумываются о безопасности базы данных. Безопасная разработка у нас воспринимается как нечто, касающееся только приложений, а проектирование СУБД с учетом угроз — это пока не норма. Нет культуры защищенной архитектуры на уровне базы данных.

Дополнительно — большинство отечественных решений базируется на форках PostgreSQL, а сам «ванильный» Postgre довольно уязвим. Например, там можно установить пустой пароль, нет встроенной политики сложности паролей, и администратор по умолчанию видит все пользовательские данные. Все форки, включая наш, уже устраняют эти недостатки: добавляют расширенные политики паролей, разграничивают права суперпользователей и настраивают контроль доступа. Но все это бессмысленно, если само приложение работает от одного общего системного пользователя.

И в этом как раз самая серьезная уязвимость — приложения не фиксируют действия конкретных пользователей в СУБД. Все идет от имени одной сессии, и никакое разграничение прав в базе не помогает.

Есть и третий момент — нехватка квалификации. Многие специалисты продолжают использовать старые зарубежные СУБД, потому что они привычны и надежны. Но новые разработки не всегда реализуются с пониманием комплексной архитектуры безопасности. Хотя стандарты требуют учитывать защиту на уровне СУБД, на практике этим часто пренебрегают.

Простой пример — 1С. Это один из самых массовых продуктов в России, но в нем нет никакой защиты данных на уровне СУБД. Вся работа идет от имени одного пользователя, и сессия открывается один раз при запуске приложения. Дальше — никаких механизмов защиты внутри базы данных. И таких примеров, к сожалению, много.

Cyber Media: Давайте перейдем к типам атак на базы данных. Про SQL-инъекции мы уже начали говорить, но, вероятно, существует пул наиболее актуальных атак, с которыми сталкиваются российские компании сегодня. Какие угрозы вы бы выделили с учетом нашей региональной специфики?

Юрий Осипов, Газинформсервис: Начну, пожалуй, с самого распространенного типа атак — это SQL-инъекции. Суть в том, чтобы с помощью специально сформированных SQL-запросов получить несанкционированный доступ к данным в СУБД или даже повредить их. Известно порядка 10 основных типов SQL-инъекций, и выявить их зачастую непросто.

Сейчас реализовать реальную атаку такого рода стало сложнее: она требует значительных вычислительных ресурсов и часто фиксируется только на уровне логов. То есть, реагируют уже специалисты ИБ, отслеживая аномалии вручную или с помощью автоматизированных средств.

Сейчас, например, появился Oracle SQL Firewall, который они объявили в своей версии Oracle 23ai, — интересное решение. Но могу сказать, что у нас подобный механизм был реализован еще в 2020 году в системе Jatobe. Более того, в этом году мы выпускаем новую версию SQL-файрвола с элементами искусственного интеллекта. Он будет анализировать неавторизованные SQL-запросы в реальном времени и определять возможные попытки SQL-инъекций. Это очень сложная разработка, потому что атакующие — это, как правило, специалисты высокого уровня, и противостоять им непросто.

Но помимо внешних атак есть и другая, не менее важная угроза — внутренние инциденты. По данным аналитики, до 67% утечек из баз данных происходят по вине инсайдеров, то есть сотрудников компаний. Причем это могут быть как умышленные действия, так и случайные ошибки. В 2024 году количество таких случаев выросло в полтора раза.

Иван Манюк, банк Точка: Если говорить именно об атаках на базы данных, то большинство из них, так или иначе, связаны с инъекциями, в первую очередь — с SQL-инъекциями. Это класс атак, при которых злоумышленник, обходя логику приложения, получает возможность отправить в СУБД произвольный SQL-запрос — тот, что не должен был быть доступен пользователю в рамках нормального сценария.

Если говорить о других угрозах, то это уже не совсем атаки в классическом смысле, а скорее организационные и внутренние риски. Например, действия администраторов или сотрудников с высокими правами, которые могут скопировать базу данных, открыть к ней доступ через небезопасные порты и протоколы или вообще по ошибке опубликовать доступ во внешний интернет.

Я лично сталкивался с ситуациями, когда для соединения между двумя базами данных открывали внешние подключения. И в результате плохо защищенные БД оказывались доступны извне. И да, это действительно реальность — есть теневой рынок, где сотрудникам компаний предлагают деньги за кражу данных.

Cyber Media: Поскольку мы уже затронули тему инсайдеров, давайте поговорим о том, как сегодня компании мониторят безопасность СУБД. Какие есть практики, и насколько помогают поведенческие системы вовремя заметить, что сотрудник начал вести себя подозрительно?

Иван Манюк, банк Точка: Если говорить о средствах мониторинга именно на уровне СУБД, то основным инструментом здесь является отслеживание SQL-запросов. Это позволяет сформировать профиль нормального поведения пользователя — будь то человек или технический аккаунт. И когда поведение отклоняется от этого профиля, система может среагировать: сгенерировать алерт или даже заблокировать запрос до выяснения обстоятельств. Это первая и довольно эффективная линия защиты.

Соответственно, здесь можно говорить о двух подходах:

1. Превентивный, когда используется, например, SQL-файрвол, который сразу блокирует подозрительные действия.
2. Детективный, когда события логируются и передаются в SIEM-систему, где уже проводится анализ и реагирование.
   

Однако важно учитывать ключевую проблему — производительность. Системы безопасности и системы баз данных почти всегда находятся в конфликте интересов: чем глубже и тщательнее анализ, тем больше нагрузка на систему и медленнее ее работа.

Поэтому нужно искать баланс, и он в каждом случае свой. В одних сценариях важнее скорость, например, в финтехе, в других можно пожертвовать производительностью ради безопасности. Но это всегда компромисс. Более тщательный анализ требует больше ресурсов и замедляет обработку запросов. Уменьшаем нагрузку — снижаем точность обнаружения угроз.

В критически важных системах чаще выбирают быстродействие, особенно если задержки недопустимы для пользователей. Но бывают и некритичные базы, где допустима просадка в скорости ради повышения уровня безопасности. Хотя такие случаи скорее исключение.

Юрий Осипов, Газинформсервис: Да, вы абсолютно правы — это как раз зона ответственности систем класса SQL-файрволов. Такие решения есть у разных вендоров: будь то наша разработка, Гарда DB или Oracle. Принцип везде примерно одинаковый: используется обучающаяся модель, которая анализирует действия пользователей и формирует шаблоны типичного поведения — это и есть поведенческая аналитика.

Однако стоит понимать, что в случае с СУБД поведенческая аналитика работает не всегда идеально. Например, пользователь по своей бизнес-роли действительно может регулярно выполнять выборки данных — SELECT, JOIN, GROUP BY. Это вполне нормальное поведение. Но если вдруг этот же пользователь начинает выполнять команды INSERT или UPDATE, которых за ним раньше не замечалось — это уже отклонение от шаблона. Такие запросы система может автоматически заблокировать или как минимум зафиксировать.

Это помогает защитить СУБД от преднамеренного повреждения данных, то есть, ситуаций, когда инсайдер пытается внести несанкционированные изменения. Особенно хорошо такие системы работают в отношении, скажем, бизнес-аналитиков, у которых заранее понятен набор допустимых действий.

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

Все действия пользователей, включая SQL-запросы, сейчас подробно логируются. Эта информация сохраняется в отдельную базу событий ИБ, которая может быть интегрирована с SIEM-системами и отображаться в едином интерфейсе для офицеров безопасности. Это важно не только для текущего контроля, но и для расследования инцидентов постфактум.

Cyber Media: Как вы считаете, последние законодательные инициативы — это шаг вперед для информационной безопасности СУБД, или они, наоборот, тормозят развитие и создают больше сложностей?

Иван Манюк, банк Точка: Как бы я ни ответил на этот вопрос, кто-то наверняка останется недовольным. Но если говорить откровенно, с моей личной точки зрения, новые законодательные инициативы действительно могут быть драйвером развития информационной безопасности, в том числе в части защиты СУБД.

Когда на чашу весов кладутся конкретные и довольно ощутимые суммы штрафов, это становится серьезным аргументом в пользу того, чтобы компания начала что-то делать для повышения своей защищенности. Особенно когда речь идет об оборотных штрафах — они способны простимулировать кого угодно.

Возможно, изначально цель этих инициатив была не в том, чтобы «замотивировать» бизнес, но такой эффект, тем не менее, есть. И с этой точки зрения — да, это работает как дополнительный стимул для развития ИБ.

Юрий Осипов, Газинформсервис: С точки зрения бизнеса вендора могу сказать, что действия регуляторов, безусловно, стимулируют рынок, в том числе рынок решений в сфере ИБ. Это с одной стороны. А с другой — это просто необходимость. Потери экономики от мошеннических действий огромны, и во многом они касаются обычных граждан.

Ведь средства, которые мошенники вымогают у людей, не возвращаются в экономику, а уходят в теневой оборот. Поэтому обеспечение защиты информации и персональных данных — это не просто желание, а необходимость. Ситуация чем-то напоминает изменения в авиационной безопасности после первых террористических актов: да, новые меры неудобны, но с новыми угрозами надо научиться жить, и нужно минимизировать риски и последствия.

Сегодня теневой рынок данных растет, и это оказывает влияние как на отдельных людей, так и на экономику в целом. Все мы сталкиваемся с обзвонами, фишингом, попытками получить доступ к счетам, и без системной защиты с этим не справиться.

Поэтому я считаю, что инициативы государства абсолютно оправданы. Но, к сожалению, сейчас они носят в основном карательный характер в виде штрафов и ответственности. А вот мотивирующих механизмов пока недостаточно. Например, не хватает программ, которые бы поощряли компании инвестировать в безопасность — будь то налоговые льготы, субсидии или иные меры поддержки.

Cyber Media: Давайте спустимся на уровень ниже — к кадрам. Все-таки администраторы СУБД, DBI-специалисты, системные аналитики работают с данными напрямую. Как вы считаете, нужно ли обучать их вопросам информационной безопасности, или это зона ответственности исключительно специалистов по ИБ?

Юрий Осипов, Газинформсервис: Вы затронули очень тонкую и сложную тему — пересечение информационной безопасности и IT. Здесь действительно проходит грань между двумя службами: с одной стороны, специалисты по ИБ, отвечающие за сохранность данных, соблюдение регламентов и требований, с другой — IT-специалисты, на которых давит бизнес с требованием скорости и эффективности (Time to Market). Администраторы баз данных оказываются как бы «между молотом и наковальней», испытывая давление с обеих сторон.

Что касается обучения, насколько мне известно, все крупные компании обучают своих системных администраторов работе с СУБД с учетом требований безопасности. Это нормальная практика. Более того, я бы не стал утверждать, что информационная безопасность — это исключительная зона ответственности ИБ-специалистов. На деле 80% ИБ — это регламенты, и только 20% — технические средства.

Поэтому говорить, что «давайте просто научим всех кибербезу» — это упрощение. Очень часто системные администраторы знают аспекты безопасности не хуже специалистов по ИБ. И это логично — кто, как не DBI-специалист, лучше всего понимает, как работает база данных, где в ней слабые места и какие риски могут возникнуть.

Служба ИБ, в свою очередь, должна обеспечивать контроль и возможность аудита всех действий. Но это не исключает обучения, наоборот, я считаю, что компании сегодня серьезно вкладываются в обучение как ИБ-специалистов, так и администраторов. Например, наш учебный центр постоянно загружен: спрос на такие программы стабильно высокий, и его формируют как заказчики, так и сами вендоры СУБД.

Иван Манюк, банк Точка: В Точке все устроено довольно неоднородно — у нас структура децентрализованная, более плоская и широкая.

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

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

Обучать таких специалистов вопросам ИБ, на мой взгляд, нужно, но не просто «для общего развития». Обучение должно быть под конкретные задачи, чтобы им было понятно, зачем это нужно в их контексте.

Что касается вопроса о разграничении зон ответственности между ИТ и ИБ, тут все зависит от компании. Где-то логично передать вопросы безопасности ИТ-службе, особенно если она гораздо больше по численности. А где-то, на мой взгляд, разумнее выстраивать модель разделения обязанностей (segregation of duties).

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

Cyber Media: После громкой утечки из американского бюро кредитных историй Equifax в 2017 году, когда пострадали данные 143 млн человек, стало ясно, насколько важны базовые меры защиты — вроде сильных паролей и своевременного устранения уязвимостей. Какие практические шаги вы рекомендуете сегодня, чтобы выстроить безопасные процессы работы с данными, особенно персональными? Например, что вы думаете о таких подходах, как обезличивание или маскирование?

Юрий Осипов, Газинформсервис: Если говорить об утечке в Equifax и упомянутых слабых паролях, то важно уточнить — о каких паролях идет речь? Пароли на уровне бизнес-приложений, баз данных, администраторских консолей? Это все разные уровни абстракции, и каждый из них требует своей модели защиты. Безопасность организации — это всегда многослойная система.

Эта система начинается с защиты сети и внешних соединений, затем переходит к серверам и рабочим станциям, потом — к бизнес-приложениям, и, наконец, к системам управления базами данных. А в самом центре — данные, самая ценная часть. Именно к ним и стремится атакующий, проходя через эти слои.

Универсального совета для всех компаний не существует. У каждой свои процессы, требования, инфраструктура, партнеры и риски. Поэтому любое построение защиты должно начинаться с анализа рисков. Это основа. Нужно оценить возможные инциденты, их последствия в деньгах, времени на восстановление, репутационных потерях. Этот аудит поможет определить приоритетные уязвимости — и уже после этого выстраивать защиту.

Но есть базовые рекомендации, актуальные для всех:

• Использование антивирусов.
• Грамотные сетевые настройки и работающий файрвол.
• Безопасные конфигурации рабочих станций.
• Политики управления паролями.
• Разграничение прав доступа на всех уровнях — от рабочих станций до СУБД и приложений.

Это все элементы комплексного подхода. Без него построить защищенную систему невозможно.

И наконец, немного иронии: самый безопасный компьютер — это тот, который отключен от сети. И от электричества.

Иван Манюк, банк Точка: Вопрос вы затронули действительно важный. Здесь сразу встает классический конфликт между безопасниками и ИТ-службами, будь то разработчики приложений или инфраструктура. Полный уровень безопасности практически не совместим с нормальным функционированием систем, особенно если речь идет об интернет-ориентированных решениях. Чем шире открыта система, тем больше потенциальных угроз.

В идеале основным инструментом, который может помочь, является анализ рисков. Он позволяет хотя бы приблизительно оценить, где тонкие места. Но проблема в том, что для точного анализа необходима репрезентативная статистика по угрозам и инцидентам, а ее в открытом доступе крайне мало. Особенно это касается коммерческих компаний — далеко не обо всех инцидентах сообщают, и уж тем более редко раскрывают настоящие причины.

Поэтому часто приходится действовать на основе экспертного мнения, а оно, как известно, у всех разное. В итоге применимо простое правило: где тонко — там и рвется. Например, если у администратора базы данных пароль «admin-admin» — неудивительно, что кто-то получит несанкционированный доступ.

Из практических шагов в первую очередь стоит говорить о контроле доступа:

• контроль прав пользователей и администраторов;
• обязательное внедрение многофакторной аутентификации;
• мониторинг действий, особенно на уровне СУБД.

База данных — это слой, о котором зачастую помнят только ее администраторы и разработчики, но именно там происходит многое из того, что критично для безопасности. И потому важен постоянный мониторинг активности на уровне БД — кто, когда, с какими правами, к каким данным обращался.

Cyber Media: Какие технологии защиты баз данных и СУБД, на ваш взгляд, будут определять повестку в ближайшие 3–5 лет? Ждать ли появления решений, которые закроют текущие уязвимости или, наоборот, усилят риски и создадут новые векторы атак?

Юрий Осипов, Газинформсервис: Если говорить о перспективах на ближайшие 3–5 лет, то, конечно, в фокусе будет ИИ. Это модная тема, но, на самом деле, абсолютно обоснованная. Сегодня только с его помощью можно эффективно анализировать аномальные запросы, распознавать подозрительные действия, отслеживать проникновения, то есть, выявлять угрозы, которые сложно заметить традиционными методами.

Но при этом, насколько я вижу, пока ни одна СУБД не использует GPU-процессора именно для задач безопасности. Это важный момент. Было бы логично разгрузить основные процессоры от анализа событий и передать эту функцию отдельным чипам, но таких реализаций я пока не встречал. Это одно из потенциальных направлений развития.

Вторая важная тема — шифрование. Сегодня шифрование и обработка данных происходят на одном и том же процессоре. А это значит, что при высокой нагрузке приходится выбирать между безопасностью и производительностью. На мой взгляд, в будущем будет происходить активный поиск технологического компромисса: как обеспечить сильное шифрование без потерь в скорости.

Если удастся разделить задачи шифрования и вычислений между разными аппаратными модулями, это будет серьезный шаг вперед.

Но тут есть и обратная сторона. Искусственный интеллект — это не только инструмент защиты, но и инструмент атаки. Уже есть примеры, когда злоумышленники используют ИИ для генерации вредоносного кода и автоматизации атак. Так что, в ИБ это щит и меч одновременно.

Иван Манюк, банк Точка: Честно говоря, когда спрашивают о перспективах на 3–5 лет, я уже с трудом представляю, как можно уверенно прогнозировать даже на 2 года вперед. Все меняется очень быстро. Но очевидно, что нас ждет что-то прорывное в плане технологий.

Один из возможных векторов изменений — резкий рост вычислительных мощностей. Если ресурсы вырастут хотя бы на порядок, это позволит создавать такие машины, которые смогут в реальном времени расшифровывать данные, зашифрованные, например, RSA. В результате злоумышленники теоретически смогут вскрывать карточные данные и другие защищенные данные на лету. И тогда начнется новая волна развития криптографии: алгоритмы, которые требуют еще больше вычислительной мощности, но обеспечивают большую стойкость. Такие математические подходы уже существуют, просто пока они мало применяются из-за своей ресурсоемкости.

Отдельно стоит отметить искусственный интеллект. Его используют не только для защиты, но и для атак. ИИ уже помогает злоумышленникам находить zero day-уязвимости и придумывать нестандартные способы обхода защиты. В то же время сам ИИ может стать очень мощным инструментом для защиты, особенно в тех зонах, где традиционные методы плохо работают.

Например, в управлении доступом. Построение ролевой модели доступа — это очень трудоемкий и медленный процесс. Пока опросишь сотрудников, соберешь данные, настроишь роли — бизнес уже изменился, и модель устарела. А если компания быстро развивается и меняется, это становится настоящей проблемой. И здесь искусственный интеллект может помочь, особенно за счет понимания семантики: он сможет анализировать, кому и зачем нужен доступ, даже если заранее такие роли не были предусмотрены. Это решает сразу много проблем — и делает контроль доступа намного точнее и адаптивнее.