Sechs Entscheidungen für einen Zugriffsvertrag von der Cloud zum Backend

Nehmen Sie einen Reporting-Dienst in einem Cloud-Konto, der freigegebene Zusammenfassungen aus einem internen System eines Kunden benötigt. Ein VPN oder eine authentifizierte Anwendungsverbindung schützt den Weg und entscheidet nichts weiter. Sie entscheidet nicht, ob die Reporting-Workload fremde Datensätze lesen, das Backend verändern oder das Abgerufene behalten darf. Schreiben Sie die Zugriffsvereinbarung in Begriffen von Operationen und Daten, bevor Sie den Connector wählen, denn der Connector ist der billigste Teil, um ihn später zu ändern, und der leichteste, um ihn zuerst falsch zu machen.

Entscheiden Sie die Operationen vor dem Connector

Die erste Entscheidung ist, was die Workload tun darf, benannt als Operationen statt als Netzbereich. Im Reporting-Fall kann eine schmale Reporting-API den Bedarf decken, ohne einer Cloud-Workload Datenbankadministration zu gewähren.

Trennen Sie Daten, die der Bericht braucht, von Daten, die nur zufällig erreichbar sind. Schreiben Sie die erlaubten Operationen als Endpunkte und Verben in dasselbe Dokument wie die Identitätsentscheidung. Dieser Unterschied ist der Unterschied zwischen einer Integration, die ein Audit übersteht, und einer, die jedes Jahr neu erklärt werden muss, und er klärt später Streitigkeiten ohne ein weiteres Meeting.

Entscheiden Sie die Workload-Identität und geben Sie ihr einen Eigentümer

Unbeaufsichtigte Jobs können keinen Prompt beantworten, deshalb greifen Teams zum breiten Konto einer Person und vergessen es dann. Verwenden Sie ein Dienstkonto oder eine Maschinenanmeldeinformation, die das Backend tatsächlich akzeptiert, und halten Sie fest, wem sie gehört, wo sie gespeichert ist und wie sie rotiert wird.

Drei Bedingungen sollten die Entscheidung zu einer dedizierten Identität kippen: Der Job läuft ohne anwesenden Menschen, die Anmeldeinformation überlebt ein einzelnes Deployment, und mehr als eine Person muss von ihrer Existenz wissen. Sind alle drei wahr, ist ein geteiltes menschliches Konto keine Abkürzung, sondern eine dauerhafte Ausnahme, die niemand sauber widerrufen kann.

Bevorzugen Sie eine Anmeldeinformation, die die Plattform für die Workload ausstellen und rotieren kann, etwa ein Workload-Identitätstoken, das das Backend validiert, gegenüber einem statischen Geheimnis, das in die Konfiguration geklebt wird. Statische Geheimnisse in Anwendungseinstellungen sind der Grund, warum Rotationen zu Ausfällen werden.

Entscheiden Sie den Netzumfang, im Wissen, dass er keine Berechtigung ist

Legen Sie fest, welche Seite die Verbindung aufbaut, den unterstützten Transport und die beteiligten Endpunkte. Lassen Sie Peer-Identitätsprüfungen eingeschaltet und lassen Sie unbezogene Backend-Ziele unerreichbar statt nur unangekündigt.

Eine schmale Tunnelroute ist nützlicher Umfang, aber sie kann die Autorisierung auf Operationsebene nicht ersetzen. Das Backend muss den Vertrag durch seine eigenen Kontrollen durchsetzen, denn das Netz befördert bereitwillig jede Anfrage, die einen erreichbaren Port erreicht. Prüfen Sie die eigenen Rollen und Berechtigungen des Backends statt die Routentabelle. Eine Route, die den Server erreicht, lässt die Entscheidung dennoch beim Server, und dort wird der Vertrag entweder durchgesetzt oder ignoriert.

Das Spiegelbild gilt ebenso: Eine gültige Dienstanmeldeinformation rechtfertigt nicht, einen Listener für jede Quelle zu veröffentlichen. Beide Kontrollen sind nötig, und keine ersetzt die andere.

Entscheiden Sie die Datenbehandlung und die Aufteilung der Verantwortung

Halten Sie fest, was die Kundenumgebung verlässt, wo die Anwendung es verarbeitet, und die tatsächlichen Regelungen zu Speicherung, Sicherung, Zugriff und Aufbewahrung. Die Aufbewahrung ist der Teil, der spät entdeckt wird, meist wenn jemand fragt, ob die Kopie vom letzten Quartal noch in einem Bucket liegt, den niemand dokumentiert hat.

Halten Sie die Parteien getrennt. Der Anwendungsbetreiber, der Softwarelieferant und der Infrastruktur-Host können unterschiedliche Verantwortlichkeiten tragen, und das Servicemodell bestimmt, wer welche hat. Lesen Sie die tatsächliche Vereinbarung, statt anzunehmen, alle drei hätten identischen Zugriff oder gar keinen.

Entscheiden Sie Ausfall, Rückbau und wie Sie ihn abnehmen

Weisen Sie die Verantwortung für die Ausfallfälle zu, bevor sie eintreten. Wenn der Connector bricht oder eine Identität als kompromittiert gilt, sollte die Reaktion keine improvisierte unbeschränkte Netzausnahme sein, die den Vorfall überlebt.

Der Rückbau verdient dieselbe Präzision wie die Einrichtung. Definieren Sie, wie die Autorisierung widerrufen wird, wie aktiver Zugriff im Rahmen des unterstützten Produktverhaltens endet und was mit aufbewahrten Kopien geschieht, wenn die Beziehung endet.

Nehmen Sie die Integration mit repräsentativen erlaubten Operationen und den vom Vertrag geforderten Ablehnungen ab, alles unter der vorgesehenen Workload-Identität. Bestätigen Sie den Anfrageweg und die tatsächlich gelieferten Daten, und üben Sie dann den Austausch von Anmeldeinformationen und den Rückbau im Ernstfall. Ein verbundener Tunnel beweist, dass ein Weg existiert; der Vertrag ist das, was diesem Weg eine Grenze gibt.