Cloudflare erişimi: üyelikle mi yönetmeli, partnerlikle mi?

Pratikte beş yol var ve bunlardan biri daha baştan elenmeli. Hangisini seçtiğin, sadece rahatlığı değil; sorumluluğun, faturanın ve iş bittiğinde erişimi geri almanın kimde olduğunu belirliyor.

• Şifre paylaşmak: En yaygın, en kötü yol. Kimin neyi değiştirdiği belli olmaz, iki adımlı doğrulama işlevsizleşir, çalışma bittiğinde şifre değiştirilmediyse erişim sessizce devam eder. Cloudflare'in üyelik sistemi tam da bunu gereksiz kılmak için var.
• Üye daveti (member + rol): Hesap senin kalır, ajansı ya da ekip arkadaşını kendi Cloudflare kullanıcısıyla, sınırlı yetkiyle davet edersin. Varsayılan ve çoğu durumda doğru yol.
• Partner (Tenant) modeli: Hesabı, Cloudflare ile partner sözleşmesi olan taraf açar ve yönetir; sen o yapının içindeki bir hesapsın.
• Organizations: Birden fazla Cloudflare hesabını tek çatı altında toplamak için; Enterprise hesap gerektiriyor ve public beta aşamasında.
• API token: İnsana değil, araca verilen erişim. Bir deploy hattı ya da otomasyon için doğru cevap genellikle budur — kullanıcı davet etmek değil.

API token'ları diğerlerinin alternatifi değil, tamamlayıcısı: bir script'in cache temizlemesi ya da DNS kaydı yazması gerekiyorsa, o iş için kapsamı daraltılmış bir token üretmek, o script'i çalıştıran kişiye hesap yetkisi vermekten çok daha güvenli. Token'ı iptal etmek de bir kişiyi hesaptan çıkarmaktan kolaydır.

Üye daveti, Cloudflare panelinde Manage Account → Members ekranından yürür. Davet gönderebilmek için iki şart var: davet eden kişinin Super Administrator rolüne ve doğrulanmış bir e-posta adresine sahip olması (Cloudflare Docs). Davet edilen kişi kendi Cloudflare kullanıcısıyla giriş yapar; yani şifre paylaşılmaz, kimin ne yaptığı denetim kayıtlarında ayrışır.

Cloudflare'de yetki, tek bir kutucuk değil bir politika (policy) olarak kurgulanıyor. Her politika üç parçadan oluşur: yetkiyi alan kişi (actor), yetkinin geçerli olduğu kapsam (resource group) ve o kapsamda yapabileceği işler (permission group, yani roller) (Cloudflare Docs).

Üç kapsam: hesap, alan adı, kaynak

• Hesap kapsamlı roller: Hesabın tamamında ve içindeki bütün alan adlarında geçerlidir. Super Administrator, Administrator, Administrator Read Only, Billing, Analytics, Audit Logs Viewer, Cache Purge, DNS ve Minimal Account Access gibi roller bu kapsamdadır.
• Alan adı kapsamlı roller: Hesaptaki belirli bir alan adı için geçerlidir. Birden fazla markası ya da hem üretim hem test alan adı olan bir hesapta, ajansı yalnızca ilgili alan adına bağlamanın yolu budur.
• Kaynak kapsamlı roller: En ince ayar — tek bir Access uygulaması ya da tek bir Tunnel gibi belirli bir kaynağa yetki verir. Cloudflare bu kapsamı beta olarak işaretliyor (Cloudflare Docs).

Rol adları kulağa teknik gelse de seçim aslında basit: ajansın işi neyse rol o olmalı. Sadece performans raporu bakacaksa Analytics, sadece sürüm sonrası cache temizleyecekse Cache Purge, alan adı devri ve kayıt düzenlemesi yapacaksa DNS, siteyi Cloudflare Pages/Workers üzerinde yayınlıyorsa Workers Platform Admin, sadece kurulumu denetleyecekse Administrator Read Only yeterlidir. Super Administrator, üyeleri ve faturayı yönetme yetkisini de kapsar — dışarıdan bir tarafa vermek için gerçekten güçlü bir gerekçe olmalı.

Bir uyarı: bir üyenin efektif yetkisi, kendisine doğrudan verilen izinlerle üyesi olduğu gruplardan miras aldığı izinlerin birleşimidir. İzinler birbirini kısıtlamaz, üst üste eklenir; üstelik Members ekranı yalnızca doğrudan atanan politikaları gösterir, gruptan gelenleri görmek için Groups sekmesine bakmak gerekir (Cloudflare Docs). "Dar rol verdim" diye rahatlamadan önce grup üyeliklerini de kontrol et.

Artıları

• Sahiplik sende kalır. Hesap, alan adı ve fatura ilişkisi markanın adına durur; ajans değiştiğinde taşınacak bir şey yoktur, yalnızca bir üyelik iptal edilir.
• Yetki gerçekten daraltılabilir. Alan adı ve kaynak kapsamlı roller sayesinde "her şeyi görebilir" ile "hiçbir şey yapamaz" arasındaki gri alanı ayarlayabilirsin.
• İz bırakır. Herkes kendi kullanıcısıyla girdiği için denetim kayıtları kimin neyi ne zaman değiştirdiğini gösterir. Şifre paylaşımında bu bilgi tamamen kaybolur.
• Geri alması anlık. İş biterse üyeliği iptal edersin; şifre değiştirmek, ekip bilgilendirmek, unutulan bir oturumu kovalamak gerekmez.
• Ek maliyeti yok. Cloudflare'in belgeleri üye davet etmeyi plana bağlı bir özellik olarak ayırmıyor; yalnızca mevcut bir kullanıcıyı e-posta onayı olmadan doğrudan ekleme Enterprise hesaplara özel (Cloudflare Docs).

Eksileri

• Yönetim yükü sende. Davet etmek, rolü doğru seçmek, ayrılanları temizlemek markanın işi. Kimse hatırlatmaz; altı ay önce ayrılan freelancer hâlâ üye olabilir.
• Rol listesi kalabalık. Onlarca rol arasından doğru olanı seçmek ilk seferde zaman alır ve yanlış seçim ya iş görmez ya da fazla yetki verir.
• Grup mirası şaşırtır. İzinlerin birleşim mantığı yüzünden, dar sandığın bir yetki gruptan gelen bir politikayla genişlemiş olabilir.
• Tek Super Administrator riski. Hesabın tek süper yöneticisi tek bir kişiyse ve o kişiye ulaşılamıyorsa, üyeleri ve faturayı yönetecek kimse kalmaz. En az iki süper yönetici tutmak iyi bir alışkanlık.
• Çok müşterili tarafta ölçeklenmez. Ajans açısından her müşteri ayrı bir davet, ayrı bir hesap, ayrı bir panel demektir; onlarca müşteride bu tablo dağınıklaşır.

Partner modeli, Cloudflare'in Tenant yapısı üzerine kurulu. Cloudflare bunu şöyle tanımlıyor: Tenant API, kanal ve ittifak partnerlerinin müşterileri adına Cloudflare hesaplarını ve hizmetlerini kurup yönetmesine yarayan bir sağlama (provisioning) mekanizmasıdır (Cloudflare Docs). Yani bu, bir markanın panelden açıp kapatabileceği bir ayar değil; iki şirket arasındaki ticari ilişkinin teknik karşılığı.

İşleyişi net: Cloudflare ile partner sözleşmesi imzalandıktan sonra Cloudflare özel bir Tenant hesabı oluşturur ve partnerin kullanıcısını bu hesaba Tenant admin olarak ekler. Tenant admin'ler, Tenant'ın içindeki bütün hesaplar ve alan adları için varsayılan Super Administrator olurlar (Cloudflare Docs). Partner, müşteri hesaplarını API ya da panel üzerinden açar, aboneliklerini tanımlar ve yönetir.

Bunun yanında bir de Organizations var: birden fazla Cloudflare hesabını tek bir üst kapsayıcıda toplayan, hesap başına ayrı üyelik gerektirmeden yönetim sağlayan yapı. Organizations üyeleri alt hesaplarda otomatik olarak Super Administrator yetkisine sahip olur; oluşturmak için Enterprise hesap gerekiyor ve özellik public beta aşamasında (Cloudflare Docs). Kurumsal ölçekte birden çok markayı yöneten yapılar için partner modeline alternatif bir yol.

Artıları

• Kurulum yükü markadan çıkar. Hesap açma, alan adı ekleme, abonelik tanımlama gibi adımlar partner tarafında ve programatik olarak yürür.
• Çok müşterili yönetim için tasarlanmış. Onlarca hesabı tek yapıdan yönetmek, davetlerle uğraşmaktan hem hızlı hem tutarlıdır.
• Tek muhatap. Fatura, destek ve teknik sorumluluk tek elde toplanır; markanın ayrı bir Cloudflare ilişkisi kurması gerekmez.
• Standart kurulum. Aynı güvenlik ve performans ayarlarını her müşteri hesabında tekrarlanabilir biçimde uygulamak mümkün olur.

Eksileri

• Herkes için değil. Tenant yapısı Cloudflare ile imzalanmış bir partner sözleşmesi gerektirir; "biz de partner olalım" diyerek bir öğleden sonrada geçilebilecek bir model değil.
• Varsayılan yetki dar değil, en geniş olanı. Tenant admin, içerideki tüm hesaplarda varsayılan olarak Super Administrator'dır. Üyelik modelindeki "sadece DNS" inceliği burada baştan yoktur.
• Bağımlılık yaratır. Hesabı partner açtıysa, ilişki bittiğinde devir bir teknik iş kalemine dönüşür; üyelik iptal etmek kadar basit değildir.
• Şeffaflık sözleşmeye bağlıdır. Markanın kendi paneline ne kadar erişeceği, ne göreceği ve neyi değiştirebileceği teknik bir varsayılan değil, taraflar arasındaki anlaşmanın konusudur.
• Küçük ölçekte fazla ağır. Tek alan adı ve tek markayla çalışan bir yapı için kurduğu soyutlama, çözdüğü sorundan büyüktür.

Tek alan adı, tek marka ve dışarıdan destek alan bir yapı — yani kozmetik markalarının neredeyse tamamı — için doğru cevap rol kapsamlı üyeliktir. Hesap markanın adına açılır, ajans kendi kullanıcısıyla ve yaptığı işe karşılık gelen rolle davet edilir. Partner modeli, çok sayıda müşteri hesabını sağlayan ve yöneten taraflar için tasarlanmış; bir markanın "daha kolay olsun" diye tercih edebileceği bir menü seçeneği değil.

Erişim verirken işini kolaylaştıracak kısa bir kontrol listesi:

• Hesabı kendi adına aç; alan adı ve fatura ilişkisi markada kalsın.
• Ajansa Super Administrator verme; işine karşılık gelen en dar rolü seç ve mümkünse alan adı kapsamına bağla.
• Hesapta en az iki Super Administrator bulunsun; tek kişiye bağlı hesap tek arıza noktasıdır.
• Herkese iki adımlı doğrulama (2FA) zorunlu olsun.
• Otomasyon ve deploy için kullanıcı değil, kapsamı dar API token üret.
• Üç ayda bir üye listesini ve denetim kayıtlarını gözden geçir; ayrılanları temizle.
• Çalışma bittiğinde üyeliği aynı gün iptal et — "belki lazım olur" diye bırakılan erişimler unutuluyor.

Bu kavramların haritadaki yerini görmek istersen: Cloudflare, Cloudflare üyelik yetkileri, Cloudflare partnerlik ve altyapı tarafında DNS kavramlarına bakabilirsin.