Toegangsbeheer, van vloek naar zegen

NACHTBLAD#003 [14/07/24]

De spion

Heb je je ooit voorgesteld dat je een spion bent, mensen beïnvloedt, hun gedachten ten goede verandert, of net niet? De opwinding van subtiele overtuiging, de uitdaging van het veranderen van perspectieven – het is een aanlokkelijke fantasie.

Laat me mezelf voorstellen, mijn naam is Yentl en ik beschouw mezelf een generalist in informatiebeveiliging. Mijn brede set van vaardigheden stelt me in staat om binnen een organisatie verschillende rollen en verantwoordelijkheden te vervullen.

Stel je een kennisdelingssessie met ontwikkelaars voor. Daar zit ik dan, de beruchte “security guy” met al zijn strenge eisen, te midden van zijn zogenaamde “slachtoffers” – de ontwikkelaars.

In de technologiewereld worden professionelen op het gebied van informatiebeveiliging vaak gezien als de boodschappers van slecht nieuws, diegenen die barrières opwerpen en het creatieve proces aan banden leggen. Maar er is een andere kant aan het verhaal. In deze sessie was ik er niet om te hinderen, maar om te leren en samen te werken. Ik had geen idee dat deze ontmoeting diepere inzichten zou opleveren aangaande de uitdagingen waarmee ontwikkelaars worden geconfronteerd en het delicate evenwicht tussen informatiebeveiliging en gebruiksvriendelijkheid.

Toegang geweigerd

Tijdens de sessie toonden de ontwikkelaars het nieuwe opslagsysteem voor broncode; gitlab met nieuwe CI/CD-functies. Ze besloten de opslagplaats te delen zodat we deze functies en de code die dit mogelijk maakt konden observeren. Het was een pareltje! Maar toen ik probeerde toegang te krijgen tot dit meesterwerk, werd ik geconfronteerd met de boodschap “TOEGANG GEWEIGERD”. Ik kon de presentatie zien, maar ik kon de code zelf niet bekijken. Dit was teleurstellend. Ik wilde deze functies en code gebruiken in mijn projecten, maar dat kon niet. Ik was niet de enige; de chat werd overspoeld met soortgelijke klachten: “Ik kan er niet bij”, “Waarom kunnen we er niet bij?”.

Frustratie

De applicatiebeheerders grepen snel in en legden uit hoe toegang kon worden aangevraagd via het identiteits- en toegangsbeheersysteem (kortweg ITB systeem). Echter, de ontwikkelaars waren allesbehalve gecharmeerd: “Dit is een slechte gebruikerservaring”, “Waarom moeten we toegang aanvragen?”, “Hoe kan ik weten wat ik moet aanvragen?” Ik voelde hun frustratie en begon antwoorden te formuleren, maar ik was niet snel genoeg. Al snel volgde een stroom aan negatieve opmerkingen over informatiebeveiliging: “Het is waarschijnlijk omdat het securityteam ons niet vertrouwt; ze denken dat we per ongeluk inloggegevens in onze code zullen zetten“.

Analyse van de situatie

Op dit punt moest ik een stap terugzetten om de frustraties en problemen van de ontwikkelaars beter te begrijpen.

Informatiedeling

Ontwikkelaars bouwen constant oplossingen voor problemen. Wanneer ze horen dat iemand in de organisatie een probleem op een interessante manier heeft opgelost, willen ze begrijpen hoe die oplossing tot stand is gekomen.

In plaats van alle broncode met elke ontwikkelaar te delen, zou het nuttig zijn om een centrale opslagplaats te hebben met goed gedocumenteerde oplossingen voor veelvoorkomende problemen. Zo hoeft niet elke ontwikkelaar toegang te hebben tot alle broncode maar enkel tot de gedeelde opslag plaats, waar alle veel voorkomende problemen gedocumenteerd kunnen worden en gevoelige code verwijderd kan worden voor deze beschikbaar te maken.

Beperkte toegang

Waarom kan niet elke ontwikkelaar toegang krijgen tot alle code? Omdat iemand per ongeluk inloggegevens in de code kan zetten bijvoorbeeld. Dit soort ongelukken gebeuren, maar het beperken van toegang voorkomt deze niet, het kan enkel de mogelijke impact verminderen.

De belangrijkste motivaties voor het beperken van de toegang tot broncode zijn:

• Het principe van de minimale rechten: alleen toegang geven tot wat nodig is, minimaliseer de mogelijke impact als één account wordt gehackt, wat altijd tot de mogelijkheden behoort, “assume breach” wordt wel eens gezegd hierover.
• Intellectueel eigendom: broncode kan beschouwd worden als intellectueel eigendom van een organisatie. De producteigenaar is verantwoordelijk voor deze eigendom en zou degene moeten zijn die de toegang goedkeurt of weigert.
  *Het vierogenprincipe moet van toepassing zijn, waarbij de manager van de aanvrager en de eigenaar van het recht de toegangsaanvraag goedkeuren.

Weten wat aan te vragen

Hoe kan een ontwikkelaar weten welke rechten hij moet aanvragen?

Het begint allemaal met een goed ontwerp van de integratie tussen de applicatie en het ITB systeem. Het ITB team en de applicatiebeheerder moeten gezamenlijk ervoor zorgen dat de medewerkers gemakkelijk de juiste rechten kunnen identificeren en aanvragen.

Een ITB systeem beheert de levenscyclus van identiteiten (bijvoorbeeld werknemers, gebaseerd op het HR-systeem) en hun rechten (gebaseerd op de aanvraagcatalogus in het systeem zelf). Het heeft als doel om zoveel als mogelijk de verschillende stromen van een identiteit bij het toetreden, verplaatsen en verlaten te automatiseren.

De mogelijkheid om de juiste toestemmingen/rechten te vinden en te krijgen, is iets dat lastiger is dan je zou verwachten. Begin best met een duidelijke en consistente naamgeving.

Doorheen de hele organisatie heeft het ITB team bepaalt om de volgende structuur te volgen:

<Applicatie> - <Recht>

Naast het hebben van een duidelijke naamgevingsconventie, moet elk recht gecategoriseerd of getagged zijn en een duidelijke beschrijving krijgen.

Geavanceerde ITB systemen stellen je in staat om de aanvraagcatalogus te beperken op basis van gebruikersattributen zoals “functie” of “afdeling”. Op deze manier kunnen medewerkers enkel rechten zien die voor hen relevant zijn. In deze specifieke case hebben we deze optimalisatie niet geïmplementeerd omdat deze buiten het doel van de integratie tussen het ITB systeem & applicatie viel en een apart traject vereist voor een succesvolle implementatie.

Op dezelfde manier kunnen we rollen configureren: dit zijn verzamelingen van rechten die we automatisch kunnen toewijzen op basis van gebruikersattributen, deze zijn vooral nuttig om de organisatiestructuur te modelleren. We hebben de teammanagers geadviseerd om dergelijke rollen te creëren voor hun team.

Laten we eens kijken naar de “eenvoudigste oplossing”, de naamgeving van rechten en hoe we deze kunnen toepassen om het leven van de ontwikkelaars gemakkelijker te maken. In ons geval met het opslagsysteem voor broncode:

De applicatiebeheerder legde ons uit dat er Groepen, Subgroepen en Opslagplaatsen zijn, elk met hun toegangsrechten zoals Guest, Reporter, Developer, Maintainer, en Owner.

Bij het openen van zo een opslagplaats verschijnt er in de URL hetvolgende:

• https://GitLab/MyGroup/MySubGroup/MyRepository
• https://GitLab/MyGroup/MySubGroup/MySubGroup/MyRepository

De volgende afspraken werden gemaakt met de applicatiebeheerder:

• Het ITB team beheert de eerste Subgroep.
• De rechten worden als volgt genoemd: Gitlab – <Subgroep> – <Permissie>.

Een verbetering die vaak over het hoofd gezien wordt, hoewel het meer onderhoud vereist van de applicatie beheerder, is het definiëren van duidelijke beschrijvingen voor elk recht. Bijvoorbeeld, wat houdt “GitLab – <Subgroup> – Guest”” in?

Om de zoekbaarheid te verbeteren, kan de URL aan de beschrijving worden toegevoegd. In de meeste ITB systemen is de beschrijving doorzoekbaar waardoor de medewerker de gewenste rechten kan vinden door de URL te kopiëren en te plakken wanneer hij “TOEGANG GEWEIGERD” ziet. Dit is een slimme manier om het aanvraagproces van toegang te stroomlijnen en de frustratie bij medewerkers te verminderen.

Voorbeeld

Het ITB team beheert een cloud product genaamd SailPoint. Ze hebben ook enkele componenten geïmplementeerd op een cloud hosting platform van AWS. Hun broncode opslagstructuur kan er zo uitzien:

• https://GitLab/ITB/SailPoint/AWS/InfraAsCode
• https://GitLab/ITB/SailPoint/AWS/SharedInfra
• https://GitLab/ITB/SailPoint/HR-APP

Wat we hier zien is hetvolgende:

• ITB: een groep 
• SailPoint: een subgroep 
• AWS: een subgroep 
• InfraAsCode : opslagplaats van code 
• SharedInfra : opslagplaats van code 
• HR-APP: opslagplaats van code

De rechten die door het ITB systeem zijn aangemaakt:

• GitLab – SailPoint – Guest 
• GitLab – SailPoint – Reporter 
• GitLab – SailPoint – Developer 
• GitLab – SailPoint – Maintainer 
• GitLab – SailPoint – Owner

Met de bovenstaande rechten in het ITB systeem kunnen de ontwikkelaars nu zelf eenvoudig toegang aanvragen of we kunnen de noodzakelijke toegangsrechten automatisch toewijzen via rollen waar gewenst.

Balans tussen informatiebeveiliging en gebruikerservaring

De beslissing over hoe veilig een systeem moet zijn, moet niet enkel worden bepaald door het informatiebeveiligingsteam, maar door de organisatie – dezelfde organisatie waarvoor ontwikkelaars functies bouwen. Informatiebeveiliging, wanneer adequaat toegepast, is een business enabler in plaats van een business blocker. Een goed ontworpen identiteitsbeheersysteem kan het voor ontwikkelaars en de organisatie gemakkelijker maken om te opereren zonder de informatiebeveiliging in gevaar te brengen of frustratie bij medewerkers te veroorzaken.

Ter afronding

Terwijl ik de wereld van ontwikkelaars verkende, realiseerde ik me dat mijn rol niet alleen ging over het handhaven van maatregelen ter bevordering van de informatiebeveiliging, maar ook over het begrijpen en aanpakken van de uitdagingen waarmee de partij aan de andere kant van de tafel, de ontwikkelaars, wordt geconfronteerd.

De kennisdelingssessie was een venster op de wereld van ontwikkelaars. Het was pas toen dat ik hun frustraties echt begreep. De “TOEGANG GEWEIGERD” melding was niet zomaar een systeemmelding, maar een symbool van de kloof tussen informatiebeveiligingsmaatregelen en de behoeften van ontwikkelaars.

Door nauw samen te werken met de ontwikkelaars en de applicatiebeheerder, konden we deze problemen aanpakken. We creëerden een centrale opslagplaats voor het delen van goed gedocumenteerde oplossingen waar iedereen toegang op heeft, implementeerden een duidelijke en consistente naamgevingsconventie en ontwierpen een effectieve integratie met het ITB systeem. Deze maatregelen verlichtten niet alleen de frustraties van de ontwikkelaars, maar bevorderden ook een cultuur van samenwerking en wederzijds respect.

Mijn reis als ‘spion’ in de wereld van de technologie heeft me geleerd dat de sleutel tot effectieve informatiebeveiliging niet enkel ligt in het opleggen van beperkingen, maar in het bevorderen van begrip, samenwerking en wederzijds respect. Het gaat om het vinden van een evenwicht tussen informatiebeveiliging en gebruiksvriendelijkheid, en het allerbelangrijkste, het gaat om het veranderen van perspectieven, niet alleen van anderen, maar ook van mezelf.

De Auteur

---