Operasyon her düzeltme için yazılımcıya geliyor: iç yönetim paneli (admin) nasıl tasarlanır?

Operasyon ekibi her kayıt düzeltmesi için yazılımcıya gidiyorsa, eksik olan şey bir panel değil, o düzeltmelerin üründe tanımlı birer işlem olmamasıdır. İç yönetim aracı ürünün yanına yapıştırılan bir yama değil, ikinci yüzüdür: aynı iş kurallarından, aynı doğrulamalardan ve aynı yan etkilerden geçmek zorundadır. Kurarken üç şeyi baştan sabitleyin. Her işlem ürünün kendi servis katmanından geçsin, veritabanına elle yazılmasın. Her işlem kimin yaptığı, neyi değiştirdiği ve niçin yaptığıyla birlikte kaydedilsin. Yetki tek bir "admin" rolüne değil, işin gerçek rollerine bölünsün; silme, iade ve kimlik değiştirme gibi işlemler süreli yetki ve ikinci onay istesin. Geri kalanı hangi işlemlerin panele gireceğini seçme meselesidir.

Önce kaç talep geldiğini sayın

Panel tartışmasına girmeden önce son otuz günde operasyondan yazılım ekibine gelen düzeltme taleplerini tek bir listeye dökün. Her satırda üç bilgi olsun: ne istendi, kaç dakika sürdü, aynı istek kaç kez tekrarlandı. Liste çoğu şirkette birbirine benzer. Müşterinin e-posta adresini değiştir, siparişi iptal et, faturayı yeniden üret, yanlış girilen tutarı düzelt, kullanıcıyı başka hesaba taşı.

Karar kuralı sayıdan çıkar. Ayda ikiden fazla tekrarlayan bir düzeltme artık istisna değildir, tanımlanmamış bir iş akışıdır ve panele girer. Yılda bir iki kez olan işler geliştiricinin elinde kalabilir, ama onların da yazılı bir prosedürü olmalı. Tekrar sayısını görmeden panel yapmaya başlayan ekipler, kimsenin açmadığı kırk ekranla bitiriyor.

Elle SQL çalıştırmak neden en pahalı çözüm

Üretim veritabanına doğrudan yazılan bir güncelleme, uygulamanın bütün korumalarını atlar. Doğrulama kuralları çalışmaz, izin verilmeyen durum geçişleri mümkün hale gelir ve en önemlisi yan etkiler oluşmaz.

Somut bir örnek: bir siparişin durumunu elle "iptal" yapan tek satırlık sorgu. Müşteriye iptal bildirimi gitmez, stok geri dönmez, iade kaydı oluşmaz, giden webhook tetiklenmez, ERP tarafı siparişi açık görmeye devam eder ve önbellekteki eski kayıt bir süre daha servis edilir. Birden çok tabloya dokunan düzeltmelerde işin yarısının yazılıp yarısının yazılmadığı durumlar da ayrı bir sınıf hata üretir.

Bunların üstüne bir de iz sorunu biner. Altı ay sonra "bu kaydı kim, neden değiştirdi" sorusunun cevabı yoktur; elinizde yalnızca birinin bir zamanlar çalıştırdığı bir sorgu vardır.

Panel, ürünle aynı kapıdan geçmeli

Doğru kurgu şu: panel ayrı bir arayüzdür ama ayrı bir mantık değildir. "Siparişi iptal et" işlemi tek bir yerde tanımlıdır. Müşteri kendi yaptığında da destek temsilcisi onun adına yaptığında da aynı kod çalışır. Tek fark, işlemi kimin başlattığı ve hangi yetkiyle yaptığıdır.

Pratikte bu, her panel işleminin üç bilgiyle çağrılması demek: işlemi yapan kişi, etkilenen kayıt ve gerekçe. İki ayrı kod yolu açtığınız anda hata düzeltmeleri de ikiye bölünür; müşteri tarafında kapatılan bir açık panel tarafında açık kalır. Hata mesajları ve eşzamanlı düzenleme kontrolleri için de aynı şey geçerli.

Hazır platform mu, kendi paneliniz mi

Üç seçenek var ve üçü de doğru olabilir.

Birincisi, çatının hazır yönetim arayüzü. Django belgeleri kendi admin arayüzünün sınırını açıkça yazıyor: önerilen kullanım "kurumun iç yönetim aracı" ile sınırlıdır, bütün ön yüzü onun üzerine kurmak için tasarlanmamıştır. Aynı belge, tablo merkezli değil süreç merkezli bir ekran gerekiyorsa kendi görünümünüzü yazma zamanının geldiğini söylüyor (Django admin belgeleri). Bu, hazır admin'in nerede biteceğini tarif eden dürüst bir cümle.

İkincisi, iç araç platformları. Hızlı başlarsınız, ama panelin asıl ihtiyaç duyduğu yönetişim özellikleri genelde üst paketlerde durur. Retool'un ilan ettiği fiyatlandırmada ücretsiz plan 5 kullanıcıyla sınırlı; Team planı yıllık ödemede geliştirici başına 10, iç kullanıcı başına 5 dolar; Business planı 50 ve 15 dolar. Denetim kayıtları Business ile geliyor, ayrıntılı roller, SSO/SCIM/2FA ve kendi altyapınızda barındırma ise Enterprise'a özel. Yani "panelde kim ne yaptı" sorusunun cevabı, en ucuz planda yok.

Kendi sunucunuzda açık kaynak bir panel çalıştıracaksanız lisans metnini okuyun. Directus v12 ile birlikte Monospace Sustainable Core License'a geçti; yıllık geliri 5 milyon doların ve çalışan sayısı 50'nin altındaki kuruluşlar platformun tamamını ücretsiz kullanabiliyor (lisans duyurusu). Eşiğin üstündeyseniz bu bir satın alma kalemidir (açık kaynak lisans uyumluluğu).

Üçüncüsü kendi geliştirmeniz. İşlemler düz kayıt düzenlemesi değil de iş operasyonuysa (iade, iptal, hesap birleştirme, abonelik değişikliği) ve bu operasyonların kuralları ürünün içinde zaten varsa, paneli ürünün parçası olarak yazmak hem daha ucuz hem daha güvenli oluyor. Low-code ne zaman yetmez sorusunun cevabı burada da aynı: ifade sınırına ve çıkış maliyetine bakın.

Tek bir "admin" rolü yetmez

New York finans düzenleyicisinin 2020 Twitter olayına ilişkin raporu bu konuda okunmaya değer bir vaka sunuyor. Şirket iç araçlara erişimi bir ölçüde sınırlamıştı, ama rapora göre 1.000'den fazla çalışan hâlâ bu araçlara erişebiliyordu. Araçlar hesabın e-posta adresini güncellemeye, parola sıfırlamaya ve çok faktörlü doğrulamayı açıp kapatmaya izin veriyordu. Saldırganlar sisteme teknik bir açıktan değil, telefonla BT ekibi gibi davranıp çalışan hesaplarını ele geçirerek girdi (NYDFS Twitter Investigation Report, Ekim 2020).

Buradan çıkan ders rol tasarımına bakıyor. Paneli tek bir yetki seviyesiyle açarsanız, destek temsilcisinin adres düzeltmek için aldığı erişim aynı zamanda parola sıfırlama ve MFA kapatma erişimi olur. Rolleri işin kendisine göre bölün: görüntüleme, sınırlı düzeltme, finansal işlem, yıkıcı işlem. Kayıt bazında kapsam da ekleyin; bir temsilcinin yalnızca kendi portföyündeki müşterileri görmesi çoğu üründe birkaç satırlık bir koşuldur (yetkilendirme modeli: RBAC ve ABAC).

Riskli işlemde ikinci imza ve süreli yetki

Aynı rapor somut bir öneri de veriyor: yüksek riskli işlemler için eylemin gerçekleşmesinden önce ikinci bir çalışanın onayı istensin. Bu kontrol, bir çalışanın hesabı ele geçirildiğinde oluşacak hasarı sınırlıyor.

Süreli yetki tarafında hazır bir model var. Google Cloud'un Privileged Access Manager yapısında yönetici bir "entitlement" tanımlıyor: kim talep edebilir, hangi rolü alır, en fazla ne kadar süreyle, gerekçe zorunlu mu, onay gerekiyor mu. Süre dolduğunda roller otomatik geri alınıyor, talep ve onay kayıtları denetim günlüğüne yazılıyor (PAM genel bakış).

Kendi panelinizde bunun ucuz hali şöyle kurulur: yıkıcı işlemler varsayılan olarak kapalıdır, operatör gerekçe yazarak yetki talep eder, yetki 60 dakika geçerlidir, talep ekip kanalına düşer ve süre sonunda kendiliğinden kapanır. Onay akışını nereye kadar karmaşıklaştıracağınıza karar verirken onay süreçleri ve iş akışı motoru yazısındaki üç seviye ölçütü işinizi görür.

Müşteri adına giriş (impersonation) kuralları

Destek ekibinin "müşterinin gördüğü ekranı görmesi" çoğu üründe gerekli bir özellik. Tehlikeli olan, bunun sınırsız bir giriş yetkisine dönüşmesi.

Çalışan kural seti şu: oturum varsayılan olarak salt okunurdur, işlem yapmak ayrı bir yetki ister. Ekranın üstünde oturum boyunca duran bir uyarı bandı bulunur. Oturum süre sınırlıdır ve tek tuşla sonlandırılır. Yapılan her işlem hem operatörün hem müşterinin kimliğiyle loglanır. Parola değiştirme, e-posta değiştirme, MFA kapatma ve ödeme yöntemi ekleme bu oturumda tamamen yasaktır. Ürün analitiği ve pazarlama olayları bu oturumları dışarıda bırakır, yoksa huni rakamlarınız destek trafiğiyle kirlenir.

Bir de veriyi görme meselesi var. Kart numarası, kimlik numarası ve benzeri alanlar varsayılan olarak maskeli dursun, açmak gerekçe istesin, dışa aktarma ayrı bir yetki ve satır limitiyle çalışsın. Shopify 2020'de destek ekibindeki iki çalışanın 200'den az satıcının müşteri kayıtlarına yetkisiz eriştiğini açıklamıştı ve bunun platformdaki teknik bir açıktan kaynaklanmadığını özellikle belirtmişti (Infosecurity Magazine, Eylül 2020). Sorulması gereken soru "sisteme kim girebiliyor" değil, "giren kişi ne kadarını görebiliyor ve ne kadarını dışarı çıkarabiliyor".

Toplu işlemler: önizleme, limit ve geri alma

Panelin en çok hasar üreten kısmı toplu işlemlerdir. Dört kontrol zorunlu.

Önizleme: işlem çalışmadan önce kaç kaydın etkileneceğini ve ilk birkaç satırın ne olacağını gösterin. Üst sınır: tek seferde işlenebilecek satır sayısına sabit bir tavan koyun, daha fazlası ayrı onay istesin. Dayanıklı yürütme: iş kuyruğa alınsın, ilerleme görünsün, kısmen başarısız olanlar satır satır raporlansın (arka plan işleri ve kuyruklar, toplu veri aktarımı). Geri alma: her toplu işleme bir grup kimliği verin ki tek hamlede geri alınabilsin, kayıtlar kalıcı silme yerine yumuşak silmeyle işaretlensin. Mükerrer kayıt birleştirme gibi geri dönüşü zor işlemlerde birleştirme öncesi kopyayı saklayın (mükerrer kayıt temizliği).

Bir de çift tıklama gerçeği var: aynı toplu işlemin iki kez çalışmaması için istek anahtarı üretin ve aynı anahtarla gelen ikinci isteği yok sayın.

Her işlemin yanında bir gerekçe olsun

Panelin denetim kaydı, ürünün genel denetim izinden daha ayrıntılı olmalı. Her satırda şunlar bulunsun: zaman, işlemi yapan gerçek kişi (paylaşılan hesap değil), etkilenen kayıt, eski ve yeni değer, gerekçe ya da talep numarası, işlemin hangi kanaldan geldiği ve kaynak IP. Kayıtlar uygulama tarafından değiştirilemez olsun.

Kart verisi işlemiyor olsanız bile PCI DSS v4.0.1'in iki maddesi iyi bir ölçüt veriyor: 10.2.1.2, yönetici erişimiyle yapılan bütün işlemlerin loglanmasını; 7.2.4 ise kullanıcı hesaplarının ve yetkilerinin en az altı ayda bir gözden geçirilmesini istiyor. Pratik karşılığı şu: panel kullanıcı listesini çeyrekte bir operasyon yöneticisiyle birlikte açıp okuyun, ayrılan personelin erişimi işten ayrılma günü kapansın. Kimlik sağlayıcınız üzerinden otomatik kullanıcı kapatma kurmak bu işi elle yapmaktan daha güvenilir (SAML, OIDC ve SCIM).

Panel de bir saldırı yüzeyidir

Adresi gizlemek bir kontrol değildir. Yetki kontrolü her istekte sunucu tarafında yapılmalı; bozuk erişim kontrolü OWASP listesinin en üst sıralarındaki sorun olmaya devam ediyor.

Üç şey daha: panel girişinde kimlik avına dayanıklı doğrulama kullanın. NYDFS raporu, uygulama tabanlı MFA'nın telefonla kandırma yöntemiyle aşıldığını, donanım anahtarının bu saldırıyı durduracağını yazıyor (MFA yöntemleri). Panel oturumunu ürün oturumundan ayırın ve süresini kısa tutun. Panelden gelen istekleri ayrıca izleyin; bir temsilcinin bir saatte 400 müşteri kaydı açması, hiçbir kuralı ihlal etmeden gerçekleşebilecek bir olaydır ve ancak izleme tarafında yakalanır (log yönetimi ve SIEM).

Bu ay yapılabilecek dört şey

Son 30 günün manuel düzeltme listesini çıkarın ve tekrar sayısına göre sıralayın. İlk üç işlemi gerçek operasyon olarak yazın: tek giriş noktası, zorunlu gerekçe, denetim kaydı. Rolleri en azından ikiye bölün, görüntüleme ve işlem. Panel kullanıcı listesini bugün açın, ayrılmış kişileri ve artık o işi yapmayanları çıkarın.

Operasyon ekibiniz hâlâ düzeltmeleri bilet açarak yaptırıyorsa, hangi işlemlerin panele girmesi gerektiğini ve bunları güvenli biçimde açmanın maliyetini birlikte çıkaralım.