Защита документов при хранении в 2026 году держится на четырёх блоках: шифрование данных на носителе и в канале передачи, аудит доступа с журналированием, контроль утечек через DLP и права по принципу минимальных привилегий. Этого набора достаточно, чтобы пройти проверку Роскомнадзора и внутренний аудит безопасности без авральных доработок.
Минимальная рабочая конфигурация выглядит так: LUKS2 на серверах Linux или BitLocker в режиме XTS-AES-256 на Windows, ZFS encryption на NAS под TrueNAS, TLS 1.3 на всех сервисах с документами, auditd или Advanced Audit Policy для файловых операций, DLP-политики в режиме мониторинга перед включением блокировки. Ключи хранятся отдельно от данных, журналы защищены от удаления, резервные копии ключей проверены на восстановление.
Ниже разобраны конкретные команды и параметры: cryptsetup, Enable-BitLocker, zfs create с encryption=on, конфигурация Nginx и Apache под TLS 1.3, правила auditd, схема выгрузки логов в SIEM, политики Microsoft Purview и SearchInform, шаги по GDPR и ФЗ-152, чек-лист сборки защищённого хранилища, типовые ошибки и порядок тестирования перед проверками.
Шифрование данных при хранении и передаче: базовый уровень защиты
Шифрование документов делится на два независимых контура: данные на носителе (data-at-rest) и данные в канале передачи (data-in-transit). Первый закрывает кражу диска, снапшота и резервной копии, а также доступ к файлам из-под чужой операционной системы. Второй защищает трафик между клиентом, СЭД, файловым сервером и внешними получателями.
Симметричный стандарт для обоих контуров один: AES-256. Различаются режимы. На блочных устройствах применяют XTS-AES-256, потому что он не раздувает данные и корректно работает со смещением блоков при перезаписи. В сетевых протоколах применяют GCM: он добавляет аутентификацию каждого пакета, и подмена блока приводит к разрыву сессии. Проверять нужно оба контура отдельно, потому что зашифрованный диск ничего не даёт при передаче документов по открытому HTTP внутри офисной сети.
Шифрование дисков и файловых систем: LUKS, BitLocker, ZFS
Для серверов Linux базовый вариант - LUKS2. Формат LUKS2 поддерживает Argon2 для вывода ключа из парольной фразы, резервные заголовки и несколько слотов ключей, что упрощает смену пароля без перешифрования данных. Типовая последовательность для отдельного диска:
cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --key-size 512 --hash sha256 /dev/sdb cryptsetup luksOpen /dev/sdb cryptdocs mkfs.ext4 /dev/mapper/cryptdocs cryptsetup luksHeaderBackup /dev/sdb --header-backup-file /root/keys/sdb-header.img cryptsetup luksDump /dev/sdb
Параметр --key-size 512 для XTS означает два ключа AES-256: один для данных, второй для настройки отбеливания. Автоматическое подключение при загрузке настраивают через /etc/crypttab и /etc/fstab:
# /etc/crypttab cryptdocs UUID=6c8f1e2a-... none luks,discard # /etc/fstab /dev/mapper/cryptdocs /srv/docs ext4 defaults,noatime 0 2
Для Windows применяют BitLocker с шифром XTS-AES-256. Включение через PowerShell без ручного обхода мастера:
Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -TpmProtector -UsedSpaceOnly manage-bde -on "D:" -RecoveryPassword -EncryptionMethod XtsAes256 BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId (Get-BitLockerVolume -MountPoint "C:").KeyProtector[0].KeyProtectorId Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionMethod, ProtectionStatus
Ключ восстановления обязательно уходит в Active Directory или Azure AD сразу при включении шифрования. Если этот шаг пропущен, а TPM вышел из строя, диск читается только через полную переустановку с потерей данных.
Для NAS и файловых серверов на ZFS шифрование включается на уровне датасета, а не всего пула. Такой подход позволяет держать зашифрованными только каталоги с документами, а кэш и системные наборы оставить без накладных расходов:
zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/docs zfs load-key tank/docs zfs get encryption,keystatus,keyformat tank/docs zfs unload-key tank/docs zfs send -w tank/docs@snap | ssh backup-host zfs receive -u backup/docs
Ключ ZFS можно хранить в файле: keylocation=file:///root/keys/docs.key с правами 400 и владельцем root. Ключ в файле упрощает автозагрузку, но превращает защиту в «шифрование против кражи диска»: получивший root-доступ прочитает и файл ключа. Флаг -w в zfs send сохраняет шифрование в потоке, поэтому резервная копия остаётся зашифрованной и на стороне приёмника.
Производительность зависит от AES-NI. На процессорах с аппаратным ускорением XTS-AES-256 выдаёт больше гигабайта в секунду на ядро, и накладные расходы на файловых операциях почти не заметны. Без AES-NI просадка на массовом копировании достигает 30 процентов и выше, а на слабых NAS-платформах упирается в процессор раньше, чем в диски. Проверить поддержку можно через /proc/cpuinfo по флагу aes.
| Решение | Сценарий | Управление ключами | Ограничения |
|---|---|---|---|
| LUKS2 | Серверы Linux, отдельные диски и разделы | Парольная фраза, файл ключа, несколько слотов | Нет встроенной репликации, заголовок нужно копировать отдельно |
| BitLocker | Windows Server и рабочие станции | TPM, пароль, ключ восстановления в AD или Azure AD | Требует TPM 1.2+ или стартового ключа на USB |
| ZFS encryption | NAS, TrueNAS, файловые серверы | Ключ в файле, парольная фраза, raw-поток zfs send | Зашифрованы только данные, записанные после включения; потеря ключа делает датасет нечитаемым |
Настройка TLS для защиты данных при передаче
В 2026 году рабочий минимум для каналов передачи документов - TLS 1.3. Протоколы TLS 1.0 и 1.1 отключены в основных браузерах и платёжных требованиях, а SSLv3 считается скомпрометированным. Для Nginx конфигурация серверного блока занимает несколько строк:
server {
listen 443 ssl;
http2 on;
ssl_certificate /etc/letsencrypt/live/docs.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/docs.example.com/privkey.pem;
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
ssl_stapling on;
ssl_stapling_verify on;
}
Для Apache действует та же логика, синтаксис отличается: SSLProtocol -all +TLSv1.3, SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256, SSLUseStapling on. Порядок шифров в TLS 1.3 определяется клиентом, поэтому параметр ssl_prefer_server_ciphers влияет только на совместимость с TLS 1.2.
Сертификаты обновляют автоматически: certbot --nginx -d docs.example.com --deploy-hook "nginx -s reload", затем certbot renew --dry-run для проверки таймера. Проверка фактического протокола выполняется одной командой: openssl s_client -connect docs.example.com:443 -tls1_3. Если соединение устанавливается, а в выводе видно TLSv1.3 и шифр TLS_AES_256_GCM_SHA384, канал настроен верно. Параметр -brief убирает лишний вывод сертификата.
Для внутренних сервисов между микросервисами применяют mTLS: сервер проверяет клиентский сертификат, а не только пароль или токен. В Nginx это ssl_client_certificate /etc/ssl/internal-ca.crt и ssl_verify_client on. Внутренний удостоверяющий центр выпускает короткоживущие сертификаты на 30-90 дней, что снижает ценность украденного ключа.
Ключи шифрования не хранят рядом с данными. Рабочие варианты: HSM для крупных инсталляций, HashiCorp Vault с аудитом каждого обращения, облачные KMS уровня AWS KMS или Yandex Cloud KMS с ролями доступа. Ротация ключей раз в год, а при увольнении сотрудника с доступом к хранилищу - немедленно. Потеря ключа равна потере данных, поэтому копия ключа и проверенный сценарий восстановления обязательны до ввода системы в эксплуатацию.
Аудит доступа к документам и журналирование в СЭД
Аудит отвечает на три вопроса: кто открыл документ, что с ним сделал и когда. Журналировать нужно вход и выход пользователя, открытие, чтение, копирование, изменение и удаление документов, смену прав, экспорт списков, попытки доступа к закрытым папкам и печать. В СЭД добавляются версии документа, скачивание, рассылка по почте, смена статуса согласования и назначение ответственных.
Формальный перечень событий Windows: 4624 и 4634 для входа и выхода, 4625 для неудачного входа, 4656 и 4663 для обращения к объекту и файловой операции, 4660 для удаления, 4670 для изменения прав. Эти идентификаторы удобно держать под рукой при настройке фильтров в SIEM, потому что именно на них строятся готовые правила обнаружения.
Настройка аудита в Windows и Linux
В Windows аудит включается на уровне политики, затем на конкретных папках задаётся SACL. Через командную строку с правами администратора:
auditpol /set /subcategory:"File System" /success:enable /failure:enable auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /get /category:"Object Access"
Либо через gpedit.msc: Computer Configuration, Windows Settings, Security Settings, Advanced Audit Policy Configuration, Object Access, Audit File System. SACL на каталог с документами назначается в свойствах папки, вкладка Security, Advanced, Auditing, либо скриптом через Set-Acl с правилом FileSystemAuditRule. Просмотр событий - Event Viewer, журнал Security, фильтр по Event ID 4663 с указанием пути к файлу.
В Linux аудит файловых операций закрывает auditd. Правила складывают в отдельный файл, чтобы не смешивать с дистрибутивными:
# /etc/audit/rules.d/docs.rules -w /srv/docs -p rwxa -k docs_access -a always,exit -F arch=b64 -S openat -F dir=/srv/docs -F success=split -w /etc/shadow -p wa -k identity_changes -e 2
Ключ docs_access позволяет быстро выбрать нужные записи: ausearch -k docs_access -ts recent, aureport -k -i, aureport -f -i для сводки по файлам. Директива -e 2 делает правила неизменяемыми до перезагрузки, что мешает атакующему подчистить конфигурацию. Параметр dir=/srv/docs в правиле openat точечный: аудит всего корня создаёт заметную нагрузку и поток событий в гигабайтах за сутки.
Журналы не должны лежать на том же сервере без защиты. Практика: немедленная отправка на удалённый коллектор, локально только короткий буфер, права на /var/log/audit и системный журнал за пределами полномочий прикладных администраторов. Срок хранения для инцидентов и разбора - не меньше 6 месяцев, для операций с персональными данными требования ФЗ-152 вынуждают держать 3 года.
Разбор прав доступа тесно связан с аудитом: избыточные разрешения видны только при сверке фактических ACL с ролевой моделью. Подробные сценарии разграничения прав на файловых серверах, включая POSIX permissions и NFSv4, собраны в руководстве аудит доступа и разграничение прав в системах хранения.
Интеграция с SIEM и анализ событий
Централизованный сбор строится из агентов, транспорта и хранилища: Winlogbeat и auditbeat с серверов, Filebeat с Linux-журналов, Logstash или прямой вывод в Elasticsearch, Kibana для поиска и алертов. Минимальная конфигурация Filebeat для логов auditd:
filebeat.inputs:
- type: filestream
paths:
- /var/log/audit/audit.log
fields:
log_source: auditd
output.logstash:
hosts: ["logstash.internal:5044"]
Правила в Kibana или Elastic Security настраивают на конкретные сценарии: больше 100 скачанных документов одним пользователем за час, доступ в нерабочее время, серия неудачных попыток входа, скачивание из архивного раздела с документами трёхлетней давности. Пример запроса KQL для разбора активности конкретного пользователя: event.action: "file_access" and user.name: "ivanov" and file.extension: "pdf" and @timestamp >= now-1h.
Журналы баз данных, в которых хранятся реквизиты документов и персональные данные, разбирают отдельно: подключения, неудачные аутентификации, массовые выборки, обращения к таблицам с ПДн. Порядок проверки логов PostgreSQL, MySQL и MongoDB с примерами запросов приведён в материале аудит безопасности баз данных в 2026 году.
Отдельная задача - защита самих журналов. Практикуют хеширование записей, WORM-хранилище для архива событий и отдельный аккаунт с правом только на запись. Настройка ретенции по индексам обязательна: без неё диск под журналы заполняется за недели, а поиск по инциденту замедляется до неприемлемого.
Предотвращение утечек: DLP-системы и контроль прав доступа
DLP без классификации документов даёт ложные срабатывания и превращается в формальность. Первый шаг - разложить документы по уровням: публичные, внутренние, конфиденциальные, персональные данные и коммерческая тайна. Дальше на этой классификации строят права доступа и правила перехвата.
Метки конфиденциальности (Microsoft Information Protection, метки Purview) решают задачу автоматически: документ получает метку при создании, метка едет с файлом при копировании и определяет, можно ли отправить его внешнему адресату. Автоматическое применение меток по содержимому настраивают правилами: наличие ИНН, номера договора или фразы «коммерческая тайна» повышает уровень.
Выбор и настройка DLP-системы
Критерии выбора: поддержка операционных систем и мобильных устройств, интеграция с СЭД и облачными сервисами, наличие endpoint-агента, работа с метками, качество отчётов, стоимость владения. Microsoft Purview закрывает Exchange, SharePoint, Teams и конечные устройства, если организация уже использует Microsoft 365. SearchInform и Solar Dozor дают сильный перехват трафика и контроль съёмных носителей. Symantec DLP уместен в крупных распределённых контурах.
Пример политики в Purview: блокировать отправку вложений с меткой «Конфиденциально» на адреса вне организации, уведомлять пользователя с возможностью запросить исключение, отправлять алерт в службу ИБ. Для endpoint-правила формулировка проще: запретить копирование файлов .docx, содержащих «коммерческая тайна», на USB-накопители.
Порядок развёртывания: инвентаризация данных, определение политик, включение в режиме мониторинга на 2-4 недели, разбор ложных срабатываний, тонкая настройка порогов, и только затем блокировка. Уведомление сотрудников о мониторинге и обучение обязательны: без них инциденты воспринимаются как слежка, а не как защита данных.
Разметку больших массивов текста, где регулярные выражения не справляются, можно автоматизировать через LLM API: единый доступ к GPT, Gemini и Claude без VPN и с оплатой в рублях предоставляет AiTunnel. Модель относит документ к уровню конфиденциальности, человек проверяет выборку и подтверждает метку.
Контроль прав доступа к документам
RBAC назначает права ролям: читатель, редактор, владелец, аудитор. Роли собираются в группы безопасности Active Directory, а права на файловые ресурсы выдаются группам, а не пользователям. Наследование включают на уровне отдела, а точечные исключения оформляют отдельными группами с понятным названием. ABAC дополняет модель атрибутами: отдел, уровень допуска, проект, территориальное расположение. Пример правила: доступ к папке «Финансы» получает сотрудник, у которого отдел = «Финансы» и уровень допуска не ниже 3.
Выдача прав через icacls выглядит так:
icacls "D:\Docs\Finance" /grant "DOM\doc_finance_rw:(OI)(CI)(M)" /grant "DOM\doc_finance_ro:(OI)(CI)(RX)" /remove:g "DOM\Domain Users" /inheritance:r Get-Acl -Path "D:\Docs" | Select-Object -ExpandProperty Access | Select-Object IdentityReference, FileSystemRights, IsInherited | Export-Csv rights.csv -NoTypeInformation
Выгрузка ACL в CSV раз в квартал показывает избыточные разрешения: прямые права на пользователей, устаревшие группы, полный доступ у подразделений, которых проект уже не касается. Тот же принцип применяется к SMB-ресурсам, где права share и NTFS складываются, и итоговое разрешение оказывается шире задуманного. Практические сценарии прав и аудита на Windows-файловом сервере разобраны в руководстве настройка и управление SMB-ресурсами в Windows Server 2026.
Учётную запись администратора не используют для повседневной работы: почта и браузер под доменным администратором превращают любую ошибку в компрометацию всего домена. Рабочий вариант - отдельная станция администратора, вход по MFA, временные привилегии на время работ, отзыв прав в тот же день по завершении задачи и при увольнении сотрудника.
Соответствие GDPR и ФЗ-152 в 2026 году: практические шаги
Оба закона требуют доказуемости мер защиты: недостаточно включить шифрование, нужно показать политики, журналы, ответственного и порядок реакции на инцидент. Проверка начинается с документов, а не с технических настроек.
Ключевые требования GDPR и ФЗ-152 в 2026 году
GDPR действует за пределами ЕС, если обрабатываются данные резидентов Евросоюза, и опирается на принципы законности, справедливости и прозрачности. Субъект получает право на доступ, исправление, удаление и переносимость данных. Уведомление регулятора об утечке направляют в течение 72 часов. Максимальный штраф - 20 млн евро или 4 процента глобального оборота за предыдущий год, в зависимости от того, что больше.
ФЗ-152 в редакции 2026 года ужесточает ответственность за утечки: уведомление Роскомнадзора об инциденте направляют в течение 24 часов, штрафы за повторные нарушения достигают 500 млн рублей, для оборотных взысканий учитывают масштаб утечки. Требования к локализации баз данных на территории России сохраняются, шифрование персональных данных при хранении и передаче закреплено как обязательная мера, согласие на обработку оформляют отдельно от других документов.
| Требование | GDPR | ФЗ-152 |
|---|---|---|
| Срок уведомления об утечке | 72 часа | 24 часа |
| Максимальный штраф | 20 млн евро или 4 процента глобального оборота | До 500 млн рублей при повторных нарушениях |
| Локализация данных | Не требуется, но нужны законные механизмы передачи | Базы с ПДн граждан РФ размещают на территории России |
| Шифрование ПДн | Ожидаемая мера по оценке рисков | Обязательная мера защиты |
| Ответственный | DPO при масштабной обработке | Ответственный за обработку ПДн |
Практические шаги для приведения системы в соответствие
Работы раскладываются на этапы с ответственными. Аудит текущих мер занимает до двух недель: инвентаризация систем с документами и ПДн, проверка шифрования, журналов, прав, договоров с подрядчиками. Затем приказ о назначении ответственного за обработку ПДн, реестр процессов обработки и политики, включая сроки хранения и порядок уничтожения. Технический блок - шифрование, DLP, аудит доступа - занимает от четырёх до восьми недель и идёт параллельно с подготовкой документов. Обучение сотрудников и уведомления о мониторинге укладываются в две недели.
Документы для проверки: политика конфиденциальности, реестр обработки, согласия, приказ об ответственном, модель угроз, договоры поручения на обработку с подрядчиками, журналы за запрошенный период, отчёты о тестировании восстановления. Шаблон уведомления об утечке содержит дату и время инцидента, категории данных, число субъектов, принятые меры и контакт ответственного.
Тестирование восстановления после инцидента входит в обязательный набор: если резервные копии не восстанавливались ни разу, при проверке предъявить нечего. Восстановление одного документа, каталога и целого датасета фиксируют протоколом с указанием фактического времени и объёма потерянных данных.
Построение защищённой инфраструктуры хранения документов: чек-лист
Сборка хранилища с нуля начинается с выбора платформы и сетевой сегментации. Документы с ПДн и коммерческой тайной размещают в отдельном VLAN, доступ к файловому серверу ограничивают портами 445 и 2049 только для нужных подсетей, административный интерфейс доступен через промежуточный хост с MFA и не публикуется наружу.
Выбор и настройка NAS с шифрованием (TrueNAS, ZFS)
TrueNAS с ZFS закрывает три задачи сразу: шифрование датасета, снапшоты для откатов и контроль целостности через контрольные суммы. Массив собирают в RAIDZ2, чтобы переживать отказ двух дисков, а каталог с документами выносят в отдельный зашифрованный датасет:
zpool create -o ashift=12 tank raidz2 /dev/sd{b,c,d,e,f,g}
zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt tank/docs
zfs set compression=lz4 tank/docs
zfs set snapdir=hidden tank/docs
zfs snapshot tank/docs@daily-$(date +%Y%m%d)
zfs get encryption,keystatus,compressratio tank/docs
Доступ по SMB или NFS настраивают с Kerberos для проверки подлинности пользователей, снапшоты держат с политикой хранения на 30 дней, scrub запускают раз в месяц. Ограничение ZFS encryption одно: ключ нужен для чтения датасета после каждой загрузки, и потеря ключа означает потерю данных. Для сервисов в Kubernetes секреты шифруют на уровне etcd, а не только на уровне томов:
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources: ["secrets", "configmaps"]
providers:
- aescbc:
keys:
- name: key1
secret: base64-ключ-32-байта
- identity: {}
Пароли и ключи в контейнерах передают через Secrets, а не через переменные окружения, тома монтируют только для чтения. Если хранилище или кластер размещают в облаке, инфраструктурную часть удобно закрыть на готовой платформе: Timeweb Cloud даёт серверы, базы данных, объектное хранилище и Kubernetes с гибким изменением ресурсов, что упрощает разнесение продакшена и резервного контура.
Управление ключами и резервное копирование
Правила работы с ключами: две копии в разных местах, доступ по схеме разделения знаний (например, 3 доли из 5 у разных сотрудников), отдельная учётная запись для операций с ключами, журнал каждого извлечения ключа. Заголовок LUKS копируют командой cryptsetup luksHeaderBackup, ключи ZFS экспортируют вместе с raw-потоком zfs send -w, ключ из файла хранят с правами 400 и владельцем root. Для централизованного хранения применяют HashiCorp Vault с аудитом обращений или облачный KMS.
Резервное копирование строится по схеме 3-2-1: три копии, два разных носителя, одна копия вне площадки. Зашифрованные данные копируют в зашифрованном виде, иначе шифрование диска теряет смысл. Инструменты: borgbackup с repokey, restic, rsync в зашифрованный контейнер, снапшоты ZFS с репликацией на второй NAS. Восстановление проверяют раз в квартал: сначала отдельный файл, затем каталог, затем полный датасет с замером времени. Отдельно проверяют восстановление из копии, снятой до смены ключа: старые копии требуют старого ключа, и это планируют заранее.
Готовый чек-лист безопасности программного хранилища, включая роли, MFA, сегментацию администрирования и защиту от случайного удаления, приведён в руководстве безопасная эксплуатация программного хранилища.
Типичные ошибки и как их избежать
Ключ шифрования в той же папке, что и данные, обнуляет защиту: получивший доступ к серверу читает и диск, и ключ. Ключи выносят на отдельный носитель или в Vault, а на сервере оставляют только минимально необходимый слот.
Устаревшие протоколы живут в инфраструктуре годами: TLS 1.0 и 1.1, SMBv1, FTP с паролем в открытом виде. Их отключают проверкой конфигураций, а SMB дополняют signing и encryption, поскольку подписывание защищает от подмены, а шифрование - от перехвата содержимого.
Журналы собираются, но никто их не читает. Минимальный набор для дежурной смены: пять правил в SIEM на массовое скачивание, доступ в нерабочее время, серию неудачных входов, изменение прав на критичные каталоги, отключение аудита.
Избыточные права накапливаются после каждого проекта. Группа Domain Users с полным доступом, прямые права на уволенных сотрудников, наследование от корня диска: всё это выявляется сверкой ACL раз в квартал и отзывом прав при увольнении в день ухода.
Резервные копии ключей отсутствуют или не проверены. Кейс из практики: администратор ушёл из компании, пароль от LUKS существовал только в его голове, резервный заголовок не снимался, и зашифрованный массив пришлось восстанавливать из полугодовой копии, потеряв месяцы документов.
DLP включают сразу в режиме блокировки. Итог предсказуем: ложные срабатывания на договорах и счетах, остановленная работа отдела продаж, отключение политик через неделю. Две-четыре недели мониторинга перед блокировкой экономят больше времени, чем стоят.
Локализация данных и договоры с обработчиками остаются на потом. Размещение базы с ПДн за пределами России и отсутствие поручений на обработку с подрядчиками дают штрафы независимо от качества шифрования.
Обновления безопасности откладываются из страха сломать рабочую среду. Практика: тестовый контур для патчей, окно обновления раз в месяц, проверка после установки на конкретные CVE в компонентах хранилища и веб-сервисов.
Проверка и тестирование защиты перед аудитом
Самопроверка строится на трёх уровнях: конфигурации, уязвимости, поведение. Конфигурации сверяют с CIS Benchmarks для Linux и Windows, уязвимости ищут сканерами OpenVAS, Nessus или Lynis, поведение проверяют имитацией атаки на хранилище документов.
Быстрые команды проверки на месте: lsblk -f и cryptsetup status cryptdocs показывают состояние шифрования дисков, Get-BitLockerVolume выводит метод шифрования и статус защиты, zfs get encryption,keystatus показывает состояние датасетов, openssl s_client -connect с флагом -tls1_3 подтверждает протокол канала. Проверка политик шифрования по всем серверам занимает часы, если собрать инвентарь заранее, и недели, если делать это впервые в день проверки.
Пентест хранилища включает попытку чтения зашифрованного диска после физического доступа, escalation privileges на файловом сервере, обход прав через SMB или NFS, проверку веб-интерфейса СЭД на доступ к чужим документам. Отчёт оформляют с оценкой критичности и сроком устранения по каждому пункту.
Тест восстановления готовит доказательства для регулятора: протокол с датой, объёмом данных и временем восстановления, а также список обнаруженных проблем. Проверки повторяют не реже раза в год и после крупных изменений в инфраструктуре. Порядок внутреннего аудита с приоритизацией рисков и готовыми формами отчёта описан в материале практические задачи аудита безопасности.
Начните с инвентаризации: выгрузите список блочных устройств и их типов, сверьте с реестром серверов и отметьте всё, что осталось без шифрования. Этот список становится планом работ на ближайший месяц, а после его закрытия проверка перестаёт быть авралом.