Qazanclar:
- Doğrulama və avtorizasiyanı ayırmaq və RBAC/ABAC ilə minimum icazəni tətbiq etmək bacarığı
- Modeli istifadəçi kontekstində işlətməklə qarışıq proxy riskindən qaçınmaq imkanı
- Gizli idarəetmə sistemi ilə API açarlarını saxlamaq və çevirmək imkanı
Süni intellekt sisteminə hücumların əhəmiyyətli bir hissəsi modeli “aldatmaqla” deyil, oğurlanmış API açarı və ya həddindən artıq icazəli hesabla başlayır. Bu təhlükəsizlik təbəqəsi klassik informasiya təhlükəsizliyindən gəlir, lakin süni intellekt kontekstində yeni risklər əlavə edir: model başqasının adından səyahət çağırır, xidmət hesabı bütün məlumatlara daxil olur, açar GitHub-a sızır. Bu bölmədə identifikasiya, avtorizasiya (RBAC/ABAC), minimum icazə və məxfi idarəetmə ilə AI sisteminə girişi necə daraltmağı öyrənəcəyik.
Doğrulama və avtorizasiya arasındakı fərq
Bu iki termin tez-tez qarışdırılır:
- Doğrulama: "Sən kimsən?" — istifadəçinin/xidmətin həqiqətən iddia etdiyi şəxs olduğunu sübut etmək (parol, nişan, sertifikat, XİN).
- Səlahiyyət: "Nə edə bilərsən?" — təsdiqlənmiş tərəfin hansı resurs/fəaliyyətə daxil ola biləcəyini müəyyənləşdirin.
Süni intellekt sistemlərində kritik incəlik budur: model istifadəçi adından iş yerinə yetirdikdə, o, həmin istifadəçinin səlahiyyəti ilə işləyir, yoxsa geniş xidmət hesabı ilə? Sonuncu təhlükəlidir - çünki inyeksiya ilə aldadılan model xidmət hesabına tam giriş əldə edir.
Diqqət: “Çaşqın deputat” problemi: aşağı səlahiyyətə malik istifadəçi yüksək səlahiyyətli modeldən autsorsing etməklə əldə edə bilmədiyi məlumatlara dolayı yolla daxil olur. Model həmişə istifadəçinin geniş səlahiyyətləri çərçivəsində deyil, onun səlahiyyətləri çərçivəsində fəaliyyət göstərməlidir.
RBAC və ABAC
- RBAC (Rola Əsaslı Giriş Nəzarəti): Giriş istifadəçinin rolundan asılıdır. "Dəstək mütəxəssisi" rolu müştəri qeydlərini oxuya bilər, lakin onları silə bilməz. Sadə və ümumi.
- ABAC (Atribut-Based Access Control): Giriş atributlardan asılıdır: istifadəçinin departamenti, məlumatların məxfilik etiketi, günün vaxtı, sorğunun gəldiyi şəbəkə. Daha incə, lakin daha mürəkkəbdir.
Əksər təşkilatlar RBAC ilə başlayır və həssas məlumatlar üçün ABAC-ı dərinləşdirir. Süni intellekt üçün əsas qayda: model sorğu edən istifadəçinin roluna/atributlarına əsasən zəng etdiyi hər bir agenti və daxil olduğu hər məlumatı süzgəcdən keçirməlidir.
Addım-addım: Minimal Səlahiyyətdən istifadə
- İnventar götürün. Model hansı alətləri çağırır, hansı verilənlərə daxil olur? Onların hamısını sadalayın.
- Hər girişi əsaslandırın. "Bu köməkçinin həqiqətən silmək səlahiyyətinə ehtiyacı varmı?" Əks halda, onu çıxarın.
- Yalnız oxumaq üçün defolt. Model standart olaraq oxuya bilməlidir; Ayrı, dar miqyaslı işarənin yazılmasını/silməsini tələb edin.
- İstifadəçi kontekstini köçürün. Avtomobilə xidmət hesabı ilə deyil, istifadəçinin səlahiyyəti ilə zəng edin.
- Qısa müddətli etimadnamə. Uzunmüddətli açarlar əvəzinə qısamüddətli, avtomatik yenilənən tokenlərdən istifadə edin.
Gizli İdarəetmə
Gizli API açarı, parol, token və ya sertifikat kimi gizli qalmalı olan etimadnamələrdir. Süni intellekt layihələrində ən çox rast gəlinən qəza model provayderinin API açarının koda daxil olması və versiya nəzarətinə (Git) sızmasıdır.
Düzgün tətbiq:
- Heç vaxt açarları koda yerləşdirməyin; Ətraf mühit dəyişənindən və ya gizli idarəetmə sistemindən (şifrələnmiş açarları saxlayan və girişə nəzarət edən xidmət) istifadə edin.
- Fırlanma: Açarları müntəzəm olaraq yeniləyin (məsələn, hər 90 gündən bir); Sızma şübhəsi varsa, dərhal ləğv edin.
- Əhatə dairəsinin azaldılması: Hər bir keçid yalnız tələb olunan xidmətə və tələb olunan icazəyə malikdir.
- Audit: Açarı kimin, nə vaxt və harada istifadə etdiyini qeyd edin.
Dörd Kopyalana bilən Şablon
Giriş yoxlamasına nəzarət sorğusu:
Aşağıdakı alətlər siyahısındakı hər bir alət üçün qiymətləndirin: - Bu köməkçinin işini yerinə yetirmək üçün bu alət TƏLƏB EDİLİR? (bəli/yox) - Yalnız oxumaq üçündür, yoxsa yazmaq/silmək? - Bu alət istifadəçinin səlahiyyəti və ya xidmət hesabı ilə çağırılır? Lazımsız və ya həddindən artıq icazəli olanları "SİL/REDACT" kimi qeyd edin.<tools>{{ tool_list }}</tools>
Gizli sızma skan sorğusu:
Aşağıdakı kod parçasında sərt kodlanmış sirr ola biləcək hər şeyi tapın: API açarı, parol, işarə, əlaqə sətri, şəxsi açar. Hər biri üçün sıra və yazın. Dəyəri cavaba KOPYALA;maska (ilk 4 simvol + ***).<code>{{ mənbə }}</code>
Ən az səlahiyyətli qərar qaydası:
Yeni alət/giriş sorğusu gəldikdə, soruşun: 1. Tapşırığı bu giriş olmadan yerinə yetirmək olarmı? -> Əgər belədirsə: RƏDD ET2. Yalnız oxumaq üçün kifayətdirmi? -> Əgər belədirsə: yazma icazəsi VERİN3. Əhatə dairəsini bir mənbəyə qədər daraltmaq olarmı? -> Əgər varsa: darat Defolt cavab "yox"dur; Giriş səbəblə əldə edilir.
Fırlanma təqvimi xatırladıcısı:
Hər bir sirr üçün qeyd edin: sahibi, yaradılma tarixi, müddəti, əhatə dairəsi. 90 günü keçmiş və ya 30 gün ərzində istifadə edilməyən hər hansı açarı "ROTASİYA/LƏĞV NƏDƏDİ" kimi bildirin.
Zəif Tələb / Güclü Tələb
pis yanaşma
Güclü yanaşma
Model bir xidmət hesabı ilə bütün məlumatlara daxil olur
Model sorğu edən istifadəçinin səlahiyyəti ilə daxil olur
API açarı koda daxil edilib, heç vaxt dəyişmir
Əsas gizli menecerdə fırlanma, 90 gün
Köməkçiyə geniş "hər şeyi etmək" səlahiyyəti
Yalnız oxumaq üçün standart, dar yazın
Girişlər heç vaxt nəzərdən keçirilmir
Daimi giriş yoxlaması və ləğvi
Üç mini qutu
1-ci hal – Qarışıq proksi məlumatları sızdırıldı. Daxili köməkçi bütün işçi qeydlərinə çıxışı olan xidmət hesabı ilə işləyirdi. Təcrübəçi istifadəçi adətən görməyəcəyi məlumatlara “idarəçilərin maaş cədvəlini ümumiləşdirin” deyərək daxil olur; çünki model bunu istifadəçinin deyil, öz geniş səlahiyyəti kontekstində sorğu-sual edirdi. İstifadəçi konteksti köçürüləcək şəkildə düzəldildikdən sonra təcrübəçi yalnız onun görə biləcəyi qeydləri çəkə bildi.
Case 2 — Sızdırılmış açar, 2 həftə ərzində 190.000 TL-lik banknot. Tərtibatçı model API açarını köməkçi skriptə daxil etdi və onu ictimai depoya itələdi. Bir bot açarı 40 dəqiqə ərzində tapdı və ondan iki həftə istifadə etdi; Hesab 190.000 TL-yə çatdı. Açar gizli menecerə köçürüldükdə, fırlanmaya qoşulduqda və repozitorun skan edilməsi əlavə olunduqda, insident təkrarlanmadı.
Hal 3 - Yalnız oxumaq üçün defolt kəsilmənin qarşısını alır. DevOps köməkçisi operativ inyeksiya vasitəsilə "istehsal verilənlər bazasını sıfırla" əmrini aldı. Bununla belə, köməkçiyə yalnız oxumaq üçün bir işarə verildi; yazmaq/silmək ayrıca təsdiq edilmiş axın içində idi. Əmr icazə xətası ilə rədd edildi və hadisə həyəcan siqnalı kimi qeyd edildi; Məlumat itkisi yox idi.
İpucu: Yeni giriş sorğusuna defolt cavabınızı "yox" edin. Giriş əsaslandırma yolu ilə əldə edilən bir şeydir; Hamıya geniş vermək və sonra kəsmək demək olar ki, heç vaxt edilmir və risk toplanır.
Ümumi səhvlər
- Modelin böyük bir xidmət hesabı ilə işlədilməsi və istifadəçi kontekstinin itirilməsi (qarışıq proxy).
- API açarının koda daxil edilməsi və versiya nəzarətinə sızdırılması.
- Düymələri ümumiyyətlə döndərməmək ("işləyir, toxunma").
- Defolt olaraq köməkçiyə yazma/silmə icazələrinin verilməsi.
- Bir dəfə giriş icazəsi vermək və heç vaxt yenidən nəzərdən keçirməmək.
- İdentifikasiyanı avtorizasiya ilə qarışdırmaq və "o, daxil olub, hər şeyə daxil ola bilər" fərziyyəsi.
Xülasə
- Doğrulama “sən kimsən”, avtorizasiya “nə edə bilərsən” sualıdır; Süni intellektdə hər ikisi istifadəçi kontekstində işləməlidir.
- Model öz geniş səlahiyyəti ilə deyil, sorğu verən istifadəçinin səlahiyyəti ilə işləməlidir (qarışıq agentlik riskindən qaçınmaqla).
- RBAC ilə başlayın, həssas məlumatlarda ABAC ilə dərinləşdirin; Minimum səlahiyyətləri defolt edin.
- Şifrə sirləri basdırmayın; onu gizli menecerdə saxlayın, daraltın və müntəzəm fırlanmaya qoyun.
- Yalnız oxumaq üçün standart və dar yazı inyeksiyanın təsirini xeyli məhdudlaşdırır.
Tətbiq tapşırığı
AI köməkçinizin əldə etdiyi bütün alətləri və məlumatları sadalayın. Hər biri üçün üç suala cavab verin: (1) Həqiqətən lazımdırmı? (2) Yalnız oxumaq üçün kifayətdirmi? (3) İstifadəçi kontekstində işləyirmi? Sonra bütün sərt kodlanmış sirləri axtarın (yuxarıdakı skan sorğusu vasitəsilə) və tapdığınız hər düymə üçün fırlanma planı yazın. Ən azı bir lazımsız icazəni silin.
yoxlama siyahısı
- [ ] Model sorğu verən istifadəçinin səlahiyyət kontekstində işləyir.
- [ ] Alət və məlumat girişi ən az imtiyaz prinsipinə qədər daraldıldı.
- [ ] Yazmaq/silmək yalnız oxumaqdan ayrıdır, təsdiqlənmiş və dardır.
- [ ] Kodda heç bir sirr gizlənmir; Gizli menecerdə saxlanılır.
- [ ] Düymələr üçün fırlanma cədvəli və ləğvetmə proseduru var.
- [ ] Girişlər müntəzəm olaraq nəzərdən keçirilir.