25. Februar 2011

Data theft: Monitor only selects with a resultset higher than 30

Oft haben meine Kunden eine genaue Vorstellung ihre Datenbanken zu überwachen. Ein gemeinsamer Nenner unterschiedlicher Kunden ist der Wunsch alle SELECTS zu kennen, die eine bestimmte Menge von Datensätzen selektiert haben:
sagen wir mal alle SELECT where SQL%ROWCOUNT > 30

Warum will man das wissen?
Dieser Wunsch ist ganz einfach zu beantworten. In der Regel nutzen die Endanwender Anwendungen wie z.B. Oracle Forms oder SAP oder andere Standardanwendungen. Durch die Anwendungen bekommt man i.d.R. einen Datenzugriff auf die Datenbank und kann Veränderungen an den Daten vornehmen. In der Regel arbeitet man genau auf einen Datensatz. Wenn man nun alle SELECTS kennt, die eine Ergebnismenge > 30 Datensätze ermittelt haben, kann  man davon ausgehen, dass eine höhere Wahrscheinlichkeit eines Datendiebstahls vorliegt.

15. Februar 2011

Oracle Information Rights Management

In der aktuellen Ausgabe der DOAG News 1/2011 habe ich einen Artikel zum Thema Oracle IRM veröffentlicht. Wer auf diesen Artikel kein Zugriff hat, kann unseren Oracle IRM Hands-on Workshop am 8.3-9.3.2011 in Potsdam besuchen.
Weitere Details zum Workshop findet Ihr hier.

Oracle Information Rights Management - Reports mit BI Publisher

Eines der richtig coolen Security Lösungen von Oracle ist in der Tat Oracle Information Rights Management. Diese Lösung gruppiert Oracle mittlerweile in die Gruppe der Identity  Management Lösungen. Wer sich in diesem Bereich auskennt, der weiß, dass alle Identity Management Lösungen von Oracle mit verschiedenen vorgefertigten BI Publisher Reports ausgeliefert werden.

Leider ist das nicht so bei der Oracle Informations Rights Management Lösung. Daher habe ich einen BI Publisher Report implementiert, den man gegen das Oracle IRM Repository ablaufen lassen kann.

Was muss man hierfür tun?
  • Im BI Publisher wird die Datenquelle eingerichtet. Hierfür definiert man eine JDBC Datenquelle
  • Sobald die Datenquelle eingerichtet ist, kann man einen Report anlegen und die entsprechenden Daten aus der Datenbank selektieren. Ich habe mich wegen der Übersichtlichkeit entschieden, ein concatenated Statement zu definieren, das aus vier Einzel-Select besteht. Der BI Publisher fasst das Ergebnis wunderbar zusammen:
IRM_AUDIT-DATA: 
select ll.name CONTEXT_NAME,
 cje.item_code_value DOCUMENT,
 to_char(je.time,'MM-DD-YYYY HH24:MI:SS') ACTION_TIME,
 je.feature_id ACTION,
 je.ACCOUNT_NAME ACCOUNT_NAME,
 je.status ACTION_STATUS,
 je.URI DOCUMENT_URI,
 je.DESKTOP_VERSION IRM_DESKTOP_VERSION,
 je.OS OS,
 je.APPLICATION APPLICATION,
 je.CONTAINER CONTAINER,
 je.DEVICE_NAME DEVICE_NAME
 from context_journal_entry cje,
 journal_entry je,
 context_instance_labels cil,
 label ll
where cje.context_instance_id = cil.context_instance_id
 and cil.label_id = ll.label_id
 and cje.journal_entry_id = je.journal_entry_id
 and ( upper(cje.item_code_value) like nvl(upper(:DOCUMENT_NAME),'%')
 and upper(ll.name) like nvl(upper(:CONTEXT_NAME),'%')
 and upper(je.ACCOUNT_NAME) like nvl(upper(:USER_NAME),'%')
 and je.time >= nvl(:START_DATE, sysdate-2000)
 and je.time <= nvl(:END_DATE, sysdate+1)
 )
DOC-SUMMARY: select cje.item_code_value DOCUMENT,
 je.feature_id ACTION,
 ll.name CONTEXT_NAME,
 count(je.feature_id) Count_Action 
 from context_journal_entry cje,
 journal_entry je,
 context_instance_labels cil,
 label ll
where cje.journal_entry_id = je.journal_entry_id 
 and cje.context_instance_id = cil.context_instance_id
 and cil.label_id = ll.label_id
 and je.status = 'SUCCESS'
and ( upper(cje.item_code_value) like nvl(upper(:DOCUMENT_NAME),'%')
 and upper(ll.name) like nvl(upper(:CONTEXT_NAME),'%')
 and upper(je.ACCOUNT_NAME) like nvl(upper(:USER_NAME),'%')
 and je.time >= nvl(:START_DATE, sysdate-2000)
 and je.time <= nvl(:END_DATE, sysdate+1)
 )
group by cje.item_code_value, je.feature_id, ll.name
PARAMETERS: select nvl(to_char(:START_DATE,'dd-mm-yyyy'),'No Start Date') START_DATE, 
 nvl(to_char(:END_DATE,'dd-mm-yyyy'),'No End Date') END_DATE, 
 nvl(:USER_NAME,'All') USER_NAME, 
 nvl(:DOCUMENT_NAME,'All') DOCUMENT_NAME, 
 nvl(:CONTEXT_NAME,'All') CONTEXT_NAME
from dual
FAILED_DOC_SUMMARY:select cje.item_code_value DOCUMENT,
 je.feature_id ACTION,
 ll.name CONTEXT_NAME,
 count(je.feature_id) Count_Action 
 from journal_entry je,
 context_journal_entry cje,
 context_instance_labels cil,
 label ll
where je.journal_entry_id = cje.journal_entry_id
 and cje.context_instance_id = cil.context_instance_id
 and cil.label_id = ll.label_id
 and je.status = 'FAILURE'
 and ( upper(cje.item_code_value) like nvl(upper(:DOCUMENT_NAME),'%')
 and upper(ll.name) like nvl(upper(:CONTEXT_NAME),'%')
 and upper(je.ACCOUNT_NAME) like nvl(upper(:USER_NAME),'%')
 and je.time >= nvl(:START_DATE, sysdate-2000)
 and je.time <= nvl(:END_DATE, sysdate+1)
 )
group by cje.item_code_value, je.feature_id, ll.name
  • Im BI Publisher sieht der Editier-Modus wie nachfolgend aufgeführt aus
  •  Sobald das concatenated Select Statement eingerichtet ist, kann man mit dem BI Publisher den Report ausführen und erhält nur XML Daten, da wir noch kein Template definiert haben. 
  • Nun exportiert man die Daten in ein XML-File und nutzt diese Informationen, um z.B. mit Word ein Layout-Template zu definieren (Vorher BI Publisher Desktop installieren). Die Template Erstellung funktioniert ähnlich einem Serienbrief. (in der Version 11g kann man auch den Online Layout Builder nutzen). Ist das Layout definiert, so kann man die Layout Datei dem Report zuordnen und fertig ist der Report. 
  • Die Profis unter Euch können dann noch Parameter definieren, um so das Ergebnis im Report besser einschränken zu können.
Das Ergebnis meines Reports sieht dann wie folgt aus und ist automatisch in verschiedenen Ausgabeformate wie PDF, Word, Excel, HTML etc. generierbar:

Wer das komplette BI Publisher IRM Report Paket haben möchte, sendet mir einfach eine Email.

10. Februar 2011

Sicherere Anlage von DB Links

Datenbank Links sind ein einfaches Mittel, um Daten zwischen verschiedenen Datenbank auszutauschen. Ein Datenbank Link speichert die Credential-Information zu der verlinkten Datenbank und so entsteht ein transparenter Zugriff in eine entfernte Datenbank.
Oft findet man Datenbank Links in Webshop Anwendungen. In der DMZ befindet sich der Onlinekatalog, der mit der internen ERP Datenbank über einen Datenbank Link verbunden ist und die aktuellen Daten synchronisiert wie Bestellungen, Lagerbestände etc. Ein direkter Zugang zu der internen DB ist somit entstanden. Die Daten werden dann über verschiedene Konzepte wie z.B. Snaphshots oder MViews ausgetauscht.

Damit man nun den direkten Zugang zu der entfernten DB etwas sicherer verschleiern kann, schlage ich folgendes Vorgehen vor:
Sicherere Anlage von DB Links in einer Oracle DB
  • Es wird grundsätzlich pro Datenbank ein Public Database Link angelegt. Dieser Link enthält die Informationen CONNECT TO mit einem falschen Benutzernamen und Kennwort sowie USING connect_string.
Create public database link dblink@db1 connect to 9292929 identified by 737373 using DB1;
  • Zusätzlich zu diesem Link wird ein Privat-Link mit der Connect-Klausel unter demselben Database link Namen angelegt, aber ohne USING Klausel.
Create database link dblink@db1 connect to scott identified by tiger;
Somit hat man die Credential Informationen etwas verschleiert und etwas mehr Sicherheit erzeugt.