Необходимость обеспечения безопасности данных и их сохранности осознают все, однако на практике задумываются о нем нередко в последнюю очередь — уже после того, как информационные системы внедрены и переданы в промышленную эксплуатацию. Между тем, есть серьезные сомнения в том, что такая «лоскутная» безопасность сможет надежно защитить корпоративные данные. Как добиться того, чтобы защита данных реально работала? Какие архитектурные принципы и компоненты для этого требуются? Какие изменения в архитектуру сохранности и безопасности корпоративных данных придется внести при переходе к широкому созданию и применению ИИ-моделей? Эти вопросы мы обсудили с экспертами в преддверии главного осеннего мероприятия в области данных — форума «Управление данными — 2026».

«Безопасность данных — это не финальный этап проекта, а его фундамент, закладываемый до появления первой строчки архитектуры, — подчеркивает Алексей Нейман, исполнительный директор Ассоциации больших данных. — Согласно Отраслевому стандарту защиты данных, разработанному нашей ассоциацией, ответственность за защиту данных закрепляется еще до старта проекта за конкретным должностным лицом: от заместителя генерального директора до выделенного CISO, отвечающего исключительно за защиту информации. Прежде чем согласовывать модель данных, платформу хранения или каталог, организация должна иметь актуальную политику защиты информации и стратегию мероприятий, обновляемую на регулярной основе. Ключевой шаг — моделирование угроз и оценка потенциального ущерба: они должны предшествовать выбору технических решений, а не “догонять” их постфактум. Отдельного внимания требует контроль подрядчиков и внешних организаций, имеющих доступ к персональным данным — эти требования закладываются в договорные и технические механизмы с самого начала. И, конечно, роли владельца данных, дата-стюарда и офицера по безопасности должны определяться на этапе замысла системы, а не после первого инцидента».

Как отмечает Николай Шевцов, CDO ОТП Банка, проработка аспектов безопасности данных на ранних стадиях создания систем означает на практике, что классификация становится обязательным атрибутом метамодели буквально уже с первого дня: «Каждый объект при регистрации в каталоге получает категорию: персональные данные, банковская тайна, коммерческая тайна, публичные данные. При таком подходе каталог — это не просто справочник, а “источник правды” для средств защиты: ролевая модель, маскирование, правила DLP берут атрибуты из него, а не ведутся отдельно и вручную. На этапе проектирования служба ИБ участвует в приемке BRD, FSD, схем потоков и проверяет конкретное: зачем поток копирует персональные данные, есть ли для этого основание, нельзя ли обойтись псевдонимизацией. И еще два принципа: минимизация на входе и назначенный владелец домена, согласующий доступ, ведь, как известно, без ответственности любая техническая схема разграничения деградирует за полгода».

Безопасность становится архитектурным требованием, которое необходимо закладывать на этапе проектирования, добавляет Сергей Коваленко, главный инженер Удостоверяющего центра «ЭТП ГПБ Консалтинг»: «На практике это выглядит так: разрабатывается модель ABAC на уровне записей и полей, встраивается автоматическая классификация данных (персданные, КИИ), на основе которой динамически применяются маскирование, шифрование или ограничение доступа. Потоки данных шифруются на всех этапах, а документация разрабатывается параллельно с архитектурой, а не постфактум для проверки регуляторов».

Олег Гиацинтов, технический директор DIS Group, уверен, что налаженное взаимодействие специалистов по управлению данными с их коллегами из ИБ имеет очень важное значение, когда речь идет об обеспечения безопасности информационных систем: «Ведь риски, связанные с данными, можно и нужно анализировать, предупреждать, выявлять и минимизировать, используя в том числе методологию и инструменты Data Governance & Management. Среди них и разделение доступа на основе каталога данных, и оперативный анализ системных журналов в Data Lakehouse, и маскирование чувствительных данных».

«Я описываю архитектуру пятью слоями: учет и классификация активов; разграничение доступа на основе атрибутов данных и доменной модели; защита самих данных — шифрование, токенизация, маскирование для тестовых и продуктивных сред; контроль перемещения и выгрузок; наконец, сохранность в узком смысле — резервирование, восстановление, аудит и прослеживаемость, — делится своими наработками Шевцов. — Тщательнее всего нужно прорабатывать классификацию: если она неполна, все вышестоящие процедуры контроля защищают не то, что нужно. Второй критичный участок — тестовые среды, выгрузки и привилегированный доступ, включая подрядчиков, это основной канал утечек. Чтобы его перекрыть, требуются обезличивание для разработки, тегирование выгрузок и контроль сессий администраторов. Третий — восстановимость: нужны неизменяемые копии для минимизации последствий от атак шифровальщиков и регулярные учения по фактическому восстановлению, потому что резервная копия, которую ни разу не разворачивали, — это всего лишь гипотеза успешного восстановления».

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

Самая недооцененной зоной риска Борисов считает неструктурированные файловые массивы — сетевые папки, архивы договоров, техническая документация, почта, сканы и «окончательные» версии документов: «Именно там одновременно “живут” персональные данные, коммерческая тайна, дубликаты, устаревшие версии и документы без владельца. Здесь DAG-подход (выявление, классификация и управление неструктурированными данными) становится основой безопасности. Нельзя надежно ограничить доступ к тому, что не обнаружено, и нельзя корректно хранить то, чья ценность и принадлежность неизвестны».

Согласно видению Коваленко, архитектура строится на основе принципа нулевого доверия (Zero Trust): «Наиболее критичны следующие четыре аспекта: управление доступом (IAM/ABAC), поскольку здесь чаще всего возникают уязвимости; классификация и защита данных — они позволяют разделять информацию по уровням чувствительности и применять к ней соответствующие меры защиты; сквозной аудит и наблюдаемость — основа для расследования инцидентов; безопасность инфраструктуры, включающая сетевую сегментацию, изоляцию сред и использование сертифицированных СЗИ. Наибольшие проблемы возникают на стыках этих направлений, поэтому их проработка должна вестись комплексно».

Особые требования предъявляются к субъектам критической информационной инфраструктуры, напоминает Коваленко: «Для субъектов КИИ крайне важны не только сертифицированные СЗИ, но и регулярное тестирование защищенности, а также выстраивание реально работающих процессов реагирования на инциденты. Особое внимание требуется уделять персональным данным и конфиденциальной информации — их классификация, маскирование и шифрование должны быть встроены в архитектуру с самого начала. Компании, работающие с такими данными, обязаны строго соблюдать требования 152-ФЗ и отраслевых регуляторов, что требует наличия не только технических решений, но и формализованных процедур управления доступом и аудита всех операций с данными».

Нейман резюмирует: «Эффективная архитектура строится как последовательность защитных контуров, охватывающих весь жизненный цикл данных: управление и ответственность, периметр и сетевая защита, управление доступом, контроль уязвимостей и обновлений, мониторинг и реагирование на инциденты, безопасность приложений. Практика отрасли предполагает использование межсетевых экранов с настроенной фильтрацией трафика по периметру, двухфакторную аутентификацию, регулярную инвентаризацию информационных ресурсов, устранение критических уязвимостей в течение 30–60 дней, непрерывный мониторинг ИБ, тестирование на проникновение не реже раза в полгода и ежегодный внутренний аудит».

По наблюдениям Неймана, сейчас компании выстраивают AI Governance на тех же принципах, что и «классическое» управление данными, — безопасность и конфиденциальность «по умолчанию» становятся стандартом де-факто: защита и приватность закладываются в настройки каждой ИИ-системы с самого начала, а не добавляются позже как опция. «Внедрение ИИ, особенно автономных агентов, создает новый класс уязвимостей, — поясняет Нейман. — Такие уязвимости компании классифицируют по типу риска и потенциальному ущербу и передают в зону ответственности службы ИБ, которая адресует каждый класс соответствующими мерами. Фактически ИБ-служба встраивает в AI Governance контур защиты для управления киберрисками, специфичными для ИИ-моделей и агентов».

Борисов предлагает взглянуть на вопрос под другим углом: «Широкое применение ИИ радикально расширяет периметр. Каждый документ, попавший в индекс (будем говорить только про инференс, не затрагивая обучения), потенциально становится источником ответа модели. Поэтому в архитектуру должны быть встроены контролируемый конвейер данных, проверка происхождения и целостности файлов, маркировка чувствительности, наследование прав доступа при поиске и RAG. ИИ должен видеть не “все, что нашлось”, а только корпус данных, доступный конкретному пользователю в конкретном контексте. Платформа подготовки данных для ИИ должна соединить эти контуры: превратить файловую “помойку” в наблюдаемый, классифицированный и управляемый слой корпоративного знания».

Обучающие выборки становятся самостоятельным классом активов: их нужно учитывать, версионировать и связывать с моделями, чтобы на вопросы о том, на каких данных обучена модель и было ли для этого правовое основание, отвечать за минуты, а не за недели, считает Шевцов: «Очень часто компании недооценивают то, что производные артефакты наследуют чувствительность источника: векторные индексы, эмбеддинги и кэши RAG позволяют восстанавливать фрагменты исходных данных, поэтому защищать их надо наравне с исходниками. RAG-контур обязан фильтровать выдачу по правам конкретного пользователя на уровне поиска, иначе языковая модель превращается в удобный инструмент для обхода всей ролевой модели доступа. Добавьте сюда новые классы угроз (инъекции в промпт, извлечение запомненных данных, утечку через внешние API), и перед вами — организационный минимум в виде реестра моделей с владельцами и регулярным пересмотром.