---
title: "Сигурност на микроуслуги и уеб приложения"
url: "https://romankryvolapov.com/bg/microservices-security/"
description: "Микроуслуга за оторизация, API Gateway, mTLS и сертификати: как да съхраняваме паролите безопасно, как да се защитим от brute-force и кои алгоритми за криптиране да изберем."
language: bg
published: 2024-08-26
updated: 2026-11-13
---
## Какво е микроуслуга за оторизация

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

- проверява кой си (автентикация)
- решава какво ти е позволено да правиш (оторизация)
- издава и проверява токени за достъп (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 с оторизация
- Гъвкаво, мощно, но изисква настройка
- Идеално за микроуслугова архитектура

| Име | Валидация | Автентикация | Политики (ABAC) | UI / Админ панел | Open-source |
| --- | --- | --- | --- | --- | --- |
| **Keycloak** | ✅ JWT | ✅ Да | ⚠️ Ограничено | ✅ Да | ✅ Да |
| **Auth0** | ✅ JWT | ✅ Да | ⚠️ Ограничено | ✅ Да | ❌ Не |
| **OPA + Keto** | ⚠️ Чрез API | ❌ Не | ✅ Много гъвкаво | ❌ Не | ✅ Да |
| **ORY Stack** | ✅ Да | ✅ Да | ✅ Да | ✅ Да | ✅ Да |
| **Firebase** | ✅ Да | ✅ Да | ❌ Не | ✅ Да | ❌ Не |

## Какво е API Gateway

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

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

```text
[Клиент] → [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 и т.н. Съдържа:

| Поле | Значение |
| --- | --- |
| Subject | На кого е издаден (домейн, име на сървъра и т.н.) |
| Issuer | Кой го е издал (CA – удостоверяващ орган) |
| Public Key | Публичен ключ на сървъра |
| Valid From / To | Срок на валидност |
| Signature | Подпис на удостоверяващия орган |
| Serial Number | Уникален ID на сертификата |

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

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

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

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

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

| Тип | За какво се използва |
| --- | --- |
| **Сървърен сертификат (SSL/TLS)** | За HTTPS, защитава сайтове и API |
| **Клиентски сертификат** | За проверка на самоличността на клиента (например mTLS) |
| **Сертификат за подписване на код** | За подписване на програми (например .exe, .apk) |
| **Email сертификат (S/MIME)** | За подписване и криптиране на email съобщения |
| **PKI сертификат в AD** | За Windows/LDAP оторизация |

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

| Тип | Описание |
| --- | --- |
| **Root Certificate** | Коренов, инсталира се в системата (Windows, браузър) |
| **Intermediate CA** | Междинен, подписва потребителските сертификати |
| **Leaf / End-entity** | Самият сертификат на сайта/услугата/потребителя |

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

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

- да се съхранява паролата в открит вид (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:

```text
$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 и др.). По-долу е систематизиран преглед.

| Подход | Ниво | Накратко |
| --- | --- | --- |
| **Rate limiting** | Gateway / Service | Ограничаване на броя заявки за период от време |
| **CAPTCHA / Proof-of-work** | UI / Backend | Защита от ботове, увеличава цената на атаката |
| **Account lockout** | Backend / DB | Блокиране след X неуспешни опита |
| **Exponential backoff** | Backend | Увеличаване на паузата между опитите |
| **IP blacklist / geo-fencing** | Gateway | Блокиране на подозрителни източници |
| **Device fingerprinting** | Backend / Frontend | Контекстна оценка (ново устройство → challenge) |
| **Behavioral analysis** | Security service | Анализ на аномалии |
| **WAF (Web Application Firewall)** | Infra | Защита от автоматизирани атаки |

## Какво е 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](https://t.me/RomanKryvolapov)