Криптография и TLS за 10 минут
Криптография превращает читаемые данные в защищённый результат с помощью алгоритма и ключа. Цели различаются: шифрование обеспечивает конфиденциальность, хэширование — контроль целостности, подпись — целостность и аутентификацию автора. Криптография не спасает от украденного ключа или скомпрометированной конечной точки.
Алгоритмы
Симметричная схема использует один секретный ключ для шифрования и расшифрования. Она быстрая и подходит для больших объёмов, но ключ нужно безопасно передать сторонам. Асимметричная использует пару public/private key. Открытый ключ можно распространять, закрытый хранится в секрете; цена — меньшая скорость. На практике TLS применяет асимметричный обмен для установления общего сеансового секрета, а данные передаёт симметрично.
Хэш — односторонний отпечаток фиксированной длины. Любое изменение обычно меняет результат. Пароли не шифруют: их хэшируют с уникальной солью и медленным адаптивным алгоритмом. Хэш не обеспечивает конфиденциальность, а совпадение хэша не доказывает автора.
PKI и подписи
PKI связывает открытый ключ с идентичностью через сертификат. Центр сертификации (CA) подписывает сертификат, промежуточные CA образуют цепочку доверия, а клиент проверяет имя, срок, подпись и отзыв. Компрометация CA опасна, поэтому важны защищённое хранение ключей и процедура revocation.
Цифровая подпись создаётся закрытым ключом, проверяется открытым и подтверждает, что подписатель контролировал ключ, а сообщение не изменилось. Она не скрывает содержание. Не путайте подпись с шифрованием.
TLS за десять минут
Клиент подключается к серверу, сервер показывает сертификат и согласует параметры. Клиент проверяет цепочку доверия и имя, стороны выполняют обмен ключами и получают сеансовый симметричный ключ. Далее трафик защищён от чтения и подмены на канале, но не от вредоносного сервера или утечки данных после расшифрования. Современная конфигурация отключает устаревшие протоколы и слабые наборы шифров, включает актуальные сертификаты и автоматическое продление.
openssl s_client -connect example.com:443 -servername example.com </dev/null
Команда только показывает сведения TLS разрешённого сервиса; интерпретируйте срок, имя и цепочку, не отправляя секреты.
Управление ключами важнее выбора красивого алгоритма: инвентаризация, ротация, резервирование с контролем доступа, разделение обязанностей и уничтожение. Для данных в покое шифруйте диски и резервные копии, для передачи — защищённый протокол.
Типичные ошибки
Не изобретайте собственный алгоритм, не храните ключ рядом с зашифрованным архивом и не принимайте любой сертификат без проверки имени. Base64 — кодирование, а не шифрование. Хэширование и шифрование решают разные задачи. Секреты держите в vault или HSM, ограничивайте доступ приложению и логируйте операции без вывода самого ключа.
Ротация должна учитывать старые данные: заранее определите, как расшифровать легитимные копии после смены ключа, и как отозвать скомпрометированный сертификат. Для TLS проверяйте цепочку на клиенте, иначе «HTTPS» может быть лишь красивой надписью.
В экзаменационном вопросе сначала определите требование: скрыть содержимое — encryption, обнаружить изменение — hash/MAC, доказать автора — digital signature, установить доверие — PKI.
Практическое задание
Закрепите тему на собственной тестовой схеме, не затрагивая рабочие системы. Сначала опишите активы и доверенные границы простыми словами, затем укажите владельца каждого решения. Для каждого риска запишите вероятность, последствия, существующий контроль и остаточный риск. Такой короткий реестр полезнее списка модных продуктов: он показывает, какую именно задачу решает мера и где остаётся пробел.
Проведите проверку в безопасной лаборатории и сохраните результат: время, команду или действие, ожидаемый результат и фактическое наблюдение. Если проверка не удалась, сначала проверьте разрешение, область теста и журналирование, а не усиливайте настройки вслепую. Любое исключение оформите с причиной, сроком и ответственным.
При разборе инцидента отделяйте факт от гипотезы. Факт подтверждается журналом, конфигурацией или воспроизводимым тестом; гипотеза требует дополнительной проверки. Это снижает риск неправильной атрибуции и помогает команде выбрать пропорциональную реакцию. После изменения контроля повторите тест и убедитесь, что доступность бизнеса не пострадала.
Полезный результат обучения — не запомнить термин, а уметь объяснить его на сценарии: какая угроза действует, какой актив затронут, какой контроль сработает первым, что обнаружит событие и как восстановиться. Именно такую цепочку проверяйте при подготовке к Security+.
Вопросы для самопроверки
Проверьте себя по сценарию. Какой актив защищается и какое свойство CIA важнее всего? Где проходит граница доверия? Как злоумышленник может получить первоначальный доступ, какое событие подтвердит гипотезу и кто принимает решение о сдерживании? Затем назовите как минимум один технический, один административный и один физический контроль. Для каждого укажите, является ли он превентивным, детективным или корректирующим, и какое доказательство эффективности можно получить.
Отдельно продумайте исключения. Что произойдёт, если основной сервис, каталог идентичностей или канал связи недоступен? Запишите ручную процедуру, резервный контакт и безопасный способ возврата к нормальной работе. Не забывайте о приватности: журналы должны содержать достаточно контекста для расследования, но не раскрывать пароли, токены и лишние персональные данные.
Хороший ответ Security+ связывает термин с решением и ограничением. MFA уменьшает риск украденного пароля, но не устраняет вредоносную конечную точку; резервная копия ускоряет восстановление, но не предотвращает утечку; IDS обнаруживает, но требует реакции. Такая причинно-следственная цепочка помогает выбирать правильный контроль в практическом вопросе. **Дисклеймер: материал учебный и не заменяет официальные exam objectives CompTIA.
Комментарии