Not: Bu içerik eğitim amaçlıdır; hukuki tavsiye değildir ve kumar oynamayı teşvik etmez. Çevrimiçi oyunlarla ilgili düzenlemeler ülke ve bölgeye göre önemli ölçüde değişebilir; bir sistem tasarlıyorsanız hedef yargı alanının güncel teknik gereksinimlerini ve lisans koşullarını ayrıca doğrulamanız gerekir. Reşit olmayanlara yönelik kullanım veya erişim tasarımı bu bağlamda değerlendirilmemeli ve engellenmelidir.

Online casino yazılım mimarisi neden “RNG + bulut + güvenlik” üçlüsüne dayanır?

Çevrimiçi casino platformları (slot, masa oyunları, canlı casino entegrasyonları vb.) teknik olarak üç kritik soruyu aynı anda cevaplamak zorundadır:

• Adillik ve bütünlük: Oyun sonuçları öngörülemez mi ve sonradan manipüle edilemez mi?
• Ölçeklenebilirlik: Trafik dalgalanmalarında gecikme/çökme olmadan hizmet sürdürülebilir mi?
• Güvenlik ve denetlenebilirlik: API’ler, anahtarlar, ödeme ve oyuncu verisi uçtan uca korunuyor mu; denetim izi var mı?

Bu nedenle “casino yazılım teknolojileri” konuşulurken genelde RNG (rastgelelik), bulut tabanlı mimari ve güvenlik kontrolleri birlikte ele alınır.

1) RNG temeli: CSPRNG/DRBG nedir, ne değildir?

Online oyunlarda “RNG” günlük kullanımda tek bir kutu gibi görünse de, modern sistemlerde sonuçlar çoğu zaman kriptografik güvenli pseudo-rastgelelik (CSPRNG) üreten bir DRBG (Deterministic Random Bit Generator) ile üretilir. NIST’in DRBG rehberi, yaygın DRBG yapılarını (ör. Hash_DRBG, HMAC_DRBG, CTR_DRBG) ve bunların nasıl kurulup test edilmesi gerektiğini anlatır. Teknik tasarımınızda DRBG seçimi, tohumlama (seed), yeniden tohumlama (reseed) ve sağlık kontrolleri birlikte düşünülmelidir. Kaynak: NIST SP 800-90A Rev.1.

RNG’de iki katman: entropi kaynağı + DRBG

• Entropi kaynağı: Tahmin edilemeyen fiziksel/işletim sistemi olaylarından toplanan “ham” rastgelelik. (Pratikte çoğu platform OS/host entropisine dayanır.)
• DRBG (CSPRNG): Entropiden aldığı tohumu kullanarak çok sayıda rastgele bit üretir; performans ve güvenlik dengesi sağlar.

Önemli sınır: DRBG deterministiktir; aynı seed ve aynı iç durumla aynı çıktıyı verir. Bu yüzden asıl risk alanları genellikle algoritmadan çok seed/entropi yönetimi, erişim kontrolü ve kayıt/audit konularında ortaya çıkar.

Pratik tasarım kararı: “RNG servisi” ayrı bir bileşen olmalı mı?

Yaygın iki yaklaşım vardır:

• Merkezi RNG servisi: Oyun servisleri, güvenliği sıkılaştırılmış tek bir RNG API’sinden rastgelelik ister. Avantajı: anahtar/seed yönetimini tek yerde toplamak. Dezavantajı: gecikme ve tek hata noktası riski.
• Gömülü RNG kütüphanesi: Her oyun servisi standart bir kütüphane ile DRBG kullanır. Avantajı: düşük gecikme. Dezavantajı: dağıtık güncelleme, yanlış konfigürasyon ve sürüm uyumsuzluğu riski.

Hangi yaklaşım seçilirse seçilsin, denetlenebilirlik (hangi sürüm, hangi konfigürasyon, hangi anahtar/seed politikası) ve erişim sınırlaması (kim RNG’ye ne zaman, hangi kapsamda erişebilir) açıkça tasarlanmalıdır.

2) “Provably fair” ve doğrulanabilir rastgelelik: Ne sağlar, neyi sağlamaz?

“Provably fair” genelde şu fikre dayanır: Sunucu, bir server seed için önceden bir taahhüt (commit) yayınlar (ör. hash), oyuncu bir client seed seçer, birlikte bir nonce ile sonuç üretilir. Tur bitince server seed açıklanır ve oyuncu aynı hesapla sonucu doğrulayabilir.

Sağladığı fayda

• Sonuç değiştirildi mi? Uygulama doğruysa, belirli bir tur için sunucunun sonradan seed değiştirerek sonucu “yeniden yazması” zorlaşır.
• Şeffaflık: Oyuncu veya denetçi, belirli turları bağımsız olarak tekrar hesaplayabilir.

Yaygın yanlış güven: “Provably fair her şeyi kanıtlar”

Provably fair, çıktı doğrulaması sağlasa bile aşağıdakileri tek başına garanti etmez:

• Yorumlama/mapping doğruluğu: Rastgele baytların oyun sonucuna (ör. rulet sayısı, kart dağıtımı) nasıl çevrildiği hatalı veya taraflı olabilir.
• Seed yaşam döngüsü yönetişimi: Taahhüt (commit) mekanizması bulunsa bile, seed’in nasıl üretildiği, nasıl döndürüldüğü (rotation) ve hangi kontrollerle yönetildiği net değilse seçim yanlılığı (cherry-picking) benzeri riskler teorik olarak gündeme gelebilir. Ledger Journal’da yayımlanan analiz, provably fair tasarımlarında bu tür yönetişim/şeffaflık eksiklerinin güven iddiasını zayıflatabileceğini tartışır. Kaynak: Ledger Journal (2016) analizi.

Bu nedenle provably fair iddiaları değerlendirilirken yalnızca “hash doğrulaması var mı?” değil; seed yaşam döngüsü, mapping kodu ve değişiklik yönetimi de incelenmelidir.

VRF/VRaaS (ör. Chainlink VRF) ne zaman anlamlıdır?

Blockchain tabanlı oyunlarda veya zincir üstünde doğrulama gereksiniminde, Verifiable Random Function (VRF) yaklaşımları kriptografik bir kanıtla rastgeleliğin doğrulanabilmesini hedefler. Chainlink VRF gibi servisler, “rastgelelik + kanıt” üretip zincir üzerinde doğrulamaya imkân tanıdığını açıklar. Kaynak: Chainlink VRF.

Ancak VRF/VRaaS çözümleri de entegrasyon maliyeti, gecikme ve uygulama hatalarına açıktır. Konunun tasarım zorluklarını ele alan akademik bir tartışma için bkz. IACR ePrint 2024/957.

3) Denetim ve sertifikasyon: “RNG çalışıyor” demek neye dayanır?

Birçok pazarda düzenleyici ve operatör pratiklerinde, oyunların ve platform bileşenlerinin bağımsız test laboratuvarlarınca doğrulanması beklenir. GLI, etkileşimli oyun sistemleri ve RNG testleri dahil birçok standardın referans noktası olarak anılır. Kaynak: GLI Standards.

Benzer şekilde iTech Labs gibi laboratuvarlar, RNG, RTP ve oyun doğrulama kapsamlarını kamuya açık şekilde özetler. Kaynak: iTech Labs FAQ.

Rapor okurken sorulacak 6 soru

• Kapsam: Test “ham RNG çıktısını” mı, yoksa “oyun sonucu mapping’ini” mi kapsıyor?
• Sürümleme: Hangi oyun sürümü, hangi RNG kütüphane sürümü test edildi?
• Konfigürasyon: Prod ile test ortamı aynı anahtar/seed politikalarını kullanıyor mu?
• Değişiklik sonrası plan: Canlıda güncelleme olunca yeniden doğrulama/recertification var mı?
• Kayıt ve iz: İnceleme için yeterli audit trail tutuluyor mu?
• Erişim kontrolleri: RNG/seed’e erişebilen roller sınırlandırılmış mı?

4) Bulut tabanlı mimari: Oyun motoru nasıl ölçeklenir?

Bulut tabanlı mimaride amaç yalnızca “daha çok sunucu” değildir. Oyun platformlarında tipik hedefler: düşük gecikme, yük altında tutarlılık, güvenli anahtar yönetimi ve denetlenebilir değişiklik süreçleridir.

Referans bileşenler (yüksek seviye)

• Kimlik ve oturum: Oyuncu kimliği, oturum yönetimi, MFA/cihaz parmak izi gibi kontroller.
• Oyun orkestrasyonu: Oyun başlatma, tur yönetimi, istemci durum senkronizasyonu.
• Oyun motoru(ları): Slot/masa oyunu kuralları, ödeme tablosu, mapping, RNG çağrıları.
• Ödeme/para hareketleri: Cüzdan/ledger, limitler, mutabakat, geri ödeme akışları.
• Risk ve suistimal izleme: Anomali tespiti, bot davranışı, hesap ele geçirme sinyalleri.
• Günlükleme ve denetim izi: Değiştirilemez/korumalı loglar, olay korelasyonu.

State yönetimi: “Stateless” her zaman mümkün mü?

Oyun turu gibi süreçler doğal olarak state üretir. Pratik yaklaşım, oyun servislerini mümkün olduğunca stateless tutup state’i:

• ya bir event log/ledger’de,
• ya da tutarlı bir veri katmanında

yönetmektir. Bu, hem ölçeklemeyi kolaylaştırır hem de audit trail için daha net bir temel sağlar. Ancak her tasarımın, gecikme ve veri tutarlılığı (consistency) ihtiyaçlarına göre ayrı değerlendirilmesi gerekir.

5) API ve SDK güvenliği: En geniş saldırı yüzeyi

Online platformlarda oyun istemcisi, ödeme entegrasyonları, CRM, KYC/AML sağlayıcıları ve analitik araçları derken çok sayıda API ortaya çıkar. OWASP’ın API Security rehberi, modern API’lerde en sık görülen risk sınıflarını özetler ve yüksek hacimli platformlarda doğrudan uygulanabilir. Kaynak: OWASP API Security Project.

Casino mimarilerinde sık görülen API riskleri (genel çerçeve)

• Kırık yetkilendirme: Hesap, cüzdan veya oyun turu kaynaklarına yatay/dikey erişim hataları.
• Aşırı veri açığa çıkarma: Profil/oturum/cihaz verisinin gereksiz dönmesi.
• Rate limiting eksikliği: Bonus/ödeme/oyun başlatma uç noktalarında kötüye kullanım.
• Güvensiz doğrudan nesne referansı (IDOR): Basit ID tahminiyle veri çekme.
• Günlükleme kör noktaları: Olaylar var ama korelasyon yok; adli inceleme zorlaşır.

Pratik kontrol seti (uygulanabilir)

• OAuth/OIDC ve kısa ömürlü token: Oturum belirteçlerini kapsam (scope) ve süre ile kısıtlayın.
• RBAC/ABAC: Operasyon ekipleri için en az ayrıcalık (least privilege).
• İmzalı istekler: Özellikle sunucudan sunucuya kritik çağrılarda bütünlük doğrulaması.
• Idempotency: Ödeme/transfer uç noktalarında çift çalışmayı engelleyin.
• Sürümleme: API ve oyun protokollerinde geriye uyumluluğu planlayın.

6) Anahtar yönetimi ve HSM: RNG kadar kritik bir katman

RNG/DRBG güvenliği pratikte çoğu zaman anahtar ve gizli materyal yönetimine bağlanır: seed’ler, imzalama anahtarları, token imzalama anahtarları, servis kimlikleri vb. Bu noktada HSM/KMS gibi çözümler devreye girer. NIST’in CMVP kapsamındaki FIPS 140-3 güvenlik politikaları, kriptografik modüllerin nasıl belgelendirildiğine dair örnek sunar (örnek doküman: NIST/CSRC FIPS 140-3 security policy PDF).

Minimum iyi uygulamalar

• Merkezi secret yönetimi: Kod içinde sabit secret yok; rotasyon politikası var.
• Anahtar erişim denetimi: İnsan erişimi kısıtlı; kırılma senaryoları (break-glass) loglanır.
• Kripto envanteri: Hangi servis hangi anahtarı hangi amaçla kullanıyor net.
• Denetim izi: Anahtar oluşturma/rotasyon/silinme olayları ayrı izlenir.

7) Canlı sistemlerde güven: İzleme, değişiklik yönetimi ve yeniden sertifikasyon

Bir platform “yayına çıktıktan sonra” riskler bitmez; asıl karmaşa sürüm güncellemeleri, A/B testleri, performans optimizasyonları ve altyapı değişiklikleriyle başlar. Bu nedenle canlı sistem için:

• Change management: Oyun mantığı, RNG kütüphanesi, mapping tablosu değişirse ne olur?
• Gözlemlenebilirlik: Oyun turları, hata oranları, anomali sinyalleri ve güvenlik olayları birlikte izleniyor mu?
• Yeniden doğrulama planı: Denetim/sertifikasyon kapsamındaki bileşenler değişince tekrar test akışı var mı?

Bu başlıklar, birçok standardın pratikte önem verdiği “süreklilik” boyutunu temsil eder. Ancak gereksinimler yargı alanına ve kurumsal politikalara göre değişebileceğinden, hedef pazar için güncel düzenleyici rehberlerin ayrıca kontrol edilmesi gerekir.

8) Mimari kontrol listesi: Teknik ekipler için hızlı öz değerlendirme

RNG/Adillik

• DRBG seçimi ve tohumlama/reseed politikası tanımlı mı? (NIST SP 800-90A referans alınarak)
• Entropi/seed materyali erişimi sınırlandırılmış ve loglanıyor mu?
• Mapping (byte → sonuç) açıkça sürümleniyor ve test ediliyor mu?
• Provably fair uygulanıyorsa doğrulama aracı, dokümantasyon ve denetim kapsamı net mi?

Bulut ve operasyon

• Oyun motoru bileşenleri yatay ölçeklenebiliyor mu, kritik state nasıl yönetiliyor?
• Dağıtım stratejisi (blue/green, canary) ve geri dönüş planı var mı?
• Audit loglar değiştirilemez şekilde saklanıyor mu (en azından yetkisiz değişikliklere karşı korunuyor mu)?

API/SDK güvenliği

• OWASP API risklerine karşı yetkilendirme, rate limit, input doğrulama ve izleme uygulanıyor mu?
• Sunucudan sunucuya çağrılarda güçlü kimlik doğrulama ve imza doğrulama var mı?
• Ödeme/transfer akışlarında idempotency ve mutabakat kontrolleri var mı?

Anahtar yönetimi

• Secret’lar KMS/HSM gibi kontrollü bir katmanda mı?
• Rotasyon, erişim politikaları ve kırılma senaryoları (break-glass) belgeli mi?
• Kriptografik modül/servis gereksinimleri (örn. FIPS gibi) hedef pazara göre değerlendirildi mi?

Sonuç: Güvenilir mimari “tek bir teknoloji” ile gelmez

Online casino yazılımlarında güven ve ölçek, tek başına “iyi bir RNG” veya “buluta taşımak” ile sağlanmaz. NIST’in DRBG yaklaşımı gibi teknik temeller (SP 800-90A), GLI/iTech Labs gibi bağımsız test pratikleri (GLI, iTech Labs) ve OWASP’ın API güvenliği çerçevesi (OWASP API Security) birlikte ele alındığında daha sağlam bir mimari resmi ortaya çıkar.

Eğer bu konuyu bir ürün gereksinimine dönüştürüyorsanız, bir sonraki adım “mimari diyagram” çizmekten çok kapsamı net bir tehdit modeli ve denetim/yeniden sertifikasyon planı oluşturmaktır.