Plannen voor beveiliging in Configuration Manager
Van toepassing op: Configuration Manager (current branch)
In dit artikel worden de volgende concepten beschreven die u kunt overwegen bij het plannen van beveiliging met uw Configuration Manager implementatie:
Certificaten (zelf-ondertekend en PKI)
De vertrouwde basissleutel
Ondertekening en versleuteling
Op rollen gebaseerd beheer
Azure Active Directory
Verificatie via SMS-provider
Voordat u begint, moet u ervoor zorgen dat u bekend bent met de basisprincipes van beveiliging in Configuration Manager.
Certificaten
Configuration Manager maakt gebruik van een combinatie van zelf-ondertekende en openbare-sleutelinfrastructuurcertificaten (PKI). Gebruik waar mogelijk PKI-certificaten. Voor sommige scenario's zijn PKI-certificaten vereist. Als er geen PKI-certificaten beschikbaar zijn, genereert de site automatisch zelf-ondertekende certificaten. In sommige scenario's worden altijd zelf-ondertekende certificaten gebruikt.
Zie Plan for certificates (Certificaten plannen) voor meer informatie.
De vertrouwde basissleutel
De Configuration Manager basissleutel biedt een mechanisme voor Configuration Manager om te controleren of sitesystemen deel uitmaken van hun hiërarchie. Elke siteserver genereert een uitwisselingssleutel om te communiceren met andere sites. De uitwisselingssleutel van de site op het hoogste niveau in de hiërarchie wordt de vertrouwde basissleutel 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 basissleutel van de site op in de root\ccm\locationservices WMI-naamruimte.
De site geeft bijvoorbeeld een certificaat uit aan het beheerpunt, dat wordt ondertekent met de persoonlijke sleutel van de vertrouwde basissleutel. De site deelt met clients de openbare sleutel van de vertrouwde basissleutel. Clients kunnen dan onderscheid maken tussen beheerpunten in hun hiërarchie en beheerpunten die zich niet in hun hiërarchie.
Clients krijgen automatisch de openbare kopie van de vertrouwde basissleutel met behulp van twee mechanismen:
U breidt het Active Directory-schema voor Configuration Manager uit en publiceert de site naar Active Directory Domain Services. Clients halen deze sitegegevens vervolgens op van een globale catalogusserver. Zie Active Directory voorbereiden voor sitepublicatie voor meer informatie.
Wanneer u clients installeert met behulp van de client-push-installatiemethode. Zie Client push installation (Client-pushinstallatie) voor meer informatie.
Als clients de vertrouwde basissleutel niet kunnen krijgen 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 worden omsingeerd naar het beheerpunt van een aanvaller, waar het beleid van het rogue-beheerpunt zou ontvangen. Voor deze actie is een geavanceerde aanvaller vereist. Deze aanval is beperkt tot de korte tijd voordat de client de vertrouwde basissleutel op haalt van een geldig beheerpunt. Om dit risico te verminderen dat een aanvaller clients naar een rogue beheerpunt omkeert, moet u de clients vooraf inrichten met de vertrouwde basissleutel.
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 geen ondertekening en versleuteling te plannen om de communicatie met clientgegevens te beveiligen. Als u sitesystemen in stelt die IIS uitvoeren om HTTP-clientverbindingen toe te staan, besluit u hoe u de clientcommunicatie voor de site wilt beveiligen.
Belangrijk
Vanaf Configuration Manager versie 2103 worden sites die HTTP-clientcommunicatie toestaan, afgeschaft. Configureer de site voor HTTPS of Enhanced HTTP. Zie Enable the site for HTTPS-only or enhanced HTTP (De site inschakelen voor ALLEEN HTTPS of verbeterde HTTP) voor meer informatie.
Ter bescherming van de gegevens die clients naar beheerpunten verzenden, kunt u clients verplichten om de gegevens te ondertekenen. U kunt ook het SHA-256-algoritme vereisen voor ondertekening. Deze configuratie is veiliger, maar vereist geen SHA-256, tenzij alle clients dit ondersteunen. Veel besturingssystemen ondersteunen dit algoritme systeemeigen, maar voor oudere besturingssystemen is mogelijk een update of hotfix vereist.
Hoewel ondertekening helpt de gegevens te beschermen 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 in de site. U hoeft geen updates te installeren op clients om deze optie te ondersteunen. Clients en beheerpunten vereisen meer CPU-gebruik voor versleuteling en ontsleuteling.
Notitie
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 gebootstrapt met de vertrouwde basissleutel van de site. Zorg ervoor dat u de vertrouwde basissleutel veilig inrichten op clients. Zie De vertrouwde basissleutel 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.
Op rollen gebaseerd beheer
Met Configuration Manager gebruikt u beheer op basis van rollen om de toegang te beveiligen die gebruikers met beheerderstoegang moeten gebruiken Configuration Manager. 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. Samen 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.
Azure Active Directory
Configuration Manager kan worden geïntegreerd met Azure Active Directory (Azure AD) zodat de site en clients moderne verificatie kunnen gebruiken.
Zie voor meer informatie over Azure AD Azure Active Directory documentatie.
Onboarding van uw site met Azure AD ondersteunt de volgende Configuration Manager scenario's:
Clientscenario's
Serverscenario's
Verificatie via SMS-provider
U kunt het minimale verificatieniveau opgeven voor beheerders voor toegang tot Configuration Manager sites. Met deze functie wordt afgedwongen dat beheerders zich aanmelden Windows het vereiste niveau voordat ze toegang krijgen tot Configuration Manager. Dit geldt voor 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 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 PKI.
Windows Hello voor zakelijke verificatie: verificatie vereisen met sterke tweestapsverificatie die is gekoppeld aan een apparaat en biometrie of een pincode gebruikt. Zie Windows Hello for Business voor meer informatie.
Belangrijk
Wanneer u deze instelling selecteert, moeten de SMS-provider en de beheerservice het verificatie-token van de gebruiker een MFA-claim (Multi-Factor Authentication) van Windows Hello for Business bevatten. Met andere woorden, een gebruiker van de console, SDK, PowerShell of beheerservice moet zich verifiëren bij Windows met hun Windows Hello voor zakelijke pincode of biometrische gegevens. Anders weigert de site de actie van de gebruiker.
Dit gedrag is voor Windows Hello voor Bedrijven, niet Windows Hello.
Zie Configure SMS Provider authentication (SMS-providerverificatie configureren) voor meer informatie over het configureren van deze instelling.