Autorisaties: Scope van functies

[Johan]

Onze EDP-auditor komt weer op bezoek, en ik moet weer even de autorisaties nakijken. Een vervelend karweitje, want je doet het echt noooit goed. Een mooie steun vormt het gebruik van de 'scope' van een functie, (SYSCFU), welke gelijk heel wat mee zou moeten pakken. Hier en daar zijn nog wat hiaten waar jullie nog eens aandacht aan zouden mogen besteden:

De scope van "LO", "SY", "PK", en "AD" zou een heel groot part van de in Profit aanwezige functies moeten hebben geraakt. Je moet eigenlijk nagenoeg alles benoemen.

Iemand die ervaring heeft met hoe je een EDP-auditor uit moet leggen hoe de autorisaties in Profit geregeld zijn: uw tips zijn meer dan welkom, het is elk jaar weer een strijd met die lui. 

In de Scope van LO, mis ik het volgende:

1a. LOTSMN. (Deze is geheel niet te autoriseren met een scope, ook LOTSMN zelf kent geen scope en geen naam volgens de autorisaties, terwijl het niet een functie is die alleen maar op de achtergrond actief kan zijn ).
1b., LOEYAR Selectie artikel (volgend uit LOAR optie 7 Histiorische Kostprijzen, valt niet onder de scope van LO. Daardoor kan iemand dus ineens wel Historische kostprijzen muteren.


2. LOVAVEMB - Massaal herberekenen VTW artikel-/Verschyningen --> Deze omschrijving is niet bekend bij de autorisaties, de naam is wel bekend als je de scope van de functie "LO" raadpleegt. Vreemd.

3. LOKOVL - Kopieren Artikelgegevens wordt door Profit niet gezien als een mutatiefunctie.
Stel je richt voor iemand het volgende in: de autorisatie key "LO", geautoriseerd N, Scope J, Expl toegang "N", Ink. Mutatiefuncties "J", daarna de autorisatie key "LO", geautoriseerd J, Scope J, Expl toegang "N", Ink. Mutatiefuncties "N", dan mag diegene geen artikelen tv/wij/vw, maar wel kopieren. Naar mijn idee is kopieren wel degelijk een mutatiefunctie.

4. lortcp Kopieren deel van een recept wordt door profit niet gezien als een mutatiefunctie. Waarom eigenlijk niet, want je muteert best wel wat.

5. functie FUNKTIE: LORPDI OMSCHRIJVING:  Receptuur Beheer - Diversen   kent geen omschrijving in de autorisaties, maar wel als je de scope print (via LO). mag de omschrijving aldaar ook getoond worden

6. FUNKTIE: LOOG OMSCHRIJVING:  Receptoptimalisatie Beheer, idem

7. FUNKTIE: LOKVARGN  OMSCHRIJVING:  Genereren Keuringsnorm in Artikel-range wordt wel opgenomen in de scope van LO, maar wordt helaas niet gezien als een mutatiefunctie, terwijl je er heel wat mee kunt muteren.

8. FUNKTIE: LOEOEF2   OMSCHRIJVING:  Effektueren Econ. Ordergrootte is er ook zo'n voorbeeld van.

9. FUNKTIE: LORDKVKO  OMSCHRIJVING:  Kopi‰ren Keuringsnormen van/naar Debiteur idem

10. FUNKTIE: LOUWKO    OMSCHRIJVING:  Kopi‰ren Uservariabelen idem. Geen idee wat uservariabelen bij een debiteur ook alweer zijn, maar zelfs de helptekst waarschuwt dat je iets gaat muteren. Je ziet ze o.a. terug in het Relatie Menu CRM.

11. FUNKTIE: LOUFGN OMSCHRIJVING: Genereren Uitg. Fakturen: is geen mutatiefunctie

12. FUNKTIE: LODBAGGN  OMSCHRIJVING:  Genereren Assortiment Klient o.b.v. Artikelgroep Hierarchie: kent geen omschrijving in de autorisaties, maar wel als je de scope print (via LO). mag de omschrijving aldaar ook getoond worden. Tevens is het geen mutatiefunctie.

13. FUNKTIE: LOVELEKZ  OMSCHRIJVING:  Keuze Raadplegen Raaplijsten  : kent geen omschrijving in de autorisaties, maar wel als je de scope print (via LO). mag de omschrijving aldaar ook getoond worden.

14. LOLRRG - Raadplegen / invullen raaplijsten: Valt niet onder de scope van enige functie (je kunt het wel zo inrichten dat je er niet kunt komen) Is dit nou werkelijk geen mutatiefunctie? je muteert toch echt wel wat. Misschien is dit verborgen in een andere functie die je niet ziet of iets dergelijks.

15. FUNKTIE: LOVBMN    OMSCHRIJVING:  Vrachten / Vrachtbrieven  : kent geen omschrijving in de autorisaties, maar wel als je de scope print (via LO). mag de omschrijving aldaar ook getoond worden.

16. LOELOGDL (Gedeeltelijke ontvangst emballage) Valt niet onder de mutatiefuncties. Ook hier muteer je heel wat zou ik zo zeggen. Jammer dat het geen omschrijving kent terwijl het wel zichtbaar is als je naar die functie toe gaat. Ook hier zullen wel onder-water functies de oorzaak zijn.

17. LORTCPBE Kopi%ren Recept naar Bedrijf Is nog zo'n functie die wel muteert, maar niet als zodanig wordt gezien.

18. LORRRA Raadplegen relaties per rubriek (LO<2-1-2-F2>maakt geen onderdeel uit van de scope van LO. Is dit te verhelpen? Verder is ook het getagd verwijderen van relaties aldaar geen mutatiefunctie. Ook niet als je LORRRA apart opgeeft mét mutatiefunctie en scope op Ja.

Is het gezien het bovenstaand ook mogelijk om bij het raadplegen scope van een functie nog eens er bij te zetten wat wel en niet een mutatiefunctie is?

Er zullen vast nog wel wat zaken opvallen, zal dit t.z.t. dan wel aanvullen.

[Johan]

Ik heb gewoon eens vergeleken: van welke functies zie ik wél een omschrijving als ik de scope van de functie "LO" afdruk, en welke functies daarvan tonen geen omschrijving als ik de autorisaties van autorisatiegroep afdruk. dat zijn er tenminste 575, te weten: zie bijlage, want dat past niet in 1 post.

[Peter Stordiau]

Om meerdere redenen een interessante post Johan. Het toont in elk geval mede dat die omschrijvingen "hier wel, daar niet" worden weergegeven, waarbij ik de Releasenotes al een tijd van "niet" verdenk.

Aangaande het muteren kunnen we daar -denk ik- tegenwoordig verregaand verbetering in aanbrengen.
Merk in elk geval op dat dit alles geautomatiseerd wordt bepaald, en dat het niet zo is dat iemand hier van een funktie kenmerkt wat voor een soort het is.

Die EDP auditor kan ik me alles bij voorstellen (zelf meerdere keren tegenover zo'n man gezeten), en je moet van aardige huize komen wil je niet "nat gaan". Maar, in de praktijk dus net zo goed; als jij niet wilt dat iedereen in LOAR enz. kan browsen, moet je echt wel wat uithalen, wat voor zover ik weet één klant ook daadwerkelijk heeft gedaan, en als er daar wat aan de knikker is kunnen wij niet eens ondersteunen ... .
Als het tegenovergestelde van pragmatisch rigide is, is een EDP auditor rigide. Maar ja, heb je'm/haar niet zelf uitgenodigd ? 


Op termijn zullen we alles uit je post hebben behandeld.
Dank.

[Johan]

Zo'n vent nodigen wij niet uit. Zo'n IT-audit is bij bedrijven van enige omvang verplichte kost wanneer een account de jaarcijfers (of hoe dat ook maar precies mag heten) opmaakt. Ben wel blij dat je er al dan niet geautomatiseerd werk van gaat maken.

[mdekraa]

Even een noot terzijde:

Wij hebben die jongens ook rondlopen (natuurlijk)
Probeer niet met argumenten altijd te winnen.

Als ze zeggen dat je iets niet goed doen, bijvoorbeeld validatie van upgrades van Heart of zo, vraag ze gewoon naar hun procedure voor het goedkeuren van Microsoft updates, omdat je dat als voorbeeld wilt gebruiken voor jouw nieuw te maken procedure. Leg meteen in het verslag vast dat je hieraan begint als de procedure binnen is.

In 9 van de 10 gevallen kunnen ze dat toch niet (als je de vragen goed stelt) en ben je er weer een jaar vanaf.
Zorg er wel voor dat niemand in Heart de Systeemmanager rechten heeft onder zijn normale "gebruikers" account, maar dat dat is vastgelegd op een separate admin account. Hetzelfde geldt voor jouw domeinadmin.

Wij hebben bv hele gevechten gehad over voorraad mutaties door productiepersoneel. In dat geval, leg goed vast dat er een mutatiebestand is en dat "gebruikers" daar geen record uit mogen verwijderen. Sommige handelingen binnen Heart zijn immers functiegerelateerd en daar kun je alleen de acties vastleggen. Maak ook voorzover mogelijk geen ge-sharede account op afdelingsniveau, maar zoveel mogelijk account op userniveau om de bovengenoemde tracebility te waarborgen.

EDP is en blijft een leuk iets. Men zal altijd een bedrijf willen benaderen als een "closed shop", want dat is voor de auditor minder werk. Maar om Peter te quoten: je moet soms pragmatisch zijn.

[Peter Stordiau]

Uitstekende reaktie, die ik ook wel had willen doen, maar waarbij e.e.a. zo erg afhankelijk is van de kreativiteit, kennis, en kunde van jou als degene die tegenover de man/vrouw zit, dat er haast geen maatstaf voor te geven is. Wat echter wel altijd geldt, is precies wat jouw voorbeeld aangeeft : leg ze een vergelijking met iets bekends voor, waarvan je op voorhand weet wat het resultaat is (en daar wordt 'ie al redelijk ondoenlijk voor 95% van "gebruikers").

In dit kader (en voor iedereen nuttig om te doorgronden) kan ik leuk verwijzen naar het Uitgebreid Beveiligings Beleid wat speciaal (en niet toevallig natuurlijk) voor Johan is gemaakt (ook leuk dat niemand dat weet, ahum, maar daar doen we nog wel een keer wat aan). Ook dit komt puur voort uit de requests van zo'n EDP figuur, en als je er eenmaal aan toegeeft, zit je er ook aan vast.
Je wilt niet weten hoeveel en hoelang wij hier intern discussies hebben gehad over de pure onzin hiervan, omdat het domweg op het verkeerde niveau wordt aangepakt, plus vooral de kennis die je EERST moet hebben van de "echte" omgevingen. En dan doel ik op een jaar of 30 terug, en de gebruikelijke "multi user" systemen van toen.
Hele discussies hebben we gehad over het "dan maar thuishoren" in het OS als je zoiets eenmaal in Profit wenst, maar, waar het al in zit. Niet dat ik wil zeggen dat je daarmee 100% kunt voldoen aan wat de EDP verlangt, maar wèl dat je daarnaar kunt verwijzen, en waar hij toch geen verstand van heeft. Heeft hij dat per abuis wel, volgende poging ...

Het punt is gewoon dat je dagen met zo'n man om de tafel zit, en je eigenlijk kontinu over lucht praat. Mij lukt het wel, en ik heb hier diverse rapportages liggen (laatste was van E&Y EDP-Audit meen ik), maar misschien ben ik ook wel de enige die dat voor elkaar krijgt (lees : zo moeilijk is het, en zo veel moet je van werkelijk àlles weten). Overigens was deze rapportage ook domweg namens een klant, die ik echter "te woord heb gestaan" (trouwens, volgens mij vergde het wel een week).

Een hele belangrijks is altijd de autorisaties op de database, waarbij het voor mij niet zo moeilijk is om te verwijzen naar de klant die dat op de juiste wijze doet (zoals eerder door mij aangegeven), met een telefoonnummer erbij. Of de EDPer dat nummer gaat draaien of niet maakt mij niet uit, ik ben er daarmee vanaf. Zeg niét dat -als het moet- e.e.a. middels een SQL/Server database kan worden opgelost, want dan mag je die overmorgen aanschaffen ...

[mdekraa]

Klopt als een bus:
2e zeg ook nooit dat je de database kunt "browsen" ....\
Dat is een lek en dus nog een dagje om de tafel

Hier spreekt ervaring   

[Peter Stordiau]

 

Nou Johan, ik heb me wild gelachen; je hebt het voor elkaar gekregen om "de man" mij te laten bellen, met precies de voorbeelden uit dit topic. Ik mag hopen dat je hebt kunnen meeluisteren.

Ik zal er niet te veel over uitwijden, maar deze meneer stelde de vragen dusdanig dat ik alleen maar hoefde te antwoorden "en dan denkt u zeker dat ik u dat ga vertellen !? tuurlijk niet, want dat màg niet eens".
Het juiste antwoord ... op de e.o.a. manier ...

 

Erg leuk was in elk geval dat ik mij -in dit geval onvoorbereid / onaangekondigd- heb geprobeerd in te beelden wat ene van Angelrooij heeft moeten bevechten, om daar maar eens op in te haken. Als het goed is sloot het aan ...
Eigenlijk jammer dat ik niet alles kan vertellen ... (gesprek duurde trouwens maar een minuut of 4).

[Wouter Rijnbende]

Op zich misschien niet zo verwonderlijk... die man denkt natuurlijk 'HEART Profit?' Wat is dat?
ff googlen...
loopt vervolgens tegen dit forum aan...
zoekt op IT-audit om te kijken of er collega's zijn die hem kunnen helpen hoe hij met dat pakket overweg moet...
tsja... en komt dan ineens dit soort topics tegen ...
pas maar op wat je er allemaal nog aan toevoegt...