Передача данных за пределы периметра: каналы, носители, шифрование и проверка настроек

Самые громкие утечки происходят не при взломе сервера, а при обычной передаче: файл с клиентами отправили подрядчику по почте без защиты, флешка с отчётом осталась в такси, ссылку на облачную папку выдали «всем, у кого есть ссылка». Передача данных за пределы компании всегда риск, и им нужно управлять заранее: определить, какими каналами что можно передавать, как их защищать и как проверять. Ниже документ с требованиями, матрица каналов по классам данных, практическая настройка защищённых способов (SFTP, зашифрованные носители и архивы), проверка того, что на ваших сервисах нет устаревших версий TLS, и журнал передач.

Основание передачи ПДн другому лицу: поручение обработки, передача между операторами, трансграничная передача. Обязательство о неразглашении: NDA. Контроль утечек по каналам: DLP.

Принцип выбора канала

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

Матрица каналов по классам данных

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

Требования в документе

Документ короткий и состоит из шести пунктов, каждый можно проверить:

1. Передача данных высокого класса за пределы компании допускается только по каналам из матрицы.
2. Каналы связи используют TLS не ниже версии 1.2, SSH с ключами или IPsec; устаревшие протоколы отключены.
3. Носители с данными высокого класса шифруются (AES-256 или эквивалент), пароль или ключ передаётся отдельно от носителя.
4. Перед передачей определены получатель, основание (договор, поручение, NDA) и срок хранения у получателя.
5. Каждая передача данных высокого класса записывается: что, кому, когда, кем передано.
6. Настройки каналов проверяются не реже раза в квартал.

Подписывают обязательство о неразглашении все, кто работает с данными: работники при приёме, подрядчики при подписании договора. Порядок сбора обязательств и хранение подписанных экземпляров описаны в статье про NDA.

Канал 1: SFTP с изоляцией каталога

Для регулярной передачи файлов внешним получателям удобнее всего SFTP на отдельной учётной записи, запертой в своём каталоге. Получатель видит только свою папку и не может выйти за её пределы. Настройка на сервере OpenSSH:

sudo groupadd sftponly
sudo useradd -m -s /usr/sbin/nologin -G sftponly partner1
sudo mkdir -p /srv/sftp/partner1/upload
sudo chown root:root /srv/sftp/partner1
sudo chown partner1:partner1 /srv/sftp/partner1/upload

# /etc/ssh/sshd_config.d/30-sftp.conf
Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PasswordAuthentication no

sudo sshd -t && sudo systemctl reload ssh
sftp -i ~/.ssh/partner1_key partner1@sftp.example.com

Ожидаемо: получатель подключается по ключу, видит только каталог upload, оболочка недоступна. Каталог входа (/srv/sftp/partner1) должен принадлежать root и не быть доступным на запись остальным, иначе ChrootDirectory откажется работать. Ключ выдаётся и отзывается так же, как любой внешний доступ: регламент удалённого доступа. Срок жизни файлов на обмене ограничьте: удаляйте их через 24–72 часа задачей по расписанию, чтобы промежуточное хранилище не стало ещё одной копией данных.

Канал 2: зашифрованные носители и архивы

Если данные уходят физически (флешка, диск), носитель шифруется до записи. Для Linux это LUKS с алгоритмом AES в режиме XTS и ключом 512 бит (в режиме XTS ключ вдвое длиннее, что соответствует AES-256):

sudo cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha256 /dev/sdX1
sudo cryptsetup luksOpen /dev/sdX1 transfer
sudo mkfs.ext4 /dev/mapper/transfer
sudo cryptsetup luksDump /dev/sdX1 | grep -E "Cipher|key size|Hash"

Ожидаемо: в выводе luksDump видны aes-xts-plain64 и размер ключа 512. Для Windows проверка шифрования носителя через BitLocker:

manage-bde -status E:

Ожидаемо: в строке «Метод шифрования» значение «XTS-AES 256» (или «AES 256»), статус «Защита включена». Для передачи отдельных файлов подойдёт зашифрованный архив или GPG:

7z a -p -mhe=on -t7z report.7z report.xlsx          # пароль запросит интерактивно, имена файлов тоже шифруются
gpg --symmetric --cipher-algo AES256 report.xlsx    # получится report.xlsx.gpg

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

Канал 3: почта

Почта передаёт файлы удобно и небезопасно: письмо хранится на нескольких серверах, пересылается дальше, остаётся в ящиках. Шифрование между серверами (TLS) защищает только участки пути и применяется по возможности, а не гарантированно. Поэтому для данных высокого класса вложение шифруется отдельно (архив с паролем или GPG), пароль идёт другим каналом. Для регулярных передач лучше SFTP или защищённая ссылка со сроком жизни. Настройка TLS и фильтрации почты: почтовый шлюз.

Проверка: нет ли устаревших версий TLS на ваших сервисах

Требование «TLS не ниже 1.2» нужно не только записать, но и регулярно проверять на всех сервисах, которые принимают данные снаружи: сайт, почтовый шлюз, API, SFTP-шлюз. Скрипт обходит список адресов и портов и сообщает, где ещё включены TLS 1.0 или 1.1:

#!/usr/bin/env bash
# tls_audit.sh: проверка отсутствия TLS 1.0 и 1.1 на своих сервисах
# Использование: tls_audit.sh hosts.txt   (строки вида: mx.example.com 25  или  www.example.com 443)
# Сканируйте только свои адреса.
fail=0
while read -r host port; do
  [ -z "$host" ] && continue
  out=$(nmap -Pn -p "$port" --script ssl-enum-ciphers "$host" 2>/dev/null)
  if echo "$out" | grep -qE "TLSv1\.[01]:"; then
    echo "ПРОВАЛ: $host:$port поддерживает TLS 1.0 или 1.1"; fail=1
  elif echo "$out" | grep -qE "TLSv1\.[23]:"; then
    echo "OK: $host:$port только TLS 1.2 и выше"
  else
    echo "НЕ ОПРЕДЕЛЕНО: $host:$port (нет ответа TLS)"
  fi
done < "$1"
exit $fail

Ожидаемо: строка «OK» для каждого сервиса с современными настройками и «ПРОВАЛ» для остальных; код выхода 1 при провалах. Для почтовых портов (25) в списке нужна опция STARTTLS, которую nmap обрабатывает автоматически. Результат ежеквартально сохраняйте в архив: он подтверждает, что проверка действительно выполняется. Исправление настроек: TLS в nginx, проверка TLS. Шифрование на VPN: WireGuard (вопрос об алгоритмах разобран там же).

Журнал передач

Запись о каждой передаче данных высокого класса короткая:

date,dataset,recipient,channel,protection,basis,sent_by,expires
2026-10-21,Выгрузка клиентов Q3,ООО Пример,SFTP,ключ получателя; файл удалён через 48 ч,поручение № 14,Иванов И.И.,2026-10-23

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

Какие артефакты хранить

Диагностика

Где это в модели зрелости

Материал относится к направлению «Безопасность данных» (хаб: безопасность данных, карта: карта зрелости). На первом уровне определены и документированы требования к защите данных при передаче за пределы периметра, в том числе порядок сбора обязательства о неразглашении, каналы и носители защищены шифрованием (не ниже TLS 1.2 для каналов и AES-256 для носителей), а настройки регулярно проверяются. Матрица, настройки и результаты проверки — подтверждения.

Как проверить

1. Документ с требованиями утверждён и содержит матрицу каналов.
2. Для случайных пяти сотрудников есть подписанные обязательства.
3. Скрипт проверки TLS на всех внешних сервисах не выдаёт «ПРОВАЛ», результат за последний квартал сохранён.
4. Тестовый носитель зашифрован: luksDump или manage-bde показывают алгоритм AES-256.
5. Для последних трёх передач данных высокого класса есть записи журнала с получателем и основанием.

Источники

• NIST SP 800-52 Rev. 2, рекомендации по использованию TLS: csrc.nist.gov. Не закон РФ.
• OpenSSH, sshd_config, раздел ChrootDirectory: man.openbsd.org.
• CIS Control 3, защита данных: cisecurity.org/controls.
• cryptsetup, документация LUKS: gitlab.com/cryptsetup.