Уровни доверия и SSL/TLS

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Инженеру

Уровни доверия и SSL/TLS

Уровни доверия:

Уровень	Применение	Пример
Высокий	Банки, государственные системы, критически важные инфраструктуры	Двухфакторная аутентификация (2FA), использование HSM-ключей для защиты секретов
Средний	Корпоративные порталы, внутренние CRM и ERP-системы	Комбинация пароля и одноразового кода по SMS или из приложения
Низкий	Блоги, форумы, публичные ресурсы с минимальными требованиями к безопасности	Аутентификация по простому паролю без дополнительных факторов

SSL / TLS – процесс шифрования трафика между клиентом и сервером. Браузер при установлении показывает значок замка и https://. Для проверки используется сертификат:

DV (Domain Validation) – базовый (проверка домена);
OV (Organization Validation) – проверка компании;
EV (Extended Validation) – максимальная проверка.

Play ITЗагрузка интерактивного демо…

Методы проверки подлинности

Основные методы

Метод	Как работает?	Плюсы/Минусы
Логин и пароль	Проверка учётных данных на сервере по базе данных (хешированных паролей)	Плюсы: Простота реализации и использования. Минусы: Уязвимость к подбору, фишингу, необходимость безопасного хранения.
OAuth 2.0	Пользователь аутентифицируется через стороннего провайдера (Google, Facebook и др.), приложение получает токен доступа	Плюсы: Удобство для пользователя, снижение нагрузки на разработчика. Минусы: Зависимость от внешнего провайдера, передача части контроля.
JWT (JSON Web Tokens)	Токен в формате JSON, подписанный сервером; содержит данные (например, роль, срок действия); хранится у клиента	Плюсы: Отсутствие состояния на сервере, высокая масштабируемость. Минусы: Невозможность отзыва до истечения срока (без дополнительных механизмов).
Биометрия	Идентификация по уникальным биологическим признакам: отпечаток пальца, распознавание лица (Face ID)	Плюсы: Высокая степень защиты от несанкционированного доступа. Минусы: Требует специализированного оборудования, сложности с восстановлением при изменении данных.

JWT и сессии

Критерий	JWT	Сессии
Место хранения состояния	На стороне клиента (в токене)	На стороне сервера (в session store, например Redis)
Масштабируемость	Высокая — не требует общего хранилища сессий	Ниже — требует централизованного хранилища (например, Redis) для работы в кластере
Безопасность	Зависит от стойкости алгоритма подписи и секрета	Зависит от защиты session ID и надёжности серверного хранилища

Верификация подлинности

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

Электронная почта остаётся одной из самых уязвимых и активно эксплуатируемых точек входа в информационные системы. Фишинг, спуфинг, рассылка вредоносного ПО и бизнес-электронное мошенничество (BEC) часто основаны на подделке адреса отправителя. Для противодействия этим угрозам были разработаны стандартизированные механизмы проверки подлинности писем на уровне DNS и криптографии: SPF и DKIM. Они являются фундаментальными компонентами современной инфраструктуры доверия в email-коммуникациях и обязательны к внедрению для любого домена, отправляющего почту.

Sender Policy Framework (SPF)

Назначение

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

Принцип работы

Администратор домена публикует в DNS TXT-запись вида:

   v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.123 include:_spf.google.com -all

Эта запись означает: "Письма от @example.com могут быть отправлены только с IP-адресов 192.0.2.0/24, 198.51.100.123 или серверов Google Workspace".

При получении письма принимающий MTA (Mail Transfer Agent):
- извлекает домен из envelope sender (обычно поле Return-Path);
- запрашивает SPF-запись для этого домена в DNS;
- сравнивает IP-адрес отправившего сервера с разрешёнными в записи.
Результат проверки может быть:
- pass — адрес авторизован;
- fail (-all) — явный запрет;
- softfail (~all) — временный отказ (для отладки);
- neutral (?all) — без указания политики.

Ограничения SPF

Не работает при пересылке — если письмо пересылается через третью систему (например, корпоративный фильтр), envelope sender может измениться, и проверка провалится.
Не проверяет поле From:, отображаемое пользователю. Это критически важно: злоумышленник может подделать From: ceo@yourcompany.com, даже если envelope sender — другой домен. Поэтому SPF должен использоваться вместе с DMARC, который связывает проверку с видимым адресом отправителя.

DomainKeys Identified Mail (DKIM)

Назначение

DKIM — это криптографический механизм, позволяющий подписывать письма цифровой подписью и подтверждать, что:

письмо действительно отправлено с авторизованного сервера домена;
содержимое письма (включая заголовки) не было изменено в пути.

Принцип работы

Отправляющий сервер:
- выбирает набор заголовков для подписи (например, From, Subject, Date);
- генерирует хэш от тела письма и выбранных заголовков;
- подписывает хэш закрытым ключом;
- добавляет в письмо заголовок DKIM-Signature, содержащий:
  - домен (d=);
  - селектор ключа (s=);
  - алгоритм подписи;
  - подпись.
Принимающий сервер:
- извлекает из DKIM-Signature домен и селектор;
- запрашивает в DNS TXT-запись по имени {selector}._domainkey.{domain};
- получает открытый ключ;
- проверяет подпись с помощью этого ключа.

Пример DNS-записи DKIM:

google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

Преимущества DKIM

Целостность: любое изменение тела или подписанных заголовков делает подпись недействительной.
Независимость от маршрута: работает при пересылке, так как подпись не зависит от envelope sender.
Доверие: крупные почтовые провайдеры (Gmail, Outlook) повышают репутацию доменов с корректной DKIM-подписью.

Важные нюансы

Подпись не шифрует письмо — она только гарантирует его неизменность и источник.
Ключи должны регулярно ротироваться (рекомендуется раз в 3–6 месяцев).
Не проверяет, имел ли отправитель право отправлять от имени домена — только то, что письмо прошло через систему, владеющую закрытым ключом.

SPF и DKIM в совокупности — необходимость DMARC

Ни SPF, ни DKIM по отдельности не защищают пользователя от подделки отображаемого адреса отправителя (From:). Для объединения политик и принятия решений на основе результатов SPF/DKIM используется DMARC (Domain-based Message Authentication, Reporting & Conformance).

DMARC позволяет владельцу домена:

указать, какие механизмы (SPF, DKIM или оба) требуются для прохождения аутентификации;
задать политику обработки писем, не прошедших проверку (none, quarantine, reject);
получать агрегированные и детальные отчёты от почтовых провайдеров.

Пример DMARC-записи:

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

Только при наличии всех трёх компонентов — SPF + DKIM + DMARC — достигается эффективная защита от спуфинга и фишинга.

Как читать SSL/TLS "по-взрослому"

Чтобы тема не оставалась только на уровне определений, полезно смотреть на TLS как на рабочий процесс с конкретными проверками.

Что происходит при подключении к HTTPS

Клиент и сервер согласуют версию TLS и набор шифров.
Сервер отправляет сертификат и цепочку доверия.
Клиент проверяет:
- срок действия сертификата;
- соответствие домена;
- доверенный центр сертификации;
- отсутствие явного отзыва.
После успешной проверки поднимается защищённый канал.

Если проверка провалена, соединение считается недоверенным, даже если "замок" визуально есть в тестовом окружении.

Практический минимум для проекта

Включать только TLS 1.2 и TLS 1.3.
Использовать современные cipher suites, отключать legacy-наборы.
Настроить HSTS для публичных доменов.
Автоматизировать продление сертификатов.
Вести журнал ошибок TLS и разбирать причины.

Частые ошибки внедрения

Сертификат выпущен корректно, но промежуточные сертификаты не отданы сервером.
Сертификат стоит только на основном домене, а поддомены работают с ошибками.
TLS настроен на балансировщике, но внутренний трафик между сервисами остаётся открытым.
Почтовый домен не настроен по SPF/DKIM/DMARC, из-за чего портится репутация отправителя.

Мини-чек-лист для ревью

Сертификат валиден на все используемые домены.
Протоколы SSLv3/TLS 1.0/TLS 1.1 отключены.
Внутренние и внешние API используют HTTPS.
Для почтовой инфраструктуры опубликованы SPF, DKIM и DMARC.
Секретные ключи не хранятся в репозитории.

Уровни доверия и SSL/TLS