Naplánovaná úloha alebo ľudské prihlásenie: akú identitu má API vidieť?

Naplánovaná úloha a človek pri prihlasovacej výzve volajú to isté API s inými údajmi, inou životnosťou a inými vlastníkmi. Úloha potrebuje sieťovú cestu, identitu aplikácie a súbor oprávnení; človek potrebuje prihlásenie, druhý faktor a reláciu. Miešanie oboch vytvára automatizáciu, ktorá sa pokazí vždy, keď sa zmení heslo človeka, alebo politiku viacerých faktorov oslabenú presne natoľko, aby úloha cron zostala živá.

Tri brány, ktoré vyzerajú ako jedna

Pravidlo zdrojovej adresy sa pýta, odkiaľ požiadavka prišla. Overovanie sa pýta, kto volá a aké dôkazy boli predložené. Autorizácia sa pýta, či tento subjekt smie vykonať túto operáciu. VPN mení iba prvú z troch a mení ju pre každý proces na hostiteľovi, nielen pre úlohu, preto tri pozorovania držte v zázname o incidente oddelene.

Preto zmena výstupného uzla môže opraviť odmietnutie pre zdrojovú adresu a nechať neplatný token nedotknutý. Preto ani platný token API nesprístupní súkromný koncový bod úlohe, ktorá k nemu nemá trasu.

Interaktívna cesta je zlým vzorom pre automatizáciu

Skriptovanie ľudského prihlásenia je lákavé, pretože to raz funguje. Skript uloží heslo, možno semienko jednorazového hesla, a potom závisí od výzvy navrhnutej tak, aby vyžadovala človeka. Najlepšia súčasná bezpečnostná prax pre OAuth, RFC 9700, zakazuje grant resource-owner-password-credentials a vysvetľuje, prečo sa zle hodí k dvojfaktorovému a viacstupňovému overovaniu.

Podporovanou alternatívou je zvyčajne tok dôverného klienta, v ktorom autorizačný server overí aplikáciu a vydá token. Grant client-credentials v RFC 6749, oddiel 4.4, je jedným príkladom. Jeho existencia neznamená, že ho každé API prijíma, ani že ním možno nahradiť úlohu delegovanú používateľom, pretože to sú otázky na vlastníka služby. Opýtajte sa, ktorý model bez dohľadu služba podporuje, kým napíšete kód.

Kde má VPN stále miesto

VPN môže poskytnúť sieťovú cestu, ktorú súkromné API vyžaduje, a to je legitímna rola. Neoveruje úlohu voči aplikácii a neurčuje, čo úloha smie robiť. Zdieľaná výstupná adresa tiež identifikuje hostiteľa, nie úlohu, takže záznam v zozname povolených pre túto adresu pustí každý proces, ktorý na nej beží.

Ak úloha beží na zdieľanom runneri, tento rozdiel je dôležitejší, nie menej dôležitý. Iný pracovný postup na tom istom hostiteľovi dedí trasu aj adresu a API ich nedokáže rozlíšiť. Je to tá istá slabina ako zdieľané heslo, posunutá o vrstvu nižšie. Umiestnite obmedzenie tam, kde ho aplikácia môže presadiť, a izolujte runner, ak zoznam povolených nedokážete zúžiť.

Porovnajte oba návrhy úprimne

Ľudské prihlásenie vám dá skutočného človeka, skutočný druhý faktor a auditovateľnú reláciu, ale nemôže bežať bez dohľadu. Identita aplikácie vám dá spúšťanie bez dohľadu, preskúmateľný rozsah a údaj, ktorý môžete rotovať, ale nemôže konať za používateľa, ktorý nič nedelegoval. Ani jedno nie je slabšou verziou druhého; odpovedajú na rôzne otázky. Vyberte podľa toho, či úloha musí bežať bez nikoho prítomného a či sa operácia musí pripísať konkrétnemu používateľovi.

Ak sú obe odpovede áno, návrh potrebuje model delegovania, nie požičané heslo. Zapíšte to rozhodnutie tam, kde ho nájde ďalší správca.

Čo overiť pred odovzdaním

Spustite jednu povolenú operáciu a jedno povinné odmietnutie zo skutočného workera a oba výsledky si ponechajte. Potom otestujte expirovaný údaj a správanie, keď je sieťová cesta nedostupná, pretože to sú dve zlyhania, ktoré niekoho v noci zobudia.

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

Zapíšte subjekt, rozsah, vlastníka rotácie a prostredie spustenia vedľa tohto výsledku. Práve tento záznam robí z ďalšej rotácie rutinu a nie incident. Je to aj časť, ktorú si vyžiada audítor.