Kisisel API anahtarlari musteri tokenlarina karsi — dogru kimlik bilgisini secmek

"Token" kelimesi Nodetonet'te cok fazla anlam tasir. Android uygulamasina yapistirdiginiz cihaz eslestirme tokeni vardir; bir de panelde birbirine benzeyen ama tamamen farkli seyleri yapan iki API kimlik bilgisi vardir. Bu yazi tam olarak bu ikisi hakkinda — Nodetonet'in REST endpoint'lerine kimlik dogrulama yapanlari.

Bunlari karistirmak "neden bu musteri sahip oldugum tum proxy'leri goruyor?" destek biletlerinin en yaygin nedenidir. Kural tek cumle: kisisel anahtarlar sizin icin, musteri tokenlari musterileriniz icin. Gerisi detay — ama bu detayi goz ardi etmenin guvenlik sonuclari ciddidir.

Iki kimlik bilgisine hizli bakis

Detaylara girmeden once yan yana bir ozet:

Kisisel API Anahtari — hesabiniz, tam erisim

Her Nodetonet hesabinin kontrol panelinin ustunde gorunen tam olarak bir kisisel API anahtari vardir. Bunu siz olarak kimlik dogrulayan ve hesabinizin sahip oldugu tum izinleri tasian uzun omurlu bir bearer token olarak dusunun.

Panel arayuzunun yapabileceği her seyi yapabilir, hatta arayuzun dogrudan aciga cikarmadigi birkaç seyi de:

• Hesabinizin altindaki herhangi bir mobil proxy, rotating proxy veya HTTP tunelini listele, olustur, degistir ve sil.
• Cihaz tokenlarini eslestir ve eslestirmeyi kaldir, kullanim istatistiklerine goz at.
• Kredi yukleme islemlerini tetikle, fatura gecmisini oku.
• Musteri hesaplarini yonet ve onlarin tokenlarini rotasyona sok.

Her kimlik dogrulamali cagri icin header formati aynidir:

curl -H "Authorization: Bearer npk_live_8x2q...z9w7"   https://nodetonet.com/api/v1/proxies

Bu anahtar sizarsa, bir veritabani root sifre sizintisi gibi ele alin. Kontrol paneli kartindan hemen rotasyona sokun — eski anahtar rotate tusuna tikladiginiz anda gecersiz kalir, onu kullanan her calisan script durur ve yeni degerle yeniden deploy edersiniz. Tasarim geregi iki anahtarli gecis suresi yoktur.

Kisisel anahtari ne zaman kullanmali

• Sahip oldugunuz ve kontrol ettiginiz altyapidaki dahili otomasyon scriptleri.
• Hic kendi sistemlerinizin disina cikamayan sunucudan sunucuya entegrasyonlar.
• Yeni musteri kayitlari olusturmak, ardindan onlara musteri tokeni vermek.

Kisisel anahtari hicbir zaman istemci tarafindaki koda, tarayici uzantilarinina, mobil uygulamalara veya kendi sunucularinizin disina cikan hicbir seye gommeyin. Ucuncu taraflarin gozleri ona ulasabilecekse, bunun yerine musteri tokeni kullanin.

Musteri API Tokeni — tek bir downstream musteriye scope'lanmis

Nodetonet'i bir bayi veya beyaz etiketli backend olarak kullaniyorsaniz — kendi markaniz altinda kendi son kullanicilariniza proxy satiyorsaniz — alici basina bir musteri kaydi olusturursunuz ve Nodetonet o kayda bagli bir musteri tokeni yayinlar. Token dar kapsamlidir: yalnizca yapılandirdiginiz limitler dahilinde (thread sayisi, kota, son kullanma tarihi, IP beyaz listesi) o musteriye acikca atanmis proxy'leri gorebilir ve kullanabilir.

Musterinin bakis acisindan token, urunlerine yapistirdiklari veya kodlarindan cagirdiklari opak bir dizedir. Ancak tokenin aciga cikardiği auth yuzeyi cok daha kucuktur:

• Kendi proxy'lerini listeleyebilirler — sizinkileri veya baska bir musterinin proxy'lerini degil.
• Onlara atanan proxy'ler icin kullanim istatistiklerini cekerler.
• Proxy olusturma, silme veya degistirme yapamazlar — bu her zaman sizin sorumlulugunuzdadir.
• Diger musterileri, fatura bakiyenizi veya kendi kapsamlarinin disindaki hicbir seyi goremezler.

Musteri tokenlari ayni Authorization: Bearer header formatini paylasir — backend hangi kapsam ve limitlerin uygulanacagini belirlemek icin token onekini okur.

Sizin belirlediginiz koruma onlemleri

Bir musteri kaydi olusturdugunuzda, tokenlarinin uygulanacagi limitleri siz belirlersiniz:

• Thread limiti — maksimum eslezamani baglanti sayisi. Ayarlama ipuclari icin istemci basina thread limitleri yazisina bakin.
• Bant genisligi kotasi — kullanilan veri uzerine bir cap. Bkz. istemci basina kota limitleri.
• Son kullanma tarihi — sureli erisim icin. Bkz. sureli proxy istemcileri.
• IP beyaz listesi / domain izin-reddi — tokenin nerede kullanilabilecegini kisitla. Bkz. IP izin ve red listeleri.

Kisisel anahtarlarda bu koruma onlemlerinin hicbiri yoktur. Rotasyona sokana kadar kalicidirlar ve hic bir thread limiti, kota veya IP kisitlamasi tasimazlar.

Karar agaci — hangi kimlik bilgisini kullanirim?

Su sorulari sirasyla yanitlayin:

1. Bu kod sahsen sahip oldugum ve kontrol ettigim altyapida mi calisiyor? Evet ise kisisel anahtar kabul edilebilir.
2. Ucuncu bir taraf bu kimlik bilgisini hic gorecek, alacak veya dokunacak mi — dolali da olsa? Evet ise her zaman musteri tokeni kullanin.
3. Bu scriptin yeni proxy olusturmasi, faturalandirmayi yonetmesi veya baska tokenlari rotasyona sokmasi gerekiyor mu? Bunu yalnizca kisisel anahtarlar yapabilir. Provisioning icin kisisel anahtarinizi kullanan bir backend olusturun, ardindan musteriye kapsamli tokenlarini verin.

Guvenlik etkileri ve etki alani

Bu iki turun var olmasinin tum nedeni, bir kimlik bilgisi sizintisindaki hasari sinirlamaktir.

Sizintiilan bir kisisel anahtar bir saldirganin her seye erisimini saglar: onpaylik kredinizi tuketmek icin proxy acabilir, musteri listinizi diyebilir, tum HTTP tunellerinizi silebilir ve sizi kilitlemek icin kimlik bilgilerini rotasyona sokabilir. Kurtarma, bir anahtar rotasyonu ve etkilenen her seyin denetimini gerektirir.

Sizintiilan bir musteri tokeni, saldirganin bir musterinin kotasina erisimini saglar — sizin belirlediginiz thread limiti ve son kullanma tarihi ile sinirli. Panelinize, diger musterilerinize veya faturalandirmaniza ulasamamazlar. Tokeni musteri yonetim ekranindan rotasyona sokarak diger operasyonunuzu etkilemeden gecersiz kilabilirsiniz.

Uygulanmasi gereken model sunudur: kisisel anahtariniz hic sunucunuzun disina cikmaz. Sunucunuz musterileri provision etmek icin onu kullanir. Her musteri yalnizca kendi kapsamli tokenini alir. Bunu bir veritabanina uygulayacaginiz ayrimla ayni sekilde dusunun — root sifre sunucuda kalir, uygulama kullanicilari yalnizca ihtiyac duyduklerini alir.

Kimlik bilgilerini guvenle rotasyona sokmak

Her iki kimlik bilgisi turu de rotasyona sokulabilir, ancak surec ve etki onemli olcude farklidir:

• Kisisel anahtar rotasyonu anlik ve kiricidir — eski anahtar rotate eder etmez calismaktan kesilir. Onu kullanan herhangi bir script veya entegrasyon icin kesinti suresi planlayın. Sifir-kesinti isterseniz rotasyondan once tum kullanim alanlarini guncelleyin (once yeni anahtari tum hedeflere kopyalayin, sonra rotasyona sokun).
• Musteri tokeni rotasyonu yalnizca o musteriye etki eder. Musteriye bildirin, yeni tokeni verin, ardindan rotasyona sokun. Diger hizmetleri etkilenmez.

Tam bir rotasyon kilavuzu icin ne zaman ve neden token rotasyonuna sokulmali yazisina bakin.

Kacınilmasi gereken yaygin hatalar

• Kisisel anahtari musteriye yonelik bir urune gondermek. En tehlikeli hata. Istemci tarafindan Nodetonet API'lerini cagiran her seyi kodunuzda denetleyin.
• Musteri tokenlarinda son kullanma tarihi belirlememek. Abonelik bittikten sonra eski erisimin askida kalmaması icin her musteri tokenina sure siniri koyun.
• Tum otomasyon icin sonsuza kadar kisisel anahtar kullanmak. Birden fazla entegrasyonunuz oldugunda, her scriptin etki alanini sinirlamak icin mumkun olan yerlerde entegrasyon-basına tokenlar olusturun.
• Cihaz eslestirme tokenini API anahtariyla karistirmak. Ilk tokeniniz ve Android eslestirme yazisinda Android agentiyla eslestirilmis token farkli bir kimlik bilgisidir — bir API cagriciyi degil, bir proxy kaynagini tanimlar.

Sirada ne var

• API anahtarinizi anlamak — kisisel anahtar icin format, rotasyon ve yaygin tuzaklar.
• Musteri proxy istemcileri nasil calisir — bu tokenin ait oldugu daha genis bayi ozelligi.
• Token gruplari olusturmak (cihaz havuzlari) — bir musteri tokeninin erisebilecegi rotating havuza birden fazla cihaz atayin.
• REST API: ilk cagriniz — kisisel anahtari kullanan uygulamali bir kilavuz.
• Ucretsiz hesap acin ve kontrol panelinde her iki kimlik bilgisi turunu goruntuleyin.