A.13.2: Безопасность передачи информации

Подробное описание

Контроль A.13.2 требует защиты информации при передаче по всем типам коммуникационных каналов — как внутри периметра организации, так и при обмене с внешними сторонами. Это включает шифрование данных в транзите, использование защищённых протоколов (TLS 1.2+, SSH, SFTP), контроль целостности и аутентичности передаваемых данных. Особое внимание уделяется защите от перехвата, подмены и несанкционированного доступа при использовании публичных сетей, облачных сервисов и каналов электронной почты. Контроль распространяется на передачу конфиденциальных данных между сотрудниками, партнёрами, заказчиками и облачными провайдерами.

Практические шаги внедрения

1. 1

   Классифицировать все каналы передачи информации (email, file sharing, API, VPN, мобильные приложения) и определить требуемый уровень защиты для каждой категории данных

2. 2

   Внедрить обязательное шифрование TLS 1.2+ для всех веб-сервисов, API и email (STARTTLS, S/MIME), запретить использование устаревших протоколов (SSLv3, TLS 1.0/1.1, FTP, Telnet)

3. 3

   Развернуть VPN или защищённые туннели (IPsec, WireGuard) для удалённого доступа сотрудников и межсайтового взаимодействия, запретить прямой доступ к критичным системам из недоверенных сетей

4. 4

   Настроить контроль целостности передаваемых файлов через контрольные суммы (SHA-256), цифровые подписи или HMAC, особенно для критичных конфигураций и обновлений ПО

5. 5

   Внедрить DLP-систему (Data Loss Prevention) для мониторинга утечек конфиденциальных данных через email, облачные хранилища и съёмные носители

6. 6

   Разработать политику использования корпоративной почты и мессенджеров: запрет пересылки персональных данных клиентов через публичные email, обязательное использование защищённых корпоративных каналов

7. 7

   Проводить ежеквартальный аудит конфигураций TLS/SSL (сканирование testssl.sh, Qualys SSL Labs), проверять отключение слабых шифров (RC4, DES) и наличие HSTS для критичных сервисов

Типичные нарушения

• Передача логинов, паролей и API-ключей через незашифрованные email или публичные мессенджеры (Telegram, WhatsApp личные аккаунты) без использования password managers или secret vaults

• Использование устаревших протоколов: FTP вместо SFTP/FTPS, HTTP API без TLS, Telnet для управления сетевым оборудованием, SMTP без STARTTLS

• Отсутствие шифрования на уровне приложения при передаче ПДн через облачные сервисы (Google Drive, Dropbox личные аккаунты), отсутствие корпоративных DLP-политик

• Слабые настройки TLS: поддержка TLS 1.0/1.1, разрешены cipher suites с NULL/EXPORT/RC4, отсутствует проверка сертификатов (certificate validation disabled в коде)

• Пересылка конфиденциальных документов через личные email сотрудников (@gmail.com, @mail.ru) без шифрования вложений, отсутствие логирования передачи данных вовне

Почему это важно

Проверяемые категории

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