Naleving van SSH-sleutelbeheer: wat auditors verwachten en hoe u dit kunt realiseren.

SSH-sleutels zijn krachtige, langdurige inloggegevens waarvan auditors tegenwoordig verwachten dat ze volledig in eigendom zijn, worden bewaakt, geroteerd en tijdig worden ingetrokken. SSH-sleutels verlopen niet vanzelf, wat betekent dat de organisatie dezelfde levenscyclusdiscipline moet toepassen op SSH-sleutels als op alle andere geprivilegieerde inloggegevens. Zonder actief beheer hopen SSH-sleutels zich op als achterdeuren zonder geldige vervaldatum: geen vervaldatum, geen eigendomsregistratie en geen auditspoor. De aanbevolen aanpak: behandel elke SSH-sleutel als een geprivilegieerde inloggegeven, stel een inventaris op, wijs eigendom toe, dwing rotatie en intrekking af en bewaar de sessielogboeken en bewijsmateriaal voor toegangscontroles die PCI DSS, ISO 27001, SOC 2, NIST en CIS vereisen.

Kort antwoord: Wat houdt naleving van SSH-sleutelbeheer in?

Naleving van SSH-sleutelbeheer betekent dat u aan auditors kunt aantonen dat elke SSH-sleutel in uw omgeving eigendom is van, beheerd wordt door, bewaakt wordt en tijdig verwijderd wordt. Belangrijke frameworks zoals PCI DSS v4.0.1, ISO 27001, SOC 2 en NIST SP 800-53 verwachten allemaal dat SSH-sleutels met dezelfde discipline worden beheerd als andere geprivilegieerde referenties. Het verschil tussen slagen en falen voor een SSH-sleutelaudit is bijna altijd een proces- en bewijsprobleem, geen cryptografische fout. Voor het basisraamwerk voor SSH-sleutelrotatie, zie Een effectief SSH-sleutelrotatiebeleid ontwerpen . Voor de pagina over de pijler SSH-sleutelgovernance, zie Hoe SSH-sleutelbeheer de beveiliging versterkt.

Waarom werden SSH-sleutels een probleem met de naleving van regelgeving?

Het ontwerp van de SSH-sleutel zorgt voor het complianceprobleem. Een SSH-sleutel bestaat uit een paar: de privésleutel blijft bij de gebruiker of service; de ​​publieke sleutel bevindt zich op de doelserver in een authorized_keys-bestand. Wanneer de twee overeenkomen, wordt toegang verleend zonder wachtwoordprompt en zonder ingebouwde vervaldatum. De protocolarchitectuur is te lezen in RFC 4251.

Dat ontwerp is handig, maar het is tegelijkertijd het probleem. Sleutels hopen zich op zonder dat er wordt opgeruimd, omdat opruimen bijna altijd handmatig gebeurt. Na verloop van jaren verliezen de meeste teams het overzicht over hoeveel sleutels er zijn en waartoe elke sleutel toegang heeft. In de branche wordt dit sleutelwildgroei genoemd : te veel sleutels, zonder duidelijk overzicht van wie ze bezit of wat ze ontgrendelen. Een auditor noemt het ongecontroleerde toegang.

De wildgroei aan systemen is slechts een deel van het verhaal. De meeste SSH-sessies worden nooit gelogd, waardoor er geen auditspoor is van wie wanneer verbinding heeft gemaakt en waarmee. Zonder die registratie kan één misbruikte sleutel leiden tot een datalek dat niet kan worden verklaard, gereconstrueerd of toegeschreven. Machine-identiteiten zijn nu veel talrijker dan menselijke identiteiten, en die kloof blijft groeien naarmate de cloud, automatisering en AI zich verder ontwikkelen. Veel van die machine-identiteiten authenticeren zich met SSH-sleutels. Als een organisatie niet kan vaststellen wie de eigenaar van een sleutel is of wat ermee kan worden ontgrendeld, kan ze tijdens een compliance-audit geen controle aantonen.

Wat betekent 'beheerd' in de context van compliance?

Auditors vragen niet om inzage in privésleutels. Ze willen een proces zien. De duidelijkste referentie hiervoor komt van NIST. NIST Internal Report (NISTIR) 7966 is de officiële richtlijn voor het beveiligen van SSH-toegang. Het beschrijft de levenscyclus van een sleutel: toegang aanvragen en goedkeuren, de sleutel toewijzen, het gebruik ervan monitoren, volgens schema roteren en verwijderen wanneer de sleutel niet langer nodig is.

Een auditklaar SSH-sleutelprogramma omvat zes zaken:

• Inventaris: Elke sleutel is gedocumenteerd, de locatie ervan is bekend en er is vastgelegd tot welke gegevens deze toegang heeft.
• Eigendom: Elke sleutel is gekoppeld aan een specifieke persoon of dienst.
• Minste privilege: Een sleutel reikt alleen tot datgene wat zijn functie vereist, niet meer.
• Rotation: Sleutels worden volgens schema vervangen en onmiddellijk wanneer iemand vertrekt of er een vermoeden van een inbreuk bestaat.
• Monitoring: Elke sessie met beheerdersrechten wordt geregistreerd en die activiteit wordt gecontroleerd op afwijkende patronen.
• Herroeping: De toegang wordt snel ingetrokken en de organisatie kan met gedateerde documenten bewijzen dat dit is gebeurd.

Als er één van deze controles ontbreekt, ontstaat er een hiaat dat een beoordelaar zal opmerken. Deze zes controles zijn ook wat de belangrijkste compliance-raamwerken verwachten.

Hoe gaan de belangrijkste frameworks om met SSH-sleutels?

Vrijwel geen enkel framework gebruikt de term 'SSH-sleutel'. Ze beschrijven uitkomsten. Zodra die uitkomsten worden geïnterpreteerd als regels over inloggegevens, wordt de koppeling duidelijk:

Kader	Wat het verwacht van uw SSH-sleutels	Belangrijke SSH-gerelateerde controles
PCI DSS v4.0.1	Unieke identiteit voor elke gebruiker, geen gedeelde inloggegevens, strikte controle over systeemaccountsleutels.	Vereiste 8 (gebruikersidentiteit, verbod op gedeelde sleutels); Vereiste 8.6 (applicatie-/systeemaccounts, verbod op hardgecodeerde geheimen); Vereiste 7.2.4 (toegangscontroles om de zes maanden)
ISO / IEC 27001: 2022	Beheerde identiteiten, gecontroleerde toegangsrechten, beschermde bevoorrechte toegang, correct gebruik van cryptografie	Bijlage A 5.15 tot en met 5.18 (identiteits- en toegangsbeheer); 8.2 (bevoorrechte toegang); 8.24 (gebruik van cryptografie)
SOC 2	Logische toegangscontroles die toegang verlenen, beoordelen en intrekken op basis van aantoonbaar bewijs.	CC6.1 (logische toegangscontrole); CC6.2 (authenticatie); CC6.3 (toegang intrekken)
NIST SP 800-53	Accountbeheer, toegangsbeheer en authenticatiebeheer	AC-2 (accountbeheer); AC-3 (toegangshandhaving); IA-5 (authenticatorbeheer)
CIS-besturingselementen v8	Account- en toegangscontrolebeheer, verwijdering van verouderde of ongebruikte inloggegevens	Controle 5 (accountbeheer); Controle 6 (toegangsbeheer)

PCI DSS is het strengste raamwerk op dit gebied. De toekomstgerichte vereisten van PCI DSS v4.0.1 zijn vanaf 31 maart 2025 verplicht. Vereiste 8 vereist unieke identiteiten voor alle gebruikers. Gedeelde SSH-sleutels overtreden deze regel, omdat authenticatielogboeken geen onderscheid kunnen maken tussen gebruikers wanneer één sleutel wordt gedeeld. Vereiste 8.6.2 vereist dat wachtwoorden en wachtzinnen voor applicatie- en systeemaccounts niet hardgecodeerd mogen zijn in scripts, configuratiebestanden of broncode. Hetzelfde doel geldt direct voor SSH-privésleutels: een privésleutel die is ingebed in een implementatiescript is precies de hardgecodeerde authenticatie waarop deze vereiste zich richt.

ISO/IEC 27001:2022 hanteert een risicogebaseerde aanpak. De controles in Annex A vereisen het beheren van identiteiten, het controleren van toegangsrechten, het beschermen van bevoorrechte toegang en het correct toepassen van cryptografie. SSH-sleutels raken al deze vier gebieden. SOC 2 richt zich op de vraag of logische toegangscontroles daadwerkelijk werken en of de organisatie dit kan aantonen. De CIS-controles zijn het meest operationeel specifiek, met duidelijke stappen voor accountbeheer en het intrekken van toegang die niet langer in gebruik is.

Ook privacyregelgeving is van toepassing. Artikel 32 van de AVG vereist een adequate beveiliging van persoonsgegevens. Een onbeheerde SSH-sleutel die toegang geeft tot systemen met persoonsgegevens is volgens de wet een beveiligingsfout. HIPAA legt vergelijkbare eisen op aan toegangscontrole voor zorgsystemen. Het patroon in alle regelgeving is consistent: ken je inloggegevens, beperk ze, houd ze in de gaten en verwijder ze tijdig.

Levenscyclusbeheer van SSH-sleutels voor naleving van regelgeving

Levenscyclusfase	Activiteit	Eigenaar	Bewijs van naleving geleverd
Verzoek en goedkeuring	Gebruikers of diensten vragen SSH-toegang aan; toegang wordt goedgekeurd op basis van de bedrijfsbehoefte en een beoordeling van het principe van minimale bevoegdheden.	Toegangsbeoordelaar; manager	Goedkeuringsdocument met zakelijke onderbouwing
Provisioning	Sleutelpaar gegenereerd met behulp van een goedgekeurd algoritme (Ed25519 heeft de voorkeur, RSA-3072 is het minimum); publieke sleutel wordt verspreid naar geautoriseerde servers.	SSH-sleutelbeheerplatform of sleutelbeheerder	Generatielogboek met algoritme, sleutelvingerafdruk en doelsystemen
Gebruik en monitoring	Alle SSH-sessies worden geregistreerd met sleutelvingerafdruk, tijdstempel, bron-IP-adres en doelsysteem.	Geautomatiseerde registratie; beveiligingsoperaties	Sessielogboeken voor nalevingscontrole en incidentafhandeling
Periodieke toegangsbeoordeling	Alle SSH-sleutelautorisaties zijn gecontroleerd; onbevoegde of verweesde sleutels zijn verwijderd; het eigenaarschap is bevestigd.	Sleutelbeheerder; toegangsbeoordelaar	Gedateerd beoordelingsverslag met genomen acties (sleutels verwijderd, geroteerd, bevestigd)
Rotatie	Sleutel wordt geroteerd volgens een door beleid vastgesteld schema (op basis van tijd) of op basis van een gebeurtenis (vertrek, inbreuk, uitfasering).	Geautomatiseerd SSH-sleutelbeheerplatform	Rotatielogboek met datum, triggertype en operator
herroeping	Openbare sleutel verwijderd uit alle authorized_keys-bestanden; toegang bevestigd verwijderd	Automatische trigger bij vertrek of inbreuk op de privacy	Intrekkingslogboek met triggerdatum, voltooiingsdatum en bevestiging

Rotatietriggers: Wanneer de geplande rotatie niet voldoende is

Tijdsgebonden rotatieschema's vormen de basis voor naleving. Gebeurtenisgebonden triggers fungeren als vangnet om de ernstigste auditbevindingen te voorkomen.

• Vertrek van een medewerker of functieverandering: Alle SSH-sleutels van de vertrekkende of van functie veranderende persoon moeten onmiddellijk worden geroteerd en ingetrokken. Documenteer de tijd die is verstreken tussen de kennisgeving van vertrek en de voltooiing van de intrekking; auditors zullen naar dit tijdsverschil kijken.
• Vermoedelijke of bevestigde inbreuk op de belangrijkste sleutels: De betreffende sleutel onmiddellijk intrekken; een vervangende sleutel genereren en implementeren; het verloop van het incident documenteren.
• Algoritme wordt afgeschaft: Elke SSH-sleutel die gebruikmaakt van een verouderd algoritme (DSA, RSA-1024) moet onmiddellijk worden vervangen door een goedgekeurd algoritme. Zie voor een vergelijking van de algoritmen de volgende documentatie: SSH-sleutels vergelijken: RSA, DSA, ECDSA of EdDSA.
• Systeemontmanteling: Trek alle SSH-sleutels in die zijn gekoppeld aan systemen die buiten gebruik zijn gesteld; gebruik sleutels niet opnieuw voor verschillende systemen.
• Einde van de overeenkomst met een derde partij of aannemer: Trek alle SSH-toegang die aan externe partijen is verleend in bij beëindiging van de relatie.

Welke fouten met SSH-sleutels leiden tot een onvoldoende bij audits?

De meeste bevindingen van audits zijn niet uitzonderlijk. Ze komen in alle organisaties terug:

• Verweesde sleutels: Een teamlid vertrekt, maar zijn of haar toegangssleutel blijft actief op de servers. PCI DSS-vereiste 8 en NIST AC-2 vereisen dat toegang die niet langer nodig is, tijdig wordt verwijderd.
• Gedeelde sleutels: Meerdere personen gebruiken één sleutel, waardoor geen enkel logboek acties naar een individu kan herleiden. PCI DSS-vereiste 8 vereist unieke identiteiten; gedeelde sleutels zijn hier een directe schending van.
• Vastgelegde sleutels: Privésleutels ingebed in scripts, containerimages of configuratiebestanden. PCI DSS-vereiste 8.6.2 verbiedt expliciet hardgecodeerde geheimen voor systeemaccounts.
• Geen rotatie: Sleutels die jaren geleden zijn aangemaakt, werken vandaag de dag nog steeds, zonder dat er een gedocumenteerde rotatie plaatsvindt. Elk framework vereist een vorm van beheer van de levenscyclus van inloggegevens.
• Geen auditlogboek: Er is geen registratie van wie wanneer verbinding heeft gemaakt en met welk systeem. SOC 2 CC6 en NIST AC-3 vereisen bewijs dat de toegangscontroles daadwerkelijk werken.
• Geen voorraad: De organisatie kan niet op verzoek een actuele lijst met SSH-sleutels overleggen. Een inventarisatie is de voorwaarde voor elke andere controle; zonder inventarisatie kan aan geen enkele vereiste van het raamwerk worden voldaan.

Hoe bouw je een auditbestendig SSH-sleutelprogramma op?

Een consistent en herhaalbaar proces is essentieel voor een succesvolle audit. De volgende implementatieworkflow van 7 stappen bouwt het bewijsmateriaal op dat auditors nodig hebben:

1. Stel de inventaris samen: Scan elke server en lees elk authorized_keys-bestand. Stel een centrale inventaris samen van sleutels, eigenaren en de systemen waartoe ze toegang hebben. Je kunt niet controleren wat je niet kunt zien; zonder inventaris kan geen enkele andere vorm van compliance-controle worden aangetoond.
2. Wijs aan elke sleutel een eigenaar toe: Een sleutel zonder eigenaar kent geen verantwoordingsplicht. Verwijder alle sleutels die geen eigenaar opeist. Documenteer het eigenaarschap in de inventaris met de rol, de bedrijfseenheid en de rechtvaardiging voor de toegang.
3. Formuleer een kort en duidelijk beleid: Definieer rotatieperioden per risicocategorie (hoog risico elke 30 tot 90 dagen, gemiddeld risico elke 90 tot 180 dagen, laag risico elke 180 tot 365 dagen); vereis unieke sleutels per persoon en doel; verbied gedeelde sleutels; verbied hardgecodeerde privésleutels in de code. Zie Een effectief beleid voor het roteren van SSH-sleutels ontwerpen voor het volledige raamwerk.
4. Automatiseer rotatie en intrekking: Handmatig uitdiensttreden en rouleren zijn de plekken waar compliance-lacunes ontstaan. Geautomatiseerde roulatie dicht de periode tussen de dag dat een persoon vertrekt en de dag dat zijn of haar toegang wordt ingetrokken. Registreer elke roulatie met datum en naam van de operator als controlemateriaal.
5. Sessielogboekregistratie inschakelen en centraliseren: Registreer elke geprivilegieerde SSH-sessie met sleutelvingerafdruk, bron-IP-adres, tijdstempel en doelsysteem. Stuur de logboeken door naar een SIEM-systeem. Het bewijsmateriaal moet gereed zijn voordat de auditor erom vraagt.
6. Voer periodieke toegangsbeoordelingen uit: PCI DSS vereist halfjaarlijkse beoordelingen; CIS Controls vereist kwartaalbeoordelingen. Een kwartaalbeoordeling voldoet aan beide eisen en spoort slapende sleutels op voordat ze tot bevindingen leiden. Documenteer elke beoordeling met datums en genomen acties.
7. Overweeg kortstondige SSH-certificaten: De meest robuuste eindtoestand voor naleving. In plaats van permanente sleutels geeft een vertrouwde certificeringsinstantie certificaten uit die binnen enkele uren verlopen. De toegang verdwijnt vanzelf; er zijn geen oude sleutels die later opgeruimd hoeven te worden. Dit model voldoet aan de essentie van alle bovenstaande frameworks. Zie SSH-sleutels versus SSH-certificaten en Transformeer statische SSH-sleutels in tijdelijke workload-identiteiten. voor implementatiebegeleiding.

Toegangsbeleid en vereisten voor auditbewijs

Auditors vragen om specifieke bewijsstukken. Configureer het SSH-sleutelbeheer zodanig dat deze worden gegenereerd voordat de beoordeling begint.

• Huidige inventaris van SSH-sleutels: Een lijst met alle sleutels, hun vingerafdruk, eigenaar, implementatieservers, toegangsomvang, aanmaakdatum, datum van laatste rotatie en datum van laatst waargenomen gebruik.
• Toegang tot beoordelingsgegevens: Gedateerde verslagen van periodieke controles, inclusief welke sleutels zijn gecontroleerd, welke acties zijn ondernomen (ingetrokken, rotatie geactiveerd, eigendom bevestigd) en de identiteit van de beoordelaar.
• Bewijs voor rotatie: Logboeken waaruit blijkt dat sleutels volgens schema of op basis van een gebeurtenis zijn geroteerd, met datums, triggertype en operatoridentiteit.
• Bewijs van intrekking: Registraties van de intrekking van SSH-toegang door vertrokken medewerkers, inclusief de vertrekdatum, de datum waarop de intrekking is voltooid en een bevestiging dat de publieke sleutels van alle geautoriseerde servers zijn verwijderd.
• Sessielogboeken: Geprivilegieerde SSH-sessiegegevens met daarin de sleutelvingerafdruk, het bron-IP-adres, de tijdstempel en het doelsysteem, bewaard gedurende de periode die vereist is door het toepasselijke framework.
• Beleidsdocumentatie: Het schriftelijke SSH-sleutelbeheerbeleid definieert cryptoperioden, algoritmevereisten, het verbod op gedeelde sleutels, het verbod op hardgecodeerde sleutels en de incidentresponsprocedure voor vermoedelijke sleutelcompromittering.

Incidentresponsplan voor SSH-sleutelcompliance-incidenten

1. Onmiddellijke intrekking: Trek de vermoedelijk gecompromitteerde sleutel in op alle servers waar deze geautoriseerd is; bevestig dat de intrekking is voltooid en registreer het tijdstempel van de voltooiing.
2. Generatie en implementatie van vervangende sleutels: Genereer een nieuw sleutelpaar met behulp van een goedgekeurd algoritme; implementeer de nieuwe publieke sleutel op alle geautoriseerde servers; controleer of de toegang voor de rechtmatige gebruiker is hersteld.
3. Onderzoek naar de blootstellingsomvang: Identificeer alle systemen die de gecompromitteerde sleutel kon bereiken; controleer sessielogboeken op toegang tijdens de periode waarin de inbreuk vermoedelijk heeft plaatsgevonden; bepaal of er ongeautoriseerde activiteiten hebben plaatsgevonden.
4. Kennisgeving aan belanghebbenden: Stel de beveiligingsleiding, de eigenaren van de getroffen systemen en, indien gereguleerde gegevens toegankelijk waren via de gecompromitteerde sleutel, mogelijk ook toezichthouders of betrokken personen op de hoogte volgens de geldende meldingsvoorschriften voor datalekken.
5. Conformiteitsdocumentatie: Documenteer de tijdlijn van het incident, de hoofdoorzaak (hoe de sleutel is blootgesteld), de tijdlijn van de intrekking, de vervanging en de reikwijdte van de toegang. Deze documentatie voldoet aan de bewijsvereisten voor incidentrespons van PCI DSS, HIPAA en ISO 27001.
6. Update van het beleid na het incident: Identificeer welke controle is mislukt (geen inventaris, vertraagde uitdiensttreding, hardgecodeerde sleutel) en werk het SSH-sleutelbeheerbeleid bij om dit probleem op te lossen.

Hoe encryptieconsultancy kan helpen

Strikte naleving van de SSH-sleutelbeheerregels vereist meer dan alleen beleid: het vereist automatisering die het bewijsmateriaal genereert dat auditors verwachten. SSH Secure van Encryption Consulting voldoet aan alle zes compliance-vereisten:

• Gecentraliseerde realtime voorraadadministratie: Zowel agentgebaseerde als agentloze detectie lokaliseert elke SSH-sleutel met eigendoms- en gebruiksgegevens, waarmee wordt voldaan aan de inventarisatie- en eigendomsvereisten van elk framework.
• Op beleid gebaseerde RBAC: Elke sleutel heeft alleen toegang tot de systemen die nodig zijn voor de betreffende functie, waarmee het principe van minimale bevoegdheden wordt nageleefd. Goedkeuringsworkflows genereren de toegangsverantwoording die auditors opvragen.
• Geautomatiseerde rotatie en intrekking: Door beleidsgestuurde rotatie volgens schema en onmiddellijke intrekking bij bepaalde gebeurtenissen (vertrek, inbreuk) wordt het toegangsvenster gesloten. Elke rotatie- en intrekkingsgebeurtenis wordt geregistreerd met datum, type trigger en operatoridentiteit als bewijs van naleving.
• Sessielogging en SIEM-integratie: Alle activiteiten van geprivilegieerde SSH-sessies worden geregistreerd en geïntegreerd met Splunk- of Loki-Grafana-dashboards, waarmee wordt voldaan aan de monitoring- en auditvereisten van PCI DSS, SOC 2 en NIST.
• Tijdelijke en sessiegebonden sleutels: Privésleutels worden beschermd in FIPS 140-3 gevalideerde HSM's; tijdelijke sleutels die voor gevoelige bewerkingen worden uitgegeven, verlopen automatisch, waardoor het probleem van het opruimen volledig wordt geëlimineerd.
• Downloadbare nalevingsrapporten: Auditklare exportbestanden van belangrijke inventarisgegevens, rotatiegeschiedenis, intrekkingsgegevens en sessielogboeken in formaten die geschikt zijn voor beoordeling door de auditor.

Just-in-Time (JIT) SSH-toegang gaat nog een stap verder door alleen inloggegevens te verstrekken wanneer dat nodig is en deze automatisch weer in te trekken. Hierdoor blijft er na afloop van de sessie geen actieve toegang over die misbruikt kan worden.

Conclusie

SSH-sleutels zijn krachtig, stil en gemakkelijk te vergeten. Die combinatie maakt ze tot een compliance-risico. De oplossing is niet ingewikkeld: ken elke sleutel, wijs een eigenaar toe, beperk de toegang, roteer en trek sleutels tijdig in, registreer de sessies en controleer de toegang regelmatig. Voer deze zes stappen consequent uit en de meeste vereisten van PCI DSS, ISO 27001, SOC 2, NIST en CIS vallen op hun plaats. Behandel SSH-sleutels als de geprivilegieerde referenties die ze zijn, en de volgende audit wordt een beoordeling van goed gedocumenteerde controles in plaats van een poging om de toegangsgeschiedenis te reconstrueren. Zie voor meer informatie over dit onderwerp: Een effectief beleid voor het roteren van SSH-sleutels ontwerpen , SSH-sleutels beveiligen met HSM's en SSH-sleutelaudits doorstaan.

Veelgestelde Vragen / FAQ

Wat zijn de vereisten voor naleving van de SSH-sleutelbeheerwetgeving?

Zes beheersmaatregelen voor elke sleutel: inventarisatie (elke sleutel gedocumenteerd met locatie en toegangsomvang), eigendom (elke sleutel gekoppeld aan een specifieke persoon of dienst), minimale bevoegdheden (elke sleutel geeft alleen toegang tot de benodigde systemen), rotatie (volgens schema en onmiddellijk na vertrek of inbreuk), monitoring (elke sessie met bevoegdheden wordt geregistreerd en gecontroleerd) en intrekking (toegang wordt onmiddellijk ingetrokken met gedateerd bewijs).

Welke compliance-frameworks hebben specifiek betrekking op SSH-sleutels?

Geen enkel raamwerk spreekt expliciet over SSH-sleutels. Ze beschrijven de uitkomsten van authenticatiegegevens: PCI DSS v4.0.1 Vereiste 8 (unieke identiteiten, geen gedeelde sleutels, verbod op hardgecodeerde geheimen in Vereiste 8.6.2); ISO 27001:2022 Bijlage A 5.15-5.18, 8.2, 8.24 (identiteitsbeheer, bevoorrechte toegang, cryptografie); SOC 2 CC6.1-CC6.3 (logische toegangscontroles met bewijs); NIST SP 800-53 AC-2, AC-3, IA-5; CIS Controls v8 Controls 5 en 6.

Welke problemen met SSH-sleutels leiden het vaakst tot mislukte audits?

Wees-sleutels (sleutels van voormalige medewerkers die nog steeds actief zijn); gedeelde sleutels (geen controle per gebruiker); hardgecodeerde sleutels in scripts of images (schendt PCI DSS 8.6.2); geen documentatie over sleutelrotatie; geen auditlogboek van sessies; geen inventaris (kan geen sleutellijst op aanvraag genereren). Elk van deze categorieën komt overeen met een specifieke frameworkcontrole.

Hoe vaak moeten SSH-sleutels worden gecontroleerd op naleving van de regels?

PCI DSS-vereiste 7.2.4 vereist toegangsbeoordelingen ten minste elke zes maanden; CIS-controle 5 vereist een beoordeling per kwartaal. Een beoordeling per kwartaal voldoet aan beide vereisten. Ook op gebeurtenissen gebaseerde beoordelingen zijn vereist: vertrek van een medewerker en een vermoedelijke inbreuk vereisen onmiddellijke intrekking, niet pas tijdens de volgende geplande beoordelingscyclus.

Welk bewijsmateriaal moet een organisatie overleggen voor een SSH-sleutelconformiteitsaudit?

Actuele sleutelinventaris; gedateerde toegangsbeoordelingsverslagen met uitgevoerde acties; bewijs van rotatie met datums en triggertype; bewijs van intrekking met vertrekdatum en datum van voltooiing van de intrekking; sessielogboeken met sleutelvingerafdruk, bron-IP-adres, tijdstempel en doel; en schriftelijk SSH-sleutelbeheerbeleid met cryptoperioden en incidentresponsprocedure.

Hoe helpt SSH Secure bij het voldoen aan de vereisten voor SSH-sleutelcompliance?

SSH Secure biedt: realtime inventarisatie met eigendomsgegevens; RBAC-handhaving voor minimale bevoegdheden; geautomatiseerde, op beleid gebaseerde rotatie en door gebeurtenissen geactiveerde intrekking met auditlogboeken; sessielogging met SIEM-integratie; uitgifte van tijdelijke sleutels; en downloadbare compliance-rapporten die klaar zijn voor beoordeling door de auditor. Privésleutels worden beschermd in FIPS 140-3 gevalideerde HSM's.