Er wordt gezegd dat reizen je blik verruimt. Zo ontdekte ik laatst een nieuw fenomeen – het beveiligde toilet. In Zwitserland waren de toiletten in een restaurant beveiligd met een digitaal slot.
De deuren van zowel het dames- als het herentoilet waren voorzien van een toetsenbord; met de juiste code mocht je er in. Niet zo verwonderlijk in een periode waarin beveiliging belangrijk is en iedere restauranteigenaar zal beamen dat misbruik van toiletten een groeiend probleem is, vandaar de beveiliging met digitale sloten.
Deze nieuwe constructie gaat gepaard met nieuwe problemen. Zo is het onwenselijk dat de klant er bij de deur achter komt dat hij er niet in mag, omdat de combinatie niet bekend is. Dat leidt tot allerlei soorten klachten. De Zwitsers hebben het aangepakt door overal in het restaurant borden te plaatsen dat de ‘wc-code’ bij het personeel kan worden gevraagd. Prima natuurlijk, maar uiteraard heeft het personeel meer te doen dan steeds klanten de code vertellen, en dat is waar het systeem spaak loopt. Vanaf mijn stoel zag ik de deur van de keuken. Het eerste wat me opviel was een bord naast de deur naar de keuken met het opschrift ‘wc code 1213’. Nader onderzoek (navraag bij de ober) leerde dat de code iedere nacht wordt gewijzigd en dat voor de dames- en herentoiletten dezelfde code wordt gebruikt. Misschien om pijnlijke situaties te voorkomen waarin het personeelslid de klant moet vragen voor welk toilet de code wordt gevraagd. Wat is dan nog het nut, vraagt u zich af? Het beveiligde toilet is een zeer duidelijke schets van het probleem van de beveiligde toegang – de klanten hebben immers toegangsrechten. Net als het restaurant niet wil dat iemand van de straat zomaar het toilet in wandelt, willen bedrijven niet dat zomaar iedereen bij de informatie in hun organisatie kan. En aangezien het niet mogelijk is toegang te verlenen op basis van de identiteit, moet er een bewakingsmechanisme worden toegepast. Veel bedrijven gebruiken dan constructies als ‘Enveloppe in geval van nood’ of ‘Break Glass-accounts’. Het concept is hetzelfde – omdat het niet mogelijk is de identiteit van de gebruiker te achterhalen die gebruik maakt van het account ‘administrator’ of ‘root’, of een ander ingebed gebruikersaccount, wordt het wachtwoord beveiligd. Dit concept werkt prima op papier (en meestal is dat ook waar de wachtwoorden zich bevinden), maar in de praktijk werkt het niet. In de vergelijking met het toilet, moet het beveiligingspersoneel vergelijkbare procedures volgen. Eerst moet iemand regelmatig met de hand de wachtwoorden wijzigen. Een of twee toiletten gaat wel, maar als we het over alle toiletten in de stad hebben, wordt het vervelend. Hetzelfde geldt voor de wachtwoorden van de ingebedde accounts – iemand moet die met de hand wijzigen. Het volgende probleem is dat de mensen die de wachtwoorden wijzigen, niet zomaar overal hetzelfde wachtwoord mogen gebruiken. U snapt waar ik heen wil – als ik één toiletcode heb, heb ik ze allemaal en kan ik dus overal naar binnen – hetzelfde geldt voor wachtwoorden. U zou versteld staan over het aantal organisaties dat slechts een enkel wachtwoord gebruikt voor honderden ingebouwde accounts. Zo hebben bijvoorbeeld alle domeinaccounts hetzelfde wachtwoord, net als alle root-accounts op de Unix-servers, of alle Oracle-databaseaccounts. Nu kan dat wel een complexe code zijn waar geen hacker ter wereld ooit achter komt, maar dat betekent waarschijnlijk dat het op een briefje geschreven wordt omdat het niet te onthouden is. Dat is een risico op zich!Wellicht vraagt u zich af of die problemen nou echt zo ernstig zijn als ik ze voordoe. Zo zou iedereen die toegang nodig heeft, een eigen toegangscode kunnen krijgen. Dan moet je er wel voor zorgen dat elk toilet me als persoon herkent, en niet alleen als ‘klant’. Veel bedrijven denken dat het probleem wordt opgelost met een Identity Managementsysteem of een of ander tokengebaseerd authenticatiesysteem. Daarbij vergeten ze dat de ingebouwde beheeraccounts in systemen en toepassingen niet kunnen worden toegewezen aan personen, waardoor er geen oplossing is voor de identiteit ‘klant’, of – in de it-wereld, ‘administrator’ of ‘root’. De vraag is waarom het restaurant eigenlijk een beveiligd toilet heeft. Ze willen dat alleen klanten er in mogen, en hoe kunnen ze daar nu voor zorgen? De enige efficiënte manier is met behulp van een of andere Audit Compliant Control, anders weet je nooit zeker of het systeem effectief werkt. Wordt bijvoorbeeld de code regelmatig gewijzigd? Het kan ook een eenmalige code zijn, zodat een klant die maar één kop koffie heeft besteld, niet de hele dag van het toilet gebruik mag maken! In de bedrijfswereld stellen auditors dezelfde eisen. Ze moeten weten wie toegang heeft gehad, wanneer dat was, waarom, waar die persoon toegang toe had en hoe die toegang is verkregen. Verder moeten ze absoluut zeker weten dat het wachtwoord volgens de vastgestelde procedure is gewijzigd. Versleuteld opslaan in een spreadsheet is niet goed genoeg, tenzij u een leger aan wachtwoordbeheerders wilt inhuren. Gelukkig is er hulp voor het it-personeel. Oplossingen die ‘Audit Compliant Control for Embedded Administrative Accounts’ bieden, een generieke beschrijving die elke beveiligingsmedewerker maar al te goed snapt, en ervoor kunnen zorgen dat uw beveiliging niet met het badwater wordt weggegooid oftewel doorgespoeld. En voor wat betreft het restaurant, ik zou het bord op een andere plek hangen.
Calum M. McLeod
