Geplanter Job oder menschliche Anmeldung: Welche Identität soll die API sehen?

Ein geplanter Job und eine Person an einer Anmeldeaufforderung rufen dieselbe API mit unterschiedlichen Anmeldedaten, unterschiedlichen Laufzeiten und unterschiedlichen Eigentümern auf. Der Job braucht einen Netzwerkpfad, eine Anwendungsidentität und eine Berechtigungsgruppe; die Person braucht eine Anmeldung, einen zweiten Faktor und eine Sitzung. Beides zu vermischen erzeugt eine Automatisierung, die jedes Mal bricht, wenn sich das Passwort der Person ändert, oder eine Mehrfaktorpolitik, die gerade so weit abgeschwächt wird, dass ein Cron-Job am Leben bleibt.

Drei Tore, die wie eines aussehen

Eine Quelladressregel fragt, woher die Anfrage kam. Die Authentifizierung fragt, wer anruft und welche Nachweise vorgelegt wurden. Die Autorisierung fragt, ob dieser Prinzipal diesen Vorgang ausführen darf. Ein VPN ändert nur das erste der drei und ändert es für jeden Prozess auf dem Host statt nur für den Job, deshalb halten Sie die drei Beobachtungen im Incident-Eintrag getrennt.

Deshalb kann ein Wechsel des Ausgangsknotens eine Ablehnung wegen der Quelladresse beheben und ein ungültiges Token unberührt lassen. Deshalb macht ein gültiges API-Token einen privaten Endpunkt nicht von einem Job aus erreichbar, der keine Route dorthin hat.

Der interaktive Weg ist eine schlechte Vorlage für Automatisierung

Die Anmeldung einer Person zu skripten ist verlockend, weil es einmal funktioniert. Das Skript speichert ein Passwort, vielleicht einen Einmalkennwort-Seed, und hängt dann von einer Abfrage ab, die einen Menschen erfordern soll. Die aktuelle bewährte Sicherheitspraxis für OAuth, RFC 9700, verbietet den resource-owner-password-credentials-Grant und erklärt, warum er schlecht zu Zwei-Faktor- und mehrstufiger Authentifizierung passt.

Die unterstützte Alternative ist meist ein vertraulicher Client-Flow, bei dem der Autorisierungsserver die Anwendung authentifiziert und ein Token ausstellt. Der client-credentials-Grant in RFC 6749 Abschnitt 4.4 ist ein Beispiel. Dass es ihn gibt, bedeutet nicht, dass jede API ihn akzeptiert oder dass eine vom Benutzer delegierte Aufgabe durch ihn ersetzt werden kann, denn das sind Fragen für den Diensteigentümer. Fragen Sie, welches unbeaufsichtigte Modell der Dienst unterstützt, bevor Sie Code schreiben.

Wo das VPN weiterhin hingehört

Ein VPN kann den Netzwerkpfad bereitstellen, den eine private API erfordert, und das ist eine legitime Rolle. Es authentifiziert den Job nicht gegenüber der Anwendung und begrenzt nicht, was der Job tun darf. Eine gemeinsam genutzte Ausgangsadresse identifiziert außerdem den Host statt den Job, sodass ein Allowlist-Eintrag für diese Adresse jeden Prozess zulässt, der darauf läuft.

Läuft der Job auf einem gemeinsam genutzten Runner, ist diese Unterscheidung eher wichtiger als unwichtiger. Ein anderer Workflow auf demselben Host erbt die Route und die Adresse, und die API kann die beiden nicht unterscheiden. Das ist dieselbe Schwäche wie bei einem geteilten Passwort, eine Ebene tiefer verlegt. Setzen Sie die Beschränkung dort, wo die Anwendung sie durchsetzen kann, und isolieren Sie den Runner, wenn Sie die Allowlist nicht enger fassen können.

Vergleichen Sie die beiden Entwürfe ehrlich

Eine menschliche Anmeldung gibt Ihnen eine echte Person, einen echten zweiten Faktor und eine prüfbare Sitzung, und sie kann nicht unbeaufsichtigt laufen. Eine Anwendungsidentität gibt Ihnen unbeaufsichtigte Ausführung, einen überprüfbaren Umfang und ein Anmeldedatum, das Sie rotieren können, und sie kann nicht für einen Benutzer handeln, der nichts delegiert hat. Keines ist eine schwächere Version des anderen; sie beantworten unterschiedliche Fragen. Wählen Sie, indem Sie fragen, ob die Aufgabe ohne Anwesende laufen muss und ob der Vorgang einem bestimmten Benutzer zugeordnet werden muss.

Sind beide Antworten ja, braucht der Entwurf ein Delegationsmodell statt eines geliehenen Passworts. Schreiben Sie diese Entscheidung dort auf, wo der nächste Betreuer sie findet.

Was vor der Übergabe zu prüfen ist

Führen Sie einen erlaubten Vorgang und eine erforderliche Ablehnung vom tatsächlichen Worker aus und bewahren Sie beide Ergebnisse auf. Testen Sie dann ein abgelaufenes Anmeldedatum und das Verhalten, wenn der Netzwerkpfad nicht verfügbar ist, denn das sind die beiden Fehler, die jemanden nachts wecken.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

Notieren Sie den Prinzipal, den Umfang, den Rotationsverantwortlichen und die Ausführungsumgebung neben diesem Ergebnis. Dieser Eintrag ist es, der die nächste Rotation zur Routine statt zum Incident macht. Er ist auch der Teil, nach dem ein Prüfer fragt.