PKIaaS för hybrid arbetskraftsautentisering

Hybridarbetskraften har fundamentalt förändrat autentiseringsproblemet. När alla anställda arbetade från ett företagskontor på hanterade bärbara datorer anslutna till ett företagsnätverk, var ett lösenord som kontrollerades mot Active Directory en rimlig autentiseringsmekanism: nätverksplatsen gav implicit förtroende, och företagets perimeter tvingade fram vem som kunde nå autentiseringsslutpunkten överhuvudtaget. Den modellen beskriver inte längre hur de flesta organisationer fungerar. Användare autentiserar från bredband i hemmet, hotell-Wi-Fi, kafénätverk och mobilanslutningar. Enheterna sträcker sig från företagshanterade bärbara datorer med fullständig MDM-registrering till personliga telefoner som får åtkomst till företagets e-post under en BYOD-policy. Nätverksperimetrar har ersatts av identitet som kontrollplan.

I den här miljön är lösenord och OTP-tokens inte tillräckliga autentiseringsmekanismer. Lösenord är nätfiskebara, återanvändbara mellan tjänster och beroende av att användaren anger rätt autentiseringsuppgifter vid varje autentiseringshändelse. Certifikat är det inte. Ett certifikat kan inte nätfiskas eftersom den privata nyckeln aldrig lämnar enheten. Ett certifikat kan inte återanvändas mellan obehöriga tjänster eftersom varje autentiseringshändelse bevisar innehav av den privata nyckeln utan att överföra den. Ett certifikat autentiseras tyst när det har registrerats, utan användarinteraktion, oavsett användarens nätverksplats. PKI as a Service tillhandahåller den certifikatutfärdarinfrastruktur som utfärdar, hanterar och återkallar dessa certifikat i hela personalstyrkan, integrerad med MDM-plattformarna och identitetsleverantörerna som IAM- och infrastrukturteam redan driver.

Snabbt svar: Vad erbjuder PKIaaS för hybrid arbetskraftsautentisering?

PKIaaS tillhandahåller den styrda CA-backend som utfärdar certifikat för varje användningsfall för arbetskraftsautentisering: användarautentiseringscertifikat för VPN och Wi-Fi 802.1X via EAP-TLS, enhetsautentiseringscertifikat för hanterade slutpunkter på företagsnätverkssegment, S/MIME-certifikat för signerad och krypterad e-post och inloggningscertifikat för smartkort för fysisk och logisk åtkomst med hög säkerhet. MDM-plattformarna (Intune, Jamf, Workspace ONE) distribuerar dessa certifikat till enheter via SCEP- eller WSTEP-registrering, utan att användarna behöver installera något manuellt. CLM-lagret övervakar certifikatutgången och automatiserar förnyelse så att certifikaten förblir giltiga i hela enhetsflottan utan certifikatrelaterade autentiseringsfel.

Key Takeaways

• Certifikatbaserad autentisering via EAP-TLS är den enda nätfiskesäkra autentiseringsmekanismen som fungerar för VPN, Wi-Fi 802.1X och nätverksåtkomstkontroll utan att kräva ett lösenord eller en OTP-token vid varje autentiseringshändelse. Den privata nyckeln lämnar aldrig enheten; autentiseringen bevisar nyckelinnehav utan att överföra en hemlighet.
• PKIaaS integreras med Microsoft Intune, Jamf, VMware Workspace ONE, Ivanti och andra MDM-plattformar via SCEP- och WSTEP-registreringsprotokoll, och distribuerar certifikat till Windows-, macOS-, iOS- och Android-enheter automatiskt som en del av enhetsregistreringen och tilldelningen av efterlevnadsprofiler.
• S/MIME-certifikat från en PKIaaS-CA tillhandahåller e-postsignering och kryptering för arbetsstyrkan utan att en offentlig CA behöver vara inblandad. Den privata PKIaaS-CA:n utfärdar S/MIME-certifikat med Email Protection EKU och användarens e-postadress i SAN:et, distribuerbara via Intune, Jamf eller automatisk registrering för Active Directory Certificate Services.
• Smartkortsinloggningscertifikat utfärdade av PKIaaS kräver stöd för Smart Card Logon EKU och PKINIT i domänkontrollantens konfiguration. De ger högsta möjliga autentiseringsgaranti för system för privilegierad åtkomst och fysisk åtkomstkontroll, där den privata nyckeln lagras i smartkortets hårdvarukryptografiska modul.
• WSTEP (Windows-registrering via Web Services Trust-protokoll) och Active Directory-baserad automatisk registrering gör det möjligt för Windows-domänanslutna enheter att automatiskt ta emot användar- och enhetscertifikat från PKIaaS-certifikatutfärdaren via grupprincip, utan någon användaråtgärd eller IT-helpdesks inblandning i certifikatdistributionsprocessen.

Varför certifikat är rätt autentiseringslager för hybridarbete

Autentiseringsproblemet för hybridarbetsstyrkor har två dimensioner som lösenord ensamma inte kan åtgärda. Den första är motståndskraft mot nätfiske: lösenord och TOTP-tokens kan fångas upp av en väl utformad nätfiskesida som använder proxy för autentiseringsflödet i realtid. En certifikatbaserad autentiseringshändelse kan inte användas som proxy eftersom autentiseringsbeviset är kryptografiskt bundet till den specifika tjänst som klienten autentiserar sig till. TLS-kanalen tillhandahåller denna bindning: klientens EAP-TLS-autentisering inkluderar serverns certifikat i handskakningen, så en man-in-the-middle som presenterar ett annat servercertifikat kommer att orsaka att klientautentiseringen misslyckas.

Den andra dimensionen är tyst kontinuerlig autentisering. I en hybridarbetsstyrka där användare rör sig mellan nätverksmiljöer flera gånger per dag (hemmanätverk på morgonen, VPN för ett möte, företags-Wi-Fi på plats på eftermiddagen) introducerar en autentiseringsmekanism som kräver manuell användaråtgärd vid varje nätverksövergång friktion och skapar belastning på helpdesk när användare misslyckas med att autentisera om korrekt. Certifikatbaserad EAP-TLS-autentisering är automatisk: enheten presenterar sitt certifikat för nätverksautentiseraren utan någon användarinteraktion, och användaren återfår nätverksåtkomst transparent. Detta är operativt kritiskt för stora hybridarbetsstyrkor där autentiseringsvolymen och variationen i nätverksmiljöer gör manuell autentisering olämplig i stor skala.

VPN-autentisering med PKIaaS-certifikat

VPN är fortfarande den primära fjärråtkomstmekanismen för de flesta hybridarbetsstyrkor på företag, särskilt för åtkomst till lokala system, utvecklingsmiljöer och interna tjänster som inte är åtkomliga från det offentliga internet. Certifikatbaserad VPN-autentisering ger väsentliga säkerhetsförbättringar jämfört med lösenordsbaserad eller OTP-baserad VPN-autentisering:

• Användar-VPN-certifikat: PKIaaS CA utfärdar ett användarautentiseringscertifikat med TLS Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2) och användarens UPN (User Principal Name) i SAN URI- eller UPN-fältet. VPN-gatewayen validerar certifikatet mot PKIaaS CA:s förtroendekedja och kontrollerar återkallelse via OCSP. Om certifikatet är giltigt och inte återkallat autentiseras användaren. VPN-gatewayen kan också mappa UPN:et till motsvarande Active Directory- eller IdP-användarkonto för auktoriseringsbeslut;
• Enhetens VPN-certifikat: Separata enhetsautentiseringscertifikat med enhetens FQDN eller serienummer i SAN:et gör det möjligt för VPN-gatewayen att framtvinga en enhetsstatuskontroll innan användarautentiseringen fortsätter. En hanterad enhet med ett giltigt, MDM-registrerat enhetscertifikat kan upprätta en enhetstunnel; en personlig enhet utan enhetscertifikat kan inte. Detta möjliggör en VPN-arkitektur med noll förtroende där både användarens och enhetens identitet måste vara giltig innan åtkomst beviljas;
• Certifikatets giltighet och återkallelse: När en användare lämnar organisationen återkallar IT-teamet användarens VPN-certifikat i PKIaaS-certifikatutfärdaren. Återkallelsen överförs till OCSP-respondern inom några sekunder. Nästa VPN-autentiseringsförsök från det återkallade certifikatet misslyckas omedelbart, utan att lösenordsåterställning, avprovisionering av konto i VPN-gatewayen eller någon manuell åtgärd i VPN-konfigurationen krävs.

VPN-certifikatprofiler i PKIaaS anger vanligtvis: ECDSA P-256- eller RSA-2048-nyckel, 1 års giltighetstid (eller kortare för miljöer med hög säkerhet), TLS-klientautentisering (EKU) och UPN SAN som fylls i från IdP-attributet vid registreringstillfället. MDM-plattformen levererar certifikatet till enhetens certifikatarkiv och konfigurerar VPN-klientprofilen för att referera till det, så att användare inte behöver välja ett certifikat manuellt när de ansluter till VPN:et.

Wi-Fi 802.1X-autentisering med EAP-TLS

Företags-Wi-Fi-autentisering via 802.1X med EAP-TLS är den certifikatbaserade motsvarigheten till åtkomstkontrollen för företagsnätverk som tidigare krävde att användare var anslutna till ett trådbundet företagsnätverk för att komma åt interna resurser. Med EAP-TLS presenterar en hanterad enhet sitt certifikat för den trådlösa åtkomstpunktens RADIUS-server; RADIUS-servern validerar certifikatkedjan mot PKIaaS-certifikatutfärdaren, kontrollerar återkallelse och signalerar till åtkomstpunkten att tillåta eller neka associering.

De praktiska fördelarna jämfört med lösenordsbaserad Wi-Fi-autentisering (WPA2-PSK eller PEAP-MSCHAPv2) är betydande:

• Ingen delad hemlighet att hantera: WPA2-PSK kräver att en fördelad nyckel distribueras till varje behörig användare. När en användare lämnar eller nyckeln komprometteras måste PSK:n roteras och omdistribueras till alla behöriga användare. EAP-TLS har ingen delad hemlighet: varje enhet har sitt eget certifikat, och att återkalla ett enskilt certifikat tar bort just den enhetens åtkomst utan att påverka någon annan enhet;
• Identitet per enhet: EAP-TLS förser RADIUS-servern med den specifika enhetens certifikatidentitet, inte bara bevis på att den anslutande enheten känner till en delad nyckel. RADIUS-servern kan tillämpa nätverksåtkomstpolicyer på enhetsnivå: tilldela hanterade enheter till företagets VLAN, tilldela BYOD-enheter till ett begränsat VLAN och neka åtkomst till enheter vars certifikat har återkallats;
• Automatisk återautentisering: När en hanterad enhet roamar mellan åtkomstpunkter i samma 802.1X-säkrade nätverk hanteras EAP-TLS-återautentisering automatiskt av enhetens supplikant utan någon användarinteraktion. Användare som rör sig genom ett campus eller en kontorsbyggnad upplever aldrig autentiseringsfrågor när de rör sig mellan trådlösa celler.

För hybridarbetsstyrkor ger 802.1X EAP-TLS-autentisering på företagskontor sömlös, nätfiskeresistent nätverksautentisering när användare är på plats, medan samma certifikat används för VPN-autentisering när de arbetar på distans. Ett enda PKIaaS-utfärdat användar- eller enhetscertifikat fungerar i båda användningsfallen, med samma återkallningsmekanism som ger omedelbar åtkomstavslutning över båda nätverksåtkomstkanalerna.

S/MIME-certifikat för e-postsäkerhet för arbetskraften

S/MIME (Secure/Multipurpose Internet Mail Extensions) använder PKI-certifikat för att tillhandahålla två e-postsäkerhetsfunktioner som ingen annan standardmekanism för e-postsäkerhet kan erbjuda tillsammans: digital signering (kryptografiskt bevis på att e-postmeddelandet kom från den angivna avsändaren och inte har ändrats) och end-to-end-kryptering (kryptering av e-postmeddelandets brödtext och bilagor så att endast mottagaren med motsvarande privata nyckel kan dekryptera).

PKIaaS utfärdar S/MIME-certifikat för e-postsäkerhet för anställda med Email Protection EKU (OID 1.3.6.1.5.5.7.3.4) och användarens e-postadress i namnfältet SAN RFC 822. Certifikatet utfärdas av den privata PKIaaS CA; e-postklienten (Microsoft Outlook, Apple Mail eller mobila e-postklienter) litar på certifikatet eftersom PKIaaS-rot-CA-certifikatet är installerat i företagets förtroendearkiv via grupprincip, MDM-profil eller hantering av operativsystemets förtroendearkiv.

För hybrid e-postsäkerhet för arbetsstyrkan tillhandahåller S/MIME:

• E-postsignering för chefskommunikation och känslig kommunikation: Signerade e-postmeddelanden ger mottagarna kryptografiskt bevis på avsändarens identitet och meddelandets integritet. Nätfiskeattacker som förfalskar chefers e-postadresser misslyckas när mottagarna är utbildade att verifiera S/MIME-signaturer, eftersom angriparen inte kan producera en giltig signatur från chefens privata nyckel;
• E-postkryptering för reglerad data: Organisationer inom reglerade branscher (hälso- och sjukvård, finansiella tjänster, juridik, myndigheter) har ofta skyldigheter att skydda sekretessen för specifika kommunikationskategorier. S/MIME-kryptering säkerställer att e-post som innehåller patientdata, finansiell information eller privilegierad juridisk kommunikation krypteras från slutpunkt till slutpunkt från avsändarens e-postklient till mottagarens e-postklient, inte bara under överföring via e-postservern;
• Certifikatupptäckt via Active Directory eller LDAP: För att S/MIME-kryptering ska fungera måste avsändarens e-postklient ha mottagarens S/MIME-certifikat (offentliga nyckel). Företagsdistributioner publicerar S/MIME-certifikat till Active Directory eller en LDAP-katalog så att Outlook och andra företagse-postklienter kan upptäcka mottagarcertifikat automatiskt när de skriver ett krypterat meddelande. PKIaaS CA:s CLM-integration kan automatisera publicering av nyligen utfärdade S/MIME-certifikat till katalogen.

Smartkortsinloggningscertifikat för privilegierad åtkomst

Smartkortsinloggningscertifikat ger den högsta möjliga autentiseringssäkerheten för Windows-domäninloggning och privilegierad åtkomstkontroll. Certifikatets privata nyckel genereras och lagras i smartkortets hårdvarukryptografiska modul och exporteras aldrig. Windows Kerberos-autentisering via PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) använder smartkortscertifikatet för att ersätta det lösenordsbaserade AS-REQ/AS-REP-utbytet: domänkontrollanten verifierar smartkortscertifikatkedjan mot PKIaaS CA och utfärdar en Kerberos-biljettbeviljande biljett baserat på certifikatidentiteten.

Smartkortsinloggningscertifikat från PKIaaS kräver specifik profilkonfiguration:

• Utökad nyckelanvändning: Smartkortsinloggning (OID 1.3.6.1.4.1.311.20.2.2) och klientautentisering (OID 1.3.6.1.5.5.7.3.2);
• Ämnesalternativ: UPN som matchar användarens Active Directory-konto i UPN SAN-fältet, krävs för att PKINIT ska kunna mappa certifikatet till rätt AD-konto;
• Nyckelförvaring: Den privata nyckeln måste finnas i smartkortets hårdvarumodul; certifikatprofilen bör ange att nyckeln inte kan exporteras och måste vara hårdvarubaserad;
• Utgivande CA-förtroende: Det PKIaaS-utfärdande CA-certifikatet måste publiceras till Active Directory NTAuthCertificates-arkivet, som auktoriserar certifikat från den CA:n för Windows-domäninloggning. Denna konfiguration utförs en gång per PKIaaS-utfärdande CA som kommer att utfärda inloggningscertifikat för smartkort.
• Certifikatets giltighetstid: Inloggningscertifikat för smartkort har vanligtvis en giltighetstid på 1 till 3 år, med förnyelse som utlöses före utgångsdatumet via registreringsarbetsflödet som konfigurerats i PKIaaS.

För hybrida arbetsmiljöer är smartkortsinloggning mest tillämpligt på: privilegierade administratörskonton som kräver tvåfaktorsautentisering som kombinerar det fysiska smartkortet (något du har) och PIN-koden (något du vet); delade arbetsstationer i säkra anläggningar (sjukhusstationer för sjuksköterskor, terminaler på tillverkningsgolvet) där flera användare autentiserar sig med personliga smartkort; och myndigheter eller försvarsmiljöer där autentisering baserad på personlig identitetsverifiering (PIV) är obligatoriskt enligt policy.

Microsoft Intune-integration för certifikatdistribution

Microsoft Intune är den mest använda MDM-plattformen för hybrid enhetshantering för arbetskraften. PKIaaS integreras med Intune genom två registreringsmekanismer, som var och en är lämplig för olika enhetsplattformar och registreringsscenarier.

SCEP-baserad certifikatregistrering för Intune

SCEP (Simple Certificate Enrollment Protocol) är det mest stödda certifikatregistreringsprotokollet för mobila och hanterade enheter. För Intune SCEP-integration exponerar PKIaaS CA en SCEP-slutpunkt. Intune-administratören skapar en SCEP-certifikatprofil i Intune och anger: SCEP-serverns URL (PKIaaS SCEP-slutpunkt), det betrodda rot-CA-certifikatet (PKIaaS rot-CA), certifikatets ämne och SAN-fält (ifyllda från Intune-enhets- och användarattribut med hjälp av mallvariabler), nyckelstorlek och algoritm samt certifikatets giltighetstid. Intune tilldelar SCEP-profilen till enhetsgrupper; registrerade enheter begär certifikat från PKIaaS SCEP-slutpunkten som en del av deras Intune-efterlevnadsprofilapplikation, och certifikatet installeras i enhetscertifikatarkivet utan någon användaråtgärd. SCEP-baserad Intune-certifikatleverans stöder: Windows- (maskin- och användarcertifikat), macOS-, iOS- och Android-enhetsplattformar.

WSTEP och automatisk registrering i Windows

WSTEP (Web Services Trust Enrollment Protocol) är det Windows-baserade certifikatregistreringsprotokollet som används av Active Directory Certificate Services och stöds av PKIaaS för registrering av Windows-enheter och användarcertifikat. För domänanslutna Windows-enheter i en Intune-samhanterings- eller Active Directory-miljö tillåter WSTEP-baserad automatisk registrering att användar- och enhetscertifikat utfärdas från PKIaaS-CA:n via automatisk registrering i Windows Group Policy, utan att enheten behöver använda Intune SCEP-flödet. PKIaaS-agenten installeras på en Windows-server i domänen; Group Policy konfigurerar automatisk registrering för att referera till den PKIaaS-utfärdande CA:n. När en domänansluten Windows-enhet bearbetar Group Policy begär den automatiskt de certifikat som anges i certifikatmallarna som konfigurerats för automatisk registrering, och PKIaaS-CA:n utfärdar dem. Detta är den sömlösa upplevelse som de flesta Windows-administratörer förväntar sig av AD CS och är nu tillgänglig mot en PKIaaS-CA utan att underhålla lokal CA-infrastruktur.

Jamf-integration för Apple-enhetscertifikat

Jamf är den MDM-plattform som används mest för att hantera Apple-enhetsflottor (macOS, iOS, iPadOS). PKIaaS integreras med Jamf via SCEP, samma protokoll som används för Intune på Apple-plattformar. Jamf-administratören skapar en PKI-integration i Jamf Pro som pekar mot PKIaaS SCEP-slutpunkt. Certifikatprofiler i Jamf anger ämne och SAN-mall, certifikattyp (användare eller enhet), nyckelalgoritm och storlek samt giltighetstid. Jamfs omfattningsregler avgör vilka enheter som får vilka certifikatprofiler.

För hybridarbetsstyrkor med stora Apple-maskiner möjliggör PKIaaS-Jamf-integrationen:

• macOS Wi-Fi 802.1X EAP-TLS: Jamf levererar ett enhets- eller användarcertifikat och en Wi-Fi-nyttolast som konfigurerar EAP-TLS-autentisering med hjälp av det certifikatet. MacBooks ansluter automatiskt till företags 802.1X Wi-Fi utan att användarna tillfrågas om inloggningsuppgifter;
• macOS VPN-certifikatautentisering: Jamf levererar användarcertifikatet och en VPN-nyttolast som är konfigurerad för att använda certifikatautentisering. VPN-klienten refererar till certifikatet från nyckelringen utan användarinteraktion;
• iOS- och iPadOS-enhetscertifikat för mobil arbetskraft: Fältarbetare och mobila anställda med hanterade iPhones och iPads får enhetscertifikat via Jamf som autentiserar dem mot företagets nätverksresurser och VPN;
• Automatisk certifikatförnyelse: Jamf övervakar certifikatens utgångsdatum för certifikat som den hanterar och kan utlösa SCEP-förnyelseförfrågningar till PKIaaS CA innan certifikatet löper ut, vilket bibehåller certifikatets giltighet i hela Apple-enhetsflottan utan manuell helpdesk-inblandning.

VMware Workspace ONE-integration

VMware Workspace ONE (nu Omnissa Workspace ONE) används i stor utsträckning i företagsmiljöer som hanterar en blandning av Windows-, macOS-, iOS-, Android- och ChromeOS-enheter. PKIaaS integreras med Workspace ONE genom SCEP- och PKI-profilbaserad certifikatleverans, med samma registreringsmodell som Intune och Jamf: PKIaaS SCEP-slutpunkten registreras i Workspace ONE som en certifikatutfärdare, och certifikatprofiler tilldelar certifikat till enhetsgrupper baserat på Workspace ONEs smarta gruppregler.

För hybridarbetsplatser med flera plattformar ger Workspace ONEs plattformsoberoende MDM-funktion i kombination med PKIaaS-certifikatutfärdande en enhetlig arkitektur för certifikatleverans: samma PKIaaS CA utfärdar certifikat för Windows-bärbara datorer, macOS MacBooks, Android-telefoner och iOS-enheter, alla hanterade via Workspace ONE-profiler, alla med konsekventa certifikatprofiler och återkallelser. CLM-lagret som är kopplat till PKIaaS ger IAM-teamet insyn i certifikatstatusen för alla enheter på alla plattformar i en enda inventeringsvy.

Att tänka på vid BYOD och ohanterade enheter

Hybridarbetsstyrkor inkluderar ofta en andel personligt ägda enheter som drivs under en BYOD-policy. Certifikatbaserad autentisering för BYOD-enheter kräver en annan registreringsmodell än MDM-hanterade enheter, eftersom organisationens MDM inte har hanteringsbehörighet över en personligt ägd enhet och inte kan installera ett certifikat i tysthet via MDM-profilmekanismen.

För registrering av BYOD-certifikat stöder PKIaaS flera metoder beroende på vad användarens enhet kan stödja:

• Användarinitierad SCEP-registrering via en registreringsportal: Användaren navigerar till en registreringsportal som tillhandahålls av organisationen, autentiserar sig med sina IdP-inloggningsuppgifter (SSO eller MFA), och portalen utlöser en SCEP-registreringsbegäran till PKIaaS CA. Certifikatet installeras i användarens personliga enhetscertifikatarkiv. Portalen kan integreras med IdP:n för att tillämpa MFA innan certifikatregistrering tillåts, vilket säkerställer att endast autentiserade användare kan få certifikat för sina personliga enheter.
• Begränsad Workspace ONE- eller Intune-registrering för BYOD: Många organisationer registrerar BYOD-enheter i en begränsad MDM-profil som endast hanterar arbetsprofilen (på Android) eller endast specifika appar (på iOS), utan fullständig enhetshantering. I denna begränsade registreringsmodell kan MDM:n fortfarande leverera certifikat till arbetsprofilen eller den hanterade appnyckelringen, vilket tillhandahåller certifikatbaserad autentisering för företagsresurser utan att kräva fullständig MDM-registrering av den personliga enheten.
• BYOD-specifika certifikatprofiler med begränsad åtkomst: PKIaaS-utfärdaren utfärdar BYOD-enhetscertifikat från en separat utfärdande utfärdare eller certifikatprofil som endast är betrodd för åtkomst till BYOD-lämpliga resurser (ett begränsat nätverks-VLAN, specifika applikationer). Hanterade enhetscertifikat från den MDM-registreringsutfärdande utfärdaren är betrodda för bredare företagsresursåtkomst. Separationen upprätthålls på RADIUS- och applikationslagret genom att kontrollera vilken utfärdande utfärdare som signerat det autentiserade certifikatet.

Certifikatlivscykelhantering för arbetskraftscertifikat

Arbetskraftscertifikat har andra krav på livscykelhantering än TLS-servercertifikat. Ett misslyckande med förnyelsen av TLS-servercertifikat orsakar ett serviceavbrott som är synligt för alla användare. Ett misslyckande med förnyelsen av användarautentiseringscertifikatet gör att en enskild användares VPN-, Wi-Fi- eller e-postsignering slutar fungera, vilket användaren kanske inte rapporterar omedelbart och som kanske inte märks förrän användaren är offsite och inte kan autentisera.

Effektiv CLM för arbetskraftscertifikat kräver:

• Certifikatförteckning per användare: CLM-plattformen upprätthåller en inventering som mappar varje certifikat till användaren och enheten det utfärdades till, inte bara till en generisk certifikattyp. När en utgångssignal utlöses skickas den till användarens chef eller helpdesk med tillräckligt med kontext för att identifiera vilken användares åtkomst som är i riskzonen.
• MDM-utlöst förnyelse: För certifikat som distribueras via MDM bör förnyelsen också ske via MDM-plattformen. Intune, Jamf och Workspace ONE stöder alla SCEP-förnyelseförfrågningar som utlöses av MDM-plattformen innan certifikatet löper ut. PKIaaS CA behandlar förnyelseförfrågan och MDM levererar det förnyade certifikatet till enheten utan att användaren behöver göra något.
• Integrering av ansluten/flyttande/avgående: Certifikatlivscykeln måste integreras med HR-systemets anslutnings-/flytt-/avgångsprocess. När en användare ansluter sig bör IAM-provisioneringsflödet inkludera att begära deras VPN-, Wi-Fi- och S/MIME-certifikat från PKIaaS via MDM-registreringen. När en användare lämnar bör offboarding-flödet inkludera återkallelse av alla certifikat som utfärdats till den användaren. PKIaaS-återkallelse via hanterings-API:et eller CA-administratörsgränssnittet sprids till OCSP inom några sekunder.
• Bekräftelse av återkallelse: Efter att ha återkallat en avgången användares certifikat bör CLM-plattformen bekräfta återkallelsen genom att kontrollera OCSP-statusen för varje återkallat certifikat och logga tidsstämpeln för bekräftad återkallelse. Detta ger den revisionslogg som behövs för att visa för granskare och efterlevnadsteam att åtkomsten avslutades omedelbart efter användarens avgång.

PKIaaS och Zero Trust-arbetskraftsidentitet

Zero Trust-arkitekturen kräver att varje åtkomstförfrågan autentiseras och auktoriseras explicit, oavsett nätverksplats. Certifikatbaserad autentisering överensstämmer naturligt med Zero Trust-principerna eftersom den tillhandahåller kontinuerlig, kryptografisk identitetsverifiering utan att förlita sig på nätverksperimeterförtroende:

• Identitetsverifiering oberoende av nätverksplats: Ett certifikat utfärdat av organisationens PKIaaS-CA verifierar användarens eller enhetens identitet oavsett om begäran kommer från företagsnätverket, ett hemmakontor eller en offentlig Wi-Fi-anslutning. Nätverket är inte betrott; certifikatet är;
• Kortlivade inloggningsuppgifter för känslig åtkomst: Zero Trust-implementeringar använder ofta kortlivade autentiseringsuppgifter för känslig åtkomst för att minimera risken för missbruk av autentiseringsuppgifter. PKIaaS stöder utfärdande av certifikat med kort giltighetstid (24 till 72 timmar) för tidsbegränsade privilegierade åtkomstsessioner, där certifikatets utgångsdatum ger automatisk åtkomstavslutning utan att kräva en uttrycklig återkallelseshändelse;
• Tillämpning av enhetsställning: Ett PKIaaS-enhetscertifikat kan endast utfärdas till en enhet som slutför MDM-registreringsprocessen. En ohanterad enhet kan inte hämta ett enhetscertifikat från PKIaaS-certifikatutfärdaren via MDM-registreringsvägen. RADIUS- och åtkomstkontrollsystem som kräver ett giltigt enhetscertifikat för nätverksåtkomst tillämpar därför implicit hanterad enhetsstatus utan en separat NAC-agent;
• Kontinuerlig kontroll av återkallelse: Nollförtroendesystem för åtkomstkontroll frågar OCSP om status för återkallelse av certifikat vid varje åtkomstbeslutspunkt, inte bara vid initial autentisering. PKIaaS OCSP-svar tillhandahåller återkallelsestatus i realtid så att ett återkallat certifikat misslyckas vid nästa åtkomstförsök även om en session tidigare har upprättats.

Hur krypteringskonsulting kan hjälpa

• PKI som en tjänst: Krypteringskonsulttjänster PKIaaS-erbjudande tillhandahåller den styrda CA-infrastrukturen för alla typer av certifikat för arbetskraftsautentisering: användarautentiseringscertifikat (TLS Client Auth EKU, UPN SAN) för VPN och 802.1X, enhetscertifikat för hanterad slutpunktsnätverksåtkomst, S/MIME-certifikat (Email Protection EKU, RFC 822 SAN) för signerad och krypterad e-post, och inloggningscertifikat för smartkort (Smart Card Logon EKU, UPN SAN, NTAuthCertificates-publicering) för privilegierad åtkomst. Kontakta oss på Krypteringskonsulting för att utforma din arkitektur för arbetskraftscertifikat.
• CertSecure-chef: Krypteringskonsulttjänster CertSecure-hanterare tillhandahåller CLM-synlighetslagret för hantering av arbetskraftens certifikatlivscykel: certifikatinventering per användare, övervakning av utgångsdatum med rollbaserad aviseringsrouting, MDM-integrerad förnyelsebekräftelse, integrering av anslutna/flyttade/avslutande för certifikatprovisionering och återkallelse, och OCSP-återkallelsesbekräftelseloggning för efterlevnadsgranskningsspår.
• PKI-tjänster (MDM-integration): Krypteringskonsulttjänster PKI-tjänster inkluderar PKIaaS-integration med Microsoft Intune (SCEP- och WSTEP-registrering), Jamf Pro (SCEP-baserad leverans av Apple-enhetscertifikat) och VMware Workspace ONE (konfiguration av SCEP- och PKI-profiler), inklusive design av certifikatprofiler för varje användningsfall, felsökning av RADIUS och 802.1X SCEP samt konfiguration av automatisk registrering av grupprinciper för Windows-domänmiljöer.
• PKI-bedömningstjänst: För organisationer som utvärderar en övergång från lösenordsbaserad VPN- och Wi-Fi-autentisering till certifikatbaserad EAP-TLS, Encryption Consultings PKI-bedömningstjänst utvärderar den nuvarande autentiseringsarkitekturen, identifierar de certifikattyper och profiler som krävs, mappar varje certifikattyp till lämplig MDM-registreringsmekanism och tar fram en implementeringsplan för det certifikatbaserade autentiseringsprogrammet.
• PQC-rådgivningstjänster: Certifikat för arbetskraftsautentisering med ECDSA P-256- eller RSA-2048-signeringsnycklar omfattas av samma tidslinje för utfasning av NIST IR 8547-algoritmen som alla andra PKI-certifikat. Encryption Consultings PQC-rådgivningstjänster inkludera planering för migrering av arbetskraftscertifikat: identifiera vilka autentiseringscertifikattyper som kan övergå till ML-DSA (FIPS 204) och vilka som kräver fortsatt användning av klassiska algoritmer i väntan på bekräftelse av stöd från förlitande parter (RADIUS-server, smartkortsmellanprogram, mobilt operativsystem).

Slutsats

Problemet med hybrid arbetskraftsautentisering är i grunden ett certifikatproblem. Varje autentiseringsanvändningsfall som är viktigt för en distribuerad arbetsstyrka, inklusive VPN-åtkomst hemifrån, Wi-Fi-autentisering på företagskontor, krypterad e-post för reglerad kommunikation, privilegierad åtkomst med smartkortsgaranti och hanterad enhetsidentitet för BYOD-styrning, har en certifikatbaserad lösning som är mer nätfiskebeständig, mer operativt skalbar och mer granskningsbar än motsvarande lösenord eller engångslösenord.

PKIaaS är det som gör detta certifikatprogram operativt genomförbart: en styrd CA-backend som utfärdar rätt certifikattyp för varje användningsfall, integrerad med MDM-plattformarna som distribuerar certifikat till enheter, övervakad av CLM-lagret som säkerställer att certifikat förblir giltiga och återkallar dem omedelbart när de inte borde. IAM- och infrastrukturteam som designar och driver detta system får ett autentiseringslager för arbetskraften som inte är beroende av att användare kommer ihåg lösenord, inte kräver helpdesk-inblandning för rutinmässiga autentiseringshändelser och tillhandahåller en revisionslogg från certifikatutfärdande till återkallelse som lösenord och OTP-system inte kan matcha.

Om din organisation utvärderar certifikatbaserad autentisering för VPN, Wi-Fi, e-postsäkerhet eller privilegierad åtkomst, kontakta Encryption Consulting.

Det här inlägget granskas med jämna mellanrum och när större MDM-plattformar (Intune, Jamf, Workspace ONE) publicerar uppdateringar av sina SCEP- eller certifikatleveransintegrationer som påverkar PKIaaS-registreringskonfigurationen.

Vanliga frågor om partihandel med mat och dryck

Vad är certifikatbaserad autentisering och hur skiljer det sig från lösenordsbaserad autentisering?

Certifikatbaserad autentisering bekräftar identitet med hjälp av ett digitalt certifikat och motsvarande privat nyckel. Den privata nyckeln lämnar aldrig enheten; autentiseringen bevisar innehav av nyckeln utan att överföra en hemlighet. Lösenord kräver överföring av en delad hemlighet vid varje autentiseringshändelse, vilket gör dem sårbara för nätfiske och avlyssning. Certifikat autentiseras tyst och kontinuerligt utan användarinteraktion efter den första registreringen, oavsett användarens nätverksplats.

Hur fungerar EAP-TLS-certifikatautentisering för VPN och Wi-Fi?

Vid EAP-TLS-autentisering presenterar klienten sitt certifikat för en RADIUS-server (för 802.1X Wi-Fi) eller en VPN-gateway. Autentiseraren verifierar certifikatkedjan mot den betrodda PKIaaS-certifikatutfärdaren, kontrollerar återkallelse via OCSP och beviljar eller nekar åtkomst. Klienten verifierar också serverns certifikat, vilket ger ömsesidig autentisering. Inget lösenord överförs i flödet. PKIaaS tillhandahåller den certifikatutfärdare som utfärdar klientcertifikat och OCSP-respondern som autentiserare frågar efter återkallningsstatus.

Vilka certifikattyper utfärdar PKIaaS för hybrid arbetskraftsautentisering?

PKIaaS utfärdar användarautentiseringscertifikat (TLS Client Auth EKU, UPN SAN) för VPN och 802.1X, enhetscertifikat (TLS Client Auth EKU, enhets-FQDN SAN) för hanterad slutpunktsnätverksåtkomst, S/MIME-certifikat (Email Protection EKU, RFC 822 email SAN) för signerad och krypterad e-post, och inloggningscertifikat för smartkort (Smart Card Logon EKU plus Client Auth EKU, UPN SAN) för privilegierad Windows-domäninloggning. Varje typ har en distinkt certifikatprofil i PKIaaS med lämpliga begränsningar för det användningsfallet.

Hur integreras PKIaaS med Microsoft Intune för certifikatdistribution?

PKIaaS integreras med Intune via SCEP (för Windows, macOS, iOS och Android) och WSTEP (för Windows-domänanslutna enheter via automatisk registrering i Active Directory). SCEP Intune-profiler refererar till PKIaaS SCEP-slutpunkten och mallvariablerna för certifikatämne och SAN-fält. Registrerade enheter begär certifikat automatiskt som en del av Intune-efterlevnadsprofilapplikationen, där certifikatet installeras i enhetens certifikatarkiv utan att användaren behöver göra något.

Vad är S/MIME och hur stöder PKIaaS det för e-postsäkerhet för anställda?

S/MIME använder certifikat för att tillhandahålla digital signering av e-post (vilket bevisar avsändarens identitet och meddelandets integritet) och end-to-end-kryptering (krypterar e-postmeddelandets brödtext så att endast mottagaren med motsvarande privata nyckel kan dekryptera). PKIaaS utfärdar S/MIME-certifikat med Email Protection EKU och användarens e-postadress i SAN RFC 822-fältet. Certifikat distribueras till e-postklienter via MDM-profiler eller automatisk registrering i Active Directory. För kryptering publiceras mottagarnas S/MIME-certifikat till Active Directory eller LDAP så att avsändarnas e-postklienter kan upptäcka dem automatiskt.