Digitale Tanzformation

NoDitch GmbH feat. Marina Dittrich

Since 09/2025 8 Episoden

Warum 'alle bekommen Admin-Rechte' eine schlechte Idee ist (und wie du Berechtigungen richtig aufsetzt)

13.10.2025 28 min

Zusammenfassung & Show Notes

Access Control ist nicht optional - auch nicht für kleine Teams. In dieser Folge erfährst du, warum das "alle dürfen alles"-Prinzip gefährlich ist und wie du mit Role-Based Access Control (RBAC) ein sicheres, skalierbares Berechtigungssystem aufbaust. Mit praktischer Anleitung zur Erstellung deiner ersten Access Matrix.

Kontakt: marina@noditch.de
Webseite: https://www.noditch.de/

Zusätzliche Ressourcen zu einzelnen Folgen gibt es über den Podcast Newsletter.
Anmeldung über diesen Link.

Transkript

Hallo und herzlich willkommen bei einer neuen Folge der digitalen Transformation. In der heutigen Folge soll es um ein Thema gehen, was sich sehr gut an die vergangene Folge anschließt, und zwar das Thema Access und Permission Management. In der letzten Folge hatte ich ja erklärt oder eher erzählt, wie der Toolstack, den wir bei NoDitch einsetzen, wie der aufgebaut ist und auch wie der historisch entstanden ist und warum bestimmte Tools eingesetzt werden und so weiter und so fort. Und das ist der Ausgangspunkt für die Frage. Wie mache ich denn jetzt, dass User in mein System reinkommen und die dort genau die Sachen machen können, die sie machen sollen? Und genau nicht mehr, nicht weniger. Und da hat man sofort das Thema Access und Permission Management. Aus meiner Praxis weiß ich, dass das ganz, ganz selten früh angegangen wird und tatsächlich einen ziemlich hohen Impact hat, wenn man das vernachlässigt. Deswegen genau. Wenn ihr die Folge noch nicht gehört habt, davor. Ich glaube Folge Nummer drei, dann hört da doch noch mal rein. Ansonsten lasst uns starten. Ich fange mal gerne damit an, indem ich erkläre, warum ich meine, dass es wichtig ist, sich mit dem Thema zu beschäftigen. Und das würde ich auch in dem Fall machen. Auch wenn die meisten von euch vermutlich wissen, dass das Thema super wichtig ist. In der Praxis erlebe ich es aber wirklich. Es ist nicht die Ausnahme. Es ist eher die Regel, dass Permission Management nicht wirklich durchdacht ist und eher so gestartet ist, dass alle alles dürfen. Und dieser Zustand hat sich einfach nicht verändert. Also alle User sind admin. Und insofern ist es nicht möglich, jetzt beispielsweise externe reinzulassen und den Granularzugriff auf bestimmte Tools oder bestimmte Bereiche in diesen Tools zu geben. Und dann lässt man es einfach und genau behilft sich irgendwie mit vielen Workarounds. Ähm, und es ist auch. Es ist jetzt so ein bisschen aus meiner Projektpraxis, also in der Zeit, wo ich noch hauptsächlich mit Atlassian Implementationsprojekte gemacht habe. Es ist sehr, sehr, sehr häufig so gewesen, dass ja, man hat eben die Angebotsphase. Man führt Gespräche und dann kommt es zum Auftrag. Und dann bekommt man Zugänge zu Confluence, beispielsweise, weil die Firma schon Confluence einsetzt und weil die auch für die ganze Planung des Implementationsprojektes bereits in dem Confluence Space gearbeitet haben. Und dort die ganzen Geschichten mit Überlegungen, Dienstleisterauswahl und die berühmten drei Angebote und das Ganze alles dort hochgeladen. Ja, und dann werde ich in den Bereich irgendwie reingeholt und sehe dann alles. Also, ich sehe dann die Konkurrenzangebote. Ich sehe die Preise. Ich sehe Dinge, die ich wahrscheinlich nicht hätte sehen sollen. Ähm, ja, meistens gebe ich dann einen Hinweis, dass sie die Sachen da rausnehmen sollen, wenn ich die nicht sehen soll. Aber das passiert super häufig und. Das ist jetzt ein kleines Beispiel mit einem nicht so hohen Impact, würde ich jetzt sagen. Weil wie die Konkurrenzpreise aussehen, das weiß ich grundsätzlich. Aber beispielsweise, wenn man jetzt Praktikantinnen mit Rechten ausstattet, wo sie halt Dinge löschen können und etwas kaputt machen können, das ist super schlecht. Oder auch einfach in manchen Tools hängt an dem Adminrecht auch eine Möglichkeit, Daten sehr einfach zu exportieren. Also in Confluence gibt es beispielsweise das Recht Export Space, kann man mit einem Klick den ganzen Inhalt von einem Confluence Bereich exportieren. Und das macht es einfach einfacher als nötig, an große Datenmengen zu kommen und ähm, dass Personen nicht auf Ewigkeiten in einem Unternehmen arbeiten, sondern auch ihre Rollen wechseln und dann gegebenenfalls sehr, sehr leicht Unternehmenswissen mitnehmen können. Das sind so die typischen Fälle. Und es kommt dann erst so richtig ins Bewusstsein, wenn sowas mal passiert ist. Und falls es euch interessiert, darüber mal mehr nachzulesen, weil das ist ein Thema, das betrifft nicht nur jetzt kleinere Unternehmen. Sondern wirklich auch große Player. Hatte ich, glaube ich, in einer der ersten Podcast Folgen schon mal erwähnt. Da gibt es die Tesla Files. Das ist eine Handelsblattrecherche. Die gibt es mittlerweile auch als Buch. Und die basieren auf letztlich einem Material, wo ein Informant an das Handelsblatt herangetreten ist und dort letztlich Exporte aus Jira und Confluence mitgegeben hat. Und genau der ganze Fall wird da so ein bisschen aufbereitet. Das Buch geht natürlich viel über was die Inhalte von diesen Daten sind. Ja, ich glaube, da ging es um so Geschichten auch mit dem Probleme mit dem Autopiloten. Das wollte das Unternehmen eigentlich unter Verschluss halten. Also so Zeug. Darum geht das Buch. Aber es wird auch darauf eingegangen, wie diese Datenlecks zustande kamen und das wäre noch mal so ein totaler Deep Dive ins Thema. Wenn euch das interessiert, verlinke ich euch das gerne in den Shownotes. Ansonsten genau ist, glaube ich, ihr wisst, glaube ich selber, dass das Thema wichtig ist. Und mit der Folge möchte ich euch mal so ein paar Konzepte an die Hand geben und eine Herangehensweise, wie man sich dem Thema nähern kann, dass ihr eine Vorstellung von dem habt, wie es optimalerweise aussehen sollte oder auch aussehen kann. Und genau auf der Basis könnt ihr überlegen, wie ihr dann von dem Zustand, den ihr jetzt gerade habt, vielleicht ist er gar nicht so weit weg davon. Vielleicht aber schon. Und dann genau bekommt ihr jetzt ein paar Anregungen, wie ihr das anders machen könntet. Schauen wir uns mal zwei Konzepte an, die ich in dem Bereich als die wirklich zentralsten ansehe. Und wenn man sich allein an die hält, ist damit schon super viel gewonnen. Und ja, damit hat man das Thema eigentlich schon ganz gut im Griff, würde ich sagen. Und zwar das erste Prinzip nennt sich Principle of least Privilege, also auf Deutsch, sowas wie so viel wie nötig und so wenig wie möglich. Und das sollte der oberste Gesichtspunkt für die Vergabe von Access oder Permissions sein. Also exakt die Permissions oder den Access, der nötig ist und nicht mehr. Das ist deswegen wichtig, weil beispielsweise wenn der Account verloren geht und ja irgendwer sich des Accounts bemächtigt, dann kann diese Person nicht alles, sondern kann halt auf bestimmte Tools oder Daten zugreifen. Ja, wenn das jetzt vielleicht nur wenn es eine Marketingrolle war, dann sind es halt Zugänge auf ja, Marketing Tools, vielleicht auf Hubspot, vielleicht auf bestimmte Confluence Spaces, aber ganz bestimmt nicht auf HR Daten, Abrechnungs, also Accounting Tools und so weiter. Sondern es ist nur eine Teilmenge von dem, was maximal da ist. Wohingegen, wenn jetzt das auch ein Admin Account ist und dieses berühmte Alle dürfen alles, dann ist der Schaden natürlich viel, viel größer. Genau das ist das erste und das zweite nennt sich Role Based Access Control, RBAC Role Based Access Control. Und das ist so das Ding, was finde ich der Game Changer ist bei diesem ganzen Thema. Was aber wirklich wenig Unternehmen schaffen, komplett durchzuziehen. Und das bedeutet ganz einfach, dass man die Berechtigung immer an Rollen koppelt und nicht an Personen. Also, dass man nicht so rangeht und sich überlegt: Ja, die Marina. Was braucht die denn? Die braucht Jira Zugang. Die braucht dieses. Die braucht jenes. Und dann wird das individuell pro Person entschieden, sondern ganz einfach: Welche Rolle hat denn die Marina? Und welche Prozesse oder welche Aufgaben, also welche Prozesse bedient sie? Welche Aufgaben hat sie in dieser Rolle? Welche Tools braucht sie um das zu tun? Und welche Berechtigung braucht sie innerhalb der Tools? Und das ergibt dann ja, quasi ein abstraktes Schema, wo man auch flexibel darauf reagieren kann, wenn jetzt Marina die Rolle wechselt. Ja, weil dann vollkommen klar ist jetzt, welches Set von Access und Permission sie braucht, wenn sie eben in dieser anderen Rolle ist, weil es nicht personenbezogen ist. Und das ist wirklich ein, ich kann es nur sagen, das ist eigentlich der Game Changer für das ganze Thema. Und die Umsetzung davon, das wird auch den Hauptteil dieser Folge ausmachen, weil das ist so das universellste Prinzip, was eigentlich alle wichtigen Fälle abdeckt. Also beispielsweise wann sind Zugänge wichtig? Wann kommt das Thema praktisch auf? Das ist beim Onboarding. Das ist beim Offboarding. Das ist, wenn sich der Verantwortlichkeitsbereich oder der Aufgabenbereich ändert. Und für all diese Fälle hat man genau hat man dann einen, ähm, man muss nicht individuell überlegen: Was bedeutet das jetzt? Sondern man guckt einfach in die Tabelle und sagt ja, okay, jetzt müssen diese Berechtigungen vergeben werden. Genau das sind die zwei wichtigen Konzepte. Und jetzt würde ich noch mal ein paar Worte darüber verlieren, was eigentlich die Voraussetzungen sind, also die Startvoraussetzungen, um jetzt sowas umzusetzen. Ich hatte ja schon gesagt, dass das Thema sich sehr gut an die vorangegangene Folge anschließt. Und das hat den Grund, weil für jetzt so eine Role based Access Control oder für so ein Berechtigungsschema, um das abzuleiten und aufzusetzen, müssen schon bestimmte Dinge klar sein. Also, es muss klar sein, grundsätzlich, wie euer Toolstack oder wie eure Core Tools nenne ich sie jetzt mal aussehen. Es muss jetzt nicht unbedingt alles dazugehören. Aber so der Core Tools Stack, so wie ich in der letzten Folge jetzt für NoDitch erklärt habe, das muss schon bekannt sein. Ja, weil ihr wissen müsst: Gut, Vertriebsprozesse Marketingprozesse sind jetzt wie bei uns beispielsweise in Hubspot. Projektmanagement ist in Jira. Und es muss auch noch ein bisschen granularer klar sein innerhalb der Tools. Da bin ich jetzt in der letzten Folge nicht drauf eingegangen. Aber das ist quasi, also das haben wir, ja, wir haben ein Konzept, wie Jira konfiguriert ist. Also in welchen Jira Projekten was stattfindet, welche Kundenprojekte in welchen Jira Projekten sind. Und das Gleiche haben wir auch für die Knowledge Base in Confluence. Also was ist der Confluence Space für jetzt die allgemeine Datenbank, also die allgemeine Knowledge Base? Was ist jetzt, was sind Bereiche, die für die Zusammenarbeit mit Kunden benutzt werden? Und genau, also diese Zuordnung muss man auch machen können. Und dann muss man ein ganz grobes Verständnis haben für Rollen, die also jetzt Berufsrollen, Berufsbezeichnung Profile, die ihr im Unternehmen habt. Das kann auch wirklich erst mal eine grobe Einordnung sein. Ja, also, dass man sagt: eine Person macht eher Vertrieb am Anfang. Wenn man jetzt ganz klein ist, dann werden ja eh mehrere Rollen in einer Person vereint sein. Und das ist auch total okay. Und dann würde ich es auch einfach so notieren. Ja, dass jetzt diese eine Person, die macht halt Sales, sie macht Marketing und sie ist auch in Kundenprojekten. Ja, so eine Situation ist ja bei uns als jetzt noch sehr kleines Boutique Consulting Unternehmen ist ja definitiv auch so. Das heißt aber nicht, dass man nicht eine Role based Access Control machen kann. Das heißt dann einfach nur, dass jetzt eine Person mehrere Hüte auf hat, also mehrere Rollen ausfüllt und natürlich dementsprechend mehr Berechtigung auch und mehr Tools hat. Das ist einfach so und dieses Konzept kann dann quasi, wenn die Firma wächst, dann wird sich das mehr ausdifferenzieren. Dann wird es so sein, dass manche Personen sich nur auf den Vertrieb konzentrieren und andere vielleicht nur in Kundenprojekten sind. Und die Logik bleibt einfach. Es ist nur, es passt sich dem an. Genau, aber jetzt bin ich etwas abgeschweift. Also, ihr müsst als Voraussetzung für die Einrichtung von so einem Berechtigungskonzept müsst ihr zumindest grundsätzlich euren Toolstack haben. Ihr müsst wissen, welche Tools für welche Prozesse implementieren. Und ihr müsst ein grobes Verständnis von Rollen haben. Und wenn ihr das habt, dann genau, dann könnt ihr loslegen mit dem, was jetzt kommt. Eine Sache habe ich tatsächlich noch vergessen. Fällt mir gerade auf. Ich rede die ganze Zeit von Access und Permission und habe noch nicht erklärt, was eigentlich der Unterschied dazwischen ist. Also von Access spricht man immer, wenn es um quasi den Login geht. Also kann ich mich mit meinem User bei einem Tool einloggen. Das ist Access. Kann ich darauf zugreifen. Und Permissions, das ist dann die Frage innerhalb des Tools. Also, welche Aktionen kann ich innerhalb des Tools durchführen? Beispielsweise kann ich eine Confluence Seite erstellen. Das wäre eine Permission. Oder auch sowas wie Zugriff zu einzelnen Teilbereichen nenne ich es jetzt mal der Tools, also Confluence Spaces oder Jira Projekten oder ich weiß nicht, ob die Notion Spaces heißen, dass wir auch alles so die Abteilungen vermischen. Ähm und Access, also zumindest in meinem Kopf, wenn ich darüber spreche, meine ich halt diese Trennung. Also Access bezieht sich auf die Application Layer. Kann ich mich einloggen oder nicht? Permissions alles innerhalb der Tools. Auch wenn man sagen kann innerhalb der Tools Access auf einen Confluence Bereich läuft in meinem Kopf unter Permissions, weil genau ich da diese Trennung bei der Application Layer ziehe. Gibt vielleicht auch andere Schulen. Aber bloß, dass ihr wisst, worüber ich spreche, wenn ich diese Worte verwende. So wenn wir jetzt so eine Role based Access Control einrichten wollen, dann ja, gehen wir eigentlich relativ stumpf diese Punkte durch, die ich gerade schon genannt habe. Also auf der ersten Ebene hat man die Personen, die im Unternehmen arbeiten. Das ist einfach. Das ist einfach eine Liste. Das ist die Liste, die man später zuordnen muss. Da muss man gar nicht viel machen. Das nächste ist die Ebene der Rollen. Also, welche Rollen habe ich im Unternehmen? Und wenn ihr noch klein seid und alle alles machen, würde ich trotzdem so darüber nachdenken, welche Rollen gerade existieren. Auch wenn es so ist, dass eine Person beispielsweise drei Rollen hat, ja, die sie nicht Ewigkeiten lang parallel machen wird, denkt trotzdem an diesen Rollen und notiert diese Rollen. Und dann habt ihr die Ebene der Tools. Also für welche, also, dazwischen sind eigentlich vermittelt wird, wird es durch die Prozesse. Ähm, aber wahrscheinlich könnt ihr auch den Schritt überspringen, weil den habt ihr eh im Kopf, sondern ihr fragt euch jetzt: Welche Rolle braucht Access zu welchen Tools? Und das könnt ihr in so einer Matrix notieren. Also, ihr habt auf der oberen Leiste, also auf der oberen Zeile. Wenn ihr euch jetzt eine Tabelle vorstellt, die Überschriftenzeile. Da habt ihr da schreibt ihr alle Tools auf, die ihr habt. Und dann in der ersten Spalte links, ähm, da schreibt ihr die Rollen auf, die ihr habt. Und dann geht ihr einfach alle Zeilen durch. Beispielsweise die erste Rolle ist Sales. Und dann geht ihr die Tabelle durch und setzt überall Haken und Kreuzchen da, wo die Rolle erstmal Access braucht. Und das macht ihr quasi für alle Rollen durch. Und das ist dann auch schon der erste Schritt. Und damit habt ihr schon mal die Frage geklärt: Zu welcher Rolle gehört welcher Access? Wenn das durch ist, dann kann man ein bisschen reinzoomen und kann sich dann fragen innerhalb der Tools. Und das ist jetzt eine Sache, die hängt halt total von der jeweiligen Software ab. Also, wie komplex es da wird und wie viel ihr dafür tatsächlich aufschreiben müsst. Ähm, und ich würde zuerst, ähm, in die Tools reingehen und mir einmal wirklich das rausschreiben. Wie sind die Permissions dort organisiert? Also, es gibt beispielsweise einfache Tools, wo man nur sowas hat wie ähm, View Edit und noch was, oder? Ja, weiß ich nicht. Was wäre jetzt da so ein Beispiel? Ich glaube, bei Loom ist das auch relativ einfach. Da kann man entweder admin sein von so einem Space oder wie auch immer die Dinger da heißen. Oder man ist quasi nur User von so einem Space. Bei Miro ist es, glaube ich auch relativ. Also, da hat man sowas wie 2, 3, 4 verschiedene Level. Und man muss halt nur entscheiden: Ist jetzt ein User quasi admin oder ist er User? Oder ist da irgendwas dazwischen? Ist er Board Admin oder sowas? Das sind einfache Tools. Da braucht ihr nicht viel aufschreiben, weil da habt ihr ja wirklich dann eine mini kleine Tabelle, wo dann eben diese Level aufgezeichnet sind. Und ich würde das für euch dann auch einmal so aufschreiben, dass ihr da einmal drauf guckt und ihr versteht dann: ja, stimmt. Loom. Da war das so und so. Und dass ihr euch das auch angewöhnt bei neuen Tools, die ihr dazu bekommt, dass ihr euch damit erst mal beschäftigt und das in eure Matrix sozusagen einpflegt. Ähm. Und dann gibt es Tools wie jetzt Jira beispielsweise oder auch Google Workspace. Die sind supergranular. Also, da braucht ihr schon, da braucht ihr wirklich ein komplettes Konzept innerhalb der Software. Also, das ist ein eigener Aufwand. Das ist aber ich würde sagen, die Ausnahme. Also von so Tools habt ihr vielleicht ein oder zwei, wo das so ein bisschen komplexer ist und, ähm, schreibt es aber auch da auf. Also, welche Möglichkeiten habe ich da drin? Und wie kann man dort granular diese Permissions, also welche Permissions kann ich vergeben? Und dann und das ist jetzt, glaube ich, das kriegt man nicht mehr auf eine Seite unter. Aber man könnte vielleicht, wenn ihr jetzt egal, ob ihr jetzt in Notion seid oder in Google Docs oder in Confluence. Könnt ihr ja jeweils mit Links arbeiten. Also, ihr habt diese Matrix von der, die wir gerade besprochen haben. Also das Mapping zwischen den Rollen und den Tools. Und dann verlinkt ihr jeweils die Tools. Also im Text sozusagen. Das ist jetzt, ich glaube, ich muss eine Vorlage dazugeben. Ich hoffe, ihr könnt mir noch folgen. Ich will das klickbar haben. Also, ihr habt diese eine Tabelle. Und wenn ihr auf die Tools klickt in der Überschriftenzeile, dann gelangt ihr auf diese Seite, wo erklärt ist, wie das im Tool funktioniert. Und dann könnt ihr, glaube ich, pro Rolle würde ich nochmal eine Seite machen, wo die Permissions. Nicht Access, sondern Permissions für eine Rolle niedergeschrieben sind. Und das wird eine etwas kompliziertere Seite. Und da kann ich euch jetzt nicht sagen, wie die aussehen soll, weil, wie gesagt, das hängt total ab von den Tools, die ihr habt. Wenn ihr nur einfache Tools habt, wo man nur entscheiden muss, welches Level sozusagen einer Rolle zugeordnet wird, dann habt ihr vielleicht. Dann schafft ihr es vielleicht auch sogar, das in einer Seite zu integrieren. Ansonsten sind es halt mehrere Seiten. Hauptsache ist, dass ihr versteht: Also, ihr möchtet Personen Rollen zuordnen und Rollen haben Access in verschiedenen Tools und haben darin auch bestimmte Permissions. Und dieses Set an Permissions am Ende also eine Rolle. Eine Rolle bei euch im Unternehmen ist definiert durch eine ganze Reihe von Permissions in verschiedenen Tools und die habt ihr dokumentiert. So das war jetzt der komplizierte Ausflug. Ihr müsst es dokumentiert haben, sonst, weil das kann man nicht im Kopf behalten. Und das klingt jetzt auch wenn ich darüber spreche, klingt es kompliziert. Am Ende sind es lauter Tabellen. Und ihr müsst euch einmal mit diesen Dingern beschäftigen und das aufschreiben. Und diese Tabelle istdann die Basis dafür, dass ihr Berechtigung vergebt. Also jedes Mal, wenn eine neue Person anfängt, dann fragt euch immer, welchen Rollen wird sie zugeordnet? Und wie gesagt, es können auch mehrere sein. Und davon leitet ihr ab, welche Berechtigung ihr vergeben müsst. Genau. Und dieses Prozedere. Also diese Matrix. Das ist nicht so zu verstehen: Das ist so wie als Projekt. Ihr macht es einmal, dann ist es abgeschlossen. Und dann ist gut. Klar. Man muss sich initial einmal hinsetzen und das machen. Aber bei jedem Tool, was ihr neu anschafft, müsst ihr diese Matrix ergänzen. Bei jeder Migration, die ihr macht, müsst ihr das anpassen. Ähm. Und genau. Das lebt davon dass ihr das, also diese, ja, ihr müsst es, ihr müsst es leben. Diese Standards. Ja, ähm, das nimmt euch keiner ab, aber eins kann ich euch sagen: Auch wenn es jetzt aufwendig klingt, was ich sage, es ist erstens zehnmal sicherer. Ja, da braucht man gar nicht darüber diskutieren. Wenn ihr mal in die Situation kommt, irgendwelche Audits, also irgendwie Rechenschaft darüber abzulegen, warum eine Person welchen Access hat, seid ihr auf der sicheren Seite. Und es ist auch wesentlich, es ist nicht, es ist absolut nicht aufwendiger. Als bei jeder Person, die neu zukommt, sich das neu zu überlegen. Ähm. Und ihr habt halt einfach ein System, was ihr anwenden könnt. Klar, das System anzuwenden, ist auch Aufwand. Aber dieser Aufwand ist geringer als jedes Mal neu sich zu fragen. Ja, okay. Was machen wir jetzt in dem Fall? Und dann wird irgendeine Einzelfallentscheidung getroffen. Diese Einzelfallentscheidung ist nicht dokumentiert. Und irgendwann kommt halt der Punkt, wo man sagt: Ja, komm, keine Ahnung. Ist jetzt eh Chaos. Alle dürfen alles. Ja. Und dann habt ihr halt die Situation. Genau. Das zum Thema Role-based Access Control und ähm, ja, gebt mal Feedback, ob das irgendwie verständlich war. Ich versuche mich mal ranzusetzen und da zumindest für den Toolstack, den wir haben, ähm, da eine Matrix aufzuzeichnen beziehungsweise wir haben teilweise auch so Dokumente. Ähm, aber die könnte ich versuchen zu verallgemeinern und das so ein bisschen Template-mäßig, dass ihr das ein bisschen anwenden könnt. Damit wären wir am Ende der heutigen Folge angekommen. Ich fasse noch mal kurz zusammen. Also zentrale Konzepte in der heutigen Folge waren einerseits das Principle of Least Privilege. Also nicht alle können alles und alle haben Adminrechte, sondern jeder wirklich so viel wie nötig, so wenig wie möglich. Und das andere große Konzept war eben die Role Based Access Control, also Permissions und Access nicht auf Personenniveau definieren, sondern überlegt euch, welche Rollen ihr habt und wie sich daraus dann eben die ganzen Zugriffe ableiten. Und wenn ihr eine Sache von der Folge mitnehmen könnt, ist es ja wirklich der Anreiz. Also beschäftigt euch mal mit diesem Thema und versucht doch zumindest diese Access Matrix. Also, ich kann schon verstehen, dass es innerhalb der Tools dann eventuell ein bisschen tricky wird, gerade wenn man da sehr granular vorgehen kann. Aber überlegt euch doch schon mal, damit ist doch auch schon was gewonnen. Ja, man muss ja nicht alles sofort haben. Aber diese Access Matrix, also welche Rolle, welche Tools hat und vielleicht soweit eine Unterscheidung wie: Wo braucht man Adminrechte? Wo braucht man Userrechte, so ganz grob. Damit ist doch auch schon was gewonnen. Und das ist eine Sache. Die kostet wirklich nicht viel Zeit. Ja, lasst es eine Stunde oder zwei sein. Und wenn ihr dabei merkt, dass es super schwierig ist, das überhaupt hinzukriegen, weil ja, es gibt Vertriebsprozesse, die sind in HubSpot und welche dann in Notion. Und dann gibt es auch noch ganz ganz wichtige Tabellen und so ähm, dann ist das ein Zeichen, dass ihr bei dem Schritt davor noch mal ansetzen müsstet. Also eine Klarheit darüber, welche Prozesse eigentlich wie in eurem Toolstack abgebildet sind. Weil wenn ihr das nicht, ja, wenn ihr das nicht in den Griff bekommt, dann braucht ihr mit dem Permission Thema gar nicht erst anzufangen. Und vielleicht hilft das auch, wenn ihr gerade an dem Permission Thema dran seid und da irgendwie auf keinen grünen Zweig kommt, eben weil das Problem einen Schritt vorher erstmal gelöst werden muss. Genau. Ansonsten freue ich mich über Feedback, Anregung und Ideen, Themenvorschläge. Meldet euch bei mir. Schreibt mir eine Mail oder auf LinkedIn. Die Mail ist auch in den Shownotes verlinkt. Und dann ja, wünsche ich euch eine schöne Woche. Und wir hören uns beim nächsten Mal. Tschüss.