NDES en SCEP uitgelegd: De ruggengraat van geautomatiseerde certificaatinschrijving

Naarmate organisaties de implementatie van Zero Trust, apparaatauthenticatie en cloud-beheerde infrastructuur versnellen, worden traditionele handmatige methoden overbodig. certificaat Het inschrijven van certificaten is niet langer schaalbaar. Of het nu gaat om het onboarden van duizenden laptops via Intune, het uitgeven van certificaten voor VPN-toegang of het inschakelen van wifi-authenticatie in wereldwijde vestigingen, geautomatiseerde certificaatinschrijving is essentieel.

Dit is waar SCEP (Simple Certificate Enrollment Protocol) en NDES (Netwerkapparaatinschrijvingsservice) spelen een cruciale rol in de PKI-ecosystemen van Microsoft.

Ondanks hun belang implementeren veel beheerders ze zonder volledig te begrijpen hoe ze werken, waarin ze verschillen of hoe ze correct beveiligd moeten worden. Verkeerd geconfigureerde NDES-servers blijven een van de meest voorkomende problemen. PKI zwakke punten die tijdens beveiligingsaudits aan het licht zijn gekomen.

In dit artikel zullen we het volgende bespreken:

• Wat SCEP is en waarom het nog steeds belangrijk is.
• Hoe NDES werkt in Microsoft PKI
• Praktische implementatiescenario's
• Veelvoorkomende fouten en veiligheidsrisico's
• Beste werkwijzen voor moderne bedrijfsomgevingen

Wat is SCEP?

SCEP, oftewel Simple Certificate Enrollment ProtocolDit protocol is oorspronkelijk ontwikkeld door Cisco om de certificaatregistratie te automatiseren voor netwerkapparaten die niet eenvoudig lid kunnen worden van Active Directory.

In tegenstelling tot traditionele AD-gebaseerde registratiemethoden, maakt SCEP het voor apparaten mogelijk om:

• Certificaten aanvragen via HTTP/HTTPS
• Authenticeer met behulp van een gedeeld geheim of een uitdaging.
• Automatisch ondertekende certificaten ophalen

SCEP is ontworpen voor apparaten zoals:

• Routers en schakelaars
• VPN-gateways
• Netwerkapparaten
• IoT-apparaten
• Mobiele toestellen

In de loop der tijd is het uitgegroeid tot de de facto standaard voor certificaatregistratie in platformen voor apparaatbeheer, waaronder Microsoft Intune en veel MDM-oplossingen.

Wat is NDES?

NDES (Netwerkapparaatinschrijvingsservice) Dit is Microsofts implementatie van SCEP.

Het fungeert als een brug tussen apparaten en de Microsoft Certification Authority, waardoor apparaten die niet via Active Directory kunnen authenticeren toch op een veilige manier certificaten kunnen verkrijgen.

Simpel gezegd werkt het als volgt:

1. Apparaten communiceren met NDES via SCEP.
2. NDES valideert het verzoek.
3. NDES dient het verzoek in bij Microsoft CA.
4. Het CA-certificaat is afgegeven.
5. NDES stuurt het terug naar het apparaat.

Zonder NDES kan SCEP niet worden gebruikt met Microsoft ADCS.

Waarom is NDES nog steeds belangrijk in moderne PKI?

Sommige beheerders denken dat SCEP verouderd is omdat het decennia geleden is ontwikkeld. Het tegendeel is echter waar; het gebruik van SCEP is enorm toegenomen dankzij moderne trends in apparaatbeheer.

Laten we eens kijken naar een paar voorbeelden van toepassingen waarin NDES veelvuldig wordt gebruikt:

1. Microsoft Intune-apparaatcertificaatregistratie

Organisaties die Intune implementeren, vertrouwen vaak op NDES voor het uitgeven van authenticatiecertificaten voor apparaten, wifi-certificaten, VPN-certificaten, e-mailcertificaten, enzovoort.

Zonder NDES kan Intune geen certificaten uitgeven vanuit on-premises ADCS..

2. Clientauthenticatiecertificaten

NDES wordt vaak gebruikt voor het uitgeven van clientauthenticatiecertificaten voor Windows Always-On VPN, VPN-clients van derden, hybride architecturen voor toegang op afstand, enzovoort.

Dit maakt VPN-authenticatie zonder wachtwoord mogelijk, gekoppeld aan de apparaatidentiteit.

3. IoT- en netwerkapparaatregistratie

NDES maakt het mogelijk om certificaten uit te geven aan printers, camera's, productiesystemen en netwerkapparaten.

Deze apparaten kunnen vaak geen verbinding maken met Active Directory, waardoor SCEP de enige schaalbare optie is.

Hoe NDES werkt: Architectuuroverzicht

Een typische NDES-implementatie bestaat uit vier componenten:

1. Het aanvragende apparaat (MDM-beheerd of netwerkapparaat)
2. De NDES-server
3. De Microsoft Certificeringsautoriteit (CA)
4. De certificaatsjabloon is geconfigureerd voor SCEP.

Het proces werkt als volgt:

Stap 1: Aanvraag tot registratie door het apparaat: Het apparaat neemt via SCEP contact op met het NDES-eindpunt.

Stap 2: NDES geeft een uitdagingswachtwoord uit: NDES genereert een eenmalig wachtwoord dat wordt gebruikt om het verzoek te valideren.

Stap 3: Apparaat dient certificaatverzoek in: Het apparaat dient zijn certificaatverzoek samen met de uitdaging in.

Stap 4: NDES dient de aanvraag in bij de CA: NDES stuurt de aanvraag door naar de Microsoft CA met behulp van een daarvoor bestemd sjabloon.

Stap 5: Certificaat wordt afgegeven: De certificeringsinstantie ondertekent het certificaat en stuurt het terug naar NDES.

Stap 6: Apparaat ontvangt certificaat: Het certificaat wordt teruggestuurd naar het aanvragende apparaat.

Veelvoorkomende NDES-configuratiefouten die tijdens beveiligingsbeoordelingen worden aangetroffen

Tijdens mijn ervaring met PKI-assessments kom ik een aantal terugkerende problemen tegen. Laten we er vandaag een paar bespreken.

1. NDES rechtstreeks toegankelijk via internet: NDES-eindpunten draaien vaak op IIS en kunnen extern worden gepubliceerd zonder bescherming. Dit stelt aanvallers in staat om certificaten te verkrijgen, sjablonen te achterhalen en IIS-kwetsbaarheden te misbruiken. NDES moet daarom altijd worden beschermd door applicatiegateways en op rollen gebaseerde toegangsregels.
2. Serviceaccounts met te veel privilegesNDES gebruikt een serviceaccount om certificaten aan te vragen bij de certificeringsinstantie (CA). Als dit account te veel machtigingen heeft, kunnen aanvallers zelf certificaten uitgeven. Dit risico is bijzonder groot, omdat certificaten gebruikt kunnen worden voor authenticatie.
3. Zwakke sjabloonconfiguratie: Sjablonen die voor SCEP worden gebruikt, zijn soms zo geconfigureerd dat ze exporteerbare privésleutels toestaan, te ruime gebruiksrechten verlenen en certificaten uitgeven zonder goedkeuringscontroles. Deze verkeerde configuraties kunnen leiden tot identiteitsfraude.
4. Gebrek aan monitoring en registratie: Veel organisaties implementeren NDES, maar monitoren het nooit. Zonder adequate monitoring en logging blijft de uitgifte van frauduleuze certificaten onopgemerkt, kan misbruik bij de inschrijving niet worden gedetecteerd en wordt incidentrespons lastig.

Beveiligingsrichtlijnen voor NDES-implementaties

Om NDES in moderne omgevingen te beveiligen, dienen organisaties een aantal best practices te volgen.

1. Isoleer NDES-servers

NDES mag nooit rechtstreeks op de CA worden geïnstalleerd.

Implementeer het in plaats daarvan:

• In een speciaal DMZ-segment
• Achter een reverse proxy of applicatiegateway
• Vanwege de beperkte netwerktoegang tot de CA

2. Beperk de sjabloonrechten

SCEP-sjablonen moeten:

• Sta alleen de vereiste EKU's toe.
• Beperk de opmaak van onderwerpnamen.
• Schakel het exporteren van privésleutels uit wanneer mogelijk.

3. Toezicht houden op de uitgifte van certificaten

Organisaties moeten:

• SCEP-verzoeken registreren
• Gebruik van sjablonen monitoren
• Waarschuwing voor abnormaal hoge inschrijvingsaantallen

Dit is met name belangrijk voor sjablonen met hoge privileges.

4. IIS-configuratie beveiligen

Omdat NDES op IIS draait, is het belangrijk om het volgende te weten:

• Schakel ongebruikte modules uit
• afdwingen TLS 1.2 of hoger
• Beveiligingsheaders toepassen
• Update de server regelmatig.

Voor meer informatie over de beste beveiligingspraktijken voor de implementatie van NDES, raadpleeg het blogbericht: NDES-beveiligingsbest practices

Waar SCEP en NDES beperkingen beginnen te vertonen

Ondanks hun wijdverbreide toepassing waren SCEP en NDES oorspronkelijk niet ontworpen voor de huidige cloudomgevingen.

Bij moderne implementaties doen zich vaak verschillende uitdagingen voor:

Beperkte beveiligingscontext

SCEP is ontworpen met eenvoud in gedachten, wat betekent dat het beperkte mogelijkheden biedt voor identiteitsvalidatie. Vaak moeten er extra controles worden toegevoegd om een ​​sterke apparaatauthenticatie te garanderen.

Operationele complexiteit

Voor NDES-implementaties zijn de volgende vereisten nodig:

• Dedicated servers
• IIS-beveiliging
• Overwegingen met betrekking tot netwerkblootstelling
• Sjabloonconfiguratiebeheer
• Dit brengt extra operationele kosten met zich mee, vooral in hybride of multi-cloudomgevingen.
• Uitdagingen schalen

Hoewel SCEP goed werkt voor eindapparaten, is het minder geschikt voor dynamische workloads zoals containers, microservices of tijdelijke cloud-instanties. Deze moderne workloads vereisen snellere certificaatuitgiftecycli en sterkere mechanismen voor identiteitsverificatie.

Het moderne framework voor certificeringsautomatisering: ACME

ACMEAutomated Certificate Management Environment (ACM) werd ontwikkeld om volledig geautomatiseerde certificaatbeheeromgevingen mogelijk te maken. Beheer van de levenscyclus van certificaten met minimale menselijke tussenkomst.

In tegenstelling tot SCEP is ACME ontwikkeld voor moderne omgevingen en ondersteunt het:

• Geautomatiseerde certificaatuitgifte
• Automatische verlenging
• API-gestuurde workflows
• Identiteitsverificatiemechanismen

ACME wordt veel gebruikt voor openbare doeleinden. TLS-certificatenMaar bedrijven nemen het steeds vaker intern in gebruik voor het identificeren van workloads.

Dit maakt het bijzonder waardevol voor:

• DevOps pijpleidingen
• Kubernetes-clusters
• Cloud-native services
• Service-to-service-authenticatie

De steun van ACME voor kortlopende certificaten sluit goed aan bij de Zero Trust-principes.

Een vergelijking tussen SCEP, NDES en ACME in Enterprise PKI.

Elke technologie dient een ander doel. SCEP biedt een eenvoudig inschrijvingsprotocol dat geschikt is voor eindapparaten. NDES maakt het mogelijk voor Microsoft PKI-omgevingen om SCEP-gebaseerde inschrijving te ondersteunen. ACME introduceert moderne automatiseringsmogelijkheden die zijn afgestemd op dynamische infrastructuren. Organisaties gebruiken ze vaak samen in plaats van er slechts één te kiezen. Bijvoorbeeld:

• SCEP/NDES voor apparaatcertificaten
• ACME voor server- en workloadcertificaten
• Traditionele AD-registratie voor systemen die lid zijn van een domein.

Deze gelaagde aanpak stelt bedrijven in staat om geleidelijk te moderniseren zonder de bestaande infrastructuur te verstoren.

Praktisch voorbeeld: hybride bedrijfsimplementatie

Neem bijvoorbeeld een onderneming die Zero Trust implementeert en tegelijkertijd naar de cloud migreert.

Ze zouden van plan kunnen zijn om het volgende in te zetten:

• NDES is geïntegreerd met Intune voor het beheer van apparaatcertificaten.
• ACME-gebaseerde uitgifte voor containerworkloads
• ADCS-automatische inschrijving voor interne servers

Dit hybride model stelt hen in staat om compatibiliteit met bestaande systemen te behouden en tegelijkertijd het beheer van de certificaatlevenscyclus te moderniseren.

Het vermindert ook de afhankelijkheid van wachtwoorden en versterkt de op identiteit gebaseerde toegangscontrole in de hele omgeving.

Hoe kies je de juiste inschrijfmethode?

De juiste aanpak hangt af van het type identiteiten dat u beheert.

Als uw focus ligt op eindgebruikersapparaten of netwerkapparatuur, blijft SCEP met NDES een praktische en breed ondersteunde oplossing.

Als uw focus ligt op moderne workloads of omgevingen met veel automatisering, biedt ACME een sterkere integratie en schaalbaarheid.

De meeste bedrijven zullen beide nodig hebben tijdens hun overgang naar cloud-native beveiligingsmodellen.

Inschrijving voor het certificaatprogramma 'De toekomst van ondernemerschap'

Authenticatie op basis van certificaten wordt in hoog tempo het standaardmechanisme voor het beveiligen van bedrijfsomgevingen. Naarmate organisaties overstappen op:

• Wachtwoordloze authenticatie
• Handhaving van apparaatidentiteit
• Zero Trust-toegangsmodellen
• Cloud-native architectuur

Certificaatautomatisering wordt een kernonderdeel van de beveiliging in plaats van een nichefunctie van de PKI.

SCEP en NDES zullen waarschijnlijk in gebruik blijven voor apparaatregistratie, terwijl de adoptie van ACME blijft groeien voor workload-identiteiten en infrastructuurautomatisering.

De grootste uitdaging voor beveiligingsteams is niet het kiezen van het ene protocol boven het andere, maar het ontwerpen van een PKI-strategie die ze op een samenhangende manier integreert.

Hoe kan Encryption Consulting helpen?

Encryption Consulting heeft uitgebreide ervaring met het leveren van end-to-end oplossingen. PKI-oplossingen voor zakelijke en overheidsklanten. We bieden zowel professionele diensten als ons automatiseringsplatform (CertSecure Manager) om ervoor te zorgen dat uw PKI veilig, veerkrachtig en klaar voor de toekomst is.

PKI-diensten

Complete advies-, ontwerp- en implementatiediensten om organisaties te helpen bij het bouwen, moderniseren en beheren van veilige Public Key Infrastructure-omgevingen.

Project planning

We beoordelen uw cryptografische omgeving, bekijken PKI-configuraties, afhankelijkheden en vereisten, en bundelen de bevindingen in een gestructureerd, door de klant goedgekeurd projectplan.

CP/CPS-ontwikkeling

In de volgende fase ontwikkelen we een certificeringsbeleid (CP) en een certificeringspraktijkverklaring (CPS) die aansluiten op RFC#3647. Deze documenten worden aangepast aan de wettelijke, beveiligings- en operationele eisen van uw organisatie.

PKI-ontwerp en -implementatie

Wij ontwerpen en implementeren robuuste PKI-infrastructuren., inclusief offline Root CA's, uitgevende CA's, NDES-servers, HSM-integratie, enz., afhankelijk van De behoeften van de klant staan ​​centraal. De oplevering omvat een PKI-ontwerpdocument, bouwhandleidingen, scripts voor de ceremonie en systeemconfiguraties. Na de implementatie voeren we grondige tests, validatie, finetuning en kennisoverdrachtsessies uit om uw team te ondersteunen.

Bedrijfscontinuïteit en Rampherstel

Na de implementatie ontwikkelen en implementeren we strategieën voor bedrijfscontinuïteit en noodherstel, voeren we failover-tests uit en documenteren we operationele workflows voor de gehele PKI- en HSM-infrastructuur, ondersteund door een uitgebreide handleiding voor PKI-beheer.

Doorlopende ondersteuning en onderhoud (optioneel)

Na de implementatie bieden we een jaarlijks ondersteuningspakket op abonnementsbasis aan dat uitgebreide dekking biedt voor PKI-, CLM- en HSM-componenten. Dit omvat incidentafhandeling, probleemoplossing, systeemoptimalisatie, certificaatlevenscyclusbeheer, CP/CPS-updates, sleutelarchivering, HSM-firmware-upgrades, auditregistratie en patchbeheer.

Met deze aanpak bent u ervan verzekerd dat uw PKI-infrastructuur niet alleen veilig en conform is, maar ook schaalbaar, veerkrachtig en volledig afgestemd op uw operationele en wettelijke doelstellingen op de lange termijn. 

CertSecure Manager 

CertSecure Manager Encryption Consulting biedt een oplossing voor het beheer van de levenscyclus van certificaten. Deze oplossing vereenvoudigt en automatiseert de volledige levenscyclus, zodat u zich kunt richten op beveiliging in plaats van op vernieuwingen.

Automatisering voor kortstondige certificaten: Nu ACME- en 90-dagen/47-dagen TLS-certificaten de standaard zijn geworden, is handmatige verlenging geen praktische optie meer. CertSecure Manager automatiseert de registratie, verlenging en implementatie, zodat certificaten nooit ongemerkt verlopen.

Naadloze DevOps- en cloudintegratie: certificaten kunnen rechtstreeks in webservers en cloud-instanties worden geïnstalleerd en integreren met moderne logboekregistratietools zoals Datadog en Splunk, ITSM-tools zoals ServiceNow en DevOps-tools zoals Terraform en Ansible.

Ondersteuning voor meerdere CA's: Veel organisaties gebruiken meerdere CA's (interne Microsoft CA, openbare CA's zoals DigiCert en GlobalSign, enz.). CertSecure Manager integreert deze bronnen en biedt één overzichtelijk dashboard voor uitgifte en levenscyclusbeheer.

Uniform uitgifte- en verlengingsbeleid: CertSecure Manager handhaaft de sleutelgroottes, algoritmen en verlengingsregels van uw organisatie consistent voor alle certificaten. Dit automatiseert niet alleen verlengingen bij meerdere CA's, maar zorgt er ook voor dat elk certificaat te allen tijde aan uw beveiligingsnormen voldoet.

Proactieve monitoring en verlengingstesten: Continue monitoring, gecombineerd met gesimuleerde verlengings-/vervaltesten, zorgt ervoor dat u risico's identificeert voordat certificaten de productiesystemen beïnvloeden.

Gecentraliseerd inzicht en naleving: één overzichtelijk dashboard toont alle certificaten, sleutellengtes, sterke en zwakke algoritmen en hun vervaldatums. Auditlogboeken en beleidshandhaving vereenvoudigen de naleving. PCI DSS, HIPAAen andere raamwerken.

Als u zich nog steeds afvraagt ​​waar en hoe u moet beginnen met het beveiligen van uw PKI, staat Encryption Consulting voor u klaar om u te ondersteunen met zijn PKI-ondersteuningsdienstenU kunt op ons rekenen als uw betrouwbare partner. Wij begeleiden u bij elke stap met helderheid, vertrouwen en praktische expertise.  

Conclusie

Enterprise PKI evolueert van een beveiligingstool aan de achterkant naar een centrale identiteitsinfrastructuur.

Inzicht in de interactie tussen SCEP, NDES en ACME stelt organisaties in staat schaalbare certificaatbeheersystemen te bouwen die zowel legacy-omgevingen als moderne cloudworkloads ondersteunen.

Door traditionele PKI-principes te combineren met moderne automatiseringsframeworks kunnen bedrijven overstappen op een sterkere identiteitsgestuurde beveiliging zonder in te boeten aan operationele efficiëntie.