Autorisatie en beveiliging in System 10

Met de komst van Sybase System 10 is er ook. het een en ander veranderd op het gebied van autorisatie en beveiliging.

Naast een aantal uitbreidingen, zoals het hanteren van nieuwe soorten system administration-rollen en de mogelijkheden tot het uitvoeren van audit-trails zijn er ook wat oneffenheden glad gestreken. Daarnaast is er ander lid aan de System 10-familie toegevoegd ten behoeve van systemen met zwaardere beveiligingseisen, namelijk de Sybase Secure SQL Server.

In de voorafgaande versies van Sybase System 10 zaten een aantal onhebbelijkheden die nu zijn aangepast. Zo was het mogelijk om een gebruikersnaam en een wachtwoord van het netwerk te vangen als men de juiste middelen had. Dit behoort nu tot het verleden met de optie Net Password Encryption op TRUE. Dit gebeurt met het commando Sp-serveroption, hetgeen alleen door de System Security Officer - deze rol wordt verderop behandeld - uitgevoerd kan worden. Delault staat namelijk deze optie op FALSE. Zodra deze optie aanstaat en iemand probeert in te loggen, dan wordt eerst zijn gebruikers naam naar de server gestuurd zonder wachtwoord. Hiermee wordt aangegeven dat encryptie noodzakelijk is. Hierop antwoordt de server met een sleutel die gehanteerd moet worden om het Wachtwoord te encrypten. Zodra dit is gebeurd wordt het wachtwoord versleuteld over het netwerk naar de server gestuurd die op zijn beurt de geldigheid controleert. Het was ook mogelijk om de wachtwoorden te lezen in de Syslogins-tabel. In System 10 worden deze versleuteld opgeslagen.

Enkele andere aanpassingen zijn dat nieuwe wachtwoorden minimaal zes karakters lang moeten zijn en 'NULL: wachtwoorden niet meer zijn toegestaan (behalve bij installatie, dan is het SA-wachtwoord NULL). Bij deze versie is het ook mogelijk een vervaldatum op een wachtwoord te zetten. Dit gebeurt met het commando Sp-configure en de optie Password Expiration Level. Zodra het wachtwoord verlopen is, kan men alleen nog inloggen om het wachtwoord te wijzigen.

Ook is het mogelijk een om een gebruiker te Iocken' (zonder hem te verwijderen), waarmee hem tijdelijk de toegang ontzegd kan worden.

System Administration-rollen

In voorafgaande versies van SQL Server 10 was er maar een System. Administration-rol, namelijk de SA. Daarnaast was er nog een speciale rol weggelegd voor de Database Owner (DBO).

De DBO heeft een ook een aantal activiteiten die door de SA uitgevoerd mogen of kunnen worden. Het verschil is dat de taken van de DBO zich beperken tot de database waarvan hij de eigenaar is. Hieraan zijn in System 10 de volgende twee nieuwe rollen toegevoegd: de System Security Officer (SSO) en de Operator (OPER). De taken binnen deze rollen zijn nu als volgt verdeeld. De SA zorgt voor het beheren van diskruimte, aanmaken van databases, het uitvoeren van diagnostische activiteiten en herstellen van indexen. De SSO verzorgt de beveiligingstaken zoals het aanmaken van login accounts, het wijzigen van wachtwoorden met bijbehorende vervaldatum en het beheren van de audit faciliteiten. De OPER zorgt voor het maken van backups en het verzorgen van recoveries, mocht dit noodzakelijk zijn. Al deze tollen kunnen, in tegenstelling tot voorafgaande versies, toegekend worden aan de verschillende login accounts. Hierdoor is het ook mogelijk meerdere gebruikers dezelfde rol toe te kennen.

Auditing

Met deze optie is het mogelijk om een groot aantal activiteiten die op de database plaatsvinden te volgen: wie doet wat, waar en wanneer. Deze activiteiten worden opgeslagen in een aparte database, Sybsecurity genaamd. Hierin bevinden zich twee extra tabellen. De Sysaudits, voor de audit-trails en Sysauditoptions voor het zetten van een aantal optie-mogelijkheden. Met behulp van een groot aantal toegevoegde stored procedures is het mogelijk om de meest uiteenlopende opties te zetten.

Wat kan er nu zoal gevolgd worden aan activiteiten? Men moet denken aan acties - zoals toevoegen, verwijderen, wijzigen en selecteren - op objecten in de database, het uitvoeren van triggers en stored procedures, het aan- /uitloggen van gebruikers, opgetreden errors en het volgen van de door de gebruikers specifiek gedefinieerde acties.

Secure SQL Server

De standaard SQL Server 10 biedt het C2- beveiligingsniveau. De Secure SQL Server gaat een stapje verder en biedt het beveiligingsniveau Bl, hetgeen een groot aantal andere relationele database-leveranciers nog niet kan waarmaken. Dit zijn eisen die door de NCSC (National Computer Security Center) zij opgesteld. Het Orange Book oftewel Trusted Computer Systems Evaluation Criteria (TCSEC) verdeelt de beveiligingseisen in vier niveaus, D tot en met A.

Niveau D is het laagste niveau en wordt aangeduid als 'Minima Predikten', hierbij hoeft men geen structurele maatregelen ten behoeve van beveiliging te treffen. Niveau C, aangeduid als 'Discretionary Predikten' wordt ook vaak aangeduid als DAC, Discretionary Access Control. Hierbij dient de eigenaar van de gegevens te bepalen wie en in welke mate andere toegang hebben tot zijn gegevens. De meeste rdbms- leveranciers zitten op dit niveau van beveiliging. Het op één na hoogste niveau B heet 'Structured Predikten'. Deze wordt vaak aangeven door de afkorting MAC ofwel Mandatory Access Cofitrol. Hierin worden gegevens geclassificeerd, Deze classificatie kan lopen van unclassified via confidentieel, secret tot aan top secret, Aan subniveau's van B worden aanvullende eisen gesteld. Het laatste en tevens hoogste niveau A wordt 'Verified Predikten' genoemd. Dit niveau is gelijkwaardig met niveau B3, alleen hierbij moet het gehele beveiligingssysteern formeel zijn gedocumenteerd. Een andere eis hierbij is dat het bewezen moet zijn dat aan de gestelde beveiligingseisen wordt voldaan.

Tot besluit

Dit korte artikel geeft een goed beeld van wat Sybase in zijn System 10 aan autorisatie en beveiliging te bieden en gewijzigd heeft ten opzichte van voorafgaande versies. Dit naast de al eerder bestaande mogelijkheden van beveiliging zoals; ANSI standaard grant/revoke, views, triggers, stored procedures, user groups en users.

Als laatste nog een aantal tips, zorg ervoor dat zodra de Sybase-installatie achter de rug is het wachtwoord van de SA gewijzigd wordt. Dit omdat een ieder die ooit met Sybase gewerkt heeft weet dat het default-wachtwoord van de SA een NULL-waarde heeft. Men zal versteld staan hoeveel organisaties dit gewoon als default blijven 'hanteren, met alle eventuele gevolgen vandien, Tijdens het ontwikkelen gelden in het algemeen geen zware autorisatie-eisen. Daarom is het handig tijdens het ontwikkelen, bouwen en testen van een database alle betrokkenen een alias te geven naar de DBO (DataBase Owner). Denk er wel aan dat, voor het in productie nemen, de juiste autorisatie/beveiligingsstructuur aan te brengen en te testen, Hierdoor komen alle aangemaakte objecten direct ter beschikking aan het gehele team. Daarnaast is het handig dat alle objecten door een gebruiker worden beheerd. Hierdoor hoeven er ook minder controles uitgevoerd te worden ten behoeve van de autorisatie/privileges, hetgeen weer ten goede komt aan de performance.

Zodra in een systeem aan zware eisen op het gebied van beveiliging/autorisatie voldaan moet worden, is het verstandig in een zo vroeg mogelijk stadium met een beveiliging/autorisatie-plan van start te gaan. Hierin wordt aangegeven hoe men de gewenste beveiliging wil bereiken en uitvoeren. Een hulpmiddel hierbij is een autorisatiematrix die aangeeft welke soorten gebruikers welke acties op welke objecten mag uitvoeren. Als men dit achteraf wil verwezenlijken kan men in grote problemen komen met de implementatie ervan.

F.G.M. van Laerhoven is medewerker van de technische staf BSO/Breda B.V. en heeft ervaring met het realiseren en invoeren van diverse soorten systemen in administratieve en industriële autormtisering.