CompTIA SY0-701: Безопасность данных, конфиденциальность и криптография — Руководство по подготовке

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Часть CompTIA Security+ SY0-701 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов CompTIA, или пройдите тесты на время на ExamRoll.io.

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

Классификация и обработка данных

Классификация данных присваивает метки конфиденциальности, которые определяют требования к их обработке. В государственных системах используются уровни «Несекретно», «Конфиденциально», «Секретно» и «Совершенно секретно». В коммерческих системах обычно используются уровни «Публичные», «Внутренние», «Конфиденциальные» и «Ограниченного доступа» (или их эквиваленты). Классификация должна основываться на конфиденциальности данных и нормативных обязательствах, а не на удобстве.

Системы предотвращения утечек данных (DLP) обеспечивают соблюдение политик обработки, проверяя содержимое на конечных точках, в точках выхода из сети и в облачных хранилищах. Правило DLP может блокировать вложения в электронные письма, содержащие 16-значные строки, соответствующие шаблонам кредитных карт, или предупреждать, когда пользователь загружает файл с фразой «цель поглощения» в личное облачное хранилище. Эффективность DLP зависит от точности классификации — если конфиденциальные данные не помечены, DLP не сможет их защитить.

Суверенитет данных касается того, где физически находятся данные и законы какой юрисдикции к ним применяются. GDPR требует, чтобы персональные данные граждан ЕС, передаваемые за пределы ЕС, были защищены решениями об адекватности (adequacy decisions), стандартными договорными условиями (Standard Contractual Clauses) или обязательными корпоративными правилами (Binding Corporate Rules). Организации, работающие по всему миру, должны составлять карты потоков данных и обеспечивать соответствие мест хранения и обработки применимым нормам.

Шифрование при передаче и хранении

TLS 1.3 — это текущий стандарт для шифрования данных при передаче. Он исключает слабые наборы шифров, требует прямой секретности (forward secrecy) (эфемерный обмен ключами Диффи-Хеллмана) и сокращает рукопожатие до одного цикла приема-передачи. TLS 1.0 и 1.1 устарели; TLS 1.2 остается приемлемым, но должен быть настроен с использованием надежных наборов шифров. Конфигурация Nginx, обеспечивающая соблюдение текущих стандартов:

# Enforcing TLS 1.2+ in an Nginx server block
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;

Шифрование при хранении защищает данные на носителях информации. Полное шифрование диска (BitLocker, FileVault, LUKS) шифрует весь том; шифрование на уровне файлов (EFS, контейнеры VeraCrypt) шифрует отдельные файлы. Шифрование на уровне базы данных (Transparent Data Encryption в SQL Server и Oracle) шифрует файлы данных и резервные копии. Важный нюанс: шифрование при хранении защищает от физической кражи носителя, но не защищает от скомпрометированного приложения, которое уже расшифровало данные для обработки.

Криптографические примитивы

Симметричные алгоритмы (AES-128, AES-256, ChaCha20) используют один общий ключ, работают быстро и подходят для больших объемов данных. Асимметричные алгоритмы (RSA, ECDSA, Ed25519, ECDH) используют пары ключей и позволяют выполнять обмен ключами, создавать цифровые подписи и привязывать удостоверения, но требуют больших вычислительных затрат. Гибридные системы, такие как TLS, используют асимметричную криптографию для согласования симметричного сессионного ключа, а затем симметрично шифруют основной трафик.

Хеширование (SHA-256, SHA-3) — это односторонняя функция, создающая дайджест (свертку) фиксированной длины. Хеши — это не шифрование: их нельзя обратить с помощью ключа, потому что ключа не существует. Хеши паролей с «солью» (с использованием bcrypt, scrypt, Argon2 или PBKDF2) добавляют случайное значение для каждого пользователя, чтобы противостоять радужным таблицам. Хеши обеспечивают проверку целостности; HMAC объединяет хеш с секретным ключом для обеспечения как целостности, так и аутентичности.

Режимы шифрования так же важны, как и сам алгоритм. AES в режиме ECB шифрует каждый блок независимо, создавая идентичный шифротекст для идентичных блоков открытого текста — это катастрофическое свойство, которое раскрывает шаблоны данных. AES-GCM (Galois/Counter Mode) обеспечивает и конфиденциальность, и целостность за один проход и является стандартом для современных протоколов. Режим CBC с правильным дополнением (padding) и HMAC приемлем, но его сложнее реализовать корректно.

Управление ключами и их хранение

Надежность криптографии определяется надежностью управления ключами. Ключи должны генерироваться с высокой энтропией, храниться отдельно от данных, которые они защищают, ротироваться по расписанию и уничтожаться по окончании срока службы. Аппаратные модули безопасности (HSM) обеспечивают защищенное от несанкционированного доступа хранение ключей и ускорение криптографических операций. Доверенный платформенный модуль (TPM) — это чип на конечных устройствах, который хранит ключи, используемые BitLocker и функцией measured boot (измеряемой загрузки). Депонирование ключей (key escrow) предполагает передачу копии ключей доверенной третьей стороне для их восстановления на законных основаниях, в то время как агенты восстановления ключей (key recovery agents) позволяют предприятиям при необходимости расшифровывать данные сотрудников. Облачные сервисы KMS (AWS KMS, Azure Key Vault, Google Cloud KMS) предлагают конвертное шифрование, при котором ключ шифрования данных (DEK) защищает данные и сам шифруется ключом шифрования ключей (KEK), хранящимся в HSM.

Инфраструктура открытых ключей

PKI (инфраструктура открытых ключей) связывает удостоверения с открытыми ключами через сертификаты, выданные центром сертификации (ЦС). Подчиненный ЦС образует цепочку до корневого ЦС, сертификат которого должен быть предварительно доверенным. Жизненный цикл сертификата начинается с запроса на подпись сертификата (CSR), который генерируется вместе с закрытым ключом:

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=www.example.com/O=Example Corp/C=US"

ЦС проверяет запрашивающего, подписывает CSR и выдает сертификат X.509. Информация об отзыве публикуется через списки отозванных сертификатов (CRL) — периодически загружаемые списки серийных номеров отозванных сертификатов — или через протокол статуса сертификата онлайн (OCSP), респондеры которого отвечают на запросы по каждому отдельному сертификату в реальном времени. OCSP stapling (прикрепление OCSP-ответа) позволяет серверу представить свежий подписанный статус во время TLS-рукопожатия, избегая обращений клиента к ЦС. Срок действия сертификатов истекает, и их необходимо продлевать; автоматизация через ACME (Let’s Encrypt, внутренние серверы ACME) предотвращает сбои в работе из-за просроченных сертификатов.

Подписание кода и проверка целостности

Подписание кода (code signing) использует закрытый ключ разработчика для подписи артефакта программного обеспечения; получатели проверяют подпись с помощью сертификата разработчика, подтверждая как целостность, так и происхождение. Это защищает от несанкционированного вмешательства в цепочку поставок. Инструменты мониторинга целостности файлов (Tripwire, AIDE) и публикация хешей (значений sha256sum рядом с файлами для скачивания) также обнаруживают несанкционированные изменения, но само по себе хеширование доказывает лишь то, что файл соответствует значению, — оно не удостоверяет, кто создал это значение. Только цифровая подпись, подкрепленная PKI, обеспечивает и целостность, и неотрекаемость (non-repudiation).

Хранение, санитизация и безопасная утилизация

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

Когда срок службы носителя подходит к концу, санитизация должна соответствовать чувствительности данных и дальнейшему назначению носителя. Стандарт NIST SP 800-88 определяет три уровня: Clear (логическая перезапись, достаточная для повторного использования внутри организации), Purge (криптографическое стирание, стирание блоков или размагничивание, достаточное для повторного использования вне организации) и Destroy (шредирование, дезинтеграция, сжигание, измельчение). Криптографическое стирание — уничтожение ключа шифрования, после которого зашифрованный текст становится невосстановимым, — является быстрым и эффективным методом для дисков с самошифрованием (self-encrypting drives), которые готовятся к повторному использованию. Размагничивание (degaussing) делает магнитные носители непригодными для использования и не работает с SSD. Физическое уничтожение — единственный гарантированный метод для поврежденных носителей или данных с наивысшим грифом секретности.

Практический сценарий: сбой в управлении ключами, приведший к утечке

SaaS-компания зашифровала свою клиентскую базу данных с помощью AES-256, но хранила ключ шифрования в текстовом конфигурационном файле в том же репозитории, что и код приложения. Когда разработчик случайно отправил репозиторий в публичный аккаунт на GitHub, автоматизированный бот для сканирования учетных данных обнаружил ключ в течение 11 минут. Злоумышленник использовал этот ключ для расшифровки резервной копии базы данных, которая хранилась в публично доступном бакете S3 (отдельная ошибка конфигурации). Шифрование было технически правильным — AES-256 невозможно взломать перебором (brute force), — но управление ключами было катастрофически ошибочным. При правильном управлении ключами ключ должен был храниться в менеджере секретов (например, AWS Secrets Manager, HashiCorp Vault) с доступом, контролируемым через IAM-роли, и никогда не находиться в исходном коде или конфигурационных файлах.

← Безопасность облаков · Все домены · Непрерывность бизнеса и аварийное восстановление →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →