Nebezpečí napadeného účtu spočívá v tom, co může útočník dělat po prvotním průniku. Pokud ukradené přihlašovací údaje uživatele umožní přístup ke každému serveru, administrátor agentury může měnit prostředí všech klientů nebo servisní účet může mazat zálohy, může se z jediného incidentu stát výpadek celé firmy.
Princip nejmenších oprávnění je praktický způsob, jak omezit rozsah škod. Každá identita získá pouze přístup potřebný pro aktuální úkol, na co nejkratší rozumnou dobu a v co nejmenším možném rozsahu. Když je účet napaden, útočník zdědí tato omezení místo volné cesty celým prostředím.
Nejmenší oprávnění nejsou jediné nastavení. Kombinují řízení přístupu, řízení přístupu podle rolí, silné ověřování, návrh sítě, kontroly oprávnění, monitorování a plánování obnovy. Vyžadují také disciplínu u účtů, na které se často zapomíná: servisních identit, klíčů API, nouzových administrátorů a přihlašovacích údajů k zálohám.
Co princip nejmenších oprávnění skutečně omezuje
Přístup má několik rozměrů. Uživatel se může moci přihlásit k serveru, ale nemusí mít právo číst konkrétní adresář. Administrátor může spravovat prostředí jednoho klienta, ale ne jiného. Databázový účet může číst vybrané tabulky, ale nesmí měnit schéma ani vytvářet nové uživatele. Zálohovací proces může zapisovat data pro obnovu, ale nesmí mazat existující body obnovy.
Užitečné rozhodnutí o přístupu proto odpovídá na čtyři otázky:
- Kdo o přístup žádá: konkrétní zaměstnanec, administrátor, služba, API nebo nouzový účet?
- Jaký zdroj je zapojen: server, databáze, souborový systém, konzole pro správu nebo úložiště záloh?
- Které akce jsou potřeba: čtení, zápis, spuštění, konfigurace, vytvoření, smazání nebo obnova?
- Kdy a odkud má být přístup platný?
Nejmenší oprávnění omezují zbytečné kombinace těchto práv. Nezaručují, že účet nemůže být napaden, ani nenahrazují aktualizace, zabezpečení koncových zařízení nebo monitorování sítě. Jejich přínosem je omezení dopadu: útočník, který získá jednu identitu, by měl narazit na skutečné hranice.
Než přiřadíte oprávnění, oddělte role
Oddělení rolí je jedním z nejúčinnějších způsobů, jak zabránit tomu, aby se napadený účet stal neomezeným administrátorem. Malá firma může oddělit běžnou práci, správu serverů, správu záloh a přístup k finančním údajům nebo údajům o zákaznících. Agentura může potřebovat samostatné role pro vlastní infrastrukturu a pro prostředí jednotlivých klientů.
Řízení přístupu podle rolí činí tyto hranice opakovatelnými. Namísto přímého udělování oprávnění jednotlivcům definujte role, jako je operátor serveru, čtenář databáze, inženýr nasazení, bezpečnostní auditor a operátor záloh. Lidi přiřaďte k rolím, které potřebují, a definice rolí kontrolujte při změnách systémů.
Nepovažujte řízení přístupu podle rolí za důvod vytvořit jednu příliš rozsáhlou roli nazvanou administrátor. Role by měla představovat skutečnou pracovní funkci a omezený rozsah. Inženýr nasazení může například restartovat konkrétní aplikační službu a aktualizovat její adresář s vydáním, ale neměl by moci vytvářet uživatele operačního systému ani odstraňovat databázové zálohy.
Udržujte administrátorské identity oddělené
Lidé, kteří spravují servery, by běžně měli mít standardní účet pro e-mail, prohlížení webu a běžnou práci a samostatnou privilegovanou identitu pro správu. Snižuje se tak riziko, že phishingový útok na účet používaný každý den okamžitě odhalí administrátorská oprávnění.
Administrátorské identity by měly být pojmenované, dohledatelné a individuálně chráněné. Sdílené administrátorské přihlašovací údaje odstraňují odpovědnost a ztěžují odebrání přístupu. Pokud stejné heslo zná několik lidí, jeho změna během incidentu bude rušivá a z protokolů nebude možné spolehlivě zjistit, kdo akci provedl.
Pokud se sdílenému nouzovému účtu nelze vyhnout, uchovávejte jej pod kontrolou ve vhodném trezoru přihlašovacích údajů, vyžadujte zdokumentované vydání, zaznamenávejte jeho použití a po přístupu přihlašovací údaj změňte. Měl by být výjimkou pro obnovu, nikoli běžným způsobem správy serverů.
Pro privilegovanou práci používejte přístup just-in-time
Trvalá oprávnění představují trvalou příležitost pro útočníka. Přístup just-in-time toto vystavení snižuje tím, že zvýšená oprávnění uděluje pouze tehdy, když je úkol vyžaduje. Schválení může být ruční nebo automatické, ale mělo by uvádět cílový systém, požadovanou roli, důvod a dobu trvání.
Technik podpory může například získat přístup k jednomu produkčnímu serveru na 45 minut za účelem prošetření selhání služby. Po uplynutí této doby by mělo oprávnění zmizet, aniž by se někdo musel spoléhat na vlastní paměť a ručně je odebrat. U citlivých akcí vyžadujte, aby přístup nebo samotnou změnu schválila druhá osoba.
Časově omezený přístup je užitečný zejména pro agentury. Vývojář může během nasazení potřebovat dočasný přístup ke klientskému serveru, zatímco externí specialista může potřebovat jednorázový diagnostický přístup. Ani jeden z nich by neměl mít neomezený přístup ke všem klientským prostředím natrvalo.
Stejným principem by se měl řídit i nouzový přístup, i když je důležitá rychlost. Udržujte malý počet účtů pro mimořádné situace s přesně vymezeným rozsahem, silným ověřováním a nezávislými metodami obnovy. Při každém použití odešlete upozornění, zaznamenejte důvod a pokud možno i příkazy a událost bezprostředně poté zkontrolujte. Nouzový proces, který se nikdy netestuje, není spolehlivý proces, proto jej testujte, aniž by přihlašovací údaje byly trvale dostupné.
Nastavte ověřování tak, aby podporovalo nejmenší oprávnění
Heslo pouze dokazuje, že někdo zná tajemství. Neomezuje, co může tato identita po přihlášení dělat. Nejmenší oprávnění a ověřování řeší různé problémy: MFA pomáhá zabránit neoprávněnému přístupu, zatímco řízení přístupu omezuje škody v případě, že je přístup získán.
Používejte MFA pro administrátorské účty, VPN, cloud, zálohy a další účty s velkým dopadem. Pokud to prostředí podporuje, upřednostňujte metody odolné proti phishingu a nespoléhejte na SMS jako jedinou ochranu kritické správy. Pro privilegované identity vynucujte samostatné zásady ověřování, místo aby přebíraly nejslabší zásady používané běžnými uživateli.
Odebrání přihlašovacích údajů musí být rychlé a nacvičené. Udržujte přehled uživatelů, klíčů SSH, tokenů API, certifikátů, servisních přihlašovacích údajů a integrací třetích stran. Pokud máte podezření na napadení účtu:
- Deaktivujte nebo pozastavte identitu a odvolejte aktivní relace.
- Odeberte její členství ve skupinách, klíče, tokeny a delegovaná oprávnění.
- Vhodným způsobem zablokujte známé zdrojové adresy nebo zařízení, ale nepředpokládejte, že to samo o sobě stačí.
- Změňte tajemství, která účet mohl číst, používat nebo odhalit.
- Zkontrolujte protokoly aktivit před odvoláním i po něm.
Nespoléhejte pouze na reset hesla. Útočník už mohl vytvořit jiný účet, zkopírovat token API, přidat klíč SSH nebo si zajistit trvalý přístup prostřednictvím naplánované úlohy.
Omezte servisní účty a přístup k API
Servisním účtům se často udělují nadměrná práva, protože fungují bez přítomnosti člověka. Jde o běžný bod selhání: aplikace potřebuje číst jednu databázi, ale její účet může spravovat všechny databáze na serveru. Token pro nasazení potřebuje publikovat jednu aplikaci, ale může měnit operační systém.
Pro jednotlivé aplikace a prostředí vytvářejte samostatné servisní identity. Přihlašovací údaje pro produkci, testovací prostředí a vývoj by neměly být zaměnitelné. Každé identitě udělte pouze oprávnění potřebná pro její funkci a u účtů určených výhradně ke spouštění služeb zakažte interaktivní přihlášení.
U API omezujte tokeny podle operace, koncového bodu, prostředí, zdrojové sítě a doby platnosti. Tajemství ukládejte mimo kód aplikace a měňte je podle stanoveného harmonogramu nebo po změně personálu. Sledujte neobvyklý objem, geografický původ, neúspěšné požadavky a pokusy používat API mimo jeho zamýšlenou funkci.
Nepředpokládejte, že servisní účet je bezpečný jen proto, že jeho heslo nezná žádný člověk. Malware spuštěný na aplikačním serveru může být schopen použít jeho přihlašovací údaje a zranitelná aplikace může útočníkovi umožnit jednat prostřednictvím servisní identity. Oprávnění účtu proto musí být dostatečně úzká, aby tuto cestu omezila.
Uplatněte nejmenší oprávnění na serverech, v souborových systémech a databázích
Místo neomezeného přístupu root používejte zásady sudo
V systémech Linux používejte individuální účty a pečlivě definovaná pravidla sudo, místo abyste každému administrátorovi poskytli neomezený přístup root. Člověk, který potřebuje pouze restartovat službu, by automaticky neměl získat oprávnění upravovat autentizační soubory, instalovat balíčky nebo mazat protokoly.
Určete povolené příkazy a tam, kde je to praktické, také povolené argumenty a cílové hostitele. Buďte opatrní u příkazů, které spouštějí editory, shelly nebo skripty, protože zdánlivě úzké pravidlo se může nepřímým únikem změnit v plný přístup root. Zásady sudo kontrolujte jako kód nebo konfiguraci, testujte je a po dokončení úkolu dočasná pravidla odstraňte.
Kontrolujte oprávnění souborového systému
Oddělte kód aplikace, konfiguraci, nahraný obsah, protokoly a zálohy. Webový proces může potřebovat zapisovat do adresáře pro nahrávání, ale neměl by moci měnit spustitelný kód ani číst soukromé konfigurační soubory s přihlašovacími údaji. Databázové procesy by neměly mít obecný přístup k nesouvisejícím domovským adresářům uživatelů.
Vhodně používejte vlastnictví, skupiny, seznamy řízení přístupu a izolaci služeb. Věnujte pozornost zděděným oprávněním: nový adresář nebo účet může omylem získat přístup prostřednictvím široké nadřazené skupiny. Oprávnění testujte pomocí skutečné servisní identity, nikoli pouze pomocí administrátorského účtu, který vidí vše.
Omezte databázová oprávnění
Databázové uživatele oddělujte podle aplikace a funkce. Účet pro reportování může potřebovat přístup SELECT k definovaným pohledům, zatímco aplikační účet může potřebovat číst a aktualizovat vybrané tabulky, ale ne měnit schéma, vytvářet uživatele ani mazat data. Administrátorský přístup k databázi vyhraďte malé skupině a používejte jej prostřednictvím pojmenovaných identit.
Pokud to architektura aplikace umožňuje, oddělte přihlašovací údaje pro čtení a zápis. Omezte databázová připojení podle hostitele nebo segmentu sítě, šifrujte připojení a zaznamenávejte administrátorské operace. Pokud je webová aplikace napadena, úzká databázová oprávnění mohou útočníkovi zabránit proměnit přístup k aplikaci v neomezené zničení dat.
Využijte segmentaci sítě jako další hranici oprávnění
Oprávnění identity nestačí, pokud se každý server může volně připojit ke každému jinému serveru. Segmentujte sítě a definujte explicitní pravidla provozu mezi zařízeními uživatelů, aplikačními servery, databázemi, rozhraními pro správu a zálohovacími systémy.
Frontendový server může potřebovat přístup k aplikačnímu portu a aplikace může potřebovat přístup k databázovému portu. Ani jeden z nich nutně nepotřebuje SSH přístup ke každému počítači. Rozhraní pro správu by měla být dostupná pouze ze schválených administrátorských cest, například z řízené VPN nebo sítě pro správu. Úložiště záloh by neměla být široce dostupná z produkčních úloh.
Segmentace omezuje laterální pohyb po napadení účtu nebo serveru. Zároveň zviditelňuje neobvyklou aktivitu: pokus webového serveru připojit se k rozhraní pro správu nebo pokus pracovní stanice kontaktovat úložiště záloh by měl vést k prověření.
Chraňte zálohy před napadenými produkčními účty
Záloha dostupná prostřednictvím stejného účtu nebo serveru, který chrání, může být během útoku zničena. Ransomware se před zašifrováním produkčních dat běžně pokouší najít zálohovací software, úložiště a přihlašovací údaje. Obnova závisí na oddělení přístupu k zálohám od správy produkce.
Používejte vyhrazenou zálohovací identitu s co nejmenšími možnými oprávněními. Produkční účet by neměl moci mazat, měnit ani zkracovat dobu uchování zálohovaných dat. Pokud to návrh umožňuje, správa záloh by měla využívat samostatnou cestu pro správu, samostatné přihlašovací údaje a MFA. Přístup k obnově by měl být rovněž řízen: lidé, kteří provozují produkci, automaticky nepotřebují oprávnění mazat historii záloh.
Pro servery kontrolované zákazníkem poskytuje Safenix zálohování mimo lokalitu, šifrované klíčem, který Safenix nikdy nedrží, uložené v Německu a neměnné po celou dobu uchování. Toto oddělení je důležité, když napadený účet serveru může poškodit živé prostředí. Více si můžete přečíst o tom, jak Safenix chrání šifrované zálohy a řídí, kdo je může číst.
Safenix chrání firemní servery kontrolované zákazníkem. Neposkytuje plán zálohování pro weby provozované na sdíleném hostingu, kde zákazník nekontroluje základní server. Toto rozlišení je důležité při posuzování, zda návrh zálohování skutečně dokáže oddělit data pro obnovu od produkčních přihlašovacích údajů.
Kontrolujte přístupy průběžně, ne pouze jednou ročně ze zvyku
Oprávnění se hromadí. Zaměstnanci mění role, agentury dokončují projekty, dodavatelé odcházejí a dočasný přístup pro řešení problémů se stává trvalým. Neaktivní účty jsou pro útočníky obzvlášť lákavé, protože mohou mít stále užitečná práva, ale věnuje se jim jen malá pozornost.
Udržujte přehled přístupů, který zahrnuje:
- Pojmenované uživatelské a administrátorské účty
- Skupiny, role a delegovaná oprávnění
- Klíče SSH, tokeny API, certifikáty a tajemství aplikací
- Servisní účty a naplánované úlohy
- Externí agentury, dodavatele a poskytovatele podpory
- Nouzové identity a účty pro mimořádné situace
- Účty pro zálohování, monitorování a správu infrastruktury
Přístupy kontrolujte po nástupu, změně pozice nebo odchodu pracovníků, po skončení projektu a po zásadních změnách infrastruktury. Naplánovaná kontrola může u privilegovaných přístupů probíhat měsíčně a u širších přístupů čtvrtletně, přičemž frekvenci upravte podle rizika. Požádejte vlastníka zdroje, aby potvrdil nejen to, že účet patří správné osobě, ale také že každé oprávnění je stále nezbytné.
Agentury by se měly vyhýbat zděděným oprávněním napříč klientskými prostředími. Technik, který podporuje klienta A, by neměl dostat roli, jež automaticky uděluje přístup klientům B, C a D. Kdykoli je to možné, používejte samostatné tenanty, účty, skupiny, klíče nebo rozsahy správy. Pokud centrální nástroje oddělení ztěžují, považujte to za návrhové riziko, nikoli za důvod přijmout široký přístup jako nevyhnutelný.
Monitorujte používání oprávnění a uchovávejte důkazy
Nejmenší oprávnění fungují nejlépe, když vidíte, jak se oprávnění používají. Zaznamenávejte ověřování, zvyšování oprávnění, změny rolí, nové klíče, vytváření tokenů, změny oprávnění, správu databází a akce se zálohami. Uvádějte identitu, cíl, čas, zdroj, výsledek a případně také tiket nebo schválení spojené s akcí.
Důležité protokoly odesílejte mimo spravované systémy, aby útočník nemohl důkazy potají přepsat. Přístup k protokolům chraňte samostatnými oprávněními a definujte dobu uchování, která podporuje vyšetřování i právní nebo regulatorní potřeby. Synchronizovaný čas na serverech výrazně zvyšuje spolehlivost korelace událostí.
Monitorování by se mělo zaměřovat na smysluplné signály, nikoli vytvářet upozornění, kterým se nikdo nedokáže věnovat. Příklady zahrnují:
- Běžný uživatel získá administrátorskou roli
- Nouzový účet je použit mimo nahlášený incident
- Servisní účet provede interaktivní přihlášení
- Token je použit z neznámé sítě nebo v neobvyklou dobu
- Rozsáhlé změny oprávnění napříč několika klientskými prostředími
- Pokusy o přístup k zálohovaným datům, jejich smazání nebo změnu
Po spuštění upozornění uchovejte relevantní protokoly, historii příkazů, záznamy ověřování a stav systému, než provedete změny, které by mohly zničit důkazy. Zároveň neodkládejte omezení incidentu ve snaze dosáhnout dokonalého forenzního sběru. Zaznamenejte, co bylo změněno, kým a kdy, a u závažných událostí spolupracujte s kvalifikovanou podporou pro reakci na incidenty.
Odstraňte běžná místa selhání
Mnoho programů nejmenších oprávnění selhává kvůli provozním zkratkám, nikoli technické nemožnosti. Dávejte pozor na tyto vzorce:
- Sdílené administrátorské přihlašovací údaje: Znemožňují spolehlivé určení odpovědnosti, komplikují ukončení přístupu a činí rychlé odvolání rušivým.
- Trvalý přístup agentur: Dodavatel může občas potřebovat přístup k jednomu serveru, nikoli trvalý přístup ke každému klientskému prostředí.
- Neaktivní účty: Účty bývalých zaměstnanců, dodavatelů a testerů si mohou zachovat cenná oprávnění dlouho po skončení svého účelu.
- Zděděná oprávnění: Široké skupiny a vnořené role mohou bez povšimnutí udělit přístup napříč klienty, servery nebo úložišti dat.
- Jeden účet pro každou funkci: Kombinace oprávnění pro nasazování, databázi, operační systém a zálohy vytváří jediný cíl s vysokým dopadem.
- Dočasné výjimky bez konce platnosti: Nouzová pravidla sudo, otevřené porty firewallu a tokeny API potřebují vlastníky a automatická data ukončení.
- Správa záloh z produkce: Pokud stejný administrátor může měnit živé systémy i data pro obnovu, může to dokázat také útočník.
Pro další informace si projděte praktické pokyny k principu nejmenších oprávnění a napadeným účtům a poté tyto myšlenky vztáhněte ke systémům a odpovědnostem, které vaše firma skutečně provozuje.
Praktické priority pro malé firmy a agentury
Malé týmy nepotřebují obrovskou platformu pro správu identit, aby dosáhly významného pokroku. Začněte seznamem kritických systémů a identit, které je mohou spravovat, měnit nebo mazat. Odstraňte sdílené přihlašovací údaje, deaktivujte neaktivní účty a vyžadujte MFA pro privilegovaný přístup.
Dále oddělte oprávnění pro produkci, správu a zálohy. Vytvořte pojmenované administrátorské účty, omezte servisní identity, zúžte oprávnění databázových uživatelů a omezte síťové cesty mezi servery. Přidejte proces schvalování a ukončení platnosti externího přístupu, i kdyby zpočátku využíval pouze tiket a připomenutí v kalendáři.
Nakonec si reakci otestujte. Dokážete rychle deaktivovat přístup zaměstnance? Dokážete odebrat člena agentury, aniž by to ovlivnilo ostatní klienty? Dokážete zjistit, který účet změnil pravidlo firewallu? Dokážete obnovit data, pokud je produkční administrátor napaden? Pokud je odpověď nejasná, nejde pouze o problém řízení přístupu, ale také o problém odolnosti.
Nejmenší oprávnění mohou neobvyklým úkolům přidat malé množství tření. Toto tření je užitečné, když běžným účtům zabrání v provádění ničivých akcí. Navrhněte smysluplné role, zajistěte rychlé zvýšení oprávnění just-in-time a udržujte nouzový přístup pod kontrolou. Cílem není blokovat legitimní provoz. Cílem je zajistit, aby jedna ukradená identita neznamenala oprávnění ovládnout celou firmu.