Eigene Policies in Grid Control ab 10.2.0.5
Ralf Durben

Oracle Enterprise Manager Grid Control ermöglicht im Rahmen des lizenzpflichtigen Configuration Management Packs die Überprüfung der ermittelten Konfigurationsdaten mittels Policies. Dabei handelt es sich  um Regeln, die eine korrekte Konfiguration sicherstellen. Diese Regeln sind zum Beispiel sehr hilfreich, wenn es darum geht, Sicherheitslücken  durch falsche Konfiguration aufzudecken. Es kommt zum Beispiel immer wieder vor, daß Anwendungen ausnahmsweise ein Skript laufen lassen müssen, unter dem Datenbankbenutzer SYSTEM. Dazu setzen manche DBAs das  Passwort auf den Standard (manager). Das ist schon schlimm genug, aber  oft wird dann vergessen das Passwort nach Ablauf des Scripts wieder zu  verändern. Und schon ist die Datenbank offen wie ein Scheunentor.

Oracle liefert eine große Menge derartiger Policies, jedoch gibt es  Situationen, in denen man eine eigene Policy erstellen möchte.  Das Erstellen eigener Policies ist in Grid Control 10.2.0.4 zwar  prinzipiell möglich, aber nicht in der GUI, sondern nur mit viel Mühe. Ab dem Patchset 10.2.0.5 ändert sich das: Man kann sehr einfach eigene  Policies erstellen.

Bevor eine eigene Policy erstellt wird, muss jedoch zunächst einmal über die Datenquelle nachgedacht werden. Eine Policy in Grid Control prüft nämlich nicht Daten direkt in einem Zielsystem, sondern nur Daten, die im Grid Control Repository gespeichert sind. Bevor also eine neue Policy erstellt werden kann, muß überprüft werden, ob der Oracle Management  Agent die notwendigen Daten im Rahmen des Konfigurationsmanagements sowieso schon ermittelt, oder ob man selbst die Ermittlung programmieren muß.

Die Datenquelle für eine Policy ist die View SYSMAN.ESM_COLLECTION_LATEST, bzw. die Tabelle SYSMAN.ESM_COLLECTION.  Dort sind drei Spalten von Wichtigkeit: PROPERTY, VALUE und VALUE2. Wenn die Daten, die man für die neue Policy braucht, dort schon vorhanden  sind, kann man direkt mit dem Erstellen der Policy anfangen (siehe  unten).

Wenn das nicht der Fall ist, müssen die Daten erst erhoben werden. Ich stelle dazu eine einfache Variante vor:

In der Zieldatenbank wird eine Tabelle mit den drei Spalten PROPERTY,  VALUE, VALUE2 erstellt. Diese Tabelle kann dann von verschiedenen Skripten gefüllt werden. Der Oracle Management Agent holt in regelmäßigen Abständen diese Daten ab und transportiert diese in das Repository.

Die Tabelle erstellt man mit

create table sys.dba_userdefined_configdata (
property varchar2(64),
value varchar2(512),
value2 varchar2(512));

Da der Oracle Management Agent mit dem Benutzer DBSNMP arbeitet, vergeben Sie das Leserecht auf die neue Tabelle an diesen Benutzer.

grant select on sys.dba_userdefined_configdata to dbsnmp;

Den Agenten muss man neu konfigurieren. Dazu wird die Datei  "$AGENT_HOME/sysman/admin/default_collection/database.xmlp" wie folgt verändert (vorher besser eine Kopie des Originals erstellen): Suchen Sie die Zeile

<MetricColl NAME="proxyAccount" />

und fügen die untenstehende Zeile hinzu

<MetricColl NAME="userDefined" />

Jetzt muss die Datei "$AGENT_HOME/sysman/admin/metadata/database.xmlp" geändert werden (vorher besser eine Kopie des Originals erstellen):  Suchen Sie die Zeile

<Metric NAME="unlimitedFailedLoginAttempts" TYPE="RAW" CONFIG="TRUE".......

Scrollen Sie weiter nach unten bis Sie </Metric> finden und fügen dann den folgenden Block ein:

<Metric NAME="userDefined" TYPE="RAW" CONFIG="TRUE" KEYS_ONLY="TRUE" HELP="NO_HELP" >
<ValidIf>
<CategoryProp NAME="VersionCategory" CHOICES="8iR2;9i;9iR2;10gR1;10gR2;10gR203;11gR1"/>
<CategoryProp NAME="MetricScope" CHOICES="DB"/>
</ValidIf>
<Display>
<Label NLSID="user_defined">User defined Policy data</Label>
</Display>
<TableDescriptor TABLE_NAME="esm_collection">
<ColumnDescriptor NAME="property" COLUMN_NAME="property" TYPE="STRING" IS_KEY="TRUE" HELP="NO_HELP">
</ColumnDescriptor>
<ColumnDescriptor NAME="value" COLUMN_NAME="value" TYPE="STRING" IS_KEY="TRUE" HELP="NO_HELP">
</ColumnDescriptor>
<ColumnDescriptor NAME="value2" COLUMN_NAME="value2" TYPE="STRING" IS_KEY="TRUE" HELP="NO_HELP"/>
</TableDescriptor>
<QueryDescriptor FETCHLET_ID="SQL">
<Property NAME="STATEMENT" SCOPE="GLOBAL">
<![CDATA[
select property,value,value2
from sys.dba_userdefined_configdata
]]></Property>
<Property NAME="MachineName" SCOPE="INSTANCE">MachineName</Property>
<Property NAME="Port" SCOPE="INSTANCE">Port</Property>
<Property NAME="SID" SCOPE="INSTANCE">SID</Property>
<Property NAME="UserName" SCOPE="INSTANCE">UserName</Property>
<Property NAME="password" SCOPE="INSTANCE">password</Property>
<Property NAME="Role" SCOPE="INSTANCE" OPTIONAL="TRUE">Role</Property>
</QueryDescriptor>
</Metric>

Der Agent muss diese neue Einstellung übernehmen. Dazu stoppen Sie diesen und starten ihn neu

./emctl stop agent
./emctl start agent

Wenn Sie den Metric Browser des Agenten eingeschaltet haben (wie das geht siehe hier), sollten Sie jetzt bei den Datenbankmetriken die neue Metrik "userDefined" finden.

Bis die Daten jedoch in das Grid Control Repository übertragen werden, kann es eine lange Zeit dauern, denn diese werden normalerweise nur alle 24 Stunden erhoben und übertragen. Diesen Zeitraum kann man zumindest für die Entwicklungsphase auf dem Testagenten verändern, indem man in  der Datei

"$AGENT_HOME/sysman/admin/default_collection/database.xmlp"

das  Zeitintervall verändert, wie zum Beispiel:

<CollectionItem NAME = "oracle_security" UPLOAD_ON_FETCH = "TRUE" CONFIG = "TRUE">
<ValidIf>
<CategoryProp NAME="VersionCategory" CHOICES="8iR2;9i;9iR2;10gR1;10gR2;10gR203;11gR1;11gR2"/>
</ValidIf>
<Schedule OFFSET_TYPE="INCREMENTAL">
<IntervalSchedule INTERVAL = "5" TIME_UNIT = "Min"/>
</Schedule>

Jetzt kann man die Tabelle dba_userdefined_configdata mit einer  Testzeile füllen und nach spätestens 5 Minuten ist diese Zeile in sysman.esm_collection_latest angekommen. Mit diesem Mechanismus kann man beliebig Konfigurationsdaten auf dem  Zielsystem erheben und übertragen, ohne ständig den Agenten neu konfigurieren zu müssen.

Wenden wir uns nun dem eigentlichen Thema zu: Das Erstellen einer  eigenen Policy. Navigieren Sie dazu auf "Compliance"->"Library". Dort finden Sie  einen "Create"-Button, den Sie betätigen.

Auf der ersten Seite geben Sie den Namen der neuen Policy, sowie Kategory und Schweregrad ein. Desweiteren können Sie eine Beschreibung und eine Anleitung zur Beseitigung des Problems hinterlegen. Klicken Sie auf "Next" und Sie kommen auf die zweite Seite.

Hier wird das SQL Statement eingegeben. Wie gesagt, man greift hier auf  die View esm_collection_latest zu und kann mit den drei Spalten PROPERTY, VALUE und VALUE2 arbeiten. Das SELECT Statement muss immer als erste Spalte die target_guid abfragen. Für die anderen Spalten vergeben sie Aliasse, wie zum Beispiel STATUS oder INFO. Mit dem Button "Validate SQL" können Sie prüfen, ob das SELECT-Statement funktioniert.  Klicken Sie dann auf "NEXT".

Jetzt geben Sie den Schwellenwert ein, der angibt, wann die Policy (Regel) verletzt sein soll. Auf den nächsten Seiten können Sie die Policy für einen Target testen und dann festlegen, wie oft die  Überprüfung der Konfigurationsdaten erfolgen soll. Das kann zeitgesteuert (z.B. alle 48 Stunden) oder eventgesteuert (bei jeden  Upload) sein. Mit dem "Finish"-Button erstellen sie die Policy.

Die neue Policy erscheint nun in der Policy-Library, wird aber noch  nicht genutzt. Dazu benötigen Sie ein Monitoring Template, entweder ein neues oder ein schon genutztes. Navigieren Sie hierzu über  "Setup"->"Monitoring Templates". Dort fügen Sie die neue Policy zu  der Liste der bereits aktiven Policies hinzu. Nachdem Sie das Monitoring Template erstellt, bzw. geändert haben (mit OK bestätigt), muss dieses nun auch den Agenten mitgeteilt werden. Dazu selektieren Sie das Monitoring Template und klicken auf "Apply". Wählen Sie nun die Agenten  aus und klicken auf "OK".

Ob eine Policy für ein target überhaupt genutzt wird püfen Sie in der  Policy-Library ("Compliance"->"Library"), indem Sie die neue Policy suchen.

Sie sehen, in wievielen Monitoring Templates die neue Policy verwendet wird, bzw. für wieviele Targets.

Mit dieser Anleitung können Sie sehr einfach eigene Policies erstellen und so auch unabhängig von den mitgelieferten Policies eine umfassende Konfigurationsprüfung durchführen.

Zu beachten ist dabei, daß Policies eine Funktionalität des  Configuration Management Packs von Oracle sind und separat zu lizenzieren sind. Desweiteren ist eine derartige Lizenzierung nur für  die Enterprise Edition der Datenbank möglich! Eigene Policies dürfen Sie also nur anlegen, wenn Sie eine entsprechende Lizenz haben.

Zurück zur Tippübersicht

Zurück zur Tippübersicht