Als wij betrokken worden bij een autorisatieproject, zien wij vaak een hele rij met logins die toegang hebben tot Dynamics NAV en vaak ook nog met SUPER-rechten. In dit artikel geef ik een aantal kritische overwegingen bij een aantal groepen van logins.
Wie je geen (super)rechten tot je Dynamics NAV productie-omgeving moet geven
- Ex-medewerkers of medewerkers met een nieuwe functie
Met name die laatste categorie, medewerkers met een nieuwe functie, is een risico. Deze medewerkers hebben vaak nog wel een login op het netwerk, maar hebben misschien voor hun nieuwe functie geen of wellicht andere rechten nodig binnen Dynamics NAV. Voor ex-medewerkers wordt vaak beargumenteerd dat deze geen rechten meer hebben op het netwerk en dus ook niet meer in Dynamics NAV kunnen. Dat is correct, echter wordt door deze ‘loze’ Dynamics NAV-gebruikers de controleerbaarheid van de autorisatie-inrichting bemoeilijkt en is niet uit te sluiten dat bij een serieuze poging tot hacking een dergelijk account toch weer geactiveerd wordt.
Het is dus beter om ex-medewerkers te verwijderen en voor functiewisselingen een goede procedure in te richten, zodat oude rechten in Dynamics NAV tijdig worden aangepast. - Consultants Dynamics NAV partner
Bij een gemiddelde Microsoft Dynamics NAV implementatie lopen nogal wat NAV consultants rond (al dan niet virtueel) en deze hebben allemaal rechten nodig tot uw Dynamics NAV productie omgeving (met SUPER rechten). Ik weet uit eigen ervaring dat dit je werk als consultant een stuk eenvoudiger maakt.
Geef enkel rechten tot TEST-omgeving!
Slechts bij hoge uitzondering moet (mag) een consultant gegevens wijzigen in je LIVE database. Bijvoorbeeld bij initiële inrichting/conversie, bij het ondersteunen van autorisatie inrichting of het herstellen van data ‘buiten de applicatie om’. Maar meestal kan een consultant zijn werk prima verrichten in een TEST omgeving of met alleen volledige leesrechten. (in het kader van de AVG nog steeds een risico overigens).
De praktijk is weerbarstiger maar wij adviseren om bewust met externe (consultants)toegang om te gaan:
- Enable consultantsaccounts alleen op verzoek, met opgaaf van reden en maak hiervan een log;
- Geef alleen leesrechten en bij uitzondering SUPER-rechten en neem dit op in het log;
- Zorg bij voorkeur voor named accounts i.p.v. generieke accounts (CONSULTANT 1 etc);
- Kijk bij kritische aanpassingen mee met de consultant, bijvoorbeeld via het delen van het scherm van de applicatiebeheerder.
- Systeemaccounts
Systeemaccounts worden aangemaakt om bepaalde interfaces en (externe) addons te laten ‘praten’ met Dynamics NAV. Vaak krijgen deze accounts SUPER rechten. Je weet dan zeker dat de werking van een dergelijke koppeling niet wordt verstoord door een autorisatieprobleem in Dynamics NAV. Maar elke SUPER account kan gecompromitteerd raken en gebruikt worden om zo volledige rechten te krijgen.Geef rechten in Dynamics NAV die echt nodig zijn
Het is beter om deze bovengenoemde accounts alleen die rechten in Dynamics NAV te geven die ze echt nodig hebben. Vaak is dat beperkt tot een paar tabellen. Mogelijk is hier ook nog een kostenbesparing mogelijk omdat een ‘beperkte gebruiker’ ingezet kan worden met lagere licentiekosten. Soms kan het lastig zijn om vast te stellen welke rechten nodig zijn, maar uw leverancier moet u hierbij kunnen helpen.
Goede databeveiliging begint met kritische vragen te stellen over wanneer, waarom en wie toegang nodig heeft en hiervoor procedures en maatregelen in te richten. Dat maakt het niet altijd eenvoudiger, maar wel veiliger.
