Ein Mehrprotokoll-Integrationsgateway ändern und prüfen, ohne Zugriffsprüfungen zu brechen

## Die nächstgelegenen Anweisungen finden und bei Widersprüchen dem laufenden Code folgen Beginne mit den projektweiten Vorgaben und suche anschließend die bereichsspezifischen Anweisungen, die den zu ändernden Dateien am nächsten liegen. Tests, Erweiterungen, Bereitstellungsvorlagen, Dokumentation, Protokollserver und leistungskritische Laufzeitumgebungen können jeweils eigene Arbeitsabläufe haben. Übertrage die Regeln eines Bereichs nicht ohne Beleg auf einen anderen. Unterscheide Hinweise für Codebeiträge von Laufzeitanweisungen für Endnutzende. Material für ein Modell oder einen Client, der das bereitgestellte System nutzt, regelt nicht automatisch die Arbeit von Agenten, die den Quellcode ändern. Erfasse vor der Bearbeitung den Systemaufbau: - Anwendungseinstiegspunkte und Umgebungskonfiguration. - Validierungsschemata, Persistenzmodelle und Migrationen. - Fachdienste, Routen, Vermittlungsschichten und Protokolltransporte. - Authentifizierung, Autorisierung, Erweiterungen und Föderationsgrenzen. - Tests, Dokumentation, Bereitstellungsressourcen und Verwaltungsoberflächen. Wenn Quellen einander widersprechen, bevorzuge zuerst den tatsächlich ausgeführten Code und die maßgebliche Konfiguration, danach unterstützte Erstellungsziele und Abhängigkeiten, anschließend Umgebungsbeispiele und zuletzt Dokumentation oder Kommentare. Prüfe die aktuelle Implementierung, bevor du Zahlenangaben oder Betriebsgrenzen wiederholst, die veralten können. Untersuche zuerst aktive Quellcodepfade. Ignoriere vorläufige Arbeitsbereiche, Protokolle, Ergebnisse der Testabdeckung, erzeugte Artefakte und Ordner für zurückgestellte Aufgaben, sofern die Anfrage sie nicht ausdrücklich einschließt. ## Nach jeder Änderung die Projektprüfungen und die Erkennung geheimer Daten ausführen Verwende die vom Projekt unterstützte Aufgabensteuerung und die versionsgebundene Werkzeugkette, statt darunterliegende Werkzeuge mit spontan gewählten Optionen aufzurufen. Vergleiche die Entwicklungsumgebung mit dem maßgeblichen Beispiel, führe erforderliche Vorbereitungs- oder Schnittstellenerzeugungsschritte aus und wähle den zur Aufgabe passenden lokalen Server- oder Prüfmodus. Nach einer Codeänderung: 1. Führe Formatierungs-, Lint-, Typ-, Sicherheits- und Dokumentationsprüfungen aus, die die geänderte Sprache und die betroffenen Dateien direkt abdecken. 2. Nutze während der Bearbeitung gezielte Prüfungen und führe vor einer Fertigmeldung die vom Projekt verlangte zusammengefasste Qualitätsprüfung aus. 3. Führe für eine zusätzliche systemnahe Sprache oder eine Hochleistungslaufzeit deren Formatprüfung, die statische Prüfung mit Warnungen als Fehlern sowie Crate- oder Pakettests aus. 4. Erzeuge Verwaltungs- oder Clientressourcen erneut, wenn sich deren Quellen ändern. 5. Ergänze für jede von außen sichtbare Änderung Verhaltenstests. Nutze die Erkennung geheimer Daten als Prüfschranke. Verwende bei einem bestätigten Fehlalarm die vom Projekt erlaubte Unterdrückung in derselben Zeile nur dort, wo sie das Verhalten eines Tests oder Beispiels nicht verändern kann. Erzeuge andernfalls die freigegebene Vergleichsbasis neu und prüfe sie. Unterdrücke niemals echte Zugangsdaten und schreibe keine Geheimnisse in eingecheckte Konfigurationen. Erweitere vorzugsweise die vorhandene Sprache sowie die bestehenden Erstellungs- und Automatisierungswerkzeuge. Füge eine Abhängigkeit oder eine neue Werkzeugkette nur hinzu, wenn eine konkrete Anforderung mit den vorhandenen Mitteln nicht sicher erfüllt werden kann. ## Getrennt prüfen, was eine Identität sehen und was sie tun darf, und Routen ohne Regel ablehnen Erhalte auf jedem geschützten Pfad zwei voneinander unabhängige Sicherheitsebenen: - Die Bereichsfilterung bestimmt, welche Ressourcen eine Identität sehen kann. - Die rollenbasierte Autorisierung bestimmt, welche Aktionen diese Identität ausführen darf. Das Bestehen einer Ebene ersetzt niemals die andere. Behandle einen plattformöffentlichen Bereich als Sichtbarkeit innerhalb der Plattform und nicht als Erlaubnis für anonymen Zugriff aus dem Internet. Normalisiere jede Tokenklasse mit genau einer maßgeblichen Richtlinienfunktion. Bei eigenständigen oder älteren API-Token muss ein fehlender oder leerer Teambereich sicher geschlossen werden und die Sichtbarkeit auf den öffentlichen Bereich beschränken. Eine Ausnahme für Administratoren erfordert sowohl einen ausdrücklichen Ausnahmezustand als auch einen bestätigten Administratorstatus. Bei sitzungsgebundenen Identitäten sind die serverseitig gespeicherte Mitgliedschaft und der Administratorstatus maßgeblich; Angaben im Token dürfen den Zugriff nur einschränken. Eine leere Schnittmenge muss sicher geschlossen werden. Identitäten aus einer vertrauenswürdigen externen Anmeldung müssen ebenfalls den gespeicherten lokalen Autorisierungsstatus verwenden, statt externen Privilegienangaben zu vertrauen. Wende folgende unveränderlichen Regeln an: - Authentifiziere, bevor du eine Transportsitzung aufbaust oder eine Nachricht weiterleitest, und prüfe anschließend die Aktionsberechtigung, bevor du die Aktion verarbeitest. - Lehne geschützte Routen ohne ausdrückliche Autorisierungszuordnung standardmäßig ab. - Leite Eigentümerschaft, Team und Sitzungsidentität aus dem authentifizierten serverseitigen Zustand ab; vertraue niemals vom Client gelieferten Eigentümerfeldern. - Nimm eingehende Clientzugangsdaten niemals über URL-Abfrageparameter an. - Halte risikoreiche Transporte und uneingeschränkte domänenübergreifende Weiterleitung standardmäßig abgeschaltet. - Verlange für gatewayübergreifenden Verkehr eine ausdrückliche Domänenzulassungsliste; eine leere Liste sperrt alle Ziele. - Verlange, dass miteinander kommunizierende Gateways demselben Aussteller vertrauen, und übermittle nur die für die entfernte Autorisierung nötigen Zugangsdaten. Leite beim delegierten Tokenaustausch das eingehende Token einer Person niemals an den nachgelagerten Dienst weiter. Tausche es über einen vertrauenswürdigen Autorisierungsserver aus und leite ausschließlich das eingetauschte Token weiter. Behandle das konfigurierte Austauschziel als SSRF-Grenze und Grenze für ausgehende Verbindungen: Prüfe es beim Speichern der Konfiguration, beschränke Änderungen auf privilegierte Identitäten, protokolliere eine Korrelationskennung und zeichne niemals unverarbeitete eingehende oder eingetauschte Token auf. Sicherheitsrelevante Änderungen müssen Regressionstests für nicht authentifizierten Zugriff, falsche Bereiche, unzureichende Berechtigungen, abgeschaltete Funktionen, unzulässige Ziele und weitere Ablehnungspfade enthalten. ## Trace- und Audit-Schreibvorgänge von der Haupttransaktion getrennt halten Verstehe die beabsichtigte Transaktionsgrenze, bevor du Persistenzcode änderst. Anfragedaten, Beobachtbarkeitsaufzeichnungen und Prüfprotokolle können absichtlich unterschiedliche Sitzungen und Atomaritätsgarantien verwenden. Nicht garantierte Beobachtbarkeitsschreibvorgänge können kurzlebige unabhängige Sitzungen verwenden, die sofort festschreiben. Dadurch bleiben Ablaufspuren und Ereignisse erhalten, wenn die Hauptanfrage fehlschlägt. Die Telemetrie ist dann jedoch nicht atomar mit der Anfrage und kann teilweise oder noch laufende Zustände zeigen. Abfragen sollten weiterhin anfragegebundene Sitzungen verwenden, damit Sichtbarkeits- und Autorisierungsfilter angewendet werden. Auch die Prüfprotokollierung kann eine eigene Sitzung besitzen und ihre Fehler isolieren. Übergib die bereits festgeschriebene Sitzung der Anfrage nicht nur der Bequemlichkeit halber an einen unabhängigen Prüfprotokollschreiber. Ein zweites Festschreiben oder Zurücksetzen kann die gemeinsame Transaktion inaktiv machen und einen Fehler sichtbar werden lassen, nachdem die Hauptressource bereits gespeichert wurde. Muss ein Prüfprotokolleintrag atomar mit dem Hauptschreibvorgang sein, behandle dies als ausdrückliche Entwurfsänderung, die eine Prüfung, neue Fehlersemantik und Tests erfordert. Unabhängige Ablaufverfolgung kann pro Anfrage mehrere Datenbanksitzungen erzeugen. Miss die Gleichzeitigkeit, überwache Anzeichen für einen erschöpften Verbindungspool und bemesse den Pool nach der tatsächlichen Datenbank und Last, statt feste Kapazitätsangaben zu übernehmen. Stufe eine absichtlich synchrone Persistenzstrategie innerhalb asynchroner Verarbeitung nicht ohne Beleg als einzelnen Fehler ein. Die Umstellung einzelner Aufrufstellen kann gemischte Semantik erzeugen; schlage stattdessen eine abgestimmte Migration des Datenbanktreibers und der Transaktionen vor. ## Vor einer neuen Datenbankmigration den aktuellen Migrations-Head prüfen Frage vor dem Erstellen einer Migration den aktuellen Migrations-Head ab. Der Vorgänger der neuen Revision muss auf diesen geprüften Head verweisen; rate niemals und kopiere keine Vorgängerkennung aus einer älteren Datei. Prüfe danach, dass der Verlauf weiterhin genau einen beabsichtigten Head besitzt. Schreibe idempotente Migrationsschritte, wenn Installationen voneinander abweichen können. Untersuche das aktuelle Schema vor einer Änderung, überspringe einen Schritt sicher, wenn eine optionale Tabelle fehlt, und füge keine bereits vorhandene Spalte oder kein vorhandenes Objekt erneut hinzu. Halte die Pfade zur Neuerstellung und zur Aktualisierung einer Datenbank konsistent. Wenn eine Rückwärtsmigration von der Laufzeitkonfiguration abhängt, gestalte sie umgebungsunabhängig und reproduzierbar: 1. Speichere während der Vorwärtsmigration jeden benötigten Konfigurationswert in revisionsbezogenen Metadaten, die der Migration gehören. 2. Lies während der Rückwärtsmigration das gespeicherte Abbild statt der aktuellen Umgebung. 3. Nutze die laufende Konfiguration nur als dokumentierte Kompatibilitätsausweichlösung für Datenbanken, die vor Einführung der Abbilder aktualisiert wurden. 4. Entferne das Abbild nach Abschluss der Rückwärtsmigration. Eine Migration, die Konfiguration nur zum Einfügen von Ausgangsdaten während der Vorwärtsmigration liest, benötigt kein Abbild für die Rückwärtsmigration, sofern diese nicht ebenfalls von dem Wert abhängt. Prüfe den Head nach der Bearbeitung erneut und führe die zugehörigen Migrations- und Anwendungstests aus. Liegt die Zieldatenbank zurück, bringe die kontrollierte Entwicklungs- oder Testdatenbank auf den erwarteten Head, bevor du eine neue Revision erzeugst. Führe diese korrigierende Vorwärtsmigration niemals ohne ausdrückliche Genehmigung und einen geprüften Plan in der Produktionsumgebung aus. ## Echte Prüfergebnisse bestätigen und vor einem Push die Freigabe einholen Vergleiche die endgültigen Änderungen mit der ursprünglichen Anfrage, den nächstgelegenen Bereichsvorgaben und den obigen Sicherheitsregeln. Bestätige, soweit zutreffend, die tatsächlichen Ergebnisse von Lint- und Typprüfungen, Sicherheitsanalysen, Tests, Migrationen, erzeugten Ressourcen und der Dokumentation. Behaupte Erfolg nicht allein aufgrund einer Sichtprüfung. Verwende die vom Projekt verlangte Konvention für Änderungseinträge, die Signaturrichtlinie, Verknüpfungen zu Vorgängen und die Vorlage für Zusammenführungsanträge. Führe ohne ausdrückliche Genehmigung weder push noch force-push aus, ändere keinen fremden Beitragszweig und verändere keinen externen Projektzustand. Für öffentliche Codeprüfungen und Vorgangskommentare: - Nenne zuerst, was funktioniert, bevor du Bedenken ansprichst. - Trenne blockierende Befunde, Vorschläge und kleinere Hinweise. - Erkläre das Risiko und biete Fragen oder Möglichkeiten an, statt unnötige Anweisungen zu erteilen. - Formuliere direkt, ohne schroff oder maschinenhaft zu wirken. Füge Produktänderungen oder öffentlichen Nachrichten keine interne Assistentenzuschreibung, verborgenen Betriebskommentare, Zugangsdaten oder spekulativen Aufwandsschätzungen hinzu. Erstelle neue Dateien oder Dokumentation nur, wenn die Änderung sie tatsächlich erfordert. Unterscheide bei der Arbeitseinordnung zwischen einer Anfrage, die auf Angaben der meldenden Person wartet, einer Abhängigkeitssperre und einem angenommenen, aber zurückgestellten Punkt. Markiere einen Vorgang erst dann als gelöst, wenn die behebende Änderung zusammengeführt wurde, nicht schon nach einer rein lokalen Umsetzung. Prüfe vor dem Abschluss, dass vertrauliche Werte außerhalb der Versionsverwaltung bleiben, Ablehnungspfade der Sicherheit getestet sind, die Rangfolge der maßgeblichen Quellen eingehalten wurde und keine unbeteiligten vorläufigen Inhalte in die Änderungen gelangt sind.