Jak se ukládají přístupy od klienta

Aktualizováno: · Autor: Radim Sekera

V téměř každém projektu přijde chvíle, kdy je potřeba heslo. Přístup do administrace WordPressu, API klíč k registrátorovi domény, FTP přístupy k hostingu, kterého se roky nikdo nedotkl. Obvyklá cesta takové hodnoty je e-mail, zpráva v chatu nebo sdílený dokument — všechny nechávají fungující přístup v otevřené podobě ležet donekonečna, čitelný pro kohokoli s přístupem do té schránky, kanálu nebo disku.

Typ položky secret v BriefGate existuje proto, aby tahle cesta nemusela být výchozí. Tahle stránka vysvětluje přesně, co se stane s přístupem, který klient vyplní na portálu, jakou ochranu to přináší — a stejně důležité, jakou ne. Radši abyste znali přesně, kde je hranice, než abyste předpokládali silnější záruku, než jaká skutečně existuje.

Co se stane, když klient vyplní pole typu secret

Na portálu se položka typu secret zobrazí jako zamaskované heslové pole s ikonou zámku a poznámkou: „Šifrováno — zobrazí se pouze jednou vašemu dodavateli.“ Není tu žádné „zobrazit vše“, žádná stopa do schránky a žádný způsob, jak hodnotu přes portál po odeslání znovu získat.

Když ji klient odešle, hodnota se přenese na server přes HTTPS. Hned po přijetí — ještě než se cokoli zapíše do databáze — se zašifruje pomocí libsodium sealed box (crypto_box_seal) veřejným klíčem BriefGate. V databázi se uloží jen ciphertext. Plaintext existuje v paměti serveru jen po dobu potřebnou k zapečetění a později, krátce, při odhalení — nikdy se nezapisuje na disk ani se neobjeví v logu.

Privátní polovina toho páru klíčů žije jen v konfiguraci prostředí serveru. Nikdy se neukládá do databáze. Ukradený dump databáze — každý řádek, každá tabulka — vydá jen ciphertext a nic víc.

Vlastnost, kterou nemáme

Tady je ta upřímná část: BriefGate není zero-knowledge a tohle není end-to-end šifrování. Oba pojmy v praxi znamenají totéž — provozovatel služby nemá k dispozici žádný klíč, kterým by data dešifroval. To tady neplatí. Privátní klíč, který otevírá zapečetěný secret, žije na serveru BriefGate, a ten samý server, který přijímá heslo vašeho klienta, je server, který ho po správném požadavku umí dešifrovat. Produkt, který přijímá heslo za sealed boxem a zároveň drží klíč, jímž se otevírá, není zero-knowledge — bez ohledu na to, jak je ten box popsaný.

Stojí za to říct přesně proč, místo aby to vypadalo jako zkratka. Skutečné end-to-end šifrování vyžaduje klíč, který drží jen zamýšlený příjemce, vygenerovaný a uchovávaný na zařízení, které ho nikdy nepředá serveru mezitím. Portál BriefGate je záměrně postavený tak, že klient nepotřebuje účet, aplikaci ani žádné nastavení — otevře odkaz na tom, co má zrovna po ruce, telefonu nebo notebooku, a vyplní pole. V takovém toku není kde by klientem drženému klíči vzniklo místo k životu: žádná trvalá identita, k níž by se přivázal, žádný instalační krok, kde by vznikl, žádná relace, která by přežila jedno odeslání formuláře. A i kdyby se takový klíč na klientově zařízení pro tu jednu návštěvu podařilo vyčarovat, musel by se pak dostat k tomu, kdo přístup čte později — k vám nebo vašemu agentovi, který se na intake dotazuje přes API i za několik dní. To by musel projít bez toho, aby ho server po cestě viděl — podstatně těžší problém, než jaký si tenhle produkt bere na starost. Radši než tu vlastnost předstírat, ji netvrdíme.

To, co zapečetění hned po přijetí skutečně přináší, je reálné, jen užší: ochrana proti kompromitované databázi, uniklé záloze nebo špatně nakonfigurovanému úložišti — kategoriím incidentů, které tvoří většinu úniků přístupů. Nechrání secret před serverem, který je plně kompromitovaný útočníkem schopným číst paměť procesu nebo zavolat vlastní dešifrovací cestu BriefGate. Celý detail téhle hranice, spolu se zbytkem bezpečnostního postoje platformy, je na stránce Bezpečnost.

Odhaleno přesně jednou

Secret lze dešifrovat přesně jednou, a to kteroukoli ze tří cest — všechny tři čerpají ze stejného jednorázového odhalení:

Kdo je z těchhle cest první, dostane plaintext. Každá další cesta se dozví, že přístup už byl odhalen. Existuje pětiminutové ochranné okno, které dovolí stejnému volajícímu — stejnému API klíči, nebo stejné relaci vlastníka v dashboardu — zopakovat vlastní volání a dostat hodnotu znovu, aby výpadek spojení mezi naší odpovědí a vaším procesem přístup nezničil. Tohle okno se sleduje podle identity volajícího: agent, který odhalí přístup přes API, a vlastník, který o chvíli později klikne na Zobrazit, ho spolu nesdílejí. Každé odhalení, ať už jakoukoli cestou, se zapíše do auditního logu s aktérem, IP adresou a časovým razítkem.

Když odhalení spotřebujete omylem

Stejnou položkou zpátky cesta nevede. Druhé volání dostane secret_unavailable: true (API) nebo already_revealed: true (dashboard), spolu s časem původního odhalení. Jediná záchrana je `request_revision` — požádat klienta, ať přístup zadá znovu. Stejná záchrana platí, pokud secret prostě vyprší (30 dní od odeslání, pokud ho nikdo včas neodhalí) dřív, než si ho někdo vyzvedne.

Přístup je určený k přečtení, ne k protečení

Integrace, která přehrává každý krok běhu — historie úloh v Zapieru, log scénáře v Make — je špatné místo pro jedinou čitelnou kopii přístupu, protože záznam z cizího execution logu zpětně smazat nejde. get_intake_results proto přijímá exclude_secrets=true přesně pro tenhle případ: všechny ostatní položky se vrátí normálně a secret položky se ohlásí jako stále dostupné místo odhalené — netknuté, čekající na kliknutí v dashboardu nebo na záměrné pozdější volání. Stažení intaku jako ZIP (GET /v1/intakes/:id/download) se řídí stejným výchozím nastavením — necháte-li include_secrets vypnuté, soubor obsahuje všechno ostatní a přístupy v něm prostě chybí; nastavíte-li ho na true, samotné stažení se stane odhalením a hodnoty se zapíší do podklady.pdf. Je to pokaždé záměrná, explicitní volba, ne něco, do čeho lze omylem spadnout.

Z toho plyne doporučený vzorec: nechte agenta sbírat soubory, texty a strukturované odpovědi automaticky, a nechte člověka otevřít dashboard a kliknout na Zobrazit ve chvíli, kdy je přístup jako přihlašovací údaje k hostingu skutečně potřeba zadat do serveru nebo administrace — jednou, někým, místo aby putoval krok za krokem skrz nástroj pro automatizaci.

Co vám to přináší

Klientovo heslo do WordPressu, API klíč nebo přihlašovací údaje k hostingu nemusí skončit v e-mailovém vlákně, na Slack kanálu nebo v ticketu podpory, kde přežijí svou užitečnost o celé roky. Přijde zašifrovaný, zůstává zašifrovaný při uložení, dá se přečíst přesně jednou tím, kdo ho potřebuje, a každé takové přečtení se loguje. To je reálné zlepšení oproti tomu, jak se přístupy obvykle pohybují mezi klientem a tím, kdo mu staví web — i když to, jak je popsáno výše, nedosahuje záruky, že BriefGate sám hodnotu za letu nevidí. Úplnou referenci API najdete na stránce Trezor na přístupy, a jak tohle zapadá do zbytku platformy, na stránce Bezpečnost.

Související návody

Nejste vývojář? Podívejte se na stránku pro sběr podkladů nebo projděte všechny návody.