Přeskočit na obsah
NemotiQ

Bezpečnost & Trust Center

Technicko-organizační opatření, kterými NemotiQ chrání data realitních makléřů a jejich klientů. Stránka cílí na prospekty a auditory, kteří potřebují konkrétní detaily před uzavřením smlouvy nebo DPA.

1. Přehled

NemotiQ provozuje SaaS pro realitní makléře, kteří nám svěřují citlivá data klientů – kontakty, smlouvy, transakce. Bezpečnost a soukromí jsou pro nás core hodnota, ne add-on. Tato stránka shrnuje konkrétní technicko-organizační opatření a postupy, které máme zavedené.

Detailní právní dokumenty: Ochrana soukromí · DPA · Subprocesoři.

2. Šifrování

  • V tranzitu: HTTPS only s HSTS na 2 roky (preload), TLS 1.2+ pro veškerou komunikaci včetně API volání externím službám (Resend, Signi, Google).
  • V klidu – citlivá PII: AES-256-GCM šifrování polí phone, ico, street a email v CRM kontaktech (přes Prisma Client Extension) a fakturační adresy. Klíč je v ENCRYPTION_KEY env var, nikdy v kódu ani v Gitu.
  • V klidu – AML / KYC: rodné číslo, číslo dokladu, adresa trvalého pobytu a jméno statutárního orgánu jsou šifrované AES-256-GCM per-field (samostatný IV pro každý zápis).
  • V klidu – osobní knihovna makléře: soubory jsou šifrované at-rest AES-256-GCM (úložiště vidí jen nečitelný blob), stejně tak názvy souborů a poznámky.
  • Přístupový token portálu: v databázi se nedrží v plaintextu — ukládá se jen SHA-256 otisk pro vyhledání a AES-256-GCM šifra pro obnovení odkazu. Únik samotné databáze bez klíče nedá funkční odkaz.
  • Tokeny pro reset hesla a ověření e-mailu: v databázi jen SHA-256 otisk; samotný token zná pouze příjemce v e-mailovém odkazu. Únik databáze tak nedá použitelný odkaz pro převzetí účtu.
  • Hashing hesel: bcrypt (cost factor 12) proUser.passwordHash; nikdy plaintext.

3. Autentizace & autorizace

  • NextAuth Credentials s JWT – žádné serverové sessions, token v httpOnly cookie (sameSite=lax, secure v prod).
  • Account lockout: 5 neúspěšných pokusů → progresivní uzamčení (5 → 15 → 30 → 60 → 120 minut).
  • Token rotation: JWT je proti DB ověřen každé 2 minuty (změna role, plánu, hesla, re-consent → invaliduje JWT).
  • Email verification: povinná před prvním přihlášením (token TTL 24 h).
  • Password policy: min. 12 znaků, alespoň 3 ze 4 kategorií (malá/velká písmena, číslice, speciální znaky), blacklist běžných hesel.
  • Re-auth pro destruktivní operace: samoobslužné smazání účtu (čl. 17 GDPR) vyžaduje opětovné zadání hesla.
  • RBAC: 4 role – agent_solo (samostatný makléř), agent_office (makléř v kanceláři; vedoucí kanceláře má navíc adminOfOffice 1:1 relaci na Office), admin a ops (platforma). Tenant filtr přes agentId nebo officeId centralizovaný v src/lib/office/access.ts; per-participant ACL k dokumentům přes docCategoryOverride.

4. Rate limiting & ochrana proti abuse

  • Auth endpointy (register, verify-email, forgot-password, reset-password) – 5–10 pokusů / 15 min / IP.
  • GDPR self-service request-erasure – max 3× / 24 h / uživatel.
  • GDPR export, document upload/download, CRM import/export – per-IP limity.
  • Backend pro rate limit: in-memory + Upstash Redis fallback (přes UPSTASH_REDIS_REST_URL) – v produkci nezbytný pro multi-replika deployments.

5. Content Security Policy & frontend hardening

  • CSP nonce-based – per-request nonce + strict-dynamic (jediné inline scripty jsou Next.js hydration s aktuální nonce).
  • X-Frame-Options: DENY (kromě /esign-done, který se načítá v Signi iframe po dokončení podpisu).
  • Permissions-Policy: camera / microphone / geolocation zakázány (kromě /esign-done kde je camera potřeba pro identity verification e-podpisu).
  • Cookie banner: blokovací overlay; uživatel musí aktivně potvrdit / odmítnout. Re-ask po 365 dnech (EDPB 5/2020).
  • httpOnly portal token: token klientského portálu se nikdy nepředává v URL; middleware ho při návštěvě /portal/{token} přesune do httpOnly cookie.

6. Webhook security

  • Ověřené webhooky povinné v produkci. Resend přes HMAC-SHA256 (svix formát), Signi přes tajný token v URL ověřený časově konstantním porovnáním (Signi payload nepodepisuje). Stripe přes ověření podpisu. Bez konfigurovaného secretu route vrací 503.
  • Replay protection – Resend svix podpis obsahuje timestamp s tolerancí 5 minut.
  • Cron routy chráněné CRON_SECRET Bearer header. V produkci (NODE_ENV=production) je flag CRON_UNPROTECTED ignorován.

7. Audit log

  • Append-only model AuditLog – DB triggery brání UPDATE i DELETE z aplikace (kromě cron retention 3 roky).
  • Logované akce: login, logout, register, password reset, lockout, GDPR žádosti (export / erasure / rectify / marketing-consent), transakce, dokumenty, e-podpis, cron běhy.
  • Pro každou akci ukládáme: aktér, cíl, timestamp, IP adresa, metadata.

8. AML / KYC compliance

  • Plnění z. č. 253/2008 Sb. – modul automatizuje identifikaci klienta (§ 8) a kontrolu proti sankčním seznamům (§ 9). Generuje PDF protokol pro inspekci FAÚ.
  • Šifrování citlivých údajů: rodné číslo, číslo dokladu, adresa trvalého pobytu a jméno statutárního orgánu jsou v databázi šifrované AES-256-GCM (per-field, IV per write).
  • Žádný outbound k AI / třetím stranám: všechen screening probíhá lokálně v NemotiQ. Sankční seznamy se stahují přes denní cron z veřejných zdrojů přes agregátor OpenSanctions (datasety EU FSF, UN SC, OFAC SDN, otevřená PEP data), ale dotazy klienta nikdy neopouštějí náš systém. AI Act compliant.
  • Veřejné zdroje seznamů: EU konsolidovaný sankční list, UN Security Council, OFAC SDN (US Treasury), OpenSanctions PEP – všechny agregované přes OpenSanctions feed s denní synchronizací. ČNB národní sankce jsou pokryty jako mirror EU FSF (zák. 69/2006 Sb.).
  • Manuální verifikace ISIR a CEE: insolvenční rejstřík (https://isir.justice.cz/) a Centrální evidence exekucí (https://www.ceecr.cz/) ověřuje odpovědná osoba ručně – datum, jméno a volitelná poznámka se ukládají do auditního logu (akce aml.manual_verification.set) a zobrazují v PDF protokolu jako důkaz pro FAÚ.
  • Fuzzy matching algoritmicky: kombinace Levenshtein + Jaro-Winkler + token set ratio nad normalizovanými jmény (NFD diacritics strip, Cyrillic transliteration). Žádný ML model, žádný LLM.
  • Retence 10 let: § 16 AML zákona vyžaduje uchování identifikačních záznamů po dobu 10 let od ukončení obchodního vztahu. Po této době cron gdpr-cleanup záznamy automaticky maže (cascade smaže i screening runs a matches). Při GDPR výmazu uživatele (čl. 17) se AML data nemažou – pouze anonymizují (agentId → NULL) a dobíhají do uplynutí retenční lhůty.
  • Audit log: každá identifikace, screening, review, manuální ověření a download PDF protokolu je zaznamenán v immutable audit logu (PostgreSQL trigger blokuje UPDATE/DELETE).
  • Re-screening alert:týdenní cron znovu prohledá identifikace s verdiktem „clean“, „pending“ nebo „error“ starší 90 dní (stavy „review“ a „rejected“ čekají na rozhodnutí odpovědné osoby). Pokud se verdict přehodnotí na „review“ nebo „rejected“ (např. klient byl nově zařazen na sankční seznam), aplikace notifikuje odpovědnou osobu in-app notifikací s odkazem na detail.

9. Infrastruktura & dodavatelé

  • Hosting: Vercel (US, edge cache, EU regiony pro serverless functions); SOC 2 Type II certifikace.
  • Databáze: managed PostgreSQL – Supabase (PostgreSQL, region EU); šifrování at-rest, TLS, automatické zálohy s point-in-time recovery.
  • Úložiště souborů: Cloudflare R2 (objektové úložiště pro dokumenty transakcí, osobní knihovnu makléře šifrovanou at-rest, profilové fotografie a fotky nemovitostí); ukládání do EU regionu.
  • Subprocesoři: Resend (e-mail), Signi (e-podpis), Google (SSO a kalendář, opt-in), Vercel (hosting), Supabase (databáze), Cloudflare R2 (úložiště), Stripe (platby), Upstash (rate limiting), Sentry (chybové logy). DPA dle čl. 28 GDPR s každým, předávání mimo EU jen na SCCs / EU-US DPF. Úplný seznam: /zpracovatele.

10. Zálohy & disaster recovery

  • Automatické denní zálohy DB s point-in-time recovery (typicky 7–30 dní retence dle providera).
  • Stateless aplikační vrstva – výpadek instance není blocker; nasazení přes Vercel je zero-downtime.
  • Roadmap: dedicated disaster recovery playbook s RTO/RPO targets – sledováno v interní roadmapě (P2).

11. GDPR & retence

  • Práva subjektů: přístup (čl. 15), oprava (čl. 16), výmaz (čl. 17), přenositelnost (čl. 20) – implementováno přes self-service v /profil a admin endpoint pro výmaz.
  • Records of Processing dle čl. 30 GDPR – interní dokument docs/records-of-processing.md.
  • Retence – automaticky: expirované invitace 90 dní, revokovaný marketing consent → anonymizace 30 dní, audit log 3 roky, OutboundMessage anonymizace 3 roky, password reset / email verification tokens 30 dní po expiraci.
  • Retence – zákonná: faktury 10 let (§ 35 zák. o účetnictví), smlouvy z transakcí 10 let (§ 16 zák. č. 39/2020 Sb.).
  • Notifikace incidentu: ÚOOÚ + makléř do 72 hodin (čl. 33 GDPR), subjekt údajů bez zbytečného odkladu při vysokém riziku (čl. 34).

12. Vulnerability disclosure

Pokud jste objevili bezpečnostní zranitelnost, neotvírejte veřejný GitHub issue. Místo toho nás kontaktujte na info@nemotiq.cz s předmětem [SECURITY].

Co zahrnout:

  • Popis zranitelnosti a její dopad
  • Reprodukční kroky (krok za krokem)
  • Affected verze / commit hash
  • Kontakt na vás

Časový rámec naší odezvy:

  • Potvrzení přijetí: do 48 hodin
  • Triáž a fix plan: do 7 dní
  • Patch release: dle závažnosti (kritická = ASAP, střední = do 30 dní, nízká = další minor release)

Děkujeme všem, kteří přispívají k bezpečnosti NemotiQ. Pokud o to stojíte, rádi vás zařadíme do Hall of Fame na této stránce.

13. Roadmap (P2 priorita)

  • Externí penetrační test před produkčním launchem
  • Dedikovaný disaster recovery playbook s cíli RTO/RPO
  • 2FA / WebAuthn pro admin role
  • Path: ISO 27001 a SOC 2 Type II (pro enterprise klienty)
  • OWASP ZAP scan v CI/CD

Související dokumenty: Ochrana soukromí · DPA · Subprocesoři · Obchodní podmínky.