Jump to content

Security für Admin-Accounts


Empfohlene Beiträge

Moin zusammen,

 

ich habe da mal eine grundsätzliche Frage zum Thema "Security eurer Admin-Accounts", besonders bei Firmen zwischen 500-5000 Mitarbeitern. Es gibt ja "rustikale Wege" mit dem Standard-Administrator, der sich überall anmelden darf  und seinen Passwort-Hash überall hinterlässt, bis hin zu Admin-Accounts im Tier-Level (t0 - Domänenebene, t1 - Server-Admins, t2 - Client-Admins), Privileged access Workstations, die gekapselt z.B. nur die DCs administrieren können, LAPS, 2FA usw.

 

Die Frage kommt jetzt vielleicht etwas plump daher, aber mich würde mal interessieren, wie es bei anderen Firmen/IT-Abteilungen so läuft, wenn es um das Thema Security geht. Hier ist das Thema seit einiger Zeit sehr hoch aufgehangen, daher habe ich persönlich so ziemlich mit allen den genannten Themen zu tun, was einem das administrative Leben natürlich nicht einfacher macht.

 

Viele Grüße

Marcel

Link zu diesem Kommentar

Moin,

 

naja, wenn du so generell fragst, hast du die Antwort schon gegeben:

 

vor 18 Minuten schrieb soulseeker:

"rustikale Wege" mit dem Standard-Administrator, der sich überall anmelden darf  und seinen Passwort-Hash überall hinterlässt, bis hin zu Admin-Accounts im Tier-Level (t0 - Domänenebene, t1 - Server-Admins, t2 - Client-Admins), Privileged access Workstations, die gekapselt z.B. nur die DCs administrieren können, LAPS, 2FA usw.

 

Das ist tatsächlich die Bandbreite, die man "da draußen" antrifft. Ich vermute nicht, dass diese Einsicht dich weiterbringt, daher wäre wichtiger, was du denn eigentlich wissen willst.

 

Gruß, Nils

 

Link zu diesem Kommentar

Ich frage halt auch deswegen, weil man hier tatsächlich lange eher "rustikal" unterwegs war und jetzt in relativ kurzer Zeit mehrere Umstellungen durchzieht. Das klappt halt nicht immer ganz reibungslos.

 

Primär würde mich mal interessieren, wie die Meinung hier z.B. zum dreistufigen Tier-Modell als Security-Basis für administrative Angelegenheiten ist. Ich bin da manchmal etwas zwiegespalten, da ich dadurch teilweise länger damit zu tun habe zu rätseln, warum mal wieder irgendwas nicht geht, als mit der Aufgabe selber. 

Link zu diesem Kommentar

Wer es nicht macht, handelt aus meiner Sicht relativ grob fahrlässig. Security kostet viel Zeit auch bei der Administration. Daher ist es aus meiner Sicht der Weg den man gehen muss, wenn man das nutzt. 
Es gibt sicher viele die es nicht machen, da wäre mir das Risiko zu hoch. Daher Glückwunsch dass Ihr das getan habt.

bearbeitet von v-rtc
Edit
Link zu diesem Kommentar

Moin,

 

ganz einfache Antwort: das kommt drauf an.

 

Admin Tiering ist als Idee überzeugend, aber wenn man es richtig machen will, dann hat man auch richtig zu tun. Im Mittelstand habe ich bislang keine Implementierung davon gesehen, die auch nur halbwegs sinnvoll gewesen wäre ... und dann wiegt man sich in falscher Sicherheit. Wie immer bei Enterprise-Konzepten muss man schauen, was davon in einer Umgebung erforderlich ist, was sinnvoll ist und was man überhaupt leisten kann.

 

Ich bin mir aber grad nicht ganz sicher, wo die Diskussion hinführen soll.

 

Gruß, Nils

 

  • Like 2
  • Haha 1
Link zu diesem Kommentar
vor einer Stunde schrieb NilsK:

Moin,

 

ganz einfache Antwort: das kommt drauf an.

 

Admin Tiering ist als Idee überzeugend, aber wenn man es richtig machen will, dann hat man auch richtig zu tun. Im Mittelstand habe ich bislang keine Implementierung davon gesehen, die auch nur halbwegs sinnvoll gewesen wäre ... und dann wiegt man sich in falscher Sicherheit. Wie immer bei Enterprise-Konzepten muss man schauen, was davon in einer Umgebung erforderlich ist, was sinnvoll ist und was man überhaupt leisten kann.

 

Ich bin mir aber grad nicht ganz sicher, wo die Diskussion hinführen soll.

 

Gruß, Nils

 

Na die Richtung stimmt schon. Wir haben es halt implementiert, aber in der Praxis ist man momentan mehr damit beschäftigt, dadurch auftretende Probleme und Hindernisse zu beseitigen. Bisher habe ich auch noch keine externe Firma gesprochen oder Consultants getroffen, die dieses Modell im Einsatz gesehen haben oder selber nutzen. Da auch momentan Powershell remoting nicht durch den Tierlevel eingeschränkt ist, bzw. man wohl nicht so recht weiß, wie man das machen soll, ist die Sicherheit vielleicht auch etwas trügerisch.

Link zu diesem Kommentar

Moin,

 

Dass Dinge nicht gehen, ist bei dem Konzept ja erwünscht. Was das auf hohem Niveau heißt, davon können einige wenige Member hier im Board berichten. Dort ist das aber eben auch Enterprise-Level, es gibt also viel Personal und viel Knowhow, um damit umzugehen. Schon daran fehlt es ja in den meisten Umgebungen.

 

Hast du konkrete Fragen oder geht es um so allgemeine Betrachtungen?

 

Gruß, Nils

Link zu diesem Kommentar

Nein, konkrete Fragen habe ich tatsächlich nicht. Mich interessiert eigentlich nur, ob sich auch andere Unternehmen in unserer Größenordnung an diese Security-Konzepte herantrauen. Das Problem hier ist z.B., dass es zwar eine eigene (kleine) Security-Abteilung gibt, die restlichen „Admins“ aber diese typischen „Schweizer Armeemesser“ sind, die sich um alles kümmern müssen. Entsprechend unspassig ist es halt manchmal, sich mit Tier, privilege access workstation, 2-3Fa und anderen Security-Hürden auseinandersetzen. Aber letztlich wollen wir ja auch nicht irgendwann verschlüsselt in der Ecke sitzen.

Link zu diesem Kommentar

Moin,

 

ich ahne schon, wo euer Poroblem liegt: Ihr versucht, eure "rustikalen" Management-Prozesse in eine gehärtete Umgebung zu verpflanzen. Das geht nicht.

 

Es gab mal diesen Typen, der eine neue Methode zu putzen entwickelt hat, womit er in 30% der Zeit mit einer Wohnung fertig wurde. Und das ging so: Statt zuerst überall zu saugen, dann überall Staub zu wischen, dann überall zu putzen, dann überall zu bohnern usw. usw., hat er sich etwas gebastelt, womit er das gesamte Inventar jederzeit am Mann hatte, so dass er sich langsam durch die Wohnung bewegte, aber dafür Streifen für Streifen den gesamten Putzgang dabei absolvierte. Gleichers Ergebnis, weniger Zeit, weniger Gesamtstrecke.

 

Genau so müsst ihr das auch machen. Das Problem ist doch, dass immer das nächste Ticket genommen wird. Ihr müsst aber anfangen zu schauen, dass ihr die Tickets nicht nach der (vom Ersteller wahrgenommenen) Prio sortiert, sondern nach Tier. Und wenn Admin Uwe gerade was in Tier 1 gemacht hat, dann nimmt er sich als nächstes ein Tier 1-Ticket und nicht das, was zuoberst liegt. Dann muss man sich nicht so oft ummelden und ist weniger frustriert. Und man kann sich im Team sogar absprechen, in welchem Tier man morgens anfängt zu arbeiten - einer nimmt sich die aufgelaufenen Tier 0-Dinger, der andere Tier 1 usw. Dabei entstehen auch weniger Kontextwechsel, was den Geist auch wieder etwas entlastet.

 

Das mit den Kontextwechseln widerspricht vielleicht ein wenig dem Putzmann-Beispiel, aber Du verstehst, was ich meine.

bearbeitet von cj_berlin
Link zu diesem Kommentar
vor 3 Stunden schrieb soulseeker:

Nein, konkrete Fragen habe ich tatsächlich nicht. Mich interessiert eigentlich nur, ob sich auch andere Unternehmen in unserer Größenordnung an diese Security-Konzepte herantrauen. Das Problem hier ist z.B., dass es zwar eine eigene (kleine) Security-Abteilung gibt, die restlichen „Admins“ aber diese typischen „Schweizer Armeemesser“ sind, die sich um alles kümmern müssen. Entsprechend unspassig ist es halt manchmal, sich mit Tier, privilege access workstation, 2-3Fa und anderen Security-Hürden auseinandersetzen. Aber letztlich wollen wir ja auch nicht irgendwann verschlüsselt in der Ecke sitzen.

Das ist der Klassiker. Ich habe schon einige dieser Gespräche geführt. Gab es ein einfaches Ergebnis? Nein. Was ich in solchen Situationen versucht habe, ist die Technik und deren Auswirkungen besser zu erklären. 

 

vor 3 Stunden schrieb cj_berlin:

Das Problem ist doch, dass immer das nächste Ticket genommen wird. Ihr müsst aber anfangen zu schauen, dass ihr die Tickets nicht nach der (vom Ersteller wahrgenommenen) Prio sortiert, sondern nach Tier. Und wenn Admin Uwe gerade was in Tier 1 gemacht hat, dann nimmt er sich als nächstes ein Tier 1-Ticket und nicht das, was zuoberst liegt. Dann muss man sich nicht so oft ummelden und ist weniger frustriert. Und man kann sich im Team sogar absprechen, in welchem Tier man morgens anfängt zu arbeiten - einer nimmt sich die aufgelaufenen Tier 0-Dinger, der andere Tier 1 usw. Dabei entstehen auch weniger Kontextwechsel, was den Geist auch wieder etwas entlastet.

Hah! Interessanter Gedankengang. Das nimm ich mal mit :D 

 

Link zu diesem Kommentar

Aus dem Alltag eines Umsetzungsveranstalters... Einführung von Tier-Trennung und Eliminieren von NTLM-Auth:

 

Du mußt jedem erst mal erklären, warum er jetzt ne Domain mit angeben muß.

Du mußt danach jedem auch erklären, daß es überhaupt verschiedene Domains gibt und warum das wichtig ist.

Danach erklärst Du dann den "Doppel-Tier-Leuten", warum sie jetzt 2 Accounts haben und mit denen jeweils andere Dinge können bzw. eben nicht können. Und warum das alles vom Arbeitsplatz aus gar nicht mehr geht.

 

Damit hast Du die Basics der Tier-Trennung aus Sicht "Admin-Accounts" beinahe durch - wenn man ignoriert, daß "eigentlich" auch alle Peripheriesysteme (Identity Management, Systems Management, Inventory Scanner etc.) getrennt aufgebaut werden müssen. Das bezahlt aber quasi niemand, da wirst Du Kompromisse eingehen müssen. Das Thema PAW ist damit auch noch ungelöst - wir haben's mit CyberArk gemacht. MFA ebenso.

 

Und gegen "verschlüsselt in der Ecke" hilft das auch nur bedingt. Im Kontext des Work-Accounts kann man halt immer alles verschlüsseln, auf das der Work-Account Schreibrechte hat.

 

Wenn Du (wie wir) gleichzeitig versuchst, NTLM loszuwerden, mußt Du dann jedem erklären, warum sein Adminserver jetzt nicht nur seine Zielserver erreichen muß, sondern auch ziemlich viele DCs. Und warum DNS-Aliase nicht mehr funktionieren. Und warum er plötzlich nicht mehr auf \\10.0.1.15\c$ kommt... ("Ging doch bisher immer")

Dann aktivierst Du LDAP Channel Binding und stellst fest, daß Deine Loadbalancer für LDAPS über Nacht unbrauchbar geworden sind, weil sie SSL terminieren.

 

Und dann merkst Du, daß die meisten MFP (Scan to Folder) zwar Kerberos unterstützen, aber daran sterben, wenn der Serviceaccount nicht im Realm der Domain ist. Und daß auch ganz viele Drittanbieter Kerberos "unterstützen", aber nur wenn alles in einem Realm liegt.

 

Daran stirbt übrigens sogar .NET - System.DirectoryServices.AccountManagement verträgt es nicht, wenn der ausführende Account aus einer trusted Domain kommt: https://github.com/dotnet/runtime/issues/95676. Und es stirbt auch, wenn GetAuthorizationGroups aufgerufen wird, der Zielaccount Mitglied von Gruppen ist, die ForeignSecurityPrincipals als weitere Mitglieder haben (warum das überhaupt geprüft wird, weiß nur MS) und der ausführende Account keine Leserechte auf die FSP-Objekte hat.

Citrix PVS hat auch ganz lustige Probleme mit Trusts. Die checken nämlich an bestimmten Stellen nicht "reale" Gruppenmitgliedschaften von Serviceaccounts, sondern schauen ins AD. Konkret mußte ein Serviceaccount aus einer trusted Domain dort (!) in eine domain local (!) Group... 🙈

 

Wenn Du dann noch aufgrund "organisatorischer Anforderungen" (= Management-Wünsche) disjoint Namespaces hast, dann hast Du jetzt richtig Spaß an der Sache 😁 Und bist für mehrere Jahre unentbehrlich .

 

Da fließt noch sehr viel Wasser ins Meer...

 

PS: Wir haben ~8.000 MA im Konzern.

  • Like 1
  • Danke 2
Link zu diesem Kommentar

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...