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.
• Heslo ven vede právě třemi cestami a každá z nich spotřebuje to jediné odhalení: get_intake_results se správným oprávněním, tlačítko Reveal u jedné položky v dashboardu (POST /v1/intakes/:id/items/:key/reveal, vyžaduje přihlášenou session vlastníka, audit zapisuje člověka, ne klíč) a ZIP vyžádaný s include_secrets=true. Dashboard záměrně odhaluje jednu položku na kliknutí a nikdy ne vykreslením stránky: pouhé otevření sběru podkladů nesmí hodnotu spálit.

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.

Přihlášení agenta bez kopírování klíče

Vedle vytvoření klíče v dashboardu a jeho zkopírování do konfigurace existují dva další způsoby, jak agentovi udělit přístup, aniž by tajný klíč vůbec prošel terminálem nebo přepisem konverzace.

Přihlášení přes zařízení (npx @briefgate/mcp login) se řídí RFC 8628. CLI si vyžádá device_code a krátký user_code, ten uživateli zobrazí a dotazuje /v1/auth/device/poll každých pár sekund. Oba kódy se ukládají jako hash, ne v otevřené podobě, a pokud je nikdo neschválí, vyprší po 10 minutách. Schválení vyžaduje aktivní session v dashboardu — panel, kde se klikne na Allow, musí být už přihlášený, takže flow nejde dokončit jen s kódem bez přístupu k účtu. Vrácený API klíč je po všech stránkách běžný API klíč: stejná oprávnění, stejné zneplatnění, stejný audit log, a v přehledu klíčů je označený klientem a názvem stroje, který o něj požádal (např. „Claude Code on laptop"), takže ho lze odlišit od klíčů založených přímo v dashboardu.

OAuth 2.1 stojí za hostovaným endpointem (https://mcp.briefgate.dev/mcp). Jde o standardní authorization-code flow s PKCE (jen S256) pro veřejné klienty — nikdy se nevydává ani nepřijímá client secret, což odpovídá tomu, čím MCP klient běžící na něčím počítači nebo v prohlížeči skutečně je. Dynamická registrace klienta (RFC 7591) je otevřená na /v1/oauth/register a metadata jsou publikovaná na https://api.briefgate.dev/.well-known/oauth-authorization-server. Redirect URI musí být https:// nebo loopback adresa, cokoli jiného se odmítne. Access tokeny jsou krátkodobé (1 hodina) API klíče a jdou zneplatnit stejně jako každý jiný klíč; refresh tokeny mají platnost 30 dní a při každém použití rotují — refresh token použitý po krádeži zneplatní ten legitimní, a krádež se v audit logu projeví jako dvojí použití stejného tokenu v krátkém okně. Authorization kódy, access tokeny i refresh tokeny se ukládají jako hash, nikdy v otevřené podobě.

Oba postupy končí stejně jako klíč založený v dashboardu: na stránce s klíči se objeví něco, co jde zneplatnit, a skončí to vždy jen v účtu toho, kdo byl v okamžiku kliknutí na Allow přihlášený do dashboardu.

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ěť.
• Šest pokusů s exponenciálním prodlužováním (1 min, 5 min, 30 min, 2 h, 6 h mezi pokusy), 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 150 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 mají strop na účet za hodinu (30 na každém tarifu) a — na tarifu Free — navíc na účet za den (10 pozvánek za den UTC; na Solo, Studio a Agency denní strop není). Ruční upomínky mají svůj vlastní, samostatný strop: 1 za hodinu na sběr podkladů a 20 za hodinu na účet, na každém tarifu — do denního stropu pozvánek se nepočítají. Přes API ani přes dashboard tak nejde z naší domény někoho zasypat poštou. Narazí-li na strop založení sběru podkladů, zůstane jako koncept (invitation_sent: false), místo aby volání selhalo; narazí-li na strop odeslání už existujícího konceptu, vrátí se 429 a koncept zůstane konceptem — v obou případech to odpověď řekne, místo aby potichu neodeslala.
• Jméno odesílatele ani vlastní znění e-mailu nesmí na žádném tarifu obsahovat odkaz (webovou adresu, holou doménu ani e-mailovou adresu) — jediný odkaz v e-mailu od BriefGate je tlačítko do portálu. Vlastní jméno odesílatele a znění e-mailu jsou samy o sobě placená funkce (viz Fakturace); tarif Free místo nich používá vestavěnou identitu odesílatele, takže si účet na Free nemůže do pole Od dát libovolnou značku.
• 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í chyb

Chyby aplikace se hlásí do Sentry (Functional Software, Inc.), s daty v EU — události jdou na de.sentry.io a jsou uložené v Německu. Co se posílá: typ chyby a stack trace, metoda a cesta požadavku (bez query stringu), request id a id účtu, pokud je známé. Co se nikdy neposílá: těla požadavků, cookies, hlavičku Authorization ani API klíče, e-mailové adresy (nahrazené za [email]), cokoli, co odeslal klient, ani hodnoty přístupů. V prohlížeči se hlásí jen neošetřené chyby JavaScriptu v dashboardu a portálu a neúspěšná volání API (jen stavový kód, bez těla odpovědi) — žádné breadcrumbs a query string v URL se před odesláním odstraní. Sentry eventy drží nejdéle 90 dní.

Sledování

Skoro žádné. Marketingový web počítá zobrazení stránek přes Cloudflare Web Analytics, které nenastavuje cookie ani neukládá do prohlížeče žádný identifikátor (zásady ochrany osobních údajů §12). Jinak nic: žádný tag manager, žádné nahrávání session, žádný reklamní pixel — a v dashboardu ani v klientském portálu nic navíc kromě sledování chyb popsaného výše. 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 privacy@briefgate.dev 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ě.