Argumente gegen gemeinsam genutzte Accounts

[Meillo]

Hoi,

kann mir jemand Links nennen zu Websites mit Argumenten, warum man Logins individualisieren sollte und eben keine Gruppenlogins, die von mehreren Personen genutzt werden, haben sollte?

Also, ich brauche keine Argumente gesagt bekommen -- ich bin schon ueberzeugt -- ich suche Referenzen, auf die ich mich beziehen kann, um andere zu ueberzeugen. Zumindest das BSI sollte was haben und in der Wikipedia sollte auch was zu finden sein. Ich habe schon gesucht, hatte aber wohl die falschen Suchbegriffe ...

Waere super, wenn ihr mir da weiterhelfen koenntet.

[inne]

Das Buch "Linux-Administrationshandbuch" hat ein Kapitel dazu: 20.5.3 Gruppen und gemeinsam genutzte Logins.

Jedes Login, das von mehrere Personen verwendet wird, bedeutet Gefahr. Gruppenlogins ... Lassen sie diese in Ihrem Unternehmen nicht zu ... Gruppenlogin root ...

Wonach hast du denn genau gesucht? Ein https://www.google.de/search?q=gruppenlogins bringt sofort meine Quelle: https://books.google.de/books?id=-bmCLF ... ppenlogins

Willst du andere Quellen?

[uname]

Als Argument für gemeinsam genutzte Accounts fällt mir Anonymous ein:

https://de.wikipedia.org/wiki/Anonymous_(Kollektiv)

Ein paar BSI-Links:

https://www.bsi.bund.de/DE/Themen/ITGru ... 04133.html
https://www.bsi.bund.de/DE/Themen/ITGru ... 04392.html
https://www.bsi.bund.de/DE/Themen/ITGru ... 02519.html

[eggy]

$suchmachine mit "shared account policy bad" gefüttert ... diverse Treffer, unter anderem sans und technet
schau mal ob das in die "richtige" Richtung geht:
https://www.sans.org/reading-room/white ... ounts-1271

[TomL]

Waere super, wenn ihr mir da weiterhelfen koenntet.

Leider nicht mit Links, sondern nur mit Stichworten, die damit unmittelbar im Zusammenhang stehen. Dabei gehts um die Begriffe Revisionssicherheit, Compliance-Regeln und Datenänderungsprotokolle. Soweit mit bekannt ist, sind Änderungsprotokolle heute eigentlich der Standard großer IT-Anwendungen. IBM und SAP bieten z.B. seit jeher Änderungsprotokolle für Datenänderungen durch Sachbearbeiter in datenschutzrelevanten Bereichn an, z.B. HR bei SAP, und darüberhinaus heute sogar auch solcherart Protokollierung für Massendaten-Änderungsjobs oder Korrektur-Reports, was früher zu meiner Zeit noch nicht bedacht war. All das schließt einen Gruppenaccount vollständig aus, weil dadurch nicht mehr reproduzierbar ist, wer eine oder viele Änderungen durchgeführt hat.

Meines Erachtens ist der Gradmesser für die Erlaubnis oder die Ablehnung von Gruppenaccounts die Revisionssicherheit für Datenänderungen und das Compliance-Regelwerk des Unternehmens.

Kein Volltreffer, aber zumindest am Rand der Scheibe:
https://it-onlinemagazin.de/it-betrieb- ... chfuehren/

[Meillo]

Danke fuer die Links. Da war einiges hilfreiche dabei.

Eine andere Person hat mich offline noch auf folgende Seiten verwiesen, die ich bislang am passendsten fand:
https://www.bsi.bund.de/DE/Themen/ITGru ... 04015.html
https://www.bsi.bund.de/DE/Themen/ITGru ... nn=6604926

Den SANS-Artikel fand ich nett, weil der andersrum drauf schaut und sich fragt, wann denn gemeinsame Accounts Sinn machen und wie man richtig damit umgeht. (Allerdings wirkt er ganz schoen alt.)

Ich denke, ich habe erstmal genug Material. Danke euch allen.

[scientific]

Bei uns wird gerade im Zuge der ISO-Zertifizierung von einem allgemeinen root-Zugriff auf personalisierte Logins auf den Servern umgestellt. Und es kommt - tadaaa - sudo zum Einsatz.
Die verschiedensten User benötigen Adminrechte. Über sudo und auditd ist dann sichergestellt, dass nachvollziehbar protokolliert wird, wer welchen Befehl wann und wo am Server abgesetzt hat. Das wird dann zentral auf einem Logserver gespeichert.

[uname]

tadaaa - sudo zum Einsatz.

sudo ist eine tolle Anwendung und mach natürlich zur Einschränkung von Benutzerrechten Sinn. Leider wird es bei Ubuntu vollkommen falsch verwendet, wodurch es mindestens hier im Debianforum unrechtmäßig einen recht schlechten Ruf hat.

[uname]

Über sudo und auditd ist dann sichergestellt, dass nachvollziehbar protokolliert wird, wer welchen Befehl wann und wo am Server abgesetzt hat. Das wird dann zentral auf einem Logserver gespeichert.

Wirklich? Kannst du mal eine Logzeile posten? Was ist wenn mehrere Benutzer parallel "sudo -s" (root-Terminal) verwenden., sofern erlaubt. Werden die Pseudoterminals pty/pts (Benutzer und root) in Verbindung mit der Anmeldung der Echtbenutzer (siehe z. B. last) protokolliert? Was ist bei daueraktiven, z. B. tagesüberschreitenden Sitzungen mit screen oder tmux?

[ThorstenS]

Die userid des Benutzers wird geloggt, nicht der Name. Kannst du recht schnell einrichten, wenn du dich hieran hälst:
https://serverfault.com/questions/47075 ... on-servers (die pam Einstellungen mußt du mind. seit jessie nicht mehr vornehmen)

Hier wird der Befehl htop von dem Benutzer mit der uid=1000 aufgerufen:

Code: Alles auswählen

# ausearch -ua 1000
…
----
time->Fri Jan 19 11:19:41 2018
type=PROCTITLE msg=audit(1516357181.344:168767): proctitle="htop"
type=PATH msg=audit(1516357181.344:168767): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=14025391 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 namety
pe=NORMAL
type=PATH msg=audit(1516357181.344:168767): item=0 name="/usr/bin/htop" inode=2098744 dev=08:03 mode=0100755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL
type=CWD msg=audit(1516357181.344:168767): cwd="/home/thorsten"
type=EXECVE msg=audit(1516357181.344:168767): argc=1 a0="htop"
type=SYSCALL msg=audit(1516357181.344:168767): arch=c000003e syscall=59 success=yes exit=0 a0=559719bd6b68 a1=559719bdf058 a2=559719bd91c0 a3=0 items=2 ppi
d=10500 pid=10501 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=4 comm="htop" exe="/usr/bin/htop" key=(null)
----
…

das ist schon recht verbose, das da so alles im Logfile landet…

[scientific]

Ich kann dir leider noch nichts liefern diesbezüglich, da ich ganz neu dabei bin, und die Kollegen das gemacht haben. Ich muss mich selber erst einarbeiten.

lg scientific