CapordiaBenoem de verantwoordelijken voordat je toegangen verdeelt
Onderscheid de verantwoordelijke voor het huurdossier, de persoon die toegang tot het project toestaat en degene die technische wijzigingen op de doelomgeving kan doorvoeren. De verantwoordelijke voor de resultaten hoeft niet noodzakelijk processen te starten of de machine te beheren. Schrijf de vereiste handelingen op voordat je de rechten kiest: een export lezen, invoer plaatsen, een taak uitvoeren of een omgeving wijzigen.
Controleer daarna het bereik van de daadwerkelijk verleende toegangen. Als je niet het recht hebt om identiteiten aan te maken of machtigingen in te stellen, laat dan de mogelijke procedure bevestigen voordat je andere betrokkenen uitnodigt. Omzeil deze beperking niet door het wachtwoord van het Capordia-account te verspreiden. Het delen van werk en het beheer van het commerciële dossier zijn twee verschillende zaken.
Gebruik een individuele identiteit en ken de reikwijdte ervan
Een individuele identiteit maakt het mogelijk de toegang van één persoon in te trekken zonder die van het hele team te vervangen. In een organisatie met SSH-sleutels maakt OpenSSH onderscheid tussen de publieke sleutel die de server kent en de privésleutel die de gebruiker bezit. Het coördinatiedocument mag een verwijzing of vingerafdruk van een publieke sleutel bevatten; het mag nooit de privésleutel of de wachtwoordzin daarbij bevatten.
Twee verschillende sleutels die toegang geven tot hetzelfde systeemaccount creëren niet automatisch twee verschillende bestandsperimeters. De rechten hangen af van het account en de mechanismen die op de machine zijn geconfigureerd. Bepaal dus of de eis alleen betrekking heeft op individuele authenticatie of ook op de scheiding van handelingen. Voorzie voor automatiseringen een expliciete identiteit en eigenaar, zonder heimelijk de persoonlijke identiteit van een collega te hergebruiken.
Controleer het doel voordat je er een identiteit aan presenteert
Controleer bij de eerste toegang de naam van de machine, het verwachte account en de vingerafdruk van de hostsleutel aan de hand van een betrouwbare verwijzing die je tijdens het overdrachtsproces van de toegangen hebt verkregen. Deze hostsleutel identificeert de server; hij staat los van je gebruikerssleutel. Een onverwachte melding over een gewijzigde identiteit van de server verdient onderzoek, niet het automatisch verwijderen van de bekende verwijzing.
OpenSSH bewaart hostsleutels en meldt wijzigingen daarin. Gebruik deze informatie samen met de context: een aangekondigde reconstructie van de machine, een gewijzigd adres of een onverklaarde gebeurtenis. Laat de wijziging bevestigen voordat je verdergaat als deze niet wordt verwacht. Het doel is niet om bij elke verbinding een ritueel toe te voegen, maar om te voorkomen dat je een identiteitswaarschuwing als een loutere weergavestoring behandelt.
Fictief voorbeeld: drie betrokkenen, drie behoeften
Het fictieve team "Dossier des ouvrages" bereidt een werkweek voor. Idriss voert de verwerkingen van project A uit, Noémie leest de exports na en Sacha komt tijdelijk tussenbeide om de omgeving te configureren. Het team wil de rechten uit de tabel, maar moet nagaan of ze toepasbaar zijn met het systeem dat daadwerkelijk wordt overgedragen. Het gaat niet om bestaande klantaccounts of om functies voor teambeheer die Capordia aankondigt.
Het beslissende principe is dat Noémie geen beheerders toegang krijgt om een resultaat te openen en dat de tussenkomst van Sacha een einde heeft. Een menselijke goedkeuring alleen configureert geen enkel recht: de technisch verantwoordelijke past de beschikbare mechanismen toe, waarna ieder de voorziene controles uitvoert. Als de gewenste scheiding niet haalbaar is, moet het project zijn organisatie aanpassen voordat het gegevens invoert die deze scheiding vereisen.
| Betrokkene | Behoefte | Gewenste perimeter | Herziening |
|---|---|---|---|
| Idriss, uitvoering | Invoer plaatsen en project A starten | Werkruimte A, zonder algemeen beheer | Einde campagne of rolwijziging |
| Noémie, validatie | De overgedragen exports lezen | Weerhouden resultaten, zonder wijziging van de invoer | Einde validatie |
| Sacha, tussenkomst | De toegestane omgeving voorbereiden | Bepaalde en goedgekeurde wijziging | Zodra de tussenkomst is ontvangen |
Een toegangsfiche opstellen en de grenzen testen
De fiche verbindt een persoon of automatisering, een technische identiteit, een goedkeurder, een perimeter, een rechtvaardiging en een einddatum. Bewaar de verwijzing naar de publieke sleutel en de intrekkingsprocedure zonder de geheimen op te slaan. Met OpenSSH ssh-keygen kun je de vingerafdruk van een publieke sleutel weergeven: deze verwijzing helpt om de juiste sleutel aan te duiden bij het toevoegen of verwijderen, zonder het privégedeelte te kopiëren.
Test een toegestane handeling op een synthetisch bestand en daarna een handeling die bewust buiten de perimeter valt en die als geweigerd is voorzien. Voor een leesrol moet het openen werken en moet een gecontroleerde wijzigingspoging worden geweigerd. Gebruik geen echte gegevens om een verwijderverbod te testen. Controleer ook de gemeenschappelijke paden en de bestemming van de uitvoer, want een correct recht op een map garandeert niet alle paden van het programma.
Intrekking plannen en een nieuwe verbinding verifiëren
Start de intrekking aan het einde van de werkzaamheden, bij het vertrek van een persoon of na een vermoeden van compromittering. De verantwoordelijke identificeert alle betrokken autorisaties, inclusief de andere toegestane toegangswegen voor dezelfde identiteit. Hij past de intrekking toe volgens de werkelijke configuratie. De RevokedKeys-richtlijn van OpenSSH is een mogelijk mechanisme naast de gedocumenteerde mechanismen; ga er niet van uit dat het actief is op een machine zonder verificatie.
Controleer vervolgens dat een nieuwe authenticatie met de ingetrokken identiteit wordt geweigerd, zonder de hersteltoegang van de verantwoordelijke te verwijderen. Onderzoek apart de al geopende sessies, de lopende taken en de automatiseringsidentiteiten: een autorisatie intrekken en een activiteit stopzetten zijn verschillende beslissingen. Als een taak moet doorgaan, draag de verantwoordelijkheid ervan over volgens een afgesproken procedure in plaats van een identiteit verweesd achter te laten.
Vermijd shortcuts die de controle onmogelijk maken
Een gedeelde privésleutel maakt het onmogelijk te weten wie deze moet vervangen en dwingt vaak tot een collectieve rotatie. Brede toegang "voorlopig" blijft doorgaans duren als niemand de evaluatiedatum heeft vastgelegd. Een validatieaccount dat ook wordt gebruikt om de machine te beheren, maakt de scheidingscontroles moeilijk te interpreteren. Los deze problemen op in de toegangsfiche voordat ze een afhankelijkheid van de exploitatie worden.
Vermijd ook om agent-forwarding, tunnels of toegangsuitzonderingen toe te voegen alleen om een niet-gediagnosticeerd probleem te omzeilen. Laat de verbindingsbehoefte en de beperkingen ervan beschrijven door de bevoegde verantwoordelijke. Deze gids biedt geen universele serverconfiguratie: de mechanismen hangen af van de toegekende rechten, de omgeving en de eisen van het project. Algemene documentatie geldt niet als validatie van het doel.
Een toegangsorganisatie opleveren die verifieerbaar blijft
Verzamel bij de overdracht de goedgekeurde matrix, de actieve identiteiten, de toegestane en geweigerde tests, de deadlines en de persoon die een toegang kan intrekken. Controleer of een afwezige persoon kan worden vervangen zonder diens geheim te verspreiden. Continuïteit berust op een procedure en een bevoegde reserveverantwoordelijke, niet op een gedeeld wachtwoord in de projectmap.
Herzie bij de overdracht de overbodig geworden toegangen en de automatiseringen die van een persoonlijke identiteit afhangen. Als een onverwachte weigering het werk blokkeert, stel dan een gericht incidentdossier op met technische identiteit, betrokken pad en gefilterde fout. Voeg geen algemene rechten toe alleen om het symptoom te laten verdwijnen. De juiste afsluiting is een noodzakelijke, geteste toegang met een bekend einde.
Vragen om te beslissen
Moet het Capordia-account met alle betrokkenen worden gedeeld?
Nee. Het volgen van de huur en de technische toegangen tot het werk moeten apart worden georganiseerd. Definieer de mogelijke machine-identiteiten met de daadwerkelijk toegekende rechten. Deze methode veronderstelt geen systeem voor uitnodigingen of teamrollen in de Capordia-omgeving.
Geeft een publieke sleutel automatisch de juiste rechten?
Nee. Ze dient voor authenticatie wanneer ze is toegestaan; de toegankelijke acties hangen vervolgens af van het account en de systeemrechten. Controleer een toegestane actie en een actie die moet worden geweigerd op synthetische bestanden.
Wat moet je controleren na het vertrek van een betrokkene?
Trek diens autorisaties in, controleer de weigering van een nieuwe authenticatie en onderzoek sessies, taken en automatiseringen die nog aan diens identiteit zijn gekoppeld. Houd een bevoegde verantwoordelijke aan voor herstel en opvolging. Concludeer niet dat de intrekking is voltooid op basis van een simpel aangevinkt vakje.