NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Einfuhrung in die System-Administration - Verwalten von Benutzer-Accounts und Ressourcen-Zugang
Red Hat Enterprise Linux 4: Einf�hrung in die System-Administration
Kapitel 6. Verwalten von Benutzer-Accounts und Ressourcen-Zugang
Die Verwaltung von Benutzer-Accounts und Gruppen ist ein wesentlicher Bestandteil der System-Administration innerhalb eines Unternehmens. Um dies jedoch so effizient als m�glich zu bewerkstelligen, muss ein guter System-Administrator zuallererst �ber Benutzer-Accounts und Gruppen genauestens Bescheid wissen.
Der Hauptgrund f�r die Existenz von Benutzer-Accounts liegt in der eindeutigen Verifizierung der Identit�t jedes einzelnen Individuums, welches ein Computersystem benutzt. Ein sekund�rer (jedoch auch wichtiger) Grund f�r die Erstellung von Benutzer-Accounts ist die f�r jeden Einzelnen ma�geschneiderte Vergabe von Resource- und Zugriffspriviligien.
Ressourcen k�nnen Dateien, Verzeichnisse und Ger�te beinhalten. Den Zugang zu diesen Ressourcen zu kontrollieren, ist ein wesentlicher Bestandteil der t�glichen Routine eines Systemadministrators. Oft wird auch der Zugang zu einer Ressource durch Gruppen kontrolliert. Gruppen sind logische Konstrukte, welche dazu benutzt werden Benutzer-Accounts f�r einen gemeinsamen Zweck zusammenzufassen. Wenn zum Beispiel ein Unternehmen mehrere Systemadministratoren besitzt, so k�nnen diese alle einer Systemadministratorengruppe zugeordnet werden. Der Gruppe kann sodann die Erlaubnis erteilt werden auf Schl�sselressourcen des Systems zuzugreifen. Dies macht Gruppen zu einem leistungsf�higen Werkzeug bei der Verwaltung von Ressourcen und Zugriffsberechtigungen.
In den folgenden Abschnitten werden Benutzer-Accounts und Gruppen genauer definiert.
6.1. Verwalten von Benutzer-Accounts
Wie bereits erw�hnt, werden Benutzer-Accounts zur Identifikation und Authentifizierung von einzelnen Individuen benutzt. Benutzer-Accounts haben etliche verschiedene Komponenten. Zuallererst gibt es den Benutzernamen. Das Passwort kommt als N�chstes, gefolgt von der Information �ber die Zugriffskontrolle.
Die folgenden Abschnitte behandeln jede einzelne Komponente im Detail.
6.1.1. Der Benutzername
Von der Sicht des Systems aus, ist der Benutzername die Antwort auf die Frage "Wer bist Du?" Als solches haben Benutzernamen eine wesentliche Bedingung zu erf�llen — sie m�ssen einzigartig sein. In anderen Worten muss jeder Benutzer einen Benutzernamen besitzen, der sich von allen anderen Benutzernamen im System unterscheidet.
Daher ist es unerl�sslich — im vorhinein — festzulegen, wie Benutzernamen erzeugt werden sollen. Ansonsten finden Sie sich selbst in einer Position wieder, in der Sie gezwungen sind einzugreifen, wann immer ein neuer Benutzer einen Account anfordert.
Was Sie ben�tigen ist eine Namenskonvention f�r Benutzer-Accounts.
6.1.1.1. Namenskonventionen
Durch die Erstellung einer Namenskonvention f�r Benutzernamen k�nnen Sie sich selbst jede Menge an Problemen ersparen. Anstatt sich immer wieder neue Namen ausdenken zu m�ssen (und es f�r Sie immer schwieriger wird einen vern�nftigen Namen zu erfinden), investieren Sie lieber etwas Arbeit im Voraus und entwickeln eine Konvention, welche bei der Erstellung aller nachfolgenden Benutzer-Accounts verwendet wird. Ihre Namenskonvention sollte m�glichst einfach aufgebaut sein, da ansonsten die Beschreibung selbst bei der Dokumentation einige Seiten in Anspruch nehmen k�nnte.
Die genaue Eigenschaft Ihrer Namenskonvention sollte etliche Faktoren ber�cksichtigen:
Die Gr��e Ihres Unternehmens
Die Struktur Ihres Unternehmens
Die Beschaffenheit Ihres Unternehmens
Die Gr��e Ihres Unternehmens spielt eine entscheidende Rolle, da es letztendlich darauf hinweist, wie viele Benutzer von der Namenskonvention in Betracht gezogen werden m�ssen. Eine sehr kleines Unternehmen ist zum Beispiel in der Lage jeden Benutzer, dessen oder deren Vorname benutzen zu lassen. F�r eine wesentlich gr�sseres Unternehmen w�re dies jedoch nicht m�glich.
Die Struktur eines Unternehmens kann ebenso Auswirkungen auf die geeignetste Namenskonvention haben. F�r Unternehmen mit einer sehr strikt festgelegten Struktur mag es angemessen sein, gewisse Elemente zu inkludieren, welche die Struktur wiederspiegeln. Zum Beispiel k�nnten Sie die Abteilungscodes als Teil jedes Benutzernamens integrieren.
Das allgemeine Wesen Ihres Unternehmens bringt ebenso mit sich, dass einige Namenskonventionen angebrachter sind als Andere. Ein Unternehmen, welches mit h�chst klassifizierten Daten zu tun hat, mag sich f�r eine Namenskonvention entscheiden, welche von s�mtlichen Aspekten einer pers�nlichen Identifikation, wie zum Beispiel durch den Namen, absieht. In einem solchen Unternehmen w�rde Maggie McOrmies Benutzername zum Beispiel LUH3417 lauten.
Hier finden Sie einige Namenskonventionen, welche andere Unternehmen bereits benutzt haben:
Vorname (john, paul, george, usw.)
Nachname (smith, jones, brown, usw.)
Erste Initiale, gefolt vom Nachnamen (jsmith, pjones, gbrown, usw.)
Nachname, gefolt vom Abteilungscode (smith029, jones454, brown191, usw.)
Tipp
Beachten Sie bitte, dass Namenskonventionen, welche verschiedene Daten zusammenf�gen, um einen Benutzernamen zu erstellen, eventuell auch anst��ige, beleidigende oder humorvolle Resultate erbringen. Deshalb empfehlen wir auch im Falle eines automatisierten Prozesses eine Art Nachpr�fungsprozess zur Verf�gung zu haben.
Die hier angef�hrten Namenskonventionen haben jedoch eines gemeinsam, n�mlich die M�glichkeit, dass laut Namenskonvention an zwei Individuen eventuell der selbe Benutzername vergeben werden sollte. Dieses Ph�nomen wird auch als Kollision bezeichnet. Da jeder Benutzername einzigartig sein muss, ist es notwendig sich mit dem Thema Kollision zu besch�ftigen. Im folgenden Abschnitt wird dieses Thema behandelt.
6.1.1.1.1. Kollisionen behandeln
Kollisionen sind beinahe unvermeidlich — egal wie sehr Sie auch versuchen dies zu vermeiden, Sie werden h�chstwahrscheinlich fr�her oder sp�ter mit einer Kollision zu tun haben. Daher m�ssen Sie Kollisionen in Ihrer Namenskonvention einplanen. Es gibt verschiedenste Wege dies zu tun:
Indem Sie aufeinanderfolgende Nummern an den kollidierenden Benutzernamen anh�ngen (smith, smith1, smith2, usw.)
Indem Sie benutzerspezifische Daten an den kollidierenden Benutzernamen anh�ngen (smith, esmith, eksmith, usw.)
Indem Sie unternehmensbezogene Informationen an den kollidierenden Benutzernamen anh�ngen (smith, smith029, smith454, usw.)
Methoden zu entwickeln, um Kollisionsprobleme l�sen zu k�nnen, ist ein wichtiger Bestandteil jeder Namenskonvention. Jedoch wird es dadurch auch schwieriger f�r einen Au�enstehenden einen Benutzernamen genauestens festzulegen. Daher ist der Nachteil der meisten Namenskonventionen, dass es mit h�chster Wahrscheinlichkeit hin und wieder zu falsch adressierten e-Mails kommen kann.
6.1.1.2. Namens�nderungen behandeln
Im Falle, dass Ihr Unternehmen eine Namenskonvention benutzt, welche auf dem Namen jedes einzelnen Benutzers basiert, ist es nahezu unumg�nglich, dass Sie von Zeit zu Zeit mit einer Namens�nderung zu tun haben. Auch wenn der eigentliche Name einer Person sich nicht �ndert, so kann es zeitweise zu einer Anfrage kommen. Die Gr�nde daf�r reichen von der Tatsache, dass Benutzer schlichtweg mit Ihrem Benutzernamen nicht zufrieden sind bis hin zu Benutzern, die je nach deren Stellung im Unternehmen um einen "angemesseneren" Benutzernamen ansuchen.
Ungeachtet der Begr�ndung f�r eine Namens�nderung, gibt es mehrere Punkte, die dabei beachtet werden m�ssen:
Machen Sie die �nderung in allen betroffenen Systemen
Die zugrundeliegende Benutzeridentifikation sollte immer konstant beibehalten werden
�ndern Sie die Eigentumsrechte aller Dateien oder andere benutzerspezifische Ressourcen (wenn notwendig)
E-Mail-bedingte Fragen behandeln
Zuallererst ist es wichtig sicherzugehen, dass der neue Benutzername auf allen Systemen verbreitet wird, auf denen der alte Benutzername in Gebrauch war. Ansonsten funktionieren Betriebssystemfunktionen, welche auf den Benutzernamen angewiesen sind lediglich auf einigen der Systeme und nicht auf allen Systemen. Bestimmte Betriebssysteme benutzen Zugriffskontrolle-Techniken, basierend auf Benutzernamen. Speziell diese Art von Systemen ist sehr anf�llig f�r Probleme, die durch die �nderung von Benutzernamen entstehen.
Viele Betriebssysteme benutzen eine Art Benutzer-Identifikationsnummer f�r den Gro�teil der benutzerspezifischen Ablaufsteuerung. Um die Probleme bei Benutzernamens�nderungen zu minimieren, empfehlen wir Ihnen falls m�glich diese Identifikationsnummer beim alten sowie auch beim neuen Benutzernamen beizubehalten. Ansonsten kann dies zu einem Szenario f�hren, worin der Benutzer auf seine zuvor benutzen Dateien oder auf andere Ressourcen nicht mehr zugreifen kann.
Wenn die Benutzeridentifikationsnummer ge�ndert werden muss, so ist es notwendig auch die Eigentumsberechtigung f�r s�mtliche Dateien und benutzerbezogene Ressourcen zu �ndern, um die neue Benutzeridentifikation widerzuspiegeln. Dies ist ein fehleranf�lliger Vorgang, da es immer irgendetwas in einer vergessenen Ecke im System zu geben scheint, was im Endeffekt �bersehen wird.
E-Mail-bezogene Themen sind wahrscheinlich der Bereich, in welchem sich die �nderung des Benutzernamens am schwierigsten gestaltet. Der Grund daf�r ist folgender: Solange keine Schritte unternommen werden, dem entgegenzuwirken, werden an den alten Benutzernamen adressierte e-Mails nicht an den neuen Benutzernamen ergehen.
Ungl�cklicherweise, sind die Themen rund um e-Mail und die �nderung des Benutzernamens multi-dimensional. Einfach ausgedr�ckt, bedeutet eine Benutzernamens�nderung, dass Dritte den korrekten Benutzernamen nicht mehr l�nger wissen k�nnen. Auf den ersten Blick mag dies nicht als ernstzunehmendes Problem erscheinen — wir empfehlen jedoch, dass Sie jeden in Ihrem Unternehmen umgehend davon verst�ndigen. Aber was passiert nun mit jemandem Au�enstehenden, der dieses pers�nliche e-Mail geschickt hat? Wie k�nnen diese davon verst�ndigt werden? Und was passiert mit den Mailing-Listen (internen und externen Ursprungs)? Wie k�nnen diese aktualisiert werden?
Es gibt keine einfache Antwort auf diese Fragen. Die beste Antwort darauf ist wahrscheinlich einen e-Mail-Alias anzulegen, sodass alle e-Mails, die an die alte Benutzeradresse adressiert sind automatisch an die neue Adresse weitergeleitet werden. Der Benutzer kann sodann dazu gedr�ngt werden, alle Absender von der �nderung zu benachrichtigen. Mit der Zeit werden immer weniger e-Mails mittels Alias eingehen. Letztendlich kann der Alias auch v�llig entfernt werden.
Trotz der Tatsache, dass die Benutzung von einem Alias zu falschen Schlussfolgerungen f�hren kann (z.B. der Benutzer, welcher als esmith bekannt ist, ist auch gleichzeit noch immer als ejones bekannt), ist dies der einzige Weg um zu garantieren, dass e-Mails die richtige Person erreichen.
Wichtig
Sollte Sie e-Mail-Aliase benutzen, so gehen Sie sicher, dass alle notwendigen Schritte unternommen werden, um den alten Benutzernamen vor potenzieller Wiederbenutzung zu sch�tzen. Sollten Sie das nicht tun und eine neuer Benutzer erh�lt Ihren alten Benutzernamen, so kann es zu Unterbrechungen in der e-Mail-Zustellung kommen (entweder f�r den Originalbenutzer oder auch den neuen Benutzer). Die genaue Art und Weise in der diese Unterbrechungen auftreten k�nnen, h�ngt selbstverst�ndlich von der Art ab, wie die e-Mail-Zustellung in Ihrem System implementiert worden ist. Die zwei h�ufigsten Varianten sind:
Der neue Benutzer erh�lt niemals e-Mails — alle werden an den Originalbenutzer vermittelt.
Der Originalbenutzer bekommt pl�tzlich keine e-Mails mehr — alle werden an den neuen Benutzer vermittelt.
6.1.2. Passw�rter
Wenn der Benutzername die Antwort auf die Frage "Wer bist Du?" darstellt, so ist das Passwort die Antwort auf die Aufforderung, die unweigerlich folgt:
"Beweise es!"
Eine fachlichere Umschreibung ist, dass ein Passwort ein Hilfsmittel darstellt, um die Authentizit�t einer Person zu best�tigen, welche sich als rechtm��iger Benutzer mittels dem Benutzernamen ausgibt. Die Effektivit�t eines Passwort-basierten Authentifizierungsschemas st�tzt sich auf einige unterschiedliche Aspekte des Passwortes:
Die Geheimhaltung des Passwortes
Die Best�ndigkeit des Passwortes gegen�ber dem Versuch es zu erraten
Die Best�ndigkeit des Passwortes gegen�ber einem Gewaltsakt in Form einer Attacke.
Passw�rter, welche in ausreichender Form diese Punkte ansprechen, werden als stark bezeichnet, wohingegen diejenigen, die einen oder mehrer Punkte oder Risiken nicht ansprechen, als schwach bezeichnet werden. Starke Passw�rter zu erstellen ist wichtig f�r die Sicherheit des gesamten Unternehmens, da diese mit einer geringeren Wahrscheinlichkeit herausgefunden oder erraten werden k�nnen. Es gibt zwei M�glichkeiten, um die Benutzung von starken Passw�rtern durchzusetzen:
Der Systemadministrator kann Passw�rter f�r alle Benutzer erstellen.
Der Systemadministrator kann die Benutzer selbst deren Passw�rter erstellen lassen, wobei er gleichzeitig �berpr�ft, ob die Passw�rter akzeptabel stark sind.
Passw�rter f�r alle Benutzer zu erstellen, stellt zwar sicher, dass diese starke Passw�rter sind, kann aber zu einer be�ngstigenden Aufgabe werden, in Hinsicht auf das stetige Wachstum eines Unternehmens. Es beinhaltet ebenso ein h�heres Risiko, dass Benutzer Ihre Passw�rter niederschreiben.
Aus diesen Gr�nden bevorzugen die meisten Systemadministratoren, dass deren Benutzer selbst deren Passw�rter erstellen. Ein guter Systemadministrator leitet jedoch immer Schritte ein, sich davon zu �berzeugen, dass es sich dabei um starke Passw�rter handelt.
F�r Richtlinien zur Erstellung starker Passw�rter, siehe Kapitel Arbeitsplatz Sicherheit in dem Red Hat Enterprise Linux Sicherheitshandbuch.
Die Notwendigkeit Passw�rter unter allen Umst�nden geheim zu halten, sollte fest in der Denkweise eines jeden Systemadministrators verwurzelt sein. Jedoch geht dieser Punkt oft bei vielen Benutzern unter. Tatsache ist, dass viele Benutzer oft nicht einmal den Unterschied zwischen Benutzername und Passwort kennen. Dieser ungl�ckliche Umstand bringt mit sich, dass ein gewisser Umfang an Benutzerweiterbildung unerl�sslich ist, sodass Benutzern klar wird, dass deren Passwort so geheim gehalten werden muss, wie deren Gehaltsscheck.
Passw�rter sollen so schwer als m�glich zu erraten sein. Ein starkes Passwort ist dadurch gekennzeichnet, dass niemand jemals in der Lage ist es zu erraten, sogar wenn diese Person den Benutzer gut kennt.
Ein Gewaltsakt oder sogenannte Attacke auf ein Passwort hat den methodischen Versuch (normalerweise mittels einem Programm, das als Password-Cracker bekannt ist) jede m�gliche Kombination von Passw�rtern auszuprobieren zur Folge, in der Hoffnung, dass eventuell das korrekte Passwort gefunden wird. Ein starkes Passwort sollte so konstruiert werden, dass die Anzahl der potenziellen Passw�rter, welche durchgetestet werden m�ssen, zur Folge haben, dass es einen m�glichst langen Zeitraum in Anspruch nimmt, um nach dem Passwort zu suchen.
Starke und schwache Passw�rter werden in den folgenden Abschnitten detaillierter behandelt.
6.1.2.1. Schwache Passw�rter
Wie bereits erw�hnt, besteht ein schwaches Passwort einen der folgenden drei Test nicht:
Es ist geheim
Es kann nicht erraten werden
Es h�lt jedem Gewaltsakt in Form einer Attacke stand
Die folgenden Abschnitte behandelt die Schwachstellen von Passw�rtern.
6.1.2.1.1. Kurze Passw�rter
Ein kurzes Passwort ist gleichzeitig ein schwaches Passwort, da es einer Attacke weniger gut standhalten kann. Um dies zu demonstrieren, beachten Sie bitte folgende Tabelle, welche die Anzahl der potenziellen Passw�rter zeigt, die im Falle einer Attacke durchgetestet werden m�ssten. (Es wird hierbei angenommen, dass die Passw�rter lediglich aus Kleinbuchstaben bestehen.)
Passwortl�nge
Potenzielle Passw�rter
1
26
2
676
3
17.576
4
456.976
5
11.881.376
6
308.915.776
Tabelle 6-1. Passwortl�nge versus der Nummer von potenziellen Passw�rtern
Wie Sie sehen k�nnen, so steigt die Nummer der m�glichen Passw�rter dramatisch mit der L�nge des Passwortes an.
Anmerkung
Auch wenn diese Tabelle bei sechs Zeichen endet, sollte dies nicht f�lschlicherweise als Empfehlung aufgefasst werden, dass sechsstellige Passw�rter lange genug sind, um ausreichende Sicherheit zu bieten. Generell gilt, je l�nger das Passwort, umso besser.
6.1.2.1.2. Limitierter Zeichensatz
Die Anzahl der verschiedenen Zeichen, aus denen ein Passwort bestehen kann, hat eine enorme Auswirkung auf die M�glichkeiten bei einer Attacke. Was w�re wenn wir zum Beispiel anstatt den 26 verschiedenen Zeichen, welche in einem Passwort in Kleinbuchstaben verwendet werden k�nnen, auch Zahlen verwenden? Dies w�rde bedeuten, dass jedes Zeichen in einem Passwort eines von 36 Zeichen, anstatt eines von nur 26 Zeichen sein k�nnte. Im Falle eines sechsstelligen Passwortes, steigt die Anzahl der M�glichkeiten von 308.915.776 auf 2.176.782.336.
Es geht noch weiter. Wenn wir n�mlich alphanumerische Passw�rter in Verbindung mit Gro�- und Kleinschreibung (f�r diejenigen Betriebssysteme, die dies unterst�tzen) verwenden, so resultiert daraus eine Anzahl von 56.800.235.584 M�glichkeiten. Das Hinzuf�gen weiterer Zeichen (wie zum Beispiel Interpunktionszeichen) erh�ht nochmals die Anzahl der m�glichen Passw�rter, was eine Attacke wesentlich erwschwert.
Jedoch sollte man immer daran denken, dass nicht jede Attacke auf ein Passwort eine Hacker-Attacke ist. Der folgende Abschnitt beschreibt weitere Merkmale eines schwachen Passwortes.
6.1.2.1.3. Erkennbare W�rter
Viele Attacken auf Passw�rter basieren auf der Tatsache, dass Leute sich mit Passw�rtern zufrieden geben, welche einfach zu merken sind. Deshalb sind die meisten Attacken W�rterbuch-basiert. In anderen Worten benutzt der Attacker verschiedene W�rterb�cher mit dem Bestreben das Wort oder die W�rter zu finden, aus denen ein Passwort besteht.
Anmerkung
Viele W�rterbuch-basierte Programme zum Herausfinden des Passwortes benutzen W�rterb�cher in mehreren Sprachen. Deshalb sollte Ihnen der Umstand, dass Sie ein nicht-deutsches oder auch nicht-englisches Passwort benutzt haben kein falsches Gef�hl von Sicherheit vermitteln.
6.1.2.1.4. Pers�nliche Information
Passw�rter, welche pers�nliche Informationen beinhalten (Name oder Geburtsdatum einer nahestehenden Person, eines Haustiers oder auch eine pers�nliche Identifikationsnummer) k�nnen bei einer W�rterbuch-basierten Attacke einfacher herausgefunden werden. Wenn jedoch ein sog. Attacker Sie pers�nlich kennt (oder auch ausreichend dazu motiviert ist Nachforschungen �ber Ihr Privatleben anzustellen), so k�nnte dieser/diese mit geringster Anstrengung auch Ihr Passwort erraten.
Zus�tzlich zu W�rterb�chern inkludieren viele Passwort-Knacker auch gebr�uchliche Namen, Daten oder andere derartige Informationen auf deren Suche nach dem richtigen Passwort. Deshalb k�nnte ein Attacker auch Ihr Passwort "meinhundbello" mit einem guten Passwort-Knacker herausfinden, ohne den Namen Ihres Hundes zu kennen.
6.1.2.1.5. Einfache Wortspiele
Das einfache Umdrehen der Reihenfolge von Zeichen in einem Passwort (jener Art, die zuvor ausgehend beschrieben worden ist), macht ein schwaches Passwort dadurch nicht st�rker. Die meisten Passwort-Knacker tun dies bereits auch automatisch bei m�glichen Passw�rtern. Dies inkludiert auch das Ersetzen von bestimmten Buchstaben mit Zahlen in gebr�uchlichen W�rtern. Hier sind einige Beispiele:
drowssaPdaB1
R3allyP00r
6.1.2.1.6. Das selbe Passwort f�r multiple Systeme
Auch wenn Sie ein starkes Passwort besitzen, so ist es nicht empfehlenswert, dieses Passwort auf mehr als einem System zu benutzen. Offenbar ist dies nicht m�glich, wenn die Systeme derart konfiguriert sind, dass so etwas wie ein zentraler Authentifizierungsserver benutzt wird. In jedem anderen Fall sollten jedoch verschiedene Passw�rter f�r jedes einzelen System benutzt werden.
6.1.2.1.7. Passw�rter auf Papier
Ein anderer Weg aus einem starken Passwort ein Schwaches zu machen, ist es ganz einfach niederzuschreiben. Indem Sie ein Passwort auf Papier niederschreiben, haben Sie nicht mehr l�nger ein Geheimhaltungsproblem, sondern ein absolutes Sicherheitsproblem — jetzt m�ssen Sie diese St�ck Papier sicher verwahren. Deshalb ist das Niederschreiben von Passw�rtern niemals eine gute Idee.
Jedoch haben einige Unternehmen einen berechtigten Bedarf nach niedergeschriebenen Passw�rtern. Zum Beispiel besitzen einige Unternehmen niedergeschriebene Passw�rter als Teil der Vorgehensweise im Falle des Verlustes einer Schl�sselfigur unter den Angestellten (wie z.B. einem Systemadministrator). In diesem Fall wird die Niederschrift an einem physikalisch-sicheren Ort aufbewahrt, wobei es die Zusammenarbeit mehrerer Personen gleichzeit bedarf, um Zugang zu den Papieren zu bekommen. Dabei werden oft Tresorr�ume mit mehreren Schl�ssern und gesicherte Banksafe-Laden benutzt.
Jedes Unternehmen, welches diese Methode der Aufbewahrung von Passw�rtern f�r Notf�lle erkunden m�chte, sollte sich dar�ber im Klaren sein, dass die reine Existenz einer Niederschrift ein weiteres Risiko-Element darstellt, egal wie sicher diese Passw�rter auch aufbewahrt werden. Dies ist speziell der Fall, wenn generell bekannt ist, dass die Passw�rter niedergeschrieben worden sind (und wo diese gelagert werden).
Ungl�cklicherweise sind niedergeschriebene Passw�rter zumeist nicht als Teil eines Notfallplanes gedacht und daher auch nicht dementsprechend in einem Tresor verwahrt. Es handelt sich dabei zumeist um Passw�rter f�r gew�hnliche Benutzer, welche in folgenden Pl�tzen untergebracht werden:
In einer Schreibtischschublade (abgesperrt oder unverschlossen)
Unter einem Keyboard
In einer Brieftasche
Auf die Seite des Bildschirms geklebt
Keine dieser Orte sind geeignete Pl�tze f�r ein niedergeschriebenes Passwort.
6.1.2.2. Starke Passw�rter
Wir haben gesehen, was schwache Passw�rter auszeichnet; die folgenden Abschnitte beschreiben die Merkmale, die alle starken Passw�rter besitzen.
6.1.2.2.1. L�ngere Passw�rter
Desto l�nger ein Passwort, desto weniger hoch ist die Chance, dass eine Attacke erfolgreich verl�uft. Deshalb sollten Sie, falls vom System unterst�tzt, eine relativ grosse Anzahl von Mindestzeichen f�r das Passwort Ihrer Benutzer festlegen.
6.1.2.2.2. Erweiterter Zeichensatz
F�rdern Sie die Benutzung von alphanumerischen Passw�rtern, die aus Gro�- und Kleinbuchstaben bestehen und bestehen Sie auf die Verwendung von zumindest einem nicht-alphanumerischen Zeichen bei allen Passw�rtern:
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. Erinnerungswert
Ein Passwort ist nur dann stark, wenn man sich auch daran erinnern kann. Jedoch liegen 'einfach zu merken' und 'leicht zu erraten' oft sehr nahe beeinander. Geben Sie deshalb Ihren Benutzern einige Tipps, wie man erinnerungswerte Passw�rter erstellt, die aber andererseit nicht einfach zu erraten sind.
Wenn Sie zum Beispiel einen bekannten Spruch oder eine bekannte Phrase nehmen und lediglich die ersten Buchstaben jeden einzelnen Wortes als Ausgangspunkt f�r Ihr Passwort w�hlen. Das Resultat ist erinnerungswert (weil der Spruch selbst, auf dem es basiert erinnerungswert ist) und doch das Resultat kein Wort beinhaltet oder darstellt.
Anmerkung
Beachten Sie dabei jedoch, dass lediglich das Benutzen der ersten Buchstabens eines jeden Wortes nicht ausreichend sind, um ein starkes Passwort zu erzeugen. Sorgen Sie immer daf�r, den Passwortzeichensatz zu erh�hen, indem Sie alphanumerische Zeichen, Gro�- und Kleinschreibung sowie ebenfalls zus�tzlich Spezialzeichen verwenden.
6.1.2.3. Passwort F�lligkeit
Falls m�glich, empfehlen wir Passwort-F�lligkeitsdaten in Ihrem Unternehmen einzuf�hren. Passwort-F�lligkeit ist ein Merkmal (in Zusammenhang mit vielen Betriebssystemen erh�ltlich), welches ein Zeitlimit aufstellt, bis zu dem das jeweilige Passwort als g�ltig angesehen ist. Am Ende der G�ltigkeitsdauer eines Passwortes, wird der Benutzer mittels Bedienerhinweis dazu aufgefordert ein neues Passwort einzugeben, welches sodann bis zu dessen neuem Ablaufdatum benutzt werden kann.
F�r die meisen Systemadminsitratoren ist die Hauptfrage zum Thema Passwort-F�lligkeit diejenige, nach der G�ltigkeitsdauer eines Passwortes.
Es gibt zwei v�llig entgegengesetzte Punkte, die im Bezug auf Passwort-G�ltigkeitsdauer zu beachten sind:
Benutzerkomfort
Sicherheit
�bertrieben ausgedr�ckt, w�rde eine Passwort-G�ltigkeitsdauer von 99 Jahren sehr wenig Unannehmlichkeiten (wenn �berhaupt) beim Benutzer hervorrufen. Jedoch w�rde es wenig (oder gar nicht) zum Thema Sicherheit beitragen.
Ebenso �bertrieben ausgedr�ckt, w�rde eine Passwort-G�ltigkeitsdauer von 99 Minuten sehr gro�e Unannehmlichkeiten f�r den Benutzer hervorrufen. Der Sicherheitsfaktor w�re dadurch jedoch ausserordentlich hoch.
Es geht haupts�chlich darum, ein Mittelma� zwischen dem Bestreben nach Bequemlichkeit f�r alle Benutzer und der Erfordernis nach h�chster Sicherheit f�r das Unternehmen zu finden. F�r die meisten Unternehmen befindet sich die allgemein�bliche Passwort-Lebensdauer im Wochen- oder Monatsbereich.
6.1.3. Zugriffskontrolle Information
Zusammen mit Benutzername und Passwort, beinhalten Benutzer-Accounts ebenso Informationen zum Thema Zugriffskontrolle. Diese Information kann verschiedene Formen je nach Art des verwendeten Betriebssystemes annehmen. Jedoch beinhalten diese Arten von Informationen zumeist:
Systemweite benutzerspezifische Identifikation
Systemweite gruppenspezifische Identifikation
Listen von zus�tzlichen Gruppen/Leistungsmerkmalen, denen ein Benutzer zugeordnet ist
Standardisierte Zugriffsinformation, welche auf alle vom Benutzer erstellten Dateien und Ressourcen zutrifft
In einigen Unternehmen ist es niemals notwendig, auf die Zugriffskontrollinformation eines Benutzers zuzugreifen. Dies trifft vor allem auf eigenst�ndige, pers�nliche Arbeitsplatzsysteme zu. F�r andere Unternehmen, speziell diejenigen, die Gebrauch von netzwerkweitem Resource-Sharing zwischen verschiedenen Benutzergruppen machen, besteht die Notwendigkeit, dass Zugriffskontrollinformationen der Benutzer weitgehend modifiziert werden.
Das Arbeitspensum, welches dazu ben�tigt wird, um die Zugriffskontrollinformation Ihrer Benutzer zu warten, variiert gem�� dem Nutzungsgrad der Zugriffskontrollfeatures des Betriebssystemes Ihrer Organisation. Einerseits ist es nicht schlecht, in hohem Ma�e auf diese Merkmale angewiesen zu sein (Tatsache ist, dass es eventuell unvermeidlich ist), andererseits bedeutet dies jedoch, dass Ihre Systemumgebung mehr Aufwand im Bereich der Wartung erfordert und dass jeder Benutzer-Account anf�lliger f�r Miskonfigurationen ist.
Im Falle, dass Ihr Unternehmen diese Art von Umgebung ben�tigt, sollten Sie daher die genauen Schritte, welche zur Erstellung und Konfiguration eines Benutzer-Accounts notwendig sind, dokumentieren. Tats�chlich sollten Sie im Falle von verschiedenen Arten von Benuzer-Accounts jeden einzelnen Account dokumentieren (Erstellung eines neuen Finanz-Benutzer-Accounts, eines neuen Operations-Benutzer-Accounts, usw.).
6.1.4. Accounts und Ressourcen-Zugang tagt�glich verwalten
Wie ein altes Sprichwort so sch�n sagt, ist die einzige Konstante im Leben die Ver�nderung. Dies trifft auch auf den Umgang mit Ihrer Benutzerschaft zu. Leute kommen und gehen oder wechseln deren Verantwortungsbereich. Deshalb m�ssen Systemadministratoren in der Lage sein, auf diese tagt�glich normal vorkommenden Ver�nderungen in deren Unternehmen zu reagieren.
6.1.4.1. Neuzug�nge
Wenn ein neues Mitglied Ihrem Unternehmen beitritt, so wird diesen mormalerweise Zugang zu verschiedenen Ressourcen (abh�ngig von deren Verantwortungsbereich) gew�hrt. Diese bekommen wahrscheinlich einen Arbeitsplatz zugewiesen, ein Telefon und einen Schl�ssel f�r die Eingangst�r.
Diese bekommen wahrscheinlich auch Zugang zu einem oder mehreren Computern in Ihrem Unternehmen. Als Systemadministrator liegt es in Ihrem Verantwortungsbereich sicherzustellen, dass die umgehend und entsprechend durchgef�hrt wird. Wie sollten Sie vorgehen?
Bevor Sie irgendetwas tun k�nnen, m�ssen Sie zun�chst einmal von der Ankunft der neuen Person informiert sein. Dies wird in verschiedenen Unternehmen ganz unterschiedlich gehandhabt. Hier sind einige M�glichkeiten:
Schaffen Sie einen Prozess, bei welchem die Personalabteilung Ihres Unternehmens Sie von der Ankunft einer neuen Person verst�ndigt.
Erstellen Sie ein Formular, welches vom Vorgesetzten dieser Person ausgef�llt und dazu benutzt werden kann, um einen Benutzer-Account anzufordern.
Veschiedene Unternehmen erfordern verschiedene Vorgehensweisen. Schlussendlich ist es unerl�sslich einen h�chst-verl�sslichen Prozess an der Hand zu haben, der Sie darauf hinweist, sobald accountbezogene Arbeit erledigt werden muss.
6.1.4.2. K�ndigungen
Tatsache ist, dass Personen Ihr Unternehmen auch verlassen werden. Manchmal geschieht dies unter gl�cklichen und ein anderes mal unter weniger gl�cklichen Umst�nden. In jedem Fall ist es notwendig, dass Sie �ber diese Situation bestens informiert sind, sodass Sie die notwendigen Schritte einleiten k�nnen.
Zumindest sollten die angemessenen Schritte folgendes beinhalten:
Den Zugang des Benutzers zu allen Systemen und dazugeh�rigen Ressourcen sperren (normalerweise mittels �nderung/Sperrung des Benutzerpasswortes)
Eine Sicherungskopie der Benutzerdateien erstellen, f�r den Fall, dass diese etwas beinhalten, das zu einem sp�teren Zeitpunkt ben�tigt wird
Den Zugang zu Dateien des Benutzers koordinieren
Die h�chste Priorit�t ist das System gegen einen gerade ausgeschiedenen Benutzer abzusichern. Dies ist besonders von Bedeutung, wenn der Benutzer unter Umst�nden entlassen worden ist, was beim Benutzer b�swillige Absichten gegen�ber dem Unternehmen hervorrufen k�nnte. Jedoch ist es auch unter anderen gegebenen Umst�nden im besten Interesse des Unternehmens rasch und verl�sslich den entsprechenden Zugang zum System zu sperren.
Dies weist darauf hin, dass auch hier ein Prozess zur Ihrer Alarmierung in Hinsicht auf Entlassungen im Unternehmen eingef�hrt werden muss — bevorzugterweise sogar bevor die K�ndigung stattgefunden hat. Dies setzt nat�rlich voraus, dass Sie eng mit der Personalabteilung Ihres Unternehmens zusammenarbeiten, um sicherzustellen, dass Sie rechtzeitig von K�ndigungen informiert werden.
Tipp
Im Umgang mit sogenannten "lock-downs" als Folge von K�ndigungen, ist genauestes Timing wichtig. Wird die Sperrung erst nach der eigentlichen K�ndigung durchgef�hrt, so besteht die Gefahr, dass die gerade gek�ndigte Person sich unerlaubterweise nochmals Zugang zum System verschafft. Wenn die Sperrung jedoch stattfindet bevor die jeweilige K�ndigung ausgesprochen worden ist, so k�nnte die betreffende Person zu fr�h alarmiert werden und der gesamte Prozess dadurch f�r alle Beteiligten erschwert werden.
Die K�ndigung wird zumeist mit einem Meeting zwischen der zu k�ndigenden Person und deren Manager sowie einem Vertreter der Personalabteilung Ihres Unternehmens eingeleitet. Deshalb w�rde ein Prozess, bei dem Sie genau am Beginn dieser Besprechung alarmiert werden, sicherstellen, dass der Vorgang der Sperrung zeitgerecht erfolgt.
Sobald der Zugang gesperrt worden ist, ist es Zeit eine Sicherungskopie der Dateien der gerade entlassenen Person durchzuf�hren. Diese Sicherungskopie kann Teil des Standard-Backups des Unternehms sein oder auch eine Sicherungsprozedur, welche lediglich der Sicherung von alten und hinf�lligen Benutzer-Accounts dient. Punkte, wie zum Beispiel Datenaufbewahrungs-Regulationen, die Konservierung von Daten im Falle eines Gerichtsverfahrens wegen ungerechtfertigter K�ndigung und dergleichen spielen alle ein wichtige Rolle in der Findung der geeignetsten Art, Sicherungskopien zu erstellen.
In jedem Fall ist eine sofortige Sicherungskopie empfehlenswert, da der n�chste Schritt (Zugang des Managers zu den Dateien der gerade entlassenen Person) die unbeabsichtigte L�schung von Daten zur Folge haben k�nnte. Unter solchen Umst�nden erm�glicht eine aktuelle Sicherungskopie die einfache Wiederherstellung von Daten, was den gesamten Ablauf nicht nur seitens des Managers, sondern auch Ihrerseits einfacher gestaltet.
An diesem Punkt m�ssen Sie festlegen, welchen Zugang zu den entsprechenden Dateien der Manager, der gerade entlassenen Person, ben�tigt. Abh�ngig von Ihrem Unternehmen und dem Zust�ndigkeitsbereich derjenigen Person, kann entweder kein Zugang ben�tigt werden oder auch der vollst�ndige Zugang zu allen Daten.
Im Falle, dass die Person das System f�r mehr als hin und wieder ein zuf�lliges e-Mail benutzt hat, ist es h�chstwahrscheinlich, dass der Manager sich kurz die Dateien durchsieht, um festzustellen was behalten werden muss und was verworfen werden kann. Bei Abschluss dieses Prozesses k�nnen zumindest einige der Dateien an den Nachfolger oder die Nachfolgerin der entlassenen Person weitergegeben werden. Ihre Unterst�tzung wird eventuell in diesem letzten Abschnitt des Prozesses ben�tigt werden, sofern der Manager selbst nicht in der Lage ist, dies selbst durchzuf�hren. Dabei kommt es selbstverst�ndlich auf die Dateien und die Art der Arbeit an, welche von Ihrem Unternehmen durchgef�hrt wird.
6.1.4.3. Berufswechsel
Auf die Anfrage zur Erstellung neuer Benutzer-Accounts zu reagieren und die Abfolge von T�tigkeiten einzuhalten, welche notwendig sind, um einen Account in Zusammenhang mit der K�ndigung einer Person zu schlie�en, sind beides relativ unkomplizierte Vorg�nge. Jedoch ist es nicht so klar definiert, wenn sich der Aufgabenbereich einer Person innerhalb des Unternehmens ver�ndert. Manchmal sind �nderungen des Benutzer-Accounts notwendig und manchmal auch hinf�llig.
Zumindest drei Personen sind dabei involviert, wenn es darum geht sicherzustellen, dass der Benutzer-Account angemessen rekonfiguriert wird und dem neuen Aufgabenbereich derjenigen Person entspricht:
Sie
Der vorhergende Manager des Benutzers
Der neue Manager des Benutzers
Es sollte m�glich sein, dass alle drei Personen (Sie selbst miteingeschlossen) festlegen k�nnen, was einerseits getan werden muss, um klar den alten Verantwortungsbereich auszugliedern und was andererseits notwendig ist, um den Account auf die neuen Anforderungen vorzubereiten. In vieler Hinsicht kann diese Vorgehensweise auch gleichgesetzt werden mit dem Schlie�en und Neuerstellen eines Benutzer-Accounts. Tats�chlich wird dies von einigen Unternehmen derartig gehandhabt.
Jedoch ist es wahrscheinlicher, dass ein Benutzer-Account behalten und entsprechend den neuen Anforderungen und Aufgaben modifiziert wird. Diese Ann�herung bedarf einer vorsichtigen Durchsicht des Accounts, um sicherzustellen, dass keine alten Ressourcen oder Zugriffsprivilegien auf dem Account zur�ckbleiben und dass der Account lediglich die Ressourcen und Privilegien passend zum neuen Aufgabenbereich des Benutzers besitzt.
Was die Situation noch weiters verkompliziert, ist die Tatsache, dass es oft eine sogennante �bergangsperiode gibt, in welcher der Benutzer Aufgaben erf�llt, die sowohl dem alten, als auch dem neuen Aufgabenbereich angeh�ren. Hier kann Ihnen vom alten und neuen Manager geholfen werden, indem ein bestimmter Zeitrahmen f�r diese �bergangsperiode angegeben wird.
