Schützen sie ihre Daten vor Manipulation und Verlust!

Um ihre Daten und Anwendungen vor unbeabsichtigter oder beabsichtigter Manipulation und Verlust zu schützen ist ein modernes Sicherheitskonzept notwendig. Wir beraten sie und implementieren die optimale Lösung für ihre Anforderungen.

Zum Schutz ihrer Daten sind in Abhängigkeit der von ihnen definierten Anforderungen bieten sich unterschiedliche Lösungsansätze. In der Kombination der Maßnahmen ergibt sich ein effizienter Schutz ihrer Daten bei definierten SLA's.

Schutz der Daten vor unberechtigten Zugriffen

Virtual Private Databases

View Layer Konzepte zur Separierung von Applikation-Usern und Object-Ownern

Schutz der Daten vor technischen Fehlern

RMAN Backup und Recovery

Standby Database mit Data Guard

BCP (Business continuity planning)

Schutz der Daten vor logischen Fehlern

Replikation über Oracle Streams

RMAN Backup und Recovery

Standby Database mit Data Guard und zeitversetztem Apply

Beispiel: Absichern des Listeners

Um die Zugriffsmöglichkeit von externen Systemen auf die Oracle DB und den Oracle Listener zu limitieren bietet sich der Einsatz von IP-Whitelisten an. Dieser werden in der sqlnet.ora konfiguriert.

NAMES.DIRECTORY_PATH= (TNSNAMES, ONAMES, HOSTNAME)

SSL_CLIENT_AUTHENTICATION =FALSE

tcp.validnode_checking = yes
tcp.invited_nodes = (127.0.0.1, 192.168.0.15, 192.168.0.15)

WALLET_LOCATION =
 (SOURCE=
   (METHOD=File)
   (METHOD_DATA=
     (DIRECTORY=/opt/app/oracle/WALLETS/oracle)
   )
 )

In diesem Fall können nur Verbindungen von Servern mit den genannten IP-Adressen zum Listener aufgebaut werden. Zur Fehlervermeidung sollten hier nur IP Adressen angegeben werden und nicht die Namensauflösung genutzt werden. In der Listener Konfiguration darf nur TCP aktiviert sein.

Beispiel: Zugriff von Application Servern

Ein typischer Anwendungsfall ist der Zugriff vom Application-Server auf die Datenbank. Für optimale Nutzung der RAC-Features sowie zur Einhaltung der Sicherheitsrichtlinien muss die jdbc-Datasource korrekt konfiguriert sein. Der Zugriff erfolgt über ein Layer-Konzept. Hierbei wird das Datenschema gelocked, die notwendigen Rechte für die Objekte werden an den Applikationsuser über Views und Synonyme gegeben.

Somit hat der Applikationsuser keinen direkten Zugriff auf die Objekte und kann diese nicht verändern. Über das Viewkonzept wird ein zusätzlicher Abstraktionslayer eingefügt, so das Änderungen im Schema über die Views gekapselt sind. Damit können Datenbank- und Applikationsänderungen unabhängig voneinander ausgeführt werden.

Die jdbc-Datasource sollte über Service-Namen auf die Oracle-Instanz zugreifen, eine re-connect fähige Konfiguration kann wie folgt aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
    <local-tx-datasource>
        <jndi-name>jdbc/MyDS_Name</jndi-name>
       <connection-url>jdbc:oracle:thin:@(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = orarac1-vip)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = orarac2-vip)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = MyDS_Name.service)
      (SERVER = DEDICATED)))
        </connection-url>
        <driver-class>oracle.jdbc.driver.OracleDriver</driver-class>
        <user-name>application_user<user-name>
        <password>topsecret<password>
        <set-tx-query-timeout/>
        <query-timeout>30</query-timeout>
        <attribute name='ManagedConnectionFactoryProperties'>
          <properties>
           <config-property name='QueryTimeout' type='int'>30</config-property>
           <config-property name='TransactionQueryTimeout' type='boolean'>true</config-property>
          </properties>
        </attribute>
        <blocking-timeout-millis>5000</blocking-timeout-millis>
        <min-pool-size>0</min-pool-size>
        <max-pool-size>50</max-pool-size>
        <check-valid-connection-sql>select count(1) from dual</check-valid-connection-sql>
        <idle-timeout-minutes>1</idle-timeout-minutes>
    </local-tx-datasource>
</datasources>