From owner-svn-doc-all@freebsd.org Tue Jun 21 20:44:05 2016 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1181BAC55AB; Tue, 21 Jun 2016 20:44:05 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C72E42EB9; Tue, 21 Jun 2016 20:44:04 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u5LKi4BV046726; Tue, 21 Jun 2016 20:44:04 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u5LKi4wk046725; Tue, 21 Jun 2016 20:44:04 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201606212044.u5LKi4wk046725@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Tue, 21 Jun 2016 20:44:03 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48976 - head/de_DE.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 20:44:05 -0000 Author: bhd Date: Tue Jun 21 20:44:03 2016 New Revision: 48976 URL: https://svnweb.freebsd.org/changeset/doc/48976 Log: Update to r48670: Add a section on installing sudo and some basic instruction on the use. Reviewed by: bcr Differential Revision: https://reviews.freebsd.org/D6909 Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Tue Jun 21 20:21:59 2016 (r48975) +++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml Tue Jun 21 20:44:03 2016 (r48976) @@ -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 @@ jail:httpd:memoryuse:deny=2G/jail + + + + 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. + +