Im Namen des Nutzers: wie edda Berechtigungen spiegelt statt sie neu zu erfinden
In jeder Sicherheitsprüfung kommt dieselbe Frage: Findet über das neue System jemand Dinge, die er vorher nicht sehen durfte? Wer darauf keine Antwort in einem Satz hat, bekommt keine Freigabe. Die Antwort von edda lautet: Nein, weil edda im Namen des Fragenden liest.
edda greift über delegierte Zugriffe per OAuth2 mit den Rechten der fragenden Person auf die Quellsysteme zu, nicht mit einem technischen Sammelkonto. Ein Dokument, das jemand in SharePoint nicht öffnen darf, wird für seine Anfrage gar nicht gelesen und kann deshalb nicht in der Antwort erscheinen. Ein eigenes Rechtekonzept wäre der falsche Weg, weil es nach wenigen Monaten nicht mehr gepflegt wird.
Wie das technisch funktioniert
edda nutzt delegierte Zugriffe über OAuth2. Wenn eine Person eine Frage stellt, greift das System mit deren Berechtigungen auf die Quellsysteme zu — nicht mit einem technischen Sammelkonto, das alles lesen darf. Ein Dokument, das diese Person in SharePoint nicht öffnen kann, wird für ihre Anfrage gar nicht erst gelesen. Es kann deshalb auch nicht in ihrer Antwort auftauchen.
Warum ein eigenes Rechtekonzept der falsche Weg wäre
Die Alternative wäre, in edda eigene Rollen zu definieren. Das scheitert an der Pflege: Jede Änderung in Ihren Quellsystemen müsste nachgezogen werden, und spätestens nach dem dritten Monat passiert das nicht mehr. Ab da hat das System Rechte, die nicht mehr Ihren entsprechen, und niemand merkt es. Mit delegierten Zugriffen gibt es nichts nachzupflegen: Ändert Ihre IT eine Berechtigung, gilt sie ab der nächsten Frage.
Die Geschichte: die Antwort, die zwei Kollegen unterschiedlich sehen
Zwei Mitarbeitende stellen dieselbe Frage zu einem Kundenprojekt. Der Projektleiter bekommt die vollständige Antwort inklusive Konditionen aus dem Vertragsordner. Der Werkstudent bekommt die technische Auskunft ohne die kaufmännischen Teile — nicht weil ein Filter greift, sondern weil die Vertragsdokumente für seine Anfrage nicht lesbar waren.
Das ist der entscheidende Unterschied zu einer nachträglichen Filterung: Was nicht gelesen werden darf, gelangt gar nicht erst in die Verarbeitung.
Was das Projekt trotzdem sichtbar macht
In fast jedem Betrieb fördert die Einführung ein bestehendes Problem zutage: historisch gewachsene Ablagen, in denen faktisch alle alles dürfen, oder alte Integrationskonten mit Vollzugriff. edda verursacht das nicht, es macht es sichtbar. Unangenehm, aber deutlich besser als die Alternative, es weiterhin nicht zu wissen.
Häufige Fragen
Sieht jemand über edda mehr als vorher?
Nein. edda liest mit den Berechtigungen der fragenden Person aus Ihren Quellsystemen. Wer ein Dokument heute nicht öffnen darf, bekommt seinen Inhalt auch über eine Antwort nicht zu sehen, weil es für diese Anfrage nicht gelesen wird. Das ist der Satz, der in der Sicherheitsprüfung zählt.
Was ist der Unterschied zu einem Filter?
Ein Filter entfernt Inhalte nachträglich aus einem Ergebnis, das bereits erzeugt wurde — und jede Lücke im Filter ist ein Datenabfluss. Bei delegiertem Zugriff gelangt unzulässiges Material gar nicht erst in die Verarbeitung. Das ist strukturell sicherer und deutlich leichter zu prüfen.
Was passiert, wenn wir Rechte ändern?
Die Änderung wirkt ab der nächsten Anfrage. Es gibt keine zweite Rechteverwaltung, die nachgezogen werden müsste, und damit auch keinen Zustand, in dem edda mehr erlaubt als Ihre Systeme. Genau das ist der Vorteil gegenüber einem eigenen Rollenkonzept.
Wie erklären wir das dem Betriebsrat?
Mit demselben Satz wie der IT, ergänzt um zwei Punkte: das Aktivitätsprotokoll, das nachvollziehbar macht, was wann gelesen wurde, und die Zusage, dass keine Leistungs- oder Verhaltenskontrolle stattfindet. Frühe Einbindung ist erfahrungsgemäß deutlich günstiger als eine nachträgliche Klärung.
