Beveiliging plannen in Configuration Manager
Van toepassing op: Configuration Manager (current branch)
In dit artikel worden de volgende concepten beschreven waarmee u rekening kunt houden bij het plannen van beveiliging met uw Configuration Manager-implementatie:
Certificaten (zelfondertekend en PKI)
De vertrouwde hoofdsleutel
Ondertekening en versleuteling
Beheer op basis van rollen
Microsoft Entra ID
VERIFICATIE VAN SMS-provider
Zorg ervoor dat u bekend bent met de basisprincipes van beveiliging in Configuration Manager voordat u begint.
Certificaten
Configuration Manager maakt gebruik van een combinatie van zelfondertekende en PKI-certificaten (Public Key Infrastructure). Gebruik waar mogelijk PKI-certificaten. Voor sommige scenario's zijn PKI-certificaten vereist. Wanneer PKI-certificaten niet beschikbaar zijn, genereert de site automatisch zelfondertekende certificaten. In sommige scenario's worden altijd zelfondertekende certificaten gebruikt.
Zie Certificaten plannen voor meer informatie.
De vertrouwde hoofdsleutel
De vertrouwde basissleutel van Configuration Manager biedt een mechanisme voor Configuration Manager-clients om te controleren of sitesystemen deel uitmaken van hun hiërarchie. Elke siteserver genereert een site-uitwisselingssleutel om te communiceren met andere sites. De site-uitwisselingssleutel van de site op het hoogste niveau in de hiërarchie wordt de vertrouwde hoofdsleutel genoemd.
De functie van de vertrouwde basissleutel in Configuration Manager lijkt op een basiscertificaat in een openbare-sleutelinfrastructuur. Alles wat is ondertekend door de persoonlijke sleutel van de vertrouwde basissleutel wordt verderop in de hiërarchie vertrouwd. Clients slaan een kopie van de vertrouwde hoofdsleutel van de site op in de root\ccm\locationservices WMI-naamruimte.
De site geeft bijvoorbeeld een certificaat uit aan het beheerpunt, dat wordt ondertekend met de persoonlijke sleutel van de vertrouwde basissleutel. De site deelt met clients de openbare sleutel van de vertrouwde hoofdsleutel. Vervolgens kunnen clients onderscheid maken tussen beheerpunten die zich in hun hiërarchie bevinden en beheerpunten die zich niet in hun hiërarchie bevinden.
Clients krijgen automatisch de openbare kopie van de vertrouwde hoofdsleutel met behulp van twee mechanismen:
U breidt het Active Directory-schema voor Configuration Manager uit en publiceert de site naar Active Directory Domain Services. Vervolgens halen clients deze sitegegevens op van een globale catalogusserver. Zie Active Directory voorbereiden voor sitepublicatie voor meer informatie.
Wanneer u clients installeert met behulp van de clientpushinstallatiemethode. Zie Clientpushinstallatie voor meer informatie.
Als clients de vertrouwde basissleutel niet kunnen ophalen met behulp van een van deze mechanismen, vertrouwen ze de vertrouwde basissleutel die wordt geleverd door het eerste beheerpunt waarmee ze communiceren. In dit scenario kan een client verkeerd worden omgeleid naar het beheerpunt van een aanvaller, waar deze beleid zou ontvangen van het rogue-beheerpunt. Voor deze actie is een geavanceerde aanvaller vereist. Deze aanval is beperkt tot de korte tijd voordat de client de vertrouwde hoofdsleutel ophaalt van een geldig beheerpunt. Om dit risico te beperken dat een aanvaller clients verkeerd omwijst naar een rogue-beheerpunt, richt u de clients vooraf in met de vertrouwde hoofdsleutel.
Zie Beveiliging configureren voor meer informatie en procedures voor het beheren van de vertrouwde basissleutel.
Ondertekening en versleuteling
Wanneer u PKI-certificaten gebruikt voor alle clientcommunicatie, hoeft u zich niet te plannen voor ondertekening en versleuteling om de communicatie met clientgegevens te beveiligen. Als u sitesystemen instelt waarop IIS wordt uitgevoerd om HTTP-clientverbindingen toe te staan, bepaalt u hoe u de clientcommunicatie voor de site kunt beveiligen.
Belangrijk
Vanaf Configuration Manager versie 2103 worden sites die HTTP-clientcommunicatie toestaan, afgeschaft. Configureer de site voor HTTPS of Verbeterde HTTP. Zie De site inschakelen voor alleen HTTPS of verbeterde HTTP voor meer informatie.
Ter bescherming van de gegevens die clients naar beheerpunten verzenden, kunt u vereisen dat clients de gegevens ondertekenen. U kunt ook het SHA-256-algoritme vereisen voor ondertekening. Deze configuratie is veiliger, maar sha-256 is niet vereist, tenzij alle clients dit ondersteunen. Veel besturingssystemen ondersteunen dit algoritme systeemeigen, maar oudere besturingssystemen vereisen mogelijk een update of hotfix.
Terwijl ondertekening de gegevens beschermt tegen manipulatie, helpt versleuteling de gegevens te beschermen tegen openbaarmaking van informatie. U kunt versleuteling inschakelen voor de inventarisgegevens en statusberichten die clients verzenden naar beheerpunten op de site. U hoeft geen updates op clients te installeren om deze optie te ondersteunen. Clients en beheerpunten vereisen meer CPU-gebruik voor versleuteling en ontsleuteling.
Opmerking
Voor het versleutelen van de gegevens gebruikt de client de openbare sleutel van het versleutelingscertificaat van het beheerpunt. Alleen het beheerpunt heeft de bijbehorende persoonlijke sleutel, zodat alleen het de gegevens kan ontsleutelen.
De client bootstrapt dit certificaat met het handtekeningcertificaat van het beheerpunt, dat wordt opgestart met de vertrouwde basissleutel van de site. Zorg ervoor dat u de vertrouwde hoofdsleutel op clients veilig inricht. Zie De vertrouwde hoofdsleutel voor meer informatie.
Zie Ondertekening en versleuteling configureren voor meer informatie over het configureren van de instellingen voor ondertekening en versleuteling.
Zie Technische naslaginformatie over cryptografische besturingselementen voor meer informatie over de cryptografische algoritmen die worden gebruikt voor ondertekening en versleuteling.
Beheer op basis van rollen
Met Configuration Manager gebruikt u op rollen gebaseerd beheer om de toegang te beveiligen die gebruikers met beheerdersrechten nodig hebben om Configuration Manager te gebruiken. U beveiligt ook de toegang tot de objecten die u beheert, zoals verzamelingen, implementaties en sites.
Met de combinatie van beveiligingsrollen, beveiligingsbereiken en verzamelingen kunt u de beheertoewijzingen scheiden die voldoen aan de vereisten van uw organisatie. Als ze samen worden gebruikt, definiëren ze het beheerbereik van een gebruiker. Dit beheerbereik bepaalt de objecten die een gebruiker met beheerdersrechten bekijkt in de Configuration Manager-console en bepaalt de machtigingen die een gebruiker heeft voor deze objecten.
Zie Basisprincipes van op rollen gebaseerd beheer voor meer informatie.
Microsoft Entra ID
Configuration Manager kan worden geïntegreerd met Microsoft Entra ID om de site en clients in staat te stellen moderne verificatie te gebruiken.
Zie Microsoft Entra-documentatie voor meer informatie over Microsoft Entra ID.
Het onboarden van uw site met Microsoft Entra ID ondersteunt de volgende Configuration Manager-scenario's:
Clientscenario's
Serverscenario's
VERIFICATIE VAN SMS-provider
U kunt het minimale verificatieniveau opgeven voor beheerders voor toegang tot Configuration Manager-sites. Deze functie dwingt beheerders af zich aan te melden bij Windows met het vereiste niveau voordat ze toegang hebben tot Configuration Manager. Deze is van toepassing op alle onderdelen die toegang hebben tot de SMS-provider. Bijvoorbeeld de Configuration Manager-console, SDK-methoden en Windows PowerShell-cmdlets.
Configuration Manager ondersteunt de volgende verificatieniveaus:
Windows-verificatie: verificatie met Active Directory-domeinreferenties vereisen. Deze instelling is het vorige gedrag en de huidige standaardinstelling.
Certificaatverificatie: verificatie vereisen met een geldig certificaat dat is uitgegeven door een vertrouwde PKI-certificeringsinstantie. U configureert dit certificaat niet in Configuration Manager. Configuration Manager vereist dat de beheerder is aangemeld bij Windows met behulp van PKI.
Windows Hello voor Bedrijven-verificatie: verificatie vereisen met sterke tweeledige verificatie die is gekoppeld aan een apparaat en gebruikmaakt van biometrische gegevens of een pincode. Zie Windows Hello voor Bedrijven voor meer informatie.
Belangrijk
Wanneer u deze instelling selecteert, vereisen de SMS-provider en beheerservice dat het verificatietoken van de gebruiker een MFA-claim (Multi-Factor Authentication) van Windows Hello voor Bedrijven bevat. Met andere woorden, een gebruiker van de console, SDK, PowerShell of beheerservice moet zich verifiëren bij Windows met de pincode of biometrische gegevens van Windows Hello voor Bedrijven. Anders weigert de site de actie van de gebruiker.
Dit gedrag is voor Windows Hello voor Bedrijven, niet voor Windows Hello.
Zie Verificatie van SMS-provider configureren voor meer informatie over het configureren van deze instelling.