Jak bezpečně získat přístupy od klienta

Poslat přístup e-mailem nebo přes WhatsApp znamená heslo natrvalo uložit do konverzace. Tady jsou bezpečnější varianty, od nejhorší po nejlepší.

Jaké přístupy vlastně budete potřebovat

Ne každý projekt potřebuje všechno z tohohle seznamu, ale většina webových zakázek se dotkne aspoň tří nebo čtyř položek:

• Administrace hostingu — cPanel, Plesk, nebo vlastní rozhraní poskytovatele (na českém trhu typicky Wedos, Active24, Forpsi a podobní).
• Registrátor domény / DNS — kvůli přidání záznamů pro odesílání pošty, ověření vlastní domény, nebo přesměrování domény na nový hosting.
• Administrace redakčního systému — WordPress, Shopify, Webflow nebo cokoliv, na čem web už běží, pokud ho předěláváte místo stavby od nuly.
• Google Analytics a Search Console — obvykle se řeší přidáním uživatele do stávající vlastnosti, ne předáním hesla.
• Firemní účty na sociálních sítích — Facebook Business Manager, Instagram nebo Profil firmy na Googlu, pokud se projekt dotýká reklamy nebo recenzí.
• Platební brána — Stripe, GoPay, Comgate — jen pokud zapojujete platby, a obvykle nejcitlivější položka ze všech.

Společný jmenovatel: tohle jsou skoro nikdy věci, které klient předá jednou a zapomene na ně. Většina z nich umí pozvat druhého člověka s konkrétní rolí, což je důležité pro to, co následuje. Pokud sestavujete kompletní seznam toho, co webový projekt potřebuje kromě přístupů, mrkněte na checklist podkladů pro webový projekt.

Proč ne e-mail nebo WhatsApp

Heslo poslané e-mailem nezmizí, jakmile projekt skončí. Zůstane v klientově Odeslané poště, ve vaší Doručené, na obou telefonech, pokud mají synchronizovanou poštu, a v každé záloze, kterou kdy kdokoliv z vás udělal — natrvalo, v čitelném textu, prohledatelné kýmkoliv, kdo se později dostane do kteréhokoliv z účtů. WhatsApp je v přenosu o něco lepší (je end-to-end šifrovaný), ale výsledek je stejný: zpráva nikdy neexpiruje a odemčený telefon nechaný na stole ukáže heslo komukoliv, kdo ho zvedne.

Ani jeden kanál nebyl stavěný na to, aby držel přihlašovací údaje. Oba byly stavěné na to, aby držely konverzaci, a heslo napsané do konverzace se chová přesně jako zbytek konverzace — zálohuje se, přeposílá, prohledává a cituje zpátky do odpovědí, aniž by to kdokoliv myslel zle.

To samé platí i pro sdílené poznámky a týmové chaty typu Slack nebo Microsoft Teams — heslo vložené do kanálu tam zůstává stejně natrvalo a je navíc viditelné komukoliv, kdo do kanálu má přístup teď, nebo ho dostane kdykoliv později.

Varianty od nejhorší po nejlepší

1. Obyčejný e-mail nebo zpráva v chatu

Heslo se napíše přímo do těla e-mailu nebo zprávy na WhatsApp. Funguje to v tom smyslu, že teď heslo máte. Všechno ostatní na tom je riziko: žádná expirace, žádný záznam, kdo další to viděl, žádný způsob, jak poznat únik dřív, než se něco pokazí.

Použijte tuhle variantu, jen když nic jiného není k dispozici a účet je opravdu nízkorizikový — třeba účet na zdarma newsletterový nástroj, ne hosting nebo platby.

2. Sdílená položka ve správci hesel

Klient vás přidá jako spolupracovníka na jednu položku v 1Password, Bitwarden nebo podobném nástroji, místo aby heslo někam psal. Tohle je reálné zlepšení: hodnota se nikdy neobjeví v e-mailu a odebrání přístupu je jedno kliknutí místo resetu hesla. Háček je v tom, že to předpokládá, že klient už správce hesel používá a je ochotný nastavit sdílení správně, což u spousty malých klientů prostě není hotové. Navíc vám do trezoru přistane klientovo skutečné, trvalé heslo, ne něco omezeného jen na projekt.

3. Dočasný účet s minimálními právy

Místo klientova vlastního přihlášení vám klient vytvoří druhý účet — pozvánku spolupracovníka ve WordPressu, položku v „Uživatelích" na hostingu, člena týmu v Google Analytics — omezenou jen na to, co úkol potřebuje, a jen na dobu trvání projektu. Většina platforem z předchozího seznamu tohle nativně podporuje: WordPress má role pod úrovní Administrátor, Google Analytics má úrovně přístupu na jednotlivou vlastnost, většina hostingů podporuje druhý účet cPanel nebo FTP.

Tohle je varianta, po které sáhnout jako po výchozí. Odpovídá na obě důležité otázky — co ten účet umí a kdy přestane existovat — aniž by po klientovi chtěla osvojit si nový nástroj.

4. Jednorázový, sám vypršující přístup

Pro případy, kdy dočasný účet nejde založit — hosting bez podpory víc uživatelů, jediné admin přihlášení bez rolí — je lepší variantou než „pošlete mi heslo" kanál stavěný přímo na to, předat jeden údaj přesně jednou: klient ho napíše do pole, které ho okamžitě zašifruje, vy si ho jednou vyzvednete, a po tom vyzvednutí ho nevidí nikdo — ani klient, když otevře tutéž stránku znovu. Nikdy neleží v e-mailu, protože v žádném e-mailu vůbec nebyl.

Přesně takhle funguje typ položky secret v BriefGate: hodnota se zašifruje v prohlížeči ještě před uložením, odhalí se vašemu agentovi nebo dashboardu přesně jednou a pak zmizí z obou míst, ať už jste si ji stihli zapsat, nebo ne. Pokud přes BriefGate na stejném projektu sbíráte i logo a pár textů, přidání jedné položky typu secret na „přístup do současného webu" nahradí samostatnou zprávu na WhatsAppu, kterou byste jinak poslali zvlášť.

Jak o to požádat, aby to neznělo jako přednáška o bezpečnosti

Většina klientů o ničem z tohohle nepřemýšlela a stěna bezpečnostních výhrad působí jako komplikace, ne jako péče. Žádost rámujte kolem toho, co má klient udělat, ne proč je e-mail nebezpečný:

„Mohl byste mě přidat jako Administrátora na váš WordPress (Uživatelé → Přidat nového) místo posílání hesla? Zabere to asi minutu a znamená to, že vaše skutečné heslo nikdy neuvidím."

Tím dostanete účet s minimálními právy, aniž byste jednou použili slovo „bezpečnost". Pokud platforma opravdu nemá víceuživatelský režim, přejděte na žádost o hodnotu přes trezor nebo jednorázový odkaz, který používáte, s jednou větou vysvětlení: „aby to pak neleželo v e-mailu."

Po předání: checklist

Získat přístup je ta snazší polovina. To, co se stane po skončení projektu, je místo, kde sedí většina skutečného rizika — zapomenutý spolupracovnický účet je funkční přihlášení, které nikdo nehlídá.

• Vyměňte heslo, a to nejen u účtů, které jste vytvořili vy — u čehokoliv, čeho se mohlo dotknout klientovo původní heslo, pokud bylo někdy napsané do e-mailu nebo chatu, byť jen dočasně.
• Odeberte svůj dočasný účet nebo pozvánku spolupracovníka ve chvíli, kdy je práce hotová, ne „až budu mít čas". Otevřený úkol smazat přístup později je přístup, který ve skutečnosti nikdy nekončí.
• Ověřte, že klient pořád drží hlavní vlastnictví — původní administrátorský účet, přihlášení k registrátorovi domény, vlastníka účtu Stripe — aby nic v jeho podnikání nezáviselo na tom, že váš účet zůstane aktivní.
• Zapište si, co bylo komu uděleno a kdy, byť stručně: které účty, jaká role, k jakému datu byl přístup zrušený. Za půl roku, až se klient zeptá „kdo má přístup k našemu webu", chcete odpověď jinou než „myslím, že jen my".
• Řekněte klientovi, co dělat s tím, co bylo poslané nebezpečně, než jste do toho vstoupili vy. Pokud heslo dorazilo e-mailem dřív, než jste stihli navrhnout alternativu, řekněte to na rovinu a doporučte ho změnit — pětivteřinové upozornění bez výčitek nic nestojí a mezeru uzavře.

Tenhle poslední bod se snadno vynechá, protože v tu chvíli už je projekt hotový a pozornost je jinde. Je to ale přesně ta chvíle, kdy staré heslo ještě funguje a nikdo ho nehlídá.

Kde do toho zapadá BriefGate

Všechno výše funguje s běžnými účty a správcem hesel — žádný nástroj k tomu není potřeba. Zdlouhavé je to teprve, když to opakujete projekt za projektem: pamatovat si, že se má žádat o roli místo hesla, urgovat klienta, když zapomene, a udržet výsledný přístup mimo vlastní e-mail. BriefGate zařadí žádost o přístupy do stejného checklistu jako logo a texty — klient vyplní zamaskované pole, vy si ho jednou vyzvednete přes agenta nebo dashboard, a ze strany BriefGate v tu chvíli zmizí. Podívejte se, co BriefGate dělá, nebo si přečtěte doprovodný článek o žádosti o zbytek podkladů k projektu, pokud jsou přístupy jen jednou položkou z delšího seznamu.