Agenda. Security in Notes

Transkript

1

2 Agenda Vorstellung Was gibt es für Ebenen der Security in Notes? Beschreibung der verschiedenen Ebenen mit Vor-/Nachteilen und Auswirkungen Wirkliche Sicherheit vs scheinbare Sicherheit Tips & Tricks 2

3 Über Wabion - Anwendungsentwicklung auf Basis Google Apps Engine und Lotus Domino - Beratungsunternehmen mit dem Focus jeweils Technologieführer auf seinem Gebiet zu sein. 3

4 Wer bin ich? Mathias Bierl, Staatl. Gepr. Wirtschaftsinformatiker Notesentwicklung / Administration seit 1997 (R 4 ND 8.5.x) Anti-Spam/Anti-Virus Lösungen Google Lösungen (Search, Apps, ) Server-Virtualisierung 4

5 Wer bin ich? Projekte mit Lotus / Domino: Lotus Notes R4 ND 8.5.x Sametime, Domino.Doc, Lotus Workflow, LEI, DECS, DGW Formelsprache, Skript, Klassen, Java, JS, HTML, AJAX Migration R4-R5-ND6-ND7-ND8, Microsoft Exchange, C-/C++-API, WIN 3.11-WIN 7, OS/2, AIX, AS/400, Linux,... Datenanbindungen an SAP, RDBS XML/XSL, Servlets, Web Services Mobile Datenanbindung (Blackberry, OBMG, ) Projekte mit Google: Google Search Appliance Google Message Security/Discovery Google Apps inkl. Migrationen Google App Engine Google Maps/Earth 5

6 Ebenen der Security Server/Domänenebene Serverzugriff Serverzugriff via Internetprotokollen Ausführungsrechte Anwendungsebene ACL Konsistente ACL Maximum Internet Access Database Script Designebene Leser-/Autorenfelder Designelementrechte Maskeneigenschaften Events 6

7 Ebenen der Security Verschlüsselung Berechnete Felder/Text Ansichten (eingeschränkt/eingebettet) Sektionen Feldbeschränkung auf Editor Access Hide When Formeln Input Enabled Formulas Sonstige Möglichkeiten Auf Clientebene durch ECL Rollen ID Sicherheit 7

8 Server-/Domänenebene Serverzugriff Konfigurierbar je Server mit Access- und Not Access (Deny) Gruppen bzw für alle User in Trusted Directories Greift standardmäßig nur für den Notes Zugriff 8

9 Server-/Domänenebene Serverzugriff Public Key Vergleich um gefälschte IDs zu verhindern Anonymer Notes Zugriff Passwortprüfung Namensvariationen 9

10 Server-/Domänenebene Serverzugriff via Internetprotokollen Anonymer Zugriff möglich Standardmäßig haben alle User aus allen Trusted Directories bei Anmeldung Zugriff Option Enforce server access settings aktiviert die Serverzugriffseinstellungen für Notes Zugriff auch für das entsprechende Internetprotokoll Internetprotokolle können einzeln konfiguriert werden 10

11 Server-/Domänenebene Ausführungsrechte Definiert wer Code auf dem Server ausführen darf Verhindert nicht eine manuelle Ausführung auf dem Client Vor allem wichtig für periodische und Web-Agenten 11

12 Server-/Domänenebene Zusammenfassung Die Sicherheit auf Server-/Domänenebene greift generell sobald auf dem Server gearbeitet wird Diese kann nur mit entsprechenden Berechtigungen umgangen bzw geändert werden Ein Missbrauch von Anwendungsinhalten wird hierbei nicht verhindert. Dies ist Sache der Anwendungsebene Diese ist bei Beachtung der Rahmenbedingungen eine wirkliche Sicherheit Bei Zugriff auf Betriebssystemebene des Servers kann diese Sicherheit umgangen werden. Abhilfe schafft hier Verschlüsselung der Datenbanken in Kombination mit einem Passwort für die Server ID 12

13 Anwendungsebene ACL Definiert den Zugriff auf eine Anwendung Generelle Zugriffslevel Kein Zugriff Verweigert den Zugriff auf die Anwendung Depositor Dokumente erstellen Leser Dokumente lesen Author Dokumente erstellen und freigegebene bearbeiten 13

14 Anwendungsebene ACL Generelle Zugriffslevel Editor Dokumente erstellen und bearbeiten Designer Design bearbeiten Manager ACL verwalten User type sollte nie auf Unspecified stehen, da dann eine gleichnamige ID eines anderen Typs die Rechte bekommt 14

15 Anwendungsebene ACL Detailrechte erweitern/schränken generelle Rechte ein Create Documents Delete Documents Create private agents Create personal folders/views Create shared folders/views Create Lotus Script/Java agents Read public documents Write public documents Replicate or copy documents Verhindert auch das Drucken von Dokumenten Bestimmte Detailrechte sind für generelle Zugriffslevel vorgegeben 15

16 Anwendungsebene Konsistente ACL Standardmäßig hat ein Benutzer auf eine lokale Replik immer Manager Zugriff Dies kann durch die konsistente ACL verhindert werden. Mit ihr greift die ACL dann auch lokal Ausserdem wird damit verhindert, daß es auf verschiedenen Servern verschiedene ACLs gibt unterbindet die Replizierung Maximum Internet Access Definiert wie weit über Internetprotokolle auf die Anwendung zugegriffen werden darf Schränkt die ACL nur ein 16

17 Anwendungsebene Database Script Erlaubt es bestimmte Events per Formelsprache/LOtus Script zu beeinflussen Beispiele das Öffnen der Anwendung an Bedingungen zu knüpfen das Löschen von bestimmten Dokumenten trotz Löschrecht verhindern Löschen durch Setzen eines Flags realisieren ohne Löschrecht Löschen abhängiger Dokumente 17

18 Anwendungsebene Zusammenfassung Auch die Sicherheit auf der Anwendungsebene greift generell, sobald auf dem Server gearbeitet wird. Lokal kann die Nutzung der konsistenten ACL eine Erhöhung der Sicherheit erreichen Eine Umgehung ist nur durch entsprechende Rechte, z.b. Full Access Administrator möglich Diese ist bei Beachtung der Rahmenbedingungen eine wirkliche Sicherheit Ausnahme ist hier nur das Database Script, da dieses durch den Debugger bzw das Unterbinden der Ausführung von Scripten umgangen werden kann Bei Zugriff auf Betriebssystemebene des Servers kann diese Sicherheit umgangen werden. Abhilfe schafft hier Verschlüsselung der Datenbanken in Kombination mit einem Passwort für die Server ID 18

19 Designebene Leser-/Autorenfelder Definieren auf Dokumentebene die Zugriffsrechte Bei Existenz können Dokumente nur gesehen werden, wenn der Benutzer in einem Leser- oder Autorenfeld steht. Für andere Benutzer sind die Dokumente nicht sichtbar Full access administrator Recht kann dies umgehen Auch in lokalen Repliken können diese nicht anders umgangen werden Mehrere Leser-/Autorenfelder ergänzen sich Autorenfelder erlauben die Bearbeitung des Dokumentes, aber nur wenn der entsprechende Benutzer Autorenrechte in der ACL hat. Bei Editorrechten greift ein Autorenfeld nicht für die Bearbeitungsrechte. Wirkliche Sicherheit auf Dokumentebene 19

20 Designebene Designelementrechte Definieren auf Ebene der Designelemente wer das Designelement sehen kann bzw z.b. bei Masken wer damit Dokumente erstellen kann Damit wird aber nicht verhindert Dokumente zu sehen oder zu erstellen, es erschwert dies nur. Daher nur eine scheinbare Sicherheit. Maskeneigenschaften Deaktivieren von Drucken, Kopieren und Weiterleiten Verhindert dies durch Setzen eines Flags im Dokument Daher kann es durch Autoren/Editoren leicht gelöscht werden Leser können dies aber nicht umgehen Daher abhängig vom ACL Recht 20

21 Designebene Verschlüsselung Verschlüsselung kann auf Dokument- oder Feldebene stattfinden. Verschlüsselung kann durch Nutzung der ID-Keys oder durch externe Keys Zugriff und Bearbeitbarkeit der Dokumente/Felder ist nur möglich wenn Zugriff auf die verwendeten Keys besteht. Daher eine wirkliche Sicherheit Berechnete Felder/Text/Teilmasken Erlauben im Frontend nur das Lesen von Informationen Verhindert aber nicht, daß Daten im Hintergrund verändert werden. Daher nur eine scheinbare Sicherheit. 21

22 Designebene Ansichten (eingeschränkt/eingebettet) Selektieren nur was angezeigt werden soll. Kann leicht durch Erstellung einer eigenen Ansicht (privat) umgangen werden. Nur wenn Leser-/Autorenfelder verwendet werden, dann werden diese Dokumente auch hier nicht angezeigt Daher nur eine scheinbare Sicherheit Hide When Formeln Verbergen Absätze, Tabellenlemente und andere Bereiche anhand von Bedingungen Bieten nur eine Sicherheit im Frontend. Vorsicht bei RichText Feldern, da diese die Hide When Formeln im Feld selbst abspeichern Daher nur eine scheinbare Sicherheit 22

23 Designebene Events In Events z.b. auf der Maskenebene kann ich verschiedenste Aktionen verhindern. Beispiele hierfür wären das Speichern oder das Versetzen eines Dokumentes in den Bearbeitungsmodus. Events können aber analog zum Database script umgangen werden und sie schützen auch nicht vor Manipulationen von Dokumenten auf der Ansichtsebene Daher nur eine scheinbare Sicherheit. Sektionen Fassen Informationen zusammen bzw regeln den Lese-/Schreibzugriff auf diese Bieten nur eine Sicherheit im Frontend. Daher nur eine scheinbare Sicherheit 23

24 Designebene Feldbeschränkung auf Editor Access Erlauben im Frontend nur das Editieren von Feldern, wenn in der ACL mindestens Editor Zugriff vergeben ist Verhindert aber nicht, daß Daten im Hintergrund verändert werden. Daher nur eine scheinbare Sicherheit. Input Enabled Formulas Erlauben im Frontend nur das Editieren von Feldern, wenn die definierten Bedingungen erfüllt sind. Verhindert aber nicht, daß Daten im Hintergrund verändert werden. Daher nur eine scheinbare Sicherheit. 24

25 Designebene Die scheinbare Sicherheit auf der Designebene gilt nur für Notes Anwendungen. Ausnahme sind hier nur Events, für diese gilt auch im Web nur eine scheinbare Sicherheit, da auch bei JavaScript die Möglichkeit besteht dieses zu umgehen bzw zu deaktivieren. Bei Web Anwendungen besteht nicht die Möglichkeit Daten im Hintergrund zu verändern oder z.b. neue Ansichten zu erstellen. Dafür gibt es bei Web Anwendungen andere Stellen die sicherheitstechnisch relevant sind z.b. Cross Site Scripting 25

26 Sonstige Möglichkeiten Execution Control List Diese definiert welche Aktionen durch andere IDs ausgeführt werden dürfen ohne eine Sicherheitswarnung zu produzieren. Diese kann und sollte administrativ festgelegt werden Anwendungen, die mit speziellen IDs signiert sind, können dann die hier definierten Aktionen durchführen Bei entsprechender Konfiguration bietet diese im Client eine wirkliche Sicherheit Rollen Rollen sind eine Ergänzung der ACL und können ACL Einträgen zugeordnet werden Diese können in Leser-/Autorenfeldern wie auch bei Designelementrechten benutzt werden Weiterhin können diese im selbstgeschriebenen Code ausgewertet und darauf reagiert werden. 26

27 Zusammenfassung Die Definition von scheinbarer vs wirklicher Sicherheit gilt bei den einzelnen Punkten jeweils nur für diese separat betrachtet. Durch Kombination verschiedener Möglichkeiten können auch die einzeln nur scheinbare Sicherheit versprechenden Punkte wirkliche Sicherheit versprechen. Vor allem für Web Anwendungen gelten hierbei noch einmal andere Regeln, da hier gewisse Möglichkeiten nicht bestehen (z.b. Agent zur Datenmanipulation selbst erstellen) 27

28 Hinweise Für Notes Anwendungen gelten zum Teil andere Regeln was Sicherheit betrifft wie für Web Anwendungen. Diese müssen je Anwendung und Einsatzbereich betrachtet werden. Die Option Generate HTML for all fields kann z.b. durch Einsatz von JavaScript sehr leicht zur Datenmanipulation in WebAnwendungen benutzt werden. Sicherheit in Anwendungen ist nie nur in der Entwicklung zu suchen, sondern immer im Zusammenwirken der Entwicklung mit der Administration 28

29 Q & A 29

30 Kontakt Wabion GmbH Limburgstrasse 31 D Esslingen Phone: +49 (0) Fax: +49 (0) Web: Mathias Bierl Mobil: +49 (0)