Ütemezett feladat vagy emberi bejelentkezés: melyik identitást lássa az API?

Egy ütemezett feladat és egy ember a bejelentkezési kérésnél ugyanazt az API-t hívja különböző hitelesítő adatokkal, különböző élettartammal és különböző tulajdonosokkal. A feladatnak hálózati útvonalra, alkalmazásidentitásra és engedélykészletre van szüksége; az embernek bejelentkezésre, második tényezőre és munkamenetre. A kettő keverése olyan automatizálást eredményez, amely minden alkalommal eltörik, amikor az ember jelszava megváltozik, vagy olyan többtényezős szabályzatot, amelyet éppen annyira gyengítettek, hogy egy cron-feladat életben maradjon.

Három kapu, amely egynek látszik

A forrás-cím szabálya azt kérdezi, honnan jött a kérés. A hitelesítés azt kérdezi, ki hív és milyen bizonyítékokat mutattak be. Az engedélyezés azt kérdezi, végrehajthatja-e ez a principal ezt a műveletet. A VPN csak az elsőt változtatja meg a három közül, és minden folyamatra megváltoztatja a gazdagépen, nem csak a feladatra, ezért tartsa külön a három megfigyelést az incidensjegyzőkönyvben.

Ezért javíthatja meg a kilépési csomópont cseréje a forrás-cím miatti elutasítást, és hagyhatja érintetlenül az érvénytelen tokent. Ezért nem teszi elérhetővé egy érvényes API-token a privát végpontot olyan feladatból, amelynek nincs oda útvonala.

Az interaktív útvonal rossz automatizálási sablon

Egy ember bejelentkezésének szkriptelése csábító, mert egyszer működik. A szkript eltárol egy jelszót, esetleg egy egyszeri jelszó magját, majd olyan kihívástól függ, amelyet ember igénylésére terveztek. Az OAuth jelenlegi legjobb biztonsági gyakorlata, az RFC 9700 tiltja a resource-owner-password-credentials engedélyezést, és elmagyarázza, miért illik rosszul a kétfaktoros és többlépéses hitelesítéshez.

A támogatott alternatíva általában bizalmas kliens folyamat, amelyben az engedélyezési kiszolgáló hitelesíti az alkalmazást és tokent ad ki. Az RFC 6749 4.4 szakaszának client-credentials engedélyezése erre egy példa. Létezése nem jelenti azt, hogy minden API elfogadja, sem azt, hogy egy felhasználó által delegált feladat helyettesíthető vele, mert ezek a szolgáltatás tulajdonosának kérdései. Kérdezze meg, milyen felügyelet nélküli modellt támogat a szolgáltatás, mielőtt kódot ír.

Hol van még helye a VPN-nek

A VPN biztosíthatja a hálózati útvonalat, amelyet egy privát API megkövetel, és ez jogos szerep. Nem hitelesíti a feladatot az alkalmazás felé, és nem határolja be, mit tehet a feladat. A megosztott kilépési cím is a gazdagépet azonosítja, nem a feladatot, ezért az arra a címre vonatkozó engedélylistabejegyzés minden ott futó folyamatot beenged.

Ha a feladat megosztott futtatón fut, ez a különbség inkább fontosabb, mint kevésbé fontos. Egy másik munkafolyamat ugyanazon a gazdagépen örökli az útvonalat és a címet, és az API nem tudja megkülönböztetni a kettőt. Ez ugyanaz a gyengeség, mint a megosztott jelszó, egy szinttel lejjebb tolva. Helyezze a korlátozást oda, ahol az alkalmazás kikényszerítheti, és izolálja a futtatót, ha nem tudja szűkíteni az engedélylistát.

Hasonlítsa össze a két tervet őszintén

Az emberi bejelentkezés valódi embert, valódi második tényezőt és auditálható munkamenetet ad, és nem tud felügyelet nélkül futni. Az alkalmazásidentitás felügyelet nélküli végrehajtást, áttekinthető hatókört és forgatható hitelesítő adatot ad, és nem tud olyan felhasználó nevében eljárni, aki semmit nem delegált. Egyik sem a másik gyengébb változata; különböző kérdésekre válaszolnak. Válasszon úgy, hogy megkérdezi, kell-e a feladatnak bárki jelenléte nélkül futnia, és a műveletet egy adott felhasználóhoz kell-e rendelni.

Ha mindkét válasz igen, a tervnek delegálási modellre van szüksége, nem kölcsönkért jelszóra. Írja le ezt a döntést ott, ahol a következő karbantartó megtalálja.

Mit kell ellenőrizni az átadás előtt

Futtasson egy engedélyezett műveletet és egy kötelező elutasítást a tényleges munkavégzőből, és mindkét eredményt őrizze meg. Ezután tesztelje a lejárt hitelesítő adatot és a viselkedést, amikor a hálózati útvonal nem elérhető, mert ez a két hiba az, amely éjjel felébreszt valakit.

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

Jegyezze fel a principalt, a hatókört, a forgatás tulajdonosát és a végrehajtási környezetet az eredmény mellé. Ez a feljegyzés teszi a következő forgatást rutinná, nem incidenssé. Ez az a rész is, amelyet egy auditor kér.