Открыть список
Как стать автором
Обновить
0
Рейтинг
Usedesk
Cервис для поддержки и общения с клиентами

Лучшая практика развертывания SSL/TLS, часть 1. Теория

UsedeskИнформационная безопасность
Перевод
Tutorial
Автор оригинала: Ivan Ristić
Часть 2

Делимся переводом полезной статьи о том, как правильно развернуть SSL/TLS на вашем сайте. Сегодня — теория, вторая (практическая) часть будет после запуска.

Введение


SSL/TLS обманчиво кажется простой технологией. Он прост в развертывании, а потом он просто работает, не обеспечивая достаточного уровня безопасности. Но основная проблема заключается в том, что SSL/TLS нелегко правильно развернуть. Для того чтобы TLS обеспечивал необходимый уровень безопасности, системные администраторы и разработчики должны приложить дополнительные усилия в настройке своих серверов и в разработке приложений.

В 2009 году Qualys SSL Labs начала работу с SSL. Они хотели понять, как использовался TLS, и восполнить недостаток простых в использовании инструментов TLS, а также их документации. С помощью глобального исследования использования TLS, а также при помощи онлайновых инструментов оценки Qualys SSL Labs добилась некоторых своих целей. Но отсутствие документации по-прежнему дает о себе знать. Этот документ является шагом на пути к решению этой проблемы.

1. Приватный ключ и сертификат

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

1.1 Используйте 2048-битные закрытые ключи

Используйте 2048-битный RSA или 256-битные ECDSA закрытые ключи для всех ваших серверов. Ключи такой крепости безопасны и будут оставаться безопасными в течение значительного периода времени. Если у вас есть 1024-битные RSA ключи, то следует заменить их более сильными ключами как можно скорее.

1.2 Защитите закрытый ключ

Относитесь к закрытым ключам как к важным активам, предоставляя доступ к как можно меньшей группе сотрудников. Рекомендуемые меры:

• Генерируйте закрытые ключи и запросы на сертификат (CSRs) на доверенном компьютере. Некоторые CA предлагают генерацию ключей и CSRs для вас, но это нецелесообразно.

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

• После компрометации отзывайте старые сертификаты и генерируйте новые ключи.

• Обновляйте сертификаты каждый год и всегда с новыми закрытыми ключами.

1.3 Обеспечьте охват всех используемых доменных имен

Убедитесь, что ваши сертификаты охватывают все доменные имена, которые вы хотите использовать на сайте. Например, у вас есть главный домен www.example.com, но вы также используете домен www.example.net. Ваша цель — избежать предупреждения о недействительности сертификата, которое будет путать ваших пользователей и ослаблять их доверие.

Даже тогда, когда на сервере настроено только одно доменное имя, нужно иметь в виду, что вы не можете контролировать, как пользователи приходят к вам на сайт или какие ссылки на него указывают. В большинстве случаев, вы должны убедиться, что сертификат работает с и без WWW (например, как для example.com и www.example.com). Безопасный веб-сервер должен иметь сертификат, действительный для каждого настроенного доменного имени. Сертификаты на весь домен (Wildcard) имеют свое преимущество, но следует избегать их, если их использование означает предоставление закрытого ключа большой группе людей, например, системным администраторам разных организации. Кроме того, имейте в виду, что Wildcard сертификаты могут быть использованы злоумышленниками для передачи уязвимости от одного веб-сайта на все другие сайты, которые используют один и тот же сертификат.

1.4. Приобретайте сертификаты у надежного удостоверяющего центра

Выбирайте надежный удостоверяющий центр (CA), который заботиться о своем бизнесе и безопасности. Рассмотрим следующие критерии при выборе CA:

Отношение к безопасности

Все CA проходят регулярный аудит (иначе они не имели бы право работать как CA), но некоторые из них более серьезно относятся к безопасности, чем другие. Выяснить, какие из них лучше в этом отношении нелегко, но один способов заключается в изучении их истории инцидентов безопасности и выявлении того, как они реагировали на компрометации и инциденты безопасности и учились ли они на своих ошибках.
Основное направление деятельности

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

Предлагаемые услуги

Как минимум, выбранный CA должен обеспечивать поддержку списка отозванных сертификатов (CRL) и протокола OCSP.

Инструменты управления сертификатами

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

Поддержка

Выберите центр сертификации, который предоставляет хорошую поддержку, когда это необходимо.

1.5. Используйте надежные алгоритмы подписи сертификата

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

Вам нужно немедленно заменить все ваши сертификаты, использующие алгоритм SHA1, если они истекают после 2015 года.
Теги:ssl/tlsинформационная безопасность
Хабы: Usedesk Информационная безопасность
Всего голосов 15: ↑8 и ↓7 +1
Просмотры15.1K

Похожие публикации

Лучшие публикации за сутки

Информация

Дата основания
Местоположение
Россия
Сайт
usedesk.ru
Численность
2–10 человек
Дата регистрации

Блог на Хабре