Безопасность и compliance на собеседовании системного аналитика

Зачем SA знать безопасность и compliance

SA не реализует security сам, но проектирует системы, которые должны быть защищены. Любой публичный endpoint, любой процесс с персональными данными, любая финансовая операция — есть требования к security и compliance.

В РФ — 152-ФЗ о персональных данных, требования ЦБ (для банков), PCI-DSS (для платежей). На собесе системного аналитика этот блок проверяют почти всегда, особенно в финтех и телекоме. Уровень: junior — знает auth vs authz; middle — понимает 2FA, 152-ФЗ; senior — может спроектировать систему с compliance-конструкцией.

Authentication vs Authorization

Authentication (authn) — кто ты. Проверка identity.

Authorization (authz) — что тебе можно. Проверка прав.

Не путать. «Залогинен» (authn) ≠ «может удалить заказ» (authz).

Сценарий:

Логин: введи email + пароль → authn успешен → токен.
Запрос: GET /orders/123 → проверяем токен (authn) → проверяем, что юзер владеет заказом (authz) → возвращаем данные.

Подробнее — Authentication vs Authorization.

Способы аутентификации

Password. Самый базовый. Минимально:

Хеширование (bcrypt, argon2 — не SHA-256, не plain text)
Salt уникальный для каждого юзера
Защита от brute-force (rate limit, captcha)

OAuth 2.0. Третьесторонний логин (Google, GitHub). Юзер логинится на их стороне, мы получаем token.

OpenID Connect (OIDC) — поверх OAuth. Стандарт для identity (id_token, user info endpoint).

SAML. Enterprise SSO. Используется в корпоративных средах.

JWT (JSON Web Token). Stateless токен с подписью. Сервер не хранит session. Минусы — нельзя «отозвать» до истечения.

Session-based (cookie + server-side store). Можно revoke, но требует session storage.

Two-Factor Authentication (2FA)

Второй фактор после пароля:

SMS-OTP — самый распространённый, но уязвим к SIM-swap
TOTP (Google Authenticator) — генерируется приложением, безопаснее
Hardware token (YubiKey) — максимум безопасности
Push-notification (банковские app-ы)
Biometrics (Face ID, Touch ID)

В банках — обязательно 2FA для транзакций. По 152-ФЗ — для доступа к ПДн.

Подробнее — Two-Factor Authentication (2FA).

Авторизация: модели

RBAC (Role-Based Access Control). Юзеры → роли → permissions. Простой, понятный. «Менеджер может одобрить заказ».

ABAC (Attribute-Based). Permission зависит от атрибутов: «менеджер может одобрить заказ только своего региона». Гибкий, сложный.

ReBAC (Relationship-Based). Permission на основе связей: «юзер может смотреть документы, которые с ним share-нули».

PBAC (Policy-Based). Permission в виде policies (например, OPA). Декларативные правила.

В большинстве случаев — RBAC + расширения для специфических кейсов.

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

Закон о персональных данных. Главное:

ПДн — любая информация, относящаяся к идентифицированному лицу (имя, телефон, email, IP).
Согласие. Сбор ПДн только с согласия субъекта.
Цели. Использование только в заявленных целях.
Локализация. ПДн граждан РФ должны храниться в РФ.
Защита. Шифрование, контроль доступа, audit log.
Права субъекта. Доступ к своим данным, удаление, исправление.
Уведомление РКН. При сборе ПДн — уведомить Роскомнадзор.

Подробнее — 152-ФЗ о персональных данных.

PCI-DSS

Стандарт безопасности платёжных карт. Применим к компаниям, обрабатывающим card data.

Главные требования:

Не хранить CVV
Шифрование PAN (номер карты)
Сегментация сети
Логирование доступа
Регулярные penetration test
2FA для администраторов

Уровни PCI-DSS зависят от объёма транзакций.

В банках — обязательно. В обычном e-commerce — обычно через payment provider (Stripe, ЮKassa), который сам PCI-compliant.

KYC и AML

KYC (Know Your Customer). Идентификация клиента: документы, биометрия, проверка по базам.

AML (Anti-Money Laundering). Противодействие отмыванию: мониторинг транзакций, отчётность подозрительных операций.

В РФ — 115-ФЗ. Применимо к банкам, обменникам, инвестиционным брокерам.

Сценарий KYC:

Юзер вводит паспортные данные
Делаем фото с паспортом
Проверка по базе МВД / Росфинмониторинга
Risk-scoring (residence, profession, expected transaction volume)
Approval / decline / запрос дополнительных данных

Защита API

Rate limiting. Лимиты по клиенту, IP, endpoint. Предотвращает abuse, DDoS, brute-force.

Input validation. Все входы проверяются. Защита от SQL injection, XSS, command injection.

HTTPS only. Никогда HTTP в production.

CORS. Контроль cross-origin запросов.

CSP (Content Security Policy). Защита от XSS в браузере.

Secrets management. API-ключи, пароли, токены — в Vault / AWS Secrets Manager, не в коде.

Audit log. Логи всех чувствительных действий — кто, что, когда.

OWASP Top 10

Top уязвимости web-приложений:

Broken access control — баги в authz
Cryptographic failures — плохое шифрование
Injection — SQL injection, XSS
Insecure design — архитектурные дыры
Security misconfiguration — открытые порты, default пароли
Vulnerable components — старые библиотеки с CVE
Authentication failures — слабые пароли, нет 2FA
Software and data integrity failures — нет подписи updates
Logging and monitoring failures — нет audit logs
SSRF (Server-Side Request Forgery) — сервер вызывает что попросил attacker

SA должен думать о всех 10 при дизайне.

Типичные вопросы

«Что такое 2FA и когда обязательно?»

Второй фактор после пароля. В банках — обязательно для транзакций. По 152-ФЗ — для доступа к ПДн (для администраторов).

«Как храним пароли?»

bcrypt (адаптивный, slow) или argon2. С уникальным salt для каждого юзера. Никогда — plain text, MD5, SHA-256 без salt.

«Auth vs authz»

Authentication — кто ты (проверка identity). Authorization — что тебе можно (проверка прав).

«Как защитить API от brute-force?»

(1) Rate limiting per IP / per user. (2) Captcha после N неудачных попыток. (3) Lock account temporarily. (4) Notify по email о подозрительной активности. (5) 2FA — fallback.

«Что нужно делать с ПДн по 152-ФЗ?»

Главное: (1) согласие на обработку, (2) указание целей, (3) локализация в РФ, (4) защита (шифрование, access control), (5) уведомление РКН, (6) права субъекта (удаление, доступ).

«Где хранить JWT-токен в браузере?»

httpOnly cookie — защита от XSS. Не localStorage (доступен JS, уязвим к XSS). + CSRF-protection через SameSite cookie.

Частые ошибки

«Шифрование» через base64. Base64 — это не шифрование, а кодирование. Защиты нет.
JWT в localStorage. Уязвимо к XSS. httpOnly cookie лучше.
Игнорировать audit log. В compliance-сценариях аудит обязателен.
Защищать только «чувствительные» endpoint-ы. Все endpoint-ы должны иметь как минимум rate limit.
Хранить ПДн без локализации. Нарушение 152-ФЗ.

FAQ

Спрашивают ли OWASP детально?

В Junior — base concepts. В Middle/Senior — знание top vulnerabilities и защиты.

Нужно ли уметь пентестить?

SA — нет. Это работа security engineer. SA должен понимать risks и защиты на уровне дизайна.

GDPR — европейский закон о ПДн. 152-ФЗ — российский. Концептуально похожи: согласие, минимизация данных, права субъекта. Различаются в деталях.

Какие компании требуют compliance-экспертизу?

Банки, телеком, медицина, госструктуры. Также любые компании, обрабатывающие ПДн в РФ.

Сколько готовиться?

Junior — 1-2 месяца. Middle — 2-3 недели. Senior — 2-4 недели для углубления.

Смотрите также

Тренироваться в Telegram