Schützen sie ihre Daten vor Manipulation und Verlußt!

Um ihre Daten und Anwendungen vor unbeabsichtigter oder beabsichtigter Manipulation und Verluß 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ßnamen ergibt sich ein effizienter Schutz ihrer Daten bei definierten SLA's.

Schutz der Daten vor unberechtigten Zugriffen

Virtual Privat 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 Strems

RMAN Backup und Recovery

Standby Database mit Data Guard und zeitversetztem Apply

Beipiel: Absichern des Listeners

Um die Zugrifssmö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.

Beipiel: Zugriff von Application Servern

Ein typische Anwendungsfall ist der Zugriff vom Application-Server auf die Datenbank. Für optimale Nutzung der RAC-Features sowie zur Einhaltung der Sicherheitsrichtlinien muß 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 wir ein zusätzlicher Apstraktionslayer eingefügt, so das Änderungen in 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>