К использованию SSL для защиты передаваемых через Интернет данных все относятся по-разному: кто-то пренебрегает и гоняет даже пароли пользователей в незашиврованном виде, а у кого-то паранойя и он готов пройти через все круги ада для получения Extended Validation сертификата от крупного вендора. В результате в народе рождаются различные мифы по этой тематике, которые я и предлагаю сегодня обсудить.
МИФ №1: Использование HTTPS - гарантия безопасности сайта
Вроде бы все просто: все данные передаются между сервером и браузером в зашифрованном виде и украсть их "по пути" невозможно. На практике же запросто могут возникать нюансы...
Во-первых сам ключ: в большинстве компаний он просто лежит на жестком диске веб-сервера и доступен если не каждому сотруднику, то каждому системному администратору точно (причем вместе с паролем - перезапускать HTTP-сервера начальству же не положено). Про потенциальный ущерб от попавшего не в те руки SSL-сертификата более-менее серьезной интернет-компании, наверное, рассказывать не стоит - у всех и так хватит воображения.
Решением чаще всего становится использование аппаратных решений (так называемых HSM), соответствующих стандарту FIPS 140-2. Они предотвращают как несанкционированный доступ к ключам, так и любые формы его экспорта в незашифрованном виде (даже при резервном копировании и смене аппаратных модулей).
Вторым моментом, на который стоит обратить внимание, является тот факт, что шифрования трафика защищает только от перехвата данных: вирусы, фишинг и опасный для пользователей код остаются таковыми даже в зашифрованном виде. Если сайт генерирует вредоносные ответы через HTTPS они попадут в браузеры пользователей-жертв еще более безопасно для себя :) В такой ситуации маршрутизаторы с защитой от вторжения (IDS/IPS) и прочие системы безопасности, основанные на "глубоком анализе пакетов", становятся бессильными, если не настроить дешифрование и повторное шифрование.
Для избежания подобных казусов максимальное внимание стоит уделять работе отдела QA, грамотной настройке всех компонентов инфраструктуры и регулярным проверкам на предмет возможных эксплойтов на сайте.
МИФ №2: SSL сегодня не является значительной статьей расходов серверных вычислительных ресурсов
Если бы это было так, то F5, Juniper, Cisco и прочие не ставили бы такие ценники на свои решения. Да, вычислительные мощности среднестатистического сервера растут не по дням, а по часам, но эти же самые вычислительные ресурсы используются и для взлома сертификатов. Не смотря на то, что на взлом 1024-битного ключа по-прежнему требуются многие годы и неплохие финансовые вложения, NIST рекомендует переходить на более криптостойким решениям (от 2048 бит), так как теоретически подбор 1024-битного ключа сейчас вполне возможен.
Для разгрузки центрального процессора веб-серверов существует два основных пути:
- SSL-акселерация на уровне маршрутизатора (чаще всего от вышеупомянутых вендоров)
- Использование HSM с встроенным криптографическим процессором
Вопрос вычислительных мощностей сегодня решается очень лекго, были бы деньги.
МИФ №3: Расходы на управление сертификатами не растут с увеличением количества веб-серверов
Вполне очевидно, что чем больше веб-серверов используется, тем больше SSL-сертификатов должно быть установлено. Еще дополнительные SSL-сертификаты возникают и когда используется несколько виртуальных хостов на одном сервере. До до сих пор часто встречаются люди, которые не знают, что веб-сервер не может определить каким ключом расшифровывать запрос, если на одном IP-адресе расположены несколько доменов, использующих SSL.
Чтобы позволить спокойно масштабировать HTTP-уровень веб-приложения, необходимо рано прерывать HTTPS-соединение для определения сервера, где запрос будет собственно обработан. Такую архитектуру намного легче поддерживать, так как нет необходимости конфигурировать абсолютно каждый HTTP-сервер с отдельными IP-адресами для каждого шифруемого поддомена.
Особенно это актуально для виртуализированных окружений: облачные решения подразумевают наличие образа операционной системы, полностью готового к работе после автоматического старта, настройка SSL в таком случае достаточно проблематична даже в обычном режиме, не говоря уже об использование аппаратных модулей.
Заключение
Полностью технический подход к архитектурным решениям, касающихся использования как SSL, так и других технологий, чаще всего абсолютное неприемлем для ИТ-организаций, пытающихся соответствовать требованиям бизнеса. Подобные решения могут сильно влиять на возможность компании разрабатывать, развертывать и контролировать бизнес приложения и решения. Они не могут приниматься чисто из технических или бизнес соображений, только полностью понимая все аспекты можно сделать верный шаг.
Вообще мифы получились достаточно спорные, но на эту тему недавно прошла довольно горячая волна дискуссии в западной блогосфере, даже с участием довольно крупных игроков в этой сфере (в частности F5). Может быть у читателей Insight IT тоже найдется что добавить, жду в комментариях :)
По традиции напоминаю про подписку на обновления.
