Prístupy k webu po spolupráci

Perex: Keď sa skončí spolupráca s dodávateľom, agentúrou alebo interným človekom, ktorý mal na starosti web, väčšina firiem si povie „vyriešime to neskôr”. Neskôr obvykle znamená nikdy. Pritom prvých 24 hodín po odchode je najdôležitejšie bezpečnostné okno, aké máte. Nejde o nedôveru voči konkrétnemu človeku — ide o to, že prístupy, ktoré ste mu dali, žijú ďalej vlastným životom: na starých notebookoch, v cloudových trezoroch, v e-mailoch, v skriptoch na serveroch. Tento článok vám presne ukáže, čo treba prejsť, prečo to treba prejsť, a čo pri každom bode reálne riskujete.

Prečo nestačí „on to bol slušný človek”

Najčastejšia námietka znie: „Veď sme sa rozišli v dobrom, on by nič neurobil.” Možno máte pravdu. Ale bezpečnostné riziko nie je len zlomyseľnosť odchádzajúceho človeka. Sú tri scenáre, a ani jeden nevyžaduje zlý úmysel:

1. Kompromitované staré heslá. Človek si vaše heslo uložil do prehliadača, do poznámok, do exportu z password manažéra. O rok mu ukradnú notebook alebo mu vytečie databáza služby, kde heslo použil znova. Vaše heslo je zrazu na internete a nikto o tom nevie.
2. Uniknuté kľúče a tokeny. SSH kľúč alebo API token skončil v starom repozitári, v zálohe, na disku, ktorý sa predal. Útočník ho nájde a jednoducho sa prihlási — server nerozlišuje, či za kľúčom sedí pôvodný autor alebo niekto iný.
3. Zabudnuté účty. Testovací účet admin2, prístup subdodávateľa, ktorého ste nikdy nevideli, servisný účet monitoringu. Kým existujú a nikto ich nesleduje, sú to otvorené dvere. Útočníci automatizovane skenujú práve takéto opustené vstupy.

Inými slovami: neriešite dôveru voči človeku, riešite plochu útoku, ktorú po ňom ostala. A tú zmenšíte jediným spôsobom — odoberiete a otočíte všetko, k čomu mal prístup.

Administrácia webu: heslá a cudzie účty

Začnite tam, kde sa dá spraviť najväčšia škoda najrýchlejšie — v admin rozhraní CMS, e-shopu alebo CRM. Zmeňte svoje heslo a prejdite zoznam používateľov. Nehľadajte len meno odchádzajúceho človeka. Hľadajte aj účty, ktoré nepoznáte, testovacie kontá a najmä účty s administrátorskými právami, ktoré tam nemajú čo robiť.

Riziko je priame: administrátor v e-shope vie zmeniť platobné údaje, vytiahnuť databázu zákazníkov, vložiť škodlivý skript do stránky alebo si založiť nový skrytý účet pre seba — a vy si to nevšimnete, kým nepríde problém.

Vo WordPresse to cez WP-CLI vyzerá takto:

# vypíš všetkých administrátorov – tu hľadáš aj to, čo si nezaložil
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# zruš konkrétny účet a jeho obsah priraď majiteľovi (ID 1)
wp user delete 42 --reassign=1

Účet nikdy len „nedeaktivujte” — ak sa dá, zmažte ho, alebo mu aspoň odoberte práva a zmeňte heslo. Deaktivovaný účet s pôvodným heslom je stále prihlasovací údaj.

SSH kľúče, heslá a sudo

Ak dodávateľ pracoval priamo na serveri, mal takmer isto SSH prístup. Heslo je len polovica problému — verejné kľúče v ~/.ssh/authorized_keys fungujú ďalej aj po zmene hesla, pretože kľúč heslo obchádza. Toto je najčastejšie prehliadnutý vstup vôbec.

Pozrite sa, čo v súbore je. Cudzí kľúč vyzerá napríklad takto — všimnite si komentár na konci, ktorý prezrádza, komu patrí:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAII... dodavatel@stary-notebook
ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB... agentura-deploy

Každý riadok, ktorý nepatrí vám alebo vášmu súčasnému správcovi, odstráňte. Potom skontrolujte, kto sa naposledy prihlasoval a či niekto nemá tichý sudo prístup:

# posledné prihlásenia – hľadáš neznáme IP alebo časy po ukončení spolupráce
last -a | head -20
lastlog

# kto všetko má práva root cez sudo
grep -R "" /etc/sudoers /etc/sudoers.d/ 2>/dev/null

# stopy v logoch – akceptované SSH prihlásenia za posledné dni
grep "Accepted" /var/log/auth.log | tail -30

Po vyčistení kľúčov zmeňte heslá servisných účtov a zvážte úplnú rotáciu SSH kľúčov. Ak na server pristupujete cez správcu prístupov, urobte to organizovane a s auditom — nie ručne v spěchu, kde ľahko na jeden kľúč zabudnete.

FTP a SFTP

FTP/SFTP účty sú notoricky zabúdané, pretože ich vidno len v hostingovom paneli, nie v samotnom webe. Pritom cez ne sa dá prepísať ktorýkoľvek súbor stránky vrátane vloženia škodlivého kódu. Prejdite zoznam FTP účtov, zmažte všetky, ktoré patrili dodávateľovi alebo vyzerajú ako dočasné (test, deploy, tmp), a ostatným zmeňte heslá. Ak hosting podporuje len SFTP cez SSH, platí to, čo v predchádzajúcej sekcii.

Databáza

Web sa k databáze pripája cez používateľa a heslo uložené v konfiguračnom súbore (napríklad wp-config.php alebo .env). Kto poznal toto heslo a vie sa dostať na port databázy, vie prečítať aj zmeniť všetky vaše dáta — objednávky, zákazníkov, obsah.

Zmeňte heslo DB používateľovi, prípadne založte nové konto a staré zrušte, a hneď aktualizujte konfiguráciu webu, aby stránka nespadla:

-- zmena hesla existujúceho DB používateľa
ALTER USER 'web_app'@'localhost' IDENTIFIED BY 'nove-silne-heslo';
FLUSH PRIVILEGES;

# potom uprav prihlasovacie údaje v konfigurácii webu (príklad pre Laravel .env)
# DB_PASSWORD=nove-silne-heslo

Overte, že databáza nie je vystavená do internetu (má počúvať len na localhost), a skontrolujte zoznam DB používateľov, či medzi nimi nie je niekto navyše.

Hosting, VPS panel, DNS a CDN

Toto sú „kľúče od domu”. Kto má prístup do cPanelu, VPS panelu alebo k účtu registrátora domény, môže obísť úplne všetko ostatné — presmerovať doménu, vydať si nový SSL certifikát, zmazať server aj zálohy. DNS a doména sú najvyššia priorita, pretože kontrola nad doménou znamená kontrolu nad e-mailmi aj webom naraz.

Zmeňte heslá do hostingu a k registrátorovi, prejdite zoznam pozvaných používateľov a delegovaných prístupov, a ak to služba ponúka, zapnite dvojfaktorové overenie. To isté platí pre CDN (napríklad Cloudflare): skontrolujte členov účtu a API tokeny, ktoré tam mohli ostať.

API kľúče, tokeny a SMTP

Moderný web je poprepájaný službami cez API kľúče a tokeny. Každý z nich je samostatný prihlasovací údaj, ktorý funguje nezávisle od hesiel. Prejdite a otočte najmä:

• Platobná brána — kľúče umožňujú vidieť transakcie, prípadne iniciovať vrátenia platieb.
• Mailing / newsletter — únikom kľúča útočník rozpošle vašim kontaktom čokoľvek pod vaším menom.
• Deploy tokeny GitLab/GitHub — dávajú prístup k zdrojovému kódu a k nasadzovaniu na server.
• Webhooky — skontrolujte, kam všade web posiela dáta; cudzí webhook je tichý odtok informácií.
• SMTP prihlásenie — únik znamená rozposielanie spamu a phishingu z vašej domény, čo poškodí doručovanie všetkých vašich e-mailov.

Kľúče sa nemenia „na počkanie v hlave” — vygenerujte nové, nasaďte ich do konfigurácie a staré zneplatnite, nielen prestaňte používať. Token, ktorý nezrušíte, platí ďalej.

WordPress: špecifické riziká

WordPress má niekoľko miest, kde sa dá skryť trvalý prístup tak, že ho v bežnom zozname používateľov nevidno.

Application passwords — samostatné heslá pre REST API, ktoré prežijú zmenu hlavného hesla. Treba ich zrušiť zvlášť:

# vypíš aplikačné heslá používateľa a zruš ich
wp user application-password list <user_id>
wp user application-password delete <user_id> --all

Skryté admin účty a backdoory v wp_users — škodlivý kód vie založiť administrátora, ktorého odfiltruje zo zoznamu. Porovnajte počet administrátorov v databáze s tým, čo vidíte v administrácii:

# koľko administrátorov reálne je v databáze
wp db query "SELECT u.ID, u.user_login FROM wp_users u \
  JOIN wp_usermeta m ON u.ID = m.user_id \
  WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%';"

Škodlivý kód v functions.php alebo mu-plugins — wp-content/mu-plugins/ sa načítava automaticky a v administrácii ho nevidno. Prejdite tieto miesta a hľadajte podozrivé funkcie:

# rýchla kontrola typických „backdoor" konštrukcií
grep -REn "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" \
  wp-content/themes/ wp-content/mu-plugins/

Ak niečo takéto nájdete, nemažte to naslepo — odložte kópiu a dajte to posúdiť niekomu, kto vie odlíšiť legitímny kód od záškodníckeho.

Google, Meta a e-mailové schránky

Prístupy k marketingovým a e-mailovým účtom sa zabúdajú najviac, lebo nie sú „na serveri”. Pritom cez ne odteká najviac citlivých dát.

• Google (GA4, Search Console, Google Ads) — odoberte dodávateľa zo správy účtu. Pri Google Ads to nie je len o dátach: kto má prístup, vie míňať váš rozpočet.
• Meta Business — skontrolujte členov Business Manageru a priradené role k stránke a reklamnému účtu.
• E-mailové schránky — zmeňte heslá k schránkam, ku ktorým mal prístup, a skontrolujte, či nie je nastavené presmerovanie (forwarding) na cudziu adresu. Tiché presmerovanie je klasický spôsob, ako si niekto ponechá prehľad aj po odchode.

Zálohy a prístup k nim

Zálohy sú posledný, no zásadný bod. Kto má prístup k zálohám, má kompletnú kópiu vášho webu aj databázy — teda všetko, čo ste vyššie pracne zabezpečovali. Skontrolujte, kde zálohy ležia (cloudové úložisko, samostatný server, služba tretej strany), kto sa k nim vie dostať, a otočte príslušné prístupy a tokeny. A pripomenieme staré pravidlo: záloha, ktorú nikto neskúsil obnoviť, nie je záloha — pri tejto príležitosti si overte, že sa z nej viete reálne obnoviť.

Checklist: čo zmeniť za prvých 24 hodín

• Admin webu — zmenené heslo, zmazané cudzie a testovacie účty, skontrolovaní administrátori
• SSH — odstránené cudzie kľúče z authorized_keys, zmenené heslá, skontrolovaný sudoers a last/lastlog
• FTP/SFTP — zrušené staré účty, zmenené heslá
• Databáza — nové heslo DB používateľa, aktualizovaná konfigurácia, DB nie je vystavená do internetu
• Hosting / VPS panel — zmenené heslá, odobraní pozvaní používatelia, zapnuté 2FA
• Doména / registrátor / DNS — zmenené heslo, skontrolované delegované prístupy (najvyššia priorita)
• CDN — skontrolovaní členovia a API tokeny
• API kľúče a tokeny — platobná brána, mailing, deploy tokeny, webhooky, SMTP — vygenerované nové, staré zneplatnené
• WordPress — zrušené application passwords, overený počet adminov v wp_users, skontrolované functions.php a mu-plugins
• Google / Meta — odobratý prístup v GA4, Search Console, Ads a Business Manageri
• E-mail — zmenené heslá schránok, skontrolované presmerovania
• Zálohy — otočené prístupy k úložisku, overená obnoviteľnosť

Ako pri tomto vie pomôcť PROSIMSI

Prejsť tento zoznam raz je práca na deň, robiť to pri každej zmene v tíme je bez systému neudržateľné. Práve preto v PROSIMSI vedieme klientom prístupy v zabezpečenom trezore prístupov — viete tak presne, kto má ku ktorej službe prístup, a pri odchode človeka otočíte všetko organizovane, nie z pamäti. Popri správe webov k tomu patrí priebežný monitoring, ktorý si všimne nové admin účty, neznáme prihlásenia či zmeny na serveri skôr, než sa stanú problémom. Ak riešite odchod dodávateľa a nechcete nič prehliadnuť, ozvite sa — prejdeme to s vami krok po kroku.