Beveiligingsoverwegingen
Gepubliceerd: maart 2016
Van toepassing op: System Center 2012 R2 Operations Manager, Data Protection Manager for System Center 2012, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager
Het meeste werk bij het voorbereiden van de omgeving voor System Center 2012 – Operations Manager heeft te maken met beveiligingstaken. In deze sectie worden deze taken op een oppervlakkig niveau besproken. Zie de Index to Security-related Information for Operations Manager (Index van beveiligingsinformatie voor Operations Manager) voor meer informatie.
Het voorbereiden van de beveiligingstaken omvat het volgende:
Bewaking buiten de grenzen van vertrouwensrelaties begrijpen, plannen en voorbereiden.
Bewaking van UNIX- of Linux-computers begrijpen, plannen en voorbereiden.
De serviceaccounts, gebruikersaccounts en beveiligingsgroepen die u nodig hebt plannen en voorbereiden.
De netwerkpoorten die u nodig hebt voor uw ontwerp begrijpen en voorbereiden.
Grenzen van vertrouwensrelaties
Active Directory-domeinen vormen de basiseenheid voor de grens van een Kerberos-vertrouwensrelatie zoals gezien door Operations Manager. Deze grens wordt automatisch uitgebreid naar andere domeinen in dezelfde naamruimte (dezelfde Active Directory-structuur), en tussen domeinen die zich verschillende Active Directory-structuren maar wel in hetzelfde Active Directory-forest bevinden, via transitieve vertrouwensrelaties. De grens van vertrouwensrelaties kan verder worden uitgebreid tussen domeinen in verschillende Active Directory-forests met behulp van vertrouwensrelaties tussen forests.
Kerberos
Het Kerberos-verificatieprotocol dat wordt ondersteund door Windows 2000-domeincontrollers en hoger, kan alleen worden gebruikt binnen de grenzen van een vertrouwensrelatie. Kerberos-verificatie is het mechanisme dat wordt gebruikt om de wederzijdse verificatie van agents en servers in Operations Manager uit te voeren. In Operations Manager Shell is wederzijdse verificatie van agents en servers vereist voor alle agent-servercommunicatie.
Een Operations Manager-beheergroep heeft de mogelijkheid om detectie en bewaking uit te voeren buiten de grenzen van Kerberos-vertrouwensrelatie waarin de beheergroep zich bevindt. Er moet echter een ander mechanisme worden gebruikt om wederzijdse verificatie te ondersteunen, omdat het standaardverificatieprotocol voor Windows-computers die geen lid zijn van een Active Directory-domein NTLM is. Dit wordt gedaan door het uitwisselen van certificaten tussen agents en servers.
Certificaten
Wanneer Operations Manager-communicatie moet plaatsvinden over de grens van vertrouwensrelaties, zoals wanneer een server die u wilt bewaken zich in een ander, niet-vertrouwd, Active Directory-domein bevindt dan de beheergroep die de bewaking uitvoert, kunnen certificaten worden gebruikt om aan de vereiste voor wederzijdse verificatie te voldoen. Met behulp van handmatige configuratie kunnen certificaten worden verkregen en gekoppeld aan de computers en de Operations Manager-services die daarop worden uitgevoerd. Wanneer een service die moet communiceren met een service op een andere computer wordt gestart en probeert te verifiëren, worden de certificaten uitgewisseld en wederzijdse verificatie uitgevoerd.
.jpeg "System_CAPS_important") Belangrijk |
|---|
De voor dit doel gebruikte certificaten moeten uiteindelijk dezelfde basiscertificeringsinstantie vertrouwen. |
Zie Een gatewayserver implementeren voor meer informatie over het verkrijgen en gebruiken van certificaten voor wederzijdse verificatie.
Certificeringsinstantie (CA)
Om de benodigde certificaten te verkrijgen, hebt u toegang nodig tot een certificeringsinstantie (CA). Dit kan Microsoft Certificate Services zijn, of een certificeringsservice van derden zoals VeriSign.
Microsoft Certificate Services
Er zijn vier typen Microsoft-CA's:
Basis-CA van onderneming
Onderliggende CA van onderneming
Zelfstandige basis-CA
Zelfstandige onderliggende CA
Voor beide ondernemings-CA's is Active Directory Domain Services vereist; voor zelfstandige CA's is dit niet nodig. Beide soorten CA's kunnen de benodigde certificaten uitgeven voor wederzijdse verificatie van agents en server buiten de grenzen van vertrouwensrelaties.
Gewoonlijk bestaat een CA-infrastructuur uit een basis-CA die zijn eigen certificaten ondertekent en zichzelf certificeert, en een of meer onderliggende CA's die door de basis-CA worden gecertificeerd. De onderliggende CA-servers zijn degene die een servicecertificaat aanvraagt, terwijl de basis-CA offline wordt gehaald en veilig wordt gesteld. Zie Infrastructure Planning and Design (Infrastructuur plannen en ontwerpen) en Verificatie en gegevensversleuteling voor Windows-computers voor meer informatie over het ontwerpen van certificaten.
Bewaking van UNIX- en Linux-computers
System Center 2012 – Operations Manager kan UNIX- en Linux-computers bewaken. Omdat de UNIX- en Linux-computers geen lid zijn van het Active Directory-domein waar de beheergroep zich bevindt, wordt een variant gebruikt op de certificaatmethode voor wederzijdse verificatie die hierboven wordt besproken.
Tot stand brengen van wederzijdse verificatie met UNIX en Linux-computers
U gebruikt de Detectiewizard om UNIX- en Linux-computers te vinden en aan de beheergroep toe te voegen als beheerde objecten. Tijdens het Detectiewizard-proces laat Operations Manager de gedetecteerde UNIX- of Linux-computer een zelfondertekend certificaat genereren dat wordt gebruikt voor wederzijdse verificatie met de beheerserver. Wanneer SSH-detectie is ingeschakeld, werkt het proces van het genereren, ondertekenen en uitwisselen van certificaten als volgt:
Het Detectiewizard-proces op de beheerserver laat de gedetecteerde UNIX- of Linux-computer een zelfondertekend certificaat genereren.
De detecterende beheerserver stuurt de UNIX- of Linux-computer een 'get certificate'-verzoek om een certificaat op te halen.
De UNIX- of Linux-computer retourneert het certificaat aan de beheerserver.
De detecterende beheerserver maakt een sleutelpaar en een zelfondertekend certificaat voor zichzelf. De beheerserver genereert alleen een sleutelpaar en zelfondertekend certificaat wanneer het de eerste UNIX- of Linux-computer detecteert. De beheerserver importeert vervolgens zijn eigen certificaat in zijn vertrouwde certificaatarchief. De detecterende beheerserver ondertekent vervolgens het UNIX- of Linux-certificaat met zijn persoonlijke sleutel. Bij elke latere ondertekening van UNIX- of Linux-certificaten door de beheerserver wordt de persoonlijke sleutel van de beheerserver die bij de eerste ondertekening is gegenereerd, opnieuw gebruikt.
De detecterende beheerserver verstuurt vervolgens een 'put certificate'-verzoek waardoor het nu door de beheerserver ondertekende certificaat weer terug wordt gezet op de UNIX- of Linux-computer die het aanvankelijk heeft gegenereerd. Vervolgens wordt de WSMAN-communicatielaag van de UNIX- of Linux-computer opnieuw gestart om het nieuwe door de UNIX- of Linux-computer gegenereerde certificaat actief te maken.
Wanneer de beheerserver nu de UNIX- of Linux-computer vraagt zich te verifiëren, geeft de UNIX- of Linux-computer het vertrouwde certificaat door aan de beheerserver, en de beheerserver leest de handtekening op het verkregen certificaat, ziet dat het deze handtekening vertrouwt (omdat de handtekening zijn eigen persoonlijke sleutel is die in zijn eigen vertrouwde certificaatarchief is opgeslagen), en accepteert dit certificaat als bewijs dat de UNIX- of Linux-computer degene is die de beheerserver denkt dat hij is.
De detecterende beheerserver gebruikt UNIX- of Linux-referenties zoals geconfigureerd in het toepasselijke Run As-profiel om zich bij de UNIX- of Linux-computer te verifiëren. Zie de sectie Planning voor UNIX- of Linux-Run As-profielen voor meer details.
| Belangrijk |
|---|
De voorgaande bewerkingsvolgorde is voor de lichte beveiligingsversie van UNIX- of Linux-detectie. |
Planning voor UNIX- of Linux-Run As-profielen
Nadat de UNIX- of Linux-computer wordt beheerd door de detecterende beheerserver komen de detecties en werkstromen van het management pack op gang. Deze werkstromen vereisen het gebruik van referenties om met succes te worden voltooid. Deze referenties, op welke objecten, klassen of groepen ze worden toegepast en de computers waarnaar ze worden gedistribueerd, bevinden zich in Run As-profielen. Er zijn twee Run As-profielen die worden geïmporteerd wanneer de UNIX-management packs in uw beheergroep worden geïmporteerd. Dit zijn:
Unix-actieaccountprofiel. Dit Run As-profiel en de bijbehorende UNIX- of Linux-referenties worden gebruikt voor licht beveiligde activiteiten op de aangewezen UNIX- of Linux-computers.
Beschermd Unix-accountprofiel. Dit Run As-profiel en de bijbehorende UNIX- of Linux-referenties worden gebruikt voor activiteiten die beschermd worden op een hoger beveiligingsniveau en daarom een account vereisten dat hogere rechten heeft op de UNIX- of Linux-computer. Dit kan het hoofdaccount zijn, maar dat hoeft niet.
U moet deze profielen configureren met de juiste referenties voor UNIX- of Linux-computers om de management pack-werkstromen die er gebruik van maken, correct te laten werken.
Accounts en groepen
Tijdens de levensloop van uw Operations Manager-implementatie hebt u mogelijk een groot aantal accounts en beveiligingsgroepen nodig. Tijdens de installatie van Operations Manager wordt u slechts gevraagd er vier op te geven. U moet rekening houden met extra accounts bij het plannen van beveiligingstoewijzingen op basis van rollen, meldingen en alternatieve referenties voor het uitvoeren van processen. Zie De implementatie van System Center 2012 - Operations Manager plannen voor richtlijnen bij het plannen van op rollen gebaseerde beveiligingstoewijzingen.
Op rollen gebaseerde beveiligingsaccounts en -groepen
Operations Manager regelt de toegang tot bewaakte groepen, taken, weergaven en beheerfuncties door het toewijzen van gebruikersaccounts aan rollen. Een rol in Operations Manager is de combinatie van een profieltype (operator, geavanceerde operator, administrator) en een bereik (tot welke gegevens de rol toegang heeft). Normaal gesproeken worden Active Directory-beveiligingsgroepen aan rollen toegewezen, en worden vervolgens afzonderlijke accounts toegewezen aan die groepen. Plan vóór de implementatie Active Directory-beveiligingsgroepen die aan deze en eventuele aangepaste rollen kunnen worden toegevoegd, zodat u vervolgens afzonderlijke gebruikersaccounts aan de beveiligingsgroepen kunt toevoegen.
Operations Manager biedt standaard de volgende roldefinities.
Rolnaam |
Profieltype |
Profielbeschrijving |
Rolbereik |
|---|---|---|---|
Operations Manager-administrators: Wordt gemaakt bij de installatie; kan niet worden verwijderd; moet een of meer globale groepen bevatten |
Administrator |
Heeft volledige rechten voor Operations Manager; scoping van het Administrator-profiel wordt niet ondersteund |
Volledige toegang tot alle gegevens, services, beheer- en ontwerpgereedschap van Operations Manager |
Geavanceerde Operations Manager-operators: Gemaakt tijdens de installatie; globaal bereik; kan niet worden verwijderd |
Geavanceerde operator |
Heeft beperkte toegang tot de configuratie van Operations Manager; kan onderdrukkingen maken voor regels; monitors voor doelen of groepen doelen binnen het geconfigureerde bereik |
Toegang tot alle groepen, weergaven en taken die momenteel aanwezig zijn of in de toekomst worden geïmporteerd |
Operations Manager-auteurs: Gemaakt tijdens de installatie; globaal bereik; kan niet worden verwijderd |
Auteur |
Kan taken, regels, monitors en weergaven binnen het geconfigureerde bereik maken, bewerken en verwijderen |
Toegang tot alle groepen, weergaven en taken die momenteel aanwezig zijn of in de toekomst worden geïmporteerd |
Operations Manager-operators: Gemaakt tijdens de installatie; globaal bereik; kan niet worden verwijderd |
Operator |
Kan omgaan met waarschuwingen, taken uitvoeren en heeft toegang tot weergaven voor het geconfigureerde bereik. |
Toegang tot alle groepen, weergaven en taken die momenteel aanwezig zijn of in de toekomst worden geïmporteerd |
Alleen-lezen Operations Manager-operators: Gemaakt tijdens de installatie; globaal bereik; kan niet worden verwijderd |
Alleen-lezen-operator |
Kan waarschuwingen zien en heeft toegang tot weergaven volgens het geconfigureerde bereik |
Toegang tot alle groepen en weergaven die momenteel aanwezig zijn of in de toekomst worden geïmporteerd |
Operations Manager-rapportoperators: Gemaakt tijdens de installatie; globaal bereik |
Rapportoperator |
Kan rapporten zien voor het geconfigureerde bereik |
Globaal bereik |
Operations Manager-rapportbeveiligingsbeheerders: Integreert de beveiliging van SQL Server Reporting Services met Operations Manager-gebruikersrollen; geeft Operations Manager-administraties de mogelijkheid toegang tot rapporten te regelen; geen scoping mogelijk |
Rapportbeveiligingsbeheerder |
Maakt het mogelijk SQL Server Reporting Services-beveiliging te integreren met Operations Manager-rollen |
Geen bereik |
U kunt Active Directory-beveiligingsgroepen of afzonderlijke accounts toevoegen aan elk van deze voorgedefinieerde rollen. Als u dat doet, kunnen de betreffende personen de aangegeven rolrechten uitoefenen op de objecten binnen het bereik.
Notitie
De voorgedefinieerde rollen hebben een globaal bereik, zodat ze toegang hebben tot alle groepen, weergaven en taken (behalve Rapportbeveiligingsbeheerder).
U kunt in Operations Manager ook aangepaste rollen maken op basis van de profielen Operator, Alleen-lezen operator, Auteur en Geavanceerde operator. Wanneer u de rol maakt, kunt u het bereik van groepen, taken en weergaven waartoe de rol toegang heeft verder beperken. U zou bijvoorbeeld een rol kunnen maken met de titel 'Exchange-operator', en het bereik beperken tot aan Exchange gerelateerde groepen, weergaven en taken. Aan deze rol toegewezen gebruikersaccounts kunnen alleen acties op Operator-niveau uitvoeren op aan Exchange gerelateerde objecten.
Meldingsaccounts en -groepen
Personen in uw bedrijf die vaak met Operations Manager werken, zoals een Exchange-beheerder die de rol Exchange-operator heeft gekregen, moeten een manier hebben om nieuwe waarschuwingen te ontdekken. Dit kan worden gedaan door voortdurend naar de Operations-console te kijken of er nieuwe waarschuwingen zijn, of door Operations Manager de beheerder op de hoogte te laten stellen van de waarschuwing via ondersteunde communicatiekanalen. Operations Manager ondersteunt meldingen via e-mail, chat, sms, of semafoon. Meldingen over hetgeen de rol moet weten, worden verstuurd naar ontvangers die u opgeeft in Operations Manager. Een Operations Manager-ontvanger is slechts een object dat een geldig adres heeft voor het ontvangen van de melding, zoals een SMTP-adres voor e-mailmeldingen.
Het is dus logisch om de roltoewijzing te combineren met het lidmaatschap van een meldingsgroep via een beveiligingsgroep waarvoor e-mail is ingeschakeld. U kunt bijvoorbeeld een beveiligingsgroep met Exchange-beheerders maken en deze vullen met personen die de kennis en rechten hebben om problemen in Exchange op te lossen. Wijs deze beveiligingsgroep toe aan een aangepaste Exchange-beheerdersrol, zodat deze personen toegang hebben tot de gegevens en e-mail kunnen ontvangen. Maak vervolgens een ontvanger door het SMTP-adres van de beveiligingsgroep met e-mail te gebruiken.
Serviceaccounts
Tijdens de implementatie moet u de volgende serviceaccounts bij de hand hebben. Als u domeinaccounts gebruikt en voor het GPO (groepsbeleidobject) van uw domein het standaardbeleid voor het verlopen van wachtwoorden is ingesteld (zoals vereist is), moet u de wachtwoorden op de serviceaccounts volgens het schema wijzigen, of systeemaccounts met laag onderhoud gebruiken, of de accounts zo configureren dat de wachtwoorden nooit verlopen.
Accountnaam |
Vereist als |
Gebruikt voor |
Laag onderhoud |
Hoge beveiliging |
|---|---|---|---|---|
Actie-account van beheerserver |
installatie van beheerserver |
Verzamelen van gegevens van providers, uitvoeren van reacties |
Lokaal systeem |
Domeinaccount met beperkte bevoegdheden |
Account voor Data Access-service en configuratieservice |
installatie van beheerserver |
Schrijven naar operationele database, uitvoeren van services |
Lokaal systeem |
Domeinaccount met beperkte bevoegdheden |
Lokale beheerdersaccount voor doelapparaten |
Detectie en push-installatie van agents |
Installatie van agents |
Domein of lokale beheerdersaccount |
Domein of lokale beheerdersaccount |
Actie-account van agent |
Detectie en push-installatie van agents |
Verzamelen van gegevens en uitvoeren van reacties op beheerde computers |
Lokaal systeem |
Domeinaccount met beperkte bevoegdheden |
Schrijfactie-account van datawarehouse |
Rapportserver installeren |
Schrijven naar de Reporting-datawarehouse-database |
Domeinaccount met beperkte bevoegdheden |
Domeinaccount met beperkte bevoegdheden |
Gegevenslezer-account |
Rapportserver installeren |
Opvragen van SQL Reporting Services-database |
Domeinaccount met beperkte bevoegdheden |
Domeinaccount met beperkte bevoegdheden |
Service Principal Names
Bij het implementeren van Operations Manager moet u in sommige configuraties mogelijk een SPN (Service Principal Name) registreren. SPN's worden door Kerberos-verificatie gebruikt om de client wederzijds te verifiëren bij de server. Zie What Are Service Publication and Service Principal Names? (Wat zijn Service Publication en Service Principal Names?) voor meer informatie.
Als u Operations Manager installeert, selecteert u een account voor de System Center Configuration-service en de System Center Data Access-service. Zie System Center 2012 - Operations Manager implementeren voor meer informatie.
.jpeg "System_CAPS_caution") Let op |
|---|
Wijzig de standaardmachtigingen van Active Directory niet om een account toe te staan om onbeperkte wijzigingen aan te brengen in zijn eigen SPN. |
Als u het Lokale systeem selecteert als het System Center Data Access-serviceaccount, kan het account de juiste SPN maken. Er is geen aanvullende configuratie nodig.
Als u een domeinaccount gebruikt, moet u een SPN registreren voor elke beheerserver. Gebruik het opdrachtregelprogramma SETSPN. Zie Setspn Overview (Overzicht van Setspn) voor meer informatie over het uitvoeren van dat hulpprogramma.
Registreer zowel de netbios-naam als de volledig gekwalificeerde domeinnaam van de beheerserver en gebruik daarbij de volgende syntaxis:
setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>
setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>
Tip
Met de volgende syntaxis kunt u een lijst weergeven van de SPN's die zijn geregistreerd voor een gebruikersaccount of computer:
setspn –l <DAS account name>
setspn –l <fqdn>
Als u netwerktaakverdeling of een hardwaretaakverdeler gebruikt, moet de System Center Data Access-service worden uitgevoerd onder een domeinaccount. Naast de al beschreven installatie moet u ook de naam voor de netwerktaakverdeling opgeven, met de volgende syntaxis:
setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>
Notitie
Alle System Center Data Access-services die achter de netwerktaakverdeler worden uitgevoerd, moeten worden uitgevoerd met hetzelfde domeinaccount.
Run As-accounts
Agents op bewaakte computers kunnen taken, modules en monitors uitvoeren op aanvraag en in reactie op vooraf gedefinieerde voorwaarden. Standaard worden alle taken uitgevoerd met de referenties van het actie-account van de agent. In sommige gevallen heeft het actie-account van de agent mogelijk onvoldoende rechten en bevoegdheden om een bepaalde actie op de computer uit te voeren. Operations Manager ondersteunt het uitvoeren van taken door agents in de context van een alternatieve set referenties die een Run As-account wordt genoemd. Een Run As-account is een object dat wordt gemaakt in Operations Manager, net zoals een geadresseerde, en dat wordt toegewezen aan een Active Directory-gebruikersaccount. Vervolgens wordt een Run As-profiel gebruikt dat het Run As-account toewijst aan een specifieke computer. Als een regel, taak of monitor die tijdens de ontwikkeling van een management pack is gekoppeld aan een Run As-profiel, moet worden uitgevoerd op de doelcomputer, gebeurt dat met het opgegeven Run As-account.
Bij levering is Operations Manager voorzien van een aantal Run As-accounts en Run As-profielen, en u kunt zelf andere toevoegen wanneer dat nodig is. U kunt er ook voor kiezen om de Active Directory-referenties te wijzigen waaraan een Run As-account is gekoppeld. Hiervoor moeten aanvullende Active Directory-referenties voor dit doel worden gepland, gemaakt en onderhouden. U moet deze accounts behandelen als serviceaccounts wat betreft het verlopen van wachtwoorden, Active Directory Domain Services, locatie en beveiliging.
U moet samenwerken met auteurs van management packs die aanvragen voor Run As-accounts ontwikkelen. Zie de Index to Security-related Information for Operations Manager (Index van beveiligingsinformatie voor Operations Manager) voor meer informatie.