Artikel
06/15/2016

Säkerhetsöverväganden

Utgivet: mars 2016

Gäller för: System Center 2012 R2 Operations Manager, Data Protection Manager for System Center 2012, System Center 2012 - Operations Manager, System Center 2012 SP1 - Operations Manager

Det mesta av arbetet med att förbereda miljön för System Center 2012 – Operations Manager handlar om säkerhetsrelaterade uppgifter. I det här avsnittet ges en översikt över sådana uppgifter. Mer information finns i Index to Security-related Information for Operations Manager (Index för säkerhetsrelaterad information för Operations Manager).

Förberedelse av säkerhetsrelaterade uppgifter innehåller följande:

Förstå, planera och förbereda för övervakning över förtroendegränser.
Förstå, planera och förbereda för övervakning av UNIX- eller Linux-datorer.
Planera och förbereda de tjänstkonton, användarkonton och säkerhetsgrupper som du behöver.
Förstå och förbereda nätverksportar efter vad designen kräver.

Förtroendegränser

Active Directory-domäner utgör den grundläggande enheten för en Kerberos-förtroendegräns som den ser ut för Operations Manager. Gränsen utökas automatiskt till andra domäner i samma namnrymd (samma Active Directory-träd), och mellan domäner som finns i olika Active Directory-träd men fortfarande i samma Active Directory-skog via transitiva förtroenden. Förtroendegränsen kan utökas vidare mellan domäner i olika Active Directory-skogar genom att förtroenden över skogar används.

Kerberos

Autentiseringsprotokollet Kerberos, som stöds av Windows 2000-domänkontrollanter och senare, kan bara förekomma inom en förtroendegräns. Kerberos-autentisering är mekanismen som används till att utföra den ömsesidiga agent/server-autentiseringen i Operations Manager. Ömsesidig agent/server-autentisering är obligatorisk i Operations Manager-gränssnitt för all agent- och serverkommunikation.

En Operations Manager-hanteringsgrupp kan utföra identifiering och övervakning utanför den Kerberos-förtroendegräns som hanteringsgruppen befinner sig i. Men eftersom standardprotokollet för autentisering för Windows-baserade datorer som inte är kopplade till en Active Directory-domän är NTLM, måste en annan mekanism användas för att kunna hantera den ömsesidiga autentiseringen. Det görs genom ett utbyte av certifikat mellan agenter och servrar.

Certifikat

När Operations Manager-kommunikation måste ske över förtroendegränser, till exempel när en server du vill övervaka finns i en annan, ej betrodd, Active Directory-domän än hanteringsgruppen som utför övervakningen, kan du använda certifikat för att uppfylla kravet på ömsesidig autentisering. Genom manuell konfiguration kan certifikat hämtas och associeras med datorerna och de Operations Manager-tjänster som körs på dem. När en tjänst som måste kommunicera med en tjänst på en annan dator startar och försöker autentisera, sker ett certifikatutbyte och den ömsesidiga autentiseringen utförs.

Viktigt
Certifikaten som används i det här syftet måste i slutänden ha samma betrodda rotcertifikatutfärdare.

Mer information om hur du hämtar och använder certifikat för ömsesidig autentisering finns i Distribuera en gateway-server.

Certifikatutfärdare

För att få de certifikat du behöver måste du ha åtkomst till en certifikatutfärdare. Det kan vara Microsoft Certifikattjänster eller en tredjepartstjänst för certifiering, till exempel VeriSign.

Microsoft Certifikattjänster

Det finns fyra typer av Microsoft-certifikatutfärdare:

Företagets rotcertifikatutfärdare
Företagets underordnade certifikatutfärdare
Fristående rotcertifikatutfärdare
Fristående underordnad certifikatutfärdare
Båda företagstyperna av certifikatutfärdare kräver Active Directory Domain Services, vilket inte fristående certifikatutfärdare gör. Alla typer av certifikatutfärdare kan utfärda nödvändiga certifikat för ömsesidig agent/server-autentisering över förtroendegränser.

Vanligtvis består en certifikatutfärdarinfrastruktur av en rotcertifikatutfärdare som signerar sina egna certifikat och en eller flera underordnade certifikatutfärdare, som certifieras av roten. De underordnade certifikatutfärdarna är dem som ett tjänstcertifikat begär, när roten tas offline och förvaras. Mer information om utformning av certifikat finns i Infrastructure Planning and Design (Planering och design av infrastruktur) och i Autentisering och datakryptering för Windows-datorer.

Övervakning av UNIX- och Linux-datorer

System Center 2012 – Operations Manager kan övervaka UNIX- och Linux-datorer. Eftersom UNIX- och Linux-datorerna inte deltar i Active Directory-domänen som hanteringsgruppen finns i så används en variant av den certifikatmetod för ömsesidig autentisering som beskrivs ovan.

Etablera ömsesidig autentisering med UNIX- och Linux-datorer

Med identifieringsguiden kan du söka efter UNIX- och Linux-datorer och lägga till dem i hanteringsgruppen som hanterade objekt. Under identifieringsguidens process gör Operations Manager så att identifierade UNIX- och Linux-datorer genererar ett självsignerat certifikat som används för ömsesidig autentisering på hanteringsservern. Generering, signering och utbyte av certifikat fungerar på det här sättet när SSH-identifiering aktiveras:

I identifieringsguidens process på hanteringsservern genererar den identifierade UNIX- eller Linux-datorn ett självsignerat certifikat.
Den identifierande hanteringsservern skickar en hämtningsbegäran för certifikat till UNIX- eller Linux-datorn.
UNIX- eller Linux-datorn returnerar certifikatet till hanteringsservern
Den identifierande hanteringsservern skapar ett nyckelpar och ett eget självsignerat certifikat. Hanteringsservern genererar bara ett nyckelpar och ett självsignerat certifikat när den identifierar den första UNIX- eller Linux-datorn. Hanteringsservern importerar sedan det egna certifikatet till arkivet över betrott certifikat. Den identifierande hanteringsservern signerar sedan UNIX- eller Linux-certifikatet med sin privata nyckel. Vid alla efterföljande signeringar av UNIX- eller Linux-datorcertifikat av hanteringsservern återanvänds hanteringsserverns privata nyckel som genererades vid den första signeringen.
Den identifierande hanteringsservern skickar sedan en Put-begäran för certifikatet, som sätter tillbaka det nu hanteringsserversignerade certifikatet på UNIX- eller Linux-datorn som först genererade det. UNIX- eller Linux-datorns WSMAN-kommunikationslager startas sedan om så att det nya UNIX-/Linux-datorgenererade certifikatet blir aktivt.
Nu när hanteringsservern begär att UNIX- eller Linux-datorn autentiserar sig själv så ger UNIX- eller Linux-datorn det betrodda certifikatet till hanteringsservern. Hanteringsservern läser signaturen på certifikatet, ser att signaturen är betrodd (eftersom signaturen är serverns egen privata nyckel som lagras i det egna arkivet över betrott certifikat) och godkänner certifikatet som bevis på att UNIX- eller Linux-datorn är den som hanteringsservern tror att datorn är.
Den identifierande hanteringsservern använder UNIX- eller Linux-autentiseringsuppgifter enligt konfigurationen i lämplig Kör som-profil för att autentisera sig själv med UNIX- eller Linux-datorn. Mer information finns i avsnittet Planera för Kör som-profiler i UNIX eller Linux.

Viktigt
Föregående åtgärdsordning är avsedd för lågsäkerhetsversionen av UNIX- eller Linux-identifiering.

Planera för Kör som-profiler i UNIX eller Linux

När UNIX- eller Linux-datorn har hanterats av den identifierande hanteringsservern börjar hanteringspaketidentifieringar och arbetsflöden att köras. För att de här arbetsflödena ska kunna slutföras krävs att autentiseringsuppgifter används. Autentiseringsuppgifterna och vilka objekt, klasser eller grupper de används för, samt vilka datorer de distribueras till finns i Kör som-profiler. Det finns två Kör som-profiler som importeras när UNIX-hanteringspaket importeras till hanteringsgruppen:

Unix-åtgärdskontoprofil – Den här Kör som-profilen och dess associerade UNIX- eller Linux-autentiseringsuppgifter används för aktiviteter med låg säkerhet på de avsedda UNIX- eller Linux-datorerna.
Profil för privilegierat Unix-konto – Den här Kör som-profilen och dess associerade UNIX- eller Linux-autentiseringsuppgifter används för aktiviteter som skyddas en högre säkerhetsnivå och därför kräver ett konto som har högre privilegier på UNIX- eller Linux-datorn. Det kan vara (men måste inte vara) rotkontot.

Du måste konfigurera de här profilerna med rätt autentiseringsuppgifter för UNIX- eller Linux-datorn för de hanteringspaketarbetsflöden som använder profilerna, om de ska fungera på rätt sätt.

Konton och grupper

Under Operations Manager-distribueringens livslängd behöver du möjligen många konton och säkerhetsgrupper. Vid installationen av Operations Manager ombeds du bara att ange fyra. Överväg att ange ytterligare konton när du planerar rollbaserade säkerhetstilldelningar, meddelanden och alternativa autentiseringsuppgifter för att köra processer. I Planera distributionen av System Center 2012 – Operations Manager får du vägledning för planering av rollbaserade säkerhetstilldelningar.

Rollbaserade säkerhetskonton och grupper

Operations Manager kontrollerar åtkomsten till övervakade grupper, uppgifter, vyer och administrativa funktioner via tilldelningen av användarkonton till roller. En roll i Operations Manager är en kombination av en profiltyp (operatör, avancerad operatör, administratör) och ett omfång (vilka data rollen har åtkomst till). Normalt tilldelas Active Directory-säkerhetsgrupper till roller och sedan tilldelas enskilda konton till de grupperna. Före distributionen planerar du Active Directory-säkerhetsgrupper som kan läggas till i de här rollerna och eventuella anpassade roller, så att du sedan kan lägga till enskilda användarkonton i säkerhetsgrupperna.

I Operations Manager finns följande fördefinierade roller.

Rollnamn	Profiltyp	Profilbeskrivning	Rollomfång
Operations Manager-administratörer: Skapas vid installationen, kan inte tas bort, måste innehålla en eller flera globala grupper	Administratör	Har fullständig behörighet i Operations Manager, det finns inget stöd för att ange omfång för profilen Administratör	Fullständig åtkomst till alla data, tjänster, administrativa verktyg och redigeringsverktyg i Operations Manager
Avancerade Operations Manager-operatörer Skapas vid installationen, globalt omfång, kan inte tas bort	Avancerad operatör	Har begränsad ändringsåtkomst till Operations Manager-konfigurationen, kan skapa åsidosättningar för regler, övervakare för mål eller grupper med mål i det konfigurerade omfånget	Åtkomst till alla aktuella grupper, vyer och uppgifter och dem som importeras framöver
Operations Manager-författare: Skapas vid installationen, globalt omfång, kan inte tas bort	Författare	Kan skapa, redigera och ta bort uppgifter, regler, övervakare och vyer i det konfigurerade omfånget	Åtkomst till alla aktuella grupper, vyer och uppgifter och dem som importeras framöver
Operations Manager-operatörer: Skapas vid installationen, globalt omfång, kan inte tas bort	Operator	Kan interagera med aviseringar, köra uppgifter och få åtkomst till vyer enligt det konfigurerade omfånget	Åtkomst till alla aktuella grupper, vyer och uppgifter och dem som importeras framöver
Skrivskyddade Operations Manager-operatörer: Skapas vid installationen, globalt omfång, kan inte tas bort	Skrivskyddad operatör	Kan visa aviseringar och få åtkomst till vyer enligt det konfigurerade omfånget	Åtkomst till alla aktuella grupper och vyer och dem som importeras framöver
Operations Manager-rapportoperatörer: Skapas vid installationen, globalt omfång	Rapportoperatör	Kan visa rapporter enligt det konfigurerade omfånget	Globalt omfång
Rapportsäkerhetsadministratörer i Operations Manager: Integrerar SQL Server Reporting Services-säkerhet med Operations Manager-användarroller, ger Operations Manager administratörer möjlighet att kontrollera åtkomst till rapporter, det går inte att ange omfång för dem	Rapportsäkerhetsadministratör	Gör det möjligt att integrera säkerhetsfunktionen i SQL Server Reporting Services med Operations Manager-roller	Inget omfång

Du kan lägga till Active Directory-säkerhetsgrupper eller enskilda konton i alla de här fördefinierade rollerna. Om du gör det kan de personerna agera efter den rollbehörighet de har fått för objekt i omfånget.

Information
De fördefinierade reglerna har globalt omfång angivet, vilket ger dem åtkomst till alla grupper, vyer och uppgifter (förutom för Rapportsäkerhetsadministratör).

Du kan med Operations Manager även skapa anpassade regler som baseras på profilerna Operatör, Skrivskyddad operatör, Författare och Avancerad operatör. När du skapar rollen kan du ytterligare begränsa omfånget för grupper, uppgifter och vyer som rollen kan få åtkomst till. Du kan exempelvis skapa en roll med namnet ”Exchange-operatör” och begränsa omfånget till bara Exchange-relaterade grupper, vyer och uppgifter. Användarkonton som tilldelas till den här rollen kan bara utföra åtgärder på operatörsnivå för Exchange-relaterade objekt.

Meddelandekonton och -grupper

Personer i företaget som interagerar med Operations Manager ofta, till exempel en Exchange-administratör som har tilldelats till rollen Exchange-operatör, behöver ett sätt att identifiera nya aviseringar. Det kan du göra genom att bevaka nya aviseringar i driftkonsolen eller genom att Operations Manager informerar dem om aviseringen via kommunikationskanaler som stöds. Operations Manager stödjer meddelanden via e-post, snabbmeddelanden, SMS eller personsökare. Meddelanden om vad rollen måste veta skickas till mottagare som du anger i Operations Manager. En Operations Manager-mottagare är bara ett objekt som har en giltig adress för att ta emot meddelandet, till exempel en SMTP-adress för e-postmeddelanden.

Det är därför logiskt att kombinera rolltilldelning med medlemskap i meddelandegruppen via en e-postaktiverad säkerhetsgrupp. Du kan exempelvis skapa säkerhetsgruppen Exchange-administratörer och fylla den med personer som har kunskapen och behörigheten att göra korrigeringar i Exchange. Tilldela den här säkerhetsgruppen till en anpassad Exchange-administratörsroll som du skapar, så att de har åtkomst till data och är e-postaktiverade. Skapa sedan en mottagare genom att använda SMTP-adressen till den e-postaktiverade säkerhetsgruppen.

Tjänstkonton

När det är dags att distribuera måste du ha följande tjänstkonton redo. Om du använder domänkonton och ditt GPO (grupprincipobjekt) har standardprincipen för lösenordets upphörande inställt som obligatorisk, måste du antingen ändra lösenord för tjänstkontona i enlighet med schemat, använda systemkonton med lågt underhåll eller konfigurera kontona så att lösenorden aldrig går ut.

Kontonamn	Begärs när	Används för	Lågt underhåll	Hög säkerhet
Åtgärdskonto för hanteringsserver	installation av hanteringsserver	Samla in data från leverantörer, köra svar	Lokalt system	Domänkonto med låg behörighet
Dataåtkomsttjänst och konfigurationstjänstkonto	installation av hanteringsserver	Skriva till använd databas, köra tjänster	Lokalt system	Domänkonto med låg behörighet
Lokalt adminstratörskonto för målenheter	Identifiering och installation av push-agent	Installera agenter	Domänkonto eller lokalt administratörskonto	Domänkonto eller lokalt administratörskonto
Åtgärdskonto för agent	Identifiering och installation av push-agent	Samla information och köra svar på hanterade datorer	Lokalt system	Domänkonto med låg behörighet
Konto för informationslagerskrivning	Installation av rapportserver	Skriva till rapportinformationslagrets databas	Domänkonto med låg behörighet	Domänkonto med låg behörighet
Dataläsarkonto	Installation av rapportserver	Skicka fråga till SQL-rapporttjänstens databas	Domänkonto med låg behörighet	Domänkonto med låg behörighet

SPN (Service Principal Name)

När du distribuerar Operations Manager behöver du kanske registrera ett SPN (Service Principal Name) för vissa konfigurationer. SPN används vid Kerberos-autentisering så att klienten ömsesidigt ska kunna sköta autentisering med servern. Mer information finns i What Are Service Publication and Service Principal Names? (Vad är tjänstpublicering och SPN?).

När du installerar Operations Manager väljer du ett konto för System Center-konfigurationstjänsten och System Center-tjänsten för dataåtkomst. Mer information finns i avsnittet Distribuera System Center 2012 – Operations Manager.

Varning
Ändra inte Active Directory-standardbehörigheterna för att tillåta ett konto att utföra obegränsade ändringar av sitt eget SPN.

Om du väljer Lokalt system som konto för System Center-tjänsten för dataåtkomst kan kontot skapa lämpligt SPN. Ingen ytterligare konfiguration krävs.

Om du använder ett domänkonto måste du registrera ett SPN för varje hanteringsserver. Använd kommandoradsverktyget SETSPN. Mer information om hur du kör verktyget finns i Setspn Overview (Översikt över Setspn).

Registrera både netbios-namnet och ett fullständigt domännamn för hanteringsservern med följande syntax:

setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>

setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>

Du kan lista SPN som finns registrerade till användarkontot eller datorn med följande syntax:

setspn –l

Om du använder utjämning av nätverksbelastning eller maskinvara för belastningsutjämning måste System Center-tjänsten för dataåtkomst köras under ett domänkonto. Förutom den installation som redan har beskrivits måste du registrera det belastningsutjämnade namnet med följande syntax:

setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>

Information
Alla System Center-tjänster för dataåtkomst som körs bakom belastningsutjämnaren måste köras med samma domänkonto.

Kör som-konton

Agenter på övervakade datorer kan köra uppgifter, moduler och övervakare på begäran eller aktiveras vid fördefinierade förhållanden. Som standard använder alla uppgifter som körs med agentåtgärdskonton autentiseringsuppgifter. I vissa fall kan agentåtgärdskontot ha otillräckliga rättigheter och behörighet för att köra en viss åtgärd på datorn. Operations Manager har stöd för körning av uppgifter av agenter med en alternativ uppsättning autentiseringsuppgifter som kallas för ett Kör som-konto. Ett Kör som-konto är ett objekt som skapas i Operations Manager, precis som en mottagare, och mappas till ett Active Directory-användarkonto. Därefter används en Kör som-profil som mappar Kör som-kontot till en specifik dator. När en regel, uppgift eller övervakare som kopplats till en Kör som-profil när ett hanteringspaket utvecklas ska köras på måldatorn, sker detta med det angivna Kör som-kontot.

Redan från början har Operations Manager ett antal Kör som-konton och Kör som-profiler, och du kan skapa fler efter behov. Du kan även välja att ändra de Active Directory-autentiseringsuppgifter som Kör som-konton är kopplade till. Detta kräver att du planerar, skapar och hanterar ytterligare Active Directory-autentiseringsuppgifter för det här syftet. Du bör hantera dessa konton som tjänstkonton när det gäller utgångna lösenord, Active Directory Domain Services, plats och säkerhet.

Du måste samarbeta med hanteringspaketens författare när de utvecklar begäranden för Kör som-konton. Mer information finns i Index to Security-related Information for Operations Manager (Index för säkerhetsrelaterad information för Operations Manager).

Se även

Miljöförutsättningar för Operations Manager

Dela via