Модуль 5.2. Безопасность и соответствие
Темы: аутентификация/авторизация, шифрование, masking, журналирование, требования регуляторов. Артефакты: политика данных и доступов. Практика: модель угроз на уровне фичи.
Системный аналитик (SA) — первый фильтр безопасности. Вы формулируете безопасные требования, закладываете контракты, политику данных, приемочные security-AC, помогаете пройти аудиты и держите систему устойчивой к ошибкам и злоумышленникам. Здесь — практические шаблоны и чек-листы, которые можно сразу унести в проект.
Базовые принципы (что считать «хорошо»)
- CIAA: Confidentiality, Integrity, Availability, Accountability.
- Privacy by Design: минимизация данных, прозрачность, контроль сроков хранения.
- Least Privilege (минимально необходимые права) и Need-to-know.
- Security as NFR: требования безопасности попадают в RTM/AC и проверяются тестами.
Роль SA: описать что защищаем (активы), от кого (угрозы), как измеряем (SLO/контроли), как реагируем (инциденты/логирование).
Аутентификация и авторизация (AuthN/AuthZ)
Аутентификация
-
Пользователи/клиенты: OIDC (OpenID Connect) поверх OAuth2:
- Web/Mobile — Authorization Code + PKCE.
- Машина↔машина — Client Credentials.
- Токены: короткоживущие JWT (access) + refresh по коду.
- Проверяем iss, aud, exp/nbf, kid (публичный ключ из JWK).
- Нельзя принимать alg=none / неподписанные JWT.
- Сроки: access 5–15 мин, refresh 7–30 дней (с ротацией/реалми).
- Сервис↔сервис: mTLS + OAuth2 CC; для вебхуков — mTLS/HMAC-подпись (timestamp+nonce).
Авторизация
- RBAC (роли), ABAC (атрибуты: отдел, регион, сумма ≤ лимита), ReBAC (отношения — «владелец/делегат»).
- Scopes в токене (например, payments:write, orders:read).
- Policy-as-code (OPA/Rego, Casbin): политики версионируем и тестируем.
- Мультитенантность: tenant-id в каждом запросе; RLS (row-level security) на БД/витринах.
Acceptance-пример (AuthZ):
Пользователь с ролью Support может читать заказ только в своём регионе; попытка чтения другого региона даёт 403 и аудит-запись с причиной отказа.
Шифрование, хранение секретов и пароли
В полёте (in-transit)
- TLS 1.2+ (лучше 1.3). Включить HSTS, запрет TLS1.0/1.1, строгие шифры (AES-GCM/ChaCha20-Poly1305).
- Внутренний трафик между сервисами — также TLS/mTLS (service mesh).
В покое (at-rest)
- TDE (шифрование томов/таблиц) для БД/бэкапов.
- Column-level для чувствительных полей (PAN/паспорт).
- Envelope encryption: мастер-ключ в KMS/HSM → data-key → шифрование данных.
- Ротация ключей: минимум ежегодно, при инциденте — немедленно. Разделение обязанностей (не один человек).
Пароли и хэширование
- Никогда не хранить в открытом виде.
- Хэшировать bcrypt/scrypt/Argon2 (соль на запись), не PBKDF2-SHA1 для новых систем.
- Политики MFA, блокировка после нескольких неудач, защита от credential-stuffing (rate-limit, WebAuthn).
Секреты
- Не в git/переменных окружения «навсегда». Хранить в Vault/KMS/Secret Manager, с аудитом и ротацией.
- Секреты в логах — запрещены; используем маскирование.
Данные: классификация, маскирование, минимизация
Классы данных (пример)
|
Класс |
Примеры |
Контроль доступа |
Шифрование |
Маскирование |
Хранение |
|---|---|---|---|---|---|
|
Public |
справка, FAQ |
общедоступно |
опционально |
нет |
без ограничений |
|
Internal |
метрики, технические логи |
сотрудники |
на уровне диска |
красить секреты |
90 дней |
|
Confidential |
email, телефон |
по роли/тенанту |
at-rest+in-transit |
частичная маска |
1–3 года |
|
Restricted |
PAN, паспорт |
строго по бизнес-процессу |
колоночное + токенизация |
обязательна |
минимум по закону |
Минимизация: берём ровно то, что нужно бизнес-процессу. Для аналитики — де-идентификация.
Маскирование и токенизация
- Отдача в UI/логи: **** 1234 (последние 4).
- В аналитике — token/референс вместо реальных идентификаторов.
- В БД — представления с маской (для read-only ролей):
CREATE VIEW v_customer_masked AS
SELECT
customer_id,
concat(left(email, 2), '***', substring(email from position('@' in email))) AS email,
CASE WHEN current_setting('role') = 'analyst_ro' THEN null ELSE phone END AS phone
FROM customer;
Журналирование, аудит, мониторинг
Что логируем
- Доступ/ошибки API: метод, путь, статус, latency, клиент/сервис, correlationId, userId/tenantId, scope.
- События безопасности: логины/логауты, MFA, неудачные попытки, изменения прав/политик, админ-операции, доступ к Restricted данным.
- Бизнес-аудит: операции с деньгами/заказами (кто, что, когда, из какого контекста).
Как логируем
- Структурированные логи (JSON). Включить маскирование: e-mail/телефон/PAN/секреты.
- Синхронизация времени (NTP), неизменяемые хранилища/подпись (tamper-evident).
- Ретенция: 90 дней «горячие», 1–3 года архив по требованиям.
- Централизация: SIEM/лог-платформа, алерты на аномалии (взрыв неудачных логинов/429, рост отказов).
Требования регуляторов (высокоуровнево)
Конкретные нормы согласовываем с юристами/безопасностью вашей компании.
- GDPR/приватность: законные основания обработки, согласия, права субъектов (доступ/удаление), минимизация, DPIA для высоких рисков, уведомление об инцидентах в сроки.
- PCI DSS (платёжные данные): сегментация PCI-зоны, запрет хранения полного PAN/CVV (или жёсткие меры), токенизация, ограничения доступа и логирование.
- Локальные требования (например, локализация персональных данных, сроки хранения, криптосредства) — уточняются для юрисдикции.
Роль SA: в спецификации и AC указать: какой класс данных, где хранится, сроки, основания, кто доступен, какие меры (шифрование/маска).
Практические шаблоны (вставляйте в требования)
HTTP-заголовки безопасности (Web)
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload Content-Security-Policy: default-src 'self'; img-src 'self' data:; frame-ancestors 'none' X-Content-Type-Options: nosniff X-Frame-Options: DENY Referrer-Policy: no-referrer Permissions-Policy: geolocation=(), camera=()
OpenAPI (фрагмент security)
components:
securitySchemes:
oauth2CC:
type: oauth2
flows:
clientCredentials:
tokenUrl: https://auth.example.com/oauth/token
scopes:
orders:read: Read orders
payments:write: Create/capture payments
security:
- oauth2CC: [orders:read]
Политика-как-код (ABAC-пример, псевдо)
allow if subject.role in {"Support","Ops"}
and resource.region == subject.region
and (action in {"orders:read"} or (action=="refunds:create" and request.amount <= subject.refund_limit))
Модель угроз на уровне фичи (методика и пример)
Методика (STRIDE + упрощённый DREAD/оценка риска)
- Граница фичи: что делаем, какие данные/активы, кто акторы.
- DFD (data flow diagram): источники, процессы, хранилища, потоки, границы доверия.
-
STRIDE по элементам:
- Spoofing (подмена личности)
- Tampering (изменение данных)
- Repudiation (отказ от авторства)
- Information disclosure (утечка)
- Denial of service (отказ)
- Elevation of privilege (повышение прав)
- Оценка риска = Вероятность × Влияние (H/M/L).
- Меры: превентивные/детективные/корректирующие, AC для приёмки.
- Остаточный риск и владелец.
Пример фичи: «Создать возврат платежа (Refund)»
Активы: деньги, идентификаторы платежа/заказа, персональные данные плательщика.
Акторы: Пользователь-оператор, Партнёр-PSP, Система уведомлений.
DFD кратко: UI → API Gateway → Refunds Service → PSP API; Audit DB; Event Bus (RefundCompleted).
STRIDE-таблица (фрагмент)
|
Угроза |
Где |
Риск |
Меры |
|---|---|---|---|
|
S: Подмена оператора |
UI/Auth |
High |
OIDC + MFA; короткий access-token; IP/UA аномалии |
|
T: Подмена суммы |
API |
High |
Sign-входного запроса, валидации на сервере, idempotency-key, AC: «сумма ≤ captured» |
|
R: Отказ от авторства |
Audit |
Medium |
Нерепудиация: неизменяемый аудит (WORM), correlationId, подпись записей |
|
I: Утечка PII/PAN |
Logs/Events |
High |
Маскирование/запрет PII в событиях; DLP-сканы; review |
|
D: DoS на PSP |
PSP link |
Medium |
Таймауты, Circuit Breaker, 202-деградация, retry-policy |
|
E: Повышение прав |
Policy |
High |
ABAC (лимит суммы, регион), принцип 4-глаз (second approval > X) |
Security-AC (приёмка):
- AC-1: Повторный POST /refunds с тем же Idempotency-Key возвращает тот же refundId.
- AC-2: Нельзя создать возврат на сумму > capturedAmount → 422, аудит причины.
- AC-3: Пользователь из региона EU не видит платежи APAC (RLS).
- AC-4: Событие refund.completed.v1 не содержит PII; схема утверждена, тесты совместимости — зелёные.
- AC-5: При PSP UNAVAILABLE API отвечает 202 Accepted и публикует задачу в очередь; лаг очереди p95 < 5 с.
Риски и «тонкие места» (как распознавать и гасить)
|
Риск |
Симптом |
Что делать |
|---|---|---|
|
«JWT без проверки aud/exp/kid» |
Любой токен «подходит» |
Строгая валидация всех полей; JWK-ротация |
|
«alg=none» / симметричный ключ у всех |
RCE/подмена |
Только асимметрия (RS/ES), alg белый список |
|
Секреты в логах/дампах |
Утечки |
Маскирование, секрет-сканеры в CI, запрет SELECT * в лог-хуках |
|
PII в событиях |
Риски GDPR/PCI |
Минимизировать payload, токенизация/ссылки |
|
Общая админ-роль «бог» |
Эскалации |
Разделение обязанностей, Just-in-time доступ |
|
Нетрейсабельность |
Инциденты «вслепую» |
traceparent, correlationId, SIEM правила |
|
Неограниченные ретраи |
Шторм |
Классификация ошибок, экспонента+джиттер, лимиты |
Артефакт: Политика данных и доступов (шаблон)
# Политика данных и доступов vX.Y.Z ## 1. Область действия Сервисы: Checkout, Payments, Refunds, DWH/BI. Данные: персональные (PII), платёжные, операционные логи. ## 2. Классификация данных - Public / Internal / Confidential / Restricted (см. матрицу) - Владелец (Data Steward) по доменам: <ФИО/команды> ## 3. Сбор и минимизация - Список полей по каждому процессу, обоснование необходимости, срок хранения, правовые основания. ## 4. Хранение и шифрование - At-rest: TDE на БД, бэкапы шифруются (KMS), колоночное на PAN. - In-transit: TLS1.3, HSTS, mTLS внутри периметра. ## 5. Доступы (RBAC/ABAC) - Роли: `Customer`, `Support`, `Ops`, `Analyst_RO`, `Admin`. - Матричная таблица «Роль × Ресурс × Действие × Условия (ABAC)». - RLS для многотенантности/регионов. ## 6. Авторизация/Аутентификация - OIDC (AC+PKCE), OAuth2 CC для сервисов; MFA для Support/Admin. - Валидация JWT (iss, aud, exp, nbf, kid), JWK-ротация 24ч. ## 7. Маскирование/Токенизация - PAN/паспорт — токенизация; email/телефон — частичная маска; аналитика — обезличенные представления. ## 8. Журналирование и аудит - Что логируем; формат (JSON), маскирование, ретенция; WORM-хранилище для аудита; SIEM-алерты. ## 9. Инциденты и уведомления - Классы инцидентов (SEV-1..3), RACI, сроки уведомлений (внешние/внутренние), план коммуникаций. ## 10. Подрядчики и обмен - Требования к партнёрам (TLS, подпись, логирование, минимизация), DPIA/договоры. ## 11. Соответствие/аудиты - PCI/GDPR/локальные законы: границы, зоны, исключения; журнал изменений. ## 12. Версионирование и исключения - Процедура изменения политики, реестр согласованных исключений с датой экспирации.
Практика (90–120 мин): «Модель угроз фичи + обновление политики»
- Выберите фичу (например, Refund, Экспорт заказов в CSV, Изменение адреса доставки).
- Нарисуйте DFD (источники, процессы, хранилища, границы доверия).
- Составьте STRIDE-таблицу (как в примере), оцените риски (H/M/L), предложите меры.
- Выпишите Security-AC (минимум 5) и внесите в RTM.
- Обновите Политику данных и доступов: добавьте поля, сроки, маскирование, роли, логирование и алерты.
- Подготовьте план тестов: негативные кейсы (подмена токена, превышение лимита, DoS), unit/contract tests, e2e.
Критерии зачёта
- DFD отражает реальные потоки и границы доверия.
- STRIDE покрывает все элементы; меры конкретные и проверяемые.
- Security-AC выполнимы и привязаны к метрикам/логам.
- Политика данных обновлена и непротиворечива.
- Есть план тестов и алертов (SIEM/метрики).
Вопрос–Ответ
В: Зачем нам ABAC, если есть RBAC?
О: RBAC хорош для «кто что может в целом». ABAC добавляет контекст (регион, час, сумма, клиент) и позволяет выражать бизнес-правила доступа без взрыва ролей.
В: Стоит ли хранить JWT в БД и делать revocation-лист?
О: Для коротких access-токенов — обычно не нужно; используйте короткий TTL и ротацию refresh. Для повышенных рисков — revocation-лист/blacklist.
В: Можно ли логировать запросы целиком?
О: Только после редакции чувствительных полей и с учётом класса данных. Для Restricted — запрещено.
В: Что важнее: TLS внутри или снаружи?
О: И там, и там. Внутренние сети «не доверены» — шифруйте и аутентифицируйте сервисы (mTLS).
В: Как сделать аудит «неподделываемым»?
О: WORM-хранилища, подпись/хэш-цепочки, отдельная учётка на запись, ограниченный доступ на удаление, периодические проверки целостности.
В: Когда токенизация, а когда шифрование?
О: Токенизация — когда бизнес-процессам не нужен исходный идентификатор (связываем через токен). Шифрование — когда нужно «вернуть» исходные данные уполномоченным процессам.
Шпаргалка (кратко)
- OIDC/OAuth2 + mTLS, короткоживущие токены, строгая валидация.
- RBAC+ABAC, RLS, principle of least privilege.
- TLS1.3, AES-GCM/ChaCha, bcrypt/Argon2, KMS/HSM, ротация ключей.
- Классификация данных, минимизация, маскирование/токенизация.
- Структурные логи, маска PII, tamper-evident аудит, SIEM-алерты.
- STRIDE на каждую фичу, Security-AC — в RTM.
- События без PII, outbox, идемпотентность.
- Политика данных — живой документ, версия в Git, владелец назначен.
