Zabezpečení Linux serveru je proces snižování počtu způsobů, kterými může útočník do serveru proniknout, pracovat v něm a dlouhodobě se v něm udržet. Nejde o jedinou změnu konfigurace ani o produkt, který lze jednoduše zapnout. Jde o řadu rozhodnutí týkajících se toho, co server spouští, kdo k němu má přístup, která síťová spojení přijímá, jak se zaznamenává aktivita a jak rychle se opravují slabiny.
U agentur a firem by k zabezpečení mělo dojít ještě před nasazením serveru do produkce. Nově nainstalovaný server může obsahovat výchozí účty, naslouchající služby, široká oprávnění a administrační rozhraní, která byla praktická během instalace, ale při běžném provozu nejsou potřebná. Každá nepotřebná součást rozšiřuje plochu útoku a vytváří další nastavení, o které je nutné se starat.
Tato příručka představuje praktický základ zabezpečení Linuxu na VPS a dedikovaných serverech spravovaných zákazníkem. Přesné příkazy se mezi distribucemi, jako jsou Debian, Ubuntu, Rocky Linux, AlmaLinux a další, liší. Příklady proto berte spíše jako konfigurační principy než jako pokyny ke kopírování a vložení. Změny testujte na neprodukčním systému, zachovejte alternativní cestu pro obnovu a zdokumentujte, co bylo změněno.
Začněte s minimální a známou instalací
Nejbezpečnější server je obvykle ten, který dělá méně. Začněte s podporovanou distribucí Linuxu a minimální instalací, která obsahuje pouze součásti operačního systému a nástroje potřebné pro zamýšlenou zátěž. Webový server, databázový server, aplikační server a monitorovací uzel nepotřebují stejné balíčky ani služby.
Zaznamenejte verzi operačního systému, zdroje repozitářů, nainstalované balíčky, povolené služby, síťová rozhraní a zamýšlené role. Tento inventář vytváří základní stav. Bez něj si správce nemusí všimnout, že byl přidán balíček, služba začala naslouchat nebo došlo k odchylce v konfiguraci.
Odstraňte to, co zátěž nepotřebuje
Prověřte nainstalované balíčky a odstraňte software, který není nutný. Mezi běžné příklady patří nepoužívané agenty pro přenos pošty, starší síťové nástroje, grafické komponenty, kompilátory a dočasné administrační nástroje. Balíček neodstraňujte jen proto, že jeho název neznáte: nejprve zjistěte, zda na něm závisí jiná služba a zda není potřebný pro aktualizace, monitoring nebo obnovu.
Vypněte služby, které nejsou součástí role serveru. Nainstalovaná, ale nepotřebná služba může stále vystavovat síťový port, zpracovávat nedůvěryhodný vstup nebo obsahovat zranitelnost. Nepoužívané administrační rozhraní je obzvlášť rizikové, protože si může ponechat výchozí nastavení a přitom mu není věnována dostatečná pozornost.
V distribucích založených na systemd správci běžně kontrolují stav služeb pomocí nástrojů, jako je systemctl, a naslouchající sockety prohlížejí pomocí ss. Cílem není za každou cenu zkrátit seznam služeb na minimum. Cílem je, aby každá spuštěná služba byla záměrná, měla svého vlastníka a byla zahrnuta do procesu aktualizací a monitoringu.
Vytvořte včasný proces aktualizací
Neaktualizovaný software je jedním z nejspolehlivějších způsobů, jak mohou útočníci zneužít známou slabinu. Zabezpečení Linux serveru proto zahrnuje operační systém, jádro, nainstalované balíčky, jazyková prostředí, webové servery, databáze, obrazy kontejnerů i aplikace. Server může mít pečlivě nastavený firewall, a přesto může být napaden prostřednictvím zranitelné služby, která přijímá legitimní síťový provoz.
Přihlaste se k bezpečnostním upozorněním pro používanou distribuci a hlavní softwarové komponenty. Určete, kdo upozornění kontroluje, jak se vyhodnocuje závažnost a jak rychle se aktualizace instalují. Kritické zranitelnosti služeb vystavených internetu mohou vyžadovat okamžitý zásah, zatímco změny s nižším rizikem lze provádět v plánovaném servisním okně.
Vyvažujte rychlost a řízení změn
Automatické bezpečnostní aktualizace mohou zkrátit dobu vystavení riziku, ale mohou také způsobit problémy s kompatibilitou. Často jsou vhodné pro vybrané bezpečnostní balíčky operačního systému, pokud mají správci k dispozici monitoring, postupy návratu zpět a způsob, jak řešit restart. U aplikačních stacků s přísnými závislostmi může být bezpečnější řízený aktualizační proces.
Tento kompromis zdokumentujte. Zásady mohou například uvádět, že bezpečnostní opravy se instalují v definované lhůtě, restarty po aktualizaci jádra probíhají v dohodnutém servisním okně a nouzové aktualizace mohou obejít běžný harmonogram. Důležité je vyhnout se neformálnímu procesu, kdy aktualizace závisí na tom, zda si někdo vzpomene přihlásit se.
Po aktualizaci ověřte, že se služby správně restartovaly, certifikáty jsou stále dostupné, aplikační závislosti fungují a server odesílá informace do monitorovacího systému. Oprava, po které zůstane kritická služba zastavená, je technicky nainstalovaná, ale z provozního hlediska neúspěšná.
Používejte oddělené účty a princip nejmenších oprávnění
Princip nejmenších oprávnění omezuje škody způsobené napadením účtu, procesu nebo aplikace. Uživatelé by měli dostat pouze přístup potřebný pro své povinnosti, a to jen na dobu, kdy jej potřebují. Vyhněte se sdíleným účtům správce, protože ztěžují dohledání odpovědnosti a podporují opakované používání přihlašovacích údajů.
Vytvořte pojmenované účty pro správce a samostatné servisní účty pro aplikace. Webová aplikace by běžně neměla být spuštěna jako root a databázový proces by neměl mít přístup k zápisu do nesouvisejících adresářů aplikace. Servisní účty by podle potřeby měly mít neinteraktivní shell a neměly by být členy administračních skupin, pokud pro to neexistuje konkrétní a zdokumentovaný důvod.
Pravidelně kontrolujte uživatele, členství ve skupinách, domovské adresáře, přihlašovací shelly, klíče SSH a údaje o posledním přihlášení. Odstraňte účty lidí, kteří na projektu skončili, při změně odpovědností obměňte přístupy a určete vlastníka každého privilegovaného účtu. Dočasný přístup by měl mít proces ukončení platnosti, aby se náhodou nestal trvalým.
Správu sudo kontrolujte pečlivě
sudo je bezpečnější než předání hesla uživatele root každému správci, ale široké pravidlo sudo může být téměř rovnocenné neomezenému přístupu root. Administrátorská oprávnění přidělujte pojmenovaným uživatelům nebo pečlivě spravovaným skupinám. Pokud je to praktické, povolujte konkrétní příkazy místo neomezeného prefixu a vyhněte se pravidlům, která uživateli umožňují upravovat libovolné konfigurační soubory nebo spouštět shell prostřednictvím jiného programu.
Pro privilegované akce vyžadujte ověření, pokud neexistuje zdokumentovaný provozní důvod postupovat jinak. Aktivitu sudo ukládejte do centrálních logů a kontrolujte ji kvůli neobvyklým časům, příkazům nebo účtům. Buďte opatrní u skriptů: povolený skript, který čte vstup ovládaný uživatelem, prohledává nezabezpečenou cestu nebo volá jiný program bez absolutní cesty, může nepřímo umožnit eskalaci oprávnění.
Princip nejmenších oprávnění může zpomalit reakci na incident, pokud není navržen spolu s nouzovými postupy. Správci by měli zdokumentovat, jak během výpadku získat zvýšený přístup, kdo jej schvaluje a jak se tento přístup následně kontroluje. Bezpečnostní opatření, která během skutečného incidentu nikdo nedokáže použít, bývají při vysokém tlaku obcházena.
Zabezpečte SSH, aniž byste ztratili přístup
SSH je často hlavní cesta pro správu Linux serveru, proto je třeba jeho zabezpečení promyslet a otestovat. Před změnou konfigurace démona otevřete druhou administrační relaci a ponechte si dostupný konzolový nebo poskytovatelem spravovaný přístup, pokud jej platforma nabízí. Před restartem služby ověřte novou konfiguraci.
Pro administrátorský přístup používejte místo hesel klíče SSH. Klíče ztěžují automatizované útoky na slabá hesla, zejména pokud jsou chráněny přístupovou frází a spravovány prostřednictvím agenta nebo schváleného procesu pro práci s tajemstvími. Soukromé klíče chraňte jako přihlašovací údaje: neukládejte je do sdílených složek, zdrojových repozitářů ani nespravovaných pracovních stanic.
Pro server spravovaný zákazníkem základní nastavení SSH obvykle zahrnuje:
- Zakázání přímého přihlášení root přes SSH.
- Zakázání ověřování heslem po otestování přístupu pomocí klíčů.
- Omezení přístupu SSH na pojmenované uživatele nebo administrační skupinu.
- Používání aktuálního protokolu SSH a podporovaných kryptografických algoritmů.
- Omezení přístupu prostřednictvím správcovské sítě, VPN nebo přesně definovaných zdrojových adres, pokud je to možné.
- Nastavení rozumných časových limitů připojení a ověřování.
- Zaznamenávání neúspěšných i úspěšných událostí ověřování.
Změna portu SSH může omezit množství provozu od jednoduchých skenerů, nejde však o bezpečnostní hranici. Nikdy nenahrazuje ověřování pomocí klíčů, omezení přístupu a aktualizace. Podobně mohou nástroje automaticky blokující opakované pokusy o přihlášení pomoci proti útokům hrubou silou, ale při špatně nastavených limitech a důvěryhodných zdrojích mohou zablokovat legitimní správce.
Zakážte přihlášení root a otestujte obnovu přístupu
Přímé přihlášení root odstraňuje dohledatelnost odpovědnosti a poskytuje útočníkovi cenný cíl. Jakmile otestujete alternativní administrátorský účet, nastavte PermitRootLogin na no. Test by měl zahrnovat nové přihlášení zamýšleným klíčem, přístup přes sudo, přístup z běžné správcovské sítě a nouzový postup přístupu.
Stávající relaci nezavírejte, dokud nepotvrdíte novou cestu. Drobná syntaktická chyba, nesprávný název skupiny nebo příliš restriktivní pravidlo AllowUsers může odříznout celý tým. Zabezpečení SSH je úspěšné pouze tehdy, když zvýší bezpečnost, aniž by odstranilo možnost server spravovat a obnovit.
Použijte výchozí konfiguraci firewallu s blokováním
Konfigurace firewallu snižuje počet síťových cest, které vedou ke službě. Praktickým základem je ve výchozím nastavení odmítat nevyžádaný příchozí provoz, povolit pouze potřebné porty a odchozí provoz řídit podle zátěže a organizačních zásad. Správná politika závisí na službě: veřejný webový server může potřebovat HTTP a HTTPS, zatímco databáze by měla obecně přijímat spojení pouze od definovaných aplikačních hostitelů.
Hostitelský firewall používejte jako jednu z vrstev, i když filtrování poskytuje také cloudový poskytovatel nebo síťový okraj. Více vrstev může omezit dopad chyby na jednom místě, musí však být zdokumentovány, aby správci rozuměli tomu, kde je spojení povoleno nebo odmítnuto. Mezi běžné linuxové nástroje firewallu patří nftables, firewalld a rozhraní specifická pro jednotlivé distribuce.
U každého povoleného pravidla zaznamenejte:
- Zdrojové sítě nebo hostitele, kterým je přístup povolen.
- Cílový port a protokol.
- Vlastníka služby a její obchodní účel.
- Zda je pravidlo dočasné, nebo trvalé.
- Jak bude pravidlo kontrolováno a odstraněno.
Pravidlo typu „povol databázový port odkudkoli“ vytváří širokou cestu útoku, i když databáze vyžaduje heslo. Administrativní služby podle možností omezte na důvěryhodné sítě. Pokud vzdálení správci potřebují přístup z proměnlivých míst, zvažte VPN, řízený bastion host nebo jinou spravovanou přístupovou cestu namísto vystavení všech administračních portů internetu.
Změny firewallu testujte ze schváleného externího místa a z aplikační sítě. Ověřte, že potřebný provoz funguje a neoprávněný provoz je odmítnut. Testujte také po restartu, protože nepersistentní firewall může po údržbě ponechat server vystavený.
Chraňte soubory, tajemství a aplikační data
Bezpečná oprávnění souborů brání jednomu účtu nebo službě ve čtení či úpravě dat jiné služby. Začněte vlastnictvím. Systémové soubory by měl obvykle vlastnit root nebo příslušný systémový účet, zatímco aplikační adresáře by měly být zapisovatelné pouze tam, kde aplikace skutečně potřebuje zapisovat.
Vyhněte se širokým oprávněním, jako je 777 u adresářů nebo souborů. Umožňují každému místnímu uživateli a napadenému procesu číst, měnit nebo spouštět obsah. Konfigurační soubory obsahující přihlašovací údaje k databázi, API klíče nebo soukromé certifikáty by měl číst pouze účet či skupina, které je potřebují. Soukromé klíče SSH chraňte restriktivními oprávněními a neumísťujte je do adresářů dostupných z webu.
Pokud je to praktické, oddělte kód, konfiguraci, nahrané soubory, logy a dočasné soubory. Obsah nahraný uživateli by neměl být automaticky spustitelný. Kořenové adresáře webu by neměly obsahovat tajemství pro nasazení, metadata správy zdrojového kódu, archivy záloh ani soubory prostředí. Pokud aplikace potřebuje zapisovat nahrané soubory, poskytněte jí vyhrazený adresář a zvažte opatření bránící spuštění nahraných skriptů.
Se секретy zacházejte promyšleně
Hesla neukládejte do historie shellu, ticketů, zdrojových repozitářů ani nahodile vytvořených skriptů. Používejte správce tajemství nebo jiný řízený mechanismus vhodný pro danou organizaci. Přihlašovací údaje měňte při odchodu zaměstnanců, při podezření na jejich prozrazení a podle rizikovosti systému. Zaznamenejte, které služby jsou na jednotlivých tajemstvích závislé, aby se jejich obměna nezměnila v příčinu výpadku.
Oprávnění souborů nejsou náhradou za šifrování. Pokud útočník získá přístup root, místní hranice oprávnění již nemusí data chránit. Přesto zůstávají důležitá, protože mnoho incidentů začíná u aplikace s nižšími oprávněními, odcizených přihlašovacích údajů uživatele nebo příliš benevolentního místního procesu.
Izolujte služby a omezte laterální pohyb
Izolace služeb omezuje dosah napadené komponenty. Každou hlavní službu spouštějte pod vlastním účtem a omezte její přístup k souborovému systému, síti a linuxovým schopnostem. Podle zátěže může izolace využívat možnosti sandboxingu systemd, kontejnery, virtuální stroje, povinné řízení přístupu, například SELinux nebo AppArmor, mechanismy podobné chrootu a segmentaci sítě.
Izolace by měla odpovídat hrozbě i provozním schopnostem týmu. Kontejner automaticky nepředstavuje úplnou bezpečnostní hranici a složitá politika, které nikdo nerozumí, může být v praxi slabší než jednodušší a dobře monitorovaný návrh. Hostitele, běhové prostředí kontejnerů, obrazy i orchestrační komponenty také udržujte aktualizované.
U aplikací vystavených internetu oddělte veřejnou vrstvu od databází a interních služeb. Povolte pouze potřebná spojení mezi aplikací a databází. Pokud to zátěž umožňuje, zabraňte napadenému webovému procesu v libovolných odchozích spojeních. To může omezit komunikaci s řídicí infrastrukturou útočníka a ztížit šíření útoku do dalších systémů.
Před použitím izolace zdokumentujte závislosti mezi službami. Příliš restriktivní zásady mohou narušit aktualizace, překlad DNS, synchronizaci času, předávání logů nebo kontroly stavu. Jde o kompromis mezi menším dopadem incidentu a dodatečným úsilím potřebným k testování, provozu a řešení problémů na těchto hranicích.
Logujte aktivitu a sledujte změny
Zabezpečení bez přehledu ponechává správce bez možnosti zjistit, zda opatření fungují. Povolte logování ověřování, eskalace oprávnění, služeb a firewallu. Zachytávejte také logy aplikací a webových serverů, dávejte však pozor, abyste nezaznamenávali hesla, tokeny relací ani jiné citlivé hodnoty.
Důležité logy podle možností odesílejte mimo server. Útočník s administrátorským přístupem může místní důkazy smazat nebo změnit. Centralizované logování také usnadňuje korelaci událostí napříč servery, například podezřelého přihlášení, po němž následuje nový účet a neobvyklé odchozí spojení.
Definujte upozornění pro události, které vyžadují pozornost, namísto posílání každé zprávy do schránky, kterou nikdo nečte. Užitečné signály mohou zahrnovat:
- Opakovaná neúspěšná přihlášení následovaná úspěšným přihlášením.
- Nové privilegované uživatele, změny členství ve skupinách nebo neočekávané klíče SSH.
- Přímou aktivitu root nebo neobvyklé příkazy sudo.
- Změny pravidel firewallu, konfigurace SSH nebo kritických systémových souborů.
- Neočekávané naslouchající porty nebo služby spouštěné při startu.
- Abnormální využití CPU, paměti, disku nebo odchozí sítě.
- Neaktivní bezpečnostní agenty, předávání logů nebo monitorovací kontroly.
Monitoring musí mít vlastníka a proces reakce. Upozornění, které se nekontroluje, netřídí a nevede ke konkrétní akci, je pouze záznam. Stanovte běžné provozní vzorce, aby tým dokázal odlišit nasazení od nevysvětlené změny konfigurace.
Spouštějte automatizované kontroly zranitelností a konfigurace
Ruční kontroly jsou užitečné, ale nekonzistentní. Automatizované skenery zranitelností, audity balíčků a kontroly konfigurace mohou odhalit chybějící opravy, vystavené služby, slabé kryptografické nastavení, zastaralé knihovny a odchylky od schváleného základu. Spouštějte je pravidelně a po významných změnách, nejen bezprostředně před auditem.
Pracujte s postupem založeným na závažnosti. Nejprve nálezy ověřte, protože skenery mohou hlásit falešně pozitivní výsledky nebo nesprávně vyhodnotit opravu distribuce zpětně zavedenou do starší verze. Poté určete vlastníka, termín nápravy a důkaz o uzavření. Zranitelnost, kterou nelze okamžitě opravit, by měla mít zdokumentované kompenzační opatření, například omezení sítě, vypnutí služby nebo zvýšený monitoring.
Správa konfigurace může zabránit odchylkám tím, že definuje zamýšlený stav uživatelů, balíčků, služeb, pravidel firewallu a oprávnění. Změny kontrolujte prostřednictvím správy verzí nebo rovnocenného schvalovacího procesu. Tajemství neukládejte do běžných konfiguračních repozitářů a zajistěte, aby samotná automatizace používala úzce omezené přihlašovací údaje.
Před produkčním nasazením ověřte základ pomocí praktického checklistu zabezpečení Linux serveru a přizpůsobte jej distribuci, zátěži a rizikovému profilu. Checklist je výchozí bod, nikoli důkaz bezpečnosti. Správce musí stále potvrdit, že jsou opatření relevantní a že je firma dokáže provozovat.
Rozumějte rozdílu mezi VPS, dedikovanými servery a sdíleným hostingem
Tato opatření platí v případě, kdy zákazník ovládá operační systém a konfiguraci serveru, například na VPS nebo dedikovaném serveru spravovaném zákazníkem. Zákazník si obvykle může zvolit distribuci, spravovat uživatele, konfigurovat SSH, nainstalovat hostitelský firewall, aktualizovat balíčky, izolovat služby a rozhodovat o zpracování logů a monitoringu.
Sdílený hosting je jiný. Prostředí spravované poskytovatelem používá více zákazníků a zákazníci obvykle nemohou měnit hostitelský firewall, vypínat systémové služby, konfigurovat démona SSH, aktualizovat operační systém ani definovat izolaci na úrovni jádra. Poskytovatel hostingu může nabízet vlastní bezpečnostní opatření, ta však nejsou rovnocenná zabezpečení Linux serveru ovládaného zákazníkem.
Při porovnávání možností hostingu rozlišujte mezi VPS nebo dedikovaným prostředím ovládaným zákazníkem a sdíleným hostingem a dalšími spravovanými hostingovými službami. Nepředpokládejte, že lze checklist zabezpečení použít na web jen proto, že běží na Linuxu. Pokud zákazník server neovládá, relevantní otázky znějí: co zabezpečuje poskytovatel, co může zákazník konfigurovat, jak se řeší incidenty a jak lze obnovit data.
Safenix chrání servery ovládané zákazníkem. Neposkytuje zálohovací plán pro web běžící na sdíleném hostingu. Toto rozlišení je důležité při stanovení rozsahu záloh: před výběrem přístupu k obnově určete skutečný server, jeho operační systém a úroveň dostupného přístupu.
Zabezpečení snižuje riziko, ale nezaručuje obnovu
I dobře zabezpečený server může být napaden. Přihlašovací údaje mohou být odcizeny, aplikace může obsahovat dosud neznámou zranitelnost, správce může udělat destruktivní chybu, privilegovaný zaměstnanec může zneužít přístup nebo ransomware může zašifrovat data prostřednictvím legitimního účtu. Zabezpečení má snížit pravděpodobnost a dopad napadení; nečiní server nezničitelným.
Obnova proto patří do stejného plánu odolnosti. Zálohy uchovávejte odděleně od produkčního serveru i od přihlašovacích údajů používaných k jeho správě. Pokud útočník dokáže smazat, změnit nebo zašifrovat živá data i jejich zálohy, může zálohování existovat pouze na papíře a selhat právě při incidentu, na kterém záleží.
Po zabezpečení serveru chraňte možnost obnovy pomocí šifrovaných off-site záloh Safenix pro firemní servery ovládané zákazníkem. Safenix ukládá zálohovaná data v Německu, šifruje je klíčem, který Safenix nikdy nevlastní, a po dobu retenčního okna je udržuje neměnná. Tyto vlastnosti řeší různá rizika: off-site úložiště odděluje záložní kopie od místního selhání, šifrování chrání důvěrnost a neměnnost pomáhá zabránit změně nebo smazání během stanovené retenční doby.
Návrh zálohování stále vyžaduje rozhodnutí zákazníka. Určete, které servery a data jsou zásadní, jakou ztrátu dat může firma tolerovat, jak rychle se systémy musí vrátit do provozu a které závislosti jsou nutné pro použitelnou obnovu. Záloha aplikačních souborů bez databáze, konfigurace, přihlašovacích údajů nebo zdokumentovaného postupu znovuvybudování nemusí vést k funkční službě.
Testujte obnovu, nejen dokončení zálohy
Úspěšná záloha dokazuje, že data byla zapsána. Nedokazuje však, že je firma dokáže obnovit. Plánujte testy obnovy pomocí reprezentativního serveru nebo izolovaného prostředí pro obnovu. Ověřte integritu souborů, konzistenci databáze, oprávnění, spuštění aplikace, změny DNS, certifikáty a schopnost uživatelů běžně pracovat.
Výsledek každého testu zaznamenejte včetně potřebného času, zjištěných problémů a přidělených úkolů. Podle potřeby testujte obnovu malého souboru i celého serveru nebo služby. Zahrňte scénáře, jako je náhodné smazání, selhání serveru, ransomware a ztráta primární hostingové lokality.
Nespoléhejte na paměť jediného správce. Postupy obnovy uložte tak, aby zůstaly dostupné během incidentu serveru, zároveň je však chraňte před neoprávněným přístupem. Měly by uvádět kontakty, závislosti, získání přihlašovacích údajů, pořadí obnovy, ověřovací kontroly a osobu s pravomocí rozhodnout o návratu do produkce.
Zdokumentujte provozní kompromisy
Bezpečnostní opatření vždy souvisejí s dostupností, výkonem, náklady a administrativní náročností. Zabezpečený základ by měl tato rozhodnutí vysvětlovat namísto toho, aby je prezentoval jako univerzální pravidla. Prostředí se tak snadněji provozuje a další správce pochopí, proč výjimka existuje.
Zdokumentujte alespoň:
- Které služby a porty jsou potřebné a kdo je vlastní.
- Kteří uživatelé a skupiny mají administrátorský přístup, jak se vydávají klíče a jak se přístup ruší.
- Jak rychle se instalují bezpečnostní opravy a kdy jsou povoleny restarty.
- Která nastavení firewallu, SSH, sudo a oprávnění se liší od standardního základu.
- Jak izolace služeb ovlivňuje nasazování, řešení problémů a výkon.
- Které logy se uchovávají, kam se odesílají a kdo reaguje na upozornění.
- Jak se vyhodnocují, prioritizují a uzavírají nálezy zranitelností.
- Která data se zálohují, jaké jsou retenční požadavky a jak probíhá testovaná obnova.
- Co se stane, pokud není dostupný primární server, přihlašovací údaje nebo správce.
Příkladem kompromisu je zakázání přihlašování heslem, které zvyšuje odolnost proti útokům na hesla, ale vyžaduje spolehlivou správu klíčů a nouzový přístup. Firewall s výchozím blokováním snižuje vystavení, ale může přerušit nově nasazenou integraci. Agresivní automatické aktualizace zkracují dobu zranitelnosti, ale mohou vyžadovat lepší testování a návrat zpět. Silná izolace služeb omezuje laterální pohyb, zvyšuje však složitost konfigurace.
Výjimky by měly mít vlastníka, důvod, datum ukončení platnosti nebo kontroly a kompenzační opatření. „Dočasný“ přístup ve firewallu, který zůstane roky, již není výjimkou, ale nezdokumentovanou infrastrukturou. Pravidelné kontroly by měly odstraňovat zastaralé účty, balíčky, služby, porty a oprávnění.
Praktický postup zabezpečení před produkcí
Týmy často dosahují lepších výsledků, když opatření zavádějí v opakovatelném pořadí:
- Definujte roli serveru, klasifikaci dat, závislosti a požadavky na obnovu.
- Nainstalujte podporovaný operační systém s nejmenší praktickou sadou balíčků.
- Nainstalujte aktuální aktualizace a zaznamenejte výsledný základ verze.
- Vytvořte pojmenované administrátorské účty a pečlivě nastavte omezený přístup sudo.
- Nainstalujte a otestujte klíče SSH, poté podle potřeby zakažte přímé přihlášení root a ověřování heslem.
- Odstraňte nepotřebné balíčky a vypněte nevyžadované služby.
- Nastavte persistentní firewall s výchozím blokováním a úzce omezenými výjimkami.
- Nastavte vlastnictví a oprávnění systémových souborů, aplikačního kódu, tajemství, nahraných souborů a logů.
- Izolujte služby a omezte jejich přístup k souborovému systému, síti a schopnostem.
- Povolte centralizované logování, monitoring a upozornění na změny ověřování, oprávnění a konfigurace.
- Spusťte kontroly zranitelností a konfigurace a poté nálezy vyřešte nebo zdokumentujte.
- Nastavte off-site zálohy a před prohlášením serveru za připravený proveďte test obnovy.
Po významných změnách postup zopakujte. Zabezpečení produkce není jednorázový obřad, protože se mění balíčky, aplikace, uživatelé, integrace i obchodní požadavky. Server, který byl při spuštění bezpečný, může mít o několik měsíců později zcela jiný rizikový profil.
Základ, který podporuje odolnost
Zabezpečení Linux serveru funguje nejlépe jako součást širší provozní disciplíny. Minimální instalace omezují zbytečné cesty útoku. Aktualizace odstraňují známé slabiny. Princip nejmenších oprávnění omezuje možnosti napadeného účtu. Opatření pro SSH chrání správu, firewally omezují síťové vystavení a oprávnění chrání data před nesouvisejícími procesy. Izolace omezuje laterální pohyb, zatímco logování a monitoring zlepšují odhalení problémů. Automatizované kontroly pomáhají týmu najít odchylky dříve než útočník.
Žádné z těchto opatření neodstraňuje potřebu testované obnovy. Prevence a obnova řeší různé způsoby selhání. Zabezpečte server, aby bylo napadení obtížnější, monitorujte jej, aby byla podezřelá aktivita viditelná, a udržujte chráněné off-site zálohy, aby se závažný incident nezměnil v trvalou ztrátu firemních dat.