Kontrol Akses, Identitas dan Manajemen Rahasia

Keuntungan:

• Kemampuan untuk memisahkan otentikasi dan otorisasi dan menerapkan otorisasi minimum dengan RBAC/ABAC
• Kemampuan untuk menghindari risiko proksi campuran dengan menjalankan model dalam konteks pengguna
• Kemampuan untuk menyimpan dan memutar kunci API dengan sistem manajemen rahasia

Sebagian besar serangan terhadap sistem AI tidak dimulai dengan “menipu” model, namun dengan kunci API yang dicuri atau akun yang diberi otorisasi berlebihan. Lapisan keamanan ini berasal dari keamanan informasi klasik, namun menambahkan risiko baru dalam konteks AI: model memanggil tumpangan atas nama orang lain, akun layanan mengakses semua data, kebocoran kunci ke GitHub. Pada unit ini, kita akan mempelajari cara mempersempit akses ke sistem AI dengan otentikasi, otorisasi (RBAC/ABAC), otorisasi minimum, dan manajemen rahasia.

Perbedaan Antara Otentikasi dan Otorisasi

Kedua istilah ini sering membingungkan:

• Otentikasi: "Siapa Anda?" — membuktikan bahwa pengguna/layanan benar-benar sesuai dengan klaimnya (kata sandi, token, sertifikat, MFA).
• Otorisasi: "Apa yang dapat Anda lakukan?" — menentukan sumber daya/tindakan mana yang dapat diakses oleh pihak yang diautentikasi.

Kehalusan penting dalam sistem AI adalah: ketika model melakukan pekerjaan atas nama pengguna, apakah model tersebut beroperasi dengan otoritas pengguna tersebut atau dengan akun layanan yang luas? Yang terakhir ini berbahaya — karena model yang diakali dengan injeksi mendapatkan akses penuh ke akun layanan.

Perhatian: Masalah "Deputi yang bingung": pengguna dengan otoritas rendah secara tidak langsung mengakses data yang tidak dapat dia akses dengan melakukan outsourcing model otoritas tinggi. Model harus selalu beroperasi dalam konteks otoritas pengguna, bukan otoritas luas pengguna.

RBAC dan ABAC

• RBAC (Kontrol Akses Berbasis Peran): Akses bergantung pada peran pengguna. Peran "spesialis dukungan" dapat membaca catatan pelanggan, namun tidak dapat menghapusnya. Sederhana dan umum.
• ABAC (Kontrol Akses Berbasis Atribut): Akses bergantung pada atribut: departemen pengguna, label privasi data, waktu, jaringan asal permintaan. Lebih halus namun lebih kompleks.

Sebagian besar organisasi memulai dengan RBAC dan mendalami ABAC untuk data sensitif. Aturan praktis untuk AI: model harus memfilter setiap agen yang dipanggilnya dan setiap data yang diaksesnya berdasarkan peran/atribut pengguna yang membuat permintaan.

Langkah demi Langkah: Menjalankan Otoritas Minimal

1. Ambil inventaris. Alat apa yang dipanggil oleh model, data apa yang diaksesnya? Daftar semuanya.
2. Justifikasi setiap akses. “Apakah asisten ini benar-benar memerlukan otoritas penghapusan?” Jika tidak, hapus saja.
3. Default hanya-baca. Model harus dapat membaca secara default; Memerlukan penulisan/penghapusan token terpisah dengan cakupan sempit.
4. Pindahkan konteks pengguna. Panggil kendaraan dengan otoritas pengguna, bukan dengan akun layanan.
5. Kredensial berumur pendek. Gunakan token yang berumur pendek dan dapat diperpanjang secara otomatis, bukan kunci yang berumur panjang.

Manajemen Rahasia

Rahasia adalah kredensial yang harus tetap dirahasiakan, seperti kunci API, kata sandi, token, atau sertifikat. Kecelakaan paling umum dalam proyek AI adalah ketika kunci API penyedia model tertanam dalam kode dan bocor ke kontrol versi (Git).

Aplikasi yang benar:

• Jangan pernah menyematkan kunci dalam kode; Gunakan variabel lingkungan atau sistem manajemen rahasia (layanan yang menyimpan kunci terenkripsi dan mengontrol akses).
• Rotasi: Perbarui kunci secara berkala (misalnya setiap 90 hari); Jika dicurigai ada kebocoran, segera batalkan.
• Pengurangan cakupan: Setiap switch hanya memiliki layanan yang diperlukan dan otorisasi yang diperlukan.
• Audit: Catat siapa yang menggunakan kunci, kapan, dan di mana.

Empat Templat yang Dapat Disalin

Akses perintah kontrol peninjauan:

Untuk setiap alat dalam daftar alat di bawah, evaluasi:- Apakah alat ini DIPERLUKAN untuk melakukan pekerjaan asisten ini? (ya/tidak) - Apakah hanya baca atau tulis/hapus? - Apakah alat ini dipanggil dengan otoritas pengguna atau akun layanan? Tandai yang tidak perlu atau terlalu diotorisasi sebagai "HAPUS/REDAKSI".<tools>{{ tool_list }}</tools>

Perintah pemindaian kebocoran rahasia:

Temukan apa pun yang bisa menjadi rahasia hardcode dalam cuplikan kode berikut: kunci API, kata sandi, token, string koneksi, kunci pribadi. Berikan baris dan ketik untuk masing-masing. SALIN nilai ke dalam respons;mask (4 karakter pertama + ***).<code>{{ source }}</code>

Aturan pengambilan keputusan dengan otoritas terkecil:

Ketika permintaan alat/akses baru tiba, tanyakan:1. Bisakah tugas dilakukan tanpa akses ini? -> Jika ya: TOLAK2. Apakah cukup membaca saja? -> Jika ya: HIBAH izin menulis3. Dapatkah cakupannya dipersempit menjadi satu sumber saja? -> Jika ya: daratJawaban defaultnya adalah "tidak"; Akses diperoleh dengan alasan.

Pengingat kalender rotasi:

Untuk setiap rahasia, catat: pemilik, tanggal pembuatan, masa berlaku, cakupan. Laporkan setiap kunci yang telah melebihi 90 hari atau tidak digunakan selama 30 hari sebagai "KANDIDAT ROTASI/PEMBATALAN".

Prompt Lemah / Prompt Kuat

pendekatan yang buruk

Pendekatan yang kuat

Model mengakses semua data dengan satu akun layanan

Model mengakses dengan otoritas pengguna yang membuat permintaan

Kunci API tertanam dalam kode, tidak pernah berubah

Rotasi di manajer rahasia kunci, 90 hari

Wewenang "melakukan apa saja" yang luas kepada asisten

Default hanya baca, tulis sempit

Akses tidak pernah ditinjau

Peninjauan dan pencabutan akses rutin

Tiga Kasus Mini

Kasus 1 — Data proxy campuran bocor. Asisten internal bekerja dengan akun layanan yang memiliki akses ke semua catatan karyawan. Seorang pengguna magang mengakses data yang biasanya tidak dia lihat dengan mengatakan "ringkas tabel gaji eksekutif"; karena model mempertanyakannya dalam konteks otoritas luasnya, bukan konteks pengguna. Setelah konteks pengguna disesuaikan untuk dipindahkan, pekerja magang dapat mengambil rekaman yang hanya dapat dilihat oleh dia.

Kasus 2 — Kunci bocor, tagihan 190.000 TL dalam 2 minggu. Pengembang menyematkan kunci API model dalam skrip pembantu dan memasukkannya ke repositori publik. Bot menemukan kuncinya dalam 40 menit dan menggunakannya selama dua minggu; Tagihannya mencapai 190.000 TL. Ketika kunci dipindahkan ke manajer rahasia, dihubungkan ke rotasi, dan pemindaian repositori ditambahkan, kejadian tersebut tidak terulang kembali.

Kasus 3 — Default read-only mencegah interupsi. Asisten DevOps menerima perintah "reset database produksi" melalui injeksi cepat. Namun, asisten hanya diberi token baca-saja; tulis/hapus berada dalam alur terpisah yang disetujui. Perintah ditolak dengan kesalahan otorisasi dan kejadian tersebut dicatat sebagai alarm; Tidak ada kehilangan data.

Tip: Jadikan "tidak" sebagai jawaban default Anda untuk permintaan akses baru. Akses adalah sesuatu yang diperoleh melalui pembenaran; Memberi kesempatan kepada semua orang secara luas dan kemudian menguranginya hampir tidak pernah dilakukan dan risikonya terakumulasi.

Kesalahan umum

• Menjalankan model dengan akun layanan besar dan kehilangan konteks pengguna (proksi campuran).
• Menyematkan kunci API dalam kode dan membocorkannya ke kontrol versi.
• Tidak memutar tombol sama sekali ("berfungsi, jangan sentuh").
• Memberi asisten izin menulis/menghapus secara default.
• Memberikan akses sekali dan tidak pernah mempertimbangkannya kembali.
• Membingungkan otentikasi dengan otorisasi dan berasumsi "dia login, dia dapat mengakses semuanya".

Singkatnya

• Otentikasi adalah pertanyaan tentang “siapa Anda”, otorisasi adalah pertanyaan tentang “apa yang dapat Anda lakukan”; Dalam AI, keduanya harus beroperasi dalam konteks pengguna.
• Model harus beroperasi dengan otoritas pengguna yang membuat permintaan, bukan dengan otoritas luasnya sendiri (menghindari risiko campur aduk).
• Mulailah dengan RBAC, perdalam dengan ABAC tentang data sensitif; Jadikan otoritas minimal sebagai default.
• Jangan mengubur rahasia dalam kode; simpan di manajer rahasia, persempit dan masukkan ke dalam rotasi reguler.
• Default hanya-baca dan penulisan sempit sangat membatasi dampak injeksi.

Tugas aplikasi

Cantumkan semua alat dan data yang diakses asisten AI Anda. Jawablah tiga pertanyaan untuk masing-masing pertanyaan: (1) Apakah ini benar-benar diperlukan? (2) Apakah cukup membaca saja? (3) Apakah ini berjalan dalam konteks pengguna? Kemudian cari semua rahasia yang dikodekan (melalui perintah pemindaian di atas) dan tulis rencana rotasi untuk setiap kunci yang Anda temukan. Hapus setidaknya satu otorisasi yang tidak perlu.

daftar periksa

• [ ] Model berjalan dalam konteks otoritas pengguna yang membuat permintaan.
• [ ] Akses alat dan data telah dipersempit menjadi prinsip hak istimewa paling rendah.
• [ ] Tulis/hapus terpisah dari hanya-baca, diautentikasi, dan sempit.
• [ ] Tidak ada rahasia yang terkubur dalam kode; Itu disimpan di manajer rahasia.
• [ ] Terdapat jadwal rotasi dan prosedur pembatalan kunci.
• [ ] Akses ditinjau secara berkala.