Sicherheitsmodell und Verantwortung

Sicherheitsmodell und Verantwortung

0:00 Sicherheit hat bei Forge eine angenehme Eigenschaft: Vieles nimmt die Plattform ab. Authentifizierung, Mandantentrennung, der Umstand, dass eine App über die Bridge nie mehr sehen kann als die Nutzerin selbst. Was sie nicht abnimmt, ist die Frage, wer in Ihrer App was tun darf — und wohin Daten fließen. Genau darum geht es heute Vormittag.

0:19 Und weil diese Fragen im Projektalltag gern zwischen Entwicklung und Betrieb verloren gehen, üben wir sie an einem konkreten Review statt an Prinzipien.

Sicherheit, Qualität und kontrollierter KI-Einsatz

0:29 Der vierte Tag hat drei Teile, die enger zusammengehören, als es scheint. Am Vormittag Sicherheit: Berechtigungen, Kontexte, ausgehende Verbindungen, Protokolle. Danach Tests und Fehlersuche — denn eine Regel, die nicht geprüft ist, ist eine Hoffnung. Und zum Schluss der kontrollierte Einsatz von KI- Werkzeugen, der ohne die ersten beiden Teile gar nicht verantwortbar wäre.

Scopes sparsam schneiden

0:52 Fangen wir bei den Berechtigungen an — dem Teil Ihrer App, den fremde Administratoren als Erstes lesen. Zwei Eigenschaften sollten Sie sich merken. Erstens: Scopes gelten für die gesamte App, nicht je Modul. Es gibt also keine Funktion, die „nur ein bisschen" schreiben darf — was im Manifest steht, gilt überall. Zweitens: Kommen Scopes hinzu, verlangt die Installation eine neue Zustimmung der Administration.

1:18 Das macht die Scope-Liste zu einer Art Vertrag, den Sie mit jedem Kunden schließen. Und wie bei jedem Vertrag gilt: Je mehr darin steht, desto länger dauert die Unterschrift. Die Gegenüberstellung zeigt den Unterschied zwischen zwei Haltungen. Oben ein breiter Konfigurationsscope, der fast alles erlaubt — technisch bequem, weil er jede künftige Frage vorwegnimmt.

1:40 Unten die passende Variante: lesen, und schreiben nur dort, wo es gebraucht wird. Die Fußzeile ist mein Prüfsatz für Reviews: Ein Scope, der sich einem Administrator nicht in einem Satz erklären lässt, ist zu breit. Probieren Sie das bei Ihrer eigenen App aus — reihum jeden Scope in einem Satz begründen. Die Stille bei einzelnen Zeilen ist sehr aufschlussreich.

2:02 Diese vier Punkte erklären, warum eine späte Scope-Erweiterung teurer ist als eine frühe. Die Installation verlangt eine neue Zustimmung — also muss jemand aktiv werden, bei jedem Kunden. Das Upgrade läuft nicht mehr automatisch durch. Sicherheitsprüfungen im Unternehmen beginnen von vorn. Und der letzte Punkt ist die tröstliche Asymmetrie: Das Entfernen eines Scopes ist unkritisch.

2:26 Sie können also sparsam anfangen und später ergänzen — Sie zahlen nur eben jedes Mal einen Preis dafür. Der erste Punkt beschreibt den Weg, auf dem fast alle zu breiten Rechte entstehen: zum Ausprobieren gesetzt, nie zurückgenommen. Der zweite ist neu und wird uns heute Nachmittag wieder begegnen — die Scope-Liste wächst mit, wenn man Beispielcode übernimmt, denn Beispiele sind großzügig.

2:49 Und der dritte ist die Spätfolge: Niemand kann sagen, welcher Aufruf welchen Scope braucht, also traut sich niemand, einen zu entfernen. Deshalb die Zeile mit dem Grund, direkt beim Eintragen.

Nutzer- und App-Kontext

3:01 Jetzt zu der Unterscheidung, die gestern schon angeklungen ist und heute praktisch wird: im Namen der Nutzerin oder im Namen der App? Der Unterschied ist folgenreich. Aufrufe über die Bridge laufen im Kontext der Nutzerin: Fehlt das Recht, scheitert der Aufruf — das Produkt prüft für Sie. Im Resolver kann die App zusätzlich mit eigenen Rechten handeln, und dann gelingt fast alles.

3:24 Damit verschiebt sich die Verantwortung: Was die Plattform nicht mehr prüft, muss Ihr Code prüfen. Man kann es auch so sagen: Mit App-Rechten zu arbeiten heißt, die Prüfung selbst zu übernehmen. Wer das weiß, nutzt sie gezielt. Wer es nicht weiß, baut ein Scheunentor. Die Gegenüberstellung hat eine Pointe in der zweiten Zeile: Links scheitert der Aufruf ohne Berechtigung — rechts gelingt er fast immer.

3:48 Das klingt wie ein Vorteil und ist der eigentliche Grund zur Vorsicht. Links bekommen Sie Sicherheit geschenkt, rechts müssen Sie sie bauen. Die praktische Regel lautet deshalb: Lesen und Anzeigen laufen im Nutzerkontext, App-Rechte nur dort, wo es einen benannten Grund gibt — typischerweise für App-eigene Daten, die die Nutzerin selbst gar nicht besitzen kann.

4:08 Achten Sie auf die Reihenfolge in diesen sechs Zeilen. Zuerst die Kennung aus dem gesicherten Kontext. Dann die fachliche Frage, ob diese Person überhaupt freigeben darf. Erst danach das Handeln mit App-Rechten. Die Fußzeile nennt den Kern: Die Entscheidung fällt über den Kontext des Resolvers, nie über ein Feld aus der Nutzlast.

4:27 Wenn Sie in einem Review eine Berechtigungsprüfung sehen, die eine Kennung aus der Nutzlast verwendet, haben Sie den Befund des Tages gefunden — und zwar unabhängig davon, wie sauber der Rest aussieht. Der erste Punkt ist ehrlich und häufig: Als App wird gearbeitet, weil es im Test einfacher war. Niemand nimmt es danach zurück.

4:47 Der zweite ist das Sicherheitsmuster, das keines ist — die Oberfläche versteckt die Aktion, das Backend erlaubt sie weiter. Und der dritte ist subtil: Lesen wird geprüft, und beim Schreiben übernimmt man ungeprüft dieselbe Kennung, weil sie ja gerade dasteht. Genau hier entstehen die Lücken, die in einem Bedrohungsreview auffallen.

Externe Zugriffe und Egress

5:07 Kommen wir zu der Frage, die Datenschutzbeauftragte als Erstes stellen: Wohin kann diese App eigentlich Daten schicken? Die Antwort ist bei Forge erfreulich eindeutig: genau dorthin, wo es im Manifest steht — und nirgendwo sonst. Ausgehende Verbindungen werden angemeldet, getrennt nach Backend und Frontend. Aufrufe an nicht angemeldete Domains werden abgewiesen.

5:28 Das ist ein ungewöhnlich starkes Versprechen, und es hat einen praktischen Nebeneffekt: Die Liste der möglichen Empfänger ist prüfbar, ohne den Code zu lesen. Für ein Sicherheitsgespräch im Unternehmen ist das Gold wert. Oben die Anmeldung einer Domain für das Backend. Darunter ein zweiter Block, der in Reviews gern übersehen wird: Freigaben für Skripte und Stile.

5:50 Auch das ist eine Erweiterung der Angriffsfläche, wenn auch eine andere Art. Die Fußzeile warnt vor Platzhaltern: Ein Stern erlaubt mehr als eine Domain, und jede zusätzliche erweitert die Fläche. Die praktische Empfehlung: so eng wie möglich eintragen, auch wenn es bedeutet, später eine Zeile zu ergänzen. Eine zusätzliche Zeile ist billiger als eine Diskussion über Platzhalter.

6:13 Der rote Faden beginnt nicht mit Technik, sondern mit einer Frage: Welche Daten müssen den Mandanten wirklich verlassen? Schritt zwei ist die Erinnerung an gestern — vielleicht liegt die Angabe im Produkt schon vor. Dann erst kommt die Anmeldung. Schritt vier ist der handwerkliche Kern: Zugangsdaten über Umgebungsvariablen, nie im Code.

6:33 Und Schritt fünf klingt banal und ist der Unterschied zwischen einer App und einem Prototyp: Behandeln Sie den Fall, dass der Dienst nicht antwortet. Er wird eintreten. Der erste Punkt kostet typischerweise eine halbe Stunde Suche: Der Aufruf scheitert, weil die Domain fehlt — und die Meldung sagt das nicht so deutlich, wie man es sich wünschen würde.

6:53 Der zweite ist der schwerwiegendste im ganzen Modul: Ein Schlüssel steht im Frontend. Alles, was im Frontend liegt, ist öffentlich, auch wenn es kompiliert aussieht. Und der dritte ist der Punkt, an dem Datenschutz konkret wird: Es gehen personenbezogene Daten mit, obwohl eine Kennung genügt hätte.

Protokollierung ohne Preisgabe

7:11 Zum Abschluss des Sicherheitsteils ein Thema, das selten auf der Tagesordnung steht und regelmäßig für unangenehme Überraschungen sorgt: Protokolle. Ausgaben aus Ihren Funktionen landen in den Protokollen der App und sind über Entwicklerkonsole und CLI abrufbar. Denken Sie kurz darüber nach, wer das alles ist: Mitwirkende der App, eventuell Support, eventuell jemand, der in drei Jahren dazukommt.

7:34 Was dort steht, verlässt also den engeren Kreis. Deshalb gehören Vorgangsinhalte, personenbezogene Daten und Geheimnisse nicht hinein — auch nicht vorübergehend, denn vorübergehend ist beim Debuggen ein dehnbarer Begriff. Oben der Reflex beim Debuggen: die ganze Nutzlast und den Kontext ausgeben. Unten dieselbe Information in nützlich — welcher Vorgang, welche Aktion, welcher Ausgang.

7:58 Damit lässt sich ein Fehler genauso gut eingrenzen, ohne Inhalte preiszugeben. Die Fußzeile nennt den Baustein, der das rund macht: eine Korrelationskennung je Aufruf. Damit finden Sie zusammengehörige Zeilen wieder, auch wenn tausend andere dazwischen liegen — und das hilft bei der Fehlersuche mehr als jeder vollständige Datensatz.

8:18 Der erste Punkt ist der ehrlichste des Moduls: Beim Debuggen wird alles protokolliert, und die Zeile bleibt stehen. Sie steht dann Jahre. Der zweite ist der, den man wirklich kaum ahnt — Fehlerobjekte enthalten oft Kopfzeilen des Aufrufs, und darin können Zugangsdaten stecken. Wer ein Fehlerobjekt komplett ausgibt, gibt eventuell mehr aus als geplant.

8:39 Und der dritte ist eine Frage der Auswertbarkeit: Wenn nur Fehler protokolliert werden, fehlt der Verlauf, der zeigt, wie es dazu kam.

Übung

8:48 Jetzt wird es konkret: Sie prüfen die Rechte Ihrer eigenen App und versuchen anschließend, sie zu missbrauchen. Klarpfad liest Vorgangsdaten, speichert eigene Einträge und soll demnächst einen externen Kalibrierungsdienst der Falkenmoos GmbH anbinden. Bevor dieser Schritt kommt, steht ein Review an: Welche Rechte hat die App, und welcher Missbrauch wäre damit möglich? Genau diese Reihenfolge empfehle ich auch im echten Projekt.

9:13 Ein Bedrohungsreview vor der Erweiterung dauert eine Stunde. Nach der Erweiterung dauert es einen Tag und ändert meistens nichts mehr. Drei Teile im Erfolgskriterium. Jeder Scope mit einem Satz begründet — das ist die Fleißarbeit, die den größten Effekt hat. Drei Missbrauchsszenarien benannt — und hier bitte konkret werden, nicht „jemand könnte Daten manipulieren", sondern „eine Nutzerin ohne Freigaberecht ändert über einen direkten Aufruf den Status einer fremden Entscheidung".

9:42 Und drittens: Dieser Versuch scheitert auch mit veränderter Nutzlast. Wer früh fertig ist, liest die eigenen Protokollausgaben — mit den Augen von eben. Die ersten beiden Schritte sind Inventur: alle Scopes auflisten, je Scope den auslösenden Aufruf nennen, Überflüssiges entfernen und neu ausrollen. Schritt drei ist der interessante — drei Szenarien beschreiben und eines wirklich ausprobieren.

10:06 Schritt vier ist die Konsequenz daraus: die Prüfung auf den gesicherten Kontext stützen. Und Schritt fünf ist die Dokumentation des Fehlversuchs mit Ausgabe und Zeitpunkt. Das klingt formal, ist aber genau das, was ein Sicherheitsnachweis später verlangt. Der erste Punkt ist der Grund, warum Bedrohungsreviews oft folgenlos bleiben: Das Szenario bleibt abstrakt und wird nie ausgelöst.

10:29 Der zweite ist der handwerkliche Klassiker — die Prüfung liegt in einer Hilfsfunktion, und ein Pfad umgeht sie. Genau darum geht es gleich beim Testen. Und der dritte schließt den Kreis zum Anfang des Moduls: Der Scope bleibt, weil unklar ist, welcher Aufruf ihn braucht. Nach dem nächsten Modul können Sie das prüfen, statt es zu vermuten.