> For the complete documentation index, see [llms.txt](https://rema.gitbook.io/it-business-system-analyst/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rema.gitbook.io/it-business-system-analyst/systems_analyst/informacionnaya-bezopasnost.md).

# Основы информационной безопасности (Information Security)

| Грейд     | Роль   |
| --------- | ------ |
| 🔵 Middle | 🅰️ SA |

> Безопасность — это не задача только security-инженеров. Аналитик должен выявлять угрозы на этапе требований, когда исправления дешевые и безопасность еще не "добавляется потом".

## Почему аналитику важна безопасность

Утечка данных может стоить:

* **Финансово:** штрафы (GDPR до 20 млн евро), компенсация пользователям
* **Репутационно:** потеря доверия клиентов
* **Юридически:** судебные разбирательства

Ошибка в безопасности, найденная на этапе требований, стоит $1. На stage стоит $100. В production стоит $10000.

## Триада CIA: основы безопасности

**Confidentiality (Конфиденциальность):**

* Только авторизованные пользователи видят данные
* Пароль видит только сам пользователь
* Защита: шифрование, контроль доступа, аутентификация

**Integrity (Целостность):**

* Данные не могут быть изменены без авторизации
* Сумма платежа не изменяется в пути передачи
* Защита: цифровые подписи, хеши, аудит

**Availability (Доступность):**

* Система доступна для авторизованных пользователей
* DDoS-атака не должна упасть сайт
* Защита: redundancy, load balancing, DDoS protection

## OWASP API Security Top 10

Это список самых критичных уязвимостей в API по версии OWASP (Open Web Application Security Project).

### Топ 3 уязвимости для аналитика

**1. Broken Object Level Authorization (BOLA)**

Проблема: GET /api/users/123 возвращает данные пользователя 123, даже если я не являюсь админом.

```
Атака: Увеличиваю ID в URL
GET /api/users/124 → получаю данные пользователя 124
GET /api/users/125 → получаю данные пользователя 125
...
GET /api/users/999 → получаю данные CEO
```

**Защита:** Проверять, что текущий пользователь имеет права на этот объект.

**Требование:**

```
API эндпоинт: GET /api/users/{user_id}
Безопасность:
- Проверить, что текущий пользователь == user_id ИЛИ админ
- Если права отсутствуют → вернуть 403 (Forbidden)
```

**2. Injection (SQL Injection, NoSQL Injection)**

Проблема: Если не валидировать входные данные, злоумышленник может внедрить код.

```
Input: name = "'; DROP TABLE users;--"
SQL: SELECT * FROM users WHERE name = ''; DROP TABLE users;--'
Результат: Таблица users удалена
```

**Защита:** Параметризованные запросы (подставлять значения безопасно).

**Требование:**

```
Все SQL запросы должны использовать параметризованные запросы
// НЕПРАВИЛЬНО:
query = f"SELECT * FROM users WHERE name = '{user_input}'"

// ПРАВИЛЬНО:
query = "SELECT * FROM users WHERE name = ?"
params = [user_input]
cursor.execute(query, params)
```

**3. Broken Authentication**

Проблема: Слабая аутентификация позволяет скомпрометировать аккаунт.

```
Примеры:
- Пароль не требует сложности
- Нет MFA (многофакторная аутентификация)
- Токен не истекает
- Сессия не логируется
```

**Защита:** Сильная аутентификация, MFA, логирование попыток входа.

**Требование:**

```
Аутентификация:
- Минимум 8 символов, обязательны буквы, цифры, спецсимволы
- Для операций > $10000 требуется SMS-код или authenticator
- Токен JWT истекает через 1 час
- Попытка входа логируется: IP, время, результат (успех/неудача)
- Алерт если 10+ неудачных попыток входа из одного IP
```

## Защита персональных данных

### 152-ФЗ (Россия)

**Что требует:**

1. Получить явное согласие на обработку персональных данных
2. Хранить данные безопасно (шифрование, контроль доступа)
3. Удалить данные по требованию пользователя
4. Сообщить об утечке в течение 30 дней
5. Назначить DPO (Data Protection Officer) если обрабатываете много данных

**Штрафы:** от 5000 до 300000 рублей.

### GDPR (Европейский Союз)

Аналог 152-ФЗ, но штрафы выше: до 4% годового дохода (максимум 20 млн евро).

## Privacy by Design

**Privacy by Design** — встраивать защиту данных с самого начала разработки, а не добавлять потом.

**Принципы:**

1. **Минимизация данных** — собирать только необходимые
2. **Шифрование** — персональные данные шифруются at rest и in transit
3. **Ограничение хранения** — удалять через определенный период
4. **Контроль доступа** — минимум сотрудников имеют доступ
5. **Логирование** — все обращения к персональным данным логируются
6. **Анонимизация** — удалять идентифицирующие данные где возможно

## Threat Modeling с STRIDE

**STRIDE** — 6 категорий угроз, которые нужно учитывать:

| Угроза          | Описание             | Пример                              | Защита                         |
| --------------- | -------------------- | ----------------------------------- | ------------------------------ |
| **S**poofing    | Подделка личности    | Выдать себя за другого пользователя | Аутентификация, MFA            |
| **T**ampering   | Изменение данных     | Изменить сумму платежа в пути       | Шифрование, подписи            |
| **R**epudiation | Отрицание действия   | "Это не я сделал платеж"            | Логирование, неотрицаемость    |
| **I**nformation | Раскрытие данных     | Перехват пароля                     | Шифрование, контроль доступа   |
| **D**enial      | Отказ в обслуживании | DDoS упасть сайт                    | Rate limiting, масштабирование |
| **E**levation   | Повышение привилегий | Юзер получает права админа          | Контроль доступа, аудит        |

## Требования к безопасности

### Пример: Защита аккаунта

```
Требование SEC-1: Защита пароля

Описание:
Пароль пользователя должен быть защищен от brute force и хранения в открытом виде.

Требования:
1. Хранение:
   - Пароли хешируются (bcrypt, scrypt, argon2)
   - Каждый пароль имеет уникальный salt
   - Хеш-функция медленная (防brute force)

2. Аутентификация:
   - Максимум 5 неудачных попыток
   - После 5 попыток → блокировка на 30 минут
   - Логирование каждой попытки (IP, время, результат)

3. Мониторинг:
   - Алерт если 50+ неудачных попыток из одного IP за час
   - Алерт если вход с нового устройства

Критерии приема:
- Пароль в БД = bcrypt_hash, не открытый текст
- Тест: 1 млн попыток brute force требует > 1 года
- Тест: неправильный пароль 5 раз → аккаунт заблокирован
```

### Пример: HTTPS и шифрование

```
Требование SEC-2: Шифрование в пути

Описание:
Персональные данные должны быть защищены при передаче между клиентом и сервером.

Требования:
1. Все эндпоинты работают на HTTPS
2. TLS версия >= 1.2
3. Сертификат от trusted CA (не self-signed)
4. Perfect Forward Secrecy (PFS) включен

Проверка:
- Попытка подключиться по HTTP → перенаправление на HTTPS
- Сертификат валидный, не истек
- HSTS header включен (Strict-Transport-Security)
```

## Zero Trust Architecture

**Zero Trust** — не доверять никому, всегда проверять.

**Принципы:**

1. **Verify explicitly** — всегда требуй аутентификацию
2. **Use least privilege** — минимум доступа
3. **Assume breach** — предположи, что система уже взломана
4. **Inspect & log everything** — логируй все

**Реализация:**

```
Даже сотрудник компании должен:
- Подтвердить личность (MFA)
- Использовать VPN для доступа из дома
- Устройство должно быть управляемым (MDM) с актуальным антивирусом
- Все обращения логируются с user, device, IP, действие
- Алерт если необычная активность (вход в 3 часа ночи из другой страны)
```

## Практический чеклист для аналитика

При написании требований проверьте:

* [ ] **Персональные данные идентифицированы?** Какие данные обрабатываются?
* [ ] **Угрозы определены?** Какие риски для каждого требования?
* [ ] **Аутентификация требуется?** Как пользователь подтверждает личность?
* [ ] **Авторизация требуется?** Что может делать каждая роль?
* [ ] **Данные шифруются?** In transit (HTTPS) и at rest (в БД)?
* [ ] **Логирование требуется?** Какие события логировать?
* [ ] **Мониторинг требуется?** На какие аномалии алертить?
* [ ] **Соответствие законам?** Какие регуляции применяются (152-ФЗ, GDPR)?

## 📚 Ресурсы для изучения

* [OWASP Top 10](https://owasp.org/www-project-top-ten/) — 10 самых критичных уязвимостей
* [OWASP API Security Top 10](https://owasp.org/www-project-api-security/) — уязвимости API
* [OWASP Testing Guide](https://owasp.org/www-project-web-security-testing-guide/) — как тестировать безопасность
* [CWE Top 25](https://cwe.mitre.org/top25/) — 25 самых опасных ошибок программирования
* [Cybersecurity Roadmap](https://roadmap.sh/cyber-security) — карта развития в cybersecurity