Začněte mapou prostředí a přístupu
Popište, kde vzniká kód, kde se sestavuje obraz, kde běží testy a kdo smí vydat produkční verzi. Vývoj, staging a produkce nemají sdílet stejné tajné klíče ani databázi. Každé prostředí potřebuje jasný účel a pravidlo, která data se do něj smějí dostat. Produkční kopie obsahující osobní údaje není neškodný testovací vzorek. Pro lidi i automatizaci stanovte nejmenší potřebná oprávnění a způsob jejich odebrání.
U VPS projektu často postačí jednoduchý model: verzovaný repozitář, opakovatelný build, Compose a jeden dobře popsaný release postup. Složitější orchestrátor není automatickou bezpečnostní výhodou. Důležitější je vědět, kdo ovládá server, registr obrazů, DNS, zálohy a přístupové klíče. Tyto role oddělte od veřejného webu. Účet používaný pro čtení obsahu nemá být současně účtem pro změnu infrastruktury.
Artefakt musí odpovídat schválenému zdroji
Sestavujte z konkrétní revize kódu a zaznamenejte identifikátor výsledného artefaktu. Když je potřeba vrátit vydání, musíte znát obraz, databázové schéma a konfiguraci, které k sobě patřily. NIST SSDF popisuje ochranu komponent před neoprávněnou změnou a začlenění bezpečnostních postupů do vývoje. Pro malý tým to znamená kontrolu změn, reprodukovatelný build a evidenci závislostí v přiměřeném rozsahu, nikoli množství podpisových služeb bez vlastníka.
Před vydáním spusťte testy kritických cest, kontrolu typů a závislostí a ověřte, že se do obrazu nedostaly místní soubory s klíči. Automatické kontroly mají selhat viditelně. Výjimka z kontroly musí mít důvod, osobu, která ji schválila, a datum přehodnocení. Slepé spuštění příkazu v nové verzi bez přečtení migračního kroku není release postup. Změnu konfigurace posuzujte stejně jako změnu kódu, protože může změnit veřejnou dostupnost i přístup k datům.
Tajemství nepatří do repozitáře ani logu
Hesla, API klíče a podpisové materiály uchovávejte mimo verzované soubory. Docker dokumentuje, že Compose secrets poskytují jednotlivým službám souborový přístup k přidělenému tajemství, což může snížit nechtěné šíření hodnot v prostředí procesů. Zvolený způsob musí odpovídat aplikaci a provoznímu postupu; jednoduchý lokální env může být praktický pro vývoj, ale pro veřejný server je třeba posoudit, kdo soubor a výpis konfigurace uvidí. Nikdy jej neposílejte do issue nebo screenshotu.
Pro každý klíč určete vlastníka, účel, místo uložení a postup rotace. Při úniku nestačí smazat řádek z posledního commitu; kompromitovaný klíč se musí zneplatnit u poskytovatele a zkontrolovat historie přístupu. Do logu ukládejte identifikátor operace a typ chyby, ne celé hlavičky požadavku nebo token. Stejná pravidla platí pro zálohy a administrátorské skripty. Jejich kopie mohou obsahovat citlivější data než veřejná aplikace.
Kontrolní brána před nasazením
Před uvolněním ověřte, že verze prošla funkčními testy, že kritické přístupy fungují jen pro správné role a že aplikace má očekávaná bezpečnostní nastavení. OWASP ASVS dává strukturu požadavkům pro ověřování webových aplikací; konkrétní rozsah musí odpovídat produktu a riziku. Kontrola by měla pokrýt přihlášení, oprávnění, validaci vstupů, práci se soubory a odchozí volání, pokud je systém používá. Záznam výsledku má být dohledatelný u příslušné revize.
Součástí brány je i provoz: healthcheck, monitorování chyb, místo pro zálohu a člověk dostupný pro první hodiny po vydání. U změny databáze zkontrolujte kompatibilitu staré a nové verze aplikace. Předem určete, co znamená úspěšné vydání: počet chyb, odezva, dokončení důležitých transakcí a stav front. Když výsledek nelze měřit, může vadná verze zůstat na serveru i přesto, že kontejner hlásí běh.
Release musí mít cestu zpět
Použijte postupný release tam, kde to objem a architektura dovolí. U menšího webu může stačit připravená předchozí verze, krátké ověřovací okno a možnost vrátit routing nebo kontejner. U datových migrací však samotný návrat obrazu nestačí. Změny tabulek navrhujte kompatibilně, náročné převody oddělte a u nevratných kroků mějte plán obnovy. Před prvním ostrým nasazením otestujte návrat v prostředí podobném produkci.
Zapište, kdo rozhoduje o rollbacku a jak zabrání duplicitnímu zpracování událostí během přepnutí. Po návratu porovnejte stav front, databáze a externích systémů. Uživatel může mezitím dokončit operaci, kterou starší verze nezná; takový případ vyžaduje došetření. Bez tohoto pohledu je rollback jen změna souboru, ne obnova služby. Každý incident by měl přidat konkrétní test nebo kontrolu, aby stejný typ chyby nebyl opakován.
Monitoring a obnova jsou součást řešení
Sledujte dostupnost zvenku, chyby aplikace, stav databáze, kapacitu disku a stáří poslední ověřené zálohy. Alert musí mít adresáta a postup, jak poznat, zda vyžaduje okamžitý zásah. Tisíce upozornění bez odpovědnosti zhoršují bezpečnost, protože důležité signály zapadnou. Logy propojujte identifikátorem požadavku a pravidelně kontrolujte jejich uchování. Zvlášť zaznamenejte neúspěšná administrátorská přihlášení a neočekávané změny konfigurace.
Záloha se považuje za funkční, až když z ní lze obnovit potřebná data v přijatelném čase. Ověřte i konfiguraci, verzi aplikace a klíče nutné ke čtení zálohy. Test obnovy provádějte mimo produkční databázi a po něm ověřte konkrétní záznamy a důležité funkce. Pro každý typ dat stanovte hranici přijatelné ztráty a dobu návratu podle skutečného dopadu. Pokud plán závisí na jednom člověku, který zná heslo nazpaměť, není dostatečně předatelný.
Přijetí řešení a hranice odpovědnosti
První pilot může nasadit jednu nevýrobní verzi a projít celý postup od změny v repozitáři po alarm a návrat. Výstupem má být krátký, ověřený návod, seznam přístupů, důkazy testů, schéma záloh a vlastníci jednotlivých kroků. EXCOIN zde netvrdí certifikaci klientského prostředí ani garanci odolnosti vůči útoku. Konkrétní bezpečnostní požadavky a rozsah případného externího testu se určují podle systému, dat a smluv.
Při předání ukažte provozovateli reálnou situaci: po vydání stoupá počet chyb, databáze je zdravá, ale jedna klíčová cesta selhává. Dokáže zjistit, která verze běží, zastavit nový provoz, vrátit správný artefakt a došetřit rozpracované požadavky? Pokud ano, nasazení má praktickou hodnotu. Pokud odpověď závisí na nezdokumentovaném zásahu vývojáře, práce na bezpečném provozu ještě není hotová.
Před ostrým spuštěním projděte návod s člověkem, který jej nepsal. Nechte ho najít poslední schválenou verzi, kontakt pro incident a místo uložení zálohy, aniž mu budete napovídat. Taková zkouška odhalí skryté závislosti na účtech, které mají pouze vývojáři, nebo na souborech uložených na jednom notebooku. Po opravě postupu opakujte nácvik. Zároveň určete, kdo pravidelně kontroluje platnost domény, certifikátu a přístupových klíčů. Tyto věci mohou selhat i bez nového nasazení aplikace. Dobré předání musí fungovat i během běžné nepřítomnosti původního autora.