# IAM и управление доступом

← [Раздел](README.md) · [Главная](../README.md)

## Цель

Разобрать **аутентификацию** и **авторизацию**, роли пользователей и сервисов, RBAC и принцип наименьших привилегий в облаке.

## Предварительно

- [Модель угроз](model-ugroz.md)

## Время

**3–4 часа**

---

## Два разных вопроса

| | Аутентификация (AuthN) | Авторизация (AuthZ) |
|---|------------------------|---------------------|
| Вопрос | **Кто** ты? | **Что** тебе можно? |
| Пример | Логин + пароль → JWT | Можно ли удалить list_id=5? |
| Ошибка HTTP | 401 Unauthorized | 403 Forbidden |

Путаница 401/403 — частая ошибка в API и документации.

---

## Пользовательская аутентификация

| Механизм | Когда |
|----------|-------|
| Email + пароль | Классика MVP |
| OAuth2 / OIDC | «Войти через Google», корпоративный SSO |
| Magic link | Без пароля, email как фактор |
| MFA (TOTP, WebAuthn) | Повышенная защита |

**Не изобретайте** криптографию паролей — bcrypt/argon2, готовые библиотеки.

---

## Токены: сессия vs JWT

| Session cookie | JWT (Bearer) |
|----------------|--------------|
| Сервер хранит сессию | Самодостаточный payload + подпись |
| Легко отозвать | Нужен blacklist или короткий TTL |
| Удобен для web same-site | Удобен для mobile API |

```http
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
```

Короткий **access token** (15 мин) + **refresh token** (дни) — распространённый компромисс.

---

## Авторизация на уровне API

```mermaid
flowchart LR
  Req[Request] --> AuthN[Проверка JWT]
  AuthN --> AuthZ[Проверка прав на ресурс]
  AuthZ -->|OK| Handler[Business logic]
  AuthZ -->|fail| R403[403]
```

Проверка **на каждом** endpoint, не только на Gateway — defense in depth.

---

## RBAC — роли

| Роль | Права в учебном кейсе |
|------|------------------------|
| `owner` | CRUD списка, invite |
| `editor` | CRUD пунктов |
| `viewer` | Только чтение |
| `admin` | Поддержка, ban user (отдельный admin API) |

Роли в JWT `claims` или в БД с lookup — зависит от частоты смены.

---

## ABAC (кратко)

**Attribute-based:** доступ по правилам «владелец списка И список не archived». Гибче RBAC, сложнее аудит. На старте RBAC + проверка `resource.owner_id === user.id` достаточно.

---

## IAM в облаке (инфраструктура)

Не путать с пользователями приложения. **Cloud IAM:**

| Субъект | Объект | Действие |
|---------|--------|----------|
| CI pipeline role | S3 bucket `artifacts` | `s3:PutObject` |
| Pod service account | Secret Manager | `secretAccessor` |
| Разработчик | Production | **нет** write |

**Принцип least privilege:** роль CI не admin на весь аккаунт.

---

## Service-to-service auth

| Подход | Суть |
|--------|------|
| mTLS | Взаимные сертификаты в mesh |
| Signed JWT service account | K8s projected volume |
| API key (internal) | Просто, ротируйте |

Публичные ключи между микросервисами в интернете — **плохо**; только private network или mesh.

---

## Аудит доступа

Логируйте:

| Событие | Поля |
|---------|------|
| login success/fail | user_id, ip, user_agent |
| permission denied | user_id, resource, action |
| admin action | who, what, when |

Без аудита Repudiation из STRIDE не закрыть.

---

## Практика

1. Матрица: роли × операции (таблица галочек) для списков.  
2. Когда 404 вместо 403 для чужого list_id? (спор: скрыть существование)  
3. Какие права нужны CI job только для push образа в registry?

---

## Самопроверка

1. Чем OAuth2 отличается от пароля в каждом запросе?  
2. Зачем короткий TTL access token?  
3. Что такое least privilege для cloud role?

---

## Дальше

→ [Секреты и шифрование](sekrety-i-shifrovanie.md)