Etkinlik geçmişi ve ekip rolleri: kim neyi değiştirdi, kim değiştirebilirdi

Ortak girişin yanıtlayamadığı soru

Küçük ekiplerin çoğu tek bir kullanıcı bilgisiyle başlar. İlk olaya kadar çalışır, sonra çok belirli bir biçimde tökezler: bir şey değişmiştir, değişiklik ortadadır ve kimse onu kimin yaptığını ya da yerine ne koyduğunu söyleyemez.

Bu boşluk mahcubiyetten fazlasına mal olur. Kayıt yoksa bir hatayı bir izinsiz girişten ayıramazsınız. Değişikliği güvenle geri alamazsınız, çünkü önceki değeri bilmiyorsunuzdur. Ve süreci düzeltemezsiniz, çünkü ne olduğunu kimse bilmiyorken elinizdeki tek ders "daha dikkatli olalım"dır.

Bir de dışarıdan bakış var. Yönetimsel işlemlerin gözden geçirilebilir bir izi ve anlamlı erişim kontrolü, güvenlik anketlerinde ve ISO 27001 gibi çerçevelerde standart beklentidir; KVKK ve GDPR gibi veri koruma düzenlemeleri de kimin neye eriştiğini gösterebilmenizi bekler. Herhangi bir belge peşinde olsanız da olmasanız da, bu gereklilik zaten kendiniz için isteyeceğiniz şeyi tarif ediyor.

Neler kaydediliyor

Etkinlik geçmişi, ziyaretçinin gördüğünü etkileyebilecek değişiklikleri kapsar: cache purge işlemleri, DNS kaydı değişiklikleri, teslim kuralı değişiklikleri, güvenlik preset'i değişiklikleri — HSTS ile ülke ve ASN kara listeleri dahil — sertifika işlemleri ve hostname değişiklikleri.

Her kayıt onu işe yarar kılan dört şeyi taşır. Kim: gerçek kişi, yani bir alt kullanıcı "hesap" olarak değil kendi adıyla görünür. Ne zaman. Değişikliğin dokunduğu hangi hesap ve yol. Ve önce/sonra, yani önceki değer hafızadan yeniden kurmaya çalıştığınız bir şey olmak yerine orada durur.

Kaydı bir rapordan bir araca çeviren de bu son alan. "Teslim kuralı değişti" size nereye bakacağınızı söyler. "Cache TTL 3600 → 60" ise aynı anda origin trafiğinize ne olduğunu söyler.

Bir şey bozukken okumak

Hesap kenar çubuğundan İzleme → Etkinlik Geçmişi sayfasını açın — /management/cdn/activities.

Olay sırasında işe yarayan sıra şu: önemsediğiniz zaman aralığına daraltın, yalnızca şüphelendiğiniz değişikliğe değil hesabın tamamına bakın ve kayıt başlıklarını değil önce/sonra değerlerini okuyun. Siteyi bozan değişiklik çoğu zaman aklınızdaki değildir; ipucunu genelde sıralama verir — farklı kişilerin beş dakika arayla attığı iki kayıt, hikâyenin kendisidir.

Yoğun bir hesabı okunur kılan şey eylem türüne göre filtrelemektir. Her yayında otomatik purge tetikleyen bir site, aradığınız şey olmayan bir sürü kayıt üretir; onları süzdüğünüzde geriye kalan bir avuç yapılandırma değişikliği genelde baştan sona okunacak kadar kısadır.

Olay dışında aynı sayfa daha sakin bir soruyu yanıtlar: kimsenin söylemediği bir şey mi değişiyor? Ayda beş dakikaya değer.

API'den erişmek

Geçmiş API üzerinden de alınabilir; kaydı arşivliyorsanız, kendi log sisteminize aktarıyorsanız ya da yalnızca kaydırarak okumak istemeyeceğiniz kadarını saklamak istiyorsanız aradığınız budur. action_type paneldeki filtreyle aynı kategorileri alır, ve uç nokta size yalnızca token'ınızın görmeye yetkili olduğu hesapları gösterir.

Tek bir hesaptaki son 25 purge

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://cdn.com.tr/api/accounts/<hesap-uuid>/activities?per_page=25&action_type=purge_cache"

Üç rol ve her birinin işi

Kayıt size ne olduğunu söyler. Roller ise ne olabileceğini azaltır. cdn.com.tr'de bir alt kullanıcı üç rolden birini alır.

Viewer hesabın gösterdiği her şeyi okur ve kendi profili ile parolası dışında hiçbir şeyi değiştiremez. Grafiklere bakmak isteyen bir yönetici, performans raporlayan bir ajans ya da olay sırasında durumu daha kötü hale getiremeden bakması gereken herkes için doğru rol budur.

Editor operasyonel işi yapar: cache purge, teslim kurallarını düzenleme, DNS kayıtları, sertifikalar ve hostname yönetimi. Editörün yapamadığı şey hesabın kendi şeklini değiştirmektir — alt kullanıcı ekleyip çıkaramaz, faturalamaya dokunamaz, hesabı silemez. Siteyi günlük olarak işleten kişilerin rolü budur.

Owner hepsini yapar; editörün bilinçli olarak uzak tutulduğu üç şey dahil. Hesap sahibinin rolüdür ve listesi çok kısa kalmalıdır.

Bilmeye değer iki ayrıntı. Bir alt kullanıcı rol seçilmeden oluşturulursa viewer olur — ölçeğin güvenli ucu, yani unutulan bir alan asla düşündüğünüzden fazlasını veremez. Ve roller API token'larında da panelde olduğu gibi uygulanır: viewer'ın token'ı okur, yazamaz. Yani DNS değiştirmeye yetkisi olmayan birinin çalıştırdığı script de DNS değiştiremez.

Birini, ihtiyacı olan yetkiyle eklemek

Yetkilendirme sayfasına gidin — /management/authorization — ve Yeni Kullanıcı'yı seçin. Bilgilerini girin ve kaydetmeden önce rolü seçin; o kişinin yapabileceği her şeye karar veren alan odur.

Pratikte iki alışkanlık bu işi yürütür. Ortak giriş paylaşmak yerine herkese kendi hesabını verin: etkinlik geçmişi ancak içindeki isimler kadar işe yarar ve "ortak hesap purge etti" başladığınız çıkmaz sokağın aynısıdır. Ve biri belirli bir iş için katıldığında — bir göç, bir ajans çalışması, bir dış kaynak — o işin gerektirdiği rolü verin ve iş bitince kullanıcıyı kaldırın. Kimsenin sahiplenmediği atıl erişim, her erişim gözden geçirmesinin en sık bulgusudur ve önlenmesi en kolay olanıdır.

Can sıkmadan en az yetki

En az yetki ilkesinin kötü bir ünü var, çünkü genelde "her seferinde bana sor" diye uygulanıyor ve insanlar bir hafta içinde etrafından dolaşmanın yolunu buluyor. Çalışan bir ekiple teması atlatan sürümü daha basit.

Herkesi varsayılan olarak viewer yapın, talep geldikçe yükseltin. Birinin ilk kez purge etmesi gerektiğinde size bir mesaja mal olur; karşılığında kimse hiç istemediği bir yetkiyi taşımaz.

Editor'ü işi bir şeyleri değiştirmek olan kişilere verin — ve sınırın nereye çizildiğine dikkat edin: bir editör canlı siteyi düzelten her şeyi yapabilir, anahtarların kimde olduğunu ya da ne kadar fatura kesildiğini değiştiren hiçbir şeyi yapamaz. Asıl önemsediğiniz çizgi budur; rolün bir taviz olmamasının sebebi de bu.

Owner'ı hesabın hesabını verenlere bırakın ve erişim el değiştirdiğinde aynı gün işlem yapın. Kayıt neyin yapıldığını tutar, kimin hâlâ yapabilir olması gerektiğini değil; o kısım size ait.

İki özellik aslında tek bir önlem

Kaydı güvenlik özelliği, rolleri idari bir ayrıntı saymak cazip geliyor. Oysa iş tam tersi yürüyor.

Roller önlemedir. Neyin mümkün olduğuna karar verirler ve bir kazayı ziyaretçilerinize ulaşmadan durduran tek şey budur. Kayıt ise tespit ve hesap verebilirliktir: neyin, kim tarafından yapıldığını ve değerin eskiden ne olduğunu söyler.

İkisi de tek başına pek işe yaramaz. Kayıtsız roller, hiç kontrol edemeyeceğiniz bir sınıra güvenmek demektir. Rolsüz kayıt ise her olayı kusursuzca anlatıp hiçbirini önleyememek demektir. Birlikte, bir kesintiden sonra gerçekten sorulan soruyu yanıtlarlar — soru asla "CDN nedir" değildir, her zaman "bunu kim değiştirdi ve neden değiştirebiliyordu"dur.