Zamanlanmış iş mi insan girişi mi: API hangi kimliği görmeli?

Zamanlanmış bir iş ile oturum açma isteminde bekleyen bir kişi aynı API'yi farklı kimlik bilgileri, farklı yaşam süreleri ve farklı sahiplerle çağırır. İşin bir ağ yoluna, uygulama kimliğine ve izin kümesine ihtiyacı vardır; kişinin ise oturum açmaya, ikinci bir faktöre ve oturuma ihtiyacı vardır. İkisini karıştırmak, kişinin parolası her değiştiğinde bozulan bir otomasyon ya da bir cron işini hayatta tutmak için tam o kadar zayıflatılmış çok faktörlü bir politika üretir.

Tek gibi görünen üç kapı

Kaynak adres kuralı, isteğin nereden geldiğini sorar. Kimlik doğrulama, kimin aradığını ve hangi kanıtların sunulduğunu sorar. Yetkilendirme, bu öznenin bu işlemi yapıp yapamayacağını sorar. VPN üçünden yalnızca ilkini değiştirir ve bunu yalnızca iş için değil, ana makinedeki her süreç için değiştirir, bu yüzden olay kaydında üç gözlemi ayrı tutun.

Bu yüzden çıkış düğümünü değiştirmek kaynak adres nedeniyle alınan reddi düzeltebilir ve geçersiz belirteci el değmemiş bırakabilir. Bu yüzden geçerli bir API belirteci, oraya rotası olmayan bir işten özel bir uç noktayı erişilebilir kılmaz.

Etkileşimli yol kötü bir otomasyon şablonudur

Bir kişinin oturum açmasını betiklemek cezbedicidir çünkü bir kez çalışır. Betik bir parola, belki tek kullanımlık parola tohumu saklar ve ardından insan gerektirecek şekilde tasarlanmış bir meydan okumaya bağlı kalır. OAuth için mevcut en iyi güvenlik uygulaması olan RFC 9700, resource-owner-password-credentials verilmesini yasaklar ve bunun iki faktörlü ve çok adımlı kimlik doğrulamaya neden kötü uyduğunu açıklar.

Desteklenen alternatif genellikle, yetkilendirme sunucusunun uygulamayı doğruladığı ve bir belirteç verdiği gizli istemci akışıdır. RFC 6749'un 4.4 bölümündeki client-credentials verilmesi bunun bir örneğidir. Bunun var olması her API'nin onu kabul ettiği ya da kullanıcı tarafından devredilen bir görevin onunla değiştirilebileceği anlamına gelmez, çünkü bunlar hizmet sahibine sorulacak sorulardır. Kod yazmadan önce hizmetin hangi gözetimsiz modeli desteklediğini sorun.

VPN hâlâ nereye ait

Bir VPN, özel bir API'nin gerektirdiği ağ yolunu sağlayabilir ve bu meşru bir roldür. İşi uygulamaya karşı doğrulamaz ve işin ne yapabileceğini sınırlamaz. Paylaşılan bir çıkış adresi de işi değil ana makineyi tanımlar, bu yüzden o adres için izin listesindeki bir kayıt, üzerinde çalışan her süreci geçirir.

İş paylaşılan bir runner üzerinde çalışıyorsa bu ayrım daha az değil, daha çok önemlidir. Aynı ana makinedeki başka bir iş akışı rotayı ve adresi devralır ve API ikisini ayırt edemez. Bu, paylaşılan bir parolayla aynı zayıflıktır, bir katman aşağı taşınmıştır. Kısıtı uygulamanın uygulayabileceği yere koyun ve izin listesini daha daraltamıyorsanız runner'ı yalıtın.

İki tasarımı dürüstçe karşılaştırın

İnsan girişi size gerçek bir kişi, gerçek bir ikinci faktör ve denetlenebilir bir oturum verir ve gözetimsiz çalışamaz. Uygulama kimliği size gözetimsiz yürütme, gözden geçirilebilir bir kapsam ve döndürebileceğiniz bir kimlik bilgisi verir ve hiçbir şey devretmemiş bir kullanıcı adına hareket edemez. Hiçbiri diğerinin daha zayıf sürümü değildir; farklı soruları yanıtlarlar. Görevin kimse yokken çalışması gerekip gerekmediğini ve işlemin belirli bir kullanıcıya atfedilmesi gerekip gerekmediğini sorarak seçin.

İki yanıt da evet ise tasarımın ödünç alınmış bir parolaya değil, bir devretme modeline ihtiyacı vardır. Bu kararı bir sonraki bakımcının bulacağı yere yazın.

Devir teslimden önce ne doğrulanmalı

Gerçek worker'dan bir izinli işlem ve bir zorunlu ret çalıştırın ve iki sonucu da saklayın. Ardından süresi dolmuş bir kimlik bilgisini ve ağ yolu kullanılamadığındaki davranışı test edin, çünkü gece birini uyandıran iki arıza bunlardır.

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

Özneyi, kapsamı, rotasyon sahibini ve yürütme ortamını o sonucun yanına not edin. O kayıt, bir sonraki rotasyonu olay değil rutin yapan şeydir. Bir denetçinin istediği kısım da odur.