3 Beveiliging en NDS rechten

Security

7/3 Beveiliging en NDS rechten Inleiding Om een NetWare-omgeving goed te beheren, is een diepgaande kennis van de NDS nodig. In de NDS zitten namelijk alle objecten die we hebben aangemaakt om ons netwerk goed te laten functioneren. Ook de rechtenstructuur is in de NDS opgeslagen. Een effectief en efficiënt NDSrechtensysteem moet er dan ook voor zorgen dat alleen degenen die daarvoor gemachtigd zijn, toegang hebben, op het juiste moment, tot de resources waarvoor ze zijn geautoriseerd. Af en toe blijkt dat, vanwege het gemak, gewoon iedereen álle rechten op álle objecten heeft gekregen. Uit oogpunt van beveiliging en integriteit van de beveiliging van gegevens is dit natuurlijk absoluut niet wenselijk. Vaak komt men daar pas achter als het al te laat is – als bijvoorbeeld data na het aansluiten van een internetverbinding voor de hele wereld toegankelijk is, met alle mogelijke gevolgen van dien.

Geschikt voor alle bedrijven

Introductie tot NDS-security NDS zorgt door middel van een hiërarchische boomstructuur voor een beveiligingsconcept dat zowel bij een multinational als een klein bedrijf kan worden ingezet. Het principe is voor beide identiek, de schaal waarop een en ander wordt uitgevoerd, verschilt uiteraard wel. De NDS is zowel lokaal als wereldwijd te beheren met behulp van NWAdmin, Console One of het recente iMonitor. Het maakt daarbij niet uit op welke plaats iemand zit of wat iemand doet; er

Novell Netwerkoplossingen, aanvulling 3

7/3-1

Beveiliging en NDS rechten

is een ingang tot het verstrekken van rechten op resources en dat is de NDS. Drie soorten objecten

Als we nu kijken naar de NDS, dan hebben we drie soorten objecten die we kunnen tegenkomen, te weten: • [Root]: De root van de NDS is het hoogste punt in een NDS-omgeving en hier begint dan ook onze tree. In de root kunnen slechts een beperkt aantal objecten voorkomen, namelijk de Organization-container, de Country-container, en een beperkt aantal andere objecten. • Container-objecten: Dit zijn objecten waarin óf andere containerobjecten voorkomen óf leaf-objecten. Ze worden gebruikt om een tree overzichtelijk in kleinere stukjes in te delen en ervoor te zorgen dat een tree een afspiegeling is van de organisatie waarvoor de NDS-tree wordt ingezet • Leaf-objecten: Dit zijn de feitelijke netwerkresources in onze omgeving. Denk daarbij aan printers, users, applicaties, routers enzovoort. Grafisch ziet dit er als volgt uit:

7/3-2


Security

We zien de [Root], de containers weka, amsterdam, rotterdam, administratie, verkoop en beheer en de leaf-objecten John, Carla en hplaser4.

Zeeffunctie

Hieruit volgt dat we de beveiliging kunnen aanbrengen op de drie bovengenoemde objecten, waarbij geldt dat er sprake is van een soort van zeeffunctie. Dit houdt in een top-downbenadering: maatregelen aangebracht op het root-object beïnvloeden de hele tree, maatregelen aangebracht op een container beïnvloeden de objecten of containers die daar aanwezig zijn en ten slotte maatregelen op het leaf-object beïnvloeden alleen het object waarover het gaat. Uit bovenstaande volgt dan weer dat een goed ontwerp van de NDS voor uw organisatie het proces van beveiliging en het uitdelen van rechten wezenlijk kan beïnvloeden. Het is belangrijk om dit in het achterhoofd te houden bij het ontwerpen van uw NDS. Trustees Beveiliging in de NDS-tree wordt verkregen door het uitdelen van rechten aan een leaf-object op een ander object in de tree. Op het moment dat een leaf-object rechten heeft gekregen op een andere object, noemen we dat in NDS-termen dat het een trustee is van dat object waarop het rechten heeft. Een leaf-object moet een trustee zijn om gebruik te kunnen maken van netwerkresources. Op het moment dat een leaf-object nergens trustee van is, is het niet in staat om ook maar iets uit te voeren. Een voorbeeld verheldert een en ander:


7/3-3


Een userobject is een leaf-object binnen een NDS-tree, een printer is eveneens een leaf-object binnen de tree. Wil het userobject nu kunnen printen, dan moet het rechten hebben op het printerobject en derhalve trustee zijn van het printerobject. Een leaf-object kan ook rechten op zichzelf hebben; dit maakt het bijvoorbeeld een userobject mogelijk om zijn password te veranderen. Door het hiërarchische model van Novell is het mogelijk om verschillende leaf-objecten (meestal userobjecten) verantwoordelijk te maken voor verschillende containers en op deze wijze de verantwoordelijkheden te decentraliseren. Let hierbij wel op het op de juiste wijze uitdelen van rechten, omdat het voor deze decentrale leaf-objecten mogelijk is om de container af te sluiten voor toegang van boven. Objectrechten De objectrechten zijn de basisrechten die kunnen worden uitgedeeld aan leaf-objecten. Er zijn de volgende objectrechten: Recht

Afkorting

Functie

Supervisor

S

Browse

B

Het supervisor-recht is het hoogste recht dat er is. Alle objectrechten zijn hierin vertegenwoordigd. Ook de rechten op het filesysteem van een server is erbij inbegrepen (mits er S-rechten zijn op het server-object). Het S-recht houdt in dat er recht is op alle property’s van een object. Het recht om door de tree heen te browsen (wandelen).

7/3-4


Security

Recht

Afkorting

Functie

Create Delete Rename Inheritable

C D R I

Het recht om objecten aan te maken in een tree. Het recht om objecten uit een tree te verwijderen. Het recht om objecten te herbenoemen in een tree. Dit recht geeft aan of een recht ook geldig is voor lager in een tree gelegen objecten. Het komt dan ook alleen voor bij het root-object en bij containers. Property-rechten Behalve objectrechten kennen we ook nog property-rechten. Property’s zijn de eigenschappen die we bij een object kunnen invullen; bij een userobject zijn dit bijvoorbeeld naam, adres, telefoonnummer, loginscript enzovoort. Een voorbeeld. We zien dan een aantal van de genoemde property’s door te klikken op details van een userobject.


7/3-5


Voordat een object iets kan doen met een property, moet het daar wel rechten op hebben. We kennen de volgende property-rechten: Recht

Afkorting

Functie

Supervisor Compare

S C

Read

R

Write

W

Add Self

A

Geeft alle rechten op een property. Geeft het recht om een vergelijking uit te voeren die een true of false oplevert. Zorgt ervoor dat de waarde van de property kan worden gelezen. In de Read-rechten zijn de Compare-rechten inbegrepen. Met het Write-recht is het mogelijk om de waarde van een property aan te passen. Dit impliceert eveneens het verwijderen of toevoegen van de waarde van de property waarop men het W-recht heeft. Als men dit recht heeft, dan kan de trustee zichzelf toevoegen of verwijderen als een waarde van een property. Bij de A-rechten zijn de W-rechten inbegrepen. Let op:

Standaard krijgen NDS-objecten niet alle rechten op bijbehorende property’s.

Standaard NDS-rechten Bij de eerste installatie van NDS op de eerste server in de tree, worden er standaard objecten property-rechten uitgedeeld. Normaal gesproken zijn deze rechten voldoende om ervoor te zorgen dat users gebruik kunnen maken van de netwerkresources. Deze rechten hoeven niet direct aan het userobject toegekend te zijn, maar kunnen ook via andere objecten toegekend zijn. Als de userobjecten hieraan aangekoppeld zijn kunnen zij dezelfde rechten ‘erven’.

7/3-6


Security

De standaardrechten kunnen ook worden beïnvloed als er een NDS-aware-applicatie wordt/is geïnstalleerd, zoals bijvoorbeeld ZENworks. Dit soort NDS-aware-achtige applicatie kan bepaalde rechten nodig hebben om goed te kunnen functioneren; vaak gaat het dan om een nieuw soort property of object. [Public] Trustee De [Public] trustee is geen object in de NDS-tree. Het is een speciale rechtenconstructie, die toegankelijk is voor alle gebruikers, of ze nu wel of niet zijn ingelogd. Standaard is iedere gebruiker security-equivalent aan het [Public]-object. Rechten die aan het [Public]-object worden toegekend, hebben dan ook een grote impact op de beveiliging omdat ze voor iedereen gelden, ongeacht dus of iemand nu wel of niet is ingelogd. Het [Public]-object staat niet in de NDS en is dus niet op de standaardwijze benaderbaar. De manier om rechten toe te wijzen gebeurt dan ook heel expliciet. Binnen NWAdmin klikt u met de rechtermuisknop op het object waarop u [Public]-rechten wilt toedelen en vervolgens gaat u naar de trustee van dit object. Hier kunt u dan via Add Trustee de [Public]-trustee toevoegen. U ziet vervolgens het [Public]-object verschijnen als trustee. Dit kunt u op deze wijze voor zowel object- als property-rechten doen. In NWAdmin ziet u het volgende scherm na het toevoegen van [Public] aan een object.


7/3-7


Standaard-objectrechten Het [Public]-object heeft standaard Browse-objectrechten op het [Root]-object. Hierdoor zijn gebruikers in staat om objecten in de tree te zien, voor- en nadat ze zijn ingelogd en kunnen ze direct naar de juiste context gaan. Als het browse-objectrecht wordt uitgezet, kunnen gebruikers standaard bijvoorbeeld niet meer naar de juiste context gaan en ondervinden ze wellicht hinder bij het inloggen. Wees dus voorzichtig met veranderingen aan deze standaardinstellingen. De [Root] heeft standaard Browse- en Inheritable-objectrechten op alle NDPS- en niet-NDPS-printers, print-queues en printserver-objecten, zodat er kan worden geprint. Bij de aanmaak van een userobject krijgt het standaard Browse-rechten op zichzelf, zodat de user in staat is zichzelf in de NDS-tree te zien.

7/3-8


Security

Standaard-propertyrechten Standaard krijgt de [Public]-trustee Read-rechten op elk userobject en de standaard (default) Server property- en Read-rechten op elk NetWare-serverobject met Network Address property. Hierdoor is het mogelijk om gedurende het loginproces de default-servernaam te achterhalen en vervolgens deze server door middel van het netwerkadres te traceren. [Root] heeft standaard Read-propertyrechten op elk userobject met Group Membership property en op elk userobject met Network Address property. Verder heeft [Root] ook Read-propertyrechten op elke groepobject met Members property. Hierdoor kunnen groepsleden worden gevonden op het netwerk. Containerobjecten krijgen standaard Read-propertyrechten op hun eigen loginscript-property. Hierdoor hebben userobjecten dit recht ook automatisch en kan het loginscript worden uitgevoerd als er wordt ingelogd. Verder krijgen Container-objecten Read-propertyrechten op het Print Job Configuration-property, waarmee een gebruiker de printerconfiguratie kan aanpassen als dat nodig is. Nieuwe userobjecten krijgen standaard de volgende propertyrechten, waardoor ze in staat zijn om hun eigen property’s te lezen en hun eigen loginscript en printerconfiguratie aan te passen: • Read-propertyrechten op alle bij de user horende eigen property’s. • Read- en Write-propertyrechten op het user-eigen loginscript-property. • Read- en Write-propertyrechten op het eigen Print Job Configuration-property.


7/3-9


Twee soorten rechten

NDS-rechten-inheritance ‘Inheritance’ (te vertalen als het Nederlandse begrip ‘erven’) is het systeem binnen de NDS waarmee de NDS rechten (object-, property- en file-systeemrechten) doorgeeft van het ene object naar het andere object. Binnen een NDS-tree worden verstrekte rechten neerwaarts doorgegeven, dat wil zeggen dat objecten (of containers) lager in de tree de rechten erven die zijn uitgedeeld op objecten hogerop in de tree, met als top het [Root]-object. In een NDS-omgeving praten we derhalve over twee soorten rechten, namelijk een • Explicit right, dat wil zeggen een recht dat expliciet aan een object is uitgedeeld, of een • Inherited right, waarbij het recht is verkregen door vererving van het recht van een hoger in de tree gelegen object. Security-equivalentie Dit is een volledig ander begrip dan de hierboven behandelde inheritance-rechten. In beide gevallen worden rechten van het ene object naar het andere object doorgegeven, maar in het geval van security-equivalentie wordt een rechtstreekse koppeling gemaakt naar de explicit rights die aan dat object zijn gekoppeld. Mocht het object waaraan men security-equivalent is, inherited rechten hebben, dan worden deze niet doorgegeven aan een security-equivalent object. Standaard zijn userobjecten security-equivalent aan de groep objecten waarvan ze lid zijn. Blokkeren van inherited rights Zoals we eerder hebben gezien, kunnen objecten lager in de tree rechten erven van hoger in de tree gelegen objecten. Dit is echter een situatie die we niet altijd willen heb-

7/3-10


Security

IRF

ben – het kan zijn dat we niet willen dat deze rechten de tree verder invloeien c.q. dat we niet willen dat het verder dan een bepaald punt de NDS invloeit. Binnen een NDS-omgeving kunnen we dit oplossen door gebruik te maken van een Inherited Rights Filter (IRF). We kunnen een IRF activeren door middel van het trusteescherm. We vinden dit scherm door met de rechtermuisknop op een object te klikken en vervolgens naar het scherm ‘Trustees of this object’ te gaan. We krijgen dan het volgende scherm te zien:

We zien linksonder in de hoek de optie ‘Inherited Rights Filter’. Met dit filter zijn we in staat om elk inherited recht te blokkeren. We zijn echter niet in staat om hiermee expliciet uitgedeelde rechten of rechten verworven middels security-equivalentie te blokkeren.


7/3-11


Met behulp van het volgende scherm

kunnen we de rechten blokkeren voor inheritance. Op het moment dat er geen vinkje staat bij een recht, wordt het recht uitgefilterd en dus niet meer doorgegeven. Het filteren kan voor zowel object- als property-rechten. Het is wel verstandig om goed op te letten als IRF’s worden ingevoerd. In het geval dat men bijvoorbeeld lokale containerbeheerders wil aanmaken die als enige S-rechten hebben op de containers, en vervolgens een IRF aanmaakt waarin het S-recht wordt uitgefilterd, heeft dit als consequentie dat de lokale beheerder nog wel S-rechten heeft – deze zijn immers expliciet toegekend –, maar dat de beheerders hoger in de tree geen S-rechten meer hebben op de container en daarin verwerkte objecten. Als men echter wil dat de centrale beheerders ook S-rechten hebben op deze container, zullen deze dus expliciet moeten worden toegekend. Effectieve rechten We hebben inmiddels een aantal onderwerpen over rechten behandeld en gezien welke mogelijkheden er allemaal zijn

7/3-12


Security

om de rechtenstructuur te beïnvloeden. Uiteindelijk gaat het er in de praktijk vaak om wat nu eigenlijk de effectieve rechten zijn die een NDS-object heeft.

Stappenplan

Afgaande op het voorgaande kunnen we nu stellen dat er een vierstappenplan is om dit te bepalen: 1. Bepaal de inherited rechten. 2. Haal hier de weggefilterde rechten (middels IRF) vanaf. 3. Voeg toe de rechten die expliciet zijn toegekend aan een object. 4. Voeg ten slotte de rechten toe die via security-equivalentie zijn toegekend. En dit alles bij elkaar geeft dan de effectieve rechten die een object heeft.

Vuistregels

Richtlijnen voor de beveiliging in een NDS-omgeving Om te komen tot een basisbeveiliging waarbij alleen daarvoor geautoriseerde objecten de gespecificeerde netwerkresources kunnen gebruiken, is er een aantal vuistregels: • Iedereen is er inmiddels van op de hoogte dat de standaard aangemaakte Admin-user de meeste rechten heeft in een NDS-omgeving. Vanuit beveiligingsoogpunt verdient het de voorkeur om een (of meerdere) nieuwe Admin-users aan te maken met een andere (niet makkelijk terug te leiden) naam. Na het creëren hiervan kan de Admin-user gedisabled worden. • Maak gebruik van groepen, containers of Organizational Role-objecten om expliciete rechten toe te kennen. Het wordt op deze makkelijker en voral overzichtelijker welke rechten aan wie zijn toegekend.


7/3-13


•

• •

•

7/3-14

Het gebruik van security-equivalentie wordt afgeraden omdat het lastig is te traceren wie waarvan security-equivalent is. Ken niet meer rechten toe dan nodig is. Omdat de rechten middels inheritance naar beneden doorvloeien in een tree, is het verstandig om de rechten boven in de tree ([Root]) zo gering mogelijk te houden, om te voorkomen dat er veel rechten door inheritance beschikbaar zijn. Hierdoor hoeven ook minder IRF’s te worden aangemaakt. Geef zo min mogelijk rechten aan het [Public]object, omdat iedereen deze rechten heeft, of men nu ingelogd is of niet.


3 Beveiliging en NDS rechten

Recommend Documents