2.4.10. Einschränken des Datenbankzugriffs

Die meisten Produktionssysteme enthalten sensible Kundendaten, die allein aus datenschutzrechtlichen Gründen vor dem Zugriff durch Entwickler gesperrt sind. In der Praxis besteht somit in der Regel nicht die Gefahr, dass Produktionsdaten durch checkerberry db gelöscht werden. Dennoch gibt es in vielen Unternehmen ausgezeichnete und ungeschützte Integrations- und Testsysteme, die wertvolle Daten enthalten. Dies betrifft vor allem Daten, die aufwändig und mühsam konstruiert wurden, sodass ein Datenverlust einen erheblichen Aufwand verursacht. Das versehentliche Überschreiben kann durch eine Zugriffskontrolle verhindert werden.

Die Zugriffskontrolle verwendet eine Black-, eine White- und eine Read-Only-List. Die Verwendung einer JDBC-URL wird erlaubt, wenn sie nicht in der Blacklist definiert ist. Für eine JDBC-URL, die in der Blacklist eingetragen ist, wird die Verbindung nicht gestattet, es sei denn, es existiert ein entsprechender Eintrag in der White- oder Read-Only-List, der ebenfalls auf diese URL zutrifft. Ist eine URL in der Read-Only-List eingetragen, wird unabhängig von den anderen beiden Listen stets ein lesender Zugriff gestattet. Bei der Definition einer URL in der Black-, White- oder Read-Only-List können die bekannten Platzhalter „*“ (0 – n beliebige Zeichen) und „?“ (ein beliebiges Zeichen) verwendet werden. Die folgenden Abbildungen zeigen einige Beispielkonfigurationen, in denen zunächst nur die Black- und die Whitelist Einträge enthalten. Die Read-Only-List ist leer und beeinflusst den Zugriff daher nicht.

Abbildung 2.16. Zugriffskontrolle

Zugriffskontrolle


In Abbildung 2.16, „Zugriffskontrolle“ sind sowohl Einträge in der Blacklist als auch in der Whitelist vorhanden. Über die Blacklist werden alle Zugriffe auf die JDBC-URLs von „host1“ und „host2“ unterbunden. In der Whitelist sind die JDBC-URLs für „host1:1111“ explizit freigegeben. In dem Beispiel erfolgt ein Zugriff auf eine JDBC-URL auf „host3“. Da dieser Host in der Blacklist nicht definiert ist, wird er Zugriff durch checkerberry db gewährt.

Abbildung 2.17. Blockierter Zugriff

Blockierter Zugriff


Abbildung 2.17, „Blockierter Zugriff“ zeigt ein weiteres Beispiel für die Zugriffskontrolle. Die Konfiguration der Black- und Whitelist entspricht der Konfiguration aus dem vorherigen Beispiel. In diesem Beispiel erfolgt der Zugriff auf eine JDBC-URL von „host2“. In der Blacklist wird ein Eintrag gefunden, der auf die aktuelle JDBC-URL zugeordnet werden kann. Die Freigabe des Zugriffs ist nur möglich, wenn die JDBC-URL auch in der Whitelist konfiguriert ist. Da dies nicht der Fall ist, wird der Zugriff abgewiesen.

Abbildung 2.18. Whitelist-Freigabe

Whitelist-Freigabe


In Abbildung 2.18, „Whitelist-Freigabe“ ist ein weiteres Beispiel für die Zugriffskontrolle dargestellt. Die Konfiguration der Black- und Whitelist entspricht den Konfigurationen aus den vorherigen Beispielen. In diesem Beispiel erfolgt der Zugriff auf eine JDBC-URL von „host1“. In der Blacklist wird ein Eintrag gefunden, der auf die aktuelle JDBC-URL zugeordnet werden kann. Die Freigabe des Zugriffs ist nur möglich, wenn die JDBC-URL auch in der Whitelist konfiguriert ist. In diesem Beispiel ist in der Whitelist ein Eintrag vorhanden, der der JDBC-URL zugeordnet werden kann. Der Zugriff wird gewährt.

Abbildung 2.19. Read-Only-Freigabe

Read-Only-Freigabe


Auch das in Abbildung 2.19, „Read-Only-Freigabe“ dargestellte Beispiel für eine Zugriffskontrolle besitzt dieselbe Konfiguration der Black- und Whitelist wie die vorherigen Beispiele. Allerdings enthält diesmal die Read-Only-List einen Eintrag, der auf die aktuelle JDBC-URL passt. Der Zugriff wird daher nur lesend durch checkerberry db gewährt. Eine Überprüfung der Black- und Whitelist findet nicht mehr statt.

Die Konfiguration der Black-, White- und Read-Only-List ist in Kapitel Abschnitt 2.5.2.3, „Konfiguration von checkerberry db mit dem DbConfigurationCallback“ beschrieben.

2.4.10.1. Konfiguration der Zugriffskontrolle

Die Konfiguration der Zugriffskontrolle erfolgt über das DbConfigurationCallback.

Beispiel 2.34. Zugriffskontrolle

public class ConfigurationCallback implements DbConfigurationCallback {
  public void configure(DbConfiguration configuration) {
    // Alle JDBC-URLs verbieten
    configuration.addToAccessControlBlacklist("*");
    // Alle JDBC-URLs auf localhost Vollzuriff erlauben
    configuration.addToAccessControlWhitelist("jdbc:*://localhost:*");
    // JDBC-URLs auf host und Port 1512 Lesezuriff erlauben
    configuration.addToAccessControlReadOnlyList("jdbc:*://host:1512");
}


Das obige Beispiel zeigt eine mögliche Konfiguration der Zugriffskontrolle. Zunächst werden alle JDBC-URLs über die Wildcard „*“ in die Blacklist aufgenommen. Durch den Eintrag von „jdbc:*://localhost:*“ in der Whitelist, werden alle lokalen JDBC-Verbindungen erlaubt. Da in der Read-Only-List kein Eintrag enthalten ist, der die lokalen JDBC-Verbindung auf einen Lesezugriff einschränkt, ist für diese der Vollzugriff gestattet. Weil zudem "jdbc:*://host:1512" der Read-Only-List hinzugefügt wurde kann über den Port 1512 lesend auf host zugegriffen werden.