Argumente gegen gemeinsam genutzte Accounts
Argumente gegen gemeinsam genutzte Accounts
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.
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.
Use ed once in a while!
-
- Beiträge: 3281
- Registriert: 29.06.2013 17:32:10
- Lizenz eigener Beiträge: GNU General Public License
-
Kontaktdaten:
Re: Argumente gegen gemeinsam genutzte Accounts
Das Buch "Linux-Administrationshandbuch" hat ein Kapitel dazu: 20.5.3 Gruppen und gemeinsam genutzte Logins.
Willst du andere Quellen?
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 ... ppenloginsJedes Login, das von mehrere Personen verwendet wird, bedeutet Gefahr. Gruppenlogins ... Lassen sie diese in Ihrem Unternehmen nicht zu ... Gruppenlogin root ...
Willst du andere Quellen?
Zuletzt geändert von Anonymous am 15.01.2018 13:59:37, insgesamt 1-mal geändert.
(=_=)
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
Unsere neue Mutter: https://www.nvidia.com/de-de/data-center/a100/
Re: Argumente gegen gemeinsam genutzte Accounts
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
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
Re: Argumente gegen gemeinsam genutzte Accounts
$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
schau mal ob das in die "richtige" Richtung geht:
https://www.sans.org/reading-room/white ... ounts-1271
Re: Argumente gegen gemeinsam genutzte Accounts
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/
Re: Argumente gegen gemeinsam genutzte Accounts
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.
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.
Use ed once in a while!
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Argumente gegen gemeinsam genutzte Accounts
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.
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.
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Re: Argumente gegen gemeinsam genutzte Accounts
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.scientific hat geschrieben:tadaaa - sudo zum Einsatz.
Re: Argumente gegen gemeinsam genutzte Accounts
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?scientific hat geschrieben:Ü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.
Re: Argumente gegen gemeinsam genutzte Accounts
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:
das ist schon recht verbose, das da so alles im Logfile landet…
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)
----
…
-
- Beiträge: 3020
- Registriert: 03.11.2009 13:45:23
- Lizenz eigener Beiträge: Artistic Lizenz
-
Kontaktdaten:
Re: Argumente gegen gemeinsam genutzte Accounts
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
lg scientific
dann putze ich hier mal nur...
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main
Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie
auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main