Naplánovaná úloha nebo lidské přihlášení: jakou identitu má API vidět?

Naplánovaná úloha a člověk u přihlašovacího dotazu volají stejné API s jinými údaji, jinou životností a jinými vlastníky. Úloha potřebuje síťovou cestu, identitu aplikace a sadu oprávnění; člověk potřebuje přihlášení, druhý faktor a relaci. Míchání obojího vytváří automatizaci, která se rozbije pokaždé, když se změní heslo člověka, nebo politiku více faktorů oslabenou právě natolik, aby úloha cron zůstala živá.

Tři brány, které vypadají jako jedna

Pravidlo zdrojové adresy se ptá, odkud požadavek přišel. Ověřování se ptá, kdo volá a jaké důkazy byly předloženy. Autorizace se ptá, zda tento subjekt smí tuto operaci provést. VPN mění jen první ze tří a mění ji pro každý proces na hostiteli, ne jen pro úlohu, takže tři pozorování držte v záznamu o incidentu odděleně.

Proto změna výstupního uzlu může opravit odmítnutí kvůli zdrojové adrese a nechat neplatný token nedotčený. Proto také platný token API nezpřístupní soukromý koncový bod úloze, která k němu nemá trasu.

Interaktivní cesta je špatná šablona pro automatizaci

Skriptovat lidské přihlášení je lákavé, protože to jednou funguje. Skript uloží heslo, možná seed jednorázového hesla, a pak závisí na výzvě navržené tak, aby vyžadovala člověka. Nejlepší současná bezpečnostní praxe pro OAuth, RFC 9700, zakazuje grant resource-owner-password-credentials a vysvětluje, proč se špatně hodí k dvoufaktorovému a vícestupňovému ověřování.

Podporovanou alternativou je obvykle tok důvěrného klienta, v němž autorizační server ověří aplikaci a vydá token. Grant client-credentials v RFC 6749, oddíl 4.4, je jedním příkladem. Jeho existence neznamená, že ho každé API přijímá, ani že jím lze nahradit úlohu delegovanou uživatelem, protože to jsou otázky na vlastníka služby. Zeptejte se, jaký model bez dohledu služba podporuje, než napíšete jakýkoli kód.

Kde má VPN stále své místo

VPN může poskytnout síťovou cestu, kterou soukromé API vyžaduje, a to je legitimní role. Neověřuje úlohu vůči aplikaci a neurčuje rozsah toho, co úloha smí dělat. Sdílená výstupní adresa navíc identifikuje hostitele, ne úlohu, takže záznam v seznamu povolených pro tuto adresu pustí každý proces, který na něm běží.

Pokud úloha běží na sdíleném runneru, je tento rozdíl důležitější, ne méně důležitý. Jiný pracovní postup na stejném hostiteli dědí trasu i adresu a API je nedokáže rozlišit. Je to stejná slabina jako sdílené heslo, posunutá o vrstvu níž. Umístěte omezení tam, kde je aplikace může vynutit, a izolujte runner, pokud seznam povolených nedokážete zúžit.

Porovnejte oba návrhy poctivě

Lidské přihlášení vám dá skutečného člověka, skutečný druhý faktor a auditovatelnou relaci, ale nemůže běžet bez dohledu. Identita aplikace vám dá spouštění bez dohledu, přezkoumatelný rozsah a údaj, který můžete rotovat, ale nemůže jednat za uživatele, který nic nedelegoval. Ani jedno není slabší verzí druhého; odpovídají na různé otázky. Vyberte podle toho, zda úloha musí běžet bez nikoho přítomného a zda se operace musí připsat konkrétnímu uživateli.

Pokud jsou obě odpovědi ano, návrh potřebuje model delegování, ne vypůjčené heslo. Zapište to rozhodnutí tam, kde ho najde příští správce.

Co ověřit před předáním

Spusťte jednu povolenou operaci a jedno povinné odmítnutí ze skutečného workeru a oba výsledky si ponechte. Pak otestujte prošlý údaj a chování, když je síťová cesta nedostupná, protože to jsou dvě selhání, která někoho v noci probudí.

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

Zapište subjekt, rozsah, vlastníka rotace a prostředí spuštění vedle tohoto výsledku. Právě tento záznam dělá z příští rotace rutinu, a ne incident. Je to také část, kterou si vyžádá auditor.