Warum der Default-Fall kritisch ist
Bei Routing-Änderungen in Integrationsprofilen ist die wichtigste Sicherheitsentscheidung oft der Default-Fall. Sobald ein unbekannter Schlüssel automatisch in einen Test- oder Standardpfad fällt, entstehen unkontrollierte Seiteneffekte.
Ein belastbares Modell arbeitet mit expliziter Whitelist und einem fail-closed Default. Nur definierte Einträge dürfen senden, alle nicht gemappten oder fehlerhaften Schlüssel bleiben konsequent auf OFF.
Fail-Closed Routingmodell
{
"routingKey": "carrier_x",
"whitelist": ["carrier_a", "carrier_b", "carrier_c"],
"targetEnvironment": "OFF",
"gates": {
"testSend": false,
"prodSend": false
}
}
Technisch sinnvoll ist eine zentrale Zielvariable, aus der die konkreten Boolean-Gates für Test und Produktivpfad abgeleitet werden. So bleibt die Routing-Entscheidung an einer Stelle nachvollziehbar.
Wichtig ist, die Gates direkt an den relevanten Sendeknoten zu setzen, nicht nur an späteren Hilfsfeldern. Nur so wird verhindert, dass Teilpfade trotz falscher Entscheidung anlaufen.
Das Ergebnis ist ein steuerbares, reviewfähiges Routingmodell mit klarer Freigabelogik statt implizitem Verhalten.