Rejalashtirilgan ish yoki inson kiritishi: API qaysi shaxsni ko'rishi kerak?

Rejalashtirilgan ish va kirish so'rovida turgan odam bir xil API-ga turli ishonch ma'lumotlari, turli yashash muddati va turli egalari bilan murojaat qiladi. Ishga tarmoq yo'li, ilova shaxsi va ruxsatlar to'plami kerak; odamga kirish, ikkinchi omil va sessiya kerak. Ikkalasini aralashtirish odamning paroli o'zgarganda buziladigan avtomatlashtirishni yoki cron ishini tirik saqlash uchun shunchaki zaiflashtirilgan ko'p omilli siyosatni keltirib chiqaradi.

Bittaga o'xshab ko'rinadigan uch darvoza

Manba manzili qoidasi so'rov qayerdan kelganini so'raydi. Autentifikatsiya kim qo'ng'iroq qilayotganini va qanday dalillar taqdim etilganini so'raydi. Avtorizatsiya bu subyekt bu operatsiyani bajara oladimi, deb so'raydi. VPN uchtadan faqat birinchisini o'zgartiradi va uni ish uchun emas, xostdagi har bir jarayon uchun o'zgartiradi, shuning uchun voqea yozuvida uchta kuzatuvni alohida saqlang.

Shuning uchun chiqish tugunini o'zgartirish manba manzili sababli rad etishni tuzatishi va yaroqsiz tokenga tegmasligi mumkin. Shuning uchun ham haqiqiy API tokeni u yerga yo'li yo'q ishdan xususiy so'nggi nuqtaga yetish imkonini bermaydi.

Interaktiv yo'l avtomatlashtirish uchun yomon shablon

Odamning kirishini skriptga aylantirish jozibador, chunki u bir marta ishlaydi. Skript parolni, ehtimol bir martalik parol urug'ini saqlaydi va keyin odam talab qilinadigan tarzda yaratilgan chaqiruvga bog'lanadi. OAuth uchun amaldagi eng yaxshi xavfsizlik amaliyoti, RFC 9700, resource-owner-password-credentials grantini taqiqlaydi va nima uchun u ikki omilli va ko'p bosqichli autentifikatsiyaga yomon mos kelishini tushuntiradi.

Qo'llab-quvvatlanadigan muqobil odatda maxfiy mijoz oqimi bo'lib, unda avtorizatsiya serveri ilovani autentifikatsiya qiladi va token beradi. RFC 6749 ning 4.4 bo'limidagi client-credentials granti bunga bir misol. Uning mavjudligi har bir API uni qabul qiladi yoki foydalanuvchi vakolat bergan vazifani u bilan almashtirish mumkin degani emas, chunki bular xizmat egasiga beriladigan savollar. Kod yozishdan oldin xizmat qanday nazoratsiz modelni qo'llab-quvvatlashini so'rang.

VPN hali ham qayerda o'rinli

VPN xususiy API talab qiladigan tarmoq yo'lini taqdim etishi mumkin va bu qonuniy rol. U ishni ilova oldida autentifikatsiya qilmaydi va ish nima qilishi mumkinligini cheklamaydi. Umumiy chiqish manzili ham ishni emas, xostni aniqlaydi, shuning uchun o'sha manzil uchun ruxsat ro'yxatidagi yozuv unda ishlaydigan har bir jarayonni o'tkazadi.

Agar ish umumiy runnerda ishlasa, bu farq kamroq emas, balki muhimroq. Xuddi shu xostdagi boshqa ish oqimi marshrut va manzilni meros oladi va API ikkalasini ajrata olmaydi. Bu umumiy parol bilan bir xil zaiflik, bir qatlam pastga ko'chirilgan. Cheklovni ilova qo'llay oladigan joyga qo'ying va ruxsat ro'yxatini yanada toraytira olmasangiz, runnerni izolyatsiya qiling.

Ikki dizaynni halol solishtiring

Inson kiritishi sizga haqiqiy odam, haqiqiy ikkinchi omil va tekshiriladigan sessiya beradi va nazoratsiz ishlay olmaydi. Ilova shaxsi sizga nazoratsiz bajarish, ko'rib chiqiladigan qamrov va aylantira oladigan ishonch ma'lumotini beradi va hech narsa vakolat bermagan foydalanuvchi nomidan harakat qila olmaydi. Hech biri boshqasining zaifroq versiyasi emas; ular turli savollarga javob beradi. Vazifa hech kim yo'qligida ishlashi kerakmi va operatsiya muayyan foydalanuvchiga tegishli bo'lishi kerakmi, deb so'rab tanlang.

Agar ikkala javob ham ha bo'lsa, dizaynga qarzga olingan parol emas, vakolat berish modeli kerak. Bu qarorni keyingi xizmatchi topadigan joyga yozing.

Topshirishdan oldin nimani tekshirish kerak

Haqiqiy ishchidan bitta ruxsat etilgan operatsiyani va bitta majburiy rad etishni ishga tushiring va ikkala natijani saqlang. Keyin muddati o'tgan ishonch ma'lumotini va tarmoq yo'li mavjud bo'lmaganda xatti-harakatni sinab ko'ring, chunki tunda kimnidir uyg'otadigan ikki nosozlik shular.

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

Subyekt, qamrov, aylantirish egasi va bajarish muhitini o'sha natija yoniga yozib qo'ying. Aynan o'sha yozuv keyingi aylantirishni voqea emas, odatiy ishga aylantiradi. Auditor so'raydigan qism ham o'sha.