Aktuální verze je nyní SCOM 2007 R2, aktualizace Cumulative Update 1 (popisuje Pavel Řepa zde).

Občas musím vysvětlovat některé dotazy, které vás mohou také napadnout, pokud ještě nepracujete se systémem SCOM. Pro zjednodušení zde většinu těchto otázek z poslední doby  zodpovím nebo se o to alespoň pokusím.

1. Logy – záznamy událostí

SCOM umí pracovat s událostmi zaznamenanými  službou Windows Event Log Service – což nikoho nepřekvapí. K dispozici jsou všechny logy v systému Windows, SCOM dokáže události sbírat, reagovat na varovné a chybové stavy výstrahou nebo lze vytvářet dvou či tří-stavové monitory. Monitor se dvěma stavy (v pořádku / problém, chyba) nebo se třemi stavy (v pořádku / varování / problém) lze plně automatizovat. To znamená, že jedna událost překlopí monitor do stavu hlášení chyby s vysláním výstrahy – událost nebo sled událostí zapsaných zdravým systémem může monitor opět překlopit do stavu hlášení bezproblémového běhu sledované služby nebo aplikace.  (Příkladem jsou události Directory service – Active Directory, události služeb SQL Serveru, služeb DNS, DHCP, apod..)  

Služby nebo programy třetích stran nemusejí zapisovat jenom do aplikačního logu prostřednictvím výše uvedené služby. Mnoho aplikací zapisuje do textových souborů a SCOM dokáže na každý takový zápis reagovat a patřičně jej vyhodnotit. K dispozici jsou všechny nástroje: pravidla, monitory, notifikační pravidla.

Agent SCOMu může být konfigurován také jako příjemce zpráv z jiných operačních systémů - serverů nebo síťových zařízení – syslog messages na portu 514 protokolu UDP. Opět jsou k dispozici všechny možnosti systému SCOM .

Síťové prvky lze pomocí SCOMu dohlížet s využitím protokolu SNMP

Přehled pravidel a monitorů ve vazbě na zdroj informace.

2. Nástroje pro vytváření výstupních zpráv – reportů

Implementované reporty jsou integrované do konzoly System Center Operations Manager. Výchozí stav po instalaci systému SCOM s komponentou SCOM Reporting poskytuje základní reporty, které lze parametrizovat a takto upravené ukládat pro opakované použití. Jde o přehledy dostupnosti serverů a služeb, analýzu nejčastějších alertů, sledování latence alertů, konfigurací, výkonových parametrů a po implementaci rozšíření pro systémy UNIX/Linux také reporty pro tyto systémy. Všechny tyto reporty používají jako zdroj dat databázi OperationsManagerDW (data warehouse).

Druhá skupina dodaných reportů představuje poněkud odlišné reporty, které jsou postavené na dotazech do databáze OperationsManagerAC (databáze auditních záznamů systému ACS), viz také můj článek zde. Zdrojová databáze obsahuje záznamy z bezpečnostních logů sledovaných systémů a lze tak reportovat neúspěšné pokusy o přihlášení, zablokování účtů, použití privilegovaných účtů s vysokým oprávněním nebo změny členství ve skupinách administrátorů. K reportům je dodán datový model databáze a lze tudíž při tvorbě nových reportů použít komponentu ReportBuilder.

clip_image002

Při návrhu vlastních reportů můžeme v některých případech výhodně použít i standardní pracovní databázi OperationsManager a vytvořit běžným postupem dotaz SQL do této databáze (samozřejmě lze se dotazovat i v obou dříve zmíněných databázích) – pomocí dodávané verze SQL Server Business Inteligence Development Studio, která je součástí instalace SQL Server reporting Services.

Konkrétní postupy pro některé kategorie reportů podle zdroje dat (jedna ze tří databází) a podle použitého nástroje (Report Builder nebo Development Studio). Jaké nástroje použít v které situaci:

  • ReportBuilder je nástrojem první volby pro zprávy generované z dat shromážděných v databázi systému ACS (databáze OperationsManagerAC na serveru ASPSCOMA). Výhodou je rychlý postup a zkrácená doba návrhu reportu. Nevýhodou je omezená paleta možností formátování výstupu a nástrojů.
  • SQL Server Business Inteligence Development Studio umožňuje využít všech možností formátování výstupů, vkládat vlastní kód a procedury použité při zpracování reportu.
  • Parametrizace existujících reportů (Linked Reports) a jejich publikování – jednoduchá metoda úpravy generických reportů z Generic Report Library, dodaných se standardní instalací systému.

Databáze:

  • OperationsManager obsahuje standardně data za 7 dní, k dispozici jsou všechna data v rozsahu importovaných definic Management Packs, tj. výstrahy (alerts), záznamy událostí (events), výkonové parametry (performance data).
  • OperationsManagerDW obsahuje standardně data záznamů událostí za 100 dnů, data výstrah za 400 dnů, neagregovaná data stavů za 180 dnů a neagregovaná výkonová data za 10 dnů. Výkonová data a stavová data agregovaná po hodinách a po dnech se uchovávají 400 dnů.
  • OperationsManagerAC obsahuje data za 14 dnů, jsou to záznamy ze Security Logs všech monitorovaných systémů.

3. Informace odesílané prostřednictvím komunikačních kanálů

image

K dispozici je rozhraní pro odesílání zpráv pomocí protokolu SMTP na servery elektronické pošty, dále na server IM (instant messaging) nebo krátké textové zprávy SMS. Poslední možností posílání upozornění je velice užitečné a univerzální řešení voláním externí dávky, skriptu VBS nebo skriptu napsaného v PowerShellu.

Nejprve definujeme komunikační kanály a příjemce zpráv upozornění. Poté může přistoupit k definici pravidel (notification subscription), ve kterých je stanoveno, jaké úrovně musí výstraha být, která dohledová pravidla ji generují a lze stanovit mnoho dalších kritérií, která musejí být splněna, aby bylo upozornění odesláno, včetně časového okna, kdy je přípustné zprávy posílat.

4. Vyhledání konkrétní aktivity – přihlášení uživatele

Pro dohledání přihlášení uživatele rozlišujeme použití lokálního účtu na konkrétním serveru a použití doménového účtu. V prvním případě vyhodnocujeme a vyhledáváme záznamy událostí z konkrétního serveru, v druhém případě musíme zajistit sběr záznamů událostí ze všech doménových řadičů. Díky jejich vzájemné zastupitelnosti může doménového uživatele ověřit kterýkoliv z nich. Systém ACS sbírá tyto záznamy v reálném čase a v jeho databázi pak můžeme pomocí vhodně definovaných a parametrizovaných reportů vytvářet výstupy a přehledy o různých aktivitách uživatelů ve zvoleném období. Zde je nutné připomenout, k čemu tato databáze slouží – je to zdroj informací o aktivitách na sledovaných serverech ve zvoleném období. Vzhledem k velikosti databáze (standardně obsahuje záznamy za 14 dnů) je vždy třeba najít kompromis mezi maximálním stářím dat v databázi a její únosnou velikostí. Vždy to závisí na technických prostředcích, které máme k dispozici na serveru s databází ACS. Osobně bych byl opatrný s historií delší než 30 dnů a s velikostí databáze ACS nad 100 GB.

Dodané standardní reporty pro audit jsou v současné době:

Access Violation - Account Locked
Access Violation - Unsuccessful Logon Attempts
Account Management - Domain and Built-in Administrators Changes
Account Management - Passwords Change Attempts by Non-owner
Account Management - User Accounts Created
Account Management - User Accounts Deleted
Audit5 Report Template
Audit Report Template
Forensic - All Events For Specified Computer
Forensic - All Events For Specified User
Forensic - All Events With Specified Event ID
Planning - Event Counts
Planning - Event Counts by Computer
Planning - Hourly Event Distribution
Planning - Logon Counts of Privileged Users
Policy - Account Policy Changed
Policy - Audit Policy Changed
Policy - Object Permissions Changed
Policy - Privilege Added Or Removed
System Integrity - Audit Failure
System Integrity - Audit Log Cleared
Usage - Object Access
Usage - Privileged logon
Usage - Sensitive Security Groups Changes
Usage - User Logon

Použití ReportBuilderu při vytvoření čtyř reportů z databáze ACS je např. na blogu DSE (Audit Report Scenarios: How to create custom reports with System Center Operations Manager 2007 R2 and Audit Collection Services (ACS))

  • Scenario 1: Computers joined to the domain (names and description)
  • Scenario 2: User passwords expired
  • Scenario 3: User accounts locked out
  • Scenario 4: Group policy changes

Reakce na přihlášení  privilegovaného účtu ADMIN / změnu členství Admins – řešíme pravidlem v SCOM, nikoliv dotazem v databázi ACS. Pravidlo lze definovat tak, že např. po zvoleném počtu neplatných pokusů generuje výstrahu a notifikační pravidlo pak odešle zprávu (e-mail, SMS, InstantMessage)

Podrobné postupy pro čtyři scénáře jsou na stejném blogu DSE (Audit Alert Scenarios System Center Operations Manager (OpsMgr) 2007 R2):

  • Scenario 1: Alert for changes to the ‘Domain Admin’ group membership
  • Scenario 2: Alert when the Audit Policy is changed (Default Domain or Domain Controller)
  • Scenario 3: Alert when xx number of unsuccessful logons occur within nn hours
  • Scenario 4: Account locked out x number of times in a 24 hour period

5. Statistika událostí a výstrah (alert)

Pokud nás zajímá např. počet událostí ve zvoleném období pro vybrané servery, které generovaly výstrahu úrovně Critical / High, je to úkol pro reporty pracující s daty v data warehouse

Základní knihovny výstupů pomocí reportů jsou Generic Report + ODR Report Library: (ODR = operational data reports)

  image image

6. Historická data

Databáze SCOMu a ACS uchovávají data pouze stanovenou dobu. Můžeme ji prodloužit nebo zkrátit podle potřeb našeho konkrétního provozu, ale po určité době jsou data z databáze odstraněna. Charakter použití pracovní databáze a data warehouse je rozdílný, na jedné straně jsou provozní data a informace o právě řešených problémech, takže doba jejich uchování jeden týden je ve většině případů dostatečná. Na druhé straně jsou data určená k zobrazení v grafech a přehledových tabulkách, takže se v databázi udržují celý rok. Slouží k vykreslení trendů zátěže, zaplňování disků, dostupnosti služeb v čase. Roční doba uchování dat je pro tento způsob využití uložených informací rozumný kompromis a vyhovuje i použití výstupů v přehledech použitých v plánování rozvoje sledovaných systémů.

Odlišný je charakter dat uložených v databázi ACS a charakter jejich využití. Informace zde uložené mají sloužit pro vysledování stop, které zanechá v systémech uživatel s nekalými úmysly nebo vysledování obecného bezpečnostního problému. Potom nemusí být standardní doba uchování dat (dva týdny) dostatečná. Prodloužením dosáhneme i několikanásobně delšího časového “okna”, ale jsou případy, kdy je předpisy požadováno uchovat auditní informace i několik let. V takovém případě nastupují řešení třetích firem, zde uvedu jen nejznámější Secure Vantage a jejich Archiver. Zaznamenal jsem i řešení “uživatelské” – založené na pravidelném archivování databáze ACS, například ve standardním dvoutýdenním cyklu. Požadovaná historická data se potom zpřístupní v odděleném databázovém systému a modifikací standardních reportů je možné v nich vyhledat žádanou informaci.

7. Demonstrace a vlastní zkušenosti se systémem SCOM

Před časem jsem zde uváděl výběr odkazů ze stránky MSevents, to jsem napočítal pouhé tři položky týkající se SCOM verze R2. Dnes je zde k dispozici několik virtuálních testovacích labů a dlouhá řada záznamů přednášek s vizuální demonstrací. Zvukové záznamy nepočítám. Vlastní zkušenosti získáte nejen v testovacím labu, který je vám k dispozici jeden a půl hodiny, ale také zkušební verzi Microsoft System Center Operations Manager 2007 R2 Evaluation Download – ta vám vydrží 180 dní.