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.