Index: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $ - basiert auf: r48103 + basiert auf: r48670 --> Sicherheit @@ -4145,4 +4145,213 @@ in &man.rctl.8;. + + + + Gemeinsame Administration mit Sudo + + + + + Tom + Rhodes + + Beigetragen von + + + + + + Björn + Heidotting + + Übersetzt von + + + + + + Sicherheit + Sudo + + + Systemadministratoren benötigen häufig die Möglichkeit, + Benutzern erweiterte Berechtigungen zu gewähren, damit + diese privilegierte Aufgaben ausführen können. Die Idee, dass + Teammitglieder einen Zugang zu einem &os;-System zur Verfügung + gestellt bekommen, um ihre spezifischen Aufgaben erledigen zu + können, stellt den Administrator vor eine große + Herausforderung. Diese Teammitglieder benötigen in der Regel + nur einen eingeschränkten Zugang. Für manche Aufgaben werden + jedoch die Rechte des Superusers benötigt. Zum Glück gibt es + keinen Grund, diesen Mitgliedern einen solchen Zugang zu geben, + da es Werkzeuge für genau diesen Anwendungsfall gibt. + + Bislang wurde in diesem Kapitel immer versucht, den Zugriff + für autorisierte Benutzer zu gewähren und den Zugriff für + nicht autorisierte Benutzer zu verhindern. Ein weiteres Problem + entsteht, sobald autorisierte Benutzer Zugriff auf die + Ressourcen des Systems haben. In vielen Fällen benötigen einige + Benutzer Zugriff auf Startskripte von Anwendungen. In anderen + Fällen muss eine Gruppe von Administratoren das System + verwalten. Traditionell wird der Zugriff über Benutzer, + Gruppen, Dateiberechtigungen und manchmal sogar &man.su.1; + verwaltet. Und da immer mehr Anwendungen einen Zugriff brauchen + und immer mehr Benutzer Zugriff auf die Systemressourcen + benötigen, ist ein besserer Lösungsansatz erforderlich. Die am + häufigsten verwendete Anwendung in solchen Fällen ist derzeit + Sudo. + + Sudo erlaubt dem Administrator + eine rigide Konfiguration des Zugriffs auf bestimmte Kommandos + und stellt einige erweiterte Protokollfunktionen zur Verfügung. + Dieses Werkzeug kann als Port oder Paket + security/sudo installiert werden. Das Paket + wird wie folgt installiert: + + &prompt.root; pkg install sudo + + Nach der Installation können Sie visudo + benutzen, um die Konfiguration in einem Texteditor zu öffnen. + Es wird ausdrücklich visudo empfohlen, da + dieses Programm die Syntax auf Fehler überprüft, bevor die + Konfigurationsdatei gespeichert wird. + + Die Konfigurationsdatei besteht aus mehreren kleinen + Abschnitten, die eine umfangreiche Konfiguration ermöglichen. + Im folgenden Beispiel soll der Webentwickler (user1) den Dienst + webservice starten und stoppen + dürfen. Um ihm dieses Recht zu gewähren, fügen Sie folgende + Zeile an das Ende von + /usr/local/etc/sudoers ein: + + user1 ALL=(ALL) /usr/sbin/service webservice * + + Der Benutzer kann jetzt + webservice über dieses Kommando + starten: + + &prompt.user; sudo /usr/sbin/service webservice start + + Diese Konfiguration gestattet den Zugriff auf den + webservice für einen einzelnen + Benutzer. Jedoch ist in den meisten Organisationen ein ganzes + Team für die Verwaltung eines solchen Dienstes verantwortlich. + Mit einer weiteren Zeile ist es möglich, einer ganzen Gruppe + diesen Zugriff zu geben. Die folgenden Schritte erstellen eine + Gruppe mit den entsprechenden Benutzern. Der Gruppe wird es + dann ermöglicht, diesen Dienst zu verwalten: + + &prompt.root; pw groupadd -g 6001 -n webteam + + Nun werden die Benutzer mit Hilfe von &man.pw.8; in die + Gruppe webteam hinzugefügt: + + &prompt.root; pw groupmod -m user1 -n webteam + + Zuletzt wird folgende Zeile in + /usr/local/etc/sudoers hinzugefügt, damit + jedes Mitglied von webteam den Dienst + webservice verwalten kann: + + %webteam ALL=(ALL) /usr/sbin/service webservice * + + Im Gegensatz zu &man.su.1;, benötigt + Sudo nur das Passwort des + Benutzers. + + Benutzer, die mit Hilfe von Sudo + Programme ausführen, müssen lediglich ihr eigenes Passwort + eingeben. Dies ist sicherer und bietet eine bessere Kontrolle + als &man.su.1;, wo der Benutzer das root-Passwort eingibt und damit + alle Rechte von root + erlangt. + + + Viele Organisationen haben bereits auf eine + Zwei-Faktor-Authentifizierung umgestellt. In diesen Fällen + hat der Benutzer möglicherweise gar kein Passwort, welches er + eingeben könnte. Sudo bietet für + solche Fälle die Variable NOPASSWD. Wenn + die Variable in die obige Konfiguration hinzugefügt wird, + dürfen die Mitglieder der Gruppe + webteam den Dienst verwalten, ohne + ein Passwort eingeben zu müssen: + + %webteam ALL=(ALL) NOPASSWORD: /usr/sbin/service webservice * + + + + Protokollierung + + Ein Vorteil von Sudo ist, dass + Sitzungen protokolliert werden können. Mit den integrierten + Protokollmechanismen und dem Befehl + sudoreplay können alle über + Sudo ausgelösten Befehle + protokolliert und zu einem späteren Zeitpunkt überprüft + werden. Um diese Funktion zu aktivieren, fügen Sie einen + Eintrag für das Verzeichnis der Protokolle hinzu. Dieses + Beispiel verwendet eine Benutzervariable. Weitere + Informationen finden Sie in der Manualpage von + sudoreplay. + + Defaults iolog_dir=/var/log/sudo-io/%{user} + + + Dieses Verzeichnis wird automatisch nach der + Konfiguration erstellt. Um auf der sicheren Seite zu sein, + ist es am besten, das System die Verzeichnisse mit + Standardberechtigungen erstellen zu lassen. Dieser + Eintrag wird auch ein Protokoll für Administratoren + erstellen, wenn diese den Befehl + sudoreplay benutzen. Um dieses + Verhalten zu ändern, kommentieren Sie die entsprechenden + Zeilen in sudoers aus. + + + Nachdem dieser Eintrag in die Datei + sudoers hinzugefügt wurde, kann die + Konfiguration der Benutzer für die Protokollierung + aktualisiert werden. In dem gezeigten Beispiel würde der + aktualisierte Eintrag für das + webteam zusätzlich folgende + Änderung benötigen: + + %webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice * + + Von nun an wird jede Änderung am + webservice protokolliert, wenn sie + von einem Mitglied der Gruppe + webteam initiiert wurde. Eine + Liste der Sitzungen kann wie folgt angezeigt werden: + + &prompt.root; sudoreplay -l + + Wenn Sie eine bestimmte Sitzung wiedergeben möchten, + suchen Sie in der Ausgabe nach dem Eintrag + TSID= und übergeben Sie den Wert ohne + weitere Optionen an sudoreplay. + Zum Beispiel: + + &prompt.root; sudoreplay user1/00/00/02 + + + Obwohl die Sitzungen protokolliert werden, kann ein + böswilliger Administrator wahllos die Sitzungsprotokolle + löschen. Daher ist es eine gute Idee, eine tägliche + Kontrolle mit einem Intrusion Detection + System (IDS) oder + einer ähnlichen Software durchzuführen, so dass andere + Administratoren auf manuelle Änderungen aufmerksam gemacht + werden. + + + sudoreplay ist extrem + erweiterbar. Lesen Sie die Dokumentation für weitere + Informationen. + +