Самоподписанные сертификаты SSL, использование и проблемы Украина купить сертификат 

Справочные материалы по безопасности в интернет
SSL, Code Signin, Email, PDF, Word... сертификаты

Контакты
☎ +380672576220

Проверка
SSL
Установка
SSL
Цепочка
SSL
Seal
SSL
CSR
pKey
Экспорт-Импорт
Конвертер
Code Sign
сертификаты
Email Smime
сертификаты
PDF и Word
сертификаты
База
знаний
Купить
SSL

Разное о сертификатах Обзор алгоритмов
RSA алгоритм
DSA алгоритм
ECC алгоритм
SHA-2 хеш алгоритм

Журнал прозрачности сертификатов
OCSP респондер сертификатов
CAA запись в DNS домена
Отзыв сертификата
Intermal Names проблема
SNI - Server Name Indication
HSTS протокол
Серверные и Клиентские серты
Обзор основ криптографии
Проблемы поля Common Name
Зачем нужны Центры сертификации
Проблемы новых доменов
Риски промежуточных сертификатов
Безопасность мобильных устройств
Технология DANE
Проверка подлинности сайта
Если ваш сайт взломали
Хронология развития TLS
Для владальцев Апача

Уязвимость Drown - лечение
Уязвимость Logjam - лечение
Уязвимость Venom - лечение
Уязвимость Heartbleed - лечение
Уязвимость Poodlebleed - лечение
Уязвимость смешанного контента
Уязвимость вашего компьютера

Руководство по SSL для начинающих
Экскурсия по SSL сертификатам
SSL и жизнь-проблемы и радости
SSL путеводитель по сертификатам
Поля сертификата от Windows
SSL краткая история
SSL на всех сайтах
Google и SSL взаимная любовь
Покупка в инет магазине
Доверие как бизнес
Классы SSL сертификатов
Standart, SAN и Wildcard серты
Самоподписанные сертификаты
EV сертфиикаты зеленые
DV сертификаты для домена
Фейковые SSL сертификаты

CA Map

Когда вы можете использовать самозаверенный сертификат? - Когда доверие, безопасность, сервис, качество и надежность не являются вашими критериями.

Хотя многие ИТ-специалисты считают, что использование самоподписанных сертификатов SSL может помочь их организациям снизить затраты на безопасность, реальные цифры говорят о другом. От инфраструктуры центра обработки данных и физической безопасности до аппаратного и программного обеспечения, необходимого для системы PKI, до персонала, необходимого для управления жизненным циклом сертификата, настоящие затраты на самоподписанную безопасность могут стать очень дорогими.

Администраторы веб-сайта могут просто использовать самоподписанные сертификаты. Их легко выпускать, и они являются «бесплатными». Перед выпуском самоподписанных сертификатов рекомендуется рассмотреть модель доверия и безопасности. Нужно сравнить самозаверяющие сертификаты с моделью доверенного центра сертификации (CA); а затем принять собственное решение.

Модель самоподписанного сертификата SSL

  • Владелец говорит, кто они
  • Владелец выпускает собственную политику
  • Владелец отвечает за качество
  • Владелец может не следовать отраслевым рекомендациям
  • Владелец может не предоставлять статус сертификата
  • Владелец не может отозвать скомпрометированные сертификаты
  • Владелец не проверяется третоей стороной
  • Эмитент сертификата не контролируется владельцем домена
  • Сертификаты не могут быть продлены, если нет напоминаний
  • Самоподписанная модель сертификата не обеспечивает доверия, и браузер предоставляет диалоговое окно доверия, чтобы указать на это

Скрытые затраты на самоподписанные SSL-сертификаты

На самом деле самозаверяющие сертификаты намного дороже и рискованнее, чем работа с надежным поставщиком безопасности Даже когда бизнес процветает, умные компании всегда присматриваются к сути. Безопасность обычно не является одним из первых мест, в которых компании стремятся урезать расходы, но некоторые ИТ-специалисты считают, что они могут легко снизить затраты, исключив сторонние сертификационные центры SSL (SSL) из бюджетного уравнения.

Несмотря на то, что тратить деньги на защиту SSL для внешних сайтов, таких как домашняя страница или страницы электронной коммерции, по-прежнему представляется необходимым, некоторые ИТ-специалисты считают, что самоподписанные сертификаты SSL являются приемлемой альтернативой для внутренних сайтов. Они считают, что, поскольку только внутренние сотрудники имеют доступ к серверам, на которых размещаются сайты, ориентированные на внутреннюю среду, такие как интранет-порталы и вики, самонастраиваемые сертификаты обеспечивают адекватную защиту практически без затрат. Однако подобные рассуждения могут иметь неприятные последствия...

Общая стоимость владения (TCO) SSL-сертификата намного больше, чем цена сертификата. Из аппаратного обеспечения безопасности, программного обеспечения для управления, пространства центров обработки данных и т. Д. Затраты на создание безопасной архитектуры самозаписывания могут быстро складываться. Не только это, но и сам подход к безопасности SSL может поставить организацию под угрозу - как с технической, так и с деловой точки зрения - различными способами. Истинная совокупная стоимость владения (TCO) для самоподписанных сертификатов SSL, включая сравнение самоподписанной архитектуры по сравнению с работой с сторонним поставщиком SSL. Прежде чем компания решит использовать самоподписанные сертификаты, эти вопросы заслуживают тщательного рассмотрения.

Публично-доверенная модель сертификата с сертификатом CA

  • CA проверяет владельца домена и заявителя сертификата
  • CA работает с политикой в ​​соответствии с требованиями поставщиков браузеров и операционных систем. Требования включают базовые требования к CA / Browser Forum Baseline Requirements, расширенные правила проверки (EV) и рекомендации от NIST.
  • CA обеспечивает качество сертификата. Проверки включают скомпрометированные ключи, минимальный размер ключа, обеспечение алгоритмов хэширования, максимальный срок действия и правильные расширения сертификатов.
  • CA обновляет политику на основе передовой практики в отрасли
  • CA предоставляет статус сертификата через CRL и OCSP
  • Скомпрометированные сертификаты могут быть аннулированы
  • CA проверяется на критерии выдачи сертификата, такие как WebTrust для CA, WebTrust для EV и базовых требований SSL
  • Провайдеры сертификатов для сертификата, подтвержденного Доменом, разрешаются владельцем домена. Запросы на сертификаты организации и расширенной проверки разрешены членом организации, указанной в сертификате.
  • ЦС предоставляют несколько напоминаний, чтобы гарантировать, что сертификаты будут продлены до истечения срока их действия. Центры сертификации могут также предоставлять инструменты обнаружения сертификатов для поиска сертификатов в ваших системах, которые могут не иметь напоминаний.
  • Публично доверенная модель CA основана на том, что CA является доверенной третьей стороной поставщика браузера / ОС, подписчика сертификата веб-сайта и конечных пользователей веб-сайта. ЦА обязан соответствовать требованиям всех трех сторон.

Сторонние проверенные или самоподписанные сертификаты?

Когда протокол SSL, дебютировавший в 1995 году, наконец, в мире появился фундамент для безопасного и безопасного способа ведения бизнеса через Интернет. С тех пор SSL стал единственным наиболее важным протоколом аутентификации, используемым в транзакциях, основанных на Интернете.

Почему необходим SSL? Большинство веб-трафика проходит через Интернет в незашифрованном виде. Это означает, что любой, обладающий достаточными техническими знаниями и инструментами, может легко «подслушивать» разговоры между двумя сторонами. Безопасность SSL шифрует данные, перемещающиеся между веб-сервером и браузером, что чрезвычайно затрудняет перехват и декодирование информации.

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

Именно здесь важна важность сторонней проверки. Сертификат, подписанный доверенным независимым центром сертификации, гарантирует, что организация, владеющая сертификатом, действительно является тем, кем она утверждает. Однако с технической точки зрения проверка подлинности сторонних поставщиков не является существенной для обеспечения безопасности SSL. Организации могут «самостоятельно подписывать» сертификаты. Когда компании используют самоподписанные сертификаты, по сути они говорят: «Я подтверждаю, что я сам. Доверьтесь мне."

Тем не менее, для стандартных веб-браузеров, таких как Internet Explorer и Firefox, эта гарантия не имеет смысла. Пользователи, которые пытаются получить доступ к сайту, «защищенному» самозаверяющим сертификатом, обычно получают сообщение об ошибке, в котором говорится, что подпись подписи неизвестна и не доверена. Неудивительно, что такое сообщение пугает потенциальных клиентов, партнеров и других заинтересованных сторон. По этой причине несколько предприятий будут самостоятельно подписывать внешние веб-сайты. Сохранение доверия пользователей просто слишком важно.

С другой стороны, сайты и серверы, ориентированные на внутреннюю среду, представляют собой другой сценарий использования сценариев SSL. Корпоративные почтовые серверы, человеческие ресурсы (HR) порталы, вики для индивидуального управления проектами, программные средства для разработки программного обеспечения - это всего лишь несколько внутренних сайтов и серверов, которые часто защищены защитой SSL. Действительно ли организациям нужны сторонние подписанные сертификаты, когда только сотрудники получают доступ к этим областям? Еще раз, когда бизнес использует самозаверяющий сертификат, он просит своих сотрудников доверять тому, что его системы безопасны. Даже если они это сделают?

Высокая стоимость инфраструктуры для безопасности SSL

Центры обработки данных и физическая безопасность

Самоподписанные сертификаты по своей сути менее надежны, чем подписанные ведущими центрами сертификации. У авторитетных сторонних ЦС есть надежные процессы, которые помогают гарантировать, что их ключи шифрования, особенно их высокочувствительные частные «корневые» ключи, хранятся в безопасности. Для этих ЦС безопасность всегда является главным приоритетом: Персонал строго проверен и высококвалифицирован, и у этих ЦС есть строгие правила, касающиеся хранения секретных ключей. Фактически, если CA хочет быть одобрен обычными веб-браузерами, эти ключи должны храниться на неиспользуемом хранилище на смарт-картах.

Чтобы обеспечить надежную защиту SSL, ЦС должен также обеспечивать механизмы высокой доступности и отказоустойчивости для предотвращения сбоя системы. Это помогает гарантировать, что он может обеспечить надлежащую аутентификацию по требованию, когда это необходимо пользователям.

Репликация этой инфраструктуры в соответствии с высокими стандартами безопасности в ведущих ЦС требует наличия ряда дорогостоящих компонентов. Во-первых, организация должна иметь репликацию высокой доступности (HA) системы и данных SSL. Второе, связанное с этим требование заключается в том, что эта репликация должна быть достигнута с использованием двух разных безопасных комнат в двух разных центрах обработки данных в двух разных местах. Это помогает гарантировать, что, если один центр обработки данных снизится из-за потери мощности или других непредвиденных факторов, другой будет там, чтобы обеспечить резервную аутентификацию. Без репликации в центрах обработки данных серверы и браузеры не смогут завершить процесс аутентификации, и жизненно важные транзакции, защищенные SSL, такие как покупки кредитных карт на сайте электронной коммерции или загрузка информации о сотрудниках на портал HR, прекратятся.

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

Базовые затраты на безопасный одноцентровый центр обработки данных Colocation с подключением всех подключений и коммунальных услуг могут варьироваться от 1000 долларов США до более чем 10 000 долларов США в месяц. Добавление большего количества стоек, увеличение пропускной способности или использование технической поддержки может еще больше повысить стоимость , часто на сотни долларов. Не только это, но все эти затраты удвоятся, чтобы реплицировать данные в двух центрах обработки данных. Очевидно, что затраты на поддержание физической инфраструктуры и безопасности, необходимые для защиты процессов шифрования и аутентификации SSL, больше, чем могут позволить многие компании.

Компоненты оборудования

Хотя вы можете легко получить бесплатное или очень дешевое программное обеспечение, которое позволит вам создавать самоподписанные SSL-сертификаты, для управления шифрованием вам по-прежнему нужен модуль безопасности оборудования (HSM) для каждого центра обработки данных. И каждый HSM должен будет находиться под контрактом поддержки для обеспечения непрерывности бизнеса.

SSL HSM - это защищенный криптопроцессор - физическое устройство, предназначенное для управления цифровыми ключами и для аутентификации закрытых ключей в системе протокола SSL PKI. HSM имеет три цели. Во-первых, он надежно генерирует открытые и закрытые ключи для шифрования транзакций через Интернет. Во-вторых, он надежно хранит ключи таким образом, чтобы они не были извлечены. В-третьих, это позволяет компаниям управлять чувствительными криптографическими данными.

HSM представляют собой высокоспециализированные аппаратные средства, которые обычно довольно дороги, от 13 000 долл. США на низком уровне до более 30 000 долл. США каждый. Еще раз, для целей репликации и обеспечения высокой доступности любая инфраструктура SSL нуждается в по меньшей мере двух HSM, по одному для каждого дата-центра.

Наконец, компании используют HSM для разгрузки серверов приложений для асимметричной и симметричной криптографии, хотя сегодня это менее актуально. Несмотря на то, что Национальный институт стандартов и технологий (NIST) рекомендует компаниям использовать 2048-разрядные ключи RSA, шифрование SSL существенно не влияет на производительность системы.

Управление и персонал

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

Инструменты, которые позволяют вам самостоятельно подписывать сертификаты, такие как Центр сертификации Microsoft, не включают функции управления сертификатами. Учитывая это, организациям необходимо будет спланировать и внедрить надежные процессы, чтобы гарантировать строгое соблюдение протоколов SSL. Без таких гарантий любой может запросить сертификат SSL и получить его, что, в свою очередь, позволит кому-либо подманить якобы «безопасный» сайт по своему усмотрению.

Во-первых, организации необходимо тщательно контролировать, кто имеет право создавать и подписывать сертификаты для своих доменов, а также устанавливать процессы для обеспечения того, чтобы это было сделано в соответствии с установленными политиками. Такая политика включает в себя требование о том, чтобы только персонал, имеющий достаточный срок пребывания и доверие, имел полномочия создавать и подписывать сертификаты и чтобы они были надлежащим образом обучены передовым методам, стандартам и технологиям. Этот авторитет не следует давать легкомысленно, и необходим четкий контрольный журнал в случае необходимости расследования.

Во-вторых, ведущие сторонние ЦС обычно предлагают веб-приложения с удобными интерфейсами управления, которые автоматизируют и ускоряют многие процессы, включая делегирование полномочий для создания сертификатов и утверждение сертификатов для подписания ЦС. Запросы на подписание сертификатов (CSR) должны в конечном итоге быть одобрены кем-либо, обладающим полномочиями для определенного домена. Надежные ЦС имеют надежные автоматизированные процедуры, чтобы обеспечить, чтобы все это происходило в соответствии с предписаниями.

В-третьих, если организация решает использовать самоподписанные сертификаты, ей понадобятся процессы, аналогичные описанным выше. Некоторые предприятия пытаются автоматизировать рабочий процесс безопасности SSL, создавая собственное программное обеспечение, но многие просто пытаются вручную управлять процессами. Это требует значительного количества времени и усилий от высококвалифицированного и надежного персонала, что может означать более высокооплачиваемых старших сотрудников.

В-четвертых, без инструментов управления и предупреждений, которые часто поступают с сертификатами из доверенного ЦС, организации не будут уведомлены о завершении срока действия сертификатов. Завершение самозаверяющих сертификатов - а также их обновление - необходимо будет отследить вручную, чрезвычайно трудоемкую задачу, которая может отвлечь квалифицированного персонала от других критически важных задач. Стоимость просроченных SSL-сертификатов неприемлемо высока; Сертификаты «изгоев» могут создавать неравномерное пэчворк безопасности, приводя к предупреждающим сообщениям, которые могут негативно повлиять на клиентов и внутренних участников.

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

В конце концов, ключи по существу являются просто файлами, а файловые серверы, виртуальные файловые системы и серверы, а также системы хранения данных (SAN) или системы сетевого хранения (NAS) могут быть скопированы, дублированы и реплицированы. Это затрудняет понимание того, сколько копий ключа существует и где они находятся. Кроме того, сложнее контролировать доступ к ним и более жестко проводить политику.

Когда ключи хранятся на аппаратных средствах, как в HSM, ключи обычно генерируются на этих устройствах, что само по себе означает, что клавиши сильнее - и они никогда не покидают устройство. Это означает, что организации всегда точно знают, где находятся ключи и сколько копий существует. Они могут применять более качественные политики для ключей, так как многие HSM позволяют использовать сильную двухфакторную аутентификацию для доступа на основе политик, например, ограничение подписания сертификатов на те времена, когда присутствуют два уполномоченных лица.

Стоящий персонал, обладающий необходимыми талантами и опытом для выполнения всех этих управленческих задач, является дорогостоящим. Согласно данным ComputerWorld IT Health Survey 2011,2, специалисты среднего звена зарабатывают около 100 000 долларов в год. В зависимости от размера организации расходы на найм даже одного опытного работника могут повысить стоимость самоподписанной безопасности SSL выше разумного порога, особенно по сравнению с затратами на использование доверенного стороннего поставщика SSL.

Компания всегда могла выбрать аутсорсинг управления инфраструктурой, но эта тактика не только добавляет дополнительные затраты, но и вызывает другие ключевые вопросы: кто будет управлять аутсорсером? Что произойдет, если аутсорсер совершит дорогостоящие ошибки? Добавление к этим проблемам, аутсорсерам инфраструктуры, как известно, трудно заменить, учитывая зависимости, которые создают такие отношения.

Технические и бизнес-риски стратегии безопасности SSL-Do-It-Yourself

В дополнение ко всем «жестким» издержкам организация может получать самоподписанные сертификаты SSL, она также сталкивается с повышенными операционными рисками. Несмотря на то, что их трудно определить количественно, эти опасности могут привести к существенным расходам, если они не будут смягчены.

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

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

Хотя истинную ценность доверия трудно оценить количественно, не победить доверие потенциальных клиентов может быть катастрофическим для доходов. Для внутреннего сайта, такого как портал HR, отсутствие доверия среди сотрудников, которые могут задаться вопросом, действительно ли их история зарплат и другие личные данные действительно безопасны, могут повлиять на моральный дух и производительность труда.

Еще один фактор, который следует учитывать, - это гарантийная защита, которую может предоставить сторонний поставщик SSL. Эти гарантии могут варьироваться от 10 000 до 250 000 долларов США (или более) и предназначены для компенсации бизнеса, если происходит нарушение данных. Самоподписанные сертификаты не предоставляют гарантийных гарантий.

Кроме того, риск использования самозаверяющих сертификатов на внутреннем уровне заключается в том, что со временем сотрудники могут игнорировать предупреждения безопасности, данные их браузерами, и начинают добавлять ненадежные сертификаты в хранилище доверенных сертификатов своих браузеров. Это может не только потенциально поставить под угрозу внутренние сети и системы, но также может создать слабое отношение к безопасности в организации и подорвать общую политику, предназначенную для защиты внутренних систем.

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


 DV SSL OV Сертификаты подтверждающие только Домен OV SSL OV Сертификаты подтверждающие Домен и Организацию EV SSL EV Зеленые усиленные сертификаты с указанием названия Организации подтверждают Домен и Организацию WC SSL wildcard Сертификаты защищающие все субдомены. Класс DV OV и EV SAN SSL SAN Мульти доменные  сертификаты защищающие несколько FQDN Доменов. Класс DV OV и EV PRO SSL SGC PRO сертификаты с технологией  Server Gated Cryptography. Класс  OV и EV CodeSign Сертификаты для подписи приложений и програмного кода MS, Java. Класс  OV и EV Email Сертификаты для подписи емаил smime. Класс  DV OV PDF Сертификаты для подписи документов PDF. Класс  OV PV Wi-Fi Сертификаты DigiCert для IoT и Wi Fi IoT Сертификаты DigiCert для IIoT ALL Все сертификаты DigiCert Familie: thawte, GeoTrust, DigiCert Купить сертификат

NO russia - мы не осблуживаем резидентов из россии Copyright © 1997-2024 adgrafics