SU24: Výhody používání SU24

V předchozím textu – Co a proč je SU24 – jsme si vysvětlili motivaci a základní princip fungování

transakce SU24. Nyní si shrňme hlavní výhody jejího používání.

(1) Vytvoř jednou, použij mnohokrát

Abychom mohli libovolnou aplikaci správně autorizovat, musíme porozumět tomu, co všechno ta

aplikace umí a jaká oprávnění k tomu potřebuje. Aplikaci tedy zběžně spustíme a podle toho jaké

kontroly oprávnění provádí ji v roli autorizujeme. Později tu samou aplikaci potřebujeme autorizovat v jiné roli. Nezbývá nám, než znovu zkoušet to že to ta aplikace dělá, abychom ji znovu správně autorizovali. Leda že bychom si mohli někam poznamenat to, co jsme o aplikaci už zjistili a příště to už jen použít. A to je přesně úloha SU24. Umožnit nám práci udělat jen jednou a příště už ji vždy jen znovu použít. 

(2) Oprav jednou, použij mnohokrát

Aplikace se aktualizují a vylepšují, a proto mohou vyžadovat nová nebo upravená oprávnění. Po

takové aktualizaci musíme zajistit, že všichni uživatelé dané aplikace ta oprávnění získají, aby jim

aktualizovaná aplikace fungovala správně. Díky používání SU24 je aktualizace pro administrátora

hračka. Nejprve doplní nové oprávnění do SU24 popisu aplikace. Ve druhém kroku je potřeba

aktualizovat všechny role, které danou aplikaci autorizují. SU24 pro svoji funkci vyžaduje, aby

aplikace byla umístěna v menu role, takže stačí jen vyhledat všechny role, které aplikaci v menu mají. Do každé z těchto rolí vstoupíme ve změnovém režimu, potvrdíme aktualizaci a hotovo. Efektivním a přesně definovaným způsobem jsme všechny role snadno aktualizovali. 

(3) Vytvořeno a opraveno, alespoň pro standardní aplikace

Vytvořit SU24 popisy aplikací není úplně malý úkol. V případě standardních aplikací ale máme štěstí. SAP totiž ve formě SU22 dat (které si zákazník kopíruje do SU24 dat a dále upravuje) dodává popisy standardních aplikací. Někdy jsou standardní popisy neúplné nebo trochu krkolomné, ale kus práce zastanou. Tímto způsobem získáváme velký náskok a výhodu.

Pro standardní aplikace provádíme pravidelně aktualizace systému, abychom v rámci podpory SAP

získali aktuální opravy a vylepšení. Stejné aktualizace a vylepšení získáváme pro SU24 data. Je třeba

pravidelně spouštět transakci SU25 a provádět také aktualizaci oprávnění, ale jak už bylo řečeno,

získáme tím velký kus práce.

(4) „Kde se to tu vzalo?“

Když autorizujeme aplikaci tím, že do role prostě vložíme nějakou sadu oprávnění, technicky to

funguje. Problém nastane až později, když se kolega nebo dokonce externí auditor zeptá "Proč je

tohle oprávnění v této roli?" A pokud si člověk nevedl důkladnou dokumentaci o všech změnách, je z toho problém. SU24 přidává dvě další automatické úrovně dokumentace, která by kolegovu nebo

auditorovu otázku bezpracně a automaticky ihned zodpověděla.

Aby SU24 data aplikace mohla být v roli použita, v prvním kroku musíme aplikaci přidat do menu

role. Když se potom někdo zeptá, proč jsou nějaká oprávnění v roli, odpověď je ve většině případů snadná "Uživatelé postrádali aplikaci X". Nevyhnutelně přijde druhá otázka: "Proč aplikace X nabízí

oprávnění Y?" Odpověď je opět snadná: v SU24 datech hned vidíme kdo a kdy tam oprávnění přidal a pak se automaticky převzalo do role. A proč tohle oprávnění? Protože programový kód té aplikace

přesně tohle oprávnění vyžaduje. Použitím SU24 se budou vaše role dokumentovat samy, a ještě

potěšíte kolegy i auditory.

(5) Kvalita a konzistence

Některé aplikace jsou dost komplexní a rychlým „proklikáním“ si těžko uděláme přesný obrázek o

tom, jaká oprávnění vyžadují. Takže je možné, že uživatelům poskytneme méně oprávnění, než kolik

jich budou k používání aplikace potřebovat. Ideální proto je, když naše aktivity nejsou jen náhodné

opravy chybějících oprávnění, ale systematické zlepšování. Díky možnosti popisovat si aplikace a

jejich oprávnění pomocí SU24 máme jednu centrální databázi, kterou rozvíjíme a zlepšujeme a

nestane se nám, že jednomu uživateli (v jedné roli) oprávnění opravíme, ale ostatní nám problém

nahlásí hned vzápětí. Vždy vytvoříme nebo opravíme jeden centrální popis aplikace v SU24 a podle

bodů (1) a (2) výše konzistentně doplníme oprávnění všem.

(6) GRC access control

Pokud již používáte nebo alespoň zvažujete použití SAP GRC, jistě víte, že tato SAP komponenta

mimo jiné umožňuje hledat kritická oprávnění v rolích nebo oprávnění uživatelů. Drobná nevýhoda

spočívá v tom, že většinou když takový problém najdeme, tak to znamená, že už existuje. To auditoři nevidí vůbec rádi. Mnohem lepší je zjistit, že se problém blíží, ale když něco podnikneme, můžeme se problému vyhnout. A to auditoři mají mnohem raději. Jestliže máme k dispozici SU24 pro jednotlivé aplikace v roli, můžeme zjistit, že role bude mít problém, pokud do ní nějakou aplikaci s kritickým oprávněním přidáme (nebo tím vytvoříme kritickou kombinaci). Jinými slovy můžeme problém vidět dopředu. Pokud už problém vznikl, je ho potřeba řešit – vyhledat která aplikace nebo kombinace aplikací problém způsobuje a pokusit se je od sebe oddělit. Když bychom ale nevěděli odkud problematická oprávnění pocházejí, se kterými aplikacemi do role přibyly (bod (4) výše), hledání nápravy by bylo velmi bolestivé. 

(7) GRC access control pro zákaznický kód

Předchozí problém se SAP GRC nemusí být až tak palčivý pro standardní aplikace, pokud pravidelně

provádíte upgrade SU24/SU25 (bod (3) výše). U zákaznického kódu ale SU24 popis sám nevzniká,

někdo ho musí vytvořit. A pokud se tomu administrátor aktivně nevěnuje, GRC komponenta uvidí v

zákaznickém vývoji jenom velké nic. Vyhodnotit nějaké autorizační aspekty zákaznického kódu je v

této situaci naprosto nemožné. Koupíte si SAP GRC, ale použitelné výsledky dostanete jen v úterý a v listopadu. Proto je důležité aktivně myslet také na SU24 popis zákaznických aplikací.