SSH-sleutels en certificaten veilig delen met je team

"Stuur me de SSH-sleutel even via Slack." Elk ontwikkelteam heeft dit weleens gehoord. Servertoegang is dringend, een nieuw teamlid moet zijn omgeving opzetten, de deployment is over een paar minuten en iemand mist de sleutel.

Maar dit ene verzoek kan het begin zijn van een ernstig beveiligingsincident.

Waarom het delen van SSH-sleutels bijzonder gevaarlijk is

SSH-sleutels zijn niet zoals gewone wachtwoorden. Ze geven volledige toegang tot een server.

Factor	Wachtwoord	SSH-sleutel
Bereik	Specifiek account	Hele server
Impact bij lek	Dat account	Alle data op de server
Gemak van rotatie	Direct wijzigen	Sleutel regenereren + alle servers updaten
2FA-ondersteuning	Beschikbaar	Sleutel is zelf de authenticatie

Een gelekte SSH-sleutel stelt elk bestand, elke database en elk stuk code op de server bloot. Dit is fundamenteel anders dan een enkel wachtwoordlek.

Wanneer teams SSH-sleutels moeten delen

Realistisch gezien zijn er legitieme redenen om te delen.

• Gedeelde servertoegang: Staging- of productieservers die het hele team nodig heeft
• Deploy keys: Sleutels gebruikt in CI/CD-pipelines
• SSL-certificaten: Certificaatvernieuwing wanneer verantwoordelijkheden veranderen
• API-geheimen: Authenticatiegegevens voor integraties met derden
• Databasegegevens: Noodrespons bij incidenten

Gevaarlijke deelmethoden

1. Slack of Discord DM's

Chatgeschiedenis wordt permanent opgeslagen op servers. Iedereen kan zoeken op "ssh" of "key" om eerder gedeelde sleutels te vinden. Zelfs accounts van voormalige medewerkers behouden de geschiedenis.

2. E-mail

Permanent gearchiveerd op mailservers en onbeheersbaar zodra doorgestuurd. Een enkele mailserverhack stelt elke ooit verzonden sleutel bloot.

3. Gedeelde Google Drive of Notion

Gedetailleerde toegangscontrole is lastig. Wanneer bestanden synchroniseren, blijven lokale kopieën op apparaten staan. Alle kopieën terughalen wanneer iemand het team verlaat is praktisch onmogelijk.

4. Gecommit naar een Git-repository

De gevaarlijkste methode. Sleutels blijven voor altijd in Git-geschiedenis bestaan. Zelfs verwijderde bestanden kunnen worden hersteld uit de geschiedenis. Als de repo openbaar is, is de sleutel wereldwijd blootgesteld.

Veilige deelmethoden

Methode 1: LOCK.PUB geheime memo (Beste voor eenmalige overdrachten)

De meest praktische oplossing wanneer je een sleutel eenmalig moet overdragen.

1. Maak een geheime memo op LOCK.PUB
2. Plak de SSH-sleutel of certificaatinhoud
3. Stel een sterk wachtwoord in
4. Stel de kortst mogelijke verloopdatum in (1-4 uur)
5. Stuur de link via Slack, deel het wachtwoord telefonisch
6. Nadat de ontvanger de sleutel lokaal heeft opgeslagen, verloopt de link

Voordelen:

• De sleutel wordt niet in platte tekst opgeslagen op een permanente server
• Ontoegankelijk na verlopen
• Geen platte tekst van de sleutel in chatgeschiedenis

Methode 2: Secrets Managers (Voor grotere teams)

Gebruik gespecialiseerde tools zoals HashiCorp Vault, AWS Secrets Manager of Google Secret Manager.

• Toegangscontrole en auditlogboeken inbegrepen
• Geautomatiseerde sleutelrotatie mogelijk
• Kosten en opzetcomplexiteit zijn nadelen

Methode 3: SSH Certificate Authority (Langetermijnoplossing)

In plaats van gedeelde sleutels, draai een SSH CA die individuele certificaten uitgeeft aan elke gebruiker.

• Elimineert de noodzaak om sleutels te delen volledig
• Toegangsbeheer per gebruiker
• Hogere initiële opzetkosten

Methode 4: Individuele sleutels (Meest aanbevolen)

Geef waar mogelijk individuele sleutels uit in plaats van een sleutel over het team te delen.

Principe: Gedeelde sleutel < Individuele sleutels
Gedeelde sleutel gelekt → Heel team getroffen
Individuele sleutel gelekt → Alleen die gebruiker getroffen

Checklist wanneer je moet delen

Als individuele sleutels geen optie zijn en delen onvermijdelijk is, volg dan deze checklist.

Voor overdracht

• Heb je het minimale machtigingsbereik voor de sleutel ingesteld?
• Zou een alleen-lezen sleutel voldoende zijn?
• Kun je IP-restricties toepassen?

Tijdens overdracht

• Stuur je de sleutel en het wachtwoord via verschillende kanalen?
• Heb je de kortst praktische verloopdatum ingesteld?
• Kan de afzender het origineel verwijderen nadat de ontvanger bevestigt?

Na overdracht

• Bevestig dat de ontvanger de sleutel veilig heeft opgeslagen
• Verifieer dat de gedeelde link/memo is verlopen
• Monitor sleutelgebruikslogboeken

Sleutelrotatieschema

Regelmatige sleutelrotatie beperkt de geldigheidsperiode van elke gecompromitteerde sleutel.

Sleuteltype	Aanbevolen rotatie
Productieserversleutels	90 dagen
Deploy keys	90 dagen
SSL-certificaten	Bij elke vernieuwing
API-geheimen	90 dagen
Ontwikkel-/stagingsleutels	180 dagen

Beveiligingschecklist voor DevOps-teams

• Worden individuele SSH-sleutels gebruikt voor alle servers?
• Als er gedeelde sleutels bestaan, zijn IP-restricties geconfigureerd?
• Worden sleutels van vertrekkende medewerkers direct gedeactiveerd?
• Is er een sleutelrotatieschema?
• Zijn SSH-sleutels ooit gecommit naar een Git-repo?
• Zijn er sleutels opgeslagen in platte tekst in chatgeschiedenis?
• Wordt een verlopend kanaal gebruikt voor geheime overdrachten?

Samenvatting

SSH-sleutels en certificaten vormen de ruggengraat van serverbeveiliging. Ze versturen via Slack DM of e-mail is als je huissleutel vastpinnen aan een openbaar prikbord. Geef waar mogelijk individuele sleutels uit. Wanneer delen onvermijdelijk is, gebruik een geheime memo met de kortst mogelijke verloopdatum.

Maak nu een geheime memo om SSH-sleutels veilig over te dragen.

Maak een geheime memo