Механизмы аутентификации для микросервисной архитектуры

"Что такое микросервисы" мы на собеседованиях уже научились отвечать, поэтому такие базовые вопросы встречаются всё реже. Но лично меня все чаще просят рассказать о безопасных и эффективных способах аутентификации между теми самыми микросервисами.

Погнали разбираться. Будет тезисно + я нашел для вас картиночку на просторах ЛинкедИна.

1. API-ключи
◾️ Простые уникальные идентификаторы, назначаемые каждому клиенту или сервису.
◾️ Передаются в заголовке или параметре запроса при каждом обращении.
◾️ Подходят для внутренних сервисов, API с низкими требованиями к безопасности или для предоставления доступа к определённым функциям.
◾️ Легко внедрять и управлять ими.
◾️ Менее безопасны, чем методы на основе токенов. Ключи могут быть легко украдены или скомпрометированы.

2. Базовая аутентификация (Basic Auth)
◾️ Логин и пароль отправляются в заголовке `Authorization` в виде строки, закодированной в base64.
◾️ Простая реализация, но требует использования HTTPS для безопасности.
◾️ Подходит для сценариев с низкими требованиями к защите.
◾️ Широко поддерживается и проста для понимания.
◾️ Уязвима к атакам «человек посередине» без HTTPS.
◾️ Пароли передаются в открытом виде (даже в закодированной форме).

3. JSON Web Tokens (JWT)
◾️ Самостоятельные токены, содержащие информацию о пользователе и параметры (claims) в формате JSON.
◾️ Выдаются сервером аутентификации после успешного входа, затем клиент отправляет их в заголовке `Authorization`.
◾️ Часто используются для статусной аутентификации в микросервисах, едином входе (SSO) и авторизации.
◾️ Без состояния, безопасны, компактны и могут включать дополнительные данные.
◾️ Требуют правильного управления ключами для подписи и проверки.

4. OAuth 2.0
◾️ Фреймворк авторизации, позволяющий сторонним приложениям получать ограниченный доступ к ресурсам от имени пользователя без передачи его учётных данных.
◾️ Использует типы разрешений (authorization code, implicit, client credentials и др.) для получения токенов доступа и токенов обновления.
◾️ Широко применяется для делегированного доступа к API.
◾️ Стандартизированный способ защиты ресурсов без раскрытия паролей.
◾️ Сложен в реализации, требует учёта уязвимостей (например, CSRF).

5. OpenID Connect (OIDC)
◾️ Слой идентификации поверх OAuth 2.0, добавляющий аутентификацию и данные профиля пользователя.
◾️ Использует ID-токен вместе с токеном доступа для подтверждения личности.
◾️ Комбинируется с OAuth 2.0: аутентификация через OIDC, авторизация через OAuth.
◾️ Упрощает аутентификацию благодаря стандартизированному формату.
◾️ Требует интеграции с провайдером OIDC (например, Google, Okta).

6. Mutual TLS (mTLS)
◾️ Клиент и сервер аутентифицируют друг друга с помощью сертификатов X.509.
◾️ Требует центра сертификации (CA) для выпуска и управления сертификатами.
◾️ Идеален для защиты коммуникации между внутренними сервисами или API с высокой секретностью.
◾️ Высокая безопасность за счёт взаимной аутентификации и шифрования.
◾️ Сложнее в настройке и управлении по сравнению с другими методами.

#BaseSecurity #SecArch

🧠 Твой Пакет Знаний | 👨‍🏫 Менторство ИБ
📂 Другие каналы

Стэнфордский курс без регистрации и СМС

Я тут на одной из страниц по стажировке в ИБ заметил в подготовительных материалах курс одного из ведущих мировых университетов. Собственно, делюсь – ссылка

Это курс Стэнфорда по веб-безопасности со всеми материалами, ссылками и презентациями. Я бы не сказал, что там вау как интересно, но и глубоко не всматривался. Для базового уровня точно сойдет.

#BaseSecurity

🧠 Твой Пакет Знаний | 👨‍🏫 Менторство ИБ
📂 Другие каналы

Продолжаем тему безопасности микросервисной архитектуры. Сегодня у нас на очереди годная статья от одного известного в узких кругах безопасника про Service Mesh и про то, как его приручить – ссылка

Там и про Istio, и про mTLS, и про то, как все это провернуть в реальной жизни.

#DevSecOps #BaseSecurity

🧠 Твой Пакет Знаний | 👨‍🏫 Менторство ИБ
📂 Другие каналы