RBAC ile Erişim Kontrolü: Bahis Panel Kullanıcı Yönetimi

Ekipteki herkesin panelde aynı yetkiye sahip olması, küçük bir operasyonda pratik görünür ama ekip büyüdükçe ciddi bir riske dönüşür. Bir destek temsilcisinin ödeme onaylayabildiği ya da bir analistin API anahtarlarını görebildiği bir yapıda, tek bir ele geçirilen hesap ya da tek bir dikkatsiz tıklama bütün operasyonu etkiler. Rol tabanlı erişim kontrolü (RBAC), izinleri kişilere değil rollere bağlayarak bu riski yönetilebilir kılar.

RBAC'ın temel kavramları

• İzin: Tek bir işlemi yapma hakkı; örneğin "çekim talebini onayla" ya da "oyuncu profilini görüntüle".
• Rol: Birlikte verilen izinlerin adlandırılmış kümesi; örneğin "Destek" ya da "Finans".
• Atama: Bir kullanıcıya bir ya da daha fazla rol verilmesi.

Kural basittir: kullanıcıya doğrudan izin verilmez, rol verilir. Böylece "Finans ekibi neleri yapabiliyor?" sorusunun tek ve net bir cevabı olur; yeni bir çalışanı eklemek de doğru rolü atamaktan ibaret kalır.

Örnek rol matrisi

Her operasyon farklıdır ama aşağıdaki beş rol, çoğu bahis ekibi için iyi bir başlangıç noktasıdır:

• Sahip: Rol atama, entegrasyon ayarları ve kritik yapılandırma. Bir ya da iki kişiyle sınırlı tutulmalı.
• Yönetici: Günlük operasyon ayarları, etkinlik ve pazar yapılandırması. Rol atama yetkisi yoktur.
• Finans: Ödeme ve çekim onayları, mutabakat raporları. Oyuncu verilerinin yalnızca işi için gereken kısmını görür.
• Destek: Oyuncu hesabını görüntüleme, talep yanıtlama, salt okunur işlem geçmişi. Bakiye değiştiremez, ödeme onaylayamaz.
• İzleyici: Raporlar ve panolar. Hiçbir işlem yapamaz.

Matrisi yazılı hale getirmek, yetki tartışmalarını kişisel olmaktan çıkarır. Bir role yeni izin gerektiğinde değişikliği matris üzerinde yap; tek bir kullanıcıya istisna tanımlamak, zamanla kimsenin tam olarak bilmediği bir yetki haritası üretir.

Kontrolü kodda zorunlu kılmak

RBAC'ın en sık bozulduğu yer, yeni eklenen bir uç noktada izin kontrolünün unutulmasıdır. Kontrolü her uç noktanın içinde elle yazmak yerine yönlendirme katmanında ya da tip sisteminde zorunlu kılmak bu hatayı önler. Basit bir örnek:

type Role = "owner" | "admin" | "finance" | "support" | "viewer";
type Permission = "payout:approve" | "player:read" | "config:write" | "report:read";

const MATRIX: Record<Role, readonly Permission[]> = {
  owner: ["payout:approve", "player:read", "config:write", "report:read"],
  admin: ["player:read", "config:write", "report:read"],
  finance: ["payout:approve", "report:read"],
  support: ["player:read"],
  viewer: ["report:read"],
};

export function can(roles: readonly Role[], permission: Permission): boolean {
  return roles.some((role) => MATRIX[role].includes(permission));
}

Varsayılan davranış her zaman reddetmek olmalı: tanımlı olmayan bir izin ya da tanınmayan bir rol erişim vermemeli. Bu kontrol yalnızca sunucuda yapılır; arayüzde butonu gizlemek kullanıcı deneyimi içindir, güvenlik sınırı değildir. API tarafındaki fonksiyon düzeyinde yetkilendirme hataları için API güvenliği rehberimize bakabilirsin.

En az ayrıcalık ilkesi

1. Yeni kullanıcıya en kısıtlı rolle başla; ihtiyaç kanıtlandıkça yetki ekle.
2. Geçici yetki gerekiyorsa bitiş tarihiyle ver ve süresi dolunca otomatik olarak geri al.
3. Rol değiştiren kişi ile değişikliği onaylayan kişi aynı olmasın.
4. Ayrılan çalışanın erişimini aynı gün kapat ve açık oturumlarını sonlandır.
5. Yetkileri dönemsel olarak gözden geçir; kullanılmayan izinleri kaldır.

API anahtarları ve entegrasyon hesapları

API anahtarı bir insan hesabından daha az dikkat çeker ama çoğu zaman daha fazla yetki taşır. Anahtarı kişi için değil iş için oluştur: hangi entegrasyon neyi okuyacak, neyi tetikleyecek? Yalnızca o kadar kapsam ver, mümkünse IP izin listesi ekle ve bir geçerlilik süresi tanımla.

LLCBullet'teki kişisel API anahtarları bu ilkeyi doğrudan uygular. Anahtar oluştururken read:account, read:subscriptions, read:automation ve run:automation kapsamlarından yalnızca gerekenleri seçersin; kapsam sonradan genişletilemez, daha fazla yetki için yeni anahtar oluşturman gerekir. Anahtar oluşturma işlemi Telegram'dan onay ister, böylece hesabına erişen biri senin haberin olmadan anahtar üretemez. Ayrıntılar API anahtarları rehberinde.

Hassas işlemler ve denetim kaydı

• İkinci onay: Ödeme onayı, rol değişikliği ve anahtar oluşturma gibi işlemlere ikinci bir kanal üzerinden onay ekle.
• Değiştirilemez kayıt: Kimin, ne zaman, hangi işlemi yaptığını ekleme yapılabilen ama değiştirilemeyen bir kayda yaz.
• Anında bildirim: Yeni giriş ve yetki değişikliklerinde ilgili kişiye haber ver.

LLCBullet panelinde de benzer katmanlar bulunur: yeni girişler, passkey ekleme ve silme, API anahtarı oluşturma ve oturumların toplu kapatılması Telegram'a sessize alınamayan güvenlik bildirimi olarak gelir; otomasyon görevi işlemleri ise değiştirilemez bir denetim kaydına yazılır.

Dönemsel yetki gözden geçirme

Yetkiler zamanla şişer: bir proje için verilen izin proje bitince unutulur, görev değiştiren biri eski rolünü de korur. Bunu önlemek için gözden geçirmeyi takvime bağla:

1. Her rolün sorumlusu, o roldeki kullanıcı listesini çeyrek dönemde bir onaylar.
2. Uzun süredir giriş yapmamış hesaplar askıya alınır.
3. Sahip ve yönetici rollerindeki kişiler, gerekçeleriyle birlikte yazılı olarak listelenir.
4. Entegrasyon anahtarlarının hâlâ kullanılıp kullanılmadığı ve kapsamlarının gerçekten gerekli olup olmadığı kontrol edilir.
5. Gözden geçirmenin sonucu tarihiyle birlikte denetim kaydına eklenir.

Rol sayısını da makul tut. Her küçük farklılık için yeni rol açmak, matrisi kimsenin tam olarak anlamadığı bir tabloya dönüştürür; birkaç iyi tanımlanmış rol, onlarca özel rolden daha güvenlidir.

Sık yapılan hatalar

• Ortak bir yönetici hesabının birden fazla kişi tarafından kullanılması.
• "Şimdilik" verilen geniş yetkilerin hiç geri alınmaması.
• İzin kontrolünün yalnızca arayüzde yapılması.
• Test ve üretim ortamında aynı anahtarların kullanılması.

Sağlam bir RBAC yapısı; net bir rol matrisi, sunucuda zorunlu kılınan kontroller, dar kapsamlı anahtarlar ve düzenli gözden geçirmeden oluşur. Bu dört parçayı birlikte kurduğunda, tek bir hesabın ele geçirilmesi bütün operasyonu tehlikeye atmaz. Oturum tarafındaki önlemler için aktif oturum yönetimi yazımıza göz atabilirsin.