NDES och SCEP förklarade: Ryggraden i automatiserad certifikatregistrering

I takt med att organisationer accelererar införandet av Zero Trust, enhetsautentisering och molnhanterad infrastruktur, traditionell manuell certifikat Registrering är inte längre skalbar. Oavsett om det gäller att installera tusentals bärbara datorer via Intune, utfärda certifikat för VPN-åtkomst eller aktivera Wi-Fi-autentisering över globala kontor, är automatiserad certifikatregistrering avgörande.

Det är här SCEP (Enkelt certifikatregistreringsprotokoll) och NDES (registreringstjänst för nätverksenheter) spelar en avgörande roll i Microsofts PKI-ekosystem.

Trots deras betydelse distribuerar många administratörer dem utan att helt förstå hur de fungerar, hur de skiljer sig åt eller hur man säkrar dem ordentligt. Felkonfigurerade NDES-servrar är fortfarande en av de vanligaste PKI svagheter som upptäckts under säkerhetsrevisioner.

I den här artikeln kommer vi att bryta ner:

• Vad SCEP är och varför det fortfarande är viktigt
• Hur NDES fungerar i Microsoft PKI
• Verkliga driftsättningsscenarier
• Vanliga misstag och säkerhetsrisker
• Bästa praxis för moderna företagsmiljöer

Vad är SCEP?

SCEP, eller Simple Certificate Enrollment Protocol, är ett protokoll som ursprungligen utvecklades av Cisco för att automatisera certifikatregistrering för nätverksenheter som inte enkelt kan ansluta till Active Directory.

Till skillnad från traditionella AD-baserade registreringsmetoder tillåter SCEP enheter att:

• Begär certifikat med HTTP/HTTPS
• Autentisera med hjälp av en delad hemlighet eller utmaning
• Hämta signerade certifikat automatiskt

SCEP utformades för enheter som:

• Router och switchar
• VPN-gateways
• Nätverksapparater
• IoT-enheter
• Mobil enheter

Med tiden har det utvecklats till de facto-standarden för certifikatregistrering i enhetshanteringsplattformar, inklusive Microsoft Intune och många MDM-lösningar.

Vad är NDES?

NDES (registreringstjänst för nätverksenheter) är Microsofts implementering av SCEP.

Den fungerar som en brygga mellan enheter och Microsofts certifieringsutfärdare, vilket gör att enheter som inte kan autentisera via Active Directory fortfarande kan hämta certifikat på ett säkert sätt.

Enkelt uttryckt fungerar det så här:

1. Enheter kommunicerar med NDES med hjälp av SCEP
2. NDES validerar begäran
3. NDES skickar begäran till Microsoft CA
4. CA utfärdade certifikatet
5. NDES levererar den tillbaka till enheten

Utan NDES kan SCEP inte användas med Microsoft ADCS.

Varför är NDES fortfarande viktigt i modern PKI?

Vissa administratörer antar att SCEP är föråldrat eftersom det skapades för årtionden sedan. Men det motsatta är sant; SCEP-användningen har ökat dramatiskt på grund av moderna trender inom enhetshantering.

Låt oss titta på ett par användningsfall där NDES används flitigt:

1. Registrering av Microsoft Intune-enhetscertifikat

Organisationer som distribuerar Intune förlitar sig ofta på NDES för att utfärda enhetsautentiseringscertifikat, Wi-Fi-certifikat, VPN-certifikat, e-postautentiseringscertifikat etc.

Utan NDES kan Intune inte utfärda certifikat från lokala ADCS.

2. Klientautentiseringscertifikat

NDES används ofta för att utfärda klientautentiseringscertifikat för Windows Always-On VPN, VPN-klienter från tredje part, hybrid-fjärråtkomstarkitekturer etc.

Detta möjliggör lösenordsfri VPN-autentisering kopplad till enhetsidentitet.

3. Registrering av IoT och nätverksenheter

NDES tillåter utfärdande av certifikat till skrivare, kameror, tillverkningssystem och nätverksenheter

Dessa enheter kan ofta inte ansluta till AD, vilket gör SCEP till det enda skalbara alternativet.

Hur NDES fungerar: Arkitekturöversikt

En typisk NDES-distribution innefattar fyra komponenter:

1. Den begärande enheten (MDM-hanterad eller nätverksenhet)
2. NDES-servern
3. Microsoft Certifieringsutfärdare (CA)
4. Certifikatmallen är konfigurerad för SCEP

Processen fungerar enligt följande:

Steg 1: Registrering av enhetsbegäranden: Enheten kontaktar NDES-slutpunkten med hjälp av SCEP.

Steg 2: NDES utfärdar ett utmaningslösenord: NDES genererar ett engångslösenord som används för att validera begäran.

Steg 3: Enheten skickar in certifikatbegäran: Enheten skickar in sin certifikatbegäran tillsammans med utmaningen.

Steg 4: NDES skickar till CA: NDES vidarebefordrar begäran till Microsoft CA med hjälp av en angiven mall.

Steg 5: Certifikat utfärdas: CA signerar certifikatet och returnerar det till NDES.

Steg 6: Enheten hämtar certifikat: Certifikatet levereras tillbaka till den begärande enheten.

Vanliga NDES-felkonfigurationer som finns i säkerhetsbedömningar

Enligt min erfarenhet under PKI-bedömning uppstår flera återkommande problem. Låt oss prata om några av dem idag.

1. NDES exponerad direkt på internet: NDES-slutpunkter körs ofta på IIS och kan publiceras externt utan skydd. Detta gör det möjligt för angripare att försöka registrera certifikat, räkna upp mallar och utnyttja sårbarheter i IIS. NDES bör alltid skyddas av programgatewayer och rollbaserade åtkomstregler.
2. Överprivilegierade tjänstkontonNDES använder ett servicekonto för att begära certifikat från certifikatutfärdaren. Om detta konto har för många behörigheter kan angripare själva utfärda certifikat. Denna risk är särskilt allvarlig eftersom certifikat kan användas för autentisering.
3. Svag mallkonfiguration: Mallar som används för SCEP är ibland konfigurerade för att tillåta exporterbara privata nycklar, tillåta alltför breda användningsrättigheter och utfärda certifikat utan godkännandekontroller. Dessa felkonfigurationer kan leda till identitetskompromiss.
4. Brist på övervakning och loggning: Många organisationer använder NDES men övervakar det aldrig. Utan korrekt övervakning och loggning går obehörig certifikatutfärdande obemärkt förbi, missbruk av registreringar kan inte upptäckas och incidenter blir svåra att hantera.

Bästa säkerhetspraxis för NDES-distributioner

För att säkra NDES i moderna miljöer bör organisationer följa flera bästa praxis.

1. Isolera NDES-servrar

NDES bör aldrig installeras direkt på CA:n.

Distribuera det istället:

• I ett dedikerat DMZ-segment
• Bakom en omvänd proxy eller applikationsgateway
• Med begränsad nätverksåtkomst till CA:n

2. Begränsa mallbehörigheter

SCEP-mallar bör:

• Tillåt endast obligatoriska EKU:er
• Begränsa format för ämnesnamn
• Inaktivera export av privata nycklar när det är möjligt

3. Övervaka certifikatutfärdande

Organisationer bör:

• Logga SCEP-förfrågningar
• Övervaka mallanvändning
• Varning om onormala registreringsvolymer

Detta är särskilt viktigt för mallar med hög behörighet.

4. Förstärkning av IIS-konfigurationen

Eftersom NDES körs på IIS är det viktigt att notera följande:

• Inaktivera oanvända moduler
• driva TLS 1.2 eller högre
• Tillämpa säkerhetsrubriker
• Regelbundet uppdatera servern

För mer information om bästa säkerhetspraxis för NDES-distribution, se bloggen: Bästa praxis för NDES-säkerhet

Där SCEP och NDES börjar visa begränsningar

Trots deras utbredda användning var SCEP och NDES ursprungligen inte utformade för dagens molnbaserade miljöer.

Flera utmaningar uppstår ofta i moderna implementeringar:

Begränsad säkerhetskontext

SCEP utformades för enkelhet, vilket innebär att det erbjuder begränsade identitetsvalideringsmöjligheter. Ytterligare kontroller måste ofta läggas ovanpå för att säkerställa stark enhetsautentisering.

Operationell komplexitet

NDES-distributioner kräver:

• Dedikerade servrar
• IIS-härdning
• Att beakta nätverksexponering
• Hantering av mallkonfiguration
• Detta introducerar driftskostnader, särskilt i hybrid- eller multimolnmiljöer.
• Skalningsutmaningar

Även om SCEP fungerar bra för slutpunktsenheter, är det mindre lämpat för dynamiska arbetsbelastningar som containrar, mikrotjänster eller tillfälliga molninstanser. Dessa moderna arbetsbelastningar kräver snabbare certifikatutfärdandecykler och starkare identitetsverifieringsmekanismer.

Det moderna ramverket för certifikatautomation: ACME

ACME, eller Automated Certificate Management Environment, utvecklades för att möjliggöra helt automatiserad certifikatlivscykelhantering med minimal mänsklig inblandning.

Till skillnad från SCEP byggdes ACME för moderna miljöer och stöder:

• Automatiserad certifikatutfärdande
• Automatiserad förnyelse
• API-drivna arbetsflöden
• Mekanismer för identitetsverifiering

ACME används flitigt för allmänheten TLS-certifikat, men företag använder det alltmer internt för arbetsbelastningsidentiteter.

Detta gör den särskilt värdefull för:

• DevOps rörledningar
• Kubernetes kluster
• Molnbaserade tjänster
• Tjänst-till-tjänst-autentisering

ACME:s stöd för kortlivade certifikat överensstämmer väl med Zero Trust-principerna.

Jämförelse av SCEP, NDES och ACME i Enterprise PKI

Varje teknik tjänar ett annat syfte. SCEP tillhandahåller ett enkelt registreringsprotokoll som är lämpligt för slutpunktsenheter. NDES gör det möjligt för Microsoft PKI-miljöer att stödja SCEP-baserad registrering. ACME introducerar moderna automatiseringsfunktioner skräddarsydda för dynamisk infrastruktur. Organisationer använder dem ofta tillsammans snarare än att bara välja en. Till exempel:

• SCEP/NDES för enhetscertifikat
• ACME för server- och arbetsbelastningscertifikat
• Traditionell AD-registrering för domänanslutna system

Denna flerskiktade metod gör det möjligt för företag att modernisera gradvis utan att störa befintlig infrastruktur.

Verkligt exempel: Hybrid företagsdistribution

Tänk dig ett företag som inför Zero Trust och migrerar till molnet samtidigt.

De kan planera att distribuera:

• NDES integrerat med Intune för att hantera enhetscertifikat
• ACME-baserad utfärdande för containerarbetsbelastningar
• ADCS automatisk registrering för interna servrar

Denna hybridmodell gör det möjligt för dem att upprätthålla kompatibilitet med äldre system samtidigt som de moderniserar hanteringen av certifikatlivscykeln.

Det minskar också beroendet av lösenord och stärker identitetsbaserade åtkomstkontroller i hela miljön.

Hur man väljer rätt registreringsmetod

Rätt tillvägagångssätt beror på vilken typ av identiteter du hanterar.

Om ditt fokus ligger på slutanvändarenheter eller nätverksapparater är SCEP med NDES fortfarande praktiskt och har ett brett stöd.

Om ditt fokus ligger på moderna arbetsbelastningar eller automatiseringstunga miljöer erbjuder ACME starkare integration och skalbarhet.

De flesta företag kommer att behöva båda under sin övergång till molnbaserade säkerhetsmodeller.

Framtiden för registrering av företagscertifikat

Certifikatbaserad autentisering blir snabbt standardmekanismen för att säkra företagsmiljöer. I takt med att organisationer går mot:

• Lösenordsfri autentisering
• Tillämpning av enhetsidentitet
• Nollförtroende-åtkomstmodeller
• Molnbaserad arkitektur

Certifikatautomatisering blir en central säkerhetsfunktion snarare än en nischad PKI-funktion.

SCEP och NDES kommer sannolikt att fortsätta användas för enhetsregistrering, medan ACME-användningen fortsätter att öka för arbetsbelastningsidentiteter och infrastrukturautomation.

Den största utmaningen för säkerhetsteam är inte att välja ett protokoll framför ett annat, utan att utforma en PKI-strategi som integrerar dem på ett sammanhängande sätt.

Hur kan krypteringskonsulting hjälpa till?

Krypteringskonsulting har lång erfarenhet av att leverera helhetslösningar PKI-lösningar för företag och myndigheter. Vi erbjuder både professionella tjänster och vår automationsplattform (CertSecure-hanterare) för att säkerställa att din PKI är säker, robust och framtidsklar.

PKI-tjänster

Heltäckande rådgivnings-, design- och implementeringstjänster som hjälper organisationer att bygga, modernisera och styra säkra miljöer med offentlig nyckelinfrastruktur.

Projekt planering

Vi utvärderar er kryptografiska miljö, granskar PKI-konfigurationer, beroenden och krav, och sammanställer resultaten i en strukturerad, kundgodkänd projektplan.

CP/CPS-utveckling

I nästa fas utvecklar vi certifikatpolicyn (CP) och certifieringspraxisutlåtandet (CPS) i linje med RFC#3647. Dessa dokument är anpassade till din organisations regelverk, säkerhetskrav och operativa krav.

PKI-design och implementering

Vi designar och driftsätter robusta PKI-infrastrukturer, inklusive offline-rot-CA:er, utfärdande CA:er, NDES-servrar, HSM-integration etc., beroende på kundens behov. Leveranserna inkluderar PKI-designdokument, byggguider, ceremonimanus och systemkonfigurationer. När driftsättningen är klar genomför vi grundliga tester, validering, finjusteringar och kunskapsöverföringssessioner för att stärka ditt team.

Företagets kontinuitet och katastrofåterställning

Efter driftsättningen utvecklar och implementerar vi strategier för affärskontinuitet och katastrofåterställning, genomför redundantester och dokumenterar operativa arbetsflöden för hela PKI- och HSM-infrastrukturen, med stöd av en omfattande PKI-driftsguide.

Löpande support och underhåll (valfritt)

Efter implementeringen erbjuder vi ett prenumerationsbaserat årligt supportpaket som ger omfattande täckning för PKI-, CLM- och HSM-komponenter. Detta inkluderar incidenthantering, felsökning, systemoptimering, hantering av certifikatlivscykeln, CP/CPS-uppdateringar, nyckelarkivering, uppgraderingar av HSM-firmware, granskningsloggning och patchhantering.

Denna metod säkerställer att din PKI-infrastruktur inte bara är säker och kompatibel, utan också skalbar, robust och helt i linje med dina långsiktiga operativa och regulatoriska mål. 

CertSecure-hanterare 

CertSecure-hanterare Encryption Consulting är en lösning för hantering av certifikatlivscykeln som förenklar och automatiserar hela livscykeln, så att du kan fokusera på säkerhet snarare än förnyelser.

Automatisering för kortlivade certifikat: Med ACME- och 90-dagars/47-dagars TLS-certifikat som blir standard är manuell förnyelse inte längre ett praktiskt alternativ. CertSecure Manager automatiserar registrering, förnyelse och driftsättning för att säkerställa att certifikat aldrig går ut obemärkt.

Sömlös DevOps- och molnintegration: Certifikat kan tillhandahållas direkt till webbservrar och molninstanser, och de integreras med moderna loggverktyg som Datadog, Splunk, ITSM-verktyg som ServiceNow och DevOps-verktyg som Terraform och Ansible.

Stöd för flera CA:er: Många organisationer använder flera CA:er (interna Microsoft CA, publika CA:er som DigiCert och GlobalSign, etc.). CertSecure Manager integreras mellan dessa källor och ger en enda plattform för utfärdande och livscykelhantering.

Enhetliga utfärdande- och förnyelsepolicyer: CertSecure Manager tillämpar din organisations nyckelstorlekar, algoritmer och förnyelseregler konsekvent över alla certifikat, inte bara automatiserar förnyelser med flera certifikatutfärdare, utan säkerställer också att varje certifikat uppfyller dina säkerhetsstandarder varje gång.

Proaktiv övervakning och förnyelsetestning: Kontinuerlig övervakning, i kombination med simulerad förnyelse-/utgångstestning, säkerställer att du identifierar risker innan certifikat påverkar produktionssystemen.

Centraliserad synlighet och efterlevnad: En konsoliderad instrumentpanel visar alla certifikat, nyckellängder, starka och svaga algoritmer och deras utgångsdatum. Revisionsspår och policytillämpning förenklar efterlevnaden. PCI DSS, HIPAAoch andra ramverk.

Om du fortfarande undrar var och hur du ska börja säkra din PKI, finns Encryption Consulting här för att hjälpa dig med det. PKI-supporttjänsterDu kan lita på oss som din betrodda partner, och vi kommer att vägleda dig genom varje steg med tydlighet, självförtroende och praktisk expertis.  

Slutsats

Enterprise PKI utvecklas från ett backend-säkerhetsverktyg till en central identitetsinfrastruktur.

Att förstå hur SCEP, NDES och ACME interagerar gör det möjligt för organisationer att bygga skalbara pipelines för certifikathantering som stöder både äldre miljöer och moderna molnarbetsbelastningar.

Genom att kombinera traditionella PKI-grunder med moderna automatiseringsramverk kan företag gå mot starkare identitetsdriven säkerhet utan att offra den operativa effektiviteten.