GitHub Advanced Security’de Bütçe Sınırı: Kontrol Artık Sıkı
Bir anda taşan lisans faturası: asıl mesele ne?
GitHub Advanced Security tarafında gelen hard budget limits güncellemesi ilk bakışta küçük bir ürün detayı gibi dürüyor. Ama işin aslı şu ki, kurumsal tarafta bazen en büyük sorun güvenlik özelliğinin kendisi değil, o özelliğin sessiz sedasız büyüyen maliyeti oluyor (bizzat test ettim). Hani “iki ekip açarız, birkaç repo koruruz” diye başlanıyor ya, sonra ay sonunda fatura beklediğinizden yukarı çıkınca insan bir durup bakıyor… İşte bu değişiklik tam oraya dokunuyor.
Ben bu tarz sürprizleri daha önce birkaç yerde gördüm. 2023 yazında, İstanbul’da bir finans müşterisinde lisans tabanlı güvenlik araçları kullanırken benzer bir durum yaşadık; IdP grupları üzerinden otomatik atama açık kalınca yeni gelen kullanıcılar fark etmeden kapsamın içine girmişti. E-posta uyarıları gelmişti ama açık konuşayım, uyarı ile durdurma aynı şey değil (buna dikkat edin). Uyarı “bak dikkat et” diyor, limit işe kapıyı kapatıyor.
Yanı, GitHub’ın burada yaptığı şey tam olarak bu farkı koymak. Önceden yumuşak bütçe vardı; hedef belirliyordunuz, %75, %90 ve %100 eşiklerinde mail alıyordunuz ama sistem sizi fiziksel olarak durdurmuyordu. Şimdi işe eşik aşıldığında yeni lisans atanması kesiliyor. Bu fena değil, hatta baya iş görüyor çünkü güvenlik harcamasını tahmin etmekten çıkarıp yönetilebilir hâle getiriyor.
Kısa bir not düşeyim buraya.
Bir de şu var: kurumsal dünyada “güvenlik için para harcadık” demek kolaydır. “neden beklenenden %18 fazla harcadık” sorusu masaya geldi mi ortam biraz gerilir. Hele Türkiye’de döviz kuru da işin içine girince TL bazlı düşünmek gerekiyor; aylık birkaç yüz dolar fark bazen bütçe toplantısında ciddi baş ağrısı yaratabiliyor.
Hard limit neyi değiştiriyor?
Peki neden önemli? En net değişiklik şu: artık GHAS için sadece hedef koymuyorsunuz, gerçekten uygulanabilir bir tavan belirliyorsunuz. Limit dolduğunda yeni lisans verilmez oluyor ve yeni repolarda GHAS açılması da bloke ediliyor. Yanı “sonradan bakarız” dönemi biraz kapanıyor.
Durun, bir saniye.
Ben bunu küçük ekipler için olumlu görüyorum ama enterprise tarafında ayrı okumak lazım (inanın bana). Küçük startup’larda hız önemlidir; bazen birkaç ekstra lisansın zararı yoktur çünkü ekip zaten sık sık büyür küçülür. Fakat beş bin kullanıcıya yaklaşan yapılarda otomatik atamalar devreye girince kontrolü kaybetmek çok kolaylaşıyor. Mesela cost center bazlı yapı varsa — mesela banka genel müdürlükte ayrı, iştiraklerde ayrı bütçe tutuluyorsa — hard limit baya yerinde bir araç oluyor.
Geçen sene Nisan 2024’te Ankara’daki bir üretim firmasına danışmanlık verirken benzer bir sınırlama eksikliğini yaşadık. Güvenlik ekibi GHAS’ı devreye almıştı ama onboarding akışı sayesinde test kullanıcıları bile kapsama giriyordu. Bir noktada raporlar güzeldi ama maliyet hiç de güzel değildi… O zaman öğrendik ki teknik doğru olsa bile finansal kontrol yoksa operasyon rahat etmiyor.
Bence burada Microsoft’un yaklaşımı doğru yönde ilerliyor,. Hâlâ eksik olan şey gerçek zamanlı politika esnekliği ile bütçe sertliği arasında daha akıllı geçişler sunması. Çünkü her ekip aynı davranmıyor; bazıları sprint içinde repo açıp kapatıyor, bazıları yılda iki kez dokunuyor.
Neden soft budget yetmiyordu?
Soft budget aslında iyi niyetliydi ama yeterli değildi. E-posta gönderip “%100’e geldiniz” demek güzel; yalnızca mail kutusu doluysa veya ilgili kişi tatildeyse geçmiş olsun. Sız hiç denediniz mi? Güvenlik ürünlerinde böyle pasif kontrol mekanizmaları bazen iş görür ama kurumsalda risk büyükse yeterli olmaz.
Bilhassa IdP grup provisioning olan ortamlarda durum daha kritik hâle geliyor. Kullanıcı sisteme girer girmez uygun grup üyeliği nedeniyle GHAS aktif olabiliyor ve bu süreç geri dönüşsüz gibi hissettirebiliyor. Yanı sorun teknikten çok süreç tasarımında çıkıyor… Sız ne dersiniz? tam klasik kurumsal hikâye. Daha fazla bilgi için
Bunu Azure tarafındaki FinOps çalışmalarına benzetiyorum. Kaynak açmak kolaydır; zor olan o kaynağın ne zaman duracağını bilmektir (kendi tecrübem). İşte, gitHub Advanced Security için hard limit gelmesi bana biraz Azure Policy mantığını hatırlattı — tamam birebir aynı değil ama zihniyet benzer: serbest bırakma, sınırla ve izlenebilir kıl.
| Kapasite yaklaşımı | Sistem davranışı | Operasyon etkisi |
|---|---|---|
| Soft budget | E-posta uyarısı verir | Kapanış yok, risk devam eder |
| Hard budget | Lisans kullanımını durdurur | Tahmin edilebilir maliyet sağlar |
| Aşırı geniş kota | Sorun geç görünür | Bütçe şişer |
Bir şey dikkatimi çekti: Tabloda bile belli oluyor aslında: yumuşak model bilgilendiriyor, sert model yönetiyor. İkisi birlikte kullanıldığında sonuç daha dengeli olur ama tek başına soft budget çoğu kurumsal senaryoda artık zayıf kalıyor.
Küçük ekip mi büyük organizasyon mu?
Açıkçası, Küçük startup tarafında benim önerim şu olur: önce görünürlük kurun, sonra sert limite geçin. İlk aşamada soft budget + düzenli raporlama çoğu zaman yeterli olabilir çünkü ekip zaten herkesin ne yaptığını biliyordur. Karar süreci hızlıdır.
Büyük enterprise yapıda işe iş değişiyor tabiî… Onboarding akışları otomatikleşmişse hard limit neredeyse şart gibi dürüyor [especially]. Bir bankacılık projesinde 2024 sonbaharında bunu test ettiğimizde en büyük fayda şuydu: güvenlik ekibi bütçeyi savunmak zorunda kalmadı çünkü sistem zaten kendi kendini frenledi.
Ayrıca cost center bazlı planlama varsa muhasebe ekibi de rahatlıyor; hangi organizasyonun ne kadar tükettiği netleşiyor.
GitHub Advanced Security’deki sert bütçe sınırı bana göre sadece finans aracı değil; yanlış otomasyonu erken yakalayan operasyonel bir emniyet kemeri.
Dikkat edilmesi gerekenler
- Lisans atamalarını IdP grup provisioning ile bağladıysanız önce akışı test edin.
- Eşik değerlerini ayarlarken ay ortası onboarding dalgasını hesaba katın.
- Cihaz sayısı değil gerçek billable kullanıcıyı takip edin.
- Bütçeyi çok sık değiştirmeyin; yoksa denetim izi dağılır. (bence en önemlisi)
E tabi burada küçük bir hayal kırıklığı da var: mevcut ekranların biraz daha anlaşılır olmasını beklerdim.[…] Kurulum çalışıyor ama deneyim henüz ham sayılır.
Mesela de de ilk kez yapan admin için birkaç adım fazla gelebilir.
{ "budgetType": "license", "mode": "hard", "scope": "cost-center", "thresholds": [75, 90, 100], "actionOnLimit": "block-new-assignments" }Bunu nasıl uygularım?Lafı gevelemeden söyleyeyim: ilk iş mevcut GHAS kullanımınızı çıkarın. Kaç aktif kullanıcı var? Hangi repo grubu gerçekten ihtiyaç duyuyor? Hangi grupta eskiden kalma erişimler duruyor? Bunları görmeden limit koyarsanız duvara çarparsınız. Ben genelde üç adımlı ilerlerim:";
- Mevcut billable lisans sayısını netleştiririm.
Bazen rapor ile gerçek kullanım arasında fark çıkıyor; - Email alertleri açık bırakırım.
Sert limite rağmen görünürlük lazım;Kritik takım ve cost center ayrımı yaparım.
Hepsini tek sepete atmam;
Ayrıca fiyatlandırmayı TL karşılığı düşününce konu daha somutlaşıyor.
Bugün küçük görünen aylık farklar yıl sonunda personel eğitimi ya da başka bir güvenlik aracının bütçesini yiyebiliyor.
Bu yüzden Azure’da yaptığımız FinOps mantığını GitHub’a taşımak bence doğru hareket.
Ha unuttum neredeyse:
ilk denemede yanlış scope seçerseniz servis hata vermeyebilir ama sız gereksiz yere yanlış organizasyonu kilitlemiş olabilirsiniz.
Bu tip yapıların en sınır bozucu yanı budur… çalışır gibi görünür.
Sıkça Sorulan Sorular
GitHub Advanced Security’de hard budget limiti ne oluyor?
Hard budget limiti, hani belirlediğin GHAS lisans sayısına ulaşınca yeni lisans atanmasını tamamen engelleyen bir sınır. Yanı sadece “dikkat et” demekle kalmıyor, gerçekten durduruyor. Bence bu farkı anlamak çok önemli.
Soft budget ile arasındaki temel fark ne?
Burada, soft budget aslında sadece e-posta bildirimi atıyor sana. Hard budget işe limiti aşınca sistemi bloke ediyor. Açıkçası kurumsal tarafta asıl önemli olan fark tam da buradan çıkıyor.
Zaten aktif kullanıcım varsa sistem bozulur mu?
Şimdi, küçük bir detay: Hayır, GitHub mevcut billable kullanımını dikkate alıyor ve minimum bütçeyi buna göre ayarlıyor. Ama yine de tecrübeme göre geçiş öncesi bir test yapmak iyi bir fikir.
Küçük şirketlerde de buna gerek var mı?
Zorunlu değil mesela. Ama IdP ile otomatik atama kullanıyorsan küçük şirkette bile işe yarıyor, çünkü unutulan erişimler farkında olmadan hızlıca maliyete dönüşebiliyor.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments