 Ja, hallo. Freut mich, dass es noch ein paar Leute geschafft haben, am sozusagen der letzte Vortrag hier in dem Slot am Sonntag zum Thema Authorized Entities Directory, abgekürzt AEDI, ja, das ist ein freies Softwareprojekt von mir, ja, ich bin Michael, ich mache das so zeug beruflich. So, worum geht es in dem ganzen Ding? In der Ankündigung schreibe ich typischerweise so was wie Paranoides und Agiles-IAM für DevOps, ja, das sind irgendwie richtig schöne, viele Basswörts, ja, in einem, damit sich auch jeder angesprochen fühlt, aber eigentlich ist es natürlich ein ziemliches Nischenthema, nämlich wirklich in Zugriffskontrolle, Zugriffskontrolle speziell für Admins, für administrative Zugriffe in Rechenzentren. Ja, und also das ist so der, kommt rein, ja, Nachwuchs, ja, so, also es geht um die Zugriffskontrolle, immerhin, okay, also es geht um Zugriffskontrolle speziell für administrative Zugriffe in Rechenzentren, typischerweise Rechenzentren. Sei es jetzt was, was ich irgendwie reale Hardware, Cloud oder sonst irgendwas, das ist egal. Das Ganze hat seine Wurzeln tatsächlich in einem Kundenprojekt, ja, das war sozusagen ein propertäres Projekt und daraus ist sozusagen inspiriert, aus diesem Kundenprojekt ist eben das freie Softwareprojekt AEDA entstanden, ja, und es ging eigentlich darum, dass die sich Security-Abteilung gesagt hat, na ja, das kleine Usermanagement, was du mal in der einen Ecke da aufgebaut hast, das ist irgendwie so ganz schön, ja, aber es wäre irgendwie noch ganz schön, wenn zum Beispiel User und Gruppen tatsächlich nur auf den Systemen sichtbar wären, auf denen sie auch wirklich gebraucht werden, ja, so, und dann habe ich mich irgendwie so am Kopf gekratzt, also ich mache das schon eine ganze Weile mit zur Elderbdirektoris und so, und habe dann natürlich irgendwie auch festgestellt, klar, man macht es normalerweise so nicht, ja, also wirklich so die Einschränkung von Sichtbarkeit ist eigentlich nicht Usus, ja, also alle sind eigentlich happy, wenn sie es schaffen, irgendwie die Maschinen und Systeme überhaupt irgendwie an ihr Active Directory zu klemmen, ja, aber das Problem ist eben, das Grundproblem ist bei Active Directory, jede Benutzer und jede Maschine sieht quasi alles, ja, so, also bis auf wenige Ausnahmen, da gibt es so ein paar Einträgen mit speziellen Attributen, die sieht man dann nicht, ja, aber in der Regel ist es einfach so, ich habe irgendeine Windows-Maschine übernommen, dann sehe ich im Prinzip die ganze Windows-Domäne, ja, so, und dann kann ich eben auch mit einer hübschen kleinen Elderbsuche einfach sagen, gibt mir mal die Mitglieder der Gruppe Superduper Admins, ja, und dann viele Unternehmen synchronisieren dann auch die Handynummern da rein und dann kann der Angreifer auch von jedem beliebigen mit AD integrierten System eben auch gleich die Handynummern der Adminsabfragen und für Social Engineering-Attacken benutzen, ja, so, und das gilt es zu verhindern. So, das heißt, ich habe hier mal so ein paar generelle Security Requirements hingeschrieben, also denen ich versucht habe zu folgen, ja, und die findet man natürlich überall, also egal, wo man in welches Sicherheitsrichtlinien immer reinschaut, ja, es ist immer dasselbe, also Ne-to-No-Prinzip, ganz klar, und natürlich nicht mehr Privileg, ja, als unbedingt erforderlich, also Least Privilege-Prinzip, und dann natürlich auch irgendwie Zuständigkeiten wirklich trennen, ja, so, und das findet man überall, ja, und wenn man sich dann aber reale Implementierungen anguckt, ja, dann setzt das kaum jemand um, ja, so beziehungsweise, wie das in der Regel umgesetzt wird, ist, dass man einfach sagt, na ja, also, dann hänge ich diese Systeme mit dem erhöhten Schutzbedarf dann doch nicht an das zentrale AD, sondern ich mache noch ein weiteres Active Directory oder wie auch immer ein anderes geartetes User Management, wie sehr beliebt im Linux-Bereich ist ja auch Free E-Power oder sowas, aber selbes Design-Prinzip dort, man kann im Prinzip in dem Datenbestand nicht die Sichtbarkeit auf die Daten eben auf die Systeme einschränken, und man macht es eben dadurch, dass man halt mehrere Benutzerverwaltung dann wieder aufbaut, ja, und die dann wieder typischerweise über ein Meta-Directory oder sonst wie Identity Management Produkt eben synchronisiert, mehr oder minder gut. Das wollte ich hier genau nicht machen, sondern ich wollte sozusagen System schaffen, wo wirklich die alle relevanten Daten in der Datenbank drin sind, ja, insbesondere auch deshalb, weil ich auch ganz konsequent die Pflege dieser Daten eben auch delegieren wollte, ja, ich erkläre das in der Teil. So, und was natürlich auch ganz klar ist, ja, wenn man so ein System macht, dann braucht man auch irgendwelche Auditrails, also man muss auch irgendwie nachvollziehen können, wer hat eigentlich jetzt welche Daten geändert. So, und das Ganze natürlich als Grundlage auch wirklich so für ein bisschen härtere Compliance-Checks, also wirklich auch so, auch zum Beispiel so gesetzlich regulierte Systeme, wo dann tatsächlich einmal pro Jahr jemand vorbeikommt und da genauer draufguckt. Ja, was verstehe ich unter SecureDevOps, ja, das ist natürlich ein weites Feld, also es ist ziemlich wolkig, also man kann das sehr wolkig anfangen, ja. In diesem Kontext hier jetzt, was Identity and Access Management angeht, verstehe ich darunter halt, dass, wenn Maschinen administriert werden, ja, das wirklich immer auch wohl definierte Sicherheitsrichtlinien dabei angewendet werden, also eigentlich auf den ganzen Prozess, ja. Und das umfasst eben insbesondere auch die Zugriffsmöglichkeiten, also wer darf jetzt eigentlich mit irgendeinem beliebigen Config Management Tool eigentlich irgendwo was hinballern und Maschinen halt umkonfigurieren. Also respektive mal runtergebrochen, wer darf zum Beispiel auf einer Kiste überhaupt rot werden, ja. Das wird oft sozusagen anhand von Teams so strukturiert, also in Unternehmen, ja. Aber man kann das zum Beispiel auch ein bisschen agiler Hand haben und zum Beispiel anhand von Projekten, ja. Also weil jetzt reden alle so über Agil und dann sind die Sachen oft so projektbezogen. Was oft gerne gemacht wird auch ist, dass man Dinge anhand von Netzwerkgrenzen separiert, ja. Das ist teilweise auch hilfreich oder so, ja. Und diese Inspiration, ja, dass man zum Beispiel auch wieder sagt, oder sagen wir mal diese Struktur, dass man sagt, na ja, da hat sich schon mal jemand was überlegt, dass man eine Infrastrukturzone hat, Frontendzone, Mittelwehrzone, Backendzone. Das kann man zum Beispiel auch wieder, oder das sollte sich nach meinem Dafürhalten auch widerspiegeln in den Berechtigungen bei den Zugriffen. Und ja, dann gibt es halt auch typischerweise in Projekten eben so Staging, ja. Also von der Entwicklung eben, wo man einfach sagt, ja, auch die Entwickler haben da irgendwie volle Kontrolle drüber auf den Spielmaschinen, auf denen sie unterwegs sind, ja. Dann gibt es halt im Prinzip meinetwegen eine Teststage, wo Entwickler nur noch eingeschränktere Rechte haben, die schon irgendwie so von dem Ops-Team übertrieben werden. Und dann gibt es eben im Prinzip Produktionssysteme, wo nur wirklich Ops-Admins zum Beispiel Zugriff haben. Und all solche Strukturen sollen eben abbildbar sein. Ja, jetzt, ja, Agil ist halt auch so ein Schlagwort, ja, irgendwie. Ich sage auch gar nicht, dass ich der Agilitäts-Experte bin. Ich beobachte nur, dass im Identity- und Access-Management eben die ganzen Workflows, also diese ganzen Prozesse, wie bekommt jemand überhaupt Zugriff auf ein System, in keinster Weise Agil sind, ja. Das heißt also, also insbesondere, ja, natürlich einmal bei dem Onboarding, also Leuten wirklich Rechte beschaffen, ja, aber hinterher sozusagen auch die Rechte wieder wirksam entziehen, ja. Also das funktioniert alles überhaupt nicht gut, ja. Und beim Rechte beschaffen ist es noch so, derjenige, der die haben will, der kümmert sich irgendwie drum, dass er irgendwann auch arbeiten kann, ja. Aber wenn jemand ein Unternehmen verlässt, ja, dann ist irgendwie, na ja, da müsste man jetzt mal den User-Datenbestand aufräumen und so, das passiert dann in der Regel nicht, ja. Also von daher soll es eben auch, da eben auch wirksame Mechanismen für geben. Und ich habe vorhin schon gesagt Delegation, also das heißt anstatt, dass jemand darauf wartet, also, sagen wir mal so, der Standard Workflow ist oft, ich stelle irgendwo ein Ticket, ich brauche irgendwie Zugriff auf dieses und jene System, ja. Und dann sagt irgendwie irgendein mächtige Proxy-Helpdesk-Rolle, sagt, hm, jetzt brauche ich aber noch die Bestätigung von dem Teamleiter, ja, sozusagen, sagen, dass das auch erlaubt wird und so weiter, ja. Dann haben wir schon zwei Leute da drin, der eine, der sagen darf, dass das passieren soll, ja. Und der andere, der eigentlich gar nicht weiß, um welches System es eigentlich geht. Eventuell weiß der Teamleiter auch nicht, um welches System es geht, ja, irgendwie so, denn der sagt einfach nur, der soll arbeiten können, ja, und dann passiert es, ja. Und das finde ich in vielerlei Hinsicht suboptimal, ja. Das heißt optimaler finde ich, dass jemand, der wirkliches entscheiden kann, es auch gleich selbst tut, ja, weil er ist schneller, ja. Und er ist sich auch irgendwie vielleicht auch bewusster auf, was es wirkt, was er da jetzt gerade macht. Er schreibt nicht nur irgendwie Eck hin, sondern er muss tatsächlich auch Daten pflegen, die eine Wirkung haben, ja. Also also von daher, keine Workflows. So, natürlich, wenn man delegiert, administriert, brauche ich im Prinzip feinkranulierte Administration, also feinkranulierte Berechtigungsschema da, ja, irgendwie, um das überhaupt delegieren zu können. Und was ich natürlich auch brauche, sind eben Constraints, idealerweise direkt auf der Datenbank, ja, um halt irgendwie Fehleingaben, inkonsistente Eingaben zu vermeiden. Und wo ich auch immer ein großer Fan bin, wenn sozusagen alle Arten von Schnittstellen, ja, also sowohl zum Beispiel ein Webinterface als auch zum Beispiel direkt der LDAP-Schreibzugriff, ja, wenn da immer dieselben Regeln gelten, ja. So, nochmal ein bisschen so Anti-Patterns, ja, also was ich zum Beispiel nicht mag, sind allmächtige Proxyrollen, also Leute, die eigentlich von dem Detail, von der Fachlichkeit überhaupt keine Ahnung haben, ja, aber die Berechtigung haben ist zu tun, das ist so, Helptestmitarbeiter, oft schlecht bezahlt. Eine Rolle, die man insbesondere bei, sagen wir mal, Systemen mit höherem Schutzbedarf jetzt nicht unbedingt irgendwelche Sachen machen lassen will, ja. Zum Beispiel, ja, also, dann eben langsame Workflows, ja, also hier, der muss auch noch genehmigen und da noch und so, und Druckzug summieren sich die Tage, die man warten muss, bis es dann tatsächlich passiert, ja. Für mich ist auch ein Anti-Pattern zum Beispiel Personeneinträge, also Personen direkt als Benutzer-Account zu verwenden, ja, weil das dann sozusagen dazu führt, dass die Menschen immer nur genau einen Account haben, ja. Also, das ist eben ein Anti-Pattern eben auch, wieder denselben Account für alles zu verwenden. Huh, ja, das war eigentlich immer das Ziel beim Identity and Access Management, ja, zu sagen, wow, ja, ich will ja nur einen Account haben, mit dem greife ich irgendwie meine E-Mail auf meine E-Mail zu, mit dem greife ich aufs WLAN zu, mit dem administriere ich aber auch den DNS-Server oder sonst irgendwas, und da sage ich eben, hm, ist ein bisschen suboptimal, wenn die Leute ihr E-Mail, also das Passwort von dem einen Account eben zum E-Mailabruf in ihr Smartphone eindängeln und da abspeichern, ja, dann sollte man nicht denselben Account mit demselben Passwort zum Unkonfigurieren des zentralen DNS nehmen oder so, ja. So, das heißt, man braucht einen Weg zu sagen, eine Person hat mehrere Accounts für verschiedene Aufgaben, mit verschiedenen Sicherheitsstufen. So, was ich auch nicht so mag, ist Passwort-Synchronisierung, ja, teilweise mache ich es, ja, aber es ist halt immer irgendwie so ein bisschen, wird man immer so ein bisschen nervös dabei, weil, ja, man behandelt eben ein Passwort und schreibt es irgendwo hin, ja, dann muss man wirklich so die ganzen Berechtigungs-Sachen und so, und insbesondere den Account, den man dann verwendet, um auf das Zielsystem zu schreiben, ja, den muss man halt auch super gut schützen, ja, so, und das ist eigentlich ziemlich anstrengend, deswegen versuche ich es auch zu vermeiden. So, und was ich auch versucht zu vermeiden, also Elderbserver, da fragen die Leute mich immer erst mal, oh, das ist ja so ein hierarchische Datenbank und so, ah, und wie strukturieren wir jetzt unser Unternehmen so in die Hierarchie, ja, dass wir das irgendwie alles so schön abbilden können, dann sage ich gar nicht, ja, alles immer möglichst flach, ja, und eben nicht die Berechtigung streng an die Hierarchien zu hängen. Ja, und auch ein Anti-Pattern ist zum Beispiel die Wiederverwendung von Benutzernamen, also das übliche P-Schmidt-Problem, ja, kommt ein Peter-Schmidt in das Unternehmen, ja, oder auch eine Petra-Schmidt, ja, und dann bekommt er oder sie die Benutzerkennung P-Schmidt. So, und dann ist die Wahrscheinlichkeit relativ hoch, je nach Unternehmensgröße, ja, dass es wieder jemanden gibt, ja, und so, und insbesondere der schlimmste Fall ist, der erste oder die erste P-Schmidt geht, die Benutzerkennung ist wieder frei, ja, so, und dann bekommt irgendwie die nächste Person, die auf die das passt, irgendwie die selber Benutzerkennung, ganz schlecht für Auditrails, irgendwie so ziemlich das Schlimmste, was man machen kann, ja, das heißt, die Wiederverwendung von Benutzernamen oder aber auch zum Beispiel POSIX-IDs und POSIX-G-IDs ist absolut zu vermeiden. So, also nochmal kurz, Paradigmen, immer explizit, ist immer besser als implizit, natürlich braucht man für die Berechtigungen, also für eine sichere Berechtigung, auch eine sichere Authentifizierung, dann sollen eben mehrere Counts pro Person benutzbar sein, ja, die sind miteinander verknüpft, also das heißt, ich habe einen Personeneintrag und dann eben mehrere Account-Einträge, so dass ich es auch vernünftig managen kann und manche IDs sollen eben persistent sein und nie wieder benutzt werden und Autorisierungen sollen eben durch Referenzen zwischen Objekten im Prinzip, also beliebigen Referenzen zwischen Objekten entstehen und eben nicht basierend auf einer Hierarchie, ja, also kommen gleich ein paar Bildchen, wo das klarer wird. So, erstmal, wie sieht so die Systemarchitektur von so einem Ding aus, ja, also letzten Endes ist hier das irgendwie einfach ein Unix-O-I-D-System, was administriert werden soll, hier unten ist eine Linie abgeschnitten, ja, also die greift halt im Prinzip auf ein Directory zu, also via LDAP und letzten Endes möchte admin eben auf diesen Unix-O-Iden-Server zugreifen, ja und jetzt ist das System halt einmal hier mit Replicken, also mit Read-Only-Replicken integriert, ja, das heißt, diese rote Linie hier ist mir relativ wichtig, das heißt, die ganzen mit dem System integrierten Systeme greifen eben nicht direkt auf die beschreibbaren Providers da oben zu, sondern auf Read-Only-Consumer, ja, und diese Read-Only-Consumer bekommen eben mit Pull-Requests, bekommen die Daten von den beschreibbaren Providern, ja, dementsprechend können eben auch die Benutzer selbst, zum Beispiel hier über Web-Oberflächen, darauf zugreifen, um Daten einmal zu pflegen, wenn sie dazu berechtigt sind, oder zumindest ihr eigenes Passwort neu zu setzen, genau. Und insbesondere ist auch sozusagen LDAP als Protokoll auch die offizielle Bulk-Schnittstelle für Datenpflege, das heißt, die Leute haben die Erlaubnis, sich selber irgendwelche Tools zu schreiben, irgendwelche Skripte zu schreiben, ja, um halt zum Beispiel viele Daten auf einmal zu manipulieren. Ja, das Ganze muss natürlich hoch verfügbar sein, also sowas ist typischerweise so eine Replikations-Turbologie, das heißt, ich habe hier wieder diese Schicht von diesen beschreibbaren Providern, ja, und dann habe ich eventuell halt Gruppen von Read-Only-Consumern in verschiedenen Rechenzentren, und jetzt kann man zum Beispiel sehen, man kann da so beliebige Vermaschungen bilden, also hier kann man zum Beispiel sagen, okay, wenn hier der Atlantik dazwischen liegt, ja, dann mache ich hier oben nur eine Vollvermaschung auf der Providerebene, und immer die lokalen Konsumer gehen halt ins lokale Rechenzentrum an die Provider, ja, so ist es so ein typischer, typisches Setup. So, jetzt habe ich zwar gesagt, hier keinerlei Hierarchien und so, ja, aber es gibt halt trotzdem eine Baumstruktur in LDAP immer grundsätzlich, ja, deswegen auch hier, auf der obersten Ebene gibt es im Prinzip die sogenannten Zonen, ja, die Zonen sind einfach nur Bereiche beliebiger, also beliebige Bereiche delegierter Administration, das können eben Teams sein, das können Projekte sein, auch ein Mix von alledem, ja, und in davon gibt es jetzt auch mehrere besondere Zonen, zum Beispiel eine PAP-Zone, das ist wirklich einfach wie der PAP-Ordner auf einem FTP-Server, alle angeschlossenen Systeme können da alle darin enthaltenen Objekte lesen, dann gibt es eine Zone Ae, das ist eben eine spezielle Zone, weil das System auch mit sich selbst integriert ist, also von daher ist das die Zone für die Administration von Ae dir selbst, von den Ae dir Systemen selbst, und dann kann man sich noch besondere Zonen machen, wie zum Beispiel irgendwie, wo man Personen und Organisationsdaten zum Beispiel aus einem Personalwesen rein synchronisiert. So, und typischerweise in so einer Zone gibt es eben persönliche User-Accounts, persönliche User-Accounts sind wirklich Benutzerkonten für Personen, ja, dann gibt es Benutzergruppen, dann eben Servicegruppen, und eben noch Sudo-Regeln, und auch besondere Benutzergruppen, die zum Beispiel auch wieder für die delegierter Administration einer Zone benutzt werden. Also typischerweise die Zonen atmen können eben alles innerhalb einer Zone eben beschreiben und verändern, und die Zonen Auditoren können innerhalb einer Zone alles lesen. So, und das kann man dann auch ein bisschen weiter runterbrechen, also man kann eben Hosts anlegen und eben Benutzer-Accounts anlegen für integrierte Systeme, und bei den Hosts kann man sogar auch noch Netzwerkkonfiguration dran kleben, wenn man das möchte. So, das ist so das volle ER-Diagramm, ja, und wie ihr seht seht ihr da gar nichts, deswegen habe ich mal so ein etwas freundlicherer Auszug davon gemacht. So, also das zentrale Element sind eigentlich Servicegruppen, also die Servicegruppen, die modellieren alles, also Mengen von Diensten oder auch zum Beispiel Rechnern, die unter dieselben Sicherheitsrichtlinien fallen sollen. Das ist jetzt die abstrakte Variante, ich sage jetzt mal ganz konkret, eine Servicegruppe ist zum Beispiel ein geklasterter Service. Ja, also zum Beispiel die AEDI-Provider selbst sind auch wieder eine Servicegruppe und die AEDI-Konsume auch, die erbringen jeweils einen bestimmten Teil eines Dienstes und deswegen sind die sozusagen geklastert in eine Servicegruppe. So, in dieser Servicegruppe sind eben einmal entweder so Dienstekonten oder Tool-User oder Service-Accounts oder wie auch immer das nennen wollt, die quasi benutzt werden, um überhaupt Daten abrufen zu können von dem System. Also das heißt Grundgedanke ist einfach wirklich, Grundgedanke ist wirklich, diese Systeme hier müssen sich selber hier anmelden, um autorisiert zu werden, überhaupt Daten sehen zu können. Also Benutzergruppen, Sudoweregeln und so weiter. Also das heißt, jeder dieser Server, und das können noch mal viele sein, also bei dem einen proprietären Vorgänger sind das ungefähr 15.000, die haben allen individuelles Passwort. Also eigentlich auch wie Computerkonten in der AD-Domain, die haben auch alle ein eigenes Passwort, ein individuelles Passwort und wenn man es ordentlich macht, wird das so ständig gewechselt. So, und auf jeden Fall hier sind im Prinzip, die Mintkleider eben der Servicegruppe sind im Prinzip immer die Tool-Accounts oder zum Beispiel auch die Host-Accounts, die unterscheiden sich so ein bisschen voneinander, die benötigt werden, um überhaupt Benutzerdaten und Gruppen sehen zu können. Und wie kommt jetzt die Sichtbarkeit zustande? Okay, hier diese Tools oder Hosts oder wie auch immer, sind Mintkleider in dieser Servicegruppe. Und im einfachsten Fall setzt man hier praktisch einen Link, eine Referenz auf eben eine Benutzergruppe. Noch kurz zur Erläuterung. Was ist eigentlich, also wie ist das strukturiert, das Bild? Das Kästchen ist im Prinzip immer ein Eintrag, soll ein Elderb-Eintrag repräsentieren. Die Beschriftung innerhalb dieses Kästchens ist die sogenannte strukturelle Objektklasse, also der Typ des Eintrags. Und die Links zwischen den Dingen, das sind einfach Attribute und enthalten meistens einfach den hierarchischen Distinkwisch-Namen von dem referenzierten Eintrag. So, das heißt, hier habe ich im Prinzip schon mal eine Beziehung, ist quasi Mitglied von der Servicegruppe. Und dann gibt es hier zum Beispiel ein Attribut, das heißt eye-visible groups. Okay, wenn dieser Link existiert, dann werden die Berechtigungen das so, dass eben einmal die Gruppe sichtbar wird für hier das angeschlossene System und auch deren Mitglieder. Das heißt, damit dieser User für dieses System zum Beispiel sichtbar ist, muss die komplette Referenzenkette über hier praktisch dieses Attribut und dem Member eben existieren. Also die muss korrekt gesetzt sein. Soll zum Beispiel irgendeine bestimmte Gruppe Sudow-Befäle ausführen können, dann gibt es auch hier wieder eine Sichtbarkeitsregel, ist die Sudow-Regel überhaupt sichtbar. Und hier dann wieder eine Referenz eben auch auf wieder eine Usergruppe. So, das ist schon der ganze Mechanismus eigentlich. Die ganzen Einträge sind halt jeweils in Zonen deswegen von den Zonen-Admin tatsächlich völlig autark gepflegt werden. Das heißt, typischerweise ist es so, dass ein Zonen-Admin zu dem übergeordneten Eye-Admin kommt und sagt, ich brauche so eine Zone, und dann sagt er okay und legt ihm einfach so eine leere Zone an und delegiert die einfach an diesen Benutzer oder einen neuen Account den er stellt. So, das heißt, jeder dieser Einträge liegt potenziell auch in unterschiedlichen Zonen. Diese Referenzen, die können auch Zonen übergreifen sein. Also es müssen nicht alle sich referenzierenden Einträge innerhalb einer Zone sein, sondern die können in unterschiedlichen Zonen sein. Das heißt, ich kann mit dem Mechanismus mehrere Dinge abbilden. Also diese typische Zusammenarbeit zwischen DEF und OPS Teams zum Beispiel. Ich kann zum Beispiel sagen, alles liegt innerhalb einer Zone. Das ist so der sicherste Modus. Das sind Produktionssysteme, die OPS Leute sagen, hier lassen wir niemand anderes drauf. Das sind zum Beispiel Systeme, da gehen Kundendaten durch, da kann man irgendwie alle E-Mails mitlesen oder sonst irgendwas. Das ist ganz klar abgeschottet. Aber wenn jetzt doch mal ein Entwickler für eine Woche drauf muss, dann muss er noch irgendwie separat was unterschreiben und dann kriegt er im Prinzip einen temporären User Account. Auch innerhalb der einen Zone, der wird noch dran geschrieben, der ist nur gültig bis dann und dann. Dann soll es einen Outtake-Expiry geben, sondern darf da vielleicht jemand eine Woche lang irgendwas tun. Aber alles innerhalb einer Zone, die Leute haben alle sozusagen alles unter Kontrolle. So, dann könnte man sagen, es gibt eine abgestufte Zone, also praktisch eine abgestufte Variante. Wenn man einen User anlegt, dann muss man dem auch bei dem Passwort Reset helfen und so und dann können die Leute sagen, naja gut, aber das will ich jetzt nicht machen. Das heißt, ich mache die erste Abstufung. Ich sage, ich habe immer noch eigene Usergruppen, eigene Servicegruppen in meiner Zone. Aber ich referenziere Userkonten aus einer anderen Zone. Das heißt, ich sage, ich kenne den Teamleiter drüben, der macht das mit der Passwort, der macht das mit der Datenpflege und der Passwort-Rücksetzung, macht er ordentlich und so, dem vertraue ich. Aber trotzdem möchte ich immer noch unter Kontrolle haben, wer kommt eigentlich in welche Gruppen rein, also die Gruppenpflege. Oder ich kann sagen, zum Beispiel typischerweise auf Entwicklungssystemen ist mir alles scheißegal. Also der Teamleiter aus dem Entwicklerteam, der darf auch bestimmen, wer sozusagen auf bestimmte Systeme eben darf, indem er die Leute einfach auch in die Benutzergruppen aufnimmt. Und ich referenziere halt einfach hier nur noch von den Servicegruppen, die Benutzergruppen, die aber auch die anderen pflegen. Das heißt, ich habe nochmal die Möglichkeit auch, dass Leute in unterschiedlichen Zonen im Prinzip auf unterschiedliche Arten und Weisen zusammenarbeiten. Also dass die alleine einfach nur durch die Variante, wo ziehe ich im Prinzip die Grenze, wo welche Referenz, welche Zone überschreitet. So weit klar? Ja, dann machen wir. Okay, ich wiederhole mir die Frage. Also was passiert, wenn zum Beispiel irgendjemand, der überhaupt irgendwelche Rechte hat? Also es muss ja nicht nur ein Teamleiter sein, der zonenatmen ist, sondern überhaupt irgendjemand, der irgendwelche Rechte hat. Was passiert, wenn der geht? Typischerweise würdest du, also hier oben seht ihr zum Beispiel, deswegen gibt es hier eine Unterscheidung zwischen quasi Tool-Accounts und wirklich persönlichen User-Accounts. Persönliche User-Accounts sind mit einem Personenobjekt verbunden. So, typischerweise kann es eben zu einer Person mehrere User-Accounts geben. Also hier gibt es eine 1 zu N Beziehung. Und diese Personeneinträge, die werden typischerweise mit einem Personalwesen synchronisiert. Das heißt, das muss man dann jeweils umgebungsspezifisch anpassen. Also je nachdem, was die Leute als Personalwesen haben oder als Datenexport-Schnittstelle oder sowas. Das heißt, wird die Person zum Beispiel deaktiviert, weil sie eben das Unternehmen verlassen hat, wird auch automatisch, schlägt dann 2 Minuten später ein Grundjob zu, der auch alle angeschlossenen persönlichen User-Accounts deaktiviert. Haben wir angenommen, der Neue soll die Alte hatte? Neue beantragen, immer neu beantragen. Also irgendwas klonen ist übrigens, ach so, das habe ich vergessen auf meiner Antipattern, auf dem Antipattern-Slide. Also irgendwas klonen und so, oder irgendwas übernehmen, oder so ein totales Antipattern, irgendwie, das kriegst du nie in den Griff. Das heißt, sämtliche Rechte, das ist immer so das Vorgehen, sämtliche Rechte müssen einzeln neu beantragt werden. Sonst kommst du nämlich unter in Teufels Küche. Und werden automatisch abgeholt. Naja, also okay, noch eine Sache. Dieses Ding hier, das dient auch dazu, das Azubi-Problem zu lösen. Also Azubis sind nämlich, nachdem sie ihre Ausbildung durchhaben, die mächtigsten Benutzer im ganzen Unternehmen, weil sie nämlich ständig weitere Rechte akkumulieren. So, und das ist nämlich so, das ist nämlich genau eines der Probleme bei diesem ein Account pro Person Ansatz. Das Problem ist, dass wenn Azubi oder auch jemand anderes, aber bei Azubis passiert es halt regelmäßig und häufig, wenn jemand die Abteilung wechselt, dann muss man den Abteilungswechsel detektieren und man muss dann sozusagen Rechte wieder entziehen und die Rechte müssen eigentlich für die neue Rolle in der neuen Abteilung, müssen neu beantragt werden. Und deswegen ein Teamleiter, der würde einfach nur mal Azubi sagen, okay, ich weiß, der ist drei Monate bei mir vom 1. bis zum 31. irgendwas. So, das heißt, ich leg den praktischen persönlichen User Account in meiner Zone an, schreib da dran, 31. 10. jetzt zum Beispiel ist Ende Gelände, dann verlässt der mein Team wieder und versieht das mit Auto Expiring, dann geht das in der nächsten Abteilung das ganze Spiel wieder von vorne los. Das heißt, bei Azubis würdest du hier im Prinzip drei Monate gültige Wegwerfercounts erzeugen. Also ganz strikt. Alles andere ist Teufels Küche. So, nochmal kurz zusammenfassen. Was gibt es da überhaupt für Rollen? Also die AI-Admins sind wirklich die, die sozusagen das ganze System administrieren. Die dürfen sich typischerweise eben auch auf die AI-Edier-Server selber einlocken. Also wird eigentlich nochmal ein bisschen unterschieden zwischen AI-Admins und AI-Sys-Admins, aber im Wesentlichen ist es das. Also die dürfen halt praktisch alle Daten auch an manchen Regeln vorbei im Prinzip ändern, wenn sie irgendwas reparieren müssen. Kommt in der Regel nicht vor, dass sie was reparieren müssen. Die sollen aber sich aus dem täglichen Datenpflegegeschäft raushalten. Also ihr erinnert euch, vorhin habe ich gesagt, ich will keine supermächtigen Proxy-Rollen haben. Also keine So-Help-Desk-Rolle, die irgendwie alles darf und die dann aber auch die tägliche Arbeit macht. Ne, das sollen die gerade nicht tun. Das heißt, das Einzige, was die im täglichen, bei der täglichen Datenpflege macht, ist neue Zonenanlegen. Fertig. Und so ein bisschen natürlich überprüfen, ob alles in Ordnung ist. So, und dann gibt es die AI-Auditoren. Das ist halt die Auditorenrolle für Wirtschaftsprüfer, sonstige Auditoren, die in einem Unternehmen aufschlagen und irgendwie komplette Reports erstellen wollen. So, und dann gibt es eben für die tägliche Datenpflege die Zonenatmens, die dürfen eben schreiben, genau in den Zonen, für denen sie Zonenatmens sind. Die Zonenauditoren, die dürfen eben alles in Zonen lesen. Typischerweise können sich zum Beispiel auch Leute, also gerade wenn die Referenzen zwischen den Objektenzonen übergreifend sind, nehmen die Leute sich quasi wechselseitig als Zonenauditoren auf. Also quasi ein Deft-Teamleiter nimmt typischerweise die Obstleute als Auditoren in seiner eigenen Teamzone auf. Also die und eben die Obstleute ermöglichen zum Beispiel den Lesezugriff dem Teamleiter bei den Entwicklern. So, dass die auch Fehler finden können in den Beziehungen. So, dann gibt es noch eine Rolle Setup-Admin. Setup-Admin sind im Prinzip die, die quasi eigentlich ein Cluster erweitern können. Also die können im Prinzip innerhalb einer Service-Gruppe neue Hosts oder Services anlegen und die mit dem Passwort versehen. Die Zonen-Admin-Accounts, die sollen typischerweise eben gerade nicht. Also auch wieder so Security-Best-Practice. Die Zonen-Admin-Accounts sollen eben gerade nicht zum Beispiel für die Administration von Systemen verwendet werden. Das kann man natürlich zentral nicht durchsetzen in dem Sinne. Aber es gibt so ein paar Regeln, dass zum Beispiel eben die Zonen-Admin gerade eben nicht in irgendwelche Gruppen aufgenommen werden können, die zum Beispiel Lock-in-Rechter auf irgendwelchen Zielsystem haben. Also das ist sozusagen eine strikte Drennung, weil Zonen-Admins, die können halt innerhalb der Zone sehr viel. Also das ist schon auch eine relativ mächtige Rolle. Teilweise ja, aber ich meine, du kannst nicht verhindern, dass sich jemand irgendwie ganz mutwillig ins Knie schießt. Aber das können wir nachher im Detail besprechen. Okay, natürlich, die Benutzer können einfach quasi zur Datenschutzauskunft, können sie natürlich ihre eigenen Einträge lesen und auch in welchen Gruppen sie sind. Und natürlich können sie ihr eigenes Passwort setzen. Das müssen sie natürlich können. Okay, wer hat sich eigentlich schon mal mit Elder Observern rumgeschlagen von euch? Okay, also das da oben ist, glaube ich, relativ berühmt berüchtigt, wenn man das schon mal getan hat. Also gerade so Dinge wie Gruppenschämata. Verwend ich jetzt RFC 2307 oder RFC 2307 bis. Das sind so verschiedene Gruppenschämata. Ja, mein Ziel war all diesen ganzen Wus, den leutningen Prinzip abzunehmen und einfach zu sagen, hey, was auch immer da draußen irgendeinen älter Kleinen haben will, ich liefe ihn aus. Das bedeutet, dass ich zwar proprietäre Schämata habe, die beginnen alle mit den beiden Buchstaben AE, also sämtlicher Objektlassen, Attributtypen, die proprietär sind innerhalb des Systems, beginnen mit diesen Prefix. Aber diese ganzen Objektlassen und Attributtypen werden in den kleinen Konfigurationen eben gerade nicht verwendet. Also das heißt, nach außen ist das Ding praktisch ein Standardeld ab. Egal welches Gruppenschema, die Leute haben wollen, durch so eine hybride Objektklasse kann ich eben sozusagen wohl das Memberattribut als auch das Member UID Attribut sozusagen ausliefern und konstraint sorgen dafür, dass die Wertemengen in sich konsistent sind. Also wer hat sich damit schon rumgeschlagen hier? Genau, also das kann man eigentlich ganz einfach lösen mit so hybriden Objektklassen. Also das ist einfach Mehrfachvererbung, so von den passenden Basisklassen. So und auch ein beliebtes Problem ist, dass die Standardobjektklasse Group of Names, keine leeren Klassen, das kann man eben auch lösen und es ist da drin auch gelöst. So, dann nochmal ganz wichtig, um überhaupt eine vernünftige, sichere Autorisierung machen zu können, müssen die jeweiligen, beteiligten Entitäten wirklich eindeutige IDs bekommen. Das sieht man ja noch relativ schnell ein bei Benutzerkennungen oder eben auch bei POSIX UID und POSIX GID von Gruppen und so weiter, aber es gibt eigentlich noch ein paar andere interessante Sachen. Nämlich ist es ziemlich praktisch, Uniconstraints auch durchzusetzen, auf zum Beispiel Namen von Gruppen natürlich, weil die können ja immer global auch referenziert werden, also einmal natürlich die Namen, aber zum Beispiel auch auf den FQDNs von Hosts. So, wir erinnern uns, eben Host-Objekte, sozusagen, werden wirklich richtig eingetragen und bekommen ein Passwort. Deswegen klebt an diesen Host-Objekten eben auch wieder ein Hostname, der eindeutig ist und dann kann ich aber auch noch weiter Netzwerk-Device-Einträge anlegen und damit kann man ziemlich coole Sachen machen, weil wenn ich zum Beispiel sage, ich hinterlege hier ein Triple von FQDN und MAC-Adresse, jemand fängt einfach an, server zu administrieren, sagt, der hat jetzt die und die IP-Adresse, mit dem und dem DNS-Namen. Wenn er der erste ist, dann gehört ihm ab dann autoritativ dieser DNS-Name. Jetzt vergleicht das kurz mit, ihr pflegt einfach im DNS, also das DNS setzt eben keinerlei Uniconstraints durch, aber wenn ihr im Prinzip hier die Netzwerk-Daten einpflegt, dann habt ihr sogar von Systemen und ihren Netzwerk-Daten, zum Beispiel wie eine MAC-Adresse, einen eindeutigen Bezug über die ganze Referenzenkette, wir gehen noch mal kurz noch zurück, also hier, wenn hier eine MAC-Adresse drin steht, kann ich praktisch über diese Referenzenkette festlegen, welcher User darf sich zum Beispiel auf, bei zum Beispiel ein Network-Access-Kontroll mit 802.1x da eigentlich, sozusagen authentifizieren. Oder auch so ein Thema, also eines meiner Themen ist eben auch PKI, und dann sagen die Leute immer, ja, Michael, wir brauchen jetzt ein PKI, wir wollen Server-Zertifikate ausstellen, dann sage ich, ja, okay, wie legt ihr denn fest, wer für welchen DNS-Namen ein Zertifikat beantragen darf? Und dann geht es los, ja, dann geht es los. Also, ja, also, hm, und, naja, aber dann kann man auch irgendwie sagen, ja, der, der den DNS-Eintrag macht, aber die wollen das dann meistens gar nicht sein, ja, also, oder die sind auch nicht diejenigen, die zum Beispiel den Server administrieren und da eigentlich Schlüsselmaterial tauschen können, ja und so. Und deswegen braucht man eigentlich Berechtigung, ja, in so einer PKI. Und dann ist es irgendwie ziemlich cool, wenn man zum Beispiel sagen kann, ja, okay, ich kenne hier den Host-Namen, ich kenne den FQ.DN, also habe ich hier die Referenz-Kette über hier sozusagen das spezielle, spezielle Attribut AI Setup Groups, das sind genau eben diese Setup Admins, dann kann ich sagen, die Rolle Setup Admins in dieser Service Group darf natürlich in einer PKI dann ein Zertifikat für diesen Namen ausgestellt bekommen, weil das ist typischerweise derjenige, der den Server eben administriert. So, das sind dann so Nebeneffekte, also neben dem eigentlichen, der eigentlichen Aufgabe, ja, einen Identity and Access Management bereitzustellen, ja, kann man eben sagen, okay, wenn ich da ordentlich gepflegte Daten drin habe, dann kann ich auch noch ein paar andere Dinge damit tun und alles immer im Rahmen dieser delegierten Datenpflege. Okay, wie wird das Ganze installiert? Also es gibt eben freies Software-Projekt auf einer Webseite und die Installation erfolgt eben über eine Enzybil-Rolle, also gibt es eben Enzybil-Rolle und Enzybil-Playbooks, ja, und ihr klont euch das im Prinzip einmal die Rolle und einmal im Prinzip schon so ein Beispiel Zeitverzeichnis. Hier schreibt dann da, wer kennt sich somit Enzybil aus? Also knapp die Hälfte. Im Prinzip gibt es in Enzybil so ein Inventory, ja, da sagt man einfach, es gibt diese und jene Host-Gruppen, die haben diese und jene FQDNs, ja, und letzten Endes parametrisiert man über dieses Ganze Inventory schon die komplette Installation, das heißt, man muss dann natürlich noch Server-Zertifikate ausstellen und so weiter, aber letzten Endes, wenn man das Ding hochzieht, kriegt man quasi so eine komplett vermaschte Replikationstobologie, ja, also das macht alles eine Enzybil-Rolle. Das ist im Prinzip, das sind die Defaults dieser Enzybil-Rollen, das sollte man sich echt durchlesen, also die Kommentare, die da dran stehen, ja, weil damit man so ein bisschen versteht, was man da parametrisieren kann. Das Schöne an dem Enzybil ist tatsächlich, ja, dass man, wenn man die Enzybil-Rolle, das Schöne an dem Enzybil ist tatsächlich, ja, dass man, also die Rollen funktionieren relativ gut jetzt, also das war natürlich auch eine längere Historie, weil ich habe damit auch Enzybil gelernt quasi, ja, aber inzwischen funktioniert das relativ gut, also das heißt, man verbaselt irgendwas, man macht irgendwas kaputt, ja, und solange man noch irgendwie an die Maschinen rankommt, ja, korrigiert sozusagen das Enzybil dann die Dinge wieder hin, ja, und das funktioniert relativ gut. So, ihr werdet eventuell schon gemerkt haben, dass mir Sicherheitsaspekte relativ wichtig sind, deswegen gibt es noch so ein paar andere Goodies, und zwar versuche ich wirklich auch, also einmal natürlich soll alles eben sichere Default-Werte haben, ja, also das heißt, wenn man das Ding irgendwie hochzieht, dann ist da nicht irgendwie irgendwas offen, was nicht offen sein soll, ja, oder irgendwie so sehr breit aufgemacht oder so was, ja, irgendwie, das führt dazu, dass man tatsächlich irgendwie IP-Netze irgendwo eintragen muss in den Enzybil-Variablen, ja, um praktisch irgendwie zum Beispiel auf die Web-Applikationen eben Zugriff zu bekommen. Also man muss sich bewusst entscheiden, will ich damit sagen, ja, und natürlich ist das System mit sich selbst integriert, eben in dieser speziellen Zone AE, ferner sind diese ganzen Prozesse auch immer separiert, das heißt, die laufen wirklich als separate System D-Units, als separate Service Accounts quasi, ja, und kommunizieren miteinander über Unix Domain Sockets typischerweise, ja. Das kommunizieren über Unix Domain Sockets, also ich weiß nicht, wer das kennt, also LDAP über IPC, also über Unix Domain Sockets zum Beispiel, da kann man zum Beispiel sagen, der Service Account A greift auf den LDAP-Server zu und der LDAP-Server mapt den dann automatisch auf intern, auf eine LDAP-Entität quasi, ja, ohne dass der sich im Prinzip mit dem Passwort authentifizieren muss. Das geht über die sogenannten Unix Peer Credentials, vielleicht kennt es auch jemand von MySQL und Postgresql-Datenbanken, ja, also praktisch man erlaubt einem Prozess, einfach weil er eben unter einem bestimmten Linux-Benutzer läuft, ja, erlaubt man zum Beispiel den Zugriff auf Datenbanken und das geht eben bei Open LDAP ganz genauso. So, dann gibt es eben, also System D, da haben wir alle so ein bisschen gespaltenes Verhältnis dazu, ich auch, ja, aber es gibt tatsächlich ein paar, auch gute Features von System D, ja. Es gibt so verschiedene Optionen, wie System D im Prinzip ein Prozess schon wieder einsperren kann, zum Beispiel in Namespaces und mit Siegrubs versehen und so weiter, also gibt es auch einen separaten Vortrag von mir dazu, also ohne, dass ich mich da als Experten bezeichnen würde, aber es ist ziemlich cool mal in der Mainpage nachzugucken, nach allem, was zum Beispiel mit Protect anfängt, ja, das ist schon mal sehr gut, ja. Dann, ferner, wenn auf dem System ein App-Armer initialisiert ist und läuft, ja, dann installieren die Enzybel-Rollen automatisch auch App-Armerprofile für alle Dienste, ja, was übrigens erstaunlich wenig Arbeit war, also ich hätte irgendwie erwartet, dass es viel mehr ist, ja, irgendwie, aber auf jeden Fall sind die praktisch alle confined, also alle Dienste, die ihr vorhin in einem Architekturshowbild gesehen haben, haben individuelle App-Armerprofile, ja, und dann gibt es halt im Prinzip auch noch zwei Faktor-Otentisierung basierend auf Ubiqui, also eigentlich Standard-OFH-OTP-Verfahren, ja, irgendwie, das was zum, und die Ubiquis werden eben genau auf dieses Verfahren programmiert, das heißt, das ist aber auch wieder ein separator Vortrag, das heißt, ihr könnt direkt das Elder-Bind zusätzlich mit einem zweiten Faktor versehen. Das funktioniert auch ganz, also recht stabil. So, ich glaube, ich muss mich ein bisschen beeilen. Ein Anwendungsfall, der da auch noch aufgetaucht war, war sowas wie ein SSH-Proxy, das heißt, Leute kommen um die Äckern und sagen, ja, das ist eigentlich schlecht, dass die Leute immer irgendwie direkt von ihrer Admin-Workstation auf bestimmte Systeme bekommen. Typischerweise Systeme, irgendwelche Liegesie-Systeme, die man überhaupt nicht an irgendein User-Management anflanschen kann. Also es gibt zum Beispiel so Sachen wie Hardware-Security-Modules, NTP-Blinds, irgendwelche ominösen, proprietären Geräte, die so in den 19-Zoll-Schrank geschraubt werden und dann so mäßig gut administriert werden. Ah, hast du noch das Passwort von dem? Also typischerweise werden auf solchen System eben auch die Passwerte nie getauscht. Das heißt, gerade wenn sich die personelle Zusammensetzung ändert, irgendwie sind solche Systeme halt immer ein Risiko. Das heißt, was gefordert war oder, na gut, das war dann auch mein eigener Ehrgeiz, war im Prinzip ein autorisierenden SSH-Proxy zu bauen. Das heißt, wenn ich oben in dem Aedir im Prinzip die Relation schon drin habe über diese ganzen Referentenkette, die Relation dieser User darf auf dieses Zielsystem zugreifen, dann möchte ich die auch benutzen. Das heißt, ich pfleg hier oben die Daten einfach so, als wäre dieses Zielsystem mit Aedir tatsächlich integriert. Und da ich dann aber sozusagen nicht direkt hier das durchsetzen kann, schalte ich eben SSH-Proxy davor. Das heißt, ich lasse hier an der Stelle Firewall-Technisch oder eben über IP-Zugriffbeschränkungen hier nur noch SSH-Zugriffe von eben diesen SSH-Proxy zu. Und dann geht das Spiel eben so, der Nutzer möchte sich mit irgendeiner Liegesie-Kennung auf dieses Ziel anmelten. Also benutzt er, macht er praktisch eine SSH-Verbindung hier zu dem Proxy auf, mit der Proxy-Komand-Direktive. Und bei dieser Anmeldung hier benutzt er im Prinzip seine Aedir-User-ID. Das heißt, das ist genau die Kennung, die er benutzen würde, wenn das Zielsystem mit Aedir integriert wäre. So, und dann gibt es hier einfach ein kleines Wrapper-Skripten, das ist total simpel. Und das fragt hier so einen kleinen Check-Deam, und dieser Check-Deam wertet genau diese Relation aus. Da kommt jetzt dieser Nutzer mit dieser Kennung, dürfte der denn auf dieses System zugreifen? So, und wenn da eben okay zurückkommt, dann schaltet er einfach mit Net-Ketten-TCP-Relay durch, ganz simpel, ganz low-Tech. Proxy-Komand, das ist so eine kleine Direktive. Also guck einfach in der SSH-Unterstrich-Config-Manpage nach, nach dieser Direktive, das Proxy-Komand. So, das ist irgendwie auch cool, und insbesondere bei der Einführung von der Zwei-Faktor-Authentisierung, dann war es dann schon so, dass man einfach gesagt hat, okay, jetzt müssen alle hier rüber. Also egal, ob das Ding dahinten Liegesieh oder ein normales System ist. Und dann macht man hier vorne eben praktisch die Zwei-Faktor-Authentisierung. Und dann können die Leute durch das Gateway, wie gehabt, zum Beispiel mit Ansible oder irgendwelchen anderen Bulk-Administration-Tools, ohne sich immer wieder neu authentifizieren zu müssen mit der Zwei-Faktor-Authentisierung. So, haben wir noch Zeit? Wollt ihr noch? Okay, also, das ganze System ist relativ CPU anstrengend, weil die Clients sind mit Absicht dumm konfiguriert. Das heißt, in den Clients ist nicht einprogrammiert. Ja, jetzt filter aber den Benutzer-Datenbestand wirklich genau nach den Gruppen oder sonst irgendwas, sondern in SQL-Sprech würde man sagen, da steht drin, from table select stern. Also, gib mir mal alles, was ich sehen darf. Bedeutet natürlich, bei all diesen Abgleichzugriffen, also wie gesagt, der eine Kunde hat damit irgendwie 15.000 Maschinen, passierte im Prinzip ständig das Auswerten von sehr aufwendigen ACLs. So, und das war eine der Gründe, also das war jetzt mein letztjähriger Beitrag zum Umweltschutz, sozusagen den Stromverbrauch, da haben wir massiv zu drosseln, indem ich eben einen eigenen NSS-Pam-Demon geschrieben habe, der eben die Daten kennt, also den muss man eben nicht konfigurieren, sondern der findet selber raus, was Sache ist für sein System. Das geht eben mit generischen System eben nicht. Also, man müsste zum Beispiel, kennt jemand SSSD und so? Also, das ist eben so die Standardkomponente inzwischen von RedHead vornehmlich entwickelt, um eben NSS-Dienste und Pam-Dienste lokal anzubieten. Und die haben dann auch wieder so Backend-Mechanismen, also das heißt, man könnte auch theoretisch einen SSSD-Backend schreiben, um praktisch irgendwie solche Filterungen selber zu machen. Also, die haben zum Beispiel auch für E3-EPA, haben sie auch praktisch dieses H-Backend, wo sie auch wieder ihre eigenen Access Control Rules auswerten. So, aber bevor ich irgendwie einen SSSD-Backend schreibe und das Ganze dann nur in der Linux läuft, habe ich mir im Prinzip den Python-Code angeguckt, den der Autor des NSS-Pam-L-Dup-D freundlicherweise mal geschrieben hat. Der hat nämlich seinen NSS-Pam-L-Dup-D nochmal komplett in Python geschrieben gehabt. So, und das habe ich dann sozusagen als Vorlage genommen, irgendwie so ein Ding selber zu bauen. Und das ist eigentlich auch, das ist viel schlanker und macht eben genau das sozusagen und kann auch den ganzen Prüfungsquatsch und so, den alle anderen machen müssen, weil sie eben mit beliebigen Rots von Daten zurechtkommen müssen, einfach weglassen, weil die Daten, die AED liefert, sind halt durch diese ganzen Constraints einfach perfekt. Also, man kann da sozusagen nicht einfach irgendwelchen Rots rein pflegen, sondern man läuft dann da immer irgendwie auf irgendeinen Constraint drauf, wenn man halt eine nicht existierende Gruppe oder nicht mehr aktive Gruppe referenziert oder sowas. So, das eine ist im Prinzip einmal CPU-Sparen, dadurch, dass man einfach weiß, wie man suchen muss. Also, ich kann dann einfach sagen, ja, okay, ich weiß, sichtbar sind bei mir eben die Gruppen so und so. Also, kann ich mir im Prinzip die User auch genau gemäß dieser Gruppen eben filtern. Und das nächste Thema, was eben auch sehr wichtig ist, wenn man zum Beispiel Server automatisiert hochfahren will, also Server automatisiert im großen Stil, dutzendweise sozusagen installieren und konfigurieren will, dann ist natürlich dieser Schritt, jedem Server ein eigenes Passwort zu geben, für die Atmens relativ anstrengend. Also, das mögen die jetzt nicht unbedingt. Deswegen gibt es im Prinzip bei dem AI Hostee auch so ein Enrollment-Prozess, wo ich im Prinzip ein Pseudo-SSH-Login mache mit so einem generischen User und dann ballert ich dem das Host Passwort drauf, der checkt das gegen das eigene Host Passwort und schreibt es dann in die Konfig. Ja, das ist das letzte Ende so. Also, erstmal ist es sozusagen einfach, der bindet sich als der, oder als ein Host zum Beispiel, ja, dann guckt er in seinen Servicegruppen Eintrag, guckt sich genau hier eben an, welche sind eigentlich visible und dann macht er praktisch ein Member-off Filter auf die User, dann guckt er in seinen Servicegruppen Eintrag, dann guckt er in seinen Servicegruppen Eintrag, dann guckt er in seinen Servicegruppen Eintrag, dann macht er praktisch ein Member-off Filter auf die User-Account sozusagen mit der Vereinigungsmenge dieser Gruppen. Ach so, also er macht eine Rückfrage des aktuellen Statusweines? Nein, der meldet sich erst mal an, dann sagt er, wer bin ich denn? Ja, sozusagen, und welcher Servicegruppe bin ich? Nein, das ist jetzt mal unabhängig davon, der casht auch, aber einfach die Art und Weise, wie der herausfindet, sozusagen, welche Benutzer und welche Gruppen sind denn bei mir sichtbar? Das macht er einfach durch Abfragen. Und ich muss ihn aber nicht konfigurieren, weil das Ding halt die Daten kennt. Ja, das heißt, das Einzige, was ich konfigurieren muss, ist eben hier einfach nur Bein-DN und Passwort, einfach Polling, Low-Tech, alle fünf Minuten oder Refresh-Time. Das ist genau das, ja, also deswegen muss man es sehr effizient machen. So, und das Weiterein hat das Ding so ein paar Eigenschaften, zum Beispiel wirklich ein kleinzeitiges Low-Balancing zu machen, basierend auf dem Hash von einem eigenen Hausnamen, und dann zum Beispiel eben auch Elder-Zugriffe immer nicht genau Zeit getaktet zu machen, sondern immer mit so einem Jitter, also irgendwie zu sagen, aha, ich habe eine Refresh-Time, aber dann habe ich ja im Prinzip noch irgendwie zwei, drei Sekunden Jitter und dann laufen die auch auseinander, also selbst wenn der, selbst wenn der Atmen vorher mit Cluster SSH irgendwie schön synchron, irgendwie den Dienst überall durchgestartet hat, ja, dann ist es nur am Anfang so, ja, dann laufen die hinterher sozusagen auch wieder zeitlich auseinander. Dann hat das auch so ein paar bessere Features, wie man zum Beispiel viele Elder-Replicken angeben kann, wie der dann wirklich Failover macht und so weiter und so fort, also so ein paar Sachen, die mir bei SSD halt fehlten, wenn man halt viele Systeme einfach hat und viele Replicken. So, und insbesondere war ich dann auch irgendwie ein bisschen müde, zum Beispiel die SSD-Leute nach einem bestimmten Feature zu fragen und deswegen habe ich es dann auch einfach eingebaut. Okay, also irgendwie bessere Performance und so weiter, kleinzeitiges Low-Bendings, hier steht da alles Enrollment Automation mit diesen Pseudo SSH-Lock in und naja, es hat einfach von allem weniger, ja, weil es einfach weiß, was es sozusagen an Daten erwartet, ja. Also insbesondere hat man jetzt auch keine riesen Abhängigkeiten mehr drauf als solche Samba-Libraries wie der SSD oder sowas, ja. So, und die Architektur ist aber ähnlich, ja. Es gibt im Prinzip so NSS und PEM Frontend-Module, ja. Da benutze ich einfach genau die von dem NSS PEM LDAP-D, ja. Die werden einfach mit einem anderen Namen kompiliert, da gibt es freundlicherweise eine Configure-Option, so dass es da auch wieder nicht irgendwie eine Kollision gibt mit irgendwelchen anderen Installationen. Dann hat das Ding einfach intern so ein Cash, ja. Also eigentlich im Prinzip in Memory Dictionary die SSD, die Group Map und auch, wenn man möchte, die Host Map. Dann werden sudoas regeln, werden eben nicht hier aus dem Cash ausgeliefert, sondern da wird tatsächlich eine sudoas Datei im Prinzip generiert, exportiert, ja. Und dann über einen privilegierten Prozess eben ins Verzeichnis EDC sudoasd geschrieben, ja. Also alles ziemlich low-tech, also auch mit Absicht, ja. So, dann gibt es noch so ein paar spezifische Features, ja. Genauso wie FreeEpa ist der Default, dass im Prinzip jeder User Account und jede Gruppe jeweils eine eigene GID bekommen, ja. Also das heißt, die primären GIDs, der Benutzer, sind alle immer unique, ja. Aber für diese GID gibt es im Prinzip keinen separaten Gruppeneintrag in den Directory, ja. FreeEpa macht das zum Beispiel anders, ja. Also die haben so ein Compat Tree, ja, und synchronisieren da im Prinzip so wirklich Gruppenobjekte in diesen Compat Tree, um das abzubilden, ja. Und das brauchen wir aber eigentlich nicht, ja. Und was ich aber hier einfach mache, dass ich für jede primäre GID eines Benutzereintrags auch nochmal in der Group Map einfach in meinem Dictionary ein Objekt anlege, ja. Und dann gibt es eben auch nochmal Roll Groups für genau diese Sachen, die Setup Admins, ja. Und Login Groups und so, die werden im Prinzip auch nochmal auf so virtuelle Gruppen in der Group Map abgebildet, ja. Ich kann das mal kurz zeigen. Kann ich das zeigen? So, das ist jetzt mal, ja. Also hier sieht man so die virtuellen Gruppen von den einzelnen User GIDs, ja. Das sind im Prinzip die virtuellen Gruppen. Und dann sieht man, ja, wo habe ich das? Ja, machen wir mal so. Ja, hier, genau. Und da sieht man jetzt zum Beispiel die Rollengruppen, ja. Das sind im Prinzip die Vereinigungsmengen jeweils der referenzierten Gruppen, zum Beispiel von den Setup Admins, ja. Und da kann ich dann auch wieder was machen, wenn ich jetzt zum Beispiel sage, oh, ich habe sowieso nur eine Sudo-Regel, die einfach SU-Root erlaubt, ja, für eine bestimmte Gruppe. Dann kann ich auch sagen, na ja, dann mache ich einfach mir hier eine lokale Konfiguration, die einfach SU-Minus erlaubt für genau diese Gruppe, ja. Das ist derselbe Effekt. Und ich habe nicht dieses Sudo-Monster an der Backe, ja. Also hat immer alles Vor- und Nachteile, ja. Aber solche Sachen kann man dann eben abbilden. Oder eben auch genau diese, wer darf eigentlich Logs lesen? Welche Gruppen dürfen Logs lesen, ja? Das ist auch typischerweise machen die Leute so Sudo-Regeln so, um auf Valog, Messages oder sonst irgendwas zugreifen zu können. Irgendeine ganz schlechte Idee. Also dazu sind eigentlich der Teil Ownership und Permissions da, ja, irgendwie. Und damit kann man das dann relativ leicht machen. So, Authorized Keys werden auch runter synchronisiert, ja. Und dann gibt es eben noch sowas wie ein Elder Possession Tracking Control, ja. Da kann ich sozusagen hinterher sogar in den Elder Blocks lesen. Von welcher IP-Adresse kam zum Beispiel der SSH-Klein, wenn er ein Sudo gemacht hat und dann den Bind-Request für die Passport-Prüfung reingesendet hat, ja. Das ist auch sehr schön. Das war so ein Feature-Request an SSD, aber Sie haben nicht verstanden, warum ich es wollte. Also das Einzige, was sich in dem Ticket ändert, ist im Prinzip seit mehreren Jahren, dass Sie immer den Milestone hochsetzen. Ja, okay. Also, ja, also Sicherheit ist schon möglich. Es ist natürlich anstrengend, es ist Arbeit, ja. In der Ecke habe ich euch versucht, die Arbeit abzunehmen, falls ihr euch dafür interessiert. Man braucht am Anfang, am Anfang ist es relativ erklärungsbedürftig, ja. Ein Kunde hat irgendwie so gemeint, der eine, der das betreut hat, gemeint, ah, Michael, seitdem du weg bist und ich muss es jetzt anderen erklären, habe ich es viel besser verstanden, ja, irgendwie. Und es ist echt genial, ja. Und, na ja gut, also man muss sich so ein bisschen mit befassen, ja. Genau, und man braucht natürlich, wenn man so ein Projekt wirklich einführen will, so ein bisschen das Management, um auch budgetfrei zu schalten und die Leute halt irgendwie dazu zu motivieren, es auch wirklich zu tun. Ja. Und für mich ist halt auch etwas, was ich immer wieder so erlebe, also ich entwickle das System ja noch weiter, ja. Alle Ideen, die ich so habe, ja, da muss ich immer sehr stark darauf aufpassen, also es ist jetzt, dass ich quasi ursprünglich mal gemachte Versprechen eben hinterher nicht durch eine Änderung wieder breche, ja. Also das heißt, diese Paradigmen, die ich ganz am Anfang hingeschrieben habe, ja, so. Das ist, das ist im Prinzip der Filter, den jede Idee durchlaufen muss auf eine sehr harte Art und Weise, ja, bevor ich dann irgendetwas tue, ja, so. Und, naja, von 20 Ideen macht es vielleicht eine, ja, so, ja, so. Okay, da gibt es das alles, ja, irgendwie. Und da gibt es auch einen, da gibt es auch einen Online-Demo, da könnt ihr direkt drin rumklicken, das ist eine kleine VM, also ein einzelner Provider. Ja, und unten ist das Projekt, was die 2-Faktor-Otentisierung da direkt in Elder implementiert. Genau, und dann sind wir jetzt so bei Fragen und Antworten angekommen. Okay, wenn wir uns dann momentiert mit planen, wer soll was können? Achso, man macht hier... Okay, man macht hier für so ein System, wenn man es beim Kunden oder im Vorort installiert, auch eine Planung, wer soll was können? Man setzt Regeln auf, man plant Gruppen und so weiter. Das heißt, man setzt das Ganze erstmal auf Papier oder von mir aus Textdokument. Kann das System in seiner Konfiguration nachher im Einsatz von diesem Entwurf abweichen? Naja, also, ich habe ja das Passwort Agil benutzt, ja. Das heißt, also du planst nicht dein ganzes Unternehmen durch, ja. Also speziell, wenn du jetzt halt verschiedene Teams hast und verschiedene Projekte ist, es lebt ja immer irgendwas, ja. Es werden auch Zuständigkeiten hin und her verschoben und sonst irgendwas, ja. Das heißt, das heißt, die Veränderung ist eigentlich der Regelbetrieb, ja. Also, das heißt, es ist tatsächlich, also deswegen auch dieses Passwort Agil, ja. Also du fängst eigentlich an, Daten zu pflegen, du wirst garantierte Dinge falsch machen. Das heißt, du musst irgendwie Sachen umstrukturieren. Das ist spätestens bei der nächsten Umorganisation, die auch in Unternehmen der Regelfall ist, ja. Also musst du anfangen, Dinge umzustrukturieren, ja. Ich will auch Folgendes hinaus. Die Planung muss ja eigentlich in mindestens zwei Ebenen passieren, ja. Man stellt Mitteregeln auf und dann geht es ins Detail, ja, auf der zweiten Ebene. Und kann man irgendwie möglichst automatisch prüfen, dass der aktuelle Zustand des Systems noch den Metaregeln konformiert. Also, das ist jetzt... Wenn man die Metaregeln auch irgendwie in die Konfiguration schreiben könnte und dann irgendwann sagen, System, sag mir, ist die aktuelle Konfiguration noch konsistent mit den Metaregeln? Also, dann müssen wir jetzt erstmal festlegen, in was formuliert man diese Metaregeln auf welcher Ebene und so weiter. Also, theoretisch ist ja immer alles möglich, ja. Aber ich meine, also, wenn du irgendwas machen... Was ich meine? Ja, klar, aber ich meine, das bedeutet ja eigentlich, wenn deine Metaregeln schon so formal sind, ja, dass du daraus im Prinzip die Berechtigungen ableiten kannst, dann sind es die Berechtigungen. Also, ich möchte nicht, dass zum Beispiel durch die Urlaubsvertretung des Obersten Atmens plötzlich der Geschäftsführer Sachen machen darf, die er nicht soll. Nein, das passiert ja sowieso nicht, ja. Also, hey, noch mal ganz hart, ja. Also, entweder du hast die Chance, also entweder du hast das Recht, ein Objekt und seine Beziehungen zu ändern oder nicht. Also, nur weil jetzt jemand in Urlaub ist, bekommt nicht irgendwie automatisch irgendjemand irgendeinen Recht. Nein, nein, nein. Aber ich sage mal Urlaubsvertretung, dann macht ihr unter Umständen Sachen anders, als ich die gemacht hätte, ja. Dann sagt zum Beispiel der Geschäftsführer, ich muss jetzt ganz dringend dieses Dokument so und so behandeln, ja. Ja, also. Und die Urlaubsvertretung sagt dann, ja, na gut. Ja, und man kommt dann aus dem Urlaub zurück und die Welt geht runter. Also, also erstens gibt es einen Access-Lock-Datenmang, das heißt, es wird sehr detailliert jede Änderung mitgeschrieben, also auch recherchierbar. Also, du kannst die direkt an, ich kann das mal kurz zeigen. Ja, das ist nachher beim Entlassungsgespräch sehr wertvoll. Ja, aber natürlich auch, ich meine, ob jemand entlassen wird, es steht nochmal auf einem anderen Blatt. Also, hier unten kannst du zum Beispiel einfach draufklicken, ja. Und da werden im Prinzip in der Access-Lock-Datenmang sämtliche Schreibzugriffe auf einen Eintrag mitprotokolliert, und zwar sehr, sehr detailliert, ja. Urlaub sehr viel zu lesen. Also, du würdest ja im Prinzip jemanden, den du gar nicht geschult hast, auf keinen Fall irgendwie zu einem AI Atmen machen oder auch nicht zu einem Zonenatmen, ja. Das heißt, in der Regel bereiten die Leute ihren Urlaub ja quasi vor. Also, die wissen ja im Prinzip, also die Praxis zeigt einfach, ja. Das zwar ein Teamleiter, der zum Beispiel auch echt fachlich Ahnung hat, was Sache ist, ja, dass der aber das trotzdem nicht alleine macht, ja. Weil der kann ja immer krankgeschrieben sein. Das sind nicht nur die Urlaubs-Situationen, sondern er kann auch einfach krank sein oder noch schlimmer, ja. So, das heißt, die Vertretung, also, wenn du keine ordentliche Vertretung vorgesehen hast, dann wirst du so deine Orga kaputt, würde ich jetzt argumentieren. Ja, annehmen, dass die Urlaubs-Vertretung weiß, was sie tut, ja. Dass der aber eben nur in diesem meinem Urlaub da ist und deswegen auch im Haus vielleicht nicht die Hausmacht hat, einem unsinnigen Ansinnen des Geschäftsführers zu widerstehen. Ja, aber nochmal, Technik löst keine Orga-Probleme. Richtig, ich würde das auch... Also, das würde ich auch nie versprechen, ja. Also, ich meine, es ist bloß so, dass allen halt, die das benutzen, klar ist, ja, dass dieses Setzen von Referenzen, ja, dass das halt Berechtigung setzt auch, ja. Das ist den Leuten schon klar. Also, die Leute, die du zu einem Zonenatmen machst, den muss das schon klar sein, ja. Und es ist auch so, dass quasi meine Ansage an die Leute ist auch immer, Leute, die zonenatmen sind, müssen im Prinzip alle Objekte in ihren Zonen fachlich verstehen. Und wenn es irgendwelche gibt, die sie nicht fachlich verstehen, dann ist der Zonenzuschnitt falsch, ja. Also, das ist so die Orga-Ansage, ja. Benutzt bitte die technischen Mittel wirklich so, ja, dass ihr das so weit aufsplittet, ja. Dass die Leute wirklich in ihren Bereichen für diese Zuständig sind, immer wissen, was die Objekte bedeuten. Also, auch insbesondere, was für Rechte hängen zum Beispiel in der Usergruppe, ja. Das ist ja eigentlich hier spannende Thema, ja. Also, von wegen, hu, wir haben da diese Usergruppe und so und die, und wir wissen aber nicht mehr genau, wo die überall verrechnet ist, ja. Das darf eben genau nicht passieren, ja. Hi, hallo. Zum Abschluss noch ein paar Anfängerfragen. Kannst du mir die Folie mit der roten Linie noch mal kurz zeigen? Ich glaube, da hat es, du vorhin gesagt, dass da dein Aedir-Consumer einen Pull-Request stellt. Genau. Wäre nicht ein Push vom Aedir-Provider sinnvoller? Das hat vor und nach Teile. Also, erst mal die Standardkonfiguration von OpenLDAP ist eben Pull-Replication. Also, das Sync-Repple-Protokoll, also, das ist eigentlich nur eine spezielle LDAP-Suche. Ja, also mit so ein paar Protokoll-Erweiterungen, so Kontrolls dran und irgendwelchen auch so Intermediate-Messages, die dann so als Response kommen, oder Intermediate-Response, die da kommen können, ja. Der Standard ist, dass man hier praktisch tatsächlich eine Suche macht, ja. Du kannst das umkonfigurieren, also, du kannst wirklich Dinge umkonfigurieren auf eine Push-Replication. Dann machst du praktisch so einen lokalen Reverse-Proxy, ja, der quasi ein Sync-Repple-Consumer ist und der ist dann quasi eine LDAP-Proxy auf das Target, ja. Aber ich mache das deswegen nicht, weil das wird dann relativ anstrengend. Heute habe ich das Bild eingefügt, das kommt mir jetzt gerade gelegen. Wenn du eine Push-Replication machst, musst du tatsächlich Replikationstobologie auf den Providern umbauen, ja. So, und das wird dann relativ anstrengend. Also, einfach mal so mehrere Konsumern auch dahin zustellen, weil du jetzt irgendwie mehr Last hast oder weil du das irgendwie noch auf andere Rechenzentrum vertraten musst oder so, das wird dann relativ anstrengend. Theoretisch möglich, aber ich habe es bewusst nicht gemacht. Okay, danke, zweite Frage. Zweite Frage, kann ich das in ein bestehendes IAM-System einbinden? Also, kann ich mich zwischen reinsetzen oder muss ich es neu aufbauen, wenn ich jetzt sage, ich möchte... Also, AIDIL selbst ist quasi, das baust du neu auf, ja. Und jetzt ist ja die Frage, wie befüllst du es, ja. Und wenn du halt sagst, klar, du hast jetzt irgendwie so eine Identity-Management, das schiebt schon irgendwelche Daten von links nach rechts, ja. Dann kannst du das theoretisch machen. Eine sinnvolle Sache wäre halt, insbesondere Personendaten zu synchronisieren, ja. Also, es muss man sich halt genau angucken, wo kriege ich eigentlich Personeneinträge, ja, ja. So, wenn du aber, jetzt muss man ein bisschen hingucken, ja. Wenn zum Beispiel in einem Unternehmen der Anspruch ist, dass das zentrale Identity-Management alles abbildet, ja. Also sozusagen, man guckt in das zentrale Identity-Management und sieht dann alle Beziehungen, was darf denn jemand, ja. Das ist ja genau immer die Anforderung eines Auditors, zum Beispiel, ja. Dann müsstest du theoretisch auch wieder alle diese, diese ganzen Beziehungen mit abbilden, ja. Also insbesondere müsstest du auch hier wieder dieses mehrere Accounts pro Person und so abbilden, ja. Und da kommt es dann immer darauf an, was verwendest du für ein Produkt? Kann das das überhaupt? Und so weiter, ja, also. Es wird schwierig. Super. Letzte Anfängerfrage. Was mache ich denn, wenn ich ein Microsoft-AD irgendwo in meinem Unternehmen rumstehen habe? Naja, tatsächlich, also der eine Kunde, der bespaßt damit tatsächlich auch das AD. Und das ist eben genau dieser eine Fall, wo ich eben auch eine Passwort-Synchronisation implementiert habe. Also da ist es im Prinzip so. Die AD-Domäne ist quasi einfach eine Servicegruppe, also um das jetzt mal in das Datenmodell zu packen, ja. Das heißt, da wird dann auch wieder gesagt, also mit diesen Beziehungen wird dann einfach wieder gesagt, welche Benutzergruppen und welche Benutzer sollen eigentlich in die AD-Domäne synchronisiert werden, ja. Und dann werden die da erstmal runtersynchronisiert. Und dann wird im Prinzip, wenn der Benutzer über das Web-Interface seinen Passwort setzt, ja. Gibt es dann quasi in den Open-Eld-Observer eingeklinkt, etwas, was die Passwort Modifier Extended Operation abgreift und ins AD runter ballert, ja. Aber das ist eben genau der Fall, wo ich sage, hm, ja, das muss man dann auch wirklich, da muss man sich auch ganz genau überlegen, wie mache ich jetzt die Systemarchitektur, mit welchen Credentials gehe ich dann schreibend auf das AD und so weiter, ja. Also da muss man genau hinschauen, was man da tut, ja. Und gebaut haben wir das übrigens, ursprünglich mal dafür, weil die haben alle MacOS-Laptops, ja. Und da haben wir wirklich quasi getestet, praktisch die MacOS-Integration, direkt mit AID-Ir. Aber dann haben sie außerdem auch noch ein AD mit einem Exchange, ja, irgendwie. Und deswegen die ganze Mimik, so dass die Leute an ihrem MacOS lokal das Passwort ändern können, das mit dem File, wo es synchronisiert wird, und dann geht die Passwort Modifier Extended Operation raus und wird dann auch hinterher ins AD geblasen, ja. Aber wie gesagt, muss man es immer genau hinschauen, wie man das dann auch macht, ja. Sonst noch eine Frage? Okay, dann bedanke ich mich. Ciao.