Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Ach wie gut, dass niemand weiß…

Da nicht alle Passwörter von allen Nutzern der Software eingesehen werden sollen, ist es nötig, ein angemessen fein granuliertes Berechtigungskonzept einzuführen. Viele Software-Lösungen, so auch PSE, bieten im Wesentlichen die Berechtigungsstufen "Lesen" und "Schreiben", wobei das Setzen von beiden Berechtigungen einem Vollzugriff gleichkommt. Oftmals gibt es noch andere Berechtigungen, die beispielsweise das Drucken, Löschen oder Exportieren von Einträgen mittels dedizierter Client-Software regeln, und die Berechtigung zum Vergeben von Berechtigungen, wie in Abbildung 1 zu sehen. Eine typischerweise gewünschte Berechtigungsstufe fehlt jedoch häufig: "Lesen mit Alarmierung". Sie muss je nach Produkt und dahinter stehender Nutzungsphilosophie anderweitig implementiert werden.

Abbildung 1: Die Verwaltung von Berechtigungsstufen im PSE-System.

Diese Berechtigungsstufe ist für ein Notfall-Passwort-Management von entscheidender Bedeutung. Diejenigen Benutzer, die einen Zugriff auf die Passwörter im Notfall benötigen, sind im alltäglichen Betrieb nicht dazu berechtigt. Daher würde man ihnen mit der Berechtigungsstufe "Lesen" zu viele Berechtigungen einräumen, was dem Grundsatz widerspricht, dass man den Benutzern nur die minimal notwenigen Rechte zuweist. Die Berechtigung "Lesen mit Alarmierung" würde die Berechtigungen soweit einschränken, dass zwar ein lesender Zugriff immer noch jederzeit möglich ist, jedoch in jedem Fall eine Benachrichtigung an die Verantwortlichen geschickt wird. Um die Missbrauchsgefahr noch weiter zu minimieren, sollte es optional auch möglich sein, für bestimmte Passworteinträge oder auch für bestimmte Benutzergruppen ein Vier-Augen-Prinzip durchzusetzen.

Ist das Siegel noch ganz?

An der Unversehrtheit von Siegeln konnte man früher erkennen, ob die Nachricht unterwegs geöffnet wurde und somit der Inhalt auch Unberechtigten zur Kenntnis gelangte. Mit diesem Prinzip soll auch bei einigen Passwort-Management-Systemen kenntlich gemacht werden, ob Passwörter angezeigt beziehungsweise benutzt wurden. Dazu bringt man an einem beliebigen Passworteintrag ein virtuelles Siegel an. Der Passwort-Manager registriert nun jeden Zugriff auf das Passwort und gibt den Inhalt des Passworteintrages erst frei, wenn das Siegel durch den Anfragenden gebrochen wird, wie in Abbildung 2 erkennbar ist.

Abbildung 2: So funktioniert der Siegelschutz eines Passworteintrags in PSE.

In Passwort-Managern mit einem ausgereiften Berechtigungssystem, wie beispielsweise im PSE, ist es nun möglich, anzugeben, welche Benutzer berechtigt sind, das Siegel zu brechen oder auch welche Benutzer berechtigt sind, Passworteinträge, die unter einem Siegelschutz stehen, trotzdem bearbeiten zu dürfen. Diese Eigenschaft ist eine wichtige Anforderung, wenn eine regelmäßige Passwortänderung vorgeschrieben ist. Wäre eine solche Funktionalität nicht vorhanden, so müsste bei jeder Passwort-änderung erst das Siegel gebrochen werden, um das Passwort ändern zu können, nur um anschließend das Siegel mit all seinen Berechtigungsstufen wieder zu aktivieren.

Schließlich stellt sich die Frage, wie viel der Funktionalitäten des Passwort-Managers auf dem Serversystem bereitgestellt werden soll und wie viel auf den Endsystemen der Nutzer. Dabei gibt es verschiedene Ansätze, die von der Datenbank und der Berechtigungsprüfung auf Serverseite bis hin zu Beispielen reichen, bei denen die gesamte Programmlogik einer Webanwendung obliegt.

Die Sicherung der Verfügbarkeit und das Berechtigungsmanagement sind Aufgaben, die in jedem Fall auf Serverseite ausgeführt werden müssen. Bei einer Client-basierten Ausführung der restlichen Funktionalitäten ist das Verhalten der Passwort-Management-Lösung einfacher anpassbar, wohingegen sich eine Webanwendung mit verschiedenen Betriebssystemen und Endgeräten nutzen lässt. Beispiel für eine mögliche Verhaltensanpassung ist der automatische Aufbau einer SSH- oder RDP-Verbindung, ohne dass das Passwort dem Nutzer angezeigt werden muss. Dabei ist es bei Client-basierten Lösungen im Allgemeinen möglich, individuelle Einstellungen für jeden Nutzer einzurichten.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019