Перейти к основному содержимому

Архитектура безопасности (security architecture) — каноничная модель угроз, шифрования, доступов и жизненного цикла секретов

Версия: 1.0 Дата: 27.04.2026 Статус: Готов к обсуждению

Назначение документа​

Этот документ задаёт каноничную архитектуру безопасности платформы Vitiana — threat model, encryption baseline, identity and access management (IAM), secret lifecycle, supply chain security, network security, runtime security, security operations.

Документ — single source of truth для security review каждого нового feature. Документ согласован с compliance-and-legal.md (SOC 2, ISO 27001, GDPR, PSD2, PCI DSS), multi-tenant-isolation-strength.md (изоляция тенантов как security control), tenancy-and-identity.md (IAM model), payment-domain.md (PSP isolation, card data protection).

Документ не описывает:

  • конкретный security tool stack (Vault vs AWS Secrets Manager — решение на стадии 1);
  • penetration testing vendor (выбор фазы 4);
  • bug bounty program details (фаза 5+).

Документ описывает:

  • threat model (что защищаем, от чего, как);
  • security controls per domain;
  • IAM canonical model;
  • encryption baseline (at-rest, in-transit, key management);
  • secret lifecycle (creation, rotation, revocation);
  • supply chain security;
  • security operations (monitoring, incident response, recovery).

Тезисное обоснование​

Тезис 1. Security — first-class дисциплина с фазы 1, не «add-on перед SOC 2».

Альтернативы: (а) basic security на старте + SOC 2 hardening на фазе 4; (б) full SOC 2 controls с фазы 1; (в) каноничный security baseline с фазы 1, расширение по фазам.

Trade-off: вариант (а) приводит к технической задолженности (security retrofit стоит в 5–10 раз дороже, чем security-by-design); вариант (б) over-engineering для bootstrap (full PCI DSS + ISO 27001 controls несовместимы со small team на фазе 1); вариант (в) — каноничный baseline (encryption, MFA, RBAC, secret management, audit logging) с фазы 1, расширение per-fase (penetration testing — фаза 3, SOC 2 controls — фаза 4, ISO 27001 — фаза 6). Это согласовано с принципом «развитие без деградации».

Тезис 2. Threat model — каноничный артефакт, не «когда-то соберём».

Альтернативы: (а) threat model implicit (в головах инженеров); (б) threat model per feature (рассыпано); (в) каноничная threat model на уровне платформы + per-domain refinement.

Trade-off: вариант (а) приводит к security gaps при ротации команды; вариант (б) рассыпает security knowledge без единой картины; вариант (в) — каноничная STRIDE-based threat model на уровне платформы (Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of privilege) с per-domain refinement. Это масштабируется и согласовано с SOC 2 audit evidence.

Тезис 3. Defense in depth — несколько слоёв security controls.

Альтернативы: (а) single layer защиты (например, только perimeter firewall); (б) zero-trust только на API уровне; (в) defense in depth — несколько independent layers.

Trade-off: вариант (а) — single point of failure; вариант (б) частичный (не защищает от insider threats); вариант (в) — каноничный pattern: network security (firewalls, network segmentation) + identity security (IAM, MFA) + application security (input validation, output encoding) + data security (encryption, access controls) + monitoring (SIEM, anomaly detection). Каждый слой может failure без полного компromise. Это согласовано с modern best practices (NIST CSF, OWASP).

Тезис 4. Secret lifecycle — automated с rotation by default.

Альтернативы: (а) static secrets (без rotation); (б) manual rotation (ad-hoc); (в) automated rotation как default.

Trade-off: вариант (а) — long-lived secrets значительно увеличивают blast radius при compromise; вариант (б) reactive — rotation после incident, не профилактически; вариант (в) — automated rotation (90 дней для long-lived, 1–24 часа для short-lived) — каноничный pattern для cloud-native платформ. Это согласовано с PCI DSS (key rotation requirement) и SOC 2.

Тезис 5. Supply chain security — first-class требование.

Альтернативы: (а) trust all dependencies; (б) manual review каждой dependency; (в) automated supply chain security (SBOM + vulnerability scanning + dependency pinning).

Trade-off: вариант (а) — каждая транзитивная зависимость потенциальный attack vector (SolarWinds, log4shell, и т.д.); вариант (б) не масштабируется (тысячи транзитивных зависимостей); вариант (в) — каноничный pattern: SBOM (Software Bill of Materials) generation для каждого release, automated vulnerability scanning (Snyk / Dependabot / OWASP), dependency pinning, signed artifacts. Это согласовано с modern supply chain best practices (SLSA framework).

Threat model — каноничная модель​

Threat model следует STRIDE methodology с per-domain extensions.

Каноничные угрозы (STRIDE)​

S — Spoofing (подделка identity)​

Угрозы:

  • impersonation legitimate user / service;
  • API key theft + replay;
  • session hijacking;
  • DNS spoofing;
  • supplier spoofing (fake supplier responses).

Mitigations:

  • MFA для всех privileged users;
  • short-lived tokens (JWT с TTL ≤ 1 час, refresh tokens с rotation);
  • TLS 1.3 для всех соединений;
  • DNSSEC для критических доменов;
  • supplier signature verification (для production webhooks).

T — Tampering (modification без авторизации)​

Угрозы:

  • modification данных в transit;
  • modification database records (insider или compromised account);
  • modification of critical configurations;
  • code injection (SQL injection, NoSQL injection, command injection);
  • man-in-the-middle attacks.

Mitigations:

  • TLS 1.3 для всех data in transit;
  • prepared statements (no string-concatenated SQL);
  • input validation на API boundary;
  • output encoding (XSS prevention);
  • immutable audit logs;
  • file integrity monitoring (FIM) для critical configurations;
  • code signing для deployment artifacts.

R — Repudiation (отказ от действия)​

Угрозы:

  • user denies performing action;
  • service account denies performing action;
  • supplier denies acknowledging booking.

Mitigations:

  • comprehensive audit logging (см. ниже);
  • non-repudiation through digital signatures (где applicable, например, contracts с suppliers);
  • legal disclaimers в T&Cs (для consumer flows).

I — Information Disclosure (утечка данных)​

Угрозы:

  • unauthorized access к persdaten (GDPR breach);
  • unauthorized access к payment data (PCI breach);
  • cross-tenant data leakage;
  • sensitive data в logs;
  • sensitive data в error messages;
  • session token leakage в URLs;
  • timing attacks revealing valid usernames / records;
  • side-channel attacks.

Mitigations:

  • encryption at-rest для persdaten + payment data tokenization;
  • encryption in-transit (TLS 1.3);
  • IsolationBoundaryCheck (см. multi-tenant-isolation-strength.md);
  • log sanitization (PII filters);
  • structured error responses без stack traces в production;
  • session tokens только в Authorization headers / HTTP-only secure cookies, никогда в URLs;
  • constant-time comparison для security-sensitive checks.

D — Denial of Service​

Угрозы:

  • volumetric attacks (DDoS);
  • application-layer attacks (slowloris, slow-post);
  • resource exhaustion (database connections, memory);
  • algorithmic complexity attacks (regex DoS, hash collision);
  • credential stuffing;
  • abuse of expensive operations (search with all-results pagination).

Mitigations:

  • DDoS protection через CDN / cloud provider (Cloudflare / OVHcloud Anti-DDoS);
  • rate limiting per tenant / per API key (см. api-metering-and-usage-governance.md);
  • connection pooling с limits;
  • timeout на всех expensive operations;
  • input length limits;
  • regex with bounded backtracking;
  • cost-limit на expensive queries (например, search depth limits);
  • captcha / proof-of-work для anonymous endpoints (login, signup).

E — Elevation of Privilege​

Угрозы:

  • privilege escalation через broken access control (BAC);
  • IDOR (Insecure Direct Object Reference);
  • mass assignment vulnerabilities;
  • container escape;
  • supply chain compromise leading to RCE;
  • compromise of CI/CD pipeline;
  • compromise of secrets management.

Mitigations:

  • least-privilege IAM (default deny, explicit grant);
  • IDOR prevention through authorization checks на каждом resource access;
  • explicit field-level allowlisting (no mass assignment);
  • container security (read-only filesystems, minimal images, no privileged containers);
  • supply chain security (см. ниже);
  • CI/CD security (signed commits, branch protection, build provenance);
  • secrets management (см. ниже).

Каноничная threat surface area per domain​

Каждый домен имеет свою threat surface:

ДоменГлавные threatsSpecific mitigations
ПлатежиI (card data leakage), T (payment manipulation), R (chargeback fraud)PSP-only card handling, idempotency, comprehensive payment audit log
BookingsT (booking manipulation), I (PII leakage), D (booking flood)RBAC, audit log, rate limiting, idempotency keys
Tour BuilderT (tour composition tampering), I (cross-tenant leakage)RBAC per workspace, IsolationBoundaryCheck
Tenancy / IdentityS (impersonation), E (privilege escalation), I (cross-tenant)MFA, short-lived tokens, IsolationBoundaryCheck, fine-grained RBAC
Search / DiscoveryD (search abuse), I (sensitive content exposure через search)rate limiting, search index sanitization
Suppliers / IngestionT (malicious supplier data), S (supplier spoofing), D (supplier flood)input validation, supplier signature verification, ingestion rate limits
NotificationsI (notification content leakage), S (phishing through legit channels)template sanitization, recipient verification, sender authentication (SPF/DKIM/DMARC)
Media / ContentT (content tampering), D (media flood), I (sensitive content)content moderation, upload limits, scan для malware
Analytics / BII (data leakage через analytics)k-anonymization, aggregation enforcement
ML PlatformT (model poisoning), I (training data leakage), inference abusetraining data isolation, inference rate limits, model versioning
API as ProductE (privilege escalation через partner API), S (API key theft), D (API abuse)strong API key rotation, OAuth2 scopes, partner-level rate limiting

Identity and Access Management (IAM) — каноничная модель​

IAM — fundamental security control, согласованный с tenancy-and-identity.md.

Каноничные сущности​

  • User — physical person с identity;
  • Service Account — programmatic identity для machine-to-machine;
  • Tenant — organizational scope;
  • Workspace — sub-scope внутри tenant (для agency surface);
  • Role — collection of permissions;
  • Permission — granular ability (например, booking.create, payment.refund);
  • Capability Set — computed set of permissions для (actor, tenant, workspace) — см. clients.md;
  • Session — authenticated context с TTL.

Аутентификация (Authentication, AuthN)​

Каноничные authentication factors​

  • Knowledge (что знает): password, PIN;
  • Possession (что имеет): TOTP/HOTP token, hardware key (YubiKey), SMS (deprecated, only fallback), push notification;
  • Inherence (чем является): biometrics (mobile only).

Каноничные authentication levels​

  • Level 0: anonymous (public reads);
  • Level 1: single factor (password) — basic users for low-sensitivity actions;
  • Level 2: MFA (password + TOTP/hardware key) — все privileged users + payment actions;
  • Level 3: MFA + step-up (re-auth для sensitive operations) — refund > €1000, account deletion, role grants.

Правила:

  • Internal operators (Surface 1) — Level 2 mandatory;
  • Agency users (Surface 2) — Level 1 minimum, Level 2 для admin actions;
  • Partner integrators — Level 2 для UI access, API через signed requests с key + secret;
  • B2C customers — Level 1 для browsing/booking, Level 2 для payment management;
  • Service accounts — keys + secrets с automatic rotation, никогда не interactive.

Token model​

  • Access tokens — JWT с TTL ≤ 1 час, claim'ы включают tenant_id, actor_id, capabilities, session_id;
  • Refresh tokens — opaque, TTL 30 дней, revocable, rotation на каждое использование;
  • Service account keys — long-lived но обязательная automated rotation 90 дней;
  • Idempotency keys — короткие, scoped per request.

Авторизация (Authorization, AuthZ)​

RBAC + ABAC hybrid​

Платформа использует hybrid approach:

  • RBAC (Role-Based) — основа: каноничные роли (platform_admin, tenant_admin, agency_user, partner_developer, b2c_customer, и т.д.);
  • ABAC (Attribute-Based) — refinement: dynamic checks (например, booking.refund доступен только если actor.tenant_id == booking.tenant_id).

Канонический authorization flow​

При каждом privileged action:

  1. Authentication check — token valid, не expired, не revoked;
  2. Tenant boundary check — actor имеет access к tenant resource;
  3. Workspace boundary check (если applicable) — actor имеет access к workspace;
  4. Permission check — permission_required ∈ actor.capabilities;
  5. Attribute check (если ABAC rule applies) — dynamic context check;
  6. Audit log — authz.action.executed с полным context.

Любой failure → deny + audit log с authz.action.denied + reason.

Каноничные деnial responses​

  • 401 Unauthorized — не authenticated;
  • 403 Forbidden — authenticated, но no permission (без deталей why — security through obscurity);
  • 404 Not Found — resource exists, но actor не имеет access (preserves resource existence privacy).

IsolationBoundaryCheck​

Каноничный automated check (см. multi-tenant-isolation-strength.md):

  • runs continuously в production;
  • attempts cross-tenant queries с different actors;
  • alert при successful unauthorized access;
  • target: 0 successful breaches за rolling 90 дней.

Encryption — каноничная модель​

Encryption at-rest​

Database​

  • PostgreSQL: Transparent Data Encryption (TDE) через cloud provider managed encryption (OVHcloud / AWS RDS) + application-layer encryption для sensitive columns;
  • Sensitive columns (отдельная column-level encryption через app):
    • users.email_hash — search;
    • users.email_encrypted — readable display (encrypted с per-tenant key);
    • payment_method.token — only PSP-tokenized references, no PAN;
    • audit_log.actor_email — encrypted;
  • Backup encryption — managed encryption keys + cross-region replication encrypted.

Object storage​

  • Server-side encryption (SSE) — managed keys (SSE-S3 equivalent на OVHcloud);
  • Customer-managed keys (CMK) для tenant Enterprise — separate keys per tenant;
  • Bucket-level encryption policy enforcement.

Cache (Redis)​

  • TLS для transport;
  • No sensitive data в cache (только tokenized references);
  • Redis ACL + per-tenant prefixing.

Encryption in-transit​

  • TLS 1.3 mandatory для всех external endpoints;
  • TLS 1.2 для legacy partner integrations (deprecated с фазы 4);
  • mTLS для internal service-to-service communication (фаза 3+);
  • Certificate management — automated через cert-manager + Let's Encrypt (production), внутренний CA для internal mTLS;
  • Certificate rotation — automated, max 90 дней TTL.

Key management​

Каноничная hierarchy​

  • Master keys — KMS (cloud provider или self-hosted Vault);
  • Data Encryption Keys (DEK) — generated по necessity, encrypted master key;
  • Per-tenant keys — separate DEK per Enterprise tenant;
  • Application secrets — encrypted by master key, accessed через secrets manager.

Key rotation​

  • Master keys — annual rotation (с key versioning для backward decryption);
  • DEK — automated rotation 90 дней;
  • Application secrets — automated rotation 90 дней (long-lived) или per-use (short-lived).

Key revocation​

При suspected compromise:

  • immediate revocation через runbook (см. runbooks-incident-playbooks.md);
  • re-encryption affected data с new key;
  • audit logging revocation action.

Secret lifecycle — каноничная модель​

Каноничные types of secrets​

  • API keys для external services (PSP, email, SMS, monitoring);
  • Database credentials;
  • Service account keys для internal service-to-service;
  • Webhook signing secrets (HMAC keys);
  • Encryption keys (см. encryption section);
  • OAuth client secrets;
  • TLS certificates and private keys.

Каноничный жизненный цикл​

Phase 1. Creation​

  • generated через secrets manager (никогда не manually typed);
  • minimum entropy: 256 bits для keys, 128 bits для tokens;
  • never committed в source control;
  • never в plain text logs / metrics / traces.

Phase 2. Distribution​

  • accessed через secrets manager API только;
  • service accounts получают через workload identity (Kubernetes service accounts с linked IAM, или equivalent);
  • никогда через environment variables в plain text для long-lived secrets (используем secret refs);
  • никогда через configuration files committed.

Phase 3. Rotation​

  • automated rotation per type:
    • PSP keys — 90 дней;
    • DB credentials — 90 дней (zero-downtime через connection pooling с rolling refresh);
    • Service account keys — 90 дней;
    • Webhook signing secrets — 180 дней (с overlap window для verification);
    • TLS certificates — automated через cert-manager (90 дней Let's Encrypt);
  • rotation не должен прерывать service (overlap windows).

Phase 4. Revocation​

  • immediate revocation при suspected compromise;
  • automated через runbook;
  • audit log включает actor, reason, affected services.

Phase 5. Destruction​

  • old secret material destroyed после rotation grace period;
  • audit log сохраняется (без secret material).

Secrets management tooling​

Канонический выбор tools (решение на стадии 1):

  • HashiCorp Vault — self-hosted, full feature set;
  • AWS Secrets Manager / OVHcloud Vault — managed, simpler ops;
  • SOPS + Git — для simple bootstrap (фаза 0–1 only).

Фаза 1 — допустимо начать с simpler option, переход на Vault на фазе 2–3 при росте complexity.

Supply chain security — каноничная модель​

Каноничные практики​

SBOM (Software Bill of Materials)​

  • генерация SBOM для каждого release;
  • format: SPDX или CycloneDX;
  • хранение SBOM в release artifacts;
  • automated vulnerability matching против CVE database.

Dependency management​

  • Pinned versions для всех direct dependencies;
  • Lock files committed (package-lock.json, Cargo.lock, go.sum);
  • Automated updates через Dependabot / Renovate с автоматическим CI verification;
  • Vulnerability scanning для каждого PR через Snyk / OWASP Dependency Check;
  • License compliance — automated check (no GPL в proprietary code, и т.д.).

Code signing​

  • Git commits signed (GPG / SSH signing) — обязательно для main / release branches;
  • Container images signed через Cosign или equivalent;
  • Release artifacts signed.

Build provenance​

  • Reproducible builds где possible;
  • Build environment documented в SBOM;
  • Trusted build infrastructure — CI runners в isolated environments, no shared state.

Trusted base images​

  • Distroless или minimal images для production containers;
  • Signed base images (Docker Content Trust, Cosign);
  • Regular base image updates — automated через CI;
  • No latest tag в production.

Supply chain incident response​

При обнаружении vulnerability в dependency:

  1. Severity assessment — CVSS score + exploitability в нашем context;
  2. Immediate mitigation (если critical) — WAF rules, runtime patching;
  3. Long-term fix — dependency update + redeployment;
  4. Notification — internal stakeholders, affected partners (если applicable).

Network security — каноничная модель​

Каноничные слои​

Layer 1. Edge / DDoS protection​

  • CDN (Cloudflare / OVHcloud Anti-DDoS) для всех public endpoints;
  • Volumetric attack mitigation — automatic;
  • Rate limiting на edge layer для anonymous endpoints.

Layer 2. WAF (Web Application Firewall)​

  • Managed rule sets (OWASP CRS, vendor-specific);
  • Custom rules для known attack patterns (specific bot signatures, и т.д.);
  • Bot management — distinguish good bots (search engines) от bad (scrapers, abuse).

Layer 3. API Gateway​

  • TLS termination + re-encryption для backend;
  • Authentication + token validation;
  • Rate limiting per tenant / per API key;
  • Request validation (schema check);
  • Response sanitization.

Layer 4. Service mesh / Internal network​

  • mTLS между services (фаза 3+);
  • Network policies (Kubernetes NetworkPolicy или equivalent) — default deny, explicit allow;
  • Service-to-service authentication через workload identity.

Layer 5. Database / data store access​

  • Network isolation — databases доступны только из specific subnets;
  • No public IP для databases;
  • VPN / bastion для admin access (с audit logging).

Network segmentation​

  • Production / staging / dev — full network isolation;
  • Tenant-aware segmentation — для dedicated_compute уровня, отдельные namespaces с network policies;
  • Public / private subnets — public только для load balancers / API gateway;
  • Egress filtering — restricted outbound для production workloads (whitelisted external services).

Runtime security — каноничная модель​

Container security​

  • Distroless / minimal base images — no shell, no debug tools в production;
  • Read-only root filesystem;
  • Non-root user для все processes;
  • No privileged containers;
  • Capabilities dropped (drop ALL, add только необходимые);
  • Seccomp profiles applied;
  • Resource limits (CPU / memory) — prevents resource exhaustion attacks;
  • Image scanning — scan для CVE до admission в production registry.

Kubernetes security (или equivalent для chosen runtime)​

  • Pod Security Standards — restricted profile в production;
  • Network Policies — default deny;
  • RBAC для service accounts — least privilege;
  • Admission controllers — OPA Gatekeeper / Kyverno для policy enforcement;
  • Secret encryption at rest в etcd;
  • Audit logging включен;
  • Regular updates Kubernetes version (n-1 supported).

Application runtime​

  • Input validation на API boundary;
  • Output encoding для prevention XSS / injection;
  • Parameterized queries mandatory;
  • CSRF protection для browser-facing surfaces (anti-CSRF tokens или SameSite cookies);
  • Content Security Policy (CSP) для все web surfaces;
  • Subresource Integrity (SRI) для third-party scripts;
  • Security headers (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy).

Audit logging — каноничная модель​

Каноничные события для audit​

Все security-relevant events:

Authentication events​

  • auth.login.success;
  • auth.login.failed;
  • auth.logout;
  • auth.mfa.required;
  • auth.mfa.success;
  • auth.mfa.failed;
  • auth.password.changed;
  • auth.password.reset_requested;
  • auth.token.issued;
  • auth.token.revoked;
  • auth.session.expired.

Authorization events​

  • authz.action.executed;
  • authz.action.denied;
  • authz.privilege.escalated;
  • authz.role.granted;
  • authz.role.revoked.

Data access events​

  • data.sensitive.accessed (для PII, payment data);
  • data.exported (bulk data export — for monitoring exfiltration);
  • data.deleted;
  • data.cross_tenant.attempted (trigger для investigation).

Administrative events​

  • admin.user.created;
  • admin.user.deleted;
  • admin.role.modified;
  • admin.config.changed;
  • admin.secret.rotated;
  • admin.secret.revoked.

Security events​

  • security.suspicious_activity.detected;
  • security.rate_limit.exceeded;
  • security.brute_force.detected;
  • security.injection.attempted;
  • security.data_breach.detected.

Каноничная audit log structure​

Каждое событие включает:

  • event_id (UUID, immutable);
  • event_type (из списка выше);
  • timestamp (ISO 8601, server time);
  • actor (user_id, service_account_id, или anonymous);
  • actor_ip (с обработкой proxy headers);
  • actor_user_agent;
  • tenant_id;
  • workspace_id (если applicable);
  • resource_type, resource_id (на что направлено действие);
  • action;
  • result (success / denied / error);
  • correlation_id (для tracing across services);
  • additional_context (JSON с domain-specific details).

Audit log storage​

  • Immutable storage — append-only, write-once-read-many (WORM);
  • Retention — 7 лет для financial / compliance audit, 2 года для operational;
  • Tier 1 backup (см. disaster-recovery-and-capacity.md);
  • Encryption at-rest + access controlled (read-only для большинства, no delete);
  • Tamper detection — periodic integrity checks (hash chains).

Security operations — каноничная модель​

SIEM (Security Information and Event Management)​

  • Log aggregation из всех sources (audit log, application logs, network logs, host logs);
  • Correlation rules для detection patterns (например, multiple failed logins → brute force);
  • Real-time alerting для critical events;
  • Investigation tooling для security incidents.

С фазы 4 — managed SIEM (Datadog Security / Wazuh / Splunk).

Vulnerability management​

  • Continuous scanning — applications, infrastructure, dependencies;
  • Severity classification — Critical / High / Medium / Low (CVSS-based + business impact);
  • SLA на patching:
    • Critical: 24 часа;
    • High: 7 дней;
    • Medium: 30 дней;
    • Low: 90 дней.
  • Verification после patch — re-scan + functional test.

Penetration testing​

  • External pen test — annual с фазы 3, semi-annual с фазы 5;
  • Specialized tests — payment flow, multi-tenant isolation, partner API surface;
  • Remediation tracking — все findings → backlog с SLA.

Bug bounty​

  • Private program на фазе 4 (HackerOne / Bugcrowd);
  • Public program на фазе 5–6;
  • Scope — public surfaces (vitrip.store, partner API, agency surface);
  • Rewards — tiered по severity.

Security incident response​

Согласовано с runbooks-incident-playbooks.md.

Каноничные incident classes:

  • security.unauthorized_access;
  • security.data_breach;
  • security.account_takeover;
  • security.malware_detection;
  • security.supply_chain_compromise;
  • security.ddos;
  • security.insider_threat.

Каждый имеет dedicated runbook с эскалацией в CISO (фаза 6) или Security Engineer (фаза 3+).

Security training​

  • Onboarding security training — для всех new hires (фаза 3+);
  • Annual refresher — для всех employees;
  • Specialized training — для engineers (secure coding), operations (incident response), customer success (social engineering awareness);
  • Phishing simulations — quarterly;
  • Training records хранятся как audit evidence.

Компromise scenarios и recovery​

Сценарий 1. Compromised user account​

Detection: anomalous login (geo, time, device fingerprint).

Response:

  1. immediate session invalidation;
  2. force password reset + MFA re-enrollment;
  3. audit recent actions для damage assessment;
  4. notification user.

Сценарий 2. Compromised service account / API key​

Detection: anomalous API usage patterns.

Response:

  1. immediate key revocation;
  2. issue new key через secret manager;
  3. update affected services;
  4. audit recent API actions;
  5. notification affected partner / internal team.

Сценарий 3. Compromised production database​

Detection: unauthorized queries, data exfiltration patterns, file integrity alerts.

Response:

  1. immediate isolation (network policy block);
  2. snapshot для forensics;
  3. assess scope through audit logs;
  4. invoke disaster recovery procedure (см. disaster-recovery-and-capacity.md);
  5. data breach notification per compliance-and-legal.md;
  6. forensic investigation;
  7. re-architect access patterns если root cause structural.

Сценарий 4. Supply chain compromise​

Detection: vulnerability disclosure, integrity check failures, anomalous behavior.

Response:

  1. assess scope (which services use compromised dependency);
  2. apply mitigations (WAF rules, runtime restrictions);
  3. patch + redeploy affected services;
  4. SBOM review для transitive impact;
  5. notification внутренние / external stakeholders.

Сценарий 5. Cross-tenant data leakage​

Detection: IsolationBoundaryCheck alert, audit log anomaly.

Response:

  1. immediate investigation;
  2. data exposure scope assessment;
  3. fix authorization gap;
  4. notification affected tenants;
  5. data breach reporting per compliance-and-legal.md;
  6. compensation per SLA если applicable.

Каноничные security события (для event stream)​

Все security события публикуются в общий поток (см. data-platform-and-events-tracking.md) с префиксом security.:

  • все события из «Audit logging» секции выше;
  • security.scan.completed (vulnerability scan);
  • security.scan.vulnerability_detected;
  • security.patch.applied;
  • security.pentest.started;
  • security.pentest.findings_received;
  • security.training.completed.

Метрики security health​

  • MFA coverage — % users with MFA — target 100% для internal/admin, ≥80% для agency/partner;
  • Vulnerability backlog — count by severity, target 0 critical / 0 high open > SLA;
  • Patch SLA compliance — % patched within SLA — target 100%;
  • IsolationBoundaryCheck breaches — target 0 в rolling 90 дней;
  • Audit log coverage — % security events logged — target 100%;
  • Failed authentication rate — anomalies trigger investigation;
  • Security training completion — target 100% within 30 дней of hire / annual refresh;
  • MTTR security incidents — target ≤ 4 часа для critical.

Соответствие compliance​

Прямая связь с compliance-and-legal.md:

Compliance requirementРеализация в security architecture
GDPR — encryption at-rest для PIIDatabase encryption + column-level encryption для sensitive
GDPR — access controlsRBAC + ABAC + audit logging
GDPR — breach notificationSecurity incident runbooks + 72h SLA
PCI DSS — no card data in our systemsPSP-only handling + no PAN storage
PCI DSS — key rotationAutomated key rotation 90 дней
PCI DSS — audit loggingComprehensive audit log + WORM storage
PSD2 — SCAThrough PSP integration
SOC 2 — security controlsAll controls in this document
SOC 2 — availabilityDR / capacity (см. operations)
SOC 2 — processing integrityInput validation + output verification
SOC 2 — confidentialityEncryption + access controls
ISO 27001 — ISMSSecurity policies + procedures + monitoring + improvement

Открытые вопросы и развилки​

  1. Vault deployment. HashiCorp Vault self-hosted vs managed (HCP Vault, AWS Secrets Manager, OVHcloud Vault). Решение — на стадии 1 baseline.
  2. mTLS rollout timing. mTLS для internal services — фаза 2 или фаза 3? Решение — на стадии 2 после assessment latency impact.
  3. Penetration testing vendor. Решение — на стадии 3 при первом external pentest.
  4. Bug bounty platform. HackerOne vs Bugcrowd vs other. Решение — на стадии 4 при private program launch.
  5. CISO timing. Когда нужен dedicated CISO? Стадия 5 vs стадия 6. Зависит от growth pace и enterprise customer requirements.
  6. Cloud HSM (Hardware Security Module). Для tenants Enterprise с extra encryption requirements — нужен ли cloud HSM? Решение — на стадии 6 при первом enterprise customer с такими требованиями.
  7. Zero-trust full implementation. Полная zero-trust architecture (BeyondCorp pattern) — стадия 5 или стадия 6? Зависит от operational maturity.

Каноничный итог​

Security architecture для платформы Vitiana — first-class дисциплина с фазы 1, расширяющаяся по стадиям:

  • caноничная STRIDE-based threat model;
  • defense in depth (network / identity / application / data / monitoring);
  • IAM с RBAC + ABAC + IsolationBoundaryCheck;
  • encryption at-rest + in-transit + key management hierarchy;
  • automated secret lifecycle с rotation by default;
  • supply chain security (SBOM + scanning + signing);
  • comprehensive audit logging с immutable storage;
  • security operations (SIEM + vulnerability management + pen testing + bug bounty);
  • compromise scenarios с каноничными recovery procedures;
  • метрики security health.

Это масштабируемая модель security для top-tier global travel platform, согласованная с GDPR, PSD2, PCI DSS, SOC 2, ISO 27001 требованиями.

Связанная документация​

Каноничные доменные документы​

Операционные документы​

Документы развития​

Архитектурные правила​