Безопасность систем хранения и обработки данных: практическое руководство по защите информации и управлению доступом

Безопасность систем хранения и обработки данных (СХОД) держится на четырех слоях: шифрование данных в покое и при передаче, доступ по принципу наименьших привилегий, непрерывный аудит действий и защита от программ-вымогателей через снапшоты и сетевую изоляцию. Выпадает один слой, и остальные перестают работать: массив с шифрованием AES-256 и правами 777 открыт любому процессу на хосте, а выверенные роли RBAC не спасут, если резервные копии лежат на том же сетевом ресурсе, который шифрует вирус.

Дальше - конкретные шаги: включение ZFS encryption в TrueNAS, шифрование секретов и базы etcd в Kubernetes, TLS 1.2 и 1.3 в Nginx, ACL и RBAC, auditd и аудит API-сервера, изоляция NAS в отдельном VLAN и пакет документов для проверок по 152-ФЗ и GDPR. Примеры рассчитаны на TrueNAS SCALE 24.04 и новее, Kubernetes 1.29+ и Nginx 1.25+, на более старых сборках отличается синтаксис одной-двух директив, о расхождениях сказано в тексте.

Безопасность СХОД: конфиденциальность, целостность и доступность данных

СХОД - это набор носителей, файловых систем, сетевых протоколов и сервисов, которые хранят данные и отдают их приложениям. В периметр попадают NAS и SAN, объектные хранилища, постоянные тома Kubernetes, базы данных и брокеры сообщений. Защиту таких систем описывают моделью CIA: конфиденциальность (confidentiality), целостность (integrity), доступность (availability). Шифрование отвечает за первое свойство, снапшоты и контроль версий - за второе, репликация и проверенное восстановление - за третье.

Угрозы для хранилищ делятся на четыре группы, и каждая требует своего набора мер.

Внешний доступ. Сканирование портов SMB (445), NFS (2049), API Kubernetes (6443), подбор паролей, эксплуатация незакрытых CVE в прошивках NAS.
Программы-вымогатели. Шифруют каждый сетевой ресурс, куда у процесса есть право записи, включая смонтированные шары и диски, подключенные по iSCSI.
Инсайдеры и ошибки. Избыточные права, копирование данных на личные носители, удаление каталога одной командой, случайный сброс ACL.
Утечки при передаче. Трафик без TLS внутри периметра, открытые бакеты объектного хранилища, резервные копии с правом чтения для всех.

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

Сводная таблица слоев защиты и мест, где состояние проверяется одной командой.

Задача	Технология	Как проверить
Шифрование в покое	ZFS encryption, LUKS, EncryptionConfiguration для etcd	zfs get keystatus, lsblk -f, etcdctl get
Шифрование при передаче	TLS 1.2 и 1.3, mTLS между сервисами	openssl s_client, curl -I
Разграничение доступа	POSIX ACL, NFSv4 ACL, RBAC	getfacl, kubectl auth can-i
Аудит	auditd, audit policy Kubernetes, логи Nginx	ausearch -k, журнал аудита, SIEM
Защита от шифровальщиков	Снапшоты ZFS, zfs hold, репликация, VLAN	zfs list -t snapshot, zfs holds, правила файрвола

Шифрование данных в состоянии покоя и при передаче

Данные шифруют в двух состояниях: at rest (на дисках, в снапшотах, в резервных копиях) и in transit (в сети между клиентом и сервером, между сервисами внутри кластера). Для первого используют симметричные алгоритмы AES-256-GCM и ChaCha20-Poly1305: они быстрые и работают на уровне блока, датасета или базы. Второе строится на TLS: рукопожатие проверяет сертификат асимметричной криптографией (RSA, ECDSA), а трафик шифруется симметричным ключом сессии.

Ключи - самое слабое место любой схемы. Три правила, которые экономят нервы: ключ лежит отдельно от данных, ротация проходит раз в 12 месяцев или при увольнении сотрудника с доступом к шифрованию, резервная копия ключа хранится офлайн или в KMS и HSM. Потерян ключ ZFS или LUKS, и данные не восстановит никто, включая вендора.

Шифрование в TrueNAS: настройка ZFS encryption

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

zpool get feature@encryption tank
zfs create -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=prompt tank/secure
dd if=/dev/urandom of=/root/zfs-secure.key bs=32 count=1
chmod 600 /root/zfs-secure.key
zfs create -o encryption=aes-256-gcm -o keyformat=raw -o keylocation=file:///root/zfs-secure.key tank/locked
zfs get encryption,keystatus,keyformat,keylocation tank/secure
zfs load-key tank/secure
zfs mount tank/secure

Проверьте доступность функции на пуле: команда zpool get feature@encryption tank возвращает active или enabled.
Включите шифрование при создании датасета командами zfs create с параметрами encryption, keyformat и keylocation. К существующему датасету шифрование не добавить, данные придется переносить в новый зашифрованный датасет.
Для файла-ключа сгенерируйте 32 случайных байта, сохраните на носитель, который не лежит рядом с пулом, и закройте правами 600.
Разблокируйте и смонтируйте датасет: zfs load-key tank/secure и zfs mount tank/secure.
Проверьте статус командой zfs get encryption,keystatus,keyformat tank/secure. Значение keystatus=available означает, что ключ загружен и данные доступны, unavailable - ключ не загружен, датасет виден, но не смонтирован.

Автозагрузку настраивают задачей, которая выполняется после старта системы: сначала zfs load-key -a, затем zfs mount -a. В TrueNAS SCALE такие команды добавляют в поле Post Init раздела System Settings, либо используют хранилище ключей и разблокировку через API. Ключ не храните на том же пуле: путь file:///mnt/tank/keys/... обесценивает схему, если злоумышленник получил доступ к пулу целиком.

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

Шифрование секретов в Kubernetes и etcd

Объекты Secret в Kubernetes по умолчанию хранятся в etcd в base64. Это кодирование, а не шифрование: тот, кто получил доступ к базе или к ее дампу, прочитает пароли и токены. Ситуацию закрывает EncryptionConfiguration на стороне kube-apiserver.

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: REPLACE_WITH_BASE64_KEY
      - identity: {}

Создайте файл конфигурации шифрования, положите его на управляющие узлы с правами 600 и владельцем root.
Добавьте к kube-apiserver флаг --encryption-provider-config=/etc/kubernetes/enc/enc.yaml. В кластере kubeadm правка идет через /etc/kubernetes/manifests/kube-apiserver.yaml, kubelet сам перезапустит статический под.
Перешифруйте существующие секреты, иначе они останутся в открытом виде: kubectl get secrets -A -o json | kubectl replace -f -
Проверьте результат напрямую в etcd: значение секрета начинается с префикса k8s:enc:aescbc:v1:key1.

ETCDCTL_API=3 etcdctl get /registry/secrets/dev/db-pass --print-value-only | head -c 80

Ротация ключей идет в три шага: новый ключ добавляется в список первым, все секреты перезаписываются тем же replace, старый ключ удаляется. Перед любой работой с etcd делайте снимок через etcdctl snapshot save и проверяйте его восстановлением на отдельном стенде. Флаг --encryption-provider-config не покрывает данные внутри persistent volumes: диски томов шифруются средствами хранилища или CSI-драйвера.

Обслуживать etcd самостоятельно не обязательно. Managed-кластеры берут шифрование дисков, снапшоты и резервные копии на себя: Timeweb Cloud предлагает Kubernetes, VDS, базы данных и объектное хранилище, где часть задач по защите данных закрыта на стороне провайдера, а вам остаются RBAC, сетевые политики и работа с секретами приложений.

Настройка TLS в Nginx: сертификаты и шифры

Внешний контур начинается с HTTPS. Порядок для отдельного сервера или reverse proxy: получить сертификат, прописать его в server-блоке, отключить устаревшие протоколы и включить автоматическое продление.

Установите certbot и получите сертификат Let's Encrypt командой certbot --nginx -d files.example.com. Для закрытых контуров выпустите самоподписанный сертификат с SAN и добавьте корневой CA в доверенные на клиентах.
Пропишите пути ssl_certificate и ssl_certificate_key. Используйте fullchain.pem, а не cert.pem: без промежуточного сертификата часть клиентов (старые версии Java и Android) оборвет соединение.
Оставьте TLS 1.2 и 1.3, уберите SSLv3, TLS 1.0 и TLS 1.1.
Включите HSTS, OCSP stapling и общий кэш сессий.
Проверьте конфигурацию через nginx -t и перезагрузите сервис без разрыва соединений: systemctl reload nginx.
Настройте продление: systemctl status certbot.timer или задача cron с certbot renew и хуком на reload. Раз в квартал прогоняйте certbot renew --dry-run.

server {
    listen 443 ssl;
    http2 on;
    server_name files.example.com;

    ssl_certificate     /etc/letsencrypt/live/files.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/files.example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_stapling on;
    ssl_stapling_verify on;

    add_header Strict-Transport-Security 'max-age=63072000; includeSubDomains' always;
}

На Nginx 1.25 и новее HTTP/2 включается директивой http2 on, на 1.24 и ниже - параметром http2 у директивы listen. Проверить, какой протокол реально работает, помогает команда openssl s_client -connect files.example.com:443 -tls1_3, а заголовки ответа видны через curl -I https://files.example.com: ответ содержит строку strict-transport-security.

Трафик между Nginx и бэкендом тоже шифруют, особенно если приложение и прокси стоят на разных хостах или в разных подсетях. Для API с малым числом потребителей включают взаимную аутентификацию по клиентским сертификатам (mTLS): proxy_ssl_verify on и доверенный CA на стороне прокси.

Управление доступом: разграничение прав в Linux, TrueNAS и Kubernetes

Принцип наименьших привилегий означает: у пользователя и процесса есть ровно те права, которые нужны для задачи, и ни одного лишнего. На практике к этому ведут три модели. DAC (дискреционное управление) - классические права владельца, группы и остальных. MAC (мандатное управление) - метки и политики SELinux или AppArmor. RBAC (ролевое управление) - права выдаются роли, роль привязывается к пользователю или сервисному аккаунту. В типовой инфраструктуре встречаются все три: POSIX-права на файлах, профиль AppArmor для Nginx, Role в Kubernetes.

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

Разграничение прав доступа в Linux: ACL и sudo

Традиционная схема из трех наборов (владелец, группа, остальные) подходит не всегда: нужно дать одному разработчику доступ к каталогу, не меняя права всей группы. Здесь работают ACL.

setfacl -m u:ivan:rw- /srv/data/report.csv
setfacl -R -m g:developers:rwx /srv/data/project
setfacl -d -m g:developers:rwx /srv/data/project
getfacl /srv/data/project
setfacl -x u:ivan /srv/data/report.csv

Параметр -m добавляет или меняет запись, -x удаляет, -R применяет рекурсивно, -d задает default ACL. Default ACL критичен: он наследуется новыми файлами внутри каталога, без него права придется выставлять вручную после каждой записи. Маска ACL (mask) ограничивает максимальные права для именованных пользователей и групп, проверяйте ее в выводе getfacl. Файловые системы ext4 и XFS поддерживают ACL из коробки, для NFSv4 ACL применяют nfs4_setfacl и nfs4_getfacl, синтаксис там другой.

Sudo ограничивают по полному пути команды и без shell-оберток. Файл /etc/sudoers.d/nginx-ops с правилом svcops ALL=(root) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl status nginx дает дежурному только перезапуск и проверку статуса сервиса. Проверяйте синтаксис через visudo -cf /etc/sudoers.d/nginx-ops и смотрите итоговые права через sudo -l -U svcops. Запись NOPASSWD: /bin/bash или маска со звездочкой в аргументах превращает правило в полный root: sudo позволяет подставить туда собственные параметры.

Настройка прав в TrueNAS: пользователи, группы, SMB/NFS ACL

В TrueNAS доступ строится на трех уровнях: учетные записи и группы, права датасета (ACL) и права шары. Ошибка новичка - настроить только шару и забыть про ACL датасета, после чего права выглядят правильными в веб-интерфейсе, но не работают при подключении по SMB.

Создайте группы (developers, interns) и пользователей в разделе Credentials, задайте им пароли или SSH-ключи и добавьте в нужные группы.
Создайте датасет и задайте acltype. Для SMB в TrueNAS SCALE оптимален nfsv4acl: он поддерживает богатые ACE и корректно наследует права из Windows. Смена acltype на датасете с данными без бэкапа приводит к потере прав.
В Edit ACL датасета добавьте записи: группе developers - Modify и Allow, группе interns - Read и Allow, у остальных права уберите. При необходимости включите Apply permissions recursively и наследование на дочерние датасеты.
Проверьте уровень шары: у SMB-шары есть отдельный Share ACL, а для NFS-экспорта в Advanced задаются подсеть и Maproot User. Правило Maproot User = nobody не дает root клиента стать root на NAS.
Для NFS ограничьте доступ подсетью, например 10.20.30.0/24, и выставьте Read Only для шары с документами.

Матрица для примера: developers получают чтение и запись в /mnt/tank/projects, interns - только чтение того же датасета, бухгалтерия видит свой датасет и не имеет доступа к проектам. Права проверяют не в интерфейсе, а с клиента: getfacl по смонтированному NFS и пробная запись файла из-под учетной записи каждого типа. Пошаговые настройки SMB, NFS и FTP с примерами для Windows, Linux, Proxmox и Docker собраны в отдельном руководстве по сетевому доступу к файлам в TrueNAS.

RBAC в Kubernetes: роли, биндинги и сервисные аккаунты

В Kubernetes права выдают объектами Role и ClusterRole, а привязывают через RoleBinding и ClusterRoleBinding. Role действует внутри одного namespace, ClusterRole - на весь кластер. ClusterRoleBinding с ролью cluster-admin выдает полный доступ к кластеру, включая чтение всех секретов.

kubectl create namespace dev
kubectl create serviceaccount ci-runner -n dev
kubectl create role pod-reader --verb=get,list,watch --resource=pods,deployments,services -n dev
kubectl create rolebinding ci-read --role=pod-reader --serviceaccount=dev:ci-runner -n dev
kubectl auth can-i list pods -n dev --as=system:serviceaccount:dev:ci-runner

Для CI и CD заведите отдельный сервисный аккаунт с минимальным набором прав: деплой обычно требует create, update и patch для deployments и configmaps в конкретном namespace, но не требует доступа к secrets. Команда kubectl auth can-i --list --as=system:serviceaccount:dev:ci-runner показывает все разрешения аккаунта и помогает поймать лишнее. Раз в квартал проверяйте, у кого есть широкие права: kubectl get clusterrolebindings -o json и поиск по имени cluster-admin занимают минуту, а находки обычно удивляют.

Встроенные роли view, edit и admin удобны на старте, но edit включает доступ к секретам namespace. Отдельного внимания требуют права escalate и bind на roles и clusterroles: они позволяют выдать себе любые полномочия в обход политики.

Аудит безопасности инфраструктуры и действий пользователей

Аудит отвечает на вопросы кто, когда, что и с каким результатом сделал. Собирают три потока: события ядра и файловой системы (auditd), действия с API Kubernetes (audit log), сетевые обращения к сервисам (логи Nginx и серверов SMB и NFS). Логи хранят 6-12 месяцев на отдельном хосте, доступ к ним есть только у администраторов безопасности, время на всех узлах синхронизировано через chrony или systemd-timesyncd: расхождение часов ломает корреляцию событий.

Проверку настроек аудита и шифрования в TrueNAS, включая права в NFS, SMB и iSCSI, удобно вести по готовому чек-листу из материала про аудит безопасности TrueNAS.

Настройка auditd в Linux для мониторинга доступа к данным

auditd пишет события ядра: обращения к файлам, изменения прав, запуск процессов. Установка стандартная: apt install auditd audispd-plugins на Debian и Ubuntu, dnf install audit на RHEL и совместимых системах. Правила складывают в /etc/audit/rules.d/ и подключают командой augenrules --load.

-w /data -p rwa -k data_access
-w /srv/nfs -p rwa -k nfs_access
-w /etc/passwd -p wa -k identity
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/ssh/sshd_config -p wa -k ssh_config

Ключ -p задает тип операций: r - чтение, w - запись, x - выполнение, a - изменение атрибутов. Ключ -k дает метку, по которой потом ищут события: ausearch -k data_access -ts today показывает все обращения к каталогу за сутки, aureport --auth --summary собирает сводку по аутентификации. Отслеживание чтения на активном каталоге порождает сотни тысяч записей в день, поэтому включайте его точечно, для каталогов с персональными данными и секретами.

Объем логов ограничивают в /etc/audit/auditd.conf параметрами max_log_file и num_logs, а сами логи отправляют на удаленный сервер через audisp-remote: локальный root не сможет бесследно их подчистить. Правило для отслеживания запуска всех команд через системный вызов execve добавляет заметную нагрузку на диск и подходит только серверам с жесткими требованиями к контролю.

Аудит в Kubernetes: логи API-сервера и события

Аудит Kubernetes строится на политике: набор правил определяет, какие запросы и с какой детализацией писать. Уровни: None (не писать), Metadata (кто, что, когда, без тела запроса), Request (с телом запроса, но без ответа), RequestResponse (полностью). Правила проверяются по порядку, первое совпадение выигрывает.

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - RequestReceived
rules:
  - level: None
    resources:
      - group: ''
        resources:
          - endpoints
          - services/status
  - level: Metadata
    resources:
      - group: ''
        resources:
          - secrets
  - level: RequestResponse
    verbs: [create, update, patch, delete]
    resources:
      - group: ''
        resources:
          - pods
          - persistentvolumeclaims
      - group: rbac.authorization.k8s.io
        resources:
          - roles
          - clusterroles
          - rolebindings
          - clusterrolebindings
  - level: Metadata

Политику подключают флагами kube-apiserver: --audit-policy-file, --audit-log-path, --audit-log-maxage=30, --audit-log-maxbackup=10, --audit-log-maxsize=100. Секреты логируют на уровне Metadata: уровень RequestResponse записал бы значения прямо в лог, и файл аудита превратился бы в источник утечки. Ротацию задают теми же флагами, на больших кластерах логи отправляют в коллектор сразу, минуя локальный диск.

Часть картины видна и без политики: kubectl get events -A --field-selector type=Warning показывает предупреждения кластера, а kubectl auth can-i --list помогает найти выданные по ошибке права. Полезные события для алертов: создание ClusterRoleBinding, чтение секретов сервисным аккаунтом приложения, exec в под, изменение admission-контроллеров.

Логи Nginx настраивают под машинный разбор: формат с $request_id, $status, $request_time, $upstream_addr, $ssl_protocol и $ssl_cipher позволяет связать запрос, ответ бэкенда и версию TLS. SIEM (Elastic, OpenSearch, Wazuh, Loki) собирает события Linux, Kubernetes и прокси в одно место. Автоматизировать первичный разбор помогает LLM: AiTunnel дает единый API к более чем 200 моделям, включая GPT, Gemini и Claude, с оплатой в рублях и без VPN, что удобно для самописных ботов, которые суммируют ночные выгрузки и подсвечивают аномалии.

Защита NAS от программ-вымогателей и сегментация сети

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

Снапшоты и неизменяемые бэкапы в TrueNAS

Периодические снапшоты ZFS - самый быстрый способ откатить изменения после атаки. Задача создается в разделе Data Protection и выглядит так: датасет /mnt/tank/data, расписание ежедневно в 02:00, срок хранения 30 дней, рекурсивно по дочерним датасетам. Снапшот занимает место только под измененные блоки, поэтому даже сотни версий на большом датасете стоят дешевле, чем полная копия.

Снапшот ZFS доступен только для чтения, но привилегированный пользователь может его удалить. Дополнительный барьер - удержание: zfs hold keep tank/data@daily-2026-09-16 запрещает удаление снапшота, пока метка не снята командой zfs release. Список удержаний смотрят через zfs holds -r tank/data. Копию уводят на второй сервер потоком zfs send -w с приемом на стороне хранилища: тогда удалить снапшот на основном NAS недостаточно, реплика останется.

Снапшоты не заменяют резервные копии. Пул выходит из строя, датасет удаляют вместе с историей, шифровальщик с правами root проходит и по снапшотам. Рабочая схема - 3-2-1: три копии, две на разных носителях, одна вне площадки или офлайн. Копия на отключенном диске или ленте закрывает атаки, которые добрались до сети.

Сегментация сети: VLAN и правила файрвола для NAS

NAS не должен стоять в одной подсети с рабочими станциями и гостевой сетью. Практичная схема: VLAN 20 - пользователи, VLAN 30 - администрирование, VLAN 40 - серверы и NAS, VLAN 50 - гости, VLAN 60 - управление сетевым оборудованием. Между подсетями трафик ходит только по явным правилам файрвола.

Список правил для NAS в VLAN 40:

SMB (TCP 445 и 139) разрешен только из VLAN 20 и с адресов, которым нужны сетевые диски;
NFS (TCP и UDP 2049) разрешен только из подсети серверов и кластера, например 10.20.30.0/24;
веб-интерфейс (TCP 443) и SSH (TCP 22) доступны только из VLAN 30 и через VPN;
iSCSI (TCP 3260) разрешен только инициаторам по IP;
все остальное, включая трафик из VLAN 50 и из интернета, запрещено правилом deny в конце списка.

iptables -A INPUT -i eth0 -p tcp --dport 445 -s 10.20.10.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 2049 -s 10.20.30.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 3260 -s 10.20.30.0/24 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 445 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 2049 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 3260 -j DROP

Публиковать SMB, NFS и iSCSI в интернет нельзя: для внешнего доступа используют VPN или SSH-туннель. Управляющий интерфейс NAS выводят на отдельный физический порт или VLAN, а подключения к нему разрешают только с адресов администраторов. В Kubernetes роль сетевой изоляции выполняют NetworkPolicy: политика default-deny закрывает весь трафик в namespace, дальше открывают только нужные направления.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: dev
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: dev
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api
      ports:
        - protocol: TCP
          port: 5432

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

Требования регуляторов описывают те же меры, что и здравый смысл, но требуют их документального подтверждения. Для 152-ФЗ ключевая статья 19: оператор обязан принимать правовые, организационные и технические меры, включая назначение ответственного за безопасность персональных данных, разграничение доступа, шифрование, учет носителей и регистрацию инцидентов. С 30 мая 2025 года действует правило: об инциденте с персональными данными оператор уведомляет Роскомнадзор в течение 24 часов после обнаружения, а результаты внутреннего расследования направляет в течение 72 часов.

В GDPR требования собраны в статье 32: шифрование, псевдонимизация, устойчивость систем и регулярная проверка мер защиты. Статья 33 обязывает сообщить надзорному органу об утечке в течение 72 часов, статья 34 - уведомить субъектов данных, если есть высокий риск для их прав. Штрафы достигают 20 миллионов евро или 4% мирового годового оборота.

Отраслевые стандарты добавляют детали. PCI DSS 4.0 требует защищать хранимые данные держателей карт (требование 3) и вести журналы доступа (требование 10). ISO/IEC 27001 в редакции 2022 года описывает меры в разделах A.5 (политики), A.8.24 (шифрование) и A.8.15 (логирование).

Как меры из этой статьи ложатся на требования:

шифрование ZFS, etcd и TLS закрывает конфиденциальность персональных данных при хранении и передаче;
ACL и RBAC обеспечивают разграничение доступа и принцип наименьших привилегий;
auditd, аудит Kubernetes и логи Nginx дают регистрацию событий безопасности;
снапшоты, репликация и офлайн-копия обеспечивают доступность и восстановление после инцидента.

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

Снижение рисков при настройке: типичные ошибки и чек-лист

Большинство проблем с безопасностью хранилищ возникает не от атак, а от поспешных изменений на рабочей системе. Ошибки повторяются из проекта в проект.

Ключ шифрования лежит на том же пуле или в том же бэкапе, что и данные: копия пула уходит вместе с ключом.
Датасет с продакшен-данными зашифровали без реплики, а ключ хранили на локальном диске, который заменили при обслуживании.
Правило auditd повесили на весь корень с отслеживанием чтения: диск переполнен, нагрузка выросла, полезных событий в логе нет.
Все сервисы и поды работают под root или cluster-admin, потому что так быстрее тестировать, и этот режим остается в продакшене на годы.
Снапшоты включены, но доступны тому же пользователю, что и данные, поэтому шифровальщик удаляет их перед шифрованием.
Схему прав или acltype на датасете сменили без бэкапа: права потеряны, восстановление заняло сутки.
Сертификаты продлевали вручную и забыли: HTTPS отвалился в момент пиковой нагрузки.
Восстановление из резервной копии не проверяли ни разу, поэтому в момент сбоя находится несовместимая версия или битый архив.

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

Чек-лист для самопроверки:

шифрование включено на всех датасетах с чувствительными данными, keystatus показывает available, копия ключа хранится офлайн или в KMS;
секреты в etcd зашифрованы, ротация ключа запланирована, снимок etcd снят и проверен восстановлением;
TLS 1.2 или 1.3, HSTS включен, продление сертификатов автоматическое и проверено через renew --dry-run;
ACL критичных каталогов не содержат прав для остальных, default ACL наследуется новыми файлами;
лишних cluster-admin нет, CI и CD работают через отдельный сервисный аккаунт, права проверены через kubectl auth can-i;
auditd и аудит Kubernetes включены, логи уходят на отдельный сервер, время на узлах синхронизировано;
снапшоты ежедневные, реплика на втором сервере, офлайн-копия обновляется по расписанию;
NAS изолирован в VLAN, SMB и NFS открыты только для доверенных подсетей, интерфейс управления доступен через VPN;
политики подписаны, ответственный назначен, шаблон уведомления об инциденте готов;
восстановление из бэкапа успешно проверено на стенде за последние три месяца.

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