Cloudflare Access token sızıntısında CI/CD erişimi nasıl geri alınır?

Bir CI işi Cloudflare Access ile korunan bir uygulamaya servis tokeni üzerinden bağlanıyorsa, anahtarın sızması yalnız güvenlik olayı değildir: aynı anahtar kapatıldığında dağıtım ve entegrasyon işleri de durabilir. Cloudflare'in 11 Kasım 2026 duyurusuna göre GitHub'ın gizli anahtar taraması, herkese açık depolara sızan Cloudflare Access servis tokeni sırlarını tespit edip Cloudflare'e bildiriyor. Access etkilenen tokeni devre dışı bırakıyor ve hesap yöneticilerine e-posta gönderiyor.

Yeni korumanın kapsamı nedir?

Bu akış, Cloudflare Access service token Client Secret değerinin herkese açık GitHub deposunda görünmesi için duyuruldu. Cloudflare, 26 Ağustos 2026 ve sonrasında oluşturulan sırların tanınabilir bir biçimi olduğunu söylüyor. Başka tarama araçları bu biçimi arayabilir; ancak bir metin eşleşmesi sırrın geçerli olduğunu veya kontrol toplamının doğrulandığını tek başına kanıtlamaz. Eski 64 karakterlik sırlar için aynı biçim kuralı geçerli değildir. Özel depoların, CI günlüklerinin veya başka sır türlerinin otomatik olarak bu mekanizmayla korunduğunu varsaymamak gerekir.

Sızıntı bildirimi geldiğinde hangi sıra izlenmeli?

1. Etkilenen tokeni ve bağımlı işleri belirleyin. Hangi pipeline, sunucu veya uygulamanın bu kimlikle Access arkasındaki kaynağa bağlandığını envanterden çıkarın. Token zaten devre dışı olduğu için oluşan 401/403 hatalarını iş etkisiyle eşleyin.

2. Yeni sırrı üretip güvenli dağıtın. Cloudflare'e göre sızan token yeniden etkinleştirilmeden önce sırrı döndürülmeli. Bu olayda eski sır için geçiş süresi yoktur; rotasyon eski sırrı hemen geçersiz kılar. Yeni değeri kaynak koduna, commit'e veya düz metin CI çıktısına koymadan ilgili gizli değişkenleri güncelleyin.

3. Tokeni yeniden etkinleştirip erişimi sınayın. Yeni sırrı bağımlı ortamlara dağıttıktan sonra Cloudflare'deki tokeni yeniden etkinleştirin. Ardından kontrollü bir çağrıyla doğru ortam ve yetkiyi doğrulayın; başarısız işleri yeniden çalıştırıp beklenmeyen erişimleri gözden geçirin.

Cloudflare'in servis tokeni belgeleri kimliğin Client ID ve Client Secret parçalarından oluştuğunu, rotasyon ve iptal yollarını açıklar. Duyurudaki özel sızıntı kurtarma davranışı, sıradan planlı rotasyondan ayrıdır: geçiş süresi olmadığı için değişiklik takvimi ve geri dönüş planı önceden hazır olmalıdır.

Bir sonraki olaydan önce hazırlanacak üç kontrol

İlk kontrol token envanteridir: amaç, sahibi, ortam, eriştiği uygulama ve bitiş tarihi bilinmeyen bir sır için müdahale yavaşlar. İkincisi ortam ayrımıdır: test ve üretim aynı sırla çalışıyorsa tek iptal iki ortamı etkileyebilir. Üçüncüsü bildirimden çalışır duruma dönüş provasıdır: alarmın kime gittiği, sırın nerede değiştirileceği, hangi sentetik isteğin başarıyı göstereceği ve hangi logun inceleneceği yazılı olmalıdır. Bunlar Cloudflare'in otomatik taramasının yerine geçmez; olay sonrası süreyi ve belirsizliği yönetmek için editoryal önerilerdir.

Codiatech açısından karar noktası

Cloudflare Access kullanımı her proje için varsayılamaz. Ancak bulut ve DevOps yönetimi ile sistem entegrasyonu kapsamındaki makineden makineye kimlikler aynı soruyu doğurur: bir anahtar aniden iptal edilirse hangi iş etkilenir ve kim nasıl geri döner? Codiatech, mevcut altyapının kimlik ve dağıtım bağımlılıklarını proje bağlamında değerlendirebilir. Somut bir envanter ve müdahale akışı için iletişime geçin.

Token rotasyonunda hata durumlarını yönetin

Sızan Access service token secret değeri için kurtarma sırasını otomasyonun çalışma yönergesine yazın. Cloudflare’in duyurusuna göre devre dışı bırakılan token yeniden etkinleştirilmeden önce sırrın döndürülmesi gerekir; eski sır için geçiş süresi yoktur. rotate isteğine gelecekteki bir son kullanma tarihi verilirse API 400 dönebilir; sır döndürülmeden yeniden etkinleştirme girişimi 409 ile reddedilir. Bu yanıtları genel ağ hatası gibi sonsuz kez yinelemek yerine insan müdahalesi gerektiren açık durumlara çevirin.

Yeni secret yalnız yetkili gizli değişken depolarına dağıtıldıktan sonra tokeni etkinleştirip kontrollü bir Access çağrısı yapın. Başarılı çağrıdan sonra bağımlı CI işini tekrar çalıştırın; eski secret ile erişimin artık başarısız olduğunu ayrıca doğrulayın. Bu kontrol, erişimin geri geldiğini gösterir; olayın bütün etkilerini veya geçmişteki yetkisiz erişimi tek başına dışlamaz.

Kaynaklar

• GitHub automatically detects leaked Access service tokens — Cloudflare changelog, 11 Kasım 2026.

• Service tokens — Cloudflare One belgeleri, servis tokeni oluşturma ve yönetimi.