SoD aneb oddělení odpovědností

Cílem oddělení odpovědností (Segregation nebo také Separation of Duties, zkr. SoD) je minimalizovat riziko zneužití přístupu k datům a funkcím systému.

Je nasnadě, že když jeden zaměstnanec zastává vícero rolí, tak je zde vyšší riziko podvodu ze strany tohoto zaměstnance anebo zneužití tohoto účtu někým jiným.

Z tohoto důvodu je třeba identifikovat role, které by neměly být vykonávány jednou osobou, což může být v mnohých organizacích problém, protože z důvodu tlaku na co nejnižších náklady a implementaci agilních přístupů jako je DevOps u nich často dochází k nežádoucí kumulaci rolí a tedy i k narušení principu SoD.

A zatímco u některých organizací absence SoD může vyplývat ze snahy ušetřit, tak u jiných se může zase jednat o pouhou neznalost a nedostatečnou schopnost identifikovat související rizika (např. s přechodem do cloudů může být management v pokušení kontrolu nad ním svěřit do rukou jedné osoby) a v krajním případě se může jednat i o kreativní řízení rizik.

Ostatně stačí se jen podívat na inzeráty firem, které shánějí nějakého toho super experta, který bude instalovat a konfigurovat, stanice, servery, sítě, spravovat databázi, programovat web, no prostě dělat takovou děvečku pro všechno. Takováto kumulace rolí představuje řadu rizik. Může dojít k:

  • narušení kontinuity podnikání (v důsledku nedostatečné zastupitelnosti a plánu následnictví, protože i tenhle super expert může jednoho dne vysílením odpadnout nebo odejít);
  • podvodu (má příležitost a spolu s nedostatečným finančním ohodnocením nebo nedostatečným oceněním a respektu podvod realizuje, toto riziko roste v době krize);
  • kybernetickému útoku (stačí jen ovládnout účet tohoto super experta a útočník má v mžiku pod kontrolou celou infrastrukturu organizace).

Asi už tušíte, že ve výsledku se žádná úspora nákladů konat nebude a firmu bude obnova provozu v případě výpadku nebo kybernetického útoku stát nakonec mnohem více než očekávaná úspora na mzdových nákladech.

Vzhledem k tomu, že neexistuje standard, který by jasně a přesně definoval jednotlivé role, a jejich pracovní náplň, takt to vede k tomu, že je pracovní náplň osob, zaujímající alespoň dle pojmenování pozice stejnou pracovní pozici, organizace od organizace více či méně odlišná, a proto se musí nad tímto administrativním opatřením každá organizace zamyslet sama.

V zásadě platí, že nikdo by neměl mít plnou kontrolu nad celý procesem, aby nemohl provádět nežádoucí modifikace, sám si schvalovat změny apod. Vždy by mělo platit, že:

  • jedna osoba může analyzovat, navrhnout a vyvinout systém, ale nemůže již daný systém nastavovat, provozovat a posuzovat kvalitu;
  • správce databáze, systému nebo sítě může být bezpečnostním administrátorem spravovaného systému, ale nikdo by neměl být správcem více vrstev, tedy jinými slovy role správce systému, databáze a sítě jsou neslučitelné;
  • koncový uživatel by neměl obdržet roli systémového programátora anebo systémového či síťového administátora, aby neměl možnost začlenit do kódu backdoor nebo logickou bombu anebo si sám povolit komunikaci do internetu pro aplikaci, kterou nasadil v rámci EUC.

V okamžiku, kdy oddělení povinností není z nějakého důvodu možné, měla by být navržena a zavedena vhodná kompenzační opatření. Např. logování veškerých aktivit dané osoby do systému, který není pod její správou a pravidelné vyhodnocování těchto logů.

To přirozeně vede k best practice jako je management stanice-jump host, síťové oddělení managent prostředí, produkce a neprodukce. A rovněž i zavedení povinné dovolené např. v délce trvání 14 dnů. Což nejsou sice až tak účinná opatření, ale mohou v mnoha případech fungovat nejen jako odstrašující, ale i detekční opatření.

Každá organizace by si měla vytvořit vlastní SoD matici a do ní si zanést, které role jsou neslučitelné, a které tak nemohou být jednomu uživateli nikdy přiděleny. V ideálním případě by toto mělo být kontrolováno a zajištěno nějakým RBAC nástrojem a pravidelně kontrolováno v rámci CSA.

Na tomto místě je rovněž nutné zmínit, že i firma, co si riziko narušení principu SoD uvědomuje, musí nějak řešit zastupitelnost. A zpravidla to řeší tak, že si jiný zaměstnanec osvojí tytéž dovednosti a budou mu přidělena i nezbytná oprávnění, aby danou funkci mohl v případě výpadku primární osoby vykonávat.

V anglosaské literatuře se o tomto procesu hovoří jako o cross-trainingu a jeho zavedením pak může dojít k narušení principu SoD. Jinými slovy jedna osoba může postupně získat kompletní znalosti o fungování celého procesu a pak jej může i ovládnout.

Na druhou stranu to, že ta nenahraditelná osoba musí někoho naučit a ideálně vytvořit písemnou dokumentaci, může pomoct managementu detekovat činnosti, které by měl dělat někdo třetí.

Máte něco jako SoD matici?

Nahrávání ... Nahrávání ...
Pokud vás tento článek zaujal, můžete odkaz na něj sdílet.

Štítky:

  1. Tomáš Mertl

    To, co je zde v principu popisováno, je označováno za Static SoD. Ale jsou i komplexnější modely Dynamic SoD, kde je třeba možné, že jeden uživatel mám přístup ke všem částem procesu, ale například na aplikační úrovni je zajištěno, že v jedné konkrétní instanci procesu nemůže mít zároveň možnost požadavek zadat a zároveň ho schválit. Přestože má právo na zadání i schválení.


K článku “SoD aneb oddělení odpovědností” se zde nachází 1 komentář.

Diskuse na tomto webu je moderována. Pod článkem budou zobrazovány jen takové komentáře, které nebudou sloužit k propagaci konkrétní firmy, produktu nebo služby. V případě, že chcete, aby z těchto stránek vedl odkaz na váš web, kontaktujte nás, známe efektivnější způsoby propagace.

Přihlášeným uživatelům se tento formulář nezobrazuje - zaregistrujte se.

Jméno:(požadováno)
E-mail:(požadováno - nebude zobrazen)
Web:

Text vaší reakce: