Недорогой SSL-сертификат не обязательно снижает уровень безопасности шифрования. Если сертификат выдан центром сертификации, которому доверяет целевой браузер, используются подходящие ключ и алгоритм подписи, а TLS развернут правильно, даже недорогой сертификат может обеспечивать надежную защиту передаваемых данных. Между стоимостью сертификата и уровнем шифрования отдельного HTTPS-соединения нет простой прямой зависимости.
При выборе недорогого SSL-сертификата специалистам по контролю качества и безопасности следует разделить вопрос на несколько частей: заслуживает ли сертификат доверия, какие параметры шифрования фактически используются для соединения и будет ли сертификат оставаться действительным. Цена может влиять на проверку личности, охват доменов, техническую поддержку и услуги управления, но сама по себе не доказывает, что соединение более или менее безопасно.
Так называемые «SSL-сертификаты» на веб-сайтах обычно используются совместно с протоколом TLS. Сертификат подтверждает связь между доменом и открытым ключом, после чего браузер и сервер согласовывают параметры соединения в ходе рукопожатия. Передача содержимого веб-страниц, форм запросов и других данных защищается ключом сеанса, полученным в результате согласования, а не определяется стоимостью сертификата.
Поэтому утверждение «дорогой сертификат обеспечивает шифрование с большей разрядностью» может привести к ошибочным выводам. Алгоритм и длина открытого ключа сертификата, алгоритм подписи сертификата, способ обмена ключами TLS и алгоритм шифрования сеанса — это разные параметры, которые нужно проверять отдельно. Одной лишь надписи «высокий уровень шифрования» на странице товара недостаточно, чтобы оценить безопасность итогового соединения.
Разница в цене сертификатов может быть обусловлена следующими факторами:
Для обычного корпоративного сайта, сайта для привлечения запросов от внешнеторговых клиентов и маркетинговой целевой страницы, если нет дополнительных требований к отображению сведений об организации или требований договора, доверенного и правильно настроенного сертификата DV может быть достаточно для защиты данных при передаче по HTTPS. Для операций с платежами или конфиденциальными данными необходимо также учитывать требования платежных сервисов и применимые нормы: пройти проверку безопасности, опираясь только на класс сертификата, нельзя.
Проверку безопасности следует проводить на общедоступном домене и фактических точках входа. Соответствие файла сертификата требованиям не означает, что каждое соединение, обслуживаемое сервером, CDN и обратным прокси-сервером, тоже соответствует требованиям.
Сначала проверьте доверие и идентификацию. Убедитесь, что домен указан в поле альтернативных имен субъекта сертификата, сертификат не просрочен, сервер предоставляет необходимые промежуточные сертификаты, а браузеры и операционные системы, которыми пользуются целевые клиенты, могут построить доверенную цепочку сертификатов. Нормальная работа на одном офисном компьютере не означает, что у устройств, используемых зарубежными клиентами, не возникнет проблем с совместимостью.
Затем проверьте протоколы и алгоритмы. При проверке конфигурации уделите особое внимание TLS 1.2 и TLS 1.3; отключите устаревшие SSL и ранние версии TLS. Для TLS 1.2 также следует проверить наборы шифров и отдавать предпочтение способам обмена ключами с поддержкой прямой секретности и подходящим алгоритмам аутентифицированного шифрования. Открытый ключ и алгоритм подписи сертификата тоже нужно проверять отдельно: поддержка TLS 1.3 не означает, что все проверки пройдены.
Наконец, выясните, где завершается TLS. При использовании CDN или облачного прокси браузер обычно видит сертификат пограничного узла. Если соединение от пограничного узла до исходного сервера использует незашифрованный HTTP или шифруется без проверки сертификата, посетитель все равно может видеть обычную страницу HTTPS. Поэтому общедоступную точку входа и соединение с исходным сервером следует проверять отдельно.

В журнале проверки следует как минимум указывать домен, время проверки, цепочку сертификатов, согласованный протокол и результаты проверки ключевых параметров конфигурации. Если многоязычные сайты, интернет-магазин и рекламные целевые страницы размещены на разных платформах, нужно проверять каждую фактическую точку входа, а не считать все соответствующим требованиям после проверки только основного сайта.
Низкая цена сама по себе не является недостатком, но неясный объем закупки создает риски. Некоторые предложения включают только выдачу сертификата, а установку, автоматическое продление и устранение сбоев компания должна обеспечивать самостоятельно. Если у компании нет необходимых ресурсов для технического сопровождения, сэкономленные на покупке средства могут обернуться расходами из-за остановки сайта и устранения неполадок.
Необходимо также четко определить ответственность за управление закрытым ключом. Его следует создавать и хранить в контролируемой среде, ограничивать права на чтение и не пересылать без необходимости через мессенджеры или по электронной почте. Если ключ хранит поставщик услуг по созданию сайта, следует согласовать порядок доступа к ключу, действия при смене сотрудников, отзыва сертификата и повторной выдачи. Покупка более дорогого сертификата не компенсирует утечку закрытого ключа.
Необходимо проверить всю цепочку автоматического продления: удается ли своевременно пройти проверку, получить новый сертификат, установить его на все узлы и убедиться, что сервис успешно его загрузил. Одного уведомления об успешном продлении недостаточно: система мониторинга должна также проверять сертификат, фактически предоставляемый через общедоступную сеть. Сертификаты с коротким сроком действия особенно зависят от автоматизации, поэтому компании следует предусмотреть время на устранение ошибок проверки, изменение прав доступа и корректировку DNS-записей.
Кроме того, HTTPS защищает данные в процессе передачи. Он не устраняет уязвимости сайта, не препятствует использованию слабых паролей для входа в административную панель и не гарантирует безопасность данных после их сохранения в базе. Даже если система обработки запросов или интернет-магазин прошли проверку сертификата, необходимо отдельно проверить права доступа приложения, хранение данных и сторонние скрипты.
Если недорогой сертификат отвечает требованиям по совместимости с доверенными системами, охвату доменов, настройкам шифрования и управлению продлением, компания может его использовать. При сравнении предложений следует попросить поставщика четко указать тип сертификата, охватываемые домены, объем работ по развертыванию, ответственность за продление и порядок реагирования на сбои. Не следует сравнивать стоимость сертификата со стоимостью полного сопровождения как одну и ту же услугу.
Если у компании много сайтов, публикации выходят часто или нет выделенных специалистов по сопровождению, доплата за централизованное управление, автоматическое развертывание и четко определенный уровень реагирования может быть оправданна. Если бизнесу действительно требуется проверка личности организации, следует выбрать соответствующий требованиям тип сертификата.
По итогам закупочной оценки нужно получить ответы на следующие вопросы: могут ли целевые клиенты доверять этому соединению, соответствуют ли требованиям параметры шифрования, кто отвечает за закрытый ключ и удастся ли заменить сертификат до истечения срока его действия. Если на все эти вопросы есть ответы, которые можно проверить, недорогой вариант может стать обоснованным способом снизить затраты. Но одного сертификата и адреса HTTPS недостаточно, чтобы пройти проверку безопасности.
Связанные статьи
Связанные продукты


