Журнал "Information Security/ Информационная безопасность" #4, 2026

Подтверждение соответствия СУБД требованиям регуляторов многие орга- низации сводят к формальному запол- нению чек-листа. На практике реализа- ция мер защиты требует не только зна- ния нормативной базы, но и понимания механизмов платформы. СУБД "Ятоба", сертифицированная ФСТЭК России по 4 УД и 4 КЗ (сертификат № 4327 от 19.11.2020), предоставляет необходимый набор инструментов, но без настройки не гарантирует соответствия и может привести к типовым ошибкам, которые выявляются при аудите. Определение контекста: модель угроз и классификация данных Технические мероприятия должны базироваться на актуальной частной модели угроз, разработанной в соответ- ствии с методическими документами ФСТЭК России. Перед конфигурирова- нием СУБД "Ятоба" необходимо сле- дующее: l определить класс защищенности информационной системы; l утвердить перечень обрабатываемых данных с разграничением по видам (пер- сональные данные, служебная инфор- мация, коммерческая тайна); l осуществить выборку актуальных угроз из банка данных угроз ФСТЭК России; l идентифицировать смежные компо- ненты (веб-приложения, API-шлюзы, сер- висные интеграционные шины), которые могут являться косвенными векторами атак на СУБД. Игнорирование подготовительного этапа приводит к ситуации, когда меры защиты либо избыточны, либо сфокуси- рованы не на критических узлах. Пример из практики: в одном из проектов раз- граничение доступа на уровне таблиц было выполнено корректно, но сервисная учетная запись системы оркестрации контейнеров обладала расширенными привилегиями, что нивелировало эффект других механизмов. Результатом подготовительного этапа должны стать два документа: модель угроз и перечень защищаемых объектов, на которые впоследствии ссылаются все политики. Реализация идентификации и аутентификации (ИАФ) В СУБД "Ятоба" управление учетными записями выполняется средствами самой системы и компонентом Jatoba Data Safe (JDS). Настройки для соответ- ствия требованиям 4 КЗ приказа № 64: 1. Уникальность субъектов доступа. Ошибка – использование групповых учетных записей. Для технических интег- раций и автоматизированных скриптов необходимо заводить отдельные учетные записи с привязкой к конкретному функ- циональному компоненту, что обеспечи- вает идентифицируемость действий в журналах аудита. При этом рекомен- дуется применять ролевой подход: соз- даются роли с необходимыми привиле- гиями, к которым присоединяются учет- ные записи пользователей. 2. Парольная политика. В JDS реали- зован механизм шаблонов, позволяю- щий единообразно применить политику ко всем пользователям. Минимальные параметры: длина пароля 8 символов; мощность алфавита 70 символов; коли- чество неудачных попыток входа 4 с последующей блокировкой. Рекомен- дуется увеличение длины пароля до 12 символов и включение всех категорий – прописные, строчные, цифры, специ- альные знаки. Это повышает стойкость хешей паролей к перебору. 3. Защита обратной связи. Отсутствие отображения пароля в явном виде реа- лизован на уровне клиентских подключе- ний и не требует модификации ядра. Однако рекомендуется проверять настройки логирования на стороне при- кладного ПО – были случаи, когда DEBUG-логи веб-приложений фиксиро- вали пароли в теле запроса. 4. Интеграция с внешними системами. При наличии в инфраструктуре LDAP или Kerberos целесообразна интеграция с ними. Это централизует управление жизненным циклом учетных записей. Вме- сте с тем следует учитывать, что политики корпоративного каталога могут быть менее строгими, чем требуемые, – в таком случае предпочтительна локальная поли- тика в СУБД "Ятоба" с синхронизацией паролей. Важно отметить, что при исполь- зовании сторонних методов аутентифи- кации соответствующее программное обеспечение должно иметь сертификат ФСТЭК России, так как приказ № 64 рас- сматривает только парольный вход. Доступ и привилегии Реализация принципа минимальных привилегий в СУБД "Ятоба" строится на 3 уровнях: ролевая модель, матрица доступа в JDS и механизм строчной безопасности (RLS). Данные механизмы реализуют требования УПД.5 из приказа № 21 ФСТЭК России от 18.02.2013 и ГОСТ Р 56545–2015 "Назначение мини- мально необходимых прав и привилегий пользователям, администраторам и лицам, обеспечивающим функциони- рование информационной системы". 1. Ролевая модель. Целесообразно выделить роли: администратор, разра- ботчик, аналитик, пользователь, сервис. Каждой определяется минимальный набор прав, исключающий избыточные операции (например, аналитику запре- щены DDL-операции). Сервисные учет- ные записи требуют особого внимания: не должны обладать привилегиями суперпользователя и должны иметь ограниченный срок. 2. Row-Level Security (RLS). Данный механизм применяется для разграниче- ния доступа на уровне строк и особенно 48 • СПЕЦПРОЕКТ Приказ No 64 ФСТЭК России: методика и типовые ошибки при приведении СУБД “Ятоба” к требованиям по безопасности информации азбираем практический опыт настройки СУБД “Ятоба” для выполнения требований по безопасности информации к СУБД, утвержденных приказом № 64 ФСТЭК России от 14.04.2023. Рассмотрены ключевые этапы: от построения модели угроз до эксплуатацион- ного контроля. Р Юрий Осипов, менеджер по продукту СУБД “Ятоба” компании “Газинформсервис