Autor: Jürgen Esser

Veröffentlicht am

Berechtigungskonzepte

Zu den Anforderungen an die Erstellung von Berechtigungskonzepten bzgl. der Vergabe von Rollen und Berechtigungen in IT-Systemen gehören z.B.:

    • Rollen und Berechtigungen müssen das „Need-to-know-Prinzip“ umsetzen.
    • Rollen und Berechtigungen müssen das Prinzip der minimalen Rechtevergabe („Least privilege principle“) umsetzen.
    • Rollen und Berechtigungen müssen das Prinzip der Gewaltenteilung („Segregation of duties“) umsetzen.
    • Die aus den Geschäftsprozessen abgeleiteten Rollen SOLLTEN im Berechtigungskonzept weiter differenziert werden, um jeder Rolle möglichst spezifische Zugriffsrechte zuordnen zu können.
    • Für jede Rolle müssen mindestens die eindeutige Bezeichnung, eine Beschreibung der Aufgaben, Rechte und Pflichten im Kontext der Anwendung und die Zuordnung der hierfür notwendigen Funktionen zur Rolle spezifiziert sein
    • Neben den Benutzer-Rollen müssen die administrativen/betrieblichen Rollen des IT-Systems spezifiziert und beschrieben sein.
    • Rollen und Berechtigungen müssen für jede Systemumgebung (Produktiv-, Entwicklungs-, und Abnahmeumgebung) unabhängig und individuell zugeordnet werden.
Veröffentlicht am

Datennutzung im Rahmen von Softwaretests

In vielen Unternehmen wird im Rahmen der Softwareentwicklung nach wie vor mit produktiven Daten getestet, obwohl gem. geltender Datenschutzbestimmungen (BDSG & TKG) keine nicht anonymisierten Produktionsdaten verwendet werden dürfen.

Daher ist es generell und insbesondere für den Off- und NearShore Entwicklungs- und Testbereich sehr wichtig geeignete Verfahren zu entwickeln, wie konsistente Testdaten für einfache sowie für komplexe System-Integrations-, Verbund- und Solutiontests mit zahlreichen Schnittstellen generiert werden können, bei denen die referentielle Integrität für wesentliche Schlüsselfelder erhalten bleiben muss.

Hierzu kommen grundsätzlich in Frage:

1.    Anonymisierte Produktionsdaten für

    • Cube- und Reportentwicklung im DWH-Umfeld
    • Performance-, Integrations- und Solutionstest
    • User Acceptance Tests der Fachseiten

2.    Synthetische Testdaten für

    • Entwicklertests
    • automatisierte Regressionstests.

Da nicht jede Art von Testdaten (anonymisierte oder synthetische Daten) für jeden Test geeignet ist, muss im Vorfeld genau überlegt werden, welche Daten wofür erzeugt werden müssen, um die Anforderungen des Datenschutzes sowie die individuellen Testanforderungen zu erfüllen.

Derzeit auf dem Markt verfügbare Lösungen zur Generierung von Testdaten sind z.B. Oracle Data Masking, IBM Optim, Micro Focus Data Express, AXIS DM Suite.

Darüber hinaus lassen sich auch individuell entwickelte Lösungen in vielen Bereichen sehr gut bzw. wegen der optimalen Anpassung an die jeweiligen Testanforderungen z.T. sogar besser einsetzen als vergleichbare Standardlösungen.

Veröffentlicht am

Begriffe im Testdatenumfeld

Im Testdatenumfeld werden häufig verschiedene Begriffe verwendet, die nachfolgend erläutert werden:

    • Anonymisierung: die schützenswerten Informationen werden hier so verändert, dass die Einzelangaben nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit und Kosten beispielsweise einer bestimmten natürlichen Person zugeordnet werden können. Von einem solch unverhältnismäßigen Aufwand ist auszugehen, wenn es für die verantwortliche Stelle mit weniger Aufwand verbunden ist, eine erneute Datenerhebung durchzuführen, als die Wiederherstellung des Personenbezugs der faktisch anonymen Daten zu betreiben. Durch eine Anonymisierung sind die Daten nicht mehr personenbezogen.
    • Pseudonymisierung: ein relevantes Identifikationsmerkmal (z.B. Name) wird durch einen anderes Merkmal (Pseudonym) oder eine Buchstabenfolgen ersetzt. Charakteristisch für pseudonyme Daten ist das Bestehen einer Zuordnungsregel, welche die unter einem Pseudonym erfassten Daten den Identifikationsmerkmalen bspw. einer Person zuweist. Pseudonymisierte Daten sind somit niemals absolut anonym sind.
    • Maskierung, Verschlüsselung/Encryption: Sind technische Methoden zu Erreichung der Anonymisierung oder Pseudonymisierung.
    • Synthetisch: synthetische Testdaten werden künstlich erzeugt und haben keinen direkten Bezug zur Realität. Bei der Erzeugung von solchen Daten ist zwingend darauf zu achten, dass eindeutig zu erkennen ist, dass es sich hierbei um synthetische Daten handelt.
Veröffentlicht am

Netzwerksicherheit

Eine umfassende Absicherung von Netzwerken ist eine äußerst anspruchsvolle und komplexe Aufgabenstellung, die sehr individuell auf die jeweiligen Kundenbedürfnisse zugeschnitten werden muss. Eine Vielzahl von Faktoren entscheidet über die zu ergreifenden Maßnahmen.

Hierzu gehören z.B. die erforderliche Systemverfügbarkeit oder die Sensibilität der zu schützenden Daten.

Jede Beeinträchtigung der Netzwerksicherheit führt zu immensen Kosten für Unternehmen, sei es durch Datenverlust, Produktionsunterbrechungen oder sogar Imageschäden. Daher ist ein bewusster Umgang mit der IT-Sicherheit eine lohnende Investition und ein entscheidender Wettbewerbsfaktor.

Maßnahmen zur Netzwerksicherheit verhindern den unberechtigten Zugriff auf zentral vorgehaltene Server und Daten-Systeme.

Wesentliche Maßnahmen sind:

    • Optimierung der Kommunikationsverbindungen
    • Authentisierung von Netzwerkgeräten
    • Network Access Control (NAC)
    • Network Segregation
      • Separierung der Applikationen / Serversysteme vom Office-Netz
      • 3-Layer Network Segregation
      • Trennung in unterschiedliche Domänen für Produktion, Test und Abnahme und Entwicklung
    • SINA Business (Virtual Private Networks)
    • Kontrolle des 3rd Party Access
    • Verschlüsselte Kommunikation intern / extern
    • Sperrung von USB-Sticks / Massenspeicher
    • Reduzierung der Mailanhang-Größe nach außen
    • E-Mail-Verschlüsselung
    • Data Loss Prevention (DLP)
    • Log-Management
    • Firewalls inkl. Freischaltungs- und Sperrprozesse
      • Etablierung eines Prozess zur Verwaltung von Firewall Regeln
      • Dokumentation der komplexen Firewallregelwerke
      • Einhaltung von Regularien (Compliance)
      • Vereinheitlichung und Integration der Prozessabläufe
      • Einrichtung eines FW-Lifecycle-Managements und Etablierung eines Freigabe-Workflows
      • Automation von Administration und Freigabeverfahren
      • Dokumentation aller Anfragen und Änderungen
      • Auditierbarkeit durch lückenlose Dokumentation
      • Sicherstellung von kundenspezifischen Service Level Agreements (SLAs)
    • Web Application Firewall
    • Layer2-Verschlüsselung
    • Managed Security Services
    • Sicherer Systemzugang
      • Einschränkung des Zugang zu tieferen Schichten für Nutzer und Dienste für Wartung / Instandhaltungszwecke
      • Vermeidung unsicherer Zugänge durch Konsolidierung der Dienstleisterzugriffe auf wenige technisch definierte und spezifizierte DMZ über das Internet
      • Nutzung von JumpHosts für Systemzugriff
Veröffentlicht am

Oracle Datenbank Glossar

Hier finden Sie kurz zusammengefasste Informationen zu wichtigen Begriffen rund um Oracle Datenbanken. Alle Begriffe sind – wo sinnvoll – in deutsch und englisch benannt.

ARCH – ARCHIVER PROCESS

Der Archiver Process archiviert automatisch die Online Redo Log Dateien und hält dadurch alle Änderungen einer Datenbank fest. Erst nachdem eine Online Redo Log Datei archiviert wurde, kann sie wieder beschrieben werde.

Voraussetzung: Die Datenbank muss im ARCHIVELOG Modus laufen und die Archivierung aktiviert sein.

BUFFER CACHE

Im BUFFER CACHE werden die verwendeten Datenblöcke gespeichert. Der Speicher wird über einen LRU-Algorithmus (Least Recently Used) verwaltet. Dadurch werden die Blöcke, die am häufigsten gebraucht werden, immer im Speicher gehalten. Die Größe des BUFFER CACHE wird durch die Initialisierungs-Parameter DB_BLOCK_SIZE und DB_BLOCK_BUFFERS festgelegt.

Data Dictionary Views: V$BUFFER_POOL, V$BUFFER_POOL_STATISTICS

CKPT – CHECKPOINT PROCESS

Bei einem Checkpoint veranlasst der Checkpoint Process den DBWR alle „dirty“ Blöcke aus dem Buffer Cache in die Datendateien zu schreiben und synchronisiert alle Datendateien und die Kontrolldatei.

COLLECTION

Collection ist ein Überbegriff für die Array-Datenypen in PL/SQL, also:

    • Varray
    • Nested Table
    • Index By Table (auch PL/SQL Table, ab Version 9.2: Associative Array)

DATENBANK – DATABASE

Unter dem Begriff Datenbank versteht man den passiven Teil eines Datenbank-Systems – alle Datenbankdateien mit all den darin enthaltenen Informationen:

    • Datendateien
    • Steuerdateien
    • Redologdateien
    • INIT.ORA Datei

Data Dictionary Views: V$DATABASE, V$DATAFILE

DATENBLOCK – DATA BLOCK

Ein Datenblock ist die kleinste physikalische Einheit, die Oracle zum Speichern von Daten verwendet. Der Wert wird bestimmt über den Initialisierungsparameter DB_BLOCK_SIZE (2KB – 32KB).

Bis Oracle 8i kann nur eine Blockgröße für die gesamte Datenbank definiert werden (dies geschieht beim Erzeugen der Datenbank). Ab Oracle 9i können bis zu fünf verschiedene Blockgrößen definiert werden.

Data Dictionary Views: V$PARAMETER

DATENDATEI – DATAFILE

Die Datendatei ist eine ganz normale Betriebssystemdatei, in die jedoch nie direkt von einem Userprozess geschrieben wird. Eine Datendatei ist immer genau einem Tablespace zugewiesen und stellt somit den physikalischen Speicher für diesen zur Verfügung.

Datendateien werden in der OPEN Phase von der Datenbank geöffnet.

Data Dictionary Views: DBA_DATA_FILES, ALL_DATA_FILES, USER_DATA_FILES,
V$DATAFILE, V$BACKUP, V$RECOVER_FILE

DBWn – DATABASE WRITER PROCESS

Der DATABASE WRITER PROCESS schreibt „dirty“ Blöcke aus dem Buffer Cache in die Datendateien.

Mit dem Initialisierungs-Parameter DB_WRITER_PROCESSES können Sie die Anzahl der DBWn-Prozesse festlegen (max. 9 Prozesse).

EQUIJOIN

Bei dieser Form des Join werden die Tabellen über ein Gleichheitszeichen verknüpft: der Wert einer Spalte in der ersten Tabelle muss genau dem Wert einer Spalte in der zweiten Tabelle entsprechen. Zeilen ohne Entsprechung in der jeweils anderen Tabelle werden nicht ausgewählt.

Ab Version 9i wird diese Art des Join auch als Inner Join bezeichnet, falls bei der Syntax die ANSI-Norm verwendet wird. Wenn die zum Join herangezogenen Spalten in den beteiligten Tabellen den gleichen Namen haben, kann (ab 9i) auch ein Natural Join (->Weglassen der Join-Bedingung) verwendet werden

EXTENT

Ein Extent besteht aus mehreren Datenblöcken und stellt einen zusammenhängenden Speicherbereich dar. Oracle allokiert Speicher für einzelne Segmente immer in Extent-Einheiten. Größe und Anzahl von Extents wird bei den jeweiligen Segmenten über die folgenden Storage-Parameter eingestellt:

    • INITIAL
    • NEXT
    • PCTINCREASE
    • MINEXTENTS
    • MAXEXTENTS

Data Dictionary Views: DBA_EXTENTS, DBA_FREE_SPACE, ALL_…, USER_…

INSTANZ – INSTANCE

Eine Instanz stellt den aktiven Teil eines Datenbank-Systems dar – die Hintergrundprozesse und die System Global Area (SGA). Diese werden in der NOMOUNT Phase gestartet bzw. allokiert.

Dazu gehören die folgenden Prozesse:

    • SMON
    • PMON
    • LGWR
    • DBWn
    • CKPT
    • RECO
    • ARCH

Data Dictionary Views: V$INSTANCE, V$PARAMETER, V$SGA, V$SGASTAT

JOB

Ein Job ist eine Aufgabe, die die Datenbank entweder einmalig oder periodisch wiederkehrend automatisch ausführt. Das kann ein Prozeduraufruf, aber auch einzelner Befehl sein. Erstmalige Durchführung, Intervall und Aufgabe werden beim Einrichten (mit dem Package DBMS_JOB)  angegeben.

Voraussetzung für die Ausführung von Jobs ist, dass mindestens ein Hintergrundprozess eingerichtet wurde, der den Job ausführen kann; dazu muss der init.ora-Parameter JOB_QUEUE_PROCESSES auf einen Wert > 0 gesetzt werden. Bis einschließlich 8i kann mit JOB_QUEUE_INTERVAL noch ein Intervall angegeben werden, wie häufig der Prozess aufwacht, um nach zu erledigenden Jobs zu sehen.

DD-Views: dba_jobs, dba_jobs_running

JOIN

Darunter versteht man die Verknüpfung zweier oder mehrerer Tabellen bei einer Abfrage. Ohne Angabe einer Join-Bedingung erhält man ein Kreuzprodukt. Man unterscheidet zwischen

    • Equijoin
    • Self Join
    • Non-Equijoin
    • Outer Join

KREUZPRODUKT

Ein Kreuzprodukt oder kartesisches Produkt entsteht, wenn bei der Verknüpfung zweier Tabellen keine Join-Bedingung angegeben wird. Als Ergebnismenge wird dann jede Zeile der einen Tabelle mit jeder Zeile der anderen Tabelle kombiniert.

Ab Version 9i wird diese Art der Kombination auch als Cross Join bezeichnet, falls bei der Syntax die ANSI-Norm verwendet wird.

LGWR – LOG WRITER

Der LOG WRITER PROCESS schreibt die Einträge aus dem Redo Log Buffer in die Online Redo Log Dateien. Sind die Online Redo Log Dateien gespiegelt, so werden alle MEMBER einer Redo Log Group beschrieben.

NON-EQUIJOIN

Diese Form des Join wird verwendet, wenn es keine geeigneten Spalten in den Tabellen gibt, die über ein Gleichheitszeichen verknüpft werden können. Stattdessen wird ein Wertebereich angegeben; klassischer Operator beim Non-Equijoin ist BETWEEN. Zeilen ohne Entsprechung in der jeweils anderen Tabelle werden nicht ausgewählt.

OUTER JOIN

Bei dieser Form des Join werden die Tabellen ebenso wie beim Equijoin über ein Gleichheitszeichen verknüpft: der Wert einer Spalte in der ersten Tabelle muss genau dem Wert einer Spalte in der zweiten Tabelle entsprechen. Im Unterschied zum Equijoin werden Zeilen einer Tabelle ohne Entsprechung in der anderen Tabelle jedoch schon ausgewählt; es muss angegeben werden, von welcher Tabelle die Zusatzzeilen angegeben werden sollen.

Ab Version 9i kann bei der Syntax auch die ANSI-Norm verwendet werden. Man spricht dann von Left Outer Join, Right Outer Join oder Full Outer Join. Beim Full Outer Join werden aus beiden beteiligten Tabellen die Zeilen ohne Entsprechung in der anderen Tabelle mit ausgewählt.

PMON – PROCESS MONITOR

Nach dem Absturz eines Benutzer-Prozesses rollt der PROCESS MONITOR die offenen Transaktionen zurück, gibt alle von diesem Benutzer gehaltenen Sperren frei (Zeilen, Tabellen) und gibt die vom Benutzer verwendeten Ressourcen wieder frei.

RDBMS

RDBMS ist die Abkürzung für Relationales Datenbank-Management-System. Die Vorteile einer Relationalen Datenbank sind unter anderem:

    • Viele Benutzer können gleichzeitig mit Datenbestand arbeiten
    • Hohe Datensicherheit durch Backup & Recovery Konzepte
    • Verwaltung von großen Datenbeständen
    • Wahrung der Datenkonsistenz und Datenintegrität
    • Einheitliche Sprache für alle Benutzer, Entwickler, Administratoren (SQL)
    • Alle Daten (auch Verwaltungsdaten der DB) liegen in Tabellen
    • Physikalische und logische Datenunabhängigkeit

REDO LOG BUFFER

Im REDO LOG BUFFER werden alle Änderungen einer Datenbank gespeichert. Er wird zyklisch beschrieben und sein Inhalt regelmäßig durch den LGWR in die Online Redo Log Dateien gesichert. Die Größe wird durch den Parameter LOG_BUFFER festgelegt.

REDOLOGDATEI – REDOLOGFILE

In den Redologdateien werden alle Änderungen protokolliert, die in der Datenbank durchgeführt worden sind. Sie sichern die Datenbank dadurch vor Dateifehlern (Redologgruppen immer mit mehreren Mitgliedern anlegen!). Bei einem COMMIT wird der LGWR Prozess veranlasst, die Daten aus dem Redologpuffer in die aktuelle Redologdatei zu schreiben. Erst wenn diese Daten wirklich in der Redologdatei gespeichert sind, erhält der Benutzerprozess die COMMIT-Bestätigung.

Bei einem Recovery der Datenbank werden alle in den Redologdateien protokollierten Änderungen auf die Datendateien angewendet, um diese wieder konsistent zu machen (Rollforward). Im Anschluss werden dann alle noch nicht mit COMMIT abgeschlossenen Transaktionen wieder zurückgerollt (Rollback).

Data Dictionary Views: V$LOG, V$LOGFILE

SCHEMA

Dieser Begriff fasst alle Datenbank-Objekte zusammen, die dem gleichen Datenbank-User gehören. Der Schemaname ist dabei gleich dem Usernamen des Besitzers.

SELF JOIN

Der Self Join ist eine Sonderform des Equijoin: eine Tabelle wird mit sich selbst verknüpft; sie erscheint zweimal unter verschiedenem Alias in der FROM-Klausel.

Ab Version 9i wird auch diese Art des Join auch als Inner Join bezeichnet, falls bei der Syntax die ANSI-Norm verwendet wird.

SHARED POOL

Der SHARED POOL wird zum Parsen und Kompilieren von SQL-Statements verwendet. Er ist in zwei Bereiche, den LIBRARY CACHE und den DATA DICTIONARY CACHE, aufgeteilt. Im LIBRARY CACHE wird der SQL-Text, der geparste Code und der Ausführungsplan gespeichert. Im DATA DICTIONARY CACHE werden Privilegien und Objektdefinitionen (Tabellen-, Spaltendefinitionen, …) gespeichert. Die Größe des SHARED POOL wird durch den Parameter SHARED_POOL_SIZE festgelegt.

Data Dictionary Views: V$LIBRARYCACHE, V$ROWCACHE, V$SQLAREA, V$SQLTEXT, V$DB_OBJECT_CACHE

SMON – SYSTEM MONITOR

Der SYSTEM MONITOR führt freie Extents in einem Dicitonary Managed Tablespace wieder zusammen, gibt temporäre Segmente, die nicht mehr beansprucht werden, wieder frei und führt nach dem Absturz einer Instanz automatisch ein Instanz-Recovery durch.

STEUERDATEI – CONTROLFILE

Die Steuerdatei beinhaltet statische Informationen über den Aufbau der Datenbank. Dies sind u.a.

    • Name und ID der Datenbank
    • die Namen aller Redologdateien sowie deren Nummern und Gruppen-ID’s
    • die Namen aller Datendateien
    • der Status (ONLINE/OFFLINE) der einzelnen Dateien
    • die Redolog Sequenz Nummer (im ARCHIVELOG Modus)
    • die Nummer der aktiven Redologdatei
    • Informationen über die ausgeführten Checkpoints
    • ARCHIVELOG Status der Datenbank
    • Backup-Informationen bei Sicherung mittels RMAN

Eine intakte Steuerdatei ist zwingende Vorraussetzung für den Betrieb einer Datenbank und sollte deshalb auch immer mehrfach vorhanden sein. Diese Spiegelung kann bei der Erzeugung einer Datenbank sehr einfach über den CONTROL_FILES Parameter in der INIT.ORA Datei erreicht werden.

Beispiel:

control_files = (/u1/ORCL/ctl2ORCL.ctl, /u2/ORCL/ctl2ORCL.ctl)

Um im Fehlerfall eine Datenbank wieder rekonstruieren zu können, sollten Sie nach Strukturänderungen (z.B. neuer Tablespace oder neue Datei) immer eine Kopie der aktuellen Steuerdatei erstellen. Sie können während des laufenden Betriebes eine binäre oder eine les- und editierbare Kopie davon erzeugen.

Beispiel für eine binäre Kopie:

ALTER DATABASE BACKUP CONTROLFILE TO <Dateiname>;

Beispiel für eine lesbare Kopie – diese wird im Verzeichnis BACKGROUND_DUMP_DEST angelegt:

ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Data Dictionary Views: V$CONTROLFILE, V$DBFILE, V$LOGFILE

SEGMENT

Segmente sind Oracle Objekte, in denen Daten gespeichert werden können:

    • Tabelle
    • Cluster
    • Index
    • Rollback Segmente
    • Temporäre Segmente
    • LOB Segmente
    • Bootstrap Segment (Oracle intern)

Segmente bestehen aus einzelnen Extents. Beim Anlegen eines Objektes allokiert Oracle MINEXTENTS Extents für das Objekt. Sollte es im weiteren Verlauf notwendig sein, so allokiert Oracle weitere Extents von der Größe NEXT (bis MAXEXTENTS erreicht ist).

Data Dictionary Views: DBA_SEGMENTS, DBS_ROLLBACK_SEGS, ALL_…, USER_…

Sequenz

Eine Sequenz ist ein eigenständiges Schemaobjekt, das als Nummerngenerator dient. Beim Anlegen einer Sequenz kann u.a. angegeben werden:

    • Startpunkt (Default: 1)
    • Schrittweite (Default: 1)
    • Maximalwert (Default: 1,0000E+27)

Sequenzen werden i.d.R. dazu verwendet, ein Primärschlüsselfeld zu füllen. Solange eine Sequenz als NOCYCLE (Default) definiert wurde, kann die gleiche Nummer niemals mehrfach vergeben werden. Dies führt zur absoluten Eindeutigkeit; allerdings kann es bei Verwendung einer Sequenz zu Lücken bei Werten der betreffenden Spalte kommen.

Data Dictionary Views: USER_SEQUENCES, ALL_SEQUENCES, DBA_SEQUENCES

SYSTEM GLOBAL AREA

Die System Global Area (SGA) wird beim Start einer Instanz im Hauptspeicher des Rechners allokiert. Sie besteht aus mehreren unterschiedlichen Bereichen, deren Größe von den INIT.ORA Einstellungen abhängt (Seit Oracle 9i können einige dieser Werte dynamisch eingestellt werden, ohne dazu die Datenbank neu starten zu müssen).

Die SGA besteht aus den folgenden Bereichen:

    • Buffer Cache
    • Shared Pool (Library Cache, Dictionary Cache)
    • Redolog Cache

Data Dictionary Views: V$PARAMETER, V$SGA, V$SGASTAT

TABLESPACE

Tablespaces sind logische Speicherbereiche innerhalb einer Oracle Datenbank, in denen Daten (Segmente, Prozeduren …) gespeichert werden können. Daten, Index, Rollback und Temporäre Segmente werden i.d.R immer in unterschiedlichen Tablespaces gespeichert. Ein Tablespace besteht aus mindestens einer Datendatei.

Der SYSTEM Tablespace wird mit dem Erzeugen der Datenbank automatisch angelegt und muss immer verfügbar (ONLINE) sein.

Data Dictionary Views: DBA_TABLESPACES, ALL_TABLESPACES,
USER_TABLESPACES, V$TS

TRIGGER

Ein Trigger ist eine PL/SQL-Routine, die nicht namentlich aufgerufen wird, sondern rein ereignisgesteuert. Sobald das Ereignis eintritt, für das ein Trigger definiert wurde, wird automatisch der Triggercode ausgeführt.

Neben den klassischen Datenbank – Triggern, bei denen es unerheblich ist, über welche Applikation ein Ereignis ausgelöst wurde, gibt es in einigen Applikationen (Forms, Reports) auch noch Trigger, die von Applikations – Ereignissen abhängen.

DD-Views: dba_triggers

Veröffentlicht am

Systemsicherheit

Schwachstellen in der Sicherheit von IT-Systemen können ggf. die Datensicherheit gefährden und stellen damit auch ein geschäftskritisches Risiko für Unternehmen dar.

Hierzu gehören u.a.:

    • Unsichere Grundkonfiguration der Server sowie unnötige Dienste und Protokolle
    • unzureichende Netztrennung z.B. Applikationen inkl. Datenbanken mit schützenswerten Daten sind von jedem Rechner aus dem Intranet aus erreichbar
    • unzureichende Prozesse und fehlendes Reporting z.B. Software auf Servern wird nicht regelmäßig mit Security Patches versorgt
    • Mangelnde Pflege des Sicherheitsstatus im Sinne von aktuellen sogenannten Patches / Bugfixes etc. und Softwareversionen
    • unzureichende Prozesse um Firewall Regeln im Sinne eines Lifecycle-Managements zu beantragen, frei zu schalten und implementieren zu lassen

Hinzu kommen häufig noch Compliance-Verstöße und Missachtung von gesetzlichen Auflagen wie dem Datenschutz.

Zur Herstellung und Aufrechterhaltung der Sicherheit von IT-Systemen kommen zahlreiche Maßnahmen in Betracht, die nachfolgend erläutert werden sollen.

Systemhärtung

Die Grundlage für alle Maßnahmen zur Verbesserung der Systemsicherheit bildet die Systemhärtung (OS-, DB-Systeme, WebServer etc.) zur Herstellung eines Mindeststandards bei der Konfiguration und dem Betrieb von Systemen, Datenbanken und Anwendungen. Die Systeme müssen technisch immer auf dem aktuellen Stand gehalten werden, wobei der Status kontinuierlich überwacht und kontrolliert werden muß.

Systemhärtung bedeutet unabhängig von der Art der Software die Konfiguration eines Systems, welche nach dem aktuellen Stand der Technik einen angemessen Schutz vor Angriffen bietet.

Durch die Umsetzung von konkreten Sicherheitsanforderungen an die Konfiguration von Betriebssystemen, Middleware und Datenbanken wird ein kurzfristiger Sicherheitsgewinn mit wenig Ressourcenaufwand sichergestellt.

Zu den Härtungsmaßnahmen gehören u.a.:

    • Abschalten von nicht benötigten Diensten/ Softwarepaketen
    • Sichere Dateisysteme und Dateiberechtigungen
    • Einrichtung von Zugriffsbeschränkungen
    • Vermeidung unsicherer Dienste und Kommunikationsprotokolle
    • Aktualisierung der Software- und Versionsstände

Sämtliche Serversysteme wie Betriebs-, Middleware-, Webserver- und Datenbanksysteme sollten gemäß einer Security Baseline „gehärtet“ sein, was bedeutet, dass nur ein minimales Set an Diensten und Softwaremodulen bereitgestellt werden soll. Informationen zur Härtung z.B. von Datenbanksystemen finden Sie hier.

Notwendige Ausnahmen von der Konfigurations-Baseline müssen grundsätzlich dokumentiert und genehmigt werden und ermöglichen somit einen „Compliance-Green“ Status trotz Abweichung.

Weitere Maßnahmen

Neben der Systemhärtung sollten auch die nachfolgenden Maßnahmen im Rahmen der Systemsicherheit berücksichtigt werden:

    • Integration von Security-Richtlinien in den Entwicklungsprozess
    • Überprüfung der Umsetzung / Compliance-Statements
    • Automatisierte Code-Inspektion
    • Patch-Management auf Servern
    • Vulnerability-Monitoring
    • Applikations-Sicherheitstests
    • Firewall- und Anti-Virus-Software Integration
    • Audits

Neben der Beseitigung von IT-Sicherheitslücken sollte auch ein kontinuierliches Reporting und Schwachstellenmanagement zur Vermeidung solcher Lücken in Zukunft mit den nachfolgenden Zielen etabliert werden:

    • Umsetzung von technischen und organisatorischen Maßnahmen zur Behebung der Sicherheitsschwachstellen
    • das Bedrohungspotentials durch Umsetzung von Best Practice Maßnahmen zu minimieren
    • Sicherheitsanforderungen (Security Requirements) umzusetzen und Security Compliance sicherzustellen
    • Vereinfachung der Security Compliance und der Kontrollnachweise z.B. für Sicherheitsaspekte im Rahmen von Sarbanes-Oxley Act (SOX), Prozessen und Produktzertifizierungen
    • Security-Informationen der Applikationen werden systematisch erhoben und notwendige Nachweise für Security-Audits und Zertifizierungen sind leichter und schneller verfügbar

Security Reporting

Das Security Reporting stellt technische Informationen über den Sicherheits- und Compliance-Status von Projekten, Applikation und Systemen zur Verfügung.

Hierzu gehören:

    • Systemhärtungs-Reports der Betriebs-, Middleware-, Webserver- und Datenbanksysteme in denen ein Abgleich der sicherheitsrelevanten Konfiguration der Server mit den Security Anforderungen durchgeführt wird
    • Basis-System Security Scans (von innen und außen), um bekannte Schwachstellen der eingesetzten Systeme aufzudecken. Hiermit werden tatsächlich vorhandene Schwachstellen identifiziert, die ein Angreifer ausnutzen könnte. Als Ergebnis werden sowohl fehlende Security-Patche der Server als auch extern wirksame Schwachstellen der Serverkonfiguration aufgedeckt.

Schwachstellen Management

Hierzu zählt insbesondere das Patch-Management auf Servern, das eine entscheidene Rolle zur Aufrechterhaltung der Systemsicherheit spielt und nachfolgend detaillierter dargestellt werden soll.

Das Patch-Management umfasst im Wesentlichen:

    • Aktualisierung der eingesetzten Software
    • adhhoc/ Emergency Schwachstellenbehebung
    • regelmäßige Einspielung von Sicherheitspatches

Zur Realisierung des Patch-Managements hat sich nachfolgender Ablauf bewährt:

    • Prüfung eingehende Patchinformationen der Systemhersteller und anderer Quellen auf Relevanz und Dringlichkeit
    • Information an System Manager der Anwendungen, die von einem Patch betroffene Komponenten (Betriebssystem, Middelware oder Datenbank) nutzen
    • Bewertung der Patchinformationen und Testnotwendigkeiten durch die System Manager
    • System Manager veranlassen die Einspielung der Patche in eine Testumgebung und testen die Auswirkungen des Patches oder erwirken die empfohlene Umkonfigurationen des Servers
Stolz präsentiert von WordPress