Kullanıcı yetkileri ve denetim kaydı: her yönetim sisteminde güvenin temeli

Bir şirketin ilk yıllarında çalışanlar birbirini tanır; faturada kimin değişiklik yaptığını ya da fiyatı kimin değiştirdiğini öğrenmek için sormanız yeterlidir. Çalışan ve şube sayısı arttıkça bu soruyu yanıtlamak zorlaşır, küçük hatalar da kimsenin çözüme kavuşturamadığı anlaşmazlıklara dönüşür.

Birçok şirket paylaşılan Excel dosyalarından bir yönetim sistemine geçer, ardından yeni sistemin aynı sorunu tekrarladığını görür: Herkes geniş yetkili hesaplarla giriş yapar ve kimin ne yaptığına dair hiçbir iz kalmaz. “Excel’den sisteme: uygulanabilir bir veri taşıma planı” başlıklı makalede verilerin kendisinin taşınmasını anlatmıştık; burada ise bu verileri sonrasında kimin değiştirmeye yetkili olduğunu ele alıyoruz.

Yetkiler ve denetim kaydı, projenin sonunda gelen teknik bir eklenti değildir. İş kurallarının bir parçasıdırlar ve gösterge panelinin gösterdiği rakamlara ne kadar güvenebileceğinizi belirlerler.

Önce roller, ardından gereken en az yetki

Sık yapılan hata, yetkilerin her kişiye tek tek verilmesidir: Bu çalışan raporları görür, şu çalışan fiyatları değiştirir, bir üçüncüsüne geçici bir yetki eklenmiş ama geri alınmamıştır. Birkaç ay sonra kimse, kimin hangi yetkiye neden sahip olduğunu bilmez.

Alternatif, rollerin işe göre tanımlanmasıdır: depo sorumlusu, muhasebeci, şube müdürü ve satış personeli. Yetkiler role, çalışan da bir ya da daha fazla role bağlanır. Yeni bir çalışan işe başladığında rolünü seçmeniz yeterlidir; bir rolün tanımı değiştiğinde ise bu değişiklik herkese aynı anda yansır.

Bu yaklaşım, yönetim için eskiden zor olan bir soruyu da kolaylaştırır: Bu talebi kim onaylayabilir? Yanıt, her kullanıcının ayarlarını tek tek incelemek yerine net bir rol listesine dönüşür.

Her rolün içinde, OWASP yönergelerinin tarif ettiği en az yetki ilkesini uyguluyoruz: Kullanıcıya işini yapması için gereken asgari yetki verilir ve bir yetki açıkça verilene kadar erişim varsayılan olarak reddedilir. İşe etkisi doğrudandır: Tek bir hesabın yapabildikleri ne kadar azsa, bir hatanın ya da parolası çalınmış bir hesabın vereceği zarar da o kadar az olur.

Veri kapsamı: şube ve depo

Rol, kullanıcının ne yapacağını; kapsam ise bunu hangi veriler üzerinde yapacağını belirler. Şube müdürünün tüm şubelerin değil, kendi şubesinin taleplerini onaylaması gerekir. Depo sorumlusu kendi deposunun stok bakiyelerini görür; fiyatları ya da kâr marjlarını görmesine ise hiç gerek olmayabilir.

Üç şubesi olan bir şirkette, şubelerden birindeki bir satış çalışanının diğer şubelerin faturalarını ve müşterilerini görebildiğini varsayalım. Henüz bir hata olmadı, ama müşteri listesinin tamamı artık her satış çalışanının erişimine açık. Kapsamı şubeyle sınırlamak, kimsenin işini aksatmadan bu kapıyı kapatır.

Görevler ayrılığı ve hassas işlemler

Görevler ayrılığı, tek bir kişinin sistemi tek başına kötüye kullanmaya yetecek yetkilere sahip olmaması demektir; bu tanım NIST’in güvenlik terimleri sözlüğünde yer alır. Günlük işte bu, basit bir kurala dönüşür: İşlemi oluşturan kişi, onu onaylayan kişi değildir.

• Satın alma siparişini oluşturan onu onaylamaz, onaylayan da malları teslim almaz.
• Tedarikçi faturasını kaydeden, ödemesini yapmaz.
• Kullanıcı ekleyen kişi kendine ek yetki vermez.

Ardından hassas işlemler gelir; bunlar, bir hatanın doğrudan parayı etkilediği işlemlerdir. Bunları kodlamaya başlamadan önce yönetimle birlikte belirliyor ve her birine net bir kural koyuyoruz:

• İndirim: her rol için bir üst sınır; bu sınırı aşan indirimler onay gerektirir.
• Fiyat değişikliği: belirli bir role verilen bir yetki; yeni fiyat, eski fiyatın üzerine yazılmak yerine geçerli olacağı bir başlangıç tarihiyle girilir.
• Döviz kuru değişikliği: kısıtlı bir yetki, çünkü etkisi başka bir para birimindeki her faturaya yansır.
• Silme: Mali kayıtlar silinmez, görünür kalan bir ters kayıtla iptal edilir.
• Kapanmış bir muhasebe döneminin yeniden açılması: açık bir onay ve yazılı bir gerekçeyle.

Onay, yönetici gelene kadar işin durması anlamına gelmez. Onay talebi cep telefonuna gelebilir; onaylayacak kişi onay vermeden önce gerekçeyi ve tutarı görebilir, kararı da aynı kayda işlenebilir. Böylece satış hızlı kalır, istisnalar da görmesi gereken kişilere görünür olur.

Denetim kaydı: kimin neyi ne zaman yaptığı

Denetim kaydı, sistemin unutmayan hafızasıdır. OWASP yönergeleri, kaydın her olay için ne zaman ve sistemin neresinde gerçekleştiğini, kimin yaptığını ve ne olduğunu saklamasını önerir. Yönetim sistemlerinde buna vazgeçilmez bir unsur ekliyoruz: değişiklikten önceki ve sonraki değer.

Bir ürünün fiyatının değiştiğini ve kimse fark etmeden ürünün yeni fiyattan defalarca satıldığını varsayalım. Denetim kaydı yoksa önünüzde bitmeyen bir tartışma kalır. Denetim kaydı varsa fiyatı kimin, hangi değerden hangi değere ve saat kaçta değiştirdiğini bilirsiniz; böylece suçlu aramak yerine sorunun nedenini giderirsiniz.

• Hiçbir kullanıcı, sistem yöneticisi bile, kaydı değiştiremez veya silemez.
• Düzeltme, ters kayıtla ya da yeni bir düzeltme kaydıyla yapılır; böylece hata ve düzeltme birlikte görünür kalır.
• Reddedilen erişim girişimleri de kaydedilir; bunlar eksik bir yetkinin ya da meşru olmayan bir girişimin erken işaretidir.
• Yetki değişikliklerinin kendisi de kaydedilir: yetkiyi kimin, kime ve ne zaman verdiği.

Kaydın iş diliyle aranabilir olması da önemlidir: faturaya, ürüne, kullanıcıya ya da döneme göre. Yalnızca bir yazılım geliştiricinin okuyabildiği bir kaydı yönetimde kimse açmaz.

Kimse okumuyorsa kaydın bir faydası olmaz. İşletme sahibinin, kısa bir dönemsel raporu inceleyecek bir kişi belirlemesini öneriyoruz: sınırı aşan indirimler, fiyat ve döviz kuru değişiklikleri, ters kayıtlar ve olağan çalışma saatleri dışında yapılan işlemler.

Sistemin rakamlarına duyulan güven, her hatayı önlemekten değil, hatanın nerede olduğunu ve nasıl düzeltildiğini bilebilmekten gelir.

Kişiler değiştiğinde yetkilerin gözden geçirilmesi

Yetkiler zamanla birikir: satıştan satın almaya geçtiği hâlde eski yetkilerini koruyan bir çalışan, şirketten ayrıldığı hâlde hesabı aktif kalan bir başkası. Bu yüzden OWASP yönergeleri, yetkilerin başlangıçta tasarlananın ötesine geçmediğinden emin olmak için canlıya geçişten sonra düzenli olarak gözden geçirilmesini önerir.

• Rol değiştiğinde: Önceki rolün yetkileri aynı gün geri alınır, yeni yetkiler bunların üzerine eklenmez.
• Çalışan ayrıldığında: Hesap hemen devre dışı bırakılır ama silinmez; böylece denetim kaydındaki izi korunur.
• Geçici yetkiler: Sonra geri alınacağı sözüyle değil, belirli bir bitiş tarihiyle verilir.
• Dönemsel gözden geçirme: Her yönetici kendi ekibinin listesini ve rollerini inceler; gerekenleri onaylar, gerekmeyenleri geri alır.

Satın alma biriminden bir çalışanın şirketten ayrıldığını ve kimseye haber verilmediği için hesabının aktif kaldığını varsayalım. Belki hiçbir şey olmaz; ama o hesaptan oluşturulan her satın alma siparişi tüm raporlarda sorunsuz görünür. Hesabın devre dışı bırakılmasını insan kaynaklarındaki işten ayrılma süreçlerine bağlamak bu açığı kapatır.

Gözden geçirme için tek bir sıklık önermiyoruz; bu, işletme sahibinin ekibin büyüklüğüne ve verilerin hassasiyetine göre vereceği bir karardır. Önemli olan, gözden geçirmenin yazılı bir sıklığının ve bilinen bir sorumlusunun olmasıdır.

Canlıya geçiş öncesi kontrol listesi

• Roller işe göre tanımlanmış; her çalışan bireysel yetkilere değil, bir role bağlı.
• Varsayılan olarak erişim reddediliyor ve verilen her yetkinin bilinen bir gerekçesi var.
• Her kullanıcının kapsamı, çalıştığı şube ya da depoyla sınırlı.
• Hassas işlemler tek tek belirlenmiş ve her birinin bir sınırı ya da onay şartı var.
• İşlemi oluşturan kişi ile onaylayan kişi farklı.
• Denetim kaydı kimin neyi ne zaman yaptığını ve değişiklikten önceki ve sonraki değeri saklıyor.
• Kayıt değiştirilmeye ve silinmeye karşı korunuyor; düzeltme ters kayıtla yapılıyor.
• Kaydı okumaktan ve yetkileri gözden geçirmekten sorumlu bir kişi var.

Bu kurallar kodlamadan önce keşif toplantısında netleştirilir; çünkü bunları mevcut bir sisteme sonradan eklemek daha zor ve daha maliyetlidir. Modül modül özel bir ERP sistemi geliştirirken yetkileri ve denetim kaydını ilk modülle birlikte tasarlıyoruz; diğer modüller de bunların üzerine kurulur.

Mevcut sisteminiz herkese her şeye erişim veriyorsa ya da yeni bir sistem planlıyorsanız, durumunuzu ITS ekibiyle görüşebilirsiniz; rolleri ve hassas işlemleri kod yazılmadan önce birlikte belirleyelim.