Wat zijn de beste beveiligingspraktijken voor NDES?

De beste beveiligingspraktijken voor NDES omvatten de configuratie- en operationele controles die de Network Device Enrollment Service (NDES)-rol in Active Directory Certificate Services beschermen. Deze controles hebben betrekking op versleutelde communicatie, het versterken van serviceaccounts, de bescherming van privésleutels en de levenscyclus van certificaatsjablonen, zodat een gecompromitteerde NDES-server niet kan worden gebruikt om willekeurige certificaten aan te vragen.

De Network Device Enrollment Service (NDES) stelt software op netwerkapparaten, zoals routers, firewalls en switches, in staat om digitale certificaten te verkrijgen zonder dat er domeinreferenties hoeven te worden uitgevoerd. NDES is een van de rolservices van Active Directory Certificate Services (AD CS) en implementeert het Simple Certificate Enrollment Protocol (SCEP) , dat de communicatie definieert tussen de registratieautoriteit (RA) en netwerkapparaten tijdens de inschrijving. Omdat NDES zich bevindt op de grens tussen niet-vertrouwde apparaten en een vertrouwde CA, zijn alle maatregelen op deze pagina erop gericht te voorkomen dat deze grens het zwakke punt in de PKI wordt.

Deze handleiding beschrijft wat NDES precies doet, de specifieke beveiligingsmaatregelen die Microsoft en EC aanbevelen, hoe u kunt bepalen welke maatregelen prioriteit moeten krijgen, een overzicht van de voor- en nadelen van de belangrijkste beslissingen, een beslissingsboom en -matrix voor uw omgeving, en hoe NDES-beveiliging past in een breder programma voor certificaatlevenscyclusbeheer.

Key Takeaways

• NDES vormt een brug tussen onbetrouwbare netwerkapparaten en een vertrouwde CA, waardoor alle beveiligingsmaatregelen zijn getroffen om te voorkomen dat een gecompromitteerde NDES-server een toegangspoort wordt tot willekeurige certificaatuitgifte.
• Bescherming van privésleutels is de belangrijkste beveiligingsmaatregel: een HSM zorgt ervoor dat NDES-sleutels niet in het geheugen van het besturingssysteem en niet in onversleutelde VM-snapshots of -backups terechtkomen.
• De scheiding van rollen en de keuze van het serviceaccount (Netwerkservice, gMSA of een beveiligd domeinaccount) bepalen hoeveel handmatig wachtwoord- en toegangsbeheer de NDES-implementatie op de lange termijn vereist.
• NDES moet op een eigen server draaien, nooit samen met de CA, tenzij achter een afgebakende firewallregel, en moet achter een reverse proxy staan ​​wanneer het vanaf internet bereikbaar is.
• Bedrijven die afhankelijk zijn van handmatige, ongedocumenteerde beveiliging van PKI-services meldden in 45% van de gevallen uitval als gevolg van certificaatproblemen in het afgelopen jaar, waarvan 37.5% specifiek werd veroorzaakt door een verlopen certificaat. Dit blijkt uit de Trust Pulse Survey van DigiCert, gepubliceerd op 2 juli 2025. Een NDES-server die niet beveiligd of gemonitord wordt, valt dus duidelijk in deze risicocategorie.

Voor wie zijn de beste beveiligingspraktijken voor NDES relevant?

De impact van NDES-beveiliging is groter dan alleen de persoon die de rol heeft geïnstalleerd. Hieronder lees je wat elk team er concreet aan moet doen.

• PKI-beheerders Beheer de NDES-build, de configuratie van het serviceaccount en de levenscyclus van de certificaatsjabloon. Actie: controleer of de CEP-versleutelings- en Exchange Enrollment Agent-sjablonen niet langer door de CA zijn toegewezen, behalve tijdens de initiële installatie- en verlengingsperioden.
• Beveiligingsarchitecten Beslis hoe de privésleutels van NDES worden opgeslagen en hoe de server wordt geïsoleerd. Actie: verplicht HSM-ondersteunde sleutelopslag voor elke NDES-implementatie die op grote schaal certificaten uitgeeft, niet alleen voor de CA zelf.
• Platform- en identiteitsteams Beheer de reverse proxy, firewallregels en TLS-configuratie vóór NDES. Actie: controleer of de reverse proxy en TLS 1.2+ correct zijn ingesteld voordat een SCEP-registratie met internettoegang (zoals Intune) van start gaat.
• Compliance en GRC Controleer of er bewijsmateriaal is voor de versterking van NDES voor audits. Actie: voeg controles op NDES-serviceaccounts, sjabloontoewijzingen en sleutelopslag toe aan de terugkerende PKI-controlebeoordeling, en niet alleen aan de eigen controles van de CA.
• CISO's Het risico nemen dat een gecompromitteerde NDES-server een pad wordt voor certificaatuitgifte door een aanvaller. Actie: behandel NDES als een Tier 0-component gezien de vertrouwensrelatie met de CA, en niet als een netwerkapparaat met lage prioriteit.

Wat zijn de beste beveiligingspraktijken voor NDES?

De best practices voor NDES-beveiliging zijn de door Microsoft en de branche aanbevolen maatregelen die het aanvalsoppervlak van de Network Device Enrollment Service verkleinen: het versleutelen van administratief verkeer, het beperken van de looptijd van de service, het scheiden van operationele rollen, het beschermen van de privésleutels die worden gebruikt om inschrijvingsverzoeken te ondertekenen en te versleutelen, en het correct afbakenen van de certificaatsjablonen die NDES mag gebruiken. Geen van deze maatregelen werkt op zichzelf; een beveiligd serviceaccount met een onbeveiligde privésleutel vormt nog steeds een kritiek risico, en een door een HSM ondersteunde sleutel zonder rolscheiding maakt de server nog steeds kwetsbaar voor misbruik door iedereen met toegang.

Functies van NDES

NDES vervult drie functies in het certificaatregistratieproces, en bij elk van deze functies is een punt waarop de onderstaande beveiligingsmaatregelen van toepassing zijn:

1. Genereert en verstrekt eenmalige inschrijfwachtwoorden aan beheerders.
2. Dien inschrijvingsverzoeken in bij de Certificate Authority (CA).
3. Haalt geregistreerde certificaten op bij de certificeringsinstantie en stuurt deze door naar het aanvragende netwerkapparaat.

De eigen richtlijnen van Microsoft met betrekking tot deze beheersmaatregelen zijn een nuttige aanvullende referentie: zie het bericht over de beste beveiligingspraktijken voor NDES op de Microsoft Community Hub.

Beveiligingsrichtlijnen voor NDES

Doorloop deze instellingen samen in plaats van afzonderlijk. Elke instelling sluit een andere belichting af, en de meeste NDES-problemen in de praktijk zijn terug te voeren op het overslaan van twee of drie van deze instellingen tegelijk, niet slechts één.

Schakel SSL/TLS in voor de NDES-beheerderssite.

SSL/TLS-beveiliging op de MSCEP_Admin-site zorgt ervoor dat het wachtwoord voor de inschrijvingsuitdaging beschermd is tegen inspectieaanvallen wanneer een beheerder of een netwerkapparaat verbinding maakt. Zonder deze beveiliging zou het eenmalige wachtwoord dat NDES genereert in platte tekst zichtbaar zijn voor iedereen die de verbinding kan onderscheppen.

Gebruik waar nodig apparaatcertificaten met een langere geldigheidsduur.

De standaard IPsec-certificaatsjabloon (Offline Request) heeft een geldigheidsduur van slechts één jaar. Als u aangepaste sjablonen voor ondertekening, versleuteling of algemene certificaten voor apparaten definieert, overweeg dan een versie 2-sjabloon met een geldigheidsduur van twee jaar om de beheerkosten voor het aanvragen van apparaatcertificaten te verlagen. Houd hierbij rekening met de algemene trend in de sector naar kortere geldigheidsduur van certificaten voor alles wat met internet te maken heeft; een langere geldigheidsduur is geschikt voor interne apparaatcertificaten, niet voor alles wat deel uitmaakt van het openbare TLS-ecosysteem.

Schakel de NDES-service uit wanneer deze niet in gebruik is.

Door de NDES-service te stoppen wanneer deze niet actief nodig is, wordt voorkomen dat er gedurende die periode ongeautoriseerde certificaten worden uitgegeven en worden ongebruikte inschrijvingswachtwoorden uit de servicecache verwijderd. Deze maatregel biedt een afweging tussen gebruiksgemak en minder risico, en werkt het beste in omgevingen met geplande, batchgewijze apparaatinschrijvingen in plaats van continue inschrijvingen op aanvraag.

Beveilig de server met de wizard voor beveiligingsconfiguratie

De wizard voor het configureren van Windows-beveiliging analyseert de rollen en services die daadwerkelijk op de NDES-server draaien en adviseert om IIS en alle andere geïnstalleerde services te beveiligen. Voer deze wizard uit nadat de NDES-configuratie is voltooid en herhaal dit na elke wijziging in de op die server geïnstalleerde rollen.

Rolscheiding implementeren

Bij de installatie, configuratie en bediening van NDES zijn verschillende accounts betrokken, en geen van deze accounts mag qua reikwijdte overlappen:

• Instelaccount, alleen gebruikt tijdens de eerste installatie en het vernieuwen van de sjabloon.
• Apparaatbeheerders, die de dagelijkse registratie van apparaten beheren.
• Het NDES-serviceaccount zelf, dat afhankelijk van de omgeving Network Service, een Group Managed Service Account (gMSA) of een beveiligd domeingebruikersaccount is.

Kies en beveilig het NDES-serviceaccount.

Welk accounttype u ook kiest, pas deze instellingen consequent toe:

• AES-versleuteling is vereist voor gMSA- of domeingebruikersaccounts.
• Configureer aanmeldingsbeperkingen en een lang, niet-hergebruikt wachtwoord voor domeinaccounts.
• Gebruik een gMSA- of domeingebruikersaccount niet opnieuw op een andere computer of voor enig ander doel.
• Schakel het selectievakje 'Account is gevoelig en kan niet worden gedelegeerd' in voor domeingebruikersaccounts.
• Bij gebruik van een gMSA of een aangepaste certificaatsjabloon moet u de machtigingen voor de privésleutels van de NDES-certificaten handmatig instellen, aangezien deze machtigingen niet altijd automatisch worden ingesteld.

Versterk het onderliggende systeem

Beperk de lokale beheerdersgroep op de NDES-server tot alleen PKI-beheerders. Alleen leden van deze groep mogen aanmeldrechten hebben op de server, zowel voor interactieve toegang, toegang op afstand, aanmelden als batchtaak als aanmelden als service. Alle andere accounts mogen geen aanmeldrechten hebben op de NDES-server.

Beveilig de privésleutels met een HSM.

Sleutelbeveiliging is de meest impactvolle beveiligingsmaatregel in deze lijst, omdat een gecompromitteerde NDES-privésleutel een aanvaller in staat stelt een geldig certificaat aan te vragen om in te loggen op Active Directory als een willekeurige gebruiker.

• Gebruik een Hardwarebeveiligingsmodule (HSM) Een HSM (Hardware Security Module) genereert, bewaart en beheert de toegang tot NDES-sleutels. Een HSM zorgt ervoor dat NDES-sleutels nooit in het geheugen van het besturingssysteem worden opgeslagen, voegt operationele controles toe en beperkt de blootstelling aan het sleutelmateriaal zelf.
• Als NDES gevirtualiseerd is, gebruik dan hoe dan ook een HSM om de privésleutels op te slaan, aangezien beheerders van de virtualisatiehost met toegang tot de VM, schijf of het geheugen de sleutels anders in onversleutelde vorm kunnen achterhalen.
• Als er geen HSM in gebruik is, versleutel dan back-ups en beperk de toegang daartoe streng, aangezien snapshots, checkpoints en andere back-uptypen doorgaans de privésleutels van NDES onversleuteld bevatten.

Isoleer NDES binnen uw infrastructuur.

• Wanneer u NDES toegang tot internet verleent, bijvoorbeeld om certificaten te registreren op mobiele apparaten die door Intune worden beheerd, beveilig dit dan met een reverse proxy zoals Azure AD Application Proxy of Web Application Proxy (WAP). Stel NDES nooit rechtstreeks bloot aan het internet.
• Installeer NDES op een andere computer dan de computer waarop de CA draait, en voer geen andere services uit op de NDES-server zelf.
• Als NDES op dezelfde computer als de CA moet worden geïnstalleerd, configureer dan de firewallregel voor het Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) zodanig dat alleen het IP-adres van NDES (en OCSP) de CA kan bereiken voor inschrijving.

Beheer CA- en certificaatsjablonen correct.

NDES maakt gebruik van een kleine set certificaatsjablonen, elk met een specifiek doel, en elk vereist zijn eigen machtigings- en levenscyclusbeheer.

CEP-versleuteling en Exchange-inschrijvingsagentsjablonen

CEP-versleuteling: een certificaat op basis van deze sjabloon wordt tijdens de serviceconfiguratie aan de NDES-computer verstrekt en past SCEP-specifieke versleuteling toe op de communicatie met de aanvragende client. Exchange Enrollment Agent (offline aanvraag): een certificaat op basis van deze sjabloon wordt ook tijdens de configuratie verstrekt en NDES gebruikt dit om de inschrijvingsaanvraag die van het apparaat of MDM is ontvangen digitaal opnieuw te ondertekenen voordat deze naar de uitgevende CA wordt doorgestuurd. Beide sjablonen zijn alleen nodig tijdens de eerste NDES-installatie en bij het verlengen van het certificaat voordat het verloopt; verwijder ze van de CA tijdens normaal gebruik en verleen de machtigingen voor het instellen van accountinschrijvingen op deze sjablonen alleen gedurende de configuratieperiode.

IPSec (offline verzoek) / SCEP-certificaatsjabloon

Deze sjabloon, ook wel bekend als de 'Apparaatsjabloon' of 'SCEP-certificaatsjabloon', wordt gebruikt voor het registreren van apparaat- of gebruikerscertificaten en wordt automatisch toegewezen aan de CA tijdens de NDES-configuratie. De meeste implementaties vervangen deze door een aangepaste sjabloon die beter aansluit op hun behoeften. Verleen registratierechten voor deze sjabloon aan de rol Apparaatbeheerder en het NDES-serviceaccount, en aan niemand anders.

Schakel encryptie van gegevens tijdens overdracht in (TLS 1.2+)

TLS moet elke communicatie tussen NDES en de MDM of het apparaat dat het certificaat aanvraagt, versleutelen. Dit houdt in dat TLS moet worden afgedwongen door de HTTP-listener van IIS volledig uit te schakelen en de naleving van TLS 1.2 in de gehele stack te bevestigen, niet alleen op de NDES-site zelf.

Selectiecriteria: Welke werkwijzen moeten als eerste prioriteit krijgen?

Niet elke omgeving kan alle elf beheersmaatregelen direct implementeren. Geef prioriteit in deze volgorde wanneer tijd of middelen beperkt zijn:

1. Beveiliging van de privésleutel (opslag met HSM-ondersteuning) heeft prioriteit, aangezien dit de beveiligingsmaatregel is met de grootste impact als deze wordt overgeslagen.
2. Versleuteling van gegevens tijdens transport (TLS 1.2+) is de tweede beste optie, omdat het weinig moeite kost en het risico op passieve onderschepping direct wegneemt.
3. Infrastructuurisolatie (aparte server, reverse proxy indien toegankelijk via internet) is ten derde belangrijk, omdat het de mogelijkheden van een aanvaller beperkt, zelfs als een andere beveiligingsmaatregel faalt.
4. Rolseparatie en het versterken van serviceaccounts staan ​​op de vierde plaats, omdat verkeerd geconfigureerde accounts de meest voorkomende manier zijn waarop de andere controles worden omzeild.
5. De levenscyclus van certificaatsjablonen en de beveiliging van systemen komen als laatste aan bod, omdat ze het resterende risico verkleinen zodra de belangrijkste beheersmaatregelen al zijn geïmplementeerd.

Voordelen en nadelen van belangrijke NDES-beveiligingsmaatregelen

Controleer:	VOORDELEN	NADELEN
HSM-ondersteunde opslag van privésleutels	Sleutels verlaten nooit een hardwarematige vertrouwensgrens; voldoet aan de meeste compliance-eisen voor sleutelbeveiliging.	Verhoogde kosten en operationele complexiteit; vereist expertise op het gebied van HSM-integratie.
gMSA-serviceaccount	Geen handmatige wachtwoordrotatie nodig; ondersteunt AES; verkleint het risico op diefstal van inloggegevens in vergelijking met een domeinaccount.	Vereist ondersteuning voor AD-schema en -versie; er is nog steeds één gMSA-scoped per NDES-server nodig.
Reverse proxy voor internetgerichte NDES	Houdt NDES zelf buiten het openbare internet; centraliseert authenticatie en TLS-terminatie	Voegt infrastructuur toe die zelf ook patches, monitoring en beveiliging nodig heeft.
Het samenvoegen van NDES met de CA	Minder servers om te bouwen, te patchen en te monitoren.	Vergroot het aanvalsoppervlak van de CA; Microsoft raadt dit af, tenzij achter een afgebakende firewallregel.
NDES uitschakelen wanneer de computer inactief is	Verkleint het weergavevenster; verwijdert ongebruikte wachtwoorden uit de cache.	Onderbreekt scenario's met continue inschrijving, zoals de voortdurende uitgifte van Intune SCEP-nummers.

Beslissingsboom: Welke NDES-beveiligingsmaatregelen zijn van toepassing op uw omgeving?

Gebruik deze boomstructuur om te bepalen welke beheermogelijkheden niet onderhandelbaar zijn voor uw specifieke implementatie:

• Is NDES bereikbaar via internet (bijvoorbeeld voor Intune SCEP-inschrijving)?
  • Ja: plaats een reverse proxy (Azure AD Application Proxy of WAP) vóór NDES en controleer of TLS 1.2 of hoger van begin tot eind wordt afgedwongen voordat u toegang inschakelt.
  • Nee: bevestig dat NDES nog steeds geïsoleerd is op een eigen intern segment; 'alleen intern' betekent niet 'onbeperkt'.
• Gebruikt uw organisatie al een HSM voor de uitgevende CA?
  • Ja: gebruik dezelfde HSM om de privésleutels van NDES te beschermen in plaats van de NDES-sleutels in de software op te slaan.
  • Nee: geef prioriteit aan de invoering van HSM voor NDES voordat het aantal SCEP-inschrijvingen wordt uitgebreid, aangezien een groter volume de waarde van de sleutels als doelwit verhoogt.
• Is NDES momenteel geïnstalleerd op dezelfde server als de CA?
  • Ja: migreer NDES indien mogelijk naar een eigen server; als dat op korte termijn niet mogelijk is, configureer dan onmiddellijk de firewallregel CERTSVC-RPC-TCP-IN.
  • Nee: bevestig dat er geen andere, niet-gerelateerde services op de NDES-server zelf draaien.
• Vindt de inschrijving continu plaats (zoals geautomatiseerde, door MDM aangestuurde SCEP-aanvragen) of in geplande batches?
  • Continu: sla de optie "uitschakelen wanneer niet in gebruik" over en vertrouw in plaats daarvan op de andere opties plus actieve monitoring.
  • Batch: schakel de NDES-service uit tussen inschrijvingsperioden om het blootstellingsgebied te verkleinen.

Beslissingsmatrix: Gebruiksscenario, Beveiligingsimpact, Operationele inspanning, Geschiktheid voor automatisering en Eigenaar

Gebruik deze matrix om elke beslissing over de beveiliging van NDES door te sturen naar de juiste verantwoordelijke, met een realistisch beeld van de benodigde inspanning.

Use Case	Beveiligingsimpact	Operationele inspanning	Automatisering Fit	Aanbevolen eigenaar
Openbaar/internettoegankelijk NDES voor MDM-inschrijving	Hoge	Medium	Het beleid voor reverse proxy en TLS kan geautomatiseerd worden.	Platform-/identiteitsteam
NDES is gevestigd op dezelfde locatie als de CA.	Hoge	Laag	Laag, meestal een eenmalige firewallregel en migratiebeslissing.	PKI-beheerder
Opslag van privésleutels (HSM versus software)	kritisch	Medium	De HSM API's ondersteunen scriptgestuurde sleutelbewerkingen.	Beveiligingsarchitect
Selectie van serviceaccount (gMSA versus domeingebruiker)	Medium	Laag	Met gMSA High wordt handmatige wachtwoordrotatie volledig afgeschaft.	PKI-beheerder
Levenscyclus van certificaatsjablonen (CEP/EER-ontbinding)	Medium	Laag	Gemiddeld, kan worden gescript, maar vereist een wijzigingsvenster.	PKI-beheerder
Handhaving van de regelgeving voor gegevensoverdracht (TLS 1.2+)	Hoge	Laag	Hoog, afdwingbaar via IIS en basislijn voor groepsbeleid	Beveiligingsarchitect

Hoe NDES-beveiliging verbinding maakt met certificaatlevenscyclusbeheer

Elk certificaat dat NDES aan een netwerkapparaat uitgeeft, moet nog steeds worden gedetecteerd, bijgehouden en gedurende de rest van zijn levensduur worden vernieuwd. Een beveiligde NDES-server die certificaten uitgeeft aan een niet-bijgehouden certificatenpopulatie, brengt nog steeds hetzelfde uitvalrisico met zich mee. Uit het Trust Pulse Survey van DigiCert, gepubliceerd op 2 juli 2025, bleek dat 45% van de bedrijven het afgelopen jaar te maken heeft gehad met uitval als gevolg van certificaatproblemen. 37.5% van deze incidenten werd specifiek veroorzaakt door een verlopen certificaat. Apparaatcertificaten die via NDES worden uitgegeven, vormen precies het soort certificaatpopulatie met een hoog volume en een groot uit het oog te verliezen, wat dit percentage verklaart.

Platformen voor certificaatlevenscyclusbeheer, zoals CertSecure Manager, bieden inzicht in elk certificaat dat door NDES wordt uitgegeven, niet alleen de certificaten die een beheerder zich herinnert te volgen. Dit overbrugt de kloof tussen "NDES is beveiligd" en "elk uitgegeven certificaat wordt geregistreerd". Als u uw PKI-activiteiten in bredere zin moderniseert, bekijk dan hoe PKI-modernisering en CLM samenwerken en hoe een gecombineerde PKI- en CLM-roadmap rekening houdt met de automatisering van apparaatcertificaten, en niet alleen met server- of gebruikerscertificaten.

NDES-beveiliging in cloud-, hybride- en multi-CA PKI-omgevingen

Hybride omgevingen die de inschrijving van mobiele apparaten via Intune of een andere cloud-MDM laten verlopen, voegen een cloudgerichte laag toe aan wat van oudsher een volledig on-premises service was. Dit is precies de reden waarom de hierboven beschreven reverse proxy- en TLS-controles juist belangrijker zijn in een hybride implementatie. Omgevingen met meerdere certificeringsinstanties (CA's) compliceren de kwestie van certificaatsjablonen: elke CA die NDES kan bereiken, heeft dezelfde sjablooncontext en machtigingsregels nodig, niet alleen de primaire uitgevende CA.

Voor organisaties die NDES en certificaatuitgifte beheren in meerdere omgevingen, centraliseert een PKI-as-a-Service -model de beveiligingsbasislijn, sleutelbescherming en monitoring die anders afzonderlijk op elke NDES-instantie zouden moeten worden gerepliceerd en gecontroleerd.

Succes meten en wat regelmatig te controleren

Een robuuste NDES-implementatie is geen eenmalig project. Controleer deze aspecten regelmatig, niet alleen tijdens de initiële configuratie:

• Of de CEP-versleutelings- en Exchange Enrollment Agent-sjablonen nog steeds niet zijn toegewezen door de CA buiten de configuratie- of verlengingsperioden.
• Of de machtigingen en het wachtwoordbeleid van het NDES-serviceaccount nog steeds overeenkomen met de beoogde beveiligingsbasislijn.
• Of de handhaving van TLS 1.2+ en het uitschakelen van de HTTP-listener nog steeds van kracht zijn na een IIS- of Windows-update.
• Of privésleutels nog steeds gegarandeerd door HSM worden ondersteund, met name na een servermigratie of virtualisatiewijziging, is een belangrijke vraag.
• Of de reverse proxy voor elke internetgerichte NDES-instantie actueel, gepatcht en nog steeds correct geconfigureerd is.

Een cryptografische inventarisatie van activa zoals CBOM Secure breidt de inventarisatie van machine-identiteiten en certificaatdetectie uit voor elk certificaat dat NDES uitgeeft. Dit biedt het auditspoor waarop deze terugkerende controles gebaseerd zijn, in plaats van te vertrouwen op het institutionele geheugen van wat NDES bij de uitrol moest doen.

Op de langere termijn heeft de stemming van het CA/Browser Forum op 11 april 2025, waarin werd besloten de maximale geldigheidsduur van TLS-certificaten te verkorten naar 200 dagen, vervolgens naar 100 dagen en ten slotte naar 47 dagen in 2029, geen directe invloed op interne apparaatcertificaten zoals op openbare TLS-certificaten. Het geeft echter wel aan waar de verwachtingen ten aanzien van de levenscyclus van certificaten in de hele sector naartoe gaan, ook voor apparaattypen zoals die waarvoor NDES-certificaten worden uitgegeven. NIST heeft op 13 augustus 2024 de eerste drie post-kwantumcryptografiestandaarden, FIPS 203, FIPS 204 en FIPS 205, afgerond. Elke organisatie die crypto-flexibiliteit binnen haar PKI wil realiseren, zou NDES-uitgegeven apparaatcertificaten in die planning moeten meenemen, en niet alleen server- en gebruikerscertificaten. Het PQC Center of Excellence van Encryption Consulting en een PQC-gereedheidsbeoordeling zijn de juiste plek om die transitie te plannen.

De visie van Encryption Consulting

Het beveiligen van NDES wordt vaak behandeld als een checklist die eenmalig tijdens de initiële installatie wordt uitgevoerd. De belangrijkste beheersmaatregelen, zoals de bescherming van privésleutels, het beheer van serviceaccounts en de levenscyclus van sjablonen, veranderen echter in de loop der tijd door personeelswisselingen, servermigraties en de toevoeging van nieuwe gebruiksscenario's, zonder dat de oorspronkelijke beveiligingsbasislijn opnieuw wordt bekeken. Beschouw de bovenstaande beslissingsmatrix en selectiecriteria daarom als een terugkerende evaluatie, niet als een eenmalige controle tijdens de implementatie.

Conclusie

Het beveiligen van NDES betekent dat alle bovenstaande controles gezamenlijk moeten worden geïmplementeerd, inclusief TLS-handhaving, het versterken van serviceaccounts, rolscheiding, discipline in de levenscyclus van sjablonen en, bovenal, HSM-ondersteunde bescherming van privésleutels. Een kwaadwillende gebruiker met toegang tot een NDES-privésleutel kan immers een geldig certificaat aanvragen om in te loggen op Active Directory als een willekeurige gebruiker. Gebruik de selectiecriteria, voor- en nadelen, de beslissingsboom en de beslissingsmatrix in deze handleiding om prioriteiten te stellen en verantwoordelijkheid toe te wijzen voor een specifieke omgeving.

Als u hulp nodig heeft bij het beveiligen van uw NDES-implementatie of uw bredere PKI-omgeving, kunt u ons gerust een e-mail sturen naar [email protected].

Veelgestelde Vragen / FAQ

Wat is de belangrijkste conclusie uit 'Wat zijn de beste beveiligingspraktijken voor NDES?'

NDES bevindt zich op de grens tussen onbetrouwbare netwerkapparaten en een vertrouwde CA. Beveiliging ervan betekent daarom het beschermen van de privésleutels, het versleutelen van alle communicatie, het scheiden van operationele rollen en het strikt beperken van certificaatsjablonen. Geen enkele beveiligingsmaatregel is op zichzelf voldoende; de ​​belangrijkste beveiligingsmaatregel is de bescherming van privésleutels door een HSM.

Waarom is dit belangrijk voor PKI-teams binnen bedrijven?

Een gecompromitteerde NDES-server kan worden gebruikt om een ​​geldig certificaat aan te vragen voor het inloggen op Active Directory als een willekeurige gebruiker. Dit maakt NDES een waardevol doelwit, ook al wordt het vaak beschouwd als een netwerkapparaat met lage prioriteit in plaats van een Tier 0-component.

Welke risico's nemen toe als dit onderwerp handmatig wordt behandeld?

Handmatige, ongedocumenteerde NDES-beveiliging betekent dat serviceaccountmachtigingen en TLS-instellingen na updates niet meer kloppen, dat niet-toegewezen certificaatsjablonen opnieuw worden ingeschakeld en vervolgens vergeten, en dat de bescherming van privésleutels na een servermigratie nooit wordt gecontroleerd totdat een incident een herziening afdwingt.

Welke teams zouden verantwoordelijk moeten zijn voor deze verandering?

PKI-beheerders zijn verantwoordelijk voor de NDES-build, het serviceaccount en de template-levenscyclus. Beveiligingsarchitecten beslissen over de opslag van privésleutels en serverisolatie. Platform- en identiteitsteams beheren de reverse proxy- en TLS-configuratie. Compliance- en CISO-afdelingen volgen de NDES-beveiliging als onderdeel van het bredere PKI-risicoprogramma.

Hoe houdt dit verband met certificaatlevenscyclusbeheer?

Elk certificaat dat NDES aan een netwerkapparaat uitgeeft, moet gedurende de volledige levensduur worden gecontroleerd op ontdekking, verlenging en vervaldatum. Hulpmiddelen voor certificaatlevenscyclusbeheer zoals CertSecure Manager breiden deze controle uit naar door NDES uitgegeven apparaatcertificaten, in plaats van te stoppen bij server- en gebruikerscertificaten.

Hoe moeten organisaties succes meten?

Succes houdt in dat de sleutelopslag geverifieerd is door een HSM, dat het serviceaccount nog steeds voldoet aan de beoogde beveiligingsnormen, dat de handhaving van TLS 1.2+ na elke update wordt bevestigd, dat certificaatsjablonen correct worden ontkoppeld buiten configuratievensters en dat er een actuele reverse proxy is voor elke instantie die met internet verbonden is.

Wat moet er regelmatig gecontroleerd of gemonitord worden?

Controleer de toewijzing van certificaatsjablonen, de machtigingen en het wachtwoordbeleid van serviceaccounts, de configuratie van TLS- en HTTP-listeners, de opslaglocatie van privésleutels en de patch- en configuratiestatus van elke reverse proxy die voor NDES staat.

Welke invloed heeft dit onderwerp op cloud-, hybride- of multi-CA PKI-oplossingen?

Hybride implementaties die de inschrijving via een cloud-MDM laten verlopen, voegen een cloudgerichte rand toe waardoor reverse proxy- en TLS-controles juist belangrijker worden. In omgevingen met meerdere certificeringsinstanties (CA's) moeten dezelfde sjablonen voor certificaten en dezelfde toegangsrechten worden toegepast op elke CA die NDES kan bereiken, niet alleen op de primaire uitgevende CA.

Welke veelgemaakte fouten moeten teams vermijden?

Vermijd het toewijzen van CEP-encryptie- en Exchange Enrollment Agent-sjablonen aan de CA buiten de installatieprocedure, het samenvoegen van NDES met de CA zonder een firewallregel die daarop van toepassing is, het opslaan van privésleutels in software wanneer een HSM beschikbaar is, het rechtstreeks blootstellen van NDES aan internet zonder een reverse proxy en het hergebruiken van een serviceaccount voor andere systemen.

Wat moet er elk kwartaal vernieuwd worden?

Deze handleiding is een stabiele, altijd actuele uitleg, waardoor de inhoud elke zes maanden volledig wordt vernieuwd in plaats van elk kwartaal. Tussen de vernieuwingen door is een kwartaalupdate nog steeds de juiste frequentie om de operationele details te controleren die regelmatig veranderen: machtigingen voor serviceaccounts, toewijzing van certificaatsjablonen, TLS-configuratie en de patchstatus van de reverse proxy.