Odborný blog: technika bez prázdnych fráz

Prečo zdražel hardvér

Roky 2023 až 2026 ukázali, ako rýchlo sa vie trh otočiť. Po období lacnejších komponentov a skladových zásob prišiel dopytový šok spôsobený AI infraštruktúrou. Hyperscaleri, cloudové platformy a veľké dátové centrá začali vo veľkom nakupovať GPU servery, HBM pamäte, serverové DRAM moduly, enterprise SSD a vysokokapacitné úložiská. Výrobcovia prirodzene presúvajú kapacitu do segmentov, kde je vyšší odber a vyššia marža.

Výsledok cíti aj bežná firma na Slovensku. Server už nezdražuje iba preto, že má výkonnejší procesor. Zdražuje preto, že jeho cena je čoraz viac závislá od pamäte a úložiska. Pri virtualizačnom hoste s väčšou RAM alebo pri storage poli s veľkým flash objemom môže byť rozdiel medzi starou a novou kalkuláciou prekvapivo veľký. Navyše sa skracuje platnosť ponúk a pri niektorých dodávateľoch sa častejšie objavuje riziko preceňovania pred dodaním.

Serverové ECC DDR5 pamäte: najtvrdší zásah do ceny serverov

V segmente DDR5 bol nárast poháňaný priamym dopytom po pamätiach pre AI servery, LLM modely a inferenčné clustre, ktoré vyžadujú obrovskú šírku pásma a hustotu. Výroba vysokokapacitných 128 GB a 256 GB modulov vyžaduje pokročilé vrstvenie kremíka, najmä 3DS/TSV technológiu. V čase obmedzených globálnych kapacít to extrémne navýšilo výrobné náklady a zároveň presmerovalo dostupnú výrobu do najziskovejších AI konfigurácií.

• 64 GB ECC DDR5: certifikovaný serverový modul stál na konci roka 2023 približne 215 USD. Vo februári 2026 sa rovnaká kapacita predávala za približne 2 268 USD, čo je najextrémnejší cenový skok v serverovej pamäti.
• 128 GB ECC DDR5: po cenovej optimalizácii v roku 2024 a začiatkom roka 2025 dosiahli tieto moduly dno okolo 928 USD. V roku 2026 sa bežné 128 GB DDR5 moduly pohybujú okolo 2 898 USD, pričom špeciálne certifikované kity pre pracovné stanice môžu stáť až 4 659 USD.
• 256 GB ECC DDR5: najpokročilejšie 3DS/TSV moduly sa v lete 2025 predávali približne za 2 408 USD. Začiatkom roka 2026 cena jedného kusu vyskočila k 7 008 USD a certifikované enterprise sady dosahujú viac ako 10 200 USD.

RAM, SSD a storage sú nové rozpočtové riziko

Najcitlivejšie oblasti sú dnes pamäte a úložiská. Pri virtualizácii sa často plánuje s veľkou RAM rezervou, pretože historicky nebola najdrahšou časťou servera. V prostredí rastúcich cien sa však over-provisioning mení na drahý zvyk. Ak má firma desiatky virtuálnych strojov, každých zbytočných 256 GB RAM v návrhu sa násobí cez viac hostov, zálohovanie, licencie, monitoring aj spotrebu.

Podobné je to pri storage. Full-flash pole dáva zmysel pre databázy, virtualizáciu s nízkou latenciou a kritické aplikácie. Nie všetky dáta však musia byť na najdrahšom type úložiska. Archívy, staré súborové dáta, retenčné kópie a menej výkonné workloady môžu patriť do hybridného alebo kapacitného tieru. Dobrá architektúra dnes nie je tá, ktorá dá všetko na najrýchlejší disk. Dobrá architektúra rozlišuje, ktoré dáta potrebujú výkon, ktoré odolnosť a ktoré hlavne lacnú kapacitu.

Prečo bude rásť aj cloud

Časť firiem bude na drahší hardvér reagovať presunom do cloudu. Je to logické: cloud znižuje potrebu okamžitého kapitálového nákupu, rieši dostupnosť infraštruktúry a pri niektorých službách prenáša časť prevádzkovej zodpovednosti na poskytovateľa. Zároveň však platí, že cloud nie je únik pred drahým hardvérom. Cloud stojí na rovnakých čipoch, pamätiach, SSD, sieťach, energii a bezpečnostných tímoch. Ak vstupné náklady rastú hyperscalerom, postupne sa premietajú aj do cien služieb, nových licenčných modelov, poplatkov za výkon, storage, prenos dát a bezpečnostné doplnky.

Najväčšie riziko je nekontrolovaný cloud. Firma presunie workload do cloudu, zapne vyšší výkon „pre istotu“, nechá bežať testovacie prostredia, neustráži storage snapshoty, výstupné dáta ani logy a po pár mesiacoch rieši účet, ktorý nikto neplánoval. Preto bude rásť význam FinOps, reserved kapacít, pravidiel pre vypínanie prostredí, merania využitia a hybridnej architektúry.

Cybersecurity už nie je doplnok, ale súčasť ceny prevádzky

Do celkovej ceny IT vstupuje aj bezpečnosť. NIS2, zákon o kybernetickej bezpečnosti, požiadavky odberateľov a reálna hrozba ransomvéru tlačia firmy k MFA, EDR, segmentácii, monitoringu, imutabilným zálohám, šifrovaniu, dokumentácii a testom obnovy. To sú správne opatrenia, ale nie sú zadarmo. Vyžadujú licencie, čas, správu, dohľad a jasný proces reakcie.

Často sa preto stáva, že nový server alebo cloudová služba nie je drahšia iba technicky. Drahší je celý bezpečný prevádzkový balík: zálohovanie, offsite kópia, monitoring, prístupové politiky, audit logy, EDR agent, firewall pravidlá, dokumentácia a pravidelné testy. Ak sa tieto položky v rozpočte ignorujú, firma síce kúpi infraštruktúru, ale nekúpi prevádzkovú odolnosť.

Čo sa dá očakávať do budúcnosti

Krátkodobo nemožno rátať s návratom k cenám z obdobia lacných zásob. Dopyt po AI infraštruktúre, serverových pamätiach a enterprise SSD zostáva silný a nové výrobné kapacity sa nepridávajú zo dňa na deň. Skôr sa dá očakávať väčšia volatilita: kratšia platnosť ponúk, dlhšie dodacie lehoty, drahšie konfigurácie s veľkou RAM, tlak na cloudové rozpočty a viac diskusií o tom, ktoré workloady majú zostať on-premise a ktoré majú ísť do cloudu.

Strednodobo bude rásť hybridný prístup. Kritické systémy, ktoré potrebujú stabilnú cenu, nízku latenciu alebo lokálnu kontrolu, môžu zostať v dobre navrhnutom datacentri. Služby s premenlivou záťažou, geografickou dostupnosťou alebo rýchlym nasadením môžu dávať zmysel v cloude. Rozhodovať by nemala móda, ale čísla: výkon, riziko, RPO/RTO, bezpečnosť, cena obnovy a celkové TCO.

Ako má firma reagovať

1. Urobiť inventár a meranie využitia. Pred nákupom treba vedieť, koľko CPU, RAM, IOPS a kapacity sa reálne používa.
2. Neplánovať rezervu naslepo. Rezerva má byť odôvodnená rastom, SLA a aplikáciami, nie zvykom z lacnejších rokov.
3. Porovnať on-premise, cloud a hybrid. Nie podľa mesačnej ceny jednej VM, ale podľa trojročného TCO vrátane záloh, bezpečnosti a správy.
4. Oddeliť výkonné a kapacitné dáta. Full-flash má patriť tam, kde prináša výkonový alebo prevádzkový prínos.
5. Zafixovať dôležité nákupy skôr. Pri plánovanej obnove serverov alebo storage je lepšie mať rámcový plán, než čakať na koniec životnosti.
6. Započítať cybersecurity do rozpočtu od začiatku. EDR, MFA, monitoring a imutabilné zálohy nie sú voliteľná dekorácia, ale prevádzková poistka.

Kde vieme pomôcť

PRETOR SLOVAKIA pomáha firmám s návrhom a správou dátových centier, dodávkou a správou serverov DELL, IBM storage riešeniami, virtualizáciou, migráciami, zálohovaním a kybernetickou bezpečnosťou. Pri drahšej infraštruktúre je dôležité neurobiť nákup podľa pocitu. Najprv treba zmerať existujúce prostredie, navrhnúť realistickú kapacitu a porovnať scenáre: vlastný hardvér, cloud alebo hybrid.

Spočítať VMware / Proxmox / Hyper-V Konzultácia k infraštruktúre

Zdroje: TrendForce - AI server demand and memory pricing, 31. 3. 2026, Cloud Computing News / Omdia - cloud infrastructure spending, 1. 4. 2026, Network World - server and storage price adjustments, 2026

Kde AI útočníkom reálne pomáha

Najviditeľnejší prínos AI pre útočníkov je sociálne inžinierstvo. Phishingové správy už nemusia mať slabú gramatiku, zlý preklad ani podozrivý tón. Model vie pripraviť text, ktorý vyzerá ako interný e-mail, správa od dodávateľa, fakturačná urgencia alebo požiadavka na zmenu hesla. Pre firmu to znamená, že zamestnanec sa už nemôže spoliehať iba na „divný jazyk“ ako varovný signál.

Druhá oblasť je prieskum. AI vie rýchlo spracovať verejné informácie o firme, technológiách, ľuďoch, pobočkách a dodávateľoch. Útočník tak ľahšie pripraví dôveryhodný scenár: kto má byť odosielateľ, aký projekt spomenúť, aký systém napodobniť a komu poslať správu.

Tretia oblasť je práca s ukradnutými dátami. Pri ransomvéri už často nejde iba o šifrovanie. Útočníci dáta kradnú, triedia a používajú na nátlak. AI im pomáha rýchlejšie nájsť citlivé zmluvy, osobné údaje, finančné informácie alebo dokumenty, ktoré sú pre firmu reputačne nebezpečné.

Prečo to súvisí s ransomvérom

Ransomvérový incident zvyčajne nezačína zašifrovaním servera. Začína prístupom. Môže to byť heslo z úniku, úspešný phishing, zraniteľná VPN, zle chránený administrátorský účet alebo neopravený verejne dostupný systém. AI pomáha práve v týchto skorých fázach: vybrať cieľ, pripraviť komunikáciu, nájsť slabé miesto a zrýchliť rozhodovanie útočníka.

Ak sa útočník dostane do siete, jeho cieľom je zvýšiť oprávnenia, nájsť kritické systémy a preveriť zálohy. Ak zálohy nie sú oddelené alebo imutabilné, pokúsi sa ich zmazať alebo poškodiť ešte pred šifrovaním produkcie. Preto je obrana proti modernému ransomvéru vždy kombinácia identity, segmentácie, monitoringu a obnoviteľných záloh.

Čo má firma skontrolovať ako prvé

1. MFA pre všetky kritické prístupy. Najmä administrátori, VPN, cloud, e-mail, vzdialená správa a zálohovacie konzoly.
2. Oddelené administrátorské účty. Bežný používateľský účet nesmie byť zároveň účet na správu serverov.
3. Imutabilné alebo offline zálohy. Aspoň jedna kópia musí prežiť aj kompromitáciu domény alebo backup servera.
4. Test obnovy. Nie screenshot úspešnej zálohy, ale reálne obnovená VM alebo služba v izolovanom prostredí.
5. Patch management. Verejne dostupné služby a VPN zariadenia musia mať kratší opravný cyklus než interné systémy.
6. Logovanie a alerty. Zmeny v admin skupinách, masové zlyhané prihlásenia, nové forward pravidlá v e-maile a neobvyklé prístupy treba vidieť včas.

Prečo školenie nestačí

Školenie používateľov má zmysel, ale pri AI-asistovanom phishingu nemôže byť jedinou ochranou. Aj pozorný človek sa môže pomýliť, ak správa sedí na reálny kontext firmy. Obrana musí rátať s tým, že niekto klikne, zadá heslo alebo schváli požiadavku. Rozhodujú potom technické bariéry: MFA, obmedzené oprávnenia, podmienený prístup, segmentácia a rýchla detekcia.

Dobrá bezpečnosť nie je o tom, že sa incident nikdy nezačne. Je o tom, že sa nerozšíri, nezasiahne zálohy a firma vie obnoviť prevádzku bez platenia výkupného.

Rýchla kontrola pripravenosti

Ak chcete zistiť, či by vaše zálohy a procesy zvládli cielený útok, začnite krátkym testom. Náš ransomware skener sa pýta na imutabilitu, oddelenie záloh, test obnovy, monitoring a dokumentáciu. Výsledok nie je audit, ale rýchlo ukáže, či je problém v technológii, procese alebo v chýbajúcej zodpovednosti.

Spustiť ransomware skener

Zdroje: NCSC - The near-term impact of AI on the cyber threat, Microsoft Digital Defense Report 2025, ENISA Threat Landscape

Čo klasický antivírus rieši dobre

Klasický antivírus je dobrý v blokovaní známeho škodlivého kódu, podozrivých súborov, známych signatúr a bežných malvérových kampaní. Pre domácu stanicu alebo jednoduché prostredie je to stále užitočná vrstva ochrany. Problém začína v momente, keď útočník nepoužije iba jeden súbor, ale kombinuje ukradnuté prihlasovacie údaje, PowerShell, RDP, legitímne administračné nástroje, makrá, cloudové účty a pohyb medzi zariadeniami.

V takom scenári sa bezpečnostná otázka mení. Nejde len o to, či je súbor známy ako škodlivý. Ide o to, či správanie na stanici dáva zmysel: kto spustil proces, odkiaľ prišiel príkaz, čo sa zmenilo v systéme, či vzniklo podozrivé sieťové spojenie a či sa rovnaké správanie objavuje aj na ďalších zariadeniach.

Čo pridáva EDR

EDR, teda Endpoint Detection and Response, zbiera a vyhodnocuje telemetriu z koncových zariadení: procesy, príkazové riadky, zmeny súborov, sieťové spojenia, pokusy o eskaláciu práv, správanie používateľov a väzby medzi udalosťami. Namiesto izolovaného pohľadu na jeden súbor dáva bezpečnostnému správcovi príbeh incidentu.

Pre firmu je najdôležitejšia reakcia. Ak EDR zistí podozrivé správanie, môže zariadenie izolovať od siete, zastaviť proces, zachovať dôkazy pre analýzu a pomôcť s nápravou. Pri ransomvéri alebo útoku na doménové účty rozhodujú minúty. Čím skôr sa kompromitovaná stanica odpojí od zvyšku siete, tým menšia je šanca, že incident zasiahne servery, zálohy alebo ďalšie pracovné stanice.

Kde má miesto SentinelOne

SentinelOne Singularity Endpoint je platforma pre ochranu koncových zariadení s funkciami prevencie, detekcie a reakcie. Jej silnou stránkou je kombinácia behaviorálnej detekcie, kontextu incidentu a automatizovanej reakcie na úrovni endpointu. V praxi to znamená, že administrátor nevidí len zoznam alertov, ale súvislosti medzi procesmi, používateľom, zariadením a časovou osou udalostí.

SentinelOne komunikuje aj koncept automatizovanej nápravy a rollbacku endpointu. To neznamená, že firma nepotrebuje zálohy alebo incident plán. Znamená to, že pri časti incidentov vie EDR skrátiť čas medzi detekciou a technickou reakciou. Pri ransomvéri je to zásadné: ak sa podarí zastaviť šifrovací proces alebo izolovať stanicu včas, rozsah škody môže byť výrazne menší.

EDR nie je náhrada za správu IT

EDR nie je kúzelná poistka. Ak má firma zdieľané administrátorské účty, slabé heslá, chýbajúce MFA, neopravené VPN zariadenia a zálohy dostupné z rovnakej domény, ani kvalitný EDR nevyrieši celý problém. EDR je senzor a reakčný mechanizmus. Aby fungoval dobre, potrebuje správnu konfiguráciu, pravidlá, dohľad, proces eskalácie a človeka, ktorý vie alert vyhodnotiť.

Najčastejšia chyba je kúpiť EDR a nechať ho bežať „potichu“. Alerty musia mať vlastníka. Niekto musí vedieť, čo sa deje po izolácii stanice, komu volať, ako skontrolovať doménové účty, ako overiť zálohy a kedy obnoviť zariadenie do prevádzky.

Čo odporúčame pred nasadením

1. Inventár zariadení. Vedieť, ktoré stanice a servery majú byť chránené, kto ich používa a aké majú kritické aplikácie.
2. MFA a privilegované účty. EDR nemá suplovať chýbajúcu identitnú bezpečnosť.
3. Politiky pre servery a pracovné stanice zvlášť. Doménový radič, SQL server a notebook obchodníka nemajú mať rovnaký režim reakcie.
4. Test izolácie. Pred ostrým incidentom treba vedieť, čo sa stane, keď EDR odpojí zariadenie od siete.
5. Napojenie na proces obnovy. Detekcia bez obnovy nestačí. Po incidente musí existovať postup pre reimage, restore alebo kontrolované vrátenie zariadenia do prevádzky.

Kedy to dáva zmysel riešiť

EDR dáva zmysel najmä vo firmách, kde endpointy pristupujú k citlivým dátam, doméne, VPN, účtovníctvu, výrobným systémom, serverom alebo zákazníckym portálom. Ak má kompromitovaný notebook cestu k súborovému serveru, účtovníctvu alebo zálohám, nejde o problém jedného zariadenia. Je to vstupný bod do celej infraštruktúry.

Ak používate iba klasický antivírus, dobrý prvý krok je technické preverenie endpointov: čo je nainštalované, čo sa loguje, či sú zapnuté lokálne firewally, či existuje MFA, ako sú riešené admin účty a či má firma reálny postup pri podozrivom správaní na stanici.

Spustiť EDR preverenie Prejsť možnosti EDR ochrany

Zdroje: SentinelOne Singularity Endpoint Security, SentinelOne - What is EDR?, CIS - Endpoint Detection and Response, CISA OpenEDR

Čo sa zmenilo

Broadcom po akvizícii VMware zjednodušil portfólio a presunul obchodný model smerom k predplatnému. Pre zákazníkov to v praxi znamená, že pri obnove už často neriešia rovnaký produkt v rovnakej podobe ako pred rokmi. Do hry vstupujú nové balíky, minimá licencovania, iné viazanosti a požiadavka plánovať náklady na niekoľko rokov dopredu.

Staršie trvalé licencie samy osebe nemusia okamžite prestať fungovať. Riziko je inde: po skončení podpory sa obmedzuje prístup k novým opravám, bezpečnostným aktualizáciám, novým verziám a technickej podpore. Pri platforme, na ktorej bežia kritické servery, je to zásadný prevádzkový aj bezpečnostný problém.

Kde vzniká skutočné riziko

Najväčšia chyba je čakať na koniec zmluvy a až potom zisťovať, koľko bude stáť obnova alebo migrácia. Virtualizácia je naviazaná na zálohovanie, monitoring, sieťové VLAN, storage, replikácie, dokumentáciu aj servisné okná. Ak sa rozhodnutie odkladá, neskôr chýba čas na testy a firma prijíma horšie rozhodnutie pod tlakom.

Pri menších a stredných prostrediach sa preto oplatí porovnať minimálne štyri scenáre: pokračovanie vo VMware s novým predplatným, hybridné obdobie s časťou prostredia mimo VMware, prechod na Proxmox VE alebo návrat k Microsoft virtualizácii cez Hyper-V. Cieľom nie je vybrať najlacnejšiu tabuľku, ale riešenie, ktoré dokážete bezpečne prevádzkovať.

Ako pripraviť rozhodnutie

1. Zmapujte licenčnú základňu. Počet CPU, jadier, edície, dátumy obnovy, typ podpory a závislosti na konkrétnych VMware funkciách.
2. Rozdeľte virtuálne stroje podľa kritickosti. Inak sa migruje doménový radič, databáza, terminálový server a testovacie VM.
3. Overte kompatibilitu zálohovania. Bez funkčnej obnovy nie je migrácia projekt, ale hazard.
4. Porovnajte Proxmox VE aj Hyper-V. Výber závisí od aplikácií, Windows licencií, storage, správy, backup nástrojov a schopnosti prevádzkovať platformu dlhodobo.
5. Urobte proof of concept. Malý testovací klaster, obnova VM a meranie výkonu povedia viac než marketingové porovnanie.
6. Nacente tri roky prevádzky. Licencie, podpora, migrácia, monitoring, úložisko, zálohy, čas administrácie a servisné zásahy.

Kedy dáva zmysel Proxmox VE

Proxmox VE je zaujímavý najmä tam, kde firma nepotrebuje celé VMware enterprise portfólio, ale potrebuje stabilný hypervízor, klastrovanie, HA, zálohovanie, rozumnú správu a predvídateľné náklady. Veľkou výhodou je otvorený ekosystém a možnosť držať infraštruktúru pod vlastnou kontrolou.

Proxmox však netreba predávať ako jednoduchú výmenu tlačidla za tlačidlo. Treba dobre navrhnúť storage, sieťové mosty, backup stratégiu, oprávnenia, monitoring a proces aktualizácií. Pri správnom návrhu môže byť výsledok veľmi efektívny. Pri rýchlej a nepremyslenej migrácii sa iba presunie problém z licenčnej roviny do prevádzkovej.

Kedy dáva zmysel Hyper-V

Hyper-V dáva zmysel najmä v prostrediach, ktoré sú silno postavené na Windows Server, Active Directory, Microsoft licencovaní a existujúcej správe Windows infraštruktúry. Hyper-V je rola Windows Servera, podporuje Windows aj Linux virtuálne stroje a v serverovom nasadení vie pokryť scenáre s vysokou dostupnosťou, migráciou VM medzi hostami a disaster recovery návrhom.

Výhodou Hyper-V je prirodzené zapadnutie do Microsoft ekosystému. Ak firma už má Windows Server Datacenter, existujúce procesy správy, monitoring, zálohovanie a administrátorov zvyknutých na Microsoft prostredie, môže byť Hyper-V rozumná cesta, ako znížiť závislosť od VMware bez zavedenia úplne cudzej prevádzkovej platformy. Aj tu však platí, že rozhoduje návrh: storage, sieťové prepínače, VLAN, zálohovanie, monitoring, aktualizácie a test obnovy.

PRETOR SLOVAKIA vie pri takomto rozhodnutí posúdiť obe vetvy: Proxmox VE aj Hyper-V. Pri niektorých firmách vyhrá Proxmox pre predvídateľné náklady a otvorený ekosystém. Pri iných dáva väčší zmysel Hyper-V, pretože lepšie zapadne do existujúceho Windows Server prostredia. Dôležité je nerobiť rozhodnutie podľa značky, ale podľa prevádzkového rizika, TCO a schopnosti obnovy.

Zdroje: Broadcom KB - End of Availability perpetual licensing, Broadcom KB - perpetual licenses after SnS expiration, Microsoft Learn - Hyper-V virtualization in Windows Server

Najprv inventúra, až potom nástroje

Pred migráciou je potrebné poznať reálny stav. Zoznam VM nestačí. Pri každom systéme potrebujete vedieť operačný systém, veľkosť diskov, typ partícií, využitie CPU a RAM, sieťové závislosti, RPO/RTO, spôsob zálohovania a to, či má aplikácia vlastný mechanizmus konzistentnej odstávky.

Najčastejšie problémy vznikajú pri starších Windows serveroch, databázach, špecifických appliance VM a systémoch s ručne nastavenými MAC adresami alebo statickým mapovaním siete. Práve tieto VM patria do prvej analýzy, nie na koniec projektu.

Príprava Proxmox prostredia

Proxmox klaster musí byť pripravený skôr, než sa začne s prvou produkčnou migráciou. To znamená nakonfigurovaný management, oddelené siete pre VM a storage, správne mosty, časovú synchronizáciu, zálohovacie úložisko, monitoring a prístupové práva. Ak používate shared storage alebo Ceph, treba overiť latencie a správanie pri výpadku uzla.

Pri Windows VM je praktické pripraviť VirtIO ovládače a QEMU Guest Agent ešte pred finálnym prepnutím. Po migrácii to uľahčí správnu detekciu diskov, siete, vypínanie VM a reporting stavu. Pri Linux VM treba skontrolovať initramfs, názvy sieťových rozhraní a bootloader.

Veeam ako migračný most

Veeam Backup & Replication podporuje Proxmox VE cez príslušnú integráciu a v praxi vie pomôcť ako bezpečný migračný most. Dôležité je pracovať s podporovanými verziami Proxmox VE, mať pripravené file-level storage v Proxmox prostredí a pri aplikačne citlivých VM počítať s QEMU Guest Agentom.

Odporúčaný postup je najprv urobiť plnú zálohu zdrojovej VM, následne testovaciu obnovu do izolovanej siete a až potom pripravovať produkčný cutover. Testovacia obnova musí overiť boot, sieť, služby, aplikačné logy, doménovú komunikáciu, výkon a konzistenciu dát. Ak sa niečo rozbije v izolovanom teste, je to lacná chyba. Ak sa to rozbije počas ostrého prepnutia, je to incident.

Kontrolný postup pred prepnutím

1. Potvrdiť aktuálnu úspešnú zálohu a možnosť obnovy späť do pôvodnej platformy.
2. Zastaviť alebo zmraziť aplikáciu podľa jej odporúčaného postupu.
3. Urobiť poslednú inkrementálnu synchronizáciu alebo obnovu podľa zvoleného nástroja.
4. Spustiť VM v Proxmox VE v izolovanej alebo cieľovej sieti podľa plánu.
5. Skontrolovať služby, logy, DNS, firewall pravidlá, monitoring a zálohovanie novej VM.
6. Nechať pôvodnú VM vypnutú, ale dostupnú ako rollback iba po vopred určený čas.

Po migrácii projekt nekončí. Treba prepnúť zálohovacie politiky, aktualizovať dokumentáciu, nastaviť monitoring Proxmox hostov, overiť restore test a naplánovať aktualizácie. Až potom je možné povedať, že VM bola skutočne presunutá do novej prevádzkovej reality.

Zdroje: Veeam Help Center - Proxmox VE support, Veeam Help Center - Proxmox system requirements

Baseline nie je slepé importovanie GPO

Microsoft Security Baseline je výborný východiskový bod, pretože zhŕňa odporúčané bezpečnostné nastavenia pre Windows. Neznamená to však, že sa má bez testovania aplikovať priamo na produkčné doménové radiče. Každá organizácia má iné legacy aplikácie, servisné účty, tlačové služby, skenery, staré NAS zariadenia alebo integračné skripty.

Správny postup je vytvoriť testovaciu OU, presunúť do nej neprodukčný alebo nový DC, aplikovať baseline a sledovať dopad. Až po kontrole event logov, replikácie, autentifikácie a aplikačných závislostí má zmysel robiť pilot v produkcii.

Najdôležitejšie oblasti hardeningu

• Staré protokoly: SMBv1 a NTLMv1 patria preč. Pri NTLM ako celku je lepšie začať auditom a postupným obmedzovaním než náhlym vypnutím.
• LDAP bezpečnosť: zapnúť alebo vynucovať LDAP signing a channel binding podľa kompatibility klientov.
• Privilegované účty: oddeliť bežné a admin účty, používať tiering model a zakázať prihlasovanie doménových adminov na bežné pracovné stanice.
• Lokálne heslá: nasadiť Windows LAPS tam, kde sa používajú lokálne administrátorské účty.
• Audit a logovanie: sledovať zmeny v privilegovaných skupinách, Kerberos udalosti, zlyhané prihlásenia a zmeny GPO.
• Správa servera: obmedziť RDP, použiť správne firewall pravidlá, spravovať DC cez vyhradené administrátorské stanice a držať minimum softvéru.

Ako postupovať bez výpadku

Začnite auditným režimom. Zbierajte udalosti, ktoré ukážu, kto ešte používa staré protokoly alebo slabé nastavenia. Následne pripravte komunikačný plán pre vlastníkov aplikácií, opravte závislosti a až potom vynucujte tvrdšie politiky. Pri Active Directory je pomalý a merateľný postup často bezpečnejší než rýchle hromadné zmeny.

Pred každou väčšou zmenou musí existovať aktuálna záloha System State, overená replikácia medzi DC a jasný rollback plán. Pri DC neoverujeme len to, či server beží. Overujeme aj DNS, Kerberos, SYSVOL, Group Policy, časovú synchronizáciu a schopnosť klientov prihlásiť sa.

Čo kontrolovať pravidelne

1. Členstvo v skupinách Domain Admins, Enterprise Admins a Schema Admins.
2. Servisné účty s vysokými právami a heslami bez expirácie.
3. Neúspešné a podozrivé prihlásenia na DC.
4. Replikáciu, DNS chyby a stav SYSVOL.
5. Aktuálnosť záloh a úspešnosť testov obnovy.

Zdroje: Microsoft Security Compliance Toolkit, Windows Server 2025 security baselines with OSConfig, Windows security baselines

Čo znamená imutabilita

Imutabilná záloha je kópia dát, ktorú počas nastavenej retenčnej doby nie je možné zmeniť alebo vymazať bežným administrátorským zásahom. Cieľ je jednoduchý: aj keď útočník získa prístup do produkčnej siete alebo ku konzole zálohovania, nemá mať možnosť zničiť všetky body obnovy.

Samotné zaškrtnutie voľby však nestačí. Imutabilita musí byť súčasťou celej architektúry: oddelené účty, žiadne bežné doménové prihlasovanie na backup server, izolované úložisko, šifrovanie, monitorovanie a pravidelné testy obnovy.

Veeam Hardened Repository

Pri Veeam prostredí je častý prístup Linux Hardened Repository. Úložisko sa pripraví na samostatnom Linux serveri, ideálne mimo domény, s minimálnym počtom služieb a s obmedzeným prístupom. Veeam zapisuje zálohy tak, aby boli počas zvolenej doby chránené proti zmene.

Dôležité detaily rozhodujú o výsledku. SSH prístup sa po konfigurácii obmedzuje, administrátorské účty sa nepoužívajú na bežnú prevádzku, repozitár nemá byť rovnaký server ako produkčný hypervízor a retenčná doba musí vychádzať z reálneho času detekcie incidentu. Ak firma zistí útok až po desiatich dňoch, trojdňová imutabilita jej nemusí stačiť.

Hornetsecurity VM Backup a immutable cloud

Hornetsecurity VM Backup používa iný model, vhodný najmä pre prostredia, kde dáva zmysel posielať druhú kópiu mimo lokality do cloudového úložiska s WORM princípom. Výhodou je geografické oddelenie a ochrana proti lokálnej katastrofe. Nevýhodou môže byť závislosť od konektivity, objemu dát a ceny dlhodobej retencie.

Pri cloudovej imutabilite treba správne nastaviť retenčné politiky, prístupové kľúče, oddelenie oprávnení a test obnovy späť do lokality alebo do náhradného prostredia. Záloha, ktorú nikto nikdy neskúsil obnoviť, je iba predpoklad.

Kontrolný zoznam odolných záloh

1. Zálohovací server nemá byť spravovaný rovnakými účtami ako bežná doména.
2. Minimálne jedna kópia musí byť mimo produkčnej lokality.
3. Retencia imutability musí pokryť aj neskorú detekciu incidentu.
4. Obnova sa testuje pravidelne, nielen po nákupe riešenia.
5. Alerty zo zálohovania nesmú končiť iba v mailboxe človeka, ktorý je na dovolenke.
6. Dokumentácia obnovy musí byť dostupná aj v prípade výpadku interných systémov.

Najlepšia zálohovacia stratégia je tá, ktorú firma dokáže použiť pod stresom. Preto má zmysel robiť aspoň raz ročne cvičenie obnovy: vybrať kritickú VM, obnoviť ju do izolovaného prostredia, zmerať čas, skontrolovať dáta a zapísať nedostatky.

Zdroje: Hornetsecurity VM Backup, Hornetsecurity - immutable backup locations, Veeam Help Center

Prečo sa to týka aj menších firiem

Regulovaná organizácia musí riešiť kybernetické riziká vo vlastnej prevádzke aj v dodávateľskom reťazci. Ak jej dodávateľ spravuje server, pristupuje do siete, hostuje aplikáciu alebo má prístup k dátam, stáva sa súčasťou jej rizikového profilu. Odberateľ preto môže zmluvne vyžadovať opatrenia, ktoré by menšia firma inak neriešila.

V praxi to býva bezpečnostný dotazník, požiadavka na MFA, incident reporting, zálohovanie, šifrovanie, evidenciu prístupov, školenie ľudí alebo právo na audit. Nejde iba o papier. Ak dodávateľ nevie preukázať základnú kyberhygienu, môže stratiť kontrakt alebo sa nedostať do verejného obstarávania.

Minimum, ktoré by mal mať každý dodávateľ

• Inventár aktív: zoznam serverov, cloud služieb, spravovaných zariadení, účtov a kritických aplikácií.
• MFA: viacfaktorové overenie pre administrátorov, vzdialený prístup, cloud služby a e-mailové účty.
• Zálohovanie: oddelené a testované zálohy vrátane jasného RPO/RTO.
• Patch management: pravidelný proces aktualizácií operačných systémov, aplikácií, firewallov a hypervízorov.
• Riadenie prístupov: žiadne zdieľané admin účty, pravidelná revízia oprávnení a odoberanie prístupov po ukončení spolupráce.
• Incident plán: kto rozhoduje, koho volať, čo izolovať a ako rýchlo informovať zákazníka.
• Logovanie: uchovávanie bezpečnostných logov aspoň pre kritické systémy a administrátorské aktivity.

30-dňový plán prípravy

1. 1. týždeň: urobiť inventár aktív, prístupov a zákazníckych systémov, ku ktorým máte oprávnenia.
2. 2. týždeň: zapnúť MFA, odstrániť zdieľané účty a nastaviť minimálne práva.
3. 3. týždeň: skontrolovať zálohy, urobiť test obnovy a doplniť monitoring zlyhaných úloh.
4. 4. týždeň: spísať incident kontakty, základnú bezpečnostnú politiku a dôkazy, ktoré viete ukázať odberateľovi.

Čo si pripraviť pre zákazníka

Dodávateľ by mal vedieť rýchlo doložiť, ako chráni prístupy, ako zálohuje, ako rieši aktualizácie, kto má administrátorské oprávnenia a čo urobí pri incidente. Nemusí to byť stostranová dokumentácia. Na začiatok často stačí stručný, pravdivý a udržiavaný bezpečnostný balík: politika prístupov, schéma zálohovania, zoznam kontaktných osôb a záznam z posledného testu obnovy.

Najhoršia odpoveď na zákaznícky dotazník je improvizácia. Ak si firma pripraví dôkazy vopred, pôsobí dôveryhodne a zároveň reálne znižuje riziko incidentu.

Zdroje: Smernica NIS2 - EUR-Lex, Vykonávacie nariadenie EÚ 2024/2690, Zákon č. 69/2018 Z. z. - Slov-Lex, Novela č. 366/2024 Z. z. - Slov-Lex