Tugas terjadwal atau login manusia: identitas mana yang harus dilihat API?

Tugas terjadwal dan orang di prompt login memanggil API yang sama dengan kredensial berbeda, masa berlaku berbeda, dan pemilik berbeda. Tugas membutuhkan jalur jaringan, identitas aplikasi, dan kumpulan izin; orang membutuhkan login, faktor kedua, dan sesi. Mencampur keduanya menghasilkan otomatisasi yang rusak setiap kali kata sandi orang berubah, atau kebijakan multifaktor yang dilemahkan secukupnya agar tugas cron tetap hidup.

Tiga gerbang yang tampak seperti satu

Aturan alamat sumber menanyakan dari mana permintaan berasal. Autentikasi menanyakan siapa yang menelepon dan bukti apa yang disajikan. Otorisasi menanyakan apakah principal ini boleh melakukan operasi ini. VPN hanya mengubah yang pertama dari ketiganya, dan mengubahnya untuk setiap proses di host, bukan hanya untuk tugas itu, jadi pisahkan ketiga pengamatan dalam catatan insiden.

Itulah sebabnya mengganti node keluar dapat memperbaiki penolakan karena alamat sumber dan membiarkan token tidak valid tidak tersentuh. Itu juga sebabnya token API yang valid tidak membuat endpoint privat dapat dijangkau dari tugas yang tidak punya rute ke sana.

Jalur interaktif adalah templat otomatisasi yang buruk

Menulis skrip untuk login seseorang menggoda karena berhasil sekali. Skrip menyimpan kata sandi, mungkin benih kata sandi sekali pakai, lalu bergantung pada tantangan yang dirancang untuk menuntut manusia. Praktik terbaik keamanan OAuth saat ini, RFC 9700, melarang pemberian resource-owner-password-credentials dan menjelaskan mengapa itu tidak cocok dengan autentikasi dua faktor dan bertahap.

Alternatif yang didukung biasanya adalah alur klien rahasia di mana server otorisasi mengautentikasi aplikasi dan menerbitkan token. Pemberian client-credentials dalam RFC 6749 bagian 4.4 adalah salah satu contoh. Keberadaannya tidak berarti setiap API menerimanya, atau bahwa tugas yang didelegasikan pengguna dapat digantikan dengannya, karena itu pertanyaan bagi pemilik layanan. Tanyakan model tanpa pengawasan mana yang didukung layanan sebelum menulis kode.

Di mana VPN masih tepat

VPN dapat menyediakan jalur jaringan yang dibutuhkan API privat, dan itu peran yang sah. VPN tidak mengautentikasi tugas ke aplikasi, dan tidak membatasi apa yang boleh dilakukan tugas. Alamat keluar bersama juga mengidentifikasi host, bukan tugas, jadi entri daftar izin untuk alamat itu mengizinkan setiap proses yang berjalan di atasnya.

Jika tugas berjalan di runner bersama, perbedaan itu lebih penting, bukan kurang penting. Alur kerja lain di host yang sama mewarisi rute dan alamatnya, dan API tidak dapat membedakan keduanya. Itu kelemahan yang sama dengan kata sandi bersama, digeser satu lapis ke bawah. Letakkan pembatasannya di tempat aplikasi dapat menegakkannya, dan isolasi runner jika Anda tidak dapat mempersempit daftar izin.

Bandingkan kedua desain dengan jujur

Login manusia memberi Anda orang nyata, faktor kedua nyata, dan sesi yang dapat diaudit, dan itu tidak dapat berjalan tanpa pengawasan. Identitas aplikasi memberi Anda eksekusi tanpa pengawasan, cakupan yang dapat ditinjau, dan kredensial yang dapat Anda rotasi, dan itu tidak dapat bertindak untuk pengguna yang belum mendelegasikan apa pun. Keduanya bukan versi yang lebih lemah satu sama lain; keduanya menjawab pertanyaan berbeda. Pilih dengan menanyakan apakah tugas harus berjalan tanpa siapa pun hadir, dan apakah operasi harus diatribusikan ke pengguna tertentu.

Jika kedua jawabannya ya, desain membutuhkan model delegasi, bukan kata sandi pinjaman. Tuliskan keputusan itu di tempat yang akan ditemukan pemelihara berikutnya.

Apa yang harus diverifikasi sebelum serah terima

Jalankan satu operasi yang diizinkan dan satu penolakan yang diwajibkan dari pekerja sebenarnya, dan simpan kedua hasilnya. Lalu uji kredensial kedaluwarsa dan perilaku saat jalur jaringan tidak tersedia, karena itu dua kegagalan yang membangunkan orang di malam hari.

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

Catat principal, cakupan, pemilik rotasi, dan lingkungan eksekusi di samping hasil itu. Catatan itulah yang membuat rotasi berikutnya menjadi rutinitas, bukan insiden. Itu juga bagian yang diminta auditor.