Planlı iş və ya insan girişi: API hansı kimliyi görməlidir?

Planlı iş və giriş ekranında dayanan insan eyni API-ni fərqli etimadnamələr, fərqli ömürlər və fərqli sahiblərlə çağırır. İşə şəbəkə yolu, tətbiq kimliyi və icazə dəsti lazımdır; insana isə giriş, ikinci amil və sessiya lazımdır. İkisini qarışdırmaq, insanın parolu dəyişdikcə pozulan avtomatlaşdırma və ya cron işini saxlamaq üçün kifayət qədər zəiflədilmiş çoxamilli siyasət yaradır.

Bir kimi görünən üç qapı

Mənbə ünvanı qaydası sorğunun haradan gəldiyini soruşur. Autentifikasiya kimin zəng etdiyini və hansı sübutların təqdim edildiyini soruşur. Avtorizasiya isə bu subyektin bu əməliyyatı yerinə yetirə biləcəyini soruşur. VPN yalnız üçün birincisini dəyişir və bunu tək iş üçün deyil, hostdakı hər proses üçün dəyişir, ona görə insident qeydində üç müşahidəni ayrı saxlayın.

Buna görə çıxış qovşağını dəyişmək mənbə ünvanına görə rədd cavabını düzəldə, etibarsız tokeni isə toxunulmaz qoya bilər. Buna görə də etibarlı API tokeni, ona yol olmayan iş üçün özəl son nöqtəni əlçatan etmir.

İnteraktiv yol zəif avtomatlaşdırma şablonudur

İnsanın girişini skriptləşdirmək cazibədardır, çünki bir dəfə işləyir. Skript parolu, bəlkə də birdəfəlik parol toxumunu saxlayır və sonra insan tələb etmək üçün qurulmuş çağırışdan asılı qalır. OAuth təhlükəsizliyi üzrə mövcud ən yaxşı təcrübə, RFC 9700, resource-owner-password-credentials qrantını qadağan edir və onun iki amilli və çoxaddımlı autentifikasiyaya niyə zəif uyğun gəldiyini izah edir.

Dəstəklənən alternativ adətən məxfi müştəri axınıdır: burada avtorizasiya serveri tətbiqi autentifikasiya edir və token verir. RFC 6749-un 4.4 bölməsindəki client-credentials qrantı buna bir nümunədir. Onun mövcudluğu hər API-nin onu qəbul etdiyi və ya istifadəçi tərəfindən delegasiya edilmiş tapşırığın onunla əvəz oluna biləcəyi anlamına gəlmir, çünki bunlar xidmət sahibinin suallarıdır. Kod yazmazdan əvvəl xidmətin hansı nəzarətsiz modeli dəstəklədiyini soruşun.

VPN hələ də harada yer alır

VPN özəl API-nin tələb etdiyi şəbəkə yolunu təmin edə bilər və bu, qanuni roldur. O, işi tətbiq qarşısında autentifikasiya etmir və işin nə edə biləcəyinin əhatəsini müəyyən etmir. Ortaq çıxış ünvanı da işi deyil, hostu müəyyən edir, ona görə həmin ünvan üçün icazə siyahısı qeydi onun üzərində işləyən hər prosesi buraxır.

İş ortaq işlədicidə işləyirsə, bu fərq daha çox, nə az, vacibdir. Eyni hostdakı başqa iş axını marşrutu və ünvanı miras alır və API ikisini ayıra bilmir. Bu, ortaq parolla eyni zəiflikdir, bir qat aşağı köçürülmüşdür. Məhdudiyyəti tətbiqin tətbiq edə biləcəyi yerə qoyun və icazə siyahısını daha dar əhatəyə ala bilmirsinizsə, işlədicini təcrid edin.

İki dizaynı dürüst müqayisə edin

İnsan girişi sizə real şəxs, real ikinci amil və audit edilə bilən sessiya verir və nəzarətsiz işləyə bilmir. Tətbiq kimliyi sizə nəzarətsiz icra, nəzərdən keçirilə bilən əhatə və fırlada biləcəyiniz etimadnamə verir və heç nə delegasiya etməmiş istifadəçi adından çıxış edə bilmir. Biri digərinin zəif versiyası deyil; onlar fərqli suallara cavab verir. Tapşırığın heç kim olmadan işləməli olub-olmadığını və əməliyyatın konkret istifadəçiyə aid edilməli olub-olmadığını soruşaraq seçin.

Hər iki cavab bəlidirsə, dizayna borc alınmış parol deyil, delegasiya modeli lazımdır. Bu qərarı növbəti baxıcının tapacağı yerə yazın.

Təhvil verməzdən əvvəl nəyi yoxlamaq lazımdır

Faktiki işçidən icazə verilmiş bir əməliyyat və tələb olunan bir imtina işə salın və hər iki nəticəni saxlayın. Sonra vaxtı keçmiş etimadnaməni və şəbəkə yolu əlçatmaz olduqda davranışı yoxlayın, çünki bunlar gecə kimsəni oyadan iki nasazlıqdır.

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

Subyekti, əhatəni, fırlatma sahibini və icra mühitini həmin nəticənin yanında qeyd edin. Bu qeyd növbəti fırlatmanı insident deyil, rutin edən şeydir. O, həm də auditorun istədiyi hissədir.