Введение: Важность безопасной связи в микросервисах

В то время как микросервисы повышают масштабируемость и гибкость современных архитектур программного обеспечения, обеспечение безопасной связи между сервисами становится сложной задачей. Традиционно используемый односторонний TLS (Transport Layer Security) обычно шифрует связь от клиента к серверу и проверяет личность сервера. Однако в микросервисных архитектурах взаимная аутентификация обеих сторон (сервисов, действующих как клиент и сервер) является фундаментальной для реализации принципов "нулевого доверия" (Zero Trust) и предотвращения потенциальных атак по сторонним каналам.

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

Что такое Mutual TLS (mTLS) и почему он критически важен для микросервисов?

Mutual TLS (mTLS) — это расширение стандартного протокола TLS. В обычном TLS, когда клиент (например, веб-браузер) подключается к серверу (например, веб-сайту), только сервер доказывает свою личность клиенту с помощью своего цифрового сертификата. В mTLS этот процесс двунаправленный: после того как клиент проверяет личность сервера, сервер также запрашивает у клиента представление его собственного цифрового сертификата и проверяет его. Таким образом, и сервер, и клиент взаимно подтверждают надежность друг друга.

Жизненно важное значение mTLS в микросервисных архитектурах можно суммировать в нескольких пунктах:

• Надежная аутентификация: Обеспечивает гораздо более надежный механизм аутентификации с использованием криптографических сертификатов вместо простой аутентификации на основе пароля/ключа API.
• Архитектура нулевого доверия: Позволяет реализовать принципы "нулевого доверия", при которых каждому сервису по умолчанию не доверяют, и каждое сообщение требует аутентификации и авторизации.
• Безопасность внутренней сети: Обеспечивает защиту от атак по сторонним каналам или несанкционированного доступа к сервисам внутри внутренней сети. Даже если злоумышленник проникнет в вашу сеть, его доступ к сервисам, защищенным mTLS, будет предотвращен.
• Целостность и конфиденциальность данных: Гарантирует конфиденциальность и целостность данных путем сквозного шифрования всей межсервисной связи.

Как работает mTLS: Пошаговый поток связи

Процесс рукопожатия mTLS включает следующие шаги:

1. Клиент инициирует соединение: Клиент отправляет запрос на TLS-соединение (Client Hello) серверу.
2. Сервер представляет свой сертификат: Сервер отвечает своим цифровым сертификатом, цепочкой сертификатов и предпочтительными наборами шифров (Server Hello, Certificate, Server Key Exchange). На этом этапе сервер также отправляет запрос на клиентский сертификат (Certificate Request).
3. Клиент проверяет сервер: Клиент проверяет личность сервера, сравнивая сертификат сервера со своим списком доверенных Центров сертификации (ЦС).
4. Клиент представляет свой сертификат: Клиент отвечает своим собственным цифровым сертификатом, цепочкой сертификатов и цифровой подписью (Certificate, Client Key Exchange, Certificate Verify).
5. Сервер проверяет клиент: Сервер проверяет личность клиента, сравнивая представленный клиентом сертификат со своим списком доверенных Центров сертификации (ЦС).
6. Устанавливается безопасная связь: После того как обе стороны успешно проверят личности друг друга, они договариваются о зашифрованном сеансовом ключе, и начинается безопасная связь.

Шаги реализации: Настройка нашей собственной инфраструктуры mTLS

В этом разделе мы рассмотрим практические шаги от создания базового Центра сертификации (ЦС) до генерации сертификатов для сервисов и их настройки на Nginx.

1. Создание Центра сертификации (ЦС)

Давайте создадим корневой ЦС (Root CA), которому будут доверять все наши сервисы. Этот ЦС будет подписывать как серверные, так и клиентские сертификаты.

# Генерация ключа для ЦСopenssl genrsa -aes256 -out ca.key 4096# Создание корневого сертификата с использованием ключа ЦСopenssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 -out ca.crt -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Security/CN=Root CA"

Эти шаги создают файлы ca.key (закрытый ключ ЦС) и ca.crt (открытый сертификат ЦС). Файл ca.crt будет принят всеми сервисами как доверенный.

2. Создание серверного сертификата

Теперь давайте сгенерируем сертификат для нашего серверного сервиса (например, API Gateway или микросервиса), который будет защищен mTLS.

# Генерация ключа для сервераopenssl genrsa -out server.key 2048# Создание запроса на подпись сертификата (CSR) для сервераopenssl req -new -key server.key -out server.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Backend/CN=api.mycompany.com"# Подписание CSR с помощью ЦС и создание серверного сертификатаopenssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 365 -sha256 -extfile 
subjectAltName=DNS:api.mycompany.com,IP:127.0.0.1

Здесь генерируются файлы server.key (закрытый ключ сервера) и server.crt (сертификат сервера, подписанный ЦС). Убедитесь, что поле CN (Common Name) соответствует доменному имени сервера. subjectAltName (SAN) также важен.

3. Создание клиентского сертификата

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

# Генерация ключа для клиентаopenssl genrsa -out client.key 2048# Создание запроса на подпись сертификата (CSR) для клиентаopenssl req -new -key client.key -out client.csr -subj "/C=TR/ST=Istanbul/L=Istanbul/O=MyCompany/OU=Frontend/CN=client-service"# Подписание CSR с помощью ЦС и создание клиентского сертификатаopenssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 365 -sha256

В результате этих шагов получаются файлы client.key и client.crt.

4. Настройка mTLS на стороне сервера Nginx

Давайте настроим Nginx для проверки сертификатов от клиента. Добавьте следующий блок server в файл конфигурации Nginx:

server {    listen 443 ssl;    server_name api.mycompany.com;    ssl_certificate /etc/nginx/ssl/server.crt;    ssl_certificate_key /etc/nginx/ssl/server.key;    # Сертификат ЦС для проверки клиентских сертификатов    ssl_client_certificate /etc/nginx/ssl/ca.crt;    # Требовать и проверять клиентский сертификат    ssl_verify_client on;    location / {        # Перенаправление запроса после успешной проверки        proxy_pass http://backend_service;        proxy_set_header Host $host;        proxy_set_header X-Real-IP $remote_addr;        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;        proxy_set_header X-Forwarded-Proto $scheme;    }    error_page 495 496 497 =403 /403.html;    location = /403.html {        return 403 "403 Forbidden: Client Certificate Required";    }}

В этой конфигурации мы указываем доверенный сертификат ЦС с помощью ssl_client_certificate и принуждаем проверку клиентского сертификата с помощью ssl_verify_client on. Если проверка не удастся, Nginx вернет ошибку 400 (Bad Request) или 403 в зависимости от вашей конфигурации.

5. Запрос mTLS на стороне клиента с помощью cURL

Давайте отправим запрос на наш сервер Nginx, используя клиентские сертификаты:

curl --cert client.crt --key client.key --cacert ca.crt https://api.mycompany.com/secure-endpoint

В этой команде:

• --cert client.crt: Открытый сертификат клиента.
• --key client.key: Закрытый ключ клиента.
• --cacert ca.crt: Сертификат ЦС, который будет использоваться для проверки сертификата сервера.

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

Лучшие практики и дополнительные меры безопасности

• Ротация сертификатов: Регулярно обновляйте сертификаты до истечения их срока действия. Использование автоматизированных инструментов управления сертификатами упрощает этот процесс.
• Безопасность ЦС: Храните закрытый ключ вашего корневого ЦС в чрезвычайно безопасной среде и ограничивайте доступ только для операций подписи сертификатов.
• Отзыв сертификатов: Отзывайте скомпрометированные или более неиспользуемые сертификаты с помощью списков отзыва сертификатов (CRL) или протокола онлайн-статуса сертификатов (OCSP).
• Надежные наборы шифров: На ваших серверах, таких как Nginx, включайте только надежные наборы шифров TLS и отключайте слабые.
• Централизованное управление сертификатами: В крупных микросервисных средах рассмотрите возможность использования специализированных решений (например, инфраструктуры PKI) для централизованного и безопасного управления сертификатами и закрытыми ключами.

Заключение

Mutual TLS (mTLS) — это мощный механизм, который значительно повышает безопасность межсервисного взаимодействия в микросервисных архитектурах. Следуя шагам, изложенным в этом руководстве, разработчики могут настроить свою собственную инфраструктуру mTLS и создать сквозные зашифрованные и взаимно аутентифицированные каналы связи, соответствующие принципам "нулевого доверия". Помните, что безопасность — это непрерывный процесс, и регулярное внимание к управлению сертификатами, их ротации и отзыву имеет решающее значение для поддержания надежности ваших систем.