SMM panelinin API açarının təhlükəsiz saxlanması

SMM panelinin API açarı nəyə giriş verir

API açarı saytı, botu, CRM-i, avtomatlaşdırma cədvəlini və ya skripti SMM panelinə bağlayır. Onun vasitəsilə sifarişlər yaratmaq, onların statuslarını almaq, balansı yoxlamaq və xidmətləri idarə etmək mümkündür. Dəqiq əməliyyatlar toplusu panelin imkanlarından və açar üçün verilmiş hüquqlardan asılıdır.

SMM panelinin açarı çox vaxt hesabın balansına bağlıdır. Buna görə də onun sızması təkcə yad sifarişlər və avtomatlaşdırmanın sıradan çıxması riski deyil, həm də birbaşa pul itkisidir. Açarı hesab adından əməliyyatlara girişi olan sirr kimi qəbul etmək lazımdır.

Açarı sayt kodunda yerləşdirmək niyə olmaz

Frontend kodu ziyarətçilər üçün brauzerdə əlçatandır. Əgər açar JavaScript-də, HTML-də, publik tətbiqin parametrlərində və ya brauzer tərəfindən göndərilən sorğularda yazılıbsa, onu developer alətləri, mənbə kodu və ya şəbəkə sorğusunun tutulması vasitəsilə tapmaq olar. Minifikasiya dəyəri gizlətmir, sadəcə oxumağı çətinləşdirir.

SMM panelinə sorğular server hissəsindən göndərilməlidir: backend, qapalı bot, tapşırıq emalçısı və ya ayrıca servis. İstifadəçi tətbiqə müraciət edir, tətbiq isə artıq panellə işləyir. Bu yanaşmanın çatışmazlığı ondadır ki, serveri saxlamaq, yeniləmək və qorumaq lazımdır.

Bot və server üçün mühit dəyişənləri

Kiçik və orta layihələr üçün açar adətən mühit dəyişənində saxlanılır. Tətbiq dəyəri işə salınarkən alır, sirr isə mənbə kodunda qalmır. Dəyişən hostinq panelində, konteyner parametrlərində, proses konfiqurasiyasında və ya serverdəki qorunan faylda təyin edilir.

• Dəyişən üçün açar dəyəri olmayan aydın ad istifadə edin.
• Prodakşn, test və lokal işləmə üçün açarları ayırın.
• Server və hostinq parametrlərinə girişi məhdudlaşdırın.
• Mühit dəyişənlərini sazlama mesajlarında göstərməyin.

Mühit dəyişənlərinin çatışmazlığı ondadır ki, sirri serverə, hostinq panelinə, ehtiyat nüsxələrə və ya işəsalma jurnallarına girişi olan şəxs oxuya bilər. Geniş giriş hüquqları olan komandada bu üsul kifayət etmir.

Lokal işləmə üçün .env faylı

.env faylı layihə lokal kompüterdə işə salındıqda əlverişlidir. O, açarı mənbə fayllarından ayrı saxlayır, tətbiq isə dəyəri başlanğıcda yükləyir. Belə fayl ilk kommitdən əvvəl .gitignore-a əlavə edilir ki, kodla birlikdə repozitoriyaya düşməsin.

.gitignore artıq baş vermiş dərci düzəltmir. Əgər .env hətta bir dəfə Git-ə düşübsə, açar kommit tarixçəsində, fork-larda, lokal klonlarda və ehtiyat nüsxələrdə qala bilər. Faylın repozitoriyadan silinməsi köhnə dəyəri təhlükəsiz etmir: açar ləğv edilməli və dəyişdirilməlidir.

.env-in çatışmazlığı ondadır ki, onu asanlıqla layihə arxivinə əlavə etmək, serverdə səhv qovluğa yükləmək və ya podratçıya mənbə faylları ilə birlikdə göndərmək olar.

İşçi layihələr üçün sirr meneceri

Bir neçə developer, bot və mühiti olan layihə üçün sirr meneceri uyğundur. O, açarları repozitoriyadan ayrı saxlayır, konkret şəxslərə və ya servislərə giriş verməyə və sirri işə salınma zamanı tətbiqə qorunan kanal vasitəsilə ötürməyə imkan verir.

Sirrə müraciətlər jurnalı formalıq üçün lazım deyil. Onun vasitəsilə kimin və nə vaxt açarа giriş əldə etdiyini yoxlamaq, tanış olmayan serverdən müraciətləri görmək və paneldə şübhəli aktivlik zamanı səbəblərin dairəsini daha tez daraltmaq olar. Bu, xüsusilə kanal, sayt və avtomatlaşdırma ilə müxtəlif insanlar məşğul olduqda faydalıdır.

Sirr meneceri həmçinin dəyərin dəyişdirilməsini asanlaşdırır: yeni açar mərkəzləşdirilmiş şəkildə əlavə edilir, köhnəsi isə inteqrasiyalar yeniləndikdən sonra söndürülür.

Sirr menecerinin çatışmazlıqları və girişin qurulması

Sirr meneceri avtomatik qorumur. Giriş hüquqlarında səhv, açıq yerləşdirmə tokeni və ya səhv qurulmuş inteqrasiya açarı tələb olunandan daha geniş əlçatan edə bilər. Onu da ehtiyat ssenariyə daxil etmək lazımdır: anbara giriş olmadan tətbiq nasazlıqdan sonra işə düşməyə bilər.

Girişi rollara görə verin. Developera test mühitinin sirri lazım ola bilər, yerləşdirmə servisinə isə açarı interfeysdə göstərmək imkanı olmadan tətbiqə ötürmək hüququ. Komanda üçün bir ümumi hesab istifadə etməyin: o zaman müraciətlər jurnalı əməliyyatı kimin yerinə yetirdiyini göstərməyəcək.

İnteqrasiyalar və podratçılar üçün ayrı açarlar

Kanal, reklam, bot və ya saytla işləyən hər kəsə bir açar verməyin. Əgər panel bir neçə açar yaratmağa imkan verirsə, hər inteqrasiya üçün ayrı açar buraxın: sifariş botu, CRM, status skripti və test layihəsi üçün. Belə şübhəli aktivliyin mənbəyini tapmaq və bütün sistemi dayandırmadan bir girişi söndürmək daha asandır.

Podratçıya minimum lazımi imkanları olan açar vermək və ya işi öz backend-iniz vasitəsilə qurmaq daha təhlükəsizdir. Sirri hətta qısa müddətə də messencerdə göndərməyin. Ayrı açarların çatışmazlığı ondadır ki, onları nəzərə almaq lazımdır: təyinatı, sahibini, buraxılma tarixini və istifadə yerini qeyd etmək.

Açarın hüquqları və tapşırıqların ayrılması

Əgər SMM paneli əməliyyatlar üzrə məhdudiyyətləri dəstəkləyirsə, hər tapşırıq üçün maksimal hüquqlu açardan istifadə etməyin. Sifarişin statusunu yoxlamaq üçün açar yeni sifarişlər yaratmamalı və ya maliyyə məlumatları almamalıdır. Hüquqlar nə qədər dar olsa, komprometasiya zamanı mümkün ziyan bir o qədər az olar.

Avtomatlaşdırmanı rollara görə ayırın: bir komponent müraciəti qəbul edir, digəri sifariş yaradır, üçüncüsü statusu yoxlayır. Bu, sızmanı istisna etmir, lakin bir sirrlə əlçatan əməliyyatları məhdudlaşdırır. Belə bölgünün çatışmazlığı ondadır ki, inteqrasiya mürəkkəbləşir, xətaların diaqnostikası isə daha çox vaxt aparır.

Loqlar, xətalar və ehtiyat nüsxələr

Açarlar çox vaxt repozitoriyadan deyil, loqlar vasitəsilə sızır. Sorğunun tam URL-ini, HTTP sorğusunun gövdəsini, avtorizasiya başlıqlarını, tətbiqin konfiqurasiyasını və ya filtrsiz xəta obyektini yazmayın. Tətbiqin, veb-serverin, tapşırıq növbələrinin, monitorinqin və xəta bildirişlərinin loqlarını yoxlayın.

Sirr verilənlər bazasının damplarına, sayt arxivlərinə və parametrlərin ehtiyat nüsxələrinə düşməməlidir. Əgər jurnalda sorğuları tutuşdurmaq lazımdırsa, açarı bərpa etmək mümkün olmayan təhlükəsiz dəyər fraqmenti saxlayın. Maskalanmanın çatışmazlığı ondadır ki, nasazlıqları araşdırmaq çətinləşir, buna görə də sirli sahələr olmadan texniki konteksti saxlayın.

API açarı sızdıqda nə etməli

Əgər açar publik repozitoriyaya, çata, ekran şəklinə, loqa, arxivə və ya başqasının kompüterinə düşübsə, mesajı və ya faylı silməklə kifayətlənməyin. Onu komprometasiya olunmuş hesab edin: dəyəri silinməzdən əvvəl kopyalaya bilərdilər. Əvvəlcə köhnə giriş bloklanır, sonra nəticələr yoxlanılır və dəyişdirmə qurulur.

1. Dərhal komprometasiya olunmuş açarı SMM panelində ləğv edin və ya söndürün.
2. Balansı, sifariş tarixçəsini, aktiv sifarişləri və hesabdakı digər əməliyyatları yoxlayın.
3. Yeni açarı yalnız lazımi hüquqlarla buraxın.
4. Dəyəri serverdə, botlarda, planlaşdırıcılarda və digər inteqrasiyalarda dəyişdirin.
5. Köhnə konfiqurasiya tamamilə silinməzdən əvvəl yenilənmiş inteqrasiyaların işini yoxlayın.
6. Sirri repozitoriyadan, loqlardan, arxivlərdən, sənədlərdən və dərc olunduğu mesajlardan silin.

Açarların rotasiyası adi prosedur kimi

Açarın ləğvi və dəyişdirilməsi təkcə sızmandan sonra lazım deyil. Rotasiya podratçı dəyişdikdə, işçi işdən çıxdıqda, layihə köçürüldükdə, giriş hüquqları dəyişdikdə və şübhəli aktivlik zamanı aparılır. Planlı dəyişdirmə həmçinin açarı uzun müddət bir neçə servis və ya şəxs istifadə etdiyi halda riski azaldır.

Rotasiyadan əvvəl bütün istifadə yerlərinin siyahısını tərtib edin: server, botlar, planlaşdırıcılar, CRM, avtomatlaşdırma cədvəlləri, test stendləri və ehtiyat ssenarilər. Əvvəlcə yeni açarı əlavə edin, konfiqurasiyaları yeniləyin və sorğuları yoxlayın, sonra köhnəni söndürün. Rotasiyanın çatışmazlığı ondadır ki, buraxılmış inteqrasiya zamanı avtomatlaşdırmanın bir hissəsi işləməyi dayandıracaq.

Komandada açarların və girişlərin uçotu

Hər açar üçün qısa qapalı qeyd saxlamaq faydalıdır: harada istifadə olunur, hansı hüquqlara malikdir, inteqrasiyaya kim cavabdehdir və giriş nə vaxt nəzərdən keçirilməlidir. Belə reyestrdə sirrin özünü yazmayın. İnteqrasiyanın adı və panel onu göstərirsə, açarın təhlükəsiz identifikatoru kifayətdir.

Podratçı işi bitirdikdə onun ayrı açarını ləğv edin və ya inteqrasiyanın açarını dəyişdirin. Əgər podratçı üçün ümumi sirr istifadə olunubsa, onu bütün əlaqəli servislərdə dəyişməli olacaqsınız. Buna görə də xarici icraçılar üçün ayrı açarlar uçot tələb edir, lakin botu, saytı və ya sifarişlərin emalını dayandırmaq riski olmadan girişi nöqtəvi şəkildə bağlamağa imkan verir.