Bezpečnost

BriefGate chce po vašich klientech loga, texty — a hesla. To poslední mění, co tenhle produkt je: služba, která sbírá přístupové údaje, je infrastruktura, a infrastruktura musí jasně říct, před čím vás chrání a před čím ne.

Všechno níž popisuje systém tak, jak je dnes postavený. Kde ochrana neexistuje, tahle stránka to říká, místo aby to vynechala.

Čím BriefGate není

Není zero-knowledge. Hodnota typu secret se šifruje sealed boxem z libsodium ve chvíli, kdy dorazí, a privátní polovina toho klíčového páru žije v prostředí serveru, ne v databázi. Ukradený dump databáze tedy vydá jen šifrovaný text. Ale server, který hodnotu přijímá, ji přečíst umí — jinak by ji nemohl předat vašemu agentovi — takže útočník, který ovládne běžící proces, si heslo za letu přečte. Kdo tvrdí opak a přitom drží klíč, slibuje něco, co nemůže splnit.

Nemá žádnou certifikaci. Není tu ISO 27001, není SOC 2 a neproběhl externí penetrační test. BriefGate provozuje jeden člověk. Uvádíme to proto, že bezpečnostní posouzení má stát na tom, co existuje.

Hesla a přístupy od klientů

Položka typu secret je jediný typ pole, který má vlastní zacházení od začátku do konce.

• Hodnota se šifruje při přijetí sealed boxem z libsodium (crypto_box_seal) a nikdy se v otevřené podobě nezapíše na disk.
• Privátní klíč je držený v prostředí serveru a nikdy není v databázi, takže kompletní dump se dešifrovat nedá.
• Ke čtení je potřeba API klíč s oprávněním secrets:read nebo admin. Klíč bez něj se dozví jen to, že hodnota existuje.
• Vydá se jednou. Vyzvednutí je atomické: první čtení označí hodnotu za odhalenou a další čtení vrátí čas toho odhalení místo hodnoty. Pětiminutové okno po prvním odhalení dovolí stejnému klíči zopakovat stejné čtení, takže požadavek ztracený po cestě vás o hodnotu nepřipraví.
• Každé odhalení se zapíše do auditního logu i s klíčem, který ho provedl.
• Dashboard heslo zobrazit neumí. Neexistuje nikde obrazovka, která by ho vykreslila — jediná cesta ven je get_intake_results se správným oprávněním.

Co tím získáte: klient může poslat heslo do WordPressu vašemu agentovi, aniž by zůstalo ležet ve schránce, v chatu nebo v tiketu podpory.

Přihlašování a session

API klíče se schválně hashují SHA-256 a ne argon2id. Klíč je 256 náhodných bitů, takže není žádný slovník, kterým by šlo útočníka zpomalit, a heslový hash u každého požadavku agenta by stál desítky milisekund bez jakéhokoli zisku. Hesla, která si lidé vymýšlejí, dostávají argon2id.

Reset hesla zneplatní všechny session a nevydá novou, takže mezi útočníkem s resetovacím odkazem a účtem pořád stojí TOTP.

Soubory

• Doručují se jen přes podepsané URL platné 24 hodin. Ta URL nejdou uhodnout ani vypsat.
• Před zpřístupněním se skenují na malware. Soubor, u kterého sken selže nebo vyprší, se zadrží, ne pošle neskenovaný.
• Každý soubor nese kontrolní součet SHA-256, spočítaný při přijetí a vracený s výsledky, takže si ověříte, že to, co jste stáhli, je to, co klient nahrál.
• Uložené v Cloudflare R2 s omezením na jurisdikci EU.

Webhooky

Endpoint, který zaregistrujete, dostává všechny události celého účtu, takže se to bere jako rozhodnutí o účtu jako celku: přidat, smazat nebo otestovat ho smí jen vlastník účtu, a při vytvoření se vydá podpisový secret zobrazený jednou.

• Každé doručení je podepsané: X-BriefGate-Signature: t=<unix>,v1=<hmac-sha256> přes <timestamp>.<tělo>. Ověřte podpis, než obsahu uvěříte.
• Cílová adresa se znovu překládá a kontroluje bezprostředně před tím, než požadavek opustí server, ne jen při registraci. Kontrola pouze při registraci je mezera mezi kontrolou a použitím: jméno, které tehdy ukazovalo na veřejnou adresu, může teď ukazovat na 169.254.169.254.
• Privátní, loopbackové, link-local a unique-local rozsahy se odmítají, a to v zápisu IPv4 i v jeho IPv6-mapované podobě.
• Přesměrování se nenásledují, takže přes ně nejde požadavek zavést na privátní adresu.
• Každý pokus má časový limit 10 sekund; tělo odpovědi se čte nejvýš do 4 KB, aby nepřátelský endpoint nevyčerpal paměť.
• Sedm pokusů s exponenciálním prodlužováním, pak se doručení označí za neúspěšné a jde ho z dashboardu odeslat znovu ručně.
• 410 Gone z vašeho endpointu ho vypne — je to dokumentovaný způsob, jak se odhlásit ze strany příjemce.

Obsah nikdy neobsahuje odkaz do portálu. Ten odkaz je přístupové pověření do sběru podkladů vašeho klienta a chatový kanál má obvykle víc čtenářů než ten sběr podkladů.

Kde data leží

Kompletní seznam i s titulem předání pro každého z nich je ve zpracovatelské smlouvě.

Uchování a mazání

• Výchozí stav: obsah se maže 90 dní po dokončení. Nastavitelné od 1 do 3650 dní, na účtu i na jednotlivém sběru podkladů.
• retention.mode: "on_delivery" smaže obsah zhruba 24 hodin poté, co si váš agent vyzvedne výsledky — tedy ve chvíli, kdy druhá kopie na našem serveru přestává být služba a začíná být riziko. Používejte to na všechno, kde jsou přístupy.
• DELETE /v1/intakes/:id smaže sběr podkladů, všechny odeslané hodnoty, všechny soubory v R2 i celou historii upomínek, okamžitě a nevratně.
• Smazání účtu ho označí okamžitě a úplně; samotný výmaz proběhne po 30 dnech.
• Zálohy se šifrují nástrojem age na veřejný klíč ještě než opustí server, takže stroj, který zálohu zapisuje, ji neumí přečíst zpátky, a privátní polovina na něm uložená není. Drží se 14 dní — to je okno, ve kterém smazaná data ještě můžou v záloze existovat.

Auditování

Citlivé operace se zapisují do append-only auditního logu s aktérem, akcí, IP adresou a časovým razítkem: odhalení hesel, vytvoření a zneplatnění klíčů, změny sedadel, přihlášení. Aplikace nenabízí žádnou cestu, jak z něj mazat. Log svého účtu si přečtete v dashboardu nebo přes GET /v1/audit.

Zneužití a limity

• API požadavky: 60, 600 nebo 3000 za hodinu podle tarifu.
• Pozvánky a ruční upomínky mají strop na sběr podkladů i na účet, takže přes API ani přes dashboard nejde z naší domény někoho zasypat poštou. Při vyčerpání stropu se sběr podkladů založí jako koncept a odpověď to řekne, místo aby potichu neodeslala.
• Upomínky respektují noční klid a zastaví se při tvrdém odrazu nebo stížnosti na spam — na odraženou adresu se už nikdy neupomíná.

Sledování

Žádné není. Žádná analytika, žádný tag manager, žádné nahrávání session, žádná služba na hlášení chyb, žádný reklamní pixel — ani na marketingovém webu, ani v dashboardu, ani v klientském portálu. Jediné cookies jsou ty, díky kterým funguje přihlášení a portálová session; jsou vypsané v zásadách ochrany osobních údajů.

Hlášení zranitelnosti

Napište na [email protected] a přiložte dost detailů, aby to šlo zopakovat. Odpoví vám člověk. Nepouštějte prosím automatické skenery proti produkci a netestujte na cizím účtu ani portálu — nahlaste to a prověří se to pořádně.