Svoji první appku jsme si už navajb-kodili. Co jí teď dát aspoň základní bezpečnost?

První verze interní appky dnes vznikne za odpoledne. Jednoduchá skládačka (GitHub, testy, Infisical, Proxmox, MikroTik, Cloudflare, monitoring, zálohy) jí dá základní řád a bezpečnost, aniž byste stavěli datové centrum.

První verze interní appky dnes může vzniknout klidně za odpoledne. A to není přehánění.

Jasně, než se z ní stane něco, co opravdu používá celá firma, většinou strávíte daleko víc času laděním. Realita prostě bývá delší než první demo.

Ale stejně je to změna.

Ještě nedávno jste na podobný interní nástroj psali poptávku a čekali týdny nebo měsíce. Dnes otevřete AI, popíšete problém a za chvíli máte něco, co už docela funguje.

A právě tady často začíná druhá část příběhu.

Appka funguje. A co teď?

• Kde vlastně běží?
• Jak se nasazuje nová verze?
• Kde jsou hesla?
• Kdo má přístup?
• Je aplikace někde otevřená do internetu?
• Co všechno může dělat AI?
• A co se stane, když se něco pokazí?

Tohle není článek pro firmy, které mají ambici stavět další unicorn. Je to spíš pro CEO a majitele menších a středních firem, kteří si už něco pomocí AI navajb-kodili a teď si říkají:

„OK. A nemáme to náhodou celé trochu špatně?"

Upřímně? Možná trochu ano. A je to normální.

K tomuhle jsme postupně dospěli i my s našimi klienty. Někteří byli na začátku s vibe codingem o dost rychlejší, než jsme si dokázali představit. Takže se část věcí ladila až zpětně. Nemáme patent na rozum.

Ale postupně nám z toho vznikla poměrně jednoduchá skládačka, která dává základní řád a bezpečnost interním aplikacím, aniž byste kvůli jedné appce museli stavět datové centrum.

A přesně o tom bude tenhle malý seriál.

1. Jedna verze pravdy: GitHub

Veškerý kód je na jednom místě. U nás v GitHubu.

Co není v Gitu, neexistuje.

Ne kvůli nějaké vývojářské akademické čistotě. Prostě proto, že chcete vědět:

• co přesně běží,
• co se změnilo,
• kdo to změnil,
• a případně se vrátit zpátky.

A jedno důležité pravidlo: na produkčním serveru se kód ručně neupravuje. Ani „jen jeden řádek". Ani „jen teď rychle".

Jakmile začnete opravovat věci přímo na serveru, velmi rychle můžete skončit se dvěma verzemi reality. Jedna je v GitHubu. Druhá někde na produkci. A rozdíl mezi nimi samozřejmě objevíte ve chvíli, kdy něco přestane fungovat.

2. Vývoj → test → produkce

Nový kód neposíláme rovnou uživatelům. Máme jednoduchou cestu: vývoj → test → produkce.

Kód na server nikdo ručně nekopíruje. O nasazení se stará GitHub Actions. Než se změna dostane do produkce, musí:

• projít automatickými testy,
• člověk ji ručně vyzkoušet na testovacím prostředí,
• někdo nasazení schválit.

Ne proto, že chceme vyrábět procesy. Ale protože když dokáže AI něco vytvořit velmi rychle, chceme mít stejně jednoduchou brzdu pro případ, že něco velmi rychle rozbije.

3. Hesla a přístupy: Infisical

Tohle je věc, kterou bych si zkontroloval možná jako první. Nemáte někde v kódu:

• heslo do databáze,
• API token,
• přístup k nějaké službě,
• soubor .env s produkčními údaji, který někdo omylem poslal dál?

My na to používáme Infisical. Je to trezor pro hesla, tokeny a další citlivé údaje. Aplikace si potřebné údaje vytáhne při spuštění. Kód je nemusí obsahovat.

AI navíc nemusí znát skutečné hodnoty. Stačí jí vědět, že aplikace například potřebuje přístup k databázi.

A když pak potřebujete nějaký přístup změnit, řešíte ho na jednom místě. Ne hledáním v pěti souborech a přemýšlením, kde jste ho ještě použili.

4. AI může pomáhat. Ale nemusí mít přístup úplně všude.

Dokud připravujeme prázdný server, může AI pomáhat poměrně hodně:

• založit prostředí,
• nastavit Docker,
• připravit monitoring,
• navrhnout a spustit potřebné příkazy.

Jakmile se ale na server dostanou skutečná produkční data a citlivé údaje, přímý přístup AI končí.

Protože „ať se AI aspoň podívá do logů" zní docela nevinně. Jenže jeden nešťastně zvolený příkaz může zobrazit mnohem víc, než jste čekali.

Od té chvíle tedy AI příkazy navrhuje. Kontroluje a spouští je člověk.

5. A kde to celé běží?

Tady přichází dobrá zpráva. Nemusíte kupovat server za milion ani stavět vlastní datové centrum.

Na začátku klidně vezmete starší počítač, který už máte. Na něj dáte Proxmox. Proxmox vám umožní jeden fyzický počítač rozdělit na několik samostatných virtuálních serverů. Na nich pak běží vaše aplikace, typicky v Dockeru.

My máme vlastní hardware a Proxmox cluster v datovém centru. Ale máme k tomu své důvody a běží nám na tom i další věci. Pro malou interní appku pro pár lidí by to byl zbytečný overkill.

Začněte jednoduše. Ověřte si, že vám celý přístup dává smysl. Až pak řešte větší železo.

6. A síť? MikroTik.

Vedle Proxmoxu se hodí mít něco, co drží pohromadě síť. U nás je to třeba levný MikroTik, případně cokoliv od FortiGate a podobně.

Přes něj řešíme síť a její oddělení (segmentaci). Testovací prostředí nemusí vidět do produkčního. Jedna aplikace nemusí automaticky komunikovat se vším ostatním.

A hlavně: nepotřebujete všechno vystavit do internetu.

7. Cloudflare: když je aplikace interní, tak ať zůstane interní

Tady nám dává velký smysl Cloudflare Tunnel.

• Server nemusí mít veřejnou IP adresu.
• Nemusíte kvůli aplikaci otevírat veřejné porty.
• Spojení navazuje server směrem ven.
• A uživatelé se dostanou jen k tomu, co opravdu potřebují.

Pokud používáte Microsoft 365, dává smysl přihlášení přes Microsoft Entra ID s MFA (co u MFA bývá nejčastěji špatně, jsme sepsali zvlášť). U jednodušší interní aplikace ale může být rozumnou alternativou i OTP kód.

Hlavní princip je jednoduchý: když je to interní aplikace, neměla by být otevřená bez přihlášení.

A argument „tu adresu přece nikdo nezná" není bezpečnostní strategie.

Protože vaše appka bude mít chyby

A to není kritika AI. Je to realita.

Když si aplikaci stavíte pomocí AI a nejste profesionální vývojářský tým se security oddělením, pravděpodobně tam nějaké chyby budou. My je máme taky.

Proto bych byl opatrný s momentem: „Funguje to. Tak to pustíme veřejně."

Je to interní nástroj? Tak ho nechte interní. A co je z vaší firmy zvenku vidět už teď, vám za pár minut ukáže náš on-line bezpečnostní audit zdarma.

8. Jak poznáte, že to celé ještě funguje?

Na dostupnost aplikací používáme Uptime Kuma. Když appka spadne, chceme se to dozvědět dřív než uživatel.

Na dohled nad servery používáme Wazuh. Sleduje například přihlášení, změny v systému a bezpečnostní události.

Jen jedna důležitá poznámka:

Monitoring, který nikdo nesleduje, je jen dekorace.

9. A samozřejmě zálohy

Ve chvíli, kdy vám interní aplikace začne opravdu šetřit čas, začněte ji zálohovat. Proxmox na to má vlastní nástroje.

Ideálně ale mějte alespoň jednu kopii i mimo samotný Proxmox. Protože záloha uložená na stejném místě jako věc, kterou zálohujete, vám při větším problému nemusí moc pomoct.

10. Takže co vlastně potřebujete?

Na začátek vlastně překvapivě málo:

A hlavně: nemusíte to všechno postavit najednou.

1. Vezměte jeden počítač.
2. Rozjeďte Proxmox.
3. Vytvořte jednu VM. Do ní Docker.
4. Postavte jednu interní aplikaci.
5. Dejte kód do GitHubu.
6. Citlivé údaje dejte do Infisicalu.
7. Aplikaci nechte interní. Přidejte přihlášení.
8. Nastavte zálohu.
9. Až pak přidávejte další věci.

Vibe coding vám umožní jít opravdu rychle. Trocha základního řádu pak pomůže, aby se z rychlého prototypu nestala aplikace, na kterou se všichni bojí sáhnout.

V dalších dílech

Tenhle setup rozebereme prakticky. Krok za krokem. Od hardwaru přes Proxmox, MikroTik a Docker až po GitHub, Infisical, Cloudflare, monitoring a zálohy.

Protože první appku už jsme si navajb-kodili. Teď jí pojďme dát trochu štábní kultury.