Sicherheit und Governance in Brownfield-Projekten

Sicherheit und Governance in Brownfield-Projekten

0:00 Über Sicherheit beim Einsatz von Coding-Agenten wird viel geschrieben — meist mit Blick auf neue Projekte. Im Bestand verschärfen sich dieselben Fragen aus einem einfachen Grund: Diese Systeme sind geschäftskritisch, sonst würde man sie nicht modernisieren, sondern abschalten. Dazu kommen gewachsene Rechte, eine lange Historie und Anbindungen, von denen niemand mehr weiß.

0:21 In diesem Modul geht es nicht um Verbote, sondern um eine Stufung, die im Alltag trägt: knappe Rechte für die häufigen Aufgaben, ausdrückliche Freigaben für die seltenen — und eine klare Zurechnung der Verantwortung.

Sicherheit und Governance in Brownfield-Projekten

0:33 Wir gehen von den Besonderheiten des Bestands zu den konkreten Maßnahmen. Zuerst: Was ist hier anders als in der Neuentwicklung? Dann die Frage, welches Werkzeug welche Daten überhaupt sehen darf. Dann eine Altlast, an die kaum jemand denkt — Zugangsdaten in der Versionshistorie. Danach die Rechtestufung, die den Kern dieses Moduls bildet, und die Angriffsfläche über Bestandsinhalte. Dann die besonders kritischen Bereiche.

0:59 Und zum Schluss die organisatorische Klammer: Freigaben, Nachweisweg, Verantwortung. In der Übung entwerfen Sie ein vollständiges Modell.

Was im Bestand anders ist

1:08 Fangen wir mit der Bestandsaufnahme an. Vier Umstände machen die agentische Arbeit hier heikler — und der wichtigste ist so banal, dass man ihn leicht übersieht. Der banale Umstand lautet: Diese Systeme sind geschäftskritisch. Das ist keine Nebenbemerkung, sondern die Auswahllogik — an unwichtigen Systemen investiert niemand Modernisierungsbudget.

1:29 Sie arbeiten also per Definition an etwas, dessen Ausfall wehtut. Dazu kommen drei weitere Umstände, die alle mit der Geschichte des Systems zu tun haben. Ein Agent, der in einer solchen Umgebung mit weitreichenden Rechten arbeitet, kann Schaden anrichten, den in der Neuentwicklung niemand fürchten muss. Alle vier haben dieselbe Wurzel: die Zeit.

1:50 Gewachsene Rechtestrukturen, die niemand mehr überblickt — jemand hat vor Jahren einen Zugang eingerichtet, und niemand hat ihn je entzogen. Eine lange Historie, in der Zugangsdaten liegen können; dazu gleich mehr. Anbindungen an Systeme, deren Betreiber gar nicht wissen, dass sie noch verbunden sind. Und der vierte Punkt zieht die Klammer: Die Menschen, die diese Zusammenhänge kannten, sind oft nicht mehr da. Sie können also nicht einmal jemanden fragen.

2:19 Der erste Punkt ist der methodische: Die Sicherheitsregeln aus der Neuentwicklung unverändert zu übernehmen, greift zu kurz. Dort gibt es keine gewachsene Historie. Der zweite ist der praktische Alltagsdruck — Rechte großzügig vergeben, weil die Erkundung sonst langsamer ist. Wir sehen gleich, dass das für die Erkundung gerade nicht gilt.

2:39 Und der vierte ist der wichtigste Perspektivwechsel dieses Moduls: Das Risiko hängt nicht am Werkzeug, sondern an den Rechten, die Sie ihm geben. Diese Frage können Sie selbst beantworten.

Zulässige Werkzeuge und Datenklassifikation

2:50 Jetzt die Frage, die vor dem ersten Einsatz beantwortet sein muss: Welches Werkzeug darf mit diesen Daten arbeiten? Und die Antwort hängt an etwas anderem, als die meisten annehmen. Sie hängt am Betriebsmodell des Werkzeugs, nicht an seiner Nützlichkeit. Wo werden die Daten verarbeitet, wer hat Zugriff, was passiert damit?

3:10 Und zu klären ist mehr als der Quellcode — den haben die meisten auf dem Schirm. Was ist mit Produktionsprotokollen, in denen Kundennamen stehen? Mit Fehlerberichten, die einen Datensatz enthalten? Mit Tickets? Beim Fahrtenbuch ist die Antwort für Fahrtdaten eindeutig, und wir schauen sie uns gleich an. Die Tabelle geht von der harmlosesten zur eindeutigsten Datenart.

3:32 Ganz unten stehen die Fahrtdaten — Bewegungsdaten benannter Personen, und da ist die Antwort eindeutig nein, solange der Verarbeitungsweg nicht geklärt ist. Und jetzt die Fußzeile, die den praktisch wichtigsten Fall benennt: Das gilt auch für den kurzen Blick in eine Produktionstabelle zur Fehlersuche. Genau dort passiert es nämlich — nicht bei einem geplanten Datenexport, sondern beim schnellen Kopieren von drei Zeilen in ein Chatfenster, weil man einen Fehler nachvollziehen will.

3:59 Der Grund ist unspektakulär und entscheidend: Ohne Schriftform entscheidet im Zweifel jeder für sich — und zwar meist zugunsten der Bequemlichkeit, unter Zeitdruck, an einem Freitagnachmittag. Das ist kein Vorwurf, sondern eine Beobachtung über Menschen in Arbeitssituationen. Der dritte Punkt ergänzt eine Selbstverständlichkeit, die oft fehlt: Die Regel muss den Entwicklern bekannt sein, nicht nur beschlossen.

4:22 Und der vierte ist die harte Fassung davon: Eine Regel, die nur im Kopf einer Person existiert, gilt faktisch nicht.

Altlasten im Repository: Secrets in der Historie

4:30 Jetzt eine Besonderheit von Bestandssystemen, an die kaum jemand denkt. Sie hat nichts mit dem aktuellen Code zu tun — und ist trotzdem ein aktuelles Problem. Was heute nicht mehr im Code steht, kann in der Historie noch stehen. Vor zehn Jahren war es verbreitet, Zugangsdaten, Zertifikate, Schlüssel und interne Adressen einzuchecken — das galt nicht als Fehler, das war die Praxis.

4:53 Irgendwann hat jemand sie aus dem aktuellen Stand entfernt, und damit gilt die Sache als erledigt. Ist sie aber nicht: In der Historie stehen sie weiterhin, vollständig und abrufbar. Wer das Repository klont, hat sie. Zwei Gründe, die zusammenwirken. Ein Agent mit Zugriff auf die Historie kann darauf stoßen — beim Hotspot-Auswerten aus Modul zwei zum Beispiel, ohne dass das jemand beabsichtigt hätte.

5:18 Und alles, was in seinen Kontext gerät, kann in Ausgaben auftauchen: in einer Zusammenfassung, in einem Codevorschlag, in einer Notiz. Der dritte Punkt ist die einfache Feststellung, die man mitnehmen sollte: Die Historie ist Teil des Repositorys, nicht ein separates Archiv. Wer nur den aktuellen Stand prüft, hat die Frage nicht beantwortet.

5:39 Fünf Schritte, und die Reihenfolge ist der eigentliche Ratschlag. Suchen, bewerten — und dann Schritt drei, der einem widerstrebt: Alles, was jemals veröffentlicht wurde, gilt als kompromittiert. Auch wenn es nur im internen Repository lag, auch wenn es lange her ist. Schritt vier ist die wirksame Maßnahme: ungültig machen und ersetzen. Das ist schnell und wirkt sofort.

6:01 Die Bereinigung der Historie dagegen — Schritt fünf — ist aufwendig, bricht bestehende Klone und ist selten die erste Maßnahme. Wirksam ist das Ungültigmachen.

Read-only zuerst, Rechte gestuft

6:12 Jetzt der Kern dieses Moduls. Eine einfache Stufung, die fast nichts kostet — und der überwiegenden Mehrheit der Aufgaben das Risiko vollständig nimmt. Erinnern Sie sich an Modul zwei: Bei Modernisierung ist die Erkundung ein großer Teil der Arbeit, oft der größte. Und diese Erkundung kommt vollständig mit Leserechten aus — sie ändert ja nichts.

6:33 Das ist eine erfreuliche Konstellation: Der häufigste Anwendungsfall ist zugleich der risikoärmste. Alles Weitere kommt gestuft hinzu, nach Planung und Freigabe. Wichtig ist die Reihenfolge — nicht alles geben und dann einschränken, sondern minimal beginnen und gezielt erweitern. Die Stufen steigen von oben nach unten im Risiko. Lesen deckt die ganze Erkundung ab. Schreiben kommt erst nach Planfreigabe und begrenzt auf ein isoliertes Arbeitsverzeichnis.

7:01 Ausführen später, mit klaren Grenzen. Bei Netzwerk sollten Sie am genauesten hinsehen, denn hier können Daten das Haus verlassen — und zwar unbemerkt. Und die letzte Zeile ist die klarste Ansage: Rechte auf fremde Systeme, also Datenbanken, Auslieferungen, Nachbarsysteme, gehören in agentischer Arbeit grundsätzlich nicht dazu, sondern hinter eine menschliche Freigabe.

7:23 Die Fußzeile nennt den Preis dieser Stufung: fast nichts. Der erste Punkt beschreibt die typische Reihenfolge: Man startet mit Vollrechten und will später einschränken. Das passiert nie, weil dann alles funktioniert und jede Einschränkung als Rückschritt erscheint. Der zweite ist der verbreitetste Sündenfall — Datenbankzugänge in die Agentenumgebung legen, weil die Analyse damit so viel besser wird.

7:47 Der dritte ist die unterschätzte Stufe: Netzwerkzugriff wirkt harmlos, weil nichts geschrieben wird. Er ist aber der Weg nach draußen. Und der vierte ist die riskanteste Bequemlichkeit: Auslieferungs‐ rechte an eine automatisierte Kette hängen.

Prompt Injection über Bestandsinhalte

8:02 Jetzt zu einer Angriffsfläche, die in Bestandssystemen größer ist als in neuen Projekten. Der Grund ist schlicht Menge: Es ist einfach mehr fremder Text im Umlauf. Ein Agent, der Kommentare, Dokumentation, Tickets und Ausgaben von Bauwerkzeugen liest, kann Anweisungen darin nicht zuverlässig von seinem Auftrag unterscheiden.

8:22 Das ist keine Schwäche eines bestimmten Produkts, sondern eine Eigenschaft der Technologie: Text ist Text. Und in einem zwanzig Jahre alten Repository liegt sehr viel Text von sehr vielen Menschen. Wichtig ist der letzte Satz der Definition: Die wirksame Verteidigung ist architektonisch, nicht sprachlich. Sie schützen sich nicht durch bessere Formulierungen, sondern durch knappere Rechte.

8:45 Vier Quellen, und die dritte ist die praktisch relevanteste. Kommentare aus zwanzig Jahren, von Personen, die niemand mehr kennt. Eingebundene Dokumentation und Ausgaben von Bauwerkzeugen. Fehlerberichte und Tickets — und in einem internen Ticketsystem können sehr viele Menschen schreiben, oft auch Externe. Das ist der Punkt: Es braucht keinen Angreifer von außen. Es genügt jemand, der irgendwo in dieser Kette Text hinterlassen kann.

9:11 Und Inhalte aus Nachbarsystemen gelangen ebenfalls in den Kontext, ohne dass es jemand als Datenfluss wahrnimmt. Fünf Maßnahmen, und die ersten drei kennen Sie schon — es sind dieselben, die auch gegen ganz gewöhnliche Fehler helfen. Knappe Rechte, kein unnötiger Netzwerkzugriff, menschliche Freigabe für alles, was nach außen wirkt.

9:31 Das ist die gute Nachricht: Sie brauchen keine eigene Verteidigungslinie gegen Injection, Sie brauchen die Stufung von vorhin. Schritt vier ist die Haltung: Fremder Text ist Daten, nicht Anweisung. Und Schritt fünf ist der praktische Umgang mit Auffälligkeiten — melden statt stillschweigend verarbeiten.

Besonders kritische Bereiche

9:50 In jedem System gibt es Bereiche, in denen strengere Regeln gelten. Und für einen von ihnen gilt eine Regel, über die ausdrücklich nicht diskutiert wird. Das sind die üblichen Verdächtigen: Anmeldung und Sitzungsverwaltung, Verschlüsselung, Rechteprüfung, alles mit Geldbezug, alles mit personenbezogenen Daten. Beim Fahrtenbuch sind das zwei Bereiche — die Berechtigungslogik, also wer welche Fahrten sehen darf, und die Abrechnung.

10:15 Es lohnt sich, diese Bereiche einmal ausdrücklich zu benennen und im Repository zu markieren. Dann muss nicht jede Person im Einzelfall entscheiden, ob eine Änderung dort besonders behandelt werden muss. Die Regeln steigern sich nach unten: keine selbstständige Änderung, Planfreigabe plus zweites Augenpaar, zusätzlich ein Vergleichstest gegen die Altfassung — das Verfahren aus Modul acht.

10:39 Und für personenbezogene Daten gilt die Datenklassifikation aus Kapitel zwei. Die Fußzeile enthält die Regel, die absolut gilt: Wer eine bestehende Prüfung entfernen will, muss ihren Ursprung kennen. Das ist der Punkt, an dem eine Diskussion endet, statt zu beginnen. Warum, sehen wir auf der nächsten Folie. Das klingt zunächst unvernünftig — eine gute Begründung soll nicht zählen? Die Logik dahinter ist aber sauber. In einem gewachsenen System hat fast jede Prüfung einen Grund.

11:08 Dieser Grund ist häufig nicht mehr dokumentiert und nicht mehr bekannt. Eine Begründung, die nur den Code betrachtet, kann ihn deshalb gar nicht kennen — sie ist notwendig unvollständig. Und weil die Wahrscheinlichkeit eines nicht mehr bekannten Grundes hoch ist, wäre jede Zustimmung eine Wette. Bei Rechteprüfungen und Geldbeträgen wetten wir nicht.

Freigaben, Audit Trail und Verantwortung

11:29 Zum Abschluss die organisatorische Klammer. Und darin ein Grundsatz, der jede Diskussion über die Verantwortung von Werkzeugen in einem Satz beendet. Freigabepflichtig ist alles, was schwer umkehrbar ist oder nach außen wirkt — das ist dieselbe Logik wie beim Blast Radius aus Modul drei. Dazu kommt der Nachweisweg, und der muss fünf Fragen beantworten können: wer, mit welchem Auftrag, unter welchen Rechten, wer hat freigegeben, was wurde geprüft.

11:56 Das klingt nach Bürokratie und ist im Ernstfall das, was Sie brauchen — wenn drei Wochen später jemand fragt, wie diese Änderung zustande kam. Links stehen die Vorgänge, rechts die Fragen — und beide Spalten gehören zusammen. Datenmigrationen, Vertrags- und Formatänderungen, neue Abhängigkeiten, Infrastruktur und jede Auslieferung: Das sind die Dinge, bei denen ein Fehler nicht durch einen Rücksprung behoben ist.

12:20 Und die Fußzeile enthält den Grundsatz, den ich angekündigt habe: Verantwortlich ist immer die Person, die freigegeben hat. Ein Agent kann Vorschläge machen und Arbeit ausführen. Er kann nicht haften, und er kann nicht wissen, was in Ihrem Unternehmen gilt. Wo diese Zurechnung unklar bleibt, ist autonome Ausführung nicht angemessen.

12:41 Der erste Punkt ist die Freigabe, die keine ist: zustimmen, ohne den Diff gelesen zu haben. Damit ist die Zurechnung formal geklärt und praktisch wertlos. Der zweite beschreibt die übliche Reihenfolge — der Nachweisweg entsteht nach dem ersten Vorfall. Der dritte ist die inhaltliche Grenze: Wo unklar ist, wer verantwortet, darf nichts autonom laufen.

13:01 Und der vierte ist ein Organisationsfehler, der sich einschleicht: Die Freigabe hängt an der Person, die gerade Zeit hat, statt an der, die den Bereich beurteilen kann.

Übung: Gestuftes Berechtigungs- und Freigabemodell

13:12 In der Übung entwerfen Sie ein vollständiges Modell für das Fahrtenbuch. Und am Schluss stellen Sie sich eine Frage, die über Papier hinausgeht. Das Modell umfasst fünf Teile: Datenklassifikation, Rechtestufen, Arbeitsumgebung, Freigabepflichten und Protokollierung. Berechtigungslogik und Abrechnung behandeln Sie ausdrücklich als besonders kritische Bereiche.

13:33 Und dann die Zusatzaufgabe, die den Bezug zur Wirklichkeit herstellt: Beschreiben Sie drei Wege, auf denen eine Prompt Injection in diesem System wirksam werden könnte — und ordnen Sie jedem die Maßnahme zu, die ihn auffängt. Sie werden merken, dass dieselben zwei, drei Maßnahmen alle drei Wege abdecken. Arbeiten Sie die fünf Schritte durch, aber reservieren Sie sich Zeit für die Schlussfrage aus der Fußzeile — sie ist der eigentliche Prüfstein.

14:00 Welcher Ihrer Punkte würde im Alltag als Erstes umgangen, und warum? Ein Modell, das den Alltag zu sehr behindert, wird nicht befolgt, sondern umgangen. Und dann haben Sie schlechtere Kontrolle als mit einer weniger strengen Regel, die tatsächlich gilt. Diese Abwägung ist unbequem und gehört zur Arbeit dazu. Im letzten Modul geht es darum, wie all das im Team verankert wird.