Сценарии применения PKI: HTTPS, S/MIME и подпись кода

Инфраструктура открытых key (PKI) — невидимая основа защищённых цифровых коммуникаций. Изученные Вами сертификаты и CA ежедневно применяются в десятках практических сценариев. На экзамене Security+ проверяется умение распознавать варианты применения PKI, понимать, какой тип сертификата подходит для каждого из них, и определять, какую защиту PKI обеспечивает в конкретном контексте. Три наиболее важные области применения на экзамене — HTTPS/TLS (безопасность веб-соединений), S/MIME (безопасность электронной почты) и подпись кода (целостность программного обеспечения).

HTTPS (HTTP поверх TLS) — наиболее заметный вариант применения PKI. Когда Вы подключаетесь к https://bank.com, браузер: (1) получает TLS-сертификат сервера, (2) проверяет, что цепочка сертификатов ведёт к доверенному корневому CA, (3) сопоставляет имя узла с полями SAN, (4) проверяет, что certificate не отозван, и (5) использует открытый key для обмена key по алгоритму Диффи — Хеллмана, чтобы установить зашифрованный сеанс. Значок замка в браузере означает, что все эти проверки пройдены. Отсутствующий или недействительный сертификат вызывает предупреждение браузера, которое не позволяет большинству пользователей продолжить работу.

S/MIME (Secure/Multipurpose Internet Mail Extensions) использует сертификаты PKI для предоставления двух средств защиты электронной почты. Шифрование: отправитель шифрует текст письма открытым key получателя, поэтому расшифровать его может только получатель — это защищает конфиденциальность, даже если письмо перехвачено при передаче или хранится на скомпрометированном сервере. Цифровые подписи: отправитель подписывает письмо своим закрытым key, доказывая получателю, что письмо действительно отправлено этим отправителем и не изменялось, — это обеспечивает целостность и неотказуемость. Для S/MIME каждому пользователю требуется собственный сертификат, выданный CA.

Подпись кода использует PKI для цифровой подписи программного обеспечения — исполняемых файлов, сценариев, драйверов и установщиков, — чтобы пользователи могли проверить, что оно получено от доверенного издателя и не подвергалось изменениям. Поставщик программного обеспечения подписывает код закрытым key из сертификата для подписи кода, выданного доверенным CA. Когда пользователь запускает программу, OS проверяет подпись с помощью открытого key поставщика из цепочки сертификатов. Windows SmartScreen, Защитник macOS Gatekeeper и магазины приложений iOS/Android используют подпись кода для подтверждения происхождения программного обеспечения. Программное обеспечение без подписи может быть заблокировано или вызвать предупреждения системы безопасности.

Аутентификация по сертификату клиента (также называемая взаимным TLS или mTLS) расширяет стандартную модель TLS, требуя, чтобы клиент также предоставлял сертификат. В стандартном TLS сертификатом аутентифицируется только сервер; при mTLS обе стороны взаимно аутентифицируются. Этот механизм используется для: аутентификации VPN (смарт-карты или сертификаты клиента вместо паролей), аутентификации API (аутентификация между компьютерами, где клиентом является служба, а не человек) и доступа администраторов с привилегиями (администраторы должны использовать аппаратные токены со встроенными сертификатами).

SSH использует криптографию с открытым key для двух целей: аутентификации сервера и аутентификации клиента. При аутентификации сервера, когда Вы впервые подключаетесь к серверу SSH, он предоставляет свой host key (открытый key). Ваш SSH-клиент сохраняет его в ~/.ssh/known_hosts. При последующих подключениях, если host key изменился, что может указывать на атаку MITM или переустановку сервера, SSH предупреждает Вас. При аутентификации клиента вместо паролей администраторы используют пары key: открытый key добавляется на сервер в authorized_keys, а закрытый key, который никогда не передаётся, подтверждает личность. Host key SSH отличаются от сертификатов PKI, но выполняют ту же функцию доверия.

PKI позволяет использовать имеющую юридическую силу цифровую подпись документов во многих юрисдикциях. Подписи Adobe PDF, DocuSign и государственные системы электронной подписи используют сертификаты PKI для подписания документов. Важным дополнением к подписанию документов является проставление отметки времени: доверенный центр отметок времени (TSA) подписывает хеш документа, указывая доверенное время, и тем самым доказывает, что документ существовал в определённый момент. Отметка времени также необходима для подписи кода: без неё подписи кода становятся недействительными после истечения срока действия сертификата подписи, даже если программное обеспечение было распространено до этой даты.

По мере распространения устройств IoT PKI предоставляет механизм масштабной аутентификации устройств. Во время производства каждое устройство получает уникальный сертификат — этот процесс называется подготовкой удостоверения устройства, — благодаря чему серверы могут аутентифицировать отдельные устройства по их сертификатам. Это позволяет, например, интеллектуальному счётчику подтверждать свою личность серверу энергоснабжающей компании, медицинскому устройству — проходить аутентификацию в сети больницы, а автопарку — аутентифицироваться во внутренней системе производителя. PKI для IoT должна обслуживать миллионы устройств с ограниченными ресурсами, поэтому всё чаще применяются сертификаты ECC: они имеют небольшой размер и быстро проверяются.

Аутентификация VPN на основе сертификатов значительно безопаснее аутентификации VPN по паролю. Каждый пользователь или устройство VPN получает сертификат клиента от внутреннего CA организации. При подключении шлюз VPN проверяет сертификат клиента, убеждаясь, что он выдан доверенным внутренним CA, находится в пределах срока действия и не был отозван через CRL/OCSP. Когда сотрудник увольняется, отзыв его сертификата немедленно блокирует доступ к VPN — это надёжнее, чем надеяться, что он не сообщил свой пароль другим.

Специалисты по безопасности должны уметь диагностировать распространённые ошибки сертификатов. Срок действия certificate истёк: дата notAfter уже прошла — обновите certificate. Несовпадение имени узла: SAN certificate не соответствует запрошенному имени узла — проверьте CN и SAN; может потребоваться сертификат с подстановочным знаком или сертификат с несколькими SAN. Самоподписанный сертификат: ни один CA не подтвердил этот certificate — добавьте его в локальное хранилище доверенных сертификатов или замените сертификатом, подписанным CA. Неполная цепочка: промежуточный сертификат CA не предоставлен сервером — настройте сервер на отправку полной цепочки. Certificate отозван: CRL или OCSP показывает отзыв — требуется немедленно отреагировать на компрометацию key.

Для нескольких имён узлов используются два типа сертификатов. Сертификат с подстановочным знаком охватывает все поддомены первого уровня домена: *.example.com охватывает www.example.com, mail.example.com и api.example.com, но NOT sub.api.example.com (два уровня). Один сертификат и один закрытый key для всех служб — это удобно, но рискованно: при компрометации key будут затронуты все службы. Сертификат с несколькими SAN явно перечисляет несколько конкретных доменов в расширении SAN, например example.com, www.example.com и api.example.com. Такой подход более точен, но при добавлении новых доменов certificate необходимо обновлять.

Проверьте своё понимание концепций CompTIA Security+ (SY0-701), рассмотренных в этом уроке.

В этом уроке Вы узнали, что сертификаты HTTPS/TLS шифруют веб-трафик и аутентифицируют серверы; сертификаты S/MIME позволяют подписывать и шифровать электронную почту; сертификаты для подписи кода подтверждают целостность программного обеспечения и личность издателя; а сертификаты клиентов обеспечивают взаимную аутентификацию для VPN и API. Далее мы рассмотрим политики паролей и многофакторную аутентификацию.