Kawalan Akses, Pengurusan Identiti dan Rahsia

Keuntungan:

• Keupayaan untuk memisahkan pengesahan dan kebenaran serta menggunakan kebenaran minimum dengan RBAC/ABAC
• Keupayaan untuk mengelakkan risiko proksi bercampur dengan menjalankan model dalam konteks pengguna
• Keupayaan untuk menyimpan dan memutar kunci API dengan sistem pengurusan rahsia

Sebahagian besar serangan ke atas sistem AI bermula bukan dengan "menipu" model, tetapi dengan kunci API yang dicuri atau akaun yang terlalu dibenarkan. Lapisan keselamatan ini datang daripada keselamatan maklumat klasik, tetapi menambah risiko baharu dalam konteks AI: model memanggil tunggangan bagi pihak orang lain, akaun perkhidmatan mengakses semua data, kunci bocor ke GitHub. Dalam unit ini, kita akan belajar bagaimana untuk mengecilkan akses kepada sistem AI dengan pengesahan, kebenaran (RBAC/ABAC), kebenaran minimum dan pengurusan rahsia.

Perbezaan Antara Pengesahan dan Keizinan

Kedua-dua istilah sering keliru:

• Pengesahan: "Siapa awak?" — membuktikan bahawa pengguna/perkhidmatan itu benar-benar orang yang mereka dakwa (kata laluan, token, sijil, MFA).
• Keizinan: "Apa yang boleh anda lakukan?" — tentukan sumber/tindakan mana yang boleh diakses oleh pihak yang disahkan.

Kehalusan kritikal dalam sistem AI ialah ini: apabila model menjalankan kerja bagi pihak pengguna, adakah ia beroperasi dengan kuasa pengguna tersebut atau dengan akaun perkhidmatan yang luas? Yang terakhir adalah berbahaya — kerana model yang ditipu oleh suntikan mendapat akses penuh ke akaun perkhidmatan.

Awas: Masalah "Timbalan keliru": pengguna berkuasa rendah secara tidak langsung mengakses data yang dia tidak dapat akses dengan menyumber luar model berkuasa tinggi. Model hendaklah sentiasa beroperasi dalam konteks kuasa pengguna, bukan kuasa luasnya sendiri.

RBAC dan ABAC

• RBAC (Kawalan Akses Berasaskan Peranan): Akses bergantung pada peranan pengguna. Peranan "pakar sokongan" boleh membaca nota pelanggan, tetapi tidak boleh memadamkannya. Mudah dan biasa.
• ABAC (Kawalan Akses Berasaskan Atribut): Akses bergantung pada atribut: jabatan pengguna, label privasi data, masa dalam hari, rangkaian dari mana permintaan itu datang. Lebih halus tetapi lebih kompleks.

Kebanyakan organisasi bermula dengan RBAC dan mendalami ABAC untuk data sensitif. Peraturan praktikal untuk AI: model harus menapis setiap ejen yang dipanggil dan setiap data yang diakses berdasarkan peranan/atribut pengguna yang membuat permintaan.

Langkah demi Langkah: Menjalankan Kuasa Minimal

1. Ambil inventori. Apakah alat yang dipanggil model, data apa yang ia akses? Senaraikan kesemuanya.
2. Wajarkan setiap akses. "Adakah pembantu ini benar-benar memerlukan kuasa memadam?" Jika tidak, keluarkannya.
3. Lalai baca sahaja. Model seharusnya boleh membaca secara lalai; Memerlukan tulis/padam token skop sempit yang berasingan.
4. Alihkan konteks pengguna. Hubungi kenderaan dengan pihak berkuasa pengguna, bukan dengan akaun perkhidmatan.
5. Tauliah jangka pendek. Gunakan token jangka pendek, pembaharuan automatik dan bukannya kunci tahan lama.

Pengurusan Rahsia

Rahsia ialah bukti kelayakan yang mesti kekal rahsia, seperti kunci API, kata laluan, token atau sijil. Kemalangan yang paling biasa dalam projek AI ialah apabila kunci API pembekal model dibenamkan dalam kod dan bocor ke dalam kawalan versi (Git).

Aplikasi yang betul:

• Jangan sekali-kali membenamkan kunci dalam kod; Gunakan pembolehubah persekitaran atau sistem pengurusan rahsia (perkhidmatan yang menyimpan kunci yang disulitkan dan mengawal akses).
• Putaran: Perbaharui kekunci pada selang masa yang tetap (mis. setiap 90 hari); Jika kebocoran disyaki, batalkan segera.
• Pengurangan skop: Setiap suis hanya mempunyai perkhidmatan yang diperlukan dan kebenaran yang diperlukan.
• Audit: Log siapa yang menggunakan kunci, bila dan di mana.

Empat Templat Boleh Disalin

Akses gesaan kawalan semakan:

Untuk setiap alat dalam senarai alat di bawah, nilaikan:- Adakah alat ini DIPERLUKAN untuk melaksanakan tugas pembantu ini? (ya/tidak) - Adakah ia baca sahaja atau tulis/padam? - Adakah alat ini dipanggil dengan pihak berkuasa atau akaun perkhidmatan pengguna? Tandai yang tidak perlu atau terlalu dibenarkan sebagai "BUANG/REDACT".<tools>{{ tool_list }}</tools>

Gesaan pengimbasan kebocoran rahsia:

Cari apa-apa yang boleh menjadi rahsia berkod keras dalam coretan kod berikut: kunci API, kata laluan, token, rentetan sambungan, kunci peribadi. Berikan baris dan taip untuk setiap satu. SALIN nilai ke dalam respons;mask (4 aksara pertama + ***).<kod>{{ sumber }}</code>

Peraturan keputusan pihak berkuasa terkecil:

Apabila alat/permintaan akses baharu tiba, tanya:1. Bolehkah tugas itu dilakukan tanpa akses ini? -> Jika ya: TOLAK2. Adakah cukup baca sahaja? -> Jika ya: BERI kebenaran menulis3. Bolehkah skop dikecilkan kepada satu sumber? -> Jika ya: daratJawapan lalai ialah "tidak"; Akses diperoleh dengan alasan.

Peringatan kalendar putaran:

Untuk setiap rahsia, rekod: pemilik, tarikh penciptaan, tamat tempoh, skop. Laporkan mana-mana kunci yang telah melebihi 90 hari atau tidak digunakan selama 30 hari sebagai "CALON GILIRAN/ PEMBATALAN".

Gesaan Lemah / Gesaan Kuat

pendekatan yang lemah

Pendekatan yang kuat

Model mengakses semua data dengan satu akaun perkhidmatan

Model mengakses dengan kuasa pengguna yang membuat permintaan

Kunci API dibenamkan dalam kod, ia tidak pernah berubah

Putaran dalam pengurus rahsia utama, 90 hari

Kuasa "melakukan apa sahaja" yang luas kepada pembantu

Lalai baca sahaja, tulis secara sempit

Akses tidak pernah disemak

Semakan dan pembatalan akses tetap

Tiga Kes Mini

Kes 1 — Data proksi bercampur yang bocor. Seorang pembantu dalaman sedang bekerja dengan akaun perkhidmatan yang mempunyai akses kepada semua rekod pekerja. Pengguna pelatih mengakses data yang biasanya tidak akan dilihatnya dengan mengatakan "ringkaskan jadual gaji eksekutif"; kerana model itu mempersoalkannya dalam konteks pihak berkuasa luasnya sendiri, bukan pengguna. Setelah konteks pengguna dilaraskan untuk dialihkan, pelatih dapat menarik rakaman yang hanya dia boleh lihat.

Kes 2 — Kunci bocor, bil 190,000 TL dalam 2 minggu. Seorang pembangun membenamkan kunci API model dalam skrip pembantu dan menolaknya ke repositori awam. Bot menemui kunci dalam masa 40 minit dan menggunakannya selama dua minggu; Bil mencecah 190,000 TL. Apabila kunci telah dialihkan kepada pengurus rahsia, disambungkan ke putaran, dan pengimbasan repositori telah ditambahkan, kejadian itu tidak berulang.

Kes 3 — Baca sahaja lalai menghalang gangguan. Pembantu DevOps menerima arahan "set semula pangkalan data pengeluaran" melalui suntikan segera. Bagaimanapun, pembantu itu hanya diberi token baca sahaja; tulis/padam berada dalam aliran yang diluluskan berasingan. Perintah itu ditolak dengan ralat kebenaran dan acara telah dilog sebagai penggera; Tiada kehilangan data.

Petua: Jadikan "tidak" sebagai jawapan lalai anda kepada permintaan akses baharu. Akses ialah sesuatu yang diperoleh melalui justifikasi; Memberi semua orang luas dan kemudian memotong semula hampir tidak pernah dilakukan dan risiko terkumpul.

Kesilapan biasa

• Menjalankan model dengan akaun perkhidmatan yang besar dan kehilangan konteks pengguna (proksi bercampur).
• Membenamkan kunci API dalam kod dan membocorkannya ke dalam kawalan versi.
• Tidak memutar kekunci sama sekali ("berfungsi, jangan sentuh").
• Memberi pembantu menulis/memadam kebenaran secara lalai.
• Memberi akses sekali dan tidak pernah mempertimbangkannya semula.
• Mengelirukan pengesahan dengan kebenaran dan menganggap "dia telah log masuk, dia boleh mengakses segala-galanya".

Secara ringkasnya

• Pengesahan ialah soalan "siapa anda", kebenaran ialah soalan "apa yang boleh anda lakukan"; Dalam AI, kedua-duanya mesti beroperasi dalam konteks pengguna.
• Model harus beroperasi dengan kuasa pengguna yang membuat permintaan, bukan dengan kuasa luasnya sendiri (mengelakkan risiko agensi campuran).
• Mulakan dengan RBAC, mendalami dengan ABAC pada data sensitif; Jadikan kuasa minimum sebagai lalai.
• Jangan kuburkan rahsia dalam kod; simpannya dalam pengurus rahsia, sempitkannya dan masukkannya ke dalam putaran biasa.
• Tulisan lalai dan sempit baca sahaja sangat mengehadkan kesan suntikan.

Tugasan permohonan

Senaraikan semua alatan dan data yang diakses oleh pembantu AI anda. Jawab tiga soalan untuk setiap satu: (1) Adakah ia benar-benar perlu? (2) Adakah cukup baca sahaja? (3) Adakah ia berjalan dalam konteks pengguna? Kemudian cari semua rahsia berkod keras (melalui gesaan imbasan di atas) dan tulis pelan putaran untuk setiap kunci yang anda temui. Alih keluar sekurang-kurangnya satu kebenaran yang tidak diperlukan.

senarai semak

• [ ] Model berjalan dalam konteks kuasa pengguna yang membuat permintaan.
• [ ] Akses alat dan data telah dikecilkan kepada prinsip keistimewaan paling rendah.
• [ ] Tulis/padam adalah berasingan daripada baca sahaja, disahkan dan sempit.
• [ ] Tiada rahsia terkubur dalam kod; Ia disimpan dalam pengurus rahsia.
• [ ] Terdapat jadual penggiliran dan prosedur pembatalan untuk kunci.
• [ ] Akses disemak dengan kerap.