top of page
bg_02_short.png

SONNENBERGER AKADEMIE

Role: status oprávnění

  • Obrázek autora: Johana Zelinska
    Johana Zelinska
  • 4. 5. 2023
  • Minut čtení: 4

Aktualizováno: 13. 5. 2023


Dnes si demonstrujeme, jak fungují jednotlivé typy oprávnění v transakci PFCG. Rozlišujeme 4 typy: Standard, Maintained, Modified a Manual. Pro zdravý rozvoj našich rolí nejsou všechny tyto typy stejně vhodné, vlastně jsou některé zcela nevhodné. Lepší než si to složitě popisovat, raději si níže ukážeme nějaké příklady, na kterých budou rozdíly, výhody a nevýhody dobře vidět.

Jako první krok vložme do menu naší demonstrační role nějakou transakci. Použijme takovou transakci, která existuje ve všech systémech – například SU01 pro administraci uživatelů – abychom byli následující příklady schopni zopakovat v libovolném systému.

Pro následující příklady bude stěžejní, že pro transakci SU01 nám SAP připravil její částečný popis pomocí SU24 dat. Zjednodušeně řečeno nás tato data informují o tom, jaké různé kontroly oprávnění (AUTHORITY-CHECK) jsou naprogramovány v kódu transakce SU01. Administrátor na základě tohoto SU24 popisu v budoucí roli pouze doplní chybějící hodnoty otevřených polí, případně deaktivuje oprávnění k funkcím, které by neměly být pro tuto konkrétní roli k dispozici. Pro úplnost jen dodejme, že pokud se v PFCG data z transakce SU24 neobjeví, znamená to, že někdo neprovedl jejich základní nahrání v transakci SU25 při instalaci systému a je to třeba rychle dohnat. Práce bez standardních SU24 je velmi neefektivní a potenciálně chybová.


Oprávnění typu „Standard“

Jsou-li v našem demonstračním systému SU24 k dispozici a naše demonstrační role má v menu vloženu transakci SU01, v záložce oprávnění role získáme neúplný popis oprávnění pro přibližně 10 autorizačních objektů.

Instance pro objekt S_TCODE bude úplná, bez otevřených polí a proto zelená, a označená „Standard“.

Dalších několik objektů bude žlutých, některá autorizační pole nejsou v SU24 datech vyplněna a my o nich musíme rozhodnout v rámci role. Protože však všechny tato informace pocházejí z transakce SU24, typ instancí těchto objektů bude také „Standard“. To znamená, že všechny tyto hodnoty pocházejí ze „standardních“ SU24 dat a jsou bez lokální změny. Typ „Standard“ nám přináší velkou výhodu – informaci, odkud konkrétní data oprávnění pocházejí. Transakce PFCG si pamatuje, že načetla tato data z SU24 popisu transakce SU01, která je vložena v menu. Jestliže později budeme chtít transakci SU01 z role odstranit, PFCG automaticky odstraní oprávnění, která pocházela z SU24 popisu transakce SU01. Jestliže později budeme provádět audit oprávnění v této roli, pro všechny typy oprávnění „Standard“ budeme mít k dispozici informaci, kde se v této roli tato konkrétní oprávnění vzala (tzv. „where-used list“).

Tímto způsobem vytváříme role, které není třeba dokumentovat. Do budoucna budeme vždycky vědět, proč tam konkrétní oprávnění jsou, budeme je moci snadno odstranit a v případě, že se SU24 popis zdrojové transakce (SU01) změní, role si automaticky změny vyžádá a integruje je.


Oprávnění typu „Maintained“

Nyní je čas připomenout, že některá SU24 data, která jsme nahráli, byla úplná, bez otevřených polí, ale některá data byla neúplná, s otevřenými poli. Otevřená pole potřebujeme před produktivním použitím role uzavřít. Doplníme do otevřených polí hodnoty a tím se typ instance změní ze „Standard“ na „Maintained“. To je ale předvídaný a správný způsob práce, takže výhody popsané pro typ instance „Standard“ budou platit i pro „Maintained“.

Tímto jsme vyčerpali ty „hodné“ typy oprávnění. Typy oprávnění, které jsou úzce svázané s SU24 daty a které nám umožňují vytvářet oprávnění, která jsou zpětně dokumentovatelná a do budoucna snadno změnitelná. Zbývající dva typy oprávnění bohužel uvedené výhody nemají.


Oprávnění typu „Changed“

Typ “Changed” dostaneme, jestliže změníme autorizační pole s hodnotou “Standard“ na hodnotu jinou. Například administrátor v transakci SU24 předepsal, že v budoucí roli budeme například potřebovat aktivity (pole ACTVT) s hodnotami 01 (Create/Vytvořit), 02 (Change/Změnit) a 03 (Display/Zobrazit). Nyní v roli bychom ale chtěli umožnit pouze 03 (Display/Zobrazit) přístup. Nyní máme dvě možnosti, jak postupovat a musíme se velice dobře zamyslet na důsledky našeho rozhodnutí.

Jedna možnost je, že se v roli skutečně rozhodneme postupovat jinak, než to předvídal předchozí administrátor SU24 dat a hodnoty 01,02 a 03 změníme („Change(d)“) pouze na hodnotu 03. Tímto jsme ztratili všechny výhody, které jsme z menu role a SU24 popisu doposud získali. Od této chvíle nebudeme pro tuto instanci oprávnění vědět odkud pochází (přijdeme o „where-used list“ a tedy dokumentaci toho, kde se tohle oprávnění vzalo a proč). Všechny operace spojené s automatickou aktualizací nebo odebráním tohoto oprávnění operacemi s menu role přestanou být k dispozici.

Zdá se, že jsme náš aktuální požadavek poskytnout jiné oprávnění, než předpokládala SU24 data, vyřešili elegantně a rychle. Na jedno kliknutí. Za cenu aktuálního drobného urychlení jsme ale přišli o mnoho do budoucna. Ještě pár takovýchto zásahů do oprávnění a bez velmi dobré dokumentace bude naprosto nemožné zjistit, proč tato role vypadá tak, jak vypadá. A protože dokumentaci buď administrátoři nepíšou, nebo ji zapomínají aktualizovat, jsou naše změny v podstatě navždycky nedohledatelné a nezdůvodnitelné. Proto doporučujeme tuto možnost vůbec nepoužívat. Jen proto, že existuje, neznamená to, že je to opravdová alternativa.

Správný přístup je druhá alternativa – uvědomit si, že SU24 data jsou příliš restriktivní, že nemohou rozhodnout něco, co je potřeba rozhodnout v různých rolích individuálně. Správně nyní musíme přepnout do transakce SU24, uvedené hodnoty vymazat, pole tím otevřít, a potom v jednotlivých rolích uzavřít odlišnými hodnotami podle toho, k čemu budou jednotlivé role sloužit.

Tímto správným způsobem jsme si umožnili flexibilitu, která změní oprávnění typu „Standard“ na typ „Maintained“. O tom již z předchozího popisu víme, že to je „ten hodný“. Do budoucna nám zůstane vazba na zdrojový menu objekt a všechny automatické operace a sebe-dokumentace.


Oprávnění typu „Manual“

Oprávnění typu „Manual“ nezískáme jinak než že skutečně ručně, zmáčknutím tlačítka, vložíme do role objekt podle našeho výběru a uzavřeme jeho políčka vybranými hodnotami. Jinými slovy typ „Manual“ nemá nic společného s transakcemi v menu role a nemá vazbu na SU24 popis transakcí. To je také účel a poslání typu „Manual“.

Předesílám, že typ „Manual“ by také bylo nejlepší nepoužívat. Opět, jako pro typ „Changed“ platí, že nemáme žádné informace, kde se tato oprávnění vzala nebo proč. Za určitých okolností ovšem nevýhoda – žádná vazba na menu a SU24 – je právě ten důvod, proč typ „Manual“ za určitých okolností můžeme použít.

Například se rozhodneme, že nějaký konkrétní objekt (typicky nějaký kritický objekt) budoucímu uživateli této role zpřístupníme. Abychom přístup k tomuto objektu ochránili před jakýmikoli neúmyslnými změnami, tedy změnami menu role nebo SU24 dat transakcí v menu, vložíme objekt do role manuálně. Jediný způsob, jak by role (a uživatel této role) mohl o tento přístup přijít je ten, že bychom skutečně jednoznačně pro toto konkrétní oprávnění rozhodli o jeho ručním oprávnění.

Speciální variantou použití manuálních oprávnění jsou velké změny SU24 dat, které by mohly negativně ovlivnit produktivně používané role. Jaké speciální triky pro projektovou práci lze s úspěchem použít, včetně toho s manuálními oprávněními, si rozebereme v dalších příspěvcích.



Nejnovější příspěvky

Zobrazit vše
Oprávnění: Role

Uživatelé v aplikačním serveru ABAP získávají oprávnění třemi způsoby – z přiřazených rolí, profilů a potenciálně z referenčního...

 
 
 

Comments


Sonnenberger, @ Copyright 2023 | Provozovatel: Sonnenberger, +420 607 010 020, info@sonnenberger.cz

  • LinkedIn
bottom of page