DataNostro's security architecture

1. Range

This document describes DataNostro's security architecture — a managed server-side Google Tag Manager (sGTM) hosting platform operated in the EU. It focuses on the technical and organizational measures under Art. 32 GDPR applied to the processing of the personal data of customers (Controllers) and the end users of their sites (Data Subjects).

This document does NOT cover:

• The external pen-test report (planned for Q4 2026; once complete we share it under NDA on request)
• The disaster recovery playbook (shared under NDA for Enterprise)
• The vendor risk assessment of sub-processors (internal)

2. Data flow

A simplified pipeline of a tracking event from a visitor to the Controller's site to dispatch to the ad platforms:

[website visitor eshop.cz]
       │ HTTPS POST /g/collect
       ▼
[Cloudflare WAF + DDoS]
       │
       ▼
[DataNostro nginx ingress (DE)]
       │ proxy_pass — Power-Ups middleware (geo, UA, bot, anonymize)
       ▼
[sGTM Docker container (per-tenant, EU)]
       │ GTM Server tags
       ▼
[Celery worker — async dispatch]
       │
       ├─→ Google Analytics 4 (Measurement Protocol)
       ├─→ Meta Conversions API
       ├─→ Google Ads Enhanced Conversions
       ├─→ TikTok Events API
       ├─→ Sklik conversions
       └─→ (10+ more platforms)
       │
       ▼
[Postgres EventCapture — debug log, per-tenant retention 3–90 days]

Key point: data travels only through our EU infrastructure layers. Cloudflare serves as a CDN + DDoS — TLS termination happens on our side (Cloudflare Authenticated Origin Pulls).

3. Data residency and sub-processors

Primary residency: Hetzner Online GmbH (DE) — a Tier III data center, Falkenstein or Nuremberg location. No US parent.

The current list of sub-processors + their DPA links is always available to download in /cs/dpa/. We announce sub-processor changes 30 days in advance per Art. 28(2) GDPR.

4. Encryption

In transit

• TLS 1.2+ (nginx forced), TLS 1.3 preferred
• Let's Encrypt certificates with 90-day rotation (cert-manager)
• HSTS 1 rok + preload
• Authenticated Origin Pulls between Cloudflare and our origin (mTLS)

At rest

• Postgres: full-disk encryption (Hetzner LUKS) + per-row encryption for platform tokens (Fernet, the cryptography library)
• Redis: not used for persistent sensitive data (only cache + queue)
• Pg_dump backups: AES-256 encrypted (gpg), stored in a second EU region
• User passwords: Argon2id (the Django default since 2025)

5. Access control

Customer access (dashboard)

• Email/password + mandatory 2FA for the admin/owner roles (TOTP + WebAuthn passkeys)
• SSO/SAML/OIDC for Enterprise (Okta, Azure AD, Google Workspace)
• Role-based: owner, admin, member, viewer + per-workspace scoping
• Brute-force protection via django-axes (lockout after 5 failed attempts)
• Session timeout 30 min idle, absolute expiry 24 h

DataNostro staff access

• SSH to the production node: only via hardware keys (FIDO2), no passwords
• Admin panel access: only via VPN (WireGuard) + mandatory MFA
• Impersonation: every 'Login as user' action is logged to the audit log with 90-day retention
• Principle of least privilege — no full-DB access except for two engineers, everything else via the Django ORM with row-level scoping

6. Network security

• Cloudflare WAF — OWASP Top 10 rules, custom rules for bot signatures
• DDoS protection: Cloudflare unmetered (L3/L4 + L7)
• Rate limiting: 100 req/s per IP on /api/*, 1000 req/s on /g/collect (per-tenant)
• nginx ingress: only ports 80 (HTTP→HTTPS redirect) + 443
• Postgres + Redis: only the internal Docker network, no public exposure
• SSH: key-based only, port 22 firewall whitelist (Hetzner Cloud Firewall)

7. Tenant isolation

Multi-tenant at the data level (shared DB) + a per-tenant Docker container at the sGTM runtime level.

• Postgres row-level: every query goes through the Django ORM with an explicit tenant=request.tenant filter (audit ORM hooks catch an attempt without it)
• sGTM containers: an isolated Docker container per tenant with CPU/RAM quotas (per-plan); no shared filesystem, no shared network namespace
• API keys: per-tenant scoping enforced by middleware; cross-tenant access returns 403 + an audit log entry
• Cookies / sessions: a cookie name unique per environment; SameSite=Lax + Secure flags

8. Backup and Disaster Recovery

• Daily pg_dump to a local Docker volume (gzip, 02:30 UTC)
• Offsite copy to a second EU region (Hetzner) — daily, an encrypted gpg dump
• Retention 30 daily + 12 weekly + 6 monthly snapshots
• Restore drill monthly as a target (we're formalizing it with the first Enterprise client)
• RPO/RTO commits: RPO ≤ 24 h (daily snapshot), target RTO ≤ 30 min
• Hetzner snapshot weekly whole-VM (a separate recovery layer — bare-metal failure)

We share the detailed DR playbook and runbook scenarios under NDA for Enterprise.

9. Monitoring and audit log

Real-time platform monitoring

• Internal: Django admin /admin/dn/uptime/ with 5-min checks on all critical services
• External: BetterStack 3-min probes from multiple EU locations (homepage, /health/, /t/_synthetic/)
• Sentry: error rate alerts (>5 errors/min)

Tenant-facing audit log

• A per-tenant immutable log: every auth event, settings change, container deploy, API key create/revoke, invoice paid/cancel
• Retention: 90 days (configurable per plan)
• Exportable as CSV/JSON via /dashboard/export/

10. Incident response

• Detection: Sentry + internal monitoring → email within a few minutes of detection; we'll add SMS alerting after the first Enterprise client (BetterStack planned)
• Triage: On-call engineer (1 person) — first response within 15 min in core hours, 60 min off-hours
• Containment: Runbook scenarios (DB down, sGTM crash loop, suspected breach) in the internal docs/RUNBOOK.md
• Customer notification (security incident): Email all owners within 24 h, a status page update within 30 min, a GDPR Art. 33 notification within 72 h if the breach involves personal data
• Post-incident: A public RCA within 5 working days for incidents with downtime > 30 min

11. Vulnerability disclosure (VDP)

Security researchers contact us via [email protected] (PGP key on request). The safe harbor clause in the /.well-known/security.txt.

• Acknowledgment within 48 h
• Severity assessment + remediation timeline within 7 days
• Bug bounty: currently no program, but we're ready to handle qualifying reports individually

12. SDLC + dependency management

• A Git monorepo with mandatory code review (pull request → main)
• Automated tests: the Django test suite, pytest, Playwright e2e — run on every PR
• Dependency scanning: Dependabot (Python + npm) + monthly pip-audit
• Container scanning: Trivy in the build pipeline (every Docker image)
• Secrets management: no secrets in git (a pre-commit hook), .env.prod outside VCS, token rotation every 6 months
• Deploy: an atomic swap via Docker Compose with a health-gated cutover (failed health = no swap)

13. Certifications and compliance status

14. Contacts

• Security disclosure / pen-test reports: [email protected]
• DPO / GDPR requests: [email protected]
• Contractual / DPA: [email protected]
• Status page: datanostro.com/cs/status/
• Trust Center: datanostro.com/cs/trust/