4.2.1
Определенные Требования к Подходу:
Сильная криптография и безопасные протоколы реализованы следующим образом для защиты PAN при передаче по открытым, публичным сетям:
- Принимаются только доверенные ключи и сертификаты.
- Сертификаты, используемые для защиты PAN при передаче по открытым, публичным сетям, подтверждаются как действительные, не истекшие и не отозванные. Этот пункт является наилучшей практикой до его даты вступления в силу; подробнее см. в примечаниях по применению ниже.
- Используемый протокол поддерживает только безопасные версии или конфигурации и не поддерживает откат к небезопасным версиям, алгоритмам, размерам ключей или реализациям.
- Сила шифрования соответствует используемой методологии шифрования.
Цель Индивидуального подхода:
PAN в открытых, публичных сетях не может быть прочитан или перехвачен в процессе передачи.
Примечания по применению:
Самоподписанный сертификат также может быть приемлем, если сертификат выдан внутренним УЦ (центром сертификации) организации, автор сертификата подтвержден, и сертификат проверен — например, через хэш или подпись — и не истек. Пункт выше (о подтверждении, что сертификаты, используемые для защиты PAN при передаче по открытым, публичным сетям, действительны и не истекли или не были отозваны) является наилучшей практикой до 31 марта 2025 года, после чего он станет обязательным в рамках Требования 4.2.1 и должен быть полностью учтен при оценке PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 4.2.1.a Изучите документированные политики и процедуры, а также проведите интервью с персоналом, чтобы убедиться, что процессы определены с учетом всех элементов, указанных в этом требовании.
- 4.2.1.b Изучите конфигурации системы, чтобы убедиться, что сильная криптография и безопасные протоколы реализованы в соответствии со всеми элементами, указанными в этом требовании.
- 4.2.1.c Изучите передачи данных держателей карт, чтобы убедиться, что весь PAN шифруется с использованием сильной криптографии, когда он передается по открытым, публичным сетям.
- 4.2.1.d Изучите конфигурации системы, чтобы убедиться, что ключи и/или сертификаты, которые не могут быть проверены как доверенные, отклоняются.
Цель:
Чувствительная информация должна быть зашифрована при передаче по публичным сетям, потому что перехват и/или перенаправление данных во время передачи — это распространенная и легкая цель для злоумышленников.
Надлежащая практика:
Схемы сети и потока данных, определенные в Требовании 1, являются полезными ресурсами для выявления всех точек подключения, где передаются или принимаются данные учетных записей по открытым, публичным сетям.
Хотя это не требуется, рекомендуется, чтобы организации также шифровали PAN в своих внутренних сетях и чтобы они обеспечивали шифрование коммуникаций для любых новых сетевых реализаций.
Передачи PAN могут быть защищены путем шифрования данных до их передачи или шифрования сеанса, по которому передаются данные, или обоих методов. Хотя не требуется, чтобы сильная криптография применялась как на уровне данных, так и на уровне сеанса, это настоятельно рекомендуется. Если шифрование происходит на уровне данных, то криптографические ключи, используемые для защиты данных, могут управляться в соответствии с Требованиями 3.6 и 3.7. Если данные шифруются на уровне сеанса, то назначенные хранители ключей должны нести ответственность за управление ключами и сертификатами для передачи.
Некоторые реализации протоколов (такие как SSL, SSH v1.0 и ранние версии TLS) имеют известные уязвимости, которые злоумышленник может использовать для получения открытых данных. Важно, чтобы организации отслеживали даты прекращения поддержки для используемых шифровальных наборов и были готовы перейти на более новые версии или протоколы, когда старые больше не считаются безопасными.
Подтверждение доверенности сертификатов помогает обеспечить целостность защищенного соединения. Чтобы сертификат считался доверенным, он должен быть выдан доверенным источником, таким как доверенный центр сертификации (CA), и не быть истекшим. Для проверки сертификатов можно использовать актуальные списки отозванных сертификатов (CRL) или протокол статуса онлайн-сертификатов (OCSP).
Методы проверки сертификатов могут включать закрепление сертификатов и публичных ключей, когда доверенный сертификат или публичный ключ закрепляются либо в процессе разработки, либо при его первом использовании. Организации могут также подтвердить с разработчиками или проверить исходный код, чтобы удостовериться, что клиенты и серверы отклоняют соединения, если сертификат невалиден.
Для браузерных TLS-сертификатов доверенность сертификата можно часто проверить, щелкнув на значок замка рядом с адресной строкой.
Примеры:
Открытые, публичные сети включают, но не ограничиваются:
- Интернет,
- Беспроводные технологии, включая Wi-Fi, Bluetooth, сотовые технологии и спутниковую связь.
Дополнительная информация:
Рекомендации поставщиков и лучшие отраслевые практики могут быть использованы для получения информации о соответствующей силе шифрования, специфичной для используемой методологии шифрования.
Для получения дополнительной информации о сильной криптографии и безопасных протоколах см. отраслевые стандарты и лучшие практики, такие как NIST SP 800-52 и SP 800-57.
Для получения информации о доверенных ключах и сертификатах см. практическое руководство NIST Cybersecurity Practice Guide Special Publication 1800-16, "Securing Web Transactions: Transport Layer Security (TLS) Server Certificate Management".
