2002-K-Kruse-Sicherheitskonzepte

International Business and Technology Consultants
Sicherheitskonzepte in Oracle
Von der Entwicklung in die
Produktion
14.11.2002
Presented by:
Bernd Kruse
Consultant
American Management Systems, Inc.
[email protected]
AMS confidential & proprietary
1
Agenda

Marketing

Betrachtete Benutzergruppen

Entwicklungs/Test Lösung

Produktion Lösung

Label Security Demo

Q&A
AMS confidential & proprietary
2
AMS Dienstleistungen
Telekommunikation / Finanzindustrie/ Energieanbieter
Management
Beratung
Wert
Analysen
Systementwicklung
Systemintegration
Application
Management
Business Process Outsourcing (Geschäftsprozessauslagerung)
Seit drei Jahrzehnten
praktiziert AMS
erfolgreiche
Partnerschaften mit
seinen Kunden.
Jedes Jahr kommen
85-90% unserer
Aufträge von
bestehenden
Kunden.
AMS confidential & proprietary
3
Oracle Know How AMS


Langjährige Erfahrung in der Entwicklung und
Implementierungen von großen Oracle
Umgebungen (Tera Byte)
Entwicklung und Implementierungen von OracleSicherheitskonzepten
AMS confidential & proprietary
4
Agenda

Marketing

Betrachtete Benutzergruppen

Entwicklungs/Test Lösungen

Produktion Lösungen

Label Security Demo

Q&A
AMS confidential & proprietary
5
Datenbank Benutzergruppen




Es gibt verschieden Datenbank Benutzergruppen
Jede dieser Gruppen hat unterschiedliche
Sicherheitsbedürfnisse
Jede dieser Gruppen braucht eine
funktionierende Arbeitsumgebung
Jede Sicherheitsrestriktion bedeutet eine
„Einschränkung“ für eine (andere)
Personengruppe
AMS confidential & proprietary
6
Betrachtet Benutzer/Gruppen
Entwickler
Tester
(Entwicklungs/Produktions-)
DBA
Produktions- Support
AMS confidential & proprietary
7
Entwickler
Ansprüche von Entwicklern an ein DB Schema


Keine Einschränkung in sein „persönlichen
Freiheit“
Möchte schnell Änderungen durchführen
können
AMS confidential & proprietary
8
Tester
Ansprüche von Testern an ein DB Schema

Stabiles Schema (möglichst wenig Änderungen)

Jeder Tester braucht sein eigenes Schema
AMS confidential & proprietary
9
Productions Support
Ansprüche vom Produktions- Support an ein DB
Schema

Stabiles Schema (möglichst wenig Änderungen)

Hohe Datensicherheit

Keine Möglichkeit von Add-Hoc Abfragen (außer
seiner Eigenen)
AMS confidential & proprietary
10
DBA
Ansprüche vom Produktions- DBA an ein DB
Schema

Stabiles Schema (möglichst wenig Änderungen)

Kein Schema Änderung ohne seine Erlaubnis



Schema Owner muss unter der Kontrolle des
DBA sein
Einhaltung von Namenskonventionen in den
Entwicklungsphasen
Änderungen am Schema müssen in allen
Umgebungen Nachvollziehbar sein
AMS confidential & proprietary
11
Agenda

Marketing

Betrachtete Benutzergruppen

Entwicklungs/Test Lösungen

Produktion Lösungen

Label Security Demo

Q&A
AMS confidential & proprietary
12
Eine Lösung für eine
Entwicklungsumgebung



Jeder Entwickler will „sein“ eigenes Schema
besitzen
Änderung im Public Schema nur über denDBA
Änderung im Public Schema nur mit einen
Qualitätssicherungsprozess (Versionskontolle)
AMS confidential & proprietary
13
Eine Lösung für eine
Entwicklungsumgebung
AMS confidential & proprietary
14
Eine Lösung für eine Testumgebung

Funktionale Testumgebung
—
—

Jeder Tester braucht seine eigenen Daten
Wichtigstes Ziel ist die Erfüllung der funktionalen
Anforderungen
End zu End Testumgebung
—
—
Reflektiert die (zukuenftige) Produktionsumgebung
Wichtigstes Ziel ist die Erfüllung der operativen
Anforderungen
AMS confidential & proprietary
15
Funktionale Testumgebung
Tester 1
Tester 2
Tester N
........
AMS confidential & proprietary
16
End zu End Testumgebung
AMS confidential & proprietary
17
Agenda

Marketing

Betrachtete Benutzergruppen

Entwicklungs/Test Lösungen

Produktion Lösungen

Label Security Demo

Q&A
AMS confidential & proprietary
18
Eine Lösung für eine
Produktionsumgebung

Publik Schema mit
public synonymen
oder
alter session set current_schema=<schema>

Applikationsuser bekommt rechte zugewiesen

Passwort des Applikationsuser muss geheim sein


Produktionssupport Benutzer bekomme
personalisierte Benutzer/Rechte
Weitere Einschränkung mit Lable Security
AMS confidential & proprietary
19
Eine Lösung für eine
Produktionsumgebung
AMS confidential & proprietary
20
Agenda

Marketing

Betrachtete Benutzergruppen

Entwicklungs/Test Lösungen

Produktion Lösungen

Label Security und Demo

Q&A
AMS confidential & proprietary
21
Label Security

Separate Software-Option

Separate Datenbank-Option

Separate Lizenzkosten
AMS confidential & proprietary
22
Label Security (cont)
Data Owner
Label Security
Data Access
Schema Owner
AMS confidential & proprietary
23
Label Security (cont)



Oracle bietet mit Label Security alle
Möglichkeiten um meine Daten zu schützen
Je nach Sensitivität der Daten können diese mit
Label Security mehr und mal weniger geschützt
werden
Label Security bietet die Möglichkeit von „Fine
Grade Access Control“
AMS confidential & proprietary
24
Label Security
Demo
AMS confidential & proprietary
25
Aber

DB Sicherheit ist nur einer von vielen Teilen

Wichtige „andere“ Sicherheitsmassnahmen:
—
—
—
—
Regelmäßige Passwort-Änderung
Verschlüsselung von Passwörtern in der Applikation
Verschlüsselung von Netzwerken
Nutzung „moderner“ Autorisierung (Single Sign On, z.B.
LDAP, Directory Service)
AMS confidential & proprietary
26
Zusammenfassung
Es gibt nicht „die Lösung“

Jedes Schema-Sicherheits-Model muss den
Anforderungen der Kunden angepasst werden

Label Security eine weiter gute Möglichkeit

100% Sicherheit gibt es nicht
AMS confidential & proprietary
27
Fragen
AMS confidential & proprietary
28
Lösung für eine
Produktionsumgebung



Trennung von Database owner, Schema owner und
Data owner
Alle Applikationen muessen das Schema ueber
<user_name>.<object_name>
referenzieren
Oder 'alter session set current_schema = ...'
AMS confidential & proprietary
29
Zugriff auf ein anderes Schema

Objektprivilegien (select, insert, etc.)

Objectreferenz
—
—
—
—
prefix (<username>.<table_name>)
private synonym
public synonym
alter session set current_schema=<schema name>
AMS confidential & proprietary
30
Virtual Private Database (VPD)






The Virtual Private Database ensures that, no matter how a
user gets to the data
(through an application, a report writing tool, or SQL*Plus)
the same strong access
control policy is enforced. In this way, VPD can help banks
ensure that customers
see their own accounts (and nobody else’s), that
telecommunications firms can keep
customer records safely segregated, and that human
resources applications can
support their complex rules of data access to employee
records.
AMS confidential & proprietary
31
Database, Schema und Data Owner
AMS confidential & proprietary
32