Frage:
Warum sollten Sie gemeinsam genutzte Benutzerkonten vermeiden?
Steve Venton
2019-02-25 21:35:13 UTC
view on stackexchange narkive permalink

Ich kenne die bewährte Methode, um keine freigegebenen Benutzerkonten zuzulassen, aber wo ist diese bewährte Methode definiert? Ist es ein ISO-Standard oder so? Was sind die Gründe, immer Konten pro Person zu erstellen?

Für diejenigen unter Ihnen, die in Kommentaren antworten - bitte tun Sie das nicht.Ich habe sie gelöscht.Wenn Sie sie als Antworten schreiben möchten, wäre das sehr hilfreich.
Zehn antworten:
#1
+147
Monica Apologists Get Out
2019-02-25 21:53:54 UTC
view on stackexchange narkive permalink

Alice und Eva arbeiten für Bob. Alice ist eine sehr gute Arbeiterin, die genau das tut, was Bob von ihr verlangt. Eve ist ein krimineller Mastermind, der unbedingt Bobs Firma zerstören will.

Alice und Eve teilen sich dasselbe Konto.

Eve meldet sich bei dem Konto an und verwendet es, um einen wichtigen Geschäftsprozess zu sabotieren . Das Überwachungsprotokoll erfasst diese Aktion.

Woher weiß Bob, wer sein Unternehmen sabotiert hat? Er muss den schlechten Schauspieler loswerden, kann aber nicht beide entlassen, weil seine Firma von der Arbeit abhängt, die sie leisten. Er könnte nur einen feuern, aber er hat keine Möglichkeit zu wissen, welcher sein Freund und welcher sein Feind ist.

Wenn Alice und Eva getrennte Konten hätten, könnte Bob sicher sein, dass Eva diejenige war, die hat die Sabotage gemacht. Eve könnte sogar die Sabotage vermeiden, wenn sie weiß, dass ihr Konto geprüft wird und sie erwischt wird.

BEARBEITEN: Hinzufügen von Kommentaren:

Wenn Eve beendet wird, müssen Sie dies jetzt tun Setzen Sie das Passwort für jedes Konto zurück, auf das sie Zugriff hatte, anstatt nur ihre persönlichen Konten zu deaktivieren. Dies ist viel schwieriger zu verwalten, und Sie werden Konten verpassen.

Außerdem wird Ihre Fähigkeit, den Zugriff detailliert zu steuern, entfällt. Wenn Alice Schecks ausstellt und Eve sie unterschreibt, haben Sie im Wesentlichen keine technologische Möglichkeit, dies durchzusetzen, wenn sie dasselbe Konto verwenden.

Außerdem ist es für eine bestimmte Person schwieriger, böswillig zu werden Änderungen an ihrer Umgebung. Alice weiß, welche Dateien sich auf Alices Desktop befinden. Alle neuen Dateien werden wahrscheinlich eine rote Fahne für sie setzen. Alice weiß nicht, welche Dateien sich auf dem gemeinsam genutzten Desktop von Alice und Eve befinden. Es ist wahrscheinlich, dass neue Dateien mit einem Achselzucken und der Annahme beantwortet werden, dass ein anderer Benutzer sie dort abgelegt hat, kein böswilliger Akteur.

+1 Außer dass Eve, ein krimineller Mastermind, sich in Bobs Konto gehackt hätte, also hätte er sich selbst feuern müssen :-)
Eine häufigere Situation: Eva gibt auf oder wird gefeuert.Jetzt müssen Sie die Anmeldeinformationen für alles ändern, was Eve verwendet hat (vorausgesetzt, Sie wissen das). Sie können nicht einfach die Konten von Eve deaktivieren.
Freigegebene Konten machen es auch viel schwieriger zu erkennen, wann ein schlechter Schauspieler Zugriff auf ein Konto erhalten hat, auf das er Zugriff haben sollte.
Zum Körper hinzugefügt.Ich habe den Teil über Kontokompromisse nicht hinzugefügt, da ich denke, dass dies für alle Konten gilt.Wenn ich das falsch denke, lass es mich wissen und ich werde es hineinwerfen.
Selbst wenn Eve nicht darauf aus ist, das Unternehmen zu sabotieren, bedeutet die gemeinsame Nutzung eines Kontos durch Alice und Eve auch, dass Bob Alice keine zusätzlichen Berechtigungen erteilen kann, ohne sie auch Eve zu erteilen.Wenn Alice befördert wird und jetzt Zugriff auf Daten X hat, erhält Eve diese ebenfalls.
@Adonalsium In Bezug auf den Kontokompromiss, wenn ich bemerke, dass eine Datei in meinem persönlichen Verzeichnis oder Seiten in meinem Browserverlauf oder etwas anderes, das nicht mit meinem Konto synchron ist, auftaucht, da ich der einzige Benutzer bin, der eine rote Fahne auslöst.Selbst wenn ich ein öffentlich zugängliches Verzeichnis verwende, haben Dateien, die ich erstelle, meine Eigentümer-ID, und wenn Dinge unter meinem Namen auftauchen, würde ich reagieren.Auf einigen unserer Testmaschinen gibt es jedoch einige Testkonten mit gemeinsam genutzten Anmeldeinformationen. Wenn also Dinge auftauchen, gehe ich davon aus, dass jemand anderes mit einem gültigen Grund sie erstellt hat, ohne zu ahnen, dass jemand das Konto kompromittiert hat.
Der spezifische Begriff für den gewünschten Zustand lautet [** Nicht-Zurückweisung **] (https://en.wikipedia.org/wiki/Non-repudiation) - die Fähigkeit, Aktionen oder Änderungen (mit einem hohen Maß an Vertrauen) zuzuordnenmit einer einzigartigen Person.
"Wenn Alice und Eve getrennte Konten hätten, könnte Bob sicher sein, dass Eve diejenige war, die die Sabotage durchgeführt hat."Vorausgesetzt, Eve konnte natürlich keinen unbefugten Zugriff erhalten.Wenn Alice ihre Passwörter auf ihrem Monitor festhält, können Probleme auftreten.
@jpmc26 Dies ist wahr, aber dies ist nicht spezifisch für gemeinsam genutzte oder nicht gemeinsam genutzte Konten.
Es scheint, dass es bei einem Großteil davon hauptsächlich darum geht, Kontokennwörter zu teilen, anstatt nur den Zugriff über ein anderes Konto zuzulassen.Sie müssen die Konten anderer Personen nicht deaktivieren, wenn deren Kennwörter nicht freigegeben wurden.
In diesem Beispiel ist Eve möglicherweise böswillig oder eher ungeschickt.Wer hat die OrderEntry-Tabelle gelöscht?WTF Jungs?!
Dies ist also weniger ein theoretisches Prinzip als vielmehr eine praktische Realität, aber es ist auch viel schwieriger, das sichere Speichern und Teilen der Anmeldeinformationen zu verwalten.Wenn das Kennwort freigegeben wird, steigt die Häufigkeit, mit der es in seiner Lebensdauer über einen bestimmten Kanal gesendet wird, und damit auch die Wahrscheinlichkeit, dass jemand einen unangemessenen und unsicheren Kanal verwendet.
"Sie werden Konten vermissen": Vor einiger Zeit fand ich heraus, dass ich zwei Jahre lang nach meinem Ausscheiden aus dem Unternehmen Administratorzugriff (CRUD auf alle Mitglieder, wenn ich nur meine eigenen Aufzeichnungen hätte lesen können) auf eine 100-Personen-Organisation hatte (Dann entdeckte ich den Fehler. Er wurde erst entfernt, nachdem ich ihnen mitgeteilt hatte, dass sie meine Anmeldeinformationen nicht widerrufen hatten.
Ein Grund besteht darin, bestehende sicherheitsrelevante Standards nicht zu verfehlen, die die Verwendung eindeutig identifizierbarer Benutzerkonten und die Minimierung oder Minderung der Verwendung gemeinsam genutzter Konten erfordern.Beispiel: PCI DSS für die Kreditkartenverarbeitung.
#2
+30
Daniel
2019-02-26 20:22:37 UTC
view on stackexchange narkive permalink

Echte Geschichte, passiert an einem Arbeitsplatz eines Freundes (Gerichtsstand: Deutschland):

Eine Mitarbeiterin seiner grob beleidigten Kunden per E-Mail ihres Unternehmens. Sie wurde dafür gefeuert. Sie ging vor Gericht. Dort machte ihr Anwalt das Gericht darauf aufmerksam, dass die Mitarbeiter ihre Passwörter teilten (zum Beispiel, um die Mail eines Kunden in Abwesenheit eines bestimmten Kollegen zu beantworten).

Der Richter entschied, dass dies der Fall war Kein guter Beweis dafür, dass die betreffende Person wirklich diejenige war, die die beleidigenden E-Mails verschickt hat. Die Person musste wieder eingestellt und für den entgangenen Lohn entschädigt werden.

Moral: Eine Funktion von Benutzerkonten besteht darin, Benutzer voneinander zu unterscheiden, um ihre Maßnahmen überprüfbar zu machen. Nur private Konten erfüllen diese Funktion.

Es ist ein Klassiker in vielen Ländern mit vielen Variationen.Sie finden fast überall ein ähnliches Beispiel.Es ist so Mainstream, dass es in den meisten französischen Prud'homme (einem französischen Tribunal, das zur Entscheidung von Arbeitskonflikten ernannt wurde) nicht für lustige Geschichten geeignet ist.
Off-Topic: Aber das ist nur eine schlechte E-Mail-Einrichtung.Jedes E-Mail-System, das es in den letzten 15 bis 20 Jahren gab, unterstützt den delegierten Postfachzugriff, sogar Google Mail und früher als Hotmail bekannt.
@The D: Es gibt immer eine technische Lösung, aber in diesem Fall hat das Unternehmen beschlossen, die Mitarbeiter nur ihr Windows-Kennwort freigeben zu lassen. Dies ist das Ergebnis dieser Richtlinie.
@TheD: Ich habe diesen Satz so gelesen, dass jeder ein individuelles E-Mail-Konto hatte, aber Passwörter mit Freunden geteilt hat, damit sein Freund seine E-Mail beantworten kann, wenn er nicht verfügbar ist (im Krankheitsurlaub usw.).Es ist eine schlechte Richtlinie und Durchsetzung, keine schlechte E-Mail-Einrichtung
@slebetman: Ich denke, die Moral der Geschichte sollte lauten: Eine Funktion von Benutzerkonten besteht darin, Benutzer voneinander zu unterscheiden, um ihre Aktionen überprüfbar zu machen.Nur private Konten erfüllen diese Funktion.
Dies liest sich eher als Geschichte als als Antwort
@Daniel Das ist die Antwort!Alles andere auf dieser Seite ist eine Ablenkung.
#3
+15
WaltZie
2019-02-25 22:37:06 UTC
view on stackexchange narkive permalink

Sie sollten in allen Kontexten ein getrenntes Konto verwenden (Sicherheit oben).
Das Adonalsium-Beispiel zeigt es Ihnen, weil es erforderlich ist. Es gibt einige seltene Situationen, in denen es "nicht möglich" oder "nicht nützlich" ist ...

Beispiele: "nicht möglich" (ältere Protokolle / Anwendungen) "nicht relevant" (anonyme Aktionen)

Wenn dies nicht möglich ist, Sie sich jedoch identifizieren müssen, müssen Sie die Risiko, mehr Quelleninformationen wie möglich hinzuzufügen (z. B. Verbindungsinformationen, Verbindungszeit usw.)

Sie können die Risikobewertungsmethode nach ISO 27001 und das Risikomanagement nach ISO 31000 als Ausgangspunkt für die Beantwortung Ihrer Frage "Warum gemeinsame Benutzerkonten vermeiden? "

ISO 27001 enthält keine detaillierten RM-Methoden. Grundsätzlich heißt es: "Hey, RM ist eine gute Idee, Sie sollten eine haben."RM wird in 27005 detailliert beschrieben, aber wieder auf hohem Niveau ohne eine bestimmte Methodik und nur mit wenigen Beispielen (und noch dazu schlechten!).Die 27k sind in dieser Hinsicht wirklich weniger als hilfreich. Ich habe es in meinen Risikomanagementkursen schwer, Menschen das richtige Risikomanagement beizubringen, selbst wenn sie die 27k bereits kennen.
#4
+9
WoJ
2019-02-25 23:27:51 UTC
view on stackexchange narkive permalink

Die typische Antwort lautet Verantwortlichkeit, Rückverfolgbarkeit usw.; Mit anderen Worten, um wissen zu können, wer genau was getan hat.

Ein freigegebenes Konto hat n potenzielle Personen, die etwas tun, aber alles, was Sie haben, deutet darauf hin, dass ein Konto diese Aufgabe ausführt.

Dieses Problem wird normalerweise behoben, indem sichergestellt wird, dass jemand rechtmäßig für die Aktivitäten dieses Kontos verantwortlich ist. Dies kann machbar sein oder auch nicht, und Sie haben möglicherweise nicht jemanden, der die Verantwortung für die Handlungen anderer übernimmt.

Dieses Problem tritt häufig auf, wenn Sie einige Überwachungsaktivitäten auslagern - das Konto, das die Überwachungsaufgaben ausführt, sollte vertraglich sein Verantwortlich für das Unternehmen, das für seine Handlungen verantwortlich ist.

Wenn Sie keine verantwortliche Person zuweisen können, ist es Sache des Managements, eine Entscheidung auf der Grundlage des Risikos zu treffen: keine Dienstleistung zu haben oder nicht zu wissen, wer was mit diesem Konto macht.

#5
+5
Tom
2019-02-26 17:04:47 UTC
view on stackexchange narkive permalink

Best Practices werden nirgends "definiert", das bedeutet der Begriff. Eine bewährte Methode ist einfach eine etablierte Methode, um Dinge zu tun, die die meisten Menschen für die beste halten.

Sie geht umgekehrt. Sobald eine "Best Practice" dominiert, beschließt normalerweise jemand in einem Normungsgremium, sie in eine ISO oder eine andere Norm aufzunehmen. Es ruht dann dort, normalerweise ohne explizite Begründung oder eine zirkuläre Begründung, die darauf hinweist, dass dies die beste Praxis ist.

Die Gründe für diese spezielle Praxis sind ebenfalls praktische. Wenn Alice und Bob einen Account teilen und etwas Schlimmes passiert, zeigen beide auf die andere Person und Sie haben keine Möglichkeit herauszufinden, wer es getan hat. Bei persönlichen Konten wird behauptet, es sei kompromittiert worden, aber dann müssen Sie zumindest einen einzigen Punkt weiter untersuchen.

Es gibt auch explizite Anforderungen an die Rechenschaftspflicht in vielen Teilbereichen, z. B. Compliance, und sie spielen Sie in diese.

Es ist jedoch nicht selten, dass jemand (oder eine Organisation) etwas schreibt und veröffentlicht, das Best Practices dokumentiert.Das * definiert * sie nicht und es kann kontrovers sein, welche Praktiken in dieses Dokument aufgenommen werden sollten / nicht, aber das Nicht-Teilen von Konten ist klar vereinbart und das OP fragt einfach, ob jemand das aufgeschrieben hat.
Nein, OP fragt speziell, ob es definiert ist, z.in einer ISO-Norm.Meine Antwort lautet: Wenn es in der ISO-Norm enthalten ist, dann ist es da, weil sie es als Best Practice angesehen haben, nicht umgekehrt.
Ich bin froh, dass jemand tatsächlich den Standardteil der Frage angesprochen hat.Die PCI DSS-Anforderungen 8.1 und 8.5 beziehen sich auf die Verwendung eindeutiger Konten und nicht auf die Verwendung gemeinsam genutzter Konten.NIST SP 800-53 enthält auch Abschnitte zur Identifizierung und Verwendung freigegebener Konten.
#6
+4
Serge Ballesta
2019-02-26 13:08:22 UTC
view on stackexchange narkive permalink

Ich kenne nur eine Ausnahme von dieser Regel. Es gibt einen einzelnen Computer, der von mehreren Benutzern gemeinsam genutzt wird, und die folgenden Aussagen sind alle zutreffend:

  • Ein und nur einer dieser Benutzer ist zu jedem Zeitpunkt für diesen Computer verantwortlich.
  • Das Konto kann nur auf dem lokalen Computer verwendet werden - über das Netzwerk deaktiviert.

Dies kann auf 7/7 24/24 Systemen geschehen. In diesem Anwendungsfall behalten Sie eine akzeptable Zurechenbarkeit bei, indem Sie den Benutzer kennen, der zu einem bestimmten Zeitpunkt anwesend war, vorausgesetzt, Sie können die obige zweite Regel festlegen. Tatsächlich ist es jedoch gleichbedeutend damit, ein Konto ohne Kennwort zu haben und nur physische Sicherheit zu verwenden.

In der Regel wird in diesem Setup empfohlen, das Kennwort alle paar Stunden mithilfe einer Verwaltungssoftware zu rollen und die Mitarbeiter das freigegebene Kennwort bei Bedarf auf ihr persönliches Konto überprüfen zu lassen.
Beachten Sie auch, dass der hier angegebene Ansatz 0 Vorteile gegenüber der ordnungsgemäßen Konfiguration von Anmeldeinformationen für mehrere Benutzer hat. Wenn Sie lernen, wie Sie den lokalen Zugriff konfigurieren, können Sie lernen, wie Sie sudo richtig konfigurieren.
#7
+3
supercat
2019-02-26 23:30:32 UTC
view on stackexchange narkive permalink

Ein weiteres Problem, das noch nicht erwähnt wurde, besteht darin, dass jemand eine Benachrichtigung erhält, dass auf sein Konto zugegriffen wird oder zu einem Zeitpunkt zugegriffen wurde, zu dem er nicht darauf zugreift / nicht zugreift und nicht erwartet, dass dies jemand anderes tut Es ist viel wahrscheinlicher, dass sie einen Alarm auslösen, als wenn sie glauben, dass jemand, den sie autorisiert haben, auf das Konto zugegriffen hat.

Angesichts der Anzahl der Fälle, in denen dies der Fall sein könnte Wenn jemand eine andere Person autorisieren muss, eine bestimmte Aktion in seinem Namen auszuführen, wäre es äußerst hilfreich, wenn die Dienste ein Mittel enthalten könnten, mit dem Konten sekundäre Anmeldeinformationen mit eingeschränkten Rechten autorisieren und widerrufen könnten. Auf diese Weise kann das System melden, welche Anmeldeinformationen für den Zugriff auf ein Konto verwendet wurden, sodass jemand die erwarteten von unerwarteten Aktivitäten besser unterscheiden kann.

#8
+3
Vcode
2019-02-28 02:47:23 UTC
view on stackexchange narkive permalink

Hier einige Punkte zum besseren Verständnis und zur schnellen Überprüfung.

Rechenschaftspflicht

Rechenschaftspflicht ist ein weiteres wichtiges Prinzip der Informationssicherheit, auf das Bezug genommen wird die Möglichkeit, Aktionen und Ereignisse in der Zeit bis zu den Benutzern, Systemen oder Prozessen zurückzuverfolgen, die sie ausgeführt haben, um die Verantwortung für Aktionen oder Auslassungen festzulegen.

Compliance

Wenn Sie den Weg zur Einhaltung der DSGVO oder der meisten Vorschriften beschreiten möchten, müssen Sie in der Lage sein, eine Zeile zu definieren, auf die jedes Konto Zugriff hat.

Rechtlich

Im Falle einer Prüfung müssen Sie in der Lage sein, die Konten zu bestimmen, die kompromittiert wurden oder für eine Aktion verantwortlich waren.

Verwalten und schützen

Um ein Konto zu schützen, zu verwalten und zu überwachen, ist es einfacher, einen separaten Einzelzugriff zum Löschen, Ändern und Erkennen abnormaler Nutzung zu haben.

Auch wenn Sie keine Vorschriften befolgen, sollten Sie diese (empfohlen) befolgen Das B est Practices "Es hilft Ihrem gesamten Netzwerkprozess in großem Maßstab.

Dies ist nur eine Zusammenfassung anderer Antworten und nichts Neues?
#9
+1
ryanyuyu
2019-02-28 20:17:04 UTC
view on stackexchange narkive permalink

Zusätzlich zu dem Überwachungsproblem, auf das andere Antworten hinweisen, sind gemeinsam genutzte Benutzerkonten von Natur aus weniger sicher als ein Einzelbenutzerkonto auf derselben Plattform .

Wenn mehr Personen die Anmeldeinformationen für die Anmeldung kennen, ist dieses Konto weniger sicher. Sie haben jetzt viel mehr potenzielle Opfer von Social-Engineering-Angriffen. Jede weitere Person mit Zugriff auf das Konto ist ein weiterer Angriffsvektor gegen die Sicherheit dieses Kontos. Wie das Sprichwort sagt, können zwei ein Geheimnis für sich behalten, wenn einer tot ist.

Ich würde auch aus psychologischer Sicht vor der Verwendung gemeinsamer Anmeldungen warnen. Gemeinsame Anmeldungen bedeuten nicht nur Bedenken hinsichtlich Prüfung / Verschulden, sondern auch, dass sowohl der Ruhm als auch die Schuld geteilt werden. Sie könnten die persönliche Rechenschaftspflicht und Arbeitsmoral beeinträchtigen. Wenn es sich um ein freigegebenes Profil handelt, fühlt sich jede Person weniger für die Sicherheit dieses Kontos verantwortlich. Selbst wenn sie die richtigen Dinge tun (z. B. einen Passwort-Manager verwenden und Phishing-E-Mails vermeiden), was ist, wenn ihr Mitarbeiter dies nicht tut? Warum sollten sie zusätzliche Anstrengungen unternehmen, wenn eine andere Person sowieso nur das Falsche tun wird?

Außerdem vermute ich, dass freigegebene Anmeldungen schwächere Kennwörter haben, die das Konto schützen. Der Versuch, ein sicheres Passwort zu teilen und es für mehrere Personen ordnungsgemäß zu verwalten, wäre unpraktisch. Sie haben wahrscheinlich entweder den kleinsten gemeinsamen Nenner für Kennwortschwäche ( CompanyName01 ?) Oder ein Kennwort, das physisch für alle in der Region sichtbar ist.

#10
+1
Ljm Dullaart
2019-03-01 00:17:50 UTC
view on stackexchange narkive permalink

Wie von vielen gesagt, sind Rechenschaftspflicht, Rückverfolgbarkeit, Haftung usw. die Hauptgründe. Es gibt eine Reihe zusätzlicher Punkte zu beachten:

  • Wie geheim sind die Informationen, auf die zugegriffen wird? Im Extremfall verwenden viele öffentliche FTP-Server (d) ein freigegebenes Konto "anonym". Und ist das Konto, mit dem Sie auf öffentliche WWW-Server zugreifen (ein nicht authentifiziertes Konto), nicht grundsätzlich dasselbe? Was ist mit WPA2-Passwörtern?
  • Wenn Sie eine Unternehmensrichtlinie erstellen, ist es viel einfacher, "NIEMALS Konten freigeben" durchzusetzen, als "Nun, Sie sollten niemals ein Konto freigeben, aber in einigen Fällen wie z Nur-Lese-Konto für nicht so geheime Informationen für einen begrenzten Zeitraum zwischen zwei Personen, die zusammenarbeiten. Sie können dies tun, wenn das tatsächliche Risiko gering ist. "
  • Es gibt auch einen Verwaltungsaufwand für gemeinsam genutzte Konten . Ein bereits gegebenes Beispiel ist die Notwendigkeit, Passwörter zu ändern, wenn jemand geht.
  • Einige Konten müssen freigegeben werden. Ein Beispiel ist root unter Unix / Linux. Ja, Sie werden die Verwendung von root in der Produktion stark einschränken, z. B. sudo mit umfassender Protokollierung und Sicherheitsüberwachung, einem Passwort-Tresor usw., aber es bleibt bestehen ist ein freigegebenes Konto.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 4.0-Lizenz, unter der er vertrieben wird.
Loading...