Сигурност на микроуслуги и уеб приложения

Какво е микроуслуга за оторизация

Микроуслугата за оторизация:

• проверява кой си (автентикация)
• решава какво ти е позволено да правиш (оторизация)
• издава и проверява токени за достъп (JWT и др.)
• често работи като Identity Provider (IdP) или като част от API Gateway

Популярни решения

Keycloak (open-source, от Red Hat)

• Готов сървър за оторизация със собствен админ панел и потребители.
• Поддържа OpenID Connect, OAuth2, SAML
• Издава JWT, управлява сесиите
• Има UI за потребители и администратори
• Поддържа MFA, LDAP, Google Login и др.
• Често се използва като SSO и централна услуга за оторизация

Използва се като:

• /auth услуга
• Свързва се към frontend и backend
• Проверява токените чрез middleware или API Gateway

Auth0 (облачен, комерсиален)

• Готово облачно решение за автентикация и оторизация.
• Лесна интеграция чрез SDK
• Поддържа социални логини, MFA, RBAC
• Издава JWT токени
• Подходящ за SaaS, мобилни приложения и SPA
• Плюсове: бързо, UI-ът е готов
• Минуси: платено, зависи от интернет

OPA (Open Policy Agent) + Keto

• За оторизация по политики (ABAC) – кой, до какво, при какви условия.
• OPA = двигател за правила (езикът Rego)
• Keto = open-source аналог на Google Zanzibar (ACL хранилище)
• Позволява да се проверява: „Може ли потребителят X да прави Y с ресурса Z?“
• Използват се заедно с други услуги
• OPA – изнася бизнес правилата от кода

ORY Stack (Hydra, Kratos, Keto, Oathkeeper)

• Open-source платформа за оторизация
• Hydra – OAuth2 / OIDC сървър (само протоколите)
• Kratos – управление на потребителите (вход, регистрация, email)
• Keto – съхранение на политики (RBAC/ABAC)
• Oathkeeper – API Gateway с оторизация
• Гъвкаво, мощно, но изисква настройка
• Идеално за микроуслугова архитектура

Какво е API Gateway

API Gateway е единна входна точка към всички микроуслуги.
Той приема заявките от клиентите и:

• ги пренасочва към нужната микроуслуга (routing)
• проверява оторизацията (например JWT)
• прави rate-limiting, логване, CORS и т.н.
• Клиентът общува само с Gateway
• Gateway скрива вътрешната структура
• Може да добавя, премахва, преименува хедъри, да проверява токен и т.н.

[Клиент] → [API Gateway] ─→ [Микроуслуга A]
                        └→ [Микроуслуга B]
                        └→ [Auth Service]

Популярни решения

NGINX

• Работи като обратен прокси
• Може да се добави валидация на JWT (чрез Lua, njs и др.)
• Много бърз, лесен за настройка
• Подходящ за low-level настройка (директно през конфига)

Kong

• Изграден върху NGINX
• Архитектура с плъгини (оторизация, лимити, логъри)
• Има UI, REST API, CLI
• Поддържа JWT, OAuth2, rate-limit, CORS, OpenID, gRPC и др.

Traefik

Лесен за използване, особено с Docker/Kubernetes
Автоматично откриване на услуги (K8s ingress, Docker labels)
Поддържа TLS, Let’s Encrypt, JWT, middlewares

Envoy

Мощен прокси от Lyft
Използва се в Istio, gRPC, AWS App Mesh
Поддръжка на мрежа от услуги (service mesh)
Висока производителност и гъвкавост

AWS API Gateway (облачен)

Напълно управлявана услуга от AWS
Интеграция с Lambda, IAM, Cognito, CloudWatch
Поддържа REST, WebSocket, HTTP APIs

Как работят сертификатите

Сертификатът е документ за самоличност за компютри и сървъри.
Той потвърждава, че сървърът е този, за когото се представя, и съдържа неговия публичен ключ.

Сертификатът е файл във формат .crt, .pem, .cer, .der и т.н. Съдържа:

При отваряне на сайт браузърът:
Получава сертификата на сървъра
Проверява дали е подписан от доверен орган (CA)
– например Let's Encrypt, DigiCert, Sectigo и др.
Използва публичния ключ от сертификата, за да:
провери автентичността на сървъра
създаде таен ключ, с който ще бъде криптиран целият трафик
По-нататъшният обмен на данни протича по криптиран канал (TLS)

Къде се използват сертификатите

• HTTPS в сайтовете
• gRPC между микроуслуги
• mTLS (взаимна автентикация на клиента и сървъра)
• OAuth2 / OpenID (подписване на токени чрез RSA/ECDSA)
• Kubernetes (kube-apiserver, kubelet, etcd)
• VPN (WireGuard, OpenVPN)

Какви типове сертификати има

По предназначение:

По структура:

Как да съхраняваме паролите на потребителите

Какво не бива да се прави

• да се съхранява паролата в открит вид (plain text)
• да се криптират паролите, „за да могат да се дешифрират“
• да се използват бързи хешове (MD5, SHA-1, чист SHA-256)

Как трябва да се съхраняват паролите

1. Хешираме паролите, а не ги криптираме<!-- wp:list -->

• Вземаме паролата и я прекарваме през специална бавна функция (KDF).
• Тя прави налучкването на паролата много скъпо.
• Всички проверки да се правят в една auth услуга, а не във всяка микроуслуга.
• Микроуслугите работят само с токени, а не с пароли.

2. Използваме KDF (ключови функции за пароли)<!-- wp:list -->

• Argon2id (най-добрият съвременен вариант, препоръчан от OWASP).
• Ако го няма – bcrypt или scrypt.
• PBKDF2 може да се използва само за съвместимост/държавни стандарти.
• За всяка парола да се генерира собствена сол.

3. Добавяме сол (salt)<!-- wp:list -->

• Уникален случаен низ за всеки потребител.
• Съхранява се заедно с хеша (това е нормално).
• Прави така, че две еднакви пароли на различни хора да имат различни хешове.

4. Може да се добави пипер (pepper)<!-- wp:list -->

• Това е обща тайна.
• Не се съхранява в базата.
• Ако базата е изтекла, а пиперът – не, хешовете са безполезни.
• Пиперът се съхранява отделно (например в KMS или Vault).

5. Съхраняваме резултата във формат с параметри Например, низ за bcrypt:

$2a$12$C6UzMDM.H6dfI/f/IKcEe.7WxoQ5y0CEajliV0z3yFNBPJzXeS.CW

Съдържа:

• алгоритъма (2a)
• сложността (12)
• солта
• самия хеш

Къде да съхраняваме паролите

• В централизирана услуга за оторизация (например Keycloak, AWS Secrets Manager, собствена Auth услуга).
• Останалите микроуслуги не знаят паролите, те проверяват токени (JWT).
• Това намалява риска от изтичане: само една услуга работи с паролите.

Алгоритъм за автентикация

1. Потребителят изпраща логин + парола към услугата за оторизация.
2. Услугата:<!-- wp:list -->

• намира хеша и солта в базата
• хешира изпратената парола със същия алгоритъм
• сравнява със съхранената стойност (constant-time сравнение)

3. Ако съвпадне → издава се JWT токен.
4. Останалите микроуслуги проверяват само токена, а не паролите.

Какво е KMS (Key Management Service)

Услуга, която управлява ключовете за криптиране.
Нейната задача: ключовете да не стоят в твоя код или база, а да се съхраняват на защитено място.
Ти не вземаш ключа, а просто казваш на KMS:

• „Криптирай това“
• „Дешифрирай това“
• „Подпиши това“

Ключът при това не напуска хранилището.

Как работи стъпка по стъпка

1. Създаване на главен ключ

• В KMS се създава главен ключ (Master Key).
• Може да е симетричен (AES) или асиметричен (RSA/ECC).
• Този ключ не може да се изтегли, той винаги остава вътре в KMS.

2. Криптиране на данните

• Ти не криптираш самите големи файлове в KMS (това е скъпо и бавно).
• Вместо това:<!-- wp:list {"ordered":true} -->
  1. KMS генерира data key (временен ключ за криптиране).
  2. Data key се използва в твоето приложение за криптиране на данните (например AES-256).
  3. Самият data key се съхранява при теб в базата, но в криптиран вид (чрез главния ключ на KMS).

3. Дешифриране на данните

• Когато трябва да се прочетат данните:<!-- wp:list {"ordered":true} -->
  1. Изпращаш към KMS криптирания data key.
  2. KMS го дешифрира и връща дешифрирания data key.
  3. Използваш този data key, за да дешифрираш данните при себе си.

Така KMS никога не вижда твоите данни – само ключовете.

Защо това е сигурно

• Ключовете стоят в защитено хранилище (HSM – хардуер за криптография).
• Не управляваш ключовете ръчно, управлява ги KMS.
• Всички действия (кой, кога е криптирал/дешифрирал) се логват.
• Може да се настрои политика: „този ключ може да се използва само от услуга А“.
• Може да се прави ротация на ключовете (нова версия на всеки N дни).

Къде се използва

• AWS KMS (Amazon)
• Google Cloud KMS
• Azure Key Vault (частта за KMS)
• HashiCorp Vault (self-hosted алтернатива)

Какви решения има за защита от brute-force атаки

За защита на микроуслугите и API от brute-force атаки (налучкване на пароли, токени, логини и т.н.) се прилагат стандартизирани решения, както на ниво код, така и на ниво инфраструктура (API Gateway, firewall, reverse proxy и др.). По-долу е систематизиран преглед.

Какво е mTLS

mTLS = Mutual TLS, или „взаимен TLS“.

Обикновеният TLS (HTTPS) работи така:

• Клиентът (браузър, услуга) проверява сертификата на сървъра, за да се убеди, че това е именно този сайт/услуга.
• Сървърът не проверява клиента, достатъчно му е, че клиентът знае парола/токен.

При mTLS проверката е двустранна:

• Сървърът предоставя своя сертификат на клиента.
• Клиентът също предоставя своя сертификат на сървъра.
• И двете страни се проверяват взаимно и се убеждават, че общуват с доверен събеседник.

Как работи стъпка по стъпка

1. Клиентът се свързва към сървъра и започва TLS ръкостискане.
2. Сървърът изпраща своя сертификат → клиентът го проверява (подпис на CA, срок на валидност, CN/SAN).
3. Сървърът в отговор иска сертификат от клиента.
4. Клиентът изпраща своя сертификат → сървърът го проверява по доверения CA.
5. Ако и двата сертификата са валидни → установява се защитена връзка.

Къде се използва mTLS

• Между микроуслуги – за да знае една услуга със сигурност, че към нея се обръща именно доверена услуга, а не злоумишленик.
• В API за B2B – когато компании обменят данни и е нужно да се доверяват не само на парола/токен, но и на сертификата на устройството/услугата.
• В IoT – устройствата се автентикират по сертификати.
• В банковите системи – задължително изискване за защита на каналите.

С какво е полезен mTLS

• Двустранна автентикация (и сървърът, и клиентът са проверени).
• Ключовете никога не се предават, а само се потвърждават със сертификати.
• Удобно за сценарии „machine-to-machine“ (микроуслуги, API, IoT).
• Паролите/токените могат да се заменят със сертификати (или да се използват заедно).

Какви са популярните алгоритми за криптиране и хеширане

Алгоритми за криптиране (encryption)

Симетрични (един ключ за криптиране и дешифриране)

• AES (Advanced Encryption Standard) – най-популярният, стандарт де факто<!-- wp:list -->
  • Режими: AES-GCM (често в TLS), AES-CBC, AES-CTR
  • Дължина на ключа: 128 / 192 / 256 бита
• ChaCha20-Poly1305 – съвременен алгоритъм, алтернатива на AES<!-- wp:list -->
  • По-бърз на мобилни устройства и ARM
  • Използва се в TLS 1.3, WireGuard, услугите на Google

Асиметрични (различни ключове: публичен и частен)

• RSA – класика, широко използван за TLS, подписи, обмен на ключове<!-- wp:list -->
  • Надеждността зависи от дължината на ключа (2048+ бита)
• Elliptic Curve Cryptography (ECC) – по-съвременна и лека<!-- wp:list -->
  • ECDSA (цифров подпис)
  • ECDH / ECDHE (обмен на ключове, използва се в TLS 1.3)
  • Ed25519, Ed448 (подписи, бързи и безопасни)

Алгоритми за хеширане (hashing)

Общи (за данни)

• SHA-2 (SHA-256, SHA-512) – стандарт в повечето системи
• SHA-3 (Keccak) – по-нов стандарт от NIST
• BLAKE2 / BLAKE3 – бързи, съвременна алтернатива на SHA

За съхранение на пароли (специални KDF)

• Argon2id – съвременният победител в Password Hashing Competition, най-добрият вариант в момента
• bcrypt – стар, но все още широко използван
• scrypt – по-добър от bcrypt, но се използва по-рядко
• PBKDF2 – стандартен, но смятан за остаряващ (използва се за съвместимост, FIPS)

Използване

• За криптиране на данни: AES-GCM или ChaCha20-Poly1305
• За обмен на ключове: ECDHE (в TLS 1.3)
• За подписи: ECDSA или Ed25519
• За хеширане на файлове: SHA-256 или BLAKE3
• За пароли: Argon2id (най-добрият избор), или bcrypt/scrypt

Copyright: Roman Kryvolapov