De productie-VPS haalt de repository op via een implementatiesleutel – goed. Behalve dat het werd gegenereerd op de laptop van de technisch directeur, gekopieerd naar /root/.ssh en hergebruikt voor het voorbereiden van en productie. Wanneer de staging in gevaar komt tijdens een kwetsbare WordPress-plug-in, kloont de aanvaller ook de privé-API-repository: dezelfde sleutel, leestoegang tot de volledige gekoppelde monorepo.
Implementatiesleutels zijn het paspoort tussen uw host en Git. Slecht gesneden transformeren ze een applicatie-incident in een lek op het gebied van intellectueel eigendom.
Sleutel SSH implementeren: minimaal bereik
Op GitHub of GitLab: implementeer sleutel per repository, alleen-lezen voor een server die alleen de code ophaalt.
| Benader | Voordeel | Risico |
|---|---|---|
| Sleutel alleen-lezen implementeren | Beperkte toegang tot een repository | Dubbele sleutel voor meerdere omgevingen |
| PAT-machinegebruiker | Rijke API | Scope te breed, geen rotatie |
| OAuth-app | Gecentraliseerd | Complexiteit, audit |
Maak een Linux deploy gebruiker aan zonder shell login (/usr/sbin/nologin), met ForceCommand als je je moet beperken tot git-shell.
Een sleutel op de productieserver is waard wat die server waard is; behandel hem als een geheim op het hoogste niveau.
CI versus runtime: twee verschillende identiteiten
De CI-pijplijn (GitHub Actions, GitLab CI) gebruikt alleen een token met read_repository scopes of een implementatiesleutel write als u tags en releases automatiseert - nooit met beheerdersrechten voor de organisatie.
De productieserver haalt gewoon de code op. De CI bouwt en pusht het artefact (afbeelding, archief); de server wordt niet noodzakelijkerwijs bij elke implementatie gekloond als u onveranderlijke afbeeldingen levert.
Door build-ID's en implementatie-ID's te scheiden, wordt de aanvalsketen beperkt.
Rotatie, audit en inventarisatie
Houd een record bij: sleutel → repository → omgeving → aanmaakdatum → volgende rotatie. Automatiseer een waarschuwing van 90 dagen.
Typische procedure: genereer een nieuw ed25519-paar, voeg de publieke sleutel toe aan de Git-host in korte co-existentie, valideer de implementatie bij staging en vervolgens productie, en trek de oude in. Na incident: direct intrekken, niet “aanstaande maandag”.
Alternatieve hosts en git-toegang
Bij gedeeld zonder SSH git: implementeren via FTP of rsync vanaf de CI – geen langetermijnsleutel op gedeelde hosting. Op VPS en bare metal: sleutelstandaard implementeren.
Sommige PaaS-platforms (Clever Cloud, etc.) gebruiken webhooks – geen sleutel op de machine; controleer wie een implementatie kan activeren.
Veelvoorkomende fouten
Privésleutel vastgelegd in de repository - scan de git-geschiedenis. StrictHostKeyChecking no faciliteert MITM-aanvallen: pin known_hosts. Privé-submodule zonder speciale implementatiesleutel: ouderkloon slaagt, submodule mislukt of forceert sleutel te groot. Persoonlijke token van Lead hergebruikt in CI en op de server: een enkel lek brengt de build en productie in gevaar.
De bovenkant: alleen-lezen, wat te veel leest
Automatiseren zonder blokkering betekent korte machine-identiteiten, minimale reikwijdte, gedocumenteerde rotatie – geen onsterfelijke sleutel in de root.
Beslis en ga vooruit zonder blinde vlek
Creëer een implementatiesleutel per repository en per omgeving, een speciale 'deploy'-gebruiker, afzonderlijke CI-identifiers, driemaandelijkse rotatie en een audit van 'known_hosts'. Vergelijk VPS en PaaS met veilige implementatie via de overzicht en de vergelijker. De gidsen geven gedetailleerde informatie over de pijpleidingen.
Voer onmiddellijk een audit uit: maak een lijst van actieve Git-sleutels en toegankelijke repository's - verwijder wezen.
Veelgestelde vragen
Sleutel of CI-token implementeren?
Implementeer de sleutel alleen-lezen per repository voor de server die de code ophaalt; CI-token met minimale reikwijdte voor API-aanroepen.
Waarom het schrijven op een implementatiesleutel verbieden?
Een gecompromitteerde server met schrijfrechten legt de toeleveringsketen bloot; reserve pull-only in productie.
Hoe kan ik roteren zonder de productie te verlagen?
Kort naast elkaar bestaan van twee sleutels, validatie bij staging en vervolgens intrekking van de oude sleutel.
Slechts één git-gebruiker gedeeld op de server?
Anti-patroon: geef de voorkeur aan één toegewijde implementatiegebruiker en één sleutel per omgeving.
Met een schone implementatiesleutel kan alleen een repository worden gekloond, en niet uw ochtend nadat de staging is gecompromitteerd.