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

# Безопасные требования

## Цель

Научиться формулировать **security requirements** (требования безопасности), которые можно проверить автоматически или на review — а не абстрактные «сделайте безопасно».

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

- [threat-modeling-lite.md](threat-modeling-lite.md) — список угроз и controls.
- Понимание разницы между functional (что система делает) и non-functional (как должна работать) требованиями.

## Время

~25 минут чтения + 30 минут практики

---

## Зачем отдельные security requirements

Фраза «система должна быть безопасной» **не тестируется**. Требование должно быть:

- **Конкретным** — измеримым поведением
- **Проверяемым** — тест, scan, audit
- **Привязанным к риску** — ссылка на threat или compliance

## Типы требований

| Тип | Пример |
|-----|--------|
| **Authentication** | «Все API кроме `/health` требуют valid JWT» |
| **Authorization** | «User не может читать чужой `order_id`» |
| **Data protection** | «PII at rest шифруется AES-256» |
| **Logging & audit** | «Login success/fail пишется с user_id, IP, timestamp» |
| **Input validation** | «Email валидируется по RFC, max 254 символа» |
| **Availability** | «Rate limit 100 req/min per API key» |

## Формат: User Story + Security AC

**User story (функциональная):**
> Как пользователь, я хочу сбросить пароль по email.

**Security Acceptance Criteria (проверяемые):**

| # | Критерий | Проверка |
|---|----------|----------|
| AC-S1 | Reset token одноразовый, TTL 15 мин | Unit test + manual |
| AC-S2 | Token 128+ bit entropy, не в URL referrer | Code review |
| AC-S3 | Не раскрывать, существует ли email | Integration test |
| AC-S4 | Rate limit 3 reset/час на email | DAST / load test |
| AC-S5 | Событие `password_reset_requested` в audit log | Log query |

## SMART для security

| Буква | Применение |
|-------|------------|
| **S** Specific | «HTTPS» → «TLS 1.2+, HSTS max-age 31536000» |
| **M** Measurable | «Быстро» → «p99 auth < 200ms» |
| **A** Achievable | Учитывать стек команды |
| **R** Relevant | Связь с threat model |
| **T** Time-bound | «До MVP» / «до релиза v2» |

## OWASP ASVS как справочник

**ASVS** (Application Security Verification Standard) — чеклист требований по уровням L1/L2/L3.

| Уровень | Для кого |
|---------|----------|
| L1 | Большинство приложений |
| L2 | PII, business-critical |
| L3 | High assurance (редко для стартапов) |

Не копируйте ASVS целиком — **выберите 20–40 пунктов** под ваш продукт и зафиксируйте в wiki.

Пример mapping:

| ASVS ref | Наше требование | Tool/Test |
|----------|-----------------|-----------|
| V2.1.1 | Password min 12 chars | SAST rule |
| V4.1.1 | IDOR запрещён на `/orders/{id}` | Integration test |
| V7.1.1 | Security headers (CSP, X-Frame) | DAST |

## Negative requirements (что запрещено)

Явные запреты снижают двусмысленность:

| Плохо | Хорошо |
|-------|--------|
| «Безопасное хранение паролей» | «Запрещено хранить plaintext password; только bcrypt cost ≥ 12» |
| «Защита от SQLi» | «Запрещены string concatenation SQL; только parameterized queries» |
| «Без секретов в коде» | «Запрещён commit `.env`; secrets только из vault/env inject» |

## Security Requirements Traceability Matrix (SRTM)

Связь: **Threat → Requirement → Test → Implementation**

| Threat ID | Requirement | Test case | Status |
|-----------|-------------|-----------|--------|
| T1 brute force | AC-S4 rate limit | `test_login_rate_limit` | ✅ |
| T2 IDOR | User sees own orders only | `test_order_idor` | 🔄 |

Обновляйте SRTM при изменении scope — иначе «дыры» без владельца.

## Чеклист минимальных требований (web API)

- [ ] AuthN на всех mutating endpoints
- [ ] AuthZ на каждый resource access (не только «залогинен»)
- [ ] Secrets не в git ([раздел 06](../06-bezopasnost-koda/secrets-scanning.md))
- [ ] Dependency scan в CI ([SCA](../06-bezopasnost-koda/sca-zavisimosti.md))
- [ ] Security headers на HTTP responses
- [ ] Structured audit logs без PII в plaintext passwords
- [ ] Error messages без stack traces в production
- [ ] Backup & restore протестирован (RTO/RPO задокументированы)

## Работа с product / stakeholders

| Возражение | Ответ |
|------------|-------|
| «Security замедлит релиз» | 1 critical в production дороже 10 stories в sprint |
| «Потом добавим» | Retrofit auth/encryption ×10 cost |
| «У нас нет sensitive data» | Email уже PII во многих юрисдикциях |

Фиксируйте **risk acceptance** письменно, если требование сознательно откладывается.

## Пример: плохие vs хорошие требования

| ❌ Плохо | ✅ Хорошо |
|----------|-----------|
| Secure API | JWT RS256, exp 1h, refresh rotation |
| Encrypt data | TLS 1.3 in transit; AES-256-GCM at rest for `users.email` |
| Monitor security | Alert on >10 failed logins/min per IP → PagerDuty |

---

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

1. Перепишите «API должно быть защищено» в 3 measurable AC.
2. Чем security AC отличается от обычной acceptance criteria?
3. Зачем negative requirements?
4. Что такое SRTM и какую проблему решает?

## Дальше

[Security code review](security-code-review.md) — как проверять, что требования реально выполнены в коде.