Externe professionals aan een PHP-team toevoegen betekent niet dat je hun dezelfde inloggegevens moet geven als interne medewerkers gebruiken. De juiste toegang hangt af van de taak: code schrijven, een fout reproduceren, metrics bekijken of een deployment uitvoeren zijn verschillende activiteiten waarvoor niet noodzakelijk dezelfde systemen of rechten nodig zijn.
Effectief toegangsbeheer voor externe developers combineert een beperkte scope, individuele identiteiten, termijnen die opnieuw kunnen worden beoordeeld en aangewezen interne verantwoordelijken. Het doel is niet om het werk te belemmeren, maar om de blootstelling te beperken en een praktische vraag helder te kunnen beantwoorden: wie kan wat doen, in welk systeem en gedurende welke periode?
Ontwikkeling, tests, deployment en onderzoek scheiden
Deel de activiteiten waarvoor toegang wordt aangevraagd in voordat je accounts aanmaakt. Voor het ontwikkelen van een PHP-functie kunnen de repository, technische documentatie en een lokale omgeving met testgegevens volstaan. Om wijzigingen te verifiëren kan een integratie- of preproductieomgeving nodig zijn. Code deployen, productie raadplegen en een incident onderzoeken zijn verschillende gevallen en moeten afzonderlijk worden beoordeeld.
Toegang tot productie is niet standaard vereist voor ontwikkeling. Moet een echt probleem worden onderzocht, kijk dan eerst of logs, traces, metrics of een reproductie in een geïsoleerde omgeving de diagnose mogelijk maken. Als directe toegang nodig is, baken dan af welke resource wordt geraadpleegd, welke acties zijn toegestaan en wanneer de toestemming verloopt.
Maak ook onderscheid tussen toestemming om code te wijzigen en toestemming om een versie te publiceren. Iemand kan een wijziging voorbereiden en ter beoordeling indienen zonder deployrechten te hebben. Zo betekent alleen-lezen toegang tot metrics niet dat iemand alerts of configuratie mag aanpassen.
Systemen en toegangsrelaties inventariseren
Koppel in de inventaris personen aan concrete systemen; beperk je niet tot een algemene lijst met tools. Controleer bij een bestaande PHP-applicatie ten minste het volgende:
- Repositories: code, beschermde branches, beoordelingsconfiguratie en, indien van toepassing, technische documentatie.
- Omgevingen: ontwikkeling, integratie, tests, preproductie en productie; noteer welke gegevens en services met elke omgeving zijn verbonden.
- Databases: instantie, schema en toegestane bewerkingen. Verleen geen schrijfrechten als de taak alleen raadpleging vereist.
- Observeerbaarheid: logs, metrics, traces, alerts en tools voor foutopvolging; maak onderscheid tussen lezen en beheren.
- Integratie en deployment: pipelines, artifactmanagers en publicatiemechanismen. Leg vast wie definities of secrets kan wijzigen.
- Verbonden services: opslag, e-mail, betalingen, queues, externe API's en secretmanagement, afhankelijk van wat de applicatie gebruikt.
Leg voor elk item de identiteit, het doel, het machtigingsniveau, de interne goedkeurder en de beoordelings- of vervaldatum vast. Met deze inventaris kun je indirecte toegang opsporen: een recht op een pipeline kan bijvoorbeeld deployment naar een omgeving mogelijk maken, ook als het account geen directe toegang tot de server heeft.
Rechten beperkt, individueel en tijdelijk toekennen
Gebruik waar mogelijk individuele accounts. Gedeelde accounts maken het lastig om acties betrouwbaar aan personen toe te wijzen, bemoeilijken het intrekken van toegang en kunnen inloggegevens buiten de controle van de organisatie brengen. Als een tool geen afzonderlijke identiteiten ondersteunt, documenteer dan de uitzondering en beperk wie het account mag gebruiken en hoe het gebruik wordt geregistreerd.
Pas het principe van minimale rechten toe: ken alleen de mogelijkheden toe die voor de huidige taak nodig zijn. In een repository kan alleen-lezen toegang bijvoorbeeld volstaan om code te beoordelen; schrijfrechten zijn gerechtvaardigd om wijzigingen aan te brengen. In een niet-productiedatabase kan een testaccount fictieve gegevens en beperkte rechten hebben, in plaats van productie-inloggegevens te repliceren.
Scheid inloggegevens per omgeving en functie. Hergebruik geen secret dat geldig is voor productie in ontwikkeling en zet geen inloggegevens in broncode, gedeelde bestanden of tickets. Gebruik de goedgekeurde methode voor het opslaan van secrets en beperk wie ze kan raadplegen of roteren. Als een taak geen secret vereist, configureer de omgeving dan zo dat de gebruiker het niet hoeft te zien.
Koppel elke toekenning aan een termijn of een expliciete beoordeling. De looptijd moet aansluiten op de taak en mag niet voor het gemak onbeperkte toegang worden. Een automatische vervaldatum helpt om iets niet te vergeten, maar vervangt geen beoordeling wanneer de verantwoordelijkheid verandert of een opdracht eindigt.
Aanvraag, goedkeuring en beoordeling vastleggen
Stel een eenvoudig proces op waarin vier zaken worden vastgelegd: wie de toegang aanvraagt, waarvoor die nodig is, wie deze goedkeurt en hoe wordt gecontroleerd of de toegang nog nodig is. De goedkeuring moet komen van een interne persoon die de impact op het systeem kan beoordelen, zoals de verantwoordelijke voor de applicatie of het platform. Voor gevoelige rechten kan volgens het interne proces ook een beoordeling door security of operations nodig zijn.
Registreer de toekenning en wijzigingen op een plek die de verantwoordelijken kunnen raadplegen. Het register moet duidelijk maken welk recht wanneer is verleend, zonder wachtwoorden of tokens op te slaan. Plan beoordelingen op relevante momenten: wanneer de taak verandert, wanneer een samenwerking wordt verlengd en voordat rechten voor gegevens of deployments worden vernieuwd.
Stem infrastructuurrechten af op applicatierechten, maar verwar ze niet met elkaar. Een serveraccount, een cloudidentiteit en een databasegebruiker zijn verschillende controles. Eén ervan intrekken garandeert niet dat de andere verdwijnen; toegang tot een dashboard verleent bovendien niet altijd dezelfde beperkingen voor gebruik via een API of pipeline.
Uitzonderingen voor productie en incidenten voorbereiden
Voor sommige incidenten is raadpleging van productie of een dringende ingreep nodig. Bepaal vooraf hoe zo'n uitzondering wordt geactiveerd, wie de toegang autoriseert, welke acties zijn toegestaan en wie het werk begeleidt of achteraf beoordeelt. Gebruik waar mogelijk een tijdelijke toestemming met automatische vervaldatum en bewaar de beschikbare activiteitenlogs.
Scheid bij dringende wijzigingen, als de operationele inrichting dat toelaat, de autorisatie van de uitvoering: degene die het probleem onderzoekt kan de diagnose aanleveren of de wijziging voorbereiden, terwijl een bevoegd persoon deze valideert en publiceert. Als de situatie vereist dat één en dezelfde persoon ingrijpt, documenteer dan de reden en voer achteraf een beoordeling uit. Laat een eenmalige uitzondering geen permanent privilege worden.
Onboarding, wijzigingen en vertrek testen
Test de procedure met concrete scenario's voordat je erop vertrouwt. Controleer bij onboarding of iemand alleen de goedgekeurde toegangsrechten krijgt en de taak in de bedoelde omgeving kan uitvoeren. Verifieer bij een wijziging van verantwoordelijkheden dat de eerdere rechten opnieuw worden beoordeeld en de nieuwe rechten een onderbouwing en termijn hebben.
Trek bij vertrek de identiteit en rechten in op elk systeem uit de inventaris, waaronder repositories, cloud, databases, observability, pipelines en verbonden services. Als een inloggegeven mogelijk gedeeld is of niet per gebruiker kan worden ingetrokken, roteer het dan en controleer het bijbehorende gebruik. Controleer waar nodig ook actieve sessies, persoonlijke tokens en API-sleutels.
Controleer tot slot dat de intrekking geen operationeel proces zonder verantwoordelijke achterlaat: geplande taken, serviceaccounts, integraties of pipelines kunnen afhankelijk zijn van een externe identiteit. Het account van één persoon mag niet de enige eigenaar zijn van noodzakelijke automatiseringen. Wijs deze resources toe aan passende interne identiteiten en verantwoordelijken en controleer of ze blijven werken nadat de persoonlijke toegang is ingetrokken.
Herbruikbare checklist
- Zijn de taak en de benodigde systemen concreet beschreven?
- Zijn de rechten voor ontwikkeling, tests, observability en deployment van elkaar gescheiden?
- Gebruikt elke toegang een individuele identiteit en het laagst haalbare machtigingsniveau?
- Zijn inloggegevens per omgeving gescheiden en buiten de broncode opgeslagen?
- Zijn er een interne goedkeurder, een register en een beoordelings- of vervaldatum?
- Zijn de scope, autorisatie en beoordeling voor uitzonderingen in productie vastgelegd?
- Omvat de vertrekprocedure alle systemen en het roteren van gedeelde inloggegevens?
- Hebben automatiseringen en services na intrekking nog steeds een verantwoordelijke?
Deze aanpak neemt niet alle risico's weg en vervangt de beveiligingsmaatregelen van de applicatie niet. Wel maakt ze externe toegang controleerbaar en aanpasbaar: toegang wordt verleend voor een concrete behoefte, opnieuw beoordeeld wanneer die behoefte verandert en gecoördineerd ingetrokken wanneer ze eindigt.
