Пункт 5.2 приложения 3 к ПТКЗИ: криптографическая защита информации при хранении

Смысл требования

Пункт 5.2 приложения 3 к ПТКЗИ – практический разбор требования «шифрование при хранении». Пункт 5.2 относится к защите информации не при передаче, а при хранении внутри информационной системы. Его смысл состоит в том, что владелец ИС должен оценить, где именно в системе хранится информация ограниченного распространения или предоставления, и при необходимости обеспечить её конфиденциальность и контроль целостности криптографическими методами до или в процессе размещения на носителе, в базе данных, файловом хранилище, резервной копии либо ином компоненте хранения.

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

Формулировка требования

Приложение 3 к Положению о порядке технической и криптографической защиты информации в информационных системах, предназначенных для обработки информации, распространение и (или) предоставление которой ограничено, утверждённому приказом Оперативно-аналитического центра при Президенте Республики Беларусь от 20 февраля 2020 г. № 66, в редакции приказа от 10 декабря 2024 г. № 259, с учётом изменений, внесённых приказом от 27 мая 2026 г. № 98 (далее – Приложение 3 к ПТКЗИ), раздел «Обеспечение криптографической защиты информации», пункт 5.2: «обеспечение конфиденциальности и контроля целостности информации при ее хранении в информационной системе (средства предварительного шифрования)».

Обязательность применения

По таблице приложения 3 требование пункта 5.2 является обязательным для классов 4-бг и 3-бг. Для классов 4-ин, 4-спец, 4-юл, 4-дсп, 3-ин, 3-спец, 3-юл и 3-дсп оно имеет рекомендательный статус.

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

Что именно должно защищаться

Ошибка в реализации пункта 5.2 часто состоит в том, что владелец ИС рассматривает только “основную базу данных” и забывает о вторичных местах хранения. В реальной инфраструктуре чувствительная информация редко хранится только в одном месте. Она может присутствовать в рабочих каталогах, резервных копиях, дампах БД, логах, временных файлах, экспортных выгрузках, файловых архивах, виртуальных дисках и на съёмных носителях.

• Основные информационные ресурсы. Базы данных, файловые хранилища, объектные хранилища, документы, карточки, записи, электронные дела и иные рабочие массивы информации.
• Резервные копии. Копии баз данных, виртуальных машин, файловых ресурсов, системных конфигураций и прикладных данных. Часто содержат тот же объём защищаемой информации, что и рабочая система.
• Выгрузки и отчёты. Excel-файлы, CSV, XML, архивы, пакетные выгрузки, отчётные формы и временные наборы данных, которые создаются для обмена, анализа или передачи.
• Дампы и технологические копии. Дампы СУБД, снимки виртуальных машин, копии дисков, тестовые наборы данных, staging-среды и временные копии для отладки.
• Журналы и события безопасности. В отдельных случаях могут содержать персональные данные, идентификаторы, адреса, сведения о действиях пользователей и признаки инцидентов.
• Носители и виртуальные диски. Физические диски, LUN, тома, виртуальные диски, контейнеры, съёмные носители и иные объекты, где информация сохраняется в состоянии покоя.

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

Предварительное шифрование: что это означает на практике

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

Конкретная реализация может находиться на уровне файла, контейнера, резервной копии, прикладного объекта или иного объекта хранения. Однако нельзя автоматически считать любую функцию «шифрования диска», TDE или шифрование хранилища полным выполнением пункта 5.2: необходимо показать, какой объект защищается, от какого сценария доступа, где находятся ключи и обеспечивается ли контроль целостности.

• Шифрование носителя или тома. Хорошо защищает при изъятии или подключении носителя, но обычно не препятствует чтению данных через работающую систему уполномоченной учётной записью.
• Шифрование файлов и контейнеров. Позволяет отделить доступ к зашифрованному объекту от доступа к файловой системе.
• Шифрование резервных копий и выгрузок. Защищает вторичные копии, которые часто выходят за пределы основной системы хранения.
• Прикладное или полевое шифрование. Может ограничивать доступ к отдельным данным, но требует точной интеграции, управления ключами и проверки целостности.

Применимость конкретного механизма должна быть закреплена в ТЗ и подтверждена проектной и эксплуатационной документацией. Название функции шифрования не заменяет такого обоснования.

Что следует подтвердить при проверке

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

• определены ли информационные ресурсы и объекты хранения, к которым применяется пункт 5.2;
• указано ли в ТЗ, ЛПА, эксплуатационном регламенте или проектной документации, где требуется предварительное шифрование;
• понятно ли, какой уровень шифрования выбран: диск, том, контейнер, файл, база данных, поле, резервная копия или прикладной объект;
• используются ли средства, допустимые для применения в рамках конкретной ИС и требований к СКЗИ;
• определён ли порядок управления ключами, их хранения, резервного копирования, смены, уничтожения и действий при компрометации;
• обеспечивается ли контроль целостности защищаемых объектов хранения, а не только их конфиденциальность;
• охвачены ли резервные копии, выгрузки, дампы, технологические копии и временные файлы, если они содержат защищаемую информацию;
• можно ли показать фактические настройки, политики, журналы, сведения о ключах, инструкции администраторов и результаты проверки восстановления.

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

Варианты реализации

Организационный вариант.

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

Шифрование носителей и томов.

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

Шифрование файлов, контейнеров и архивов.

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

Шифрование на уровне СУБД или приложения.

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

Комбинированный вариант.

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

Что целесообразно закрепить в ТЗ, ЛПА и ОРД

Для обязательных классов следует прямо определить, какие объекты хранения защищаются средствами предварительного шифрования. Если владелец предполагает не включать требование в ТЗ или использовать компенсирующие меры, нужен порядок пункта 12 Положения, а не простая запись «не применяется».

Для пункта 5.2 документы должны описывать не общую фразу “использовать шифрование”, а конкретную модель защиты информации при хранении. Проверяющему должно быть понятно, какие данные защищаются, где они хранятся, каким способом шифруются, кто управляет ключами и как проверяется сохранность и восстановимость данных.

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

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

Возможность технической реализации и инструменты

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

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

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

Типичные ошибки при реализации

• шифруется только основной диск сервера, но резервные копии и выгрузки остаются в открытом виде;
• используется шифрование диска, хотя основной риск связан с доступом к работающей СУБД или приложению;
• ключи шифрования хранятся рядом с зашифрованными данными или доступны тем же лицам, от которых данные должны быть защищены;
• нет процедуры резервного копирования ключей, из-за чего восстановление данных зависит от одного администратора или одного носителя;
• не проверяется восстановление зашифрованных резервных копий;
• временные файлы, дампы, отчёты и экспортные выгрузки не попадают в модель шифрования;
• шифрование включено технически, но не отражено в ТЗ, ЛПА, инструкциях и эксплуатационных регламентах;
• не определён порядок действий при компрометации ключа;
• контроль целостности подменяется только правами доступа без криптографического или иного проверяемого механизма;
• используется неподходящее средство шифрования без анализа его допустимости для конкретной ИС и требований к СКЗИ.

Вывод

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

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

Связанные материалы

• Защита информации при передаче по открытым каналам
• Контроль целостности информации в ИС
• Резервное копирование виртуальных машин

Нормативная основа

• Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 с учётом изменений, внесённых приказом № 98 от 27.05.2026 – приложение 3, пункт 5.2; пункт 12 о требованиях к СКЗИ и условиях невключения отдельных обязательных требований; пункт 20 о действиях при компрометации ключей. Официальный текст