Kurumsal yazılım güvenliği: kim neyi görüyor, kim ne yaptı, yedek geri dönüyor mu?

Güvenlik konuşulmaya başlandığında herkes sunucuya bakar. Oysa kurumsal sistemlerde yaşanan olayların önemli bir kısmı dışarıdan bir saldırıyla değil, içeriden verilmiş fazla yetkiyle olur: ayrılan bir çalışanın hâlâ açık hesabı, herkese açılmış bir dışa aktarım tuşu, ya da kimin değiştirdiği bilinmeyen bir fiyat satırı.

Bu yazı verinin hangi ülkede ve hangi sunucuda durduğunu anlatmıyor; onu verileriniz nerede duruyor yazısında ayrı ele aldık. Buradaki konu sistemin içi: yetkilendirme, denetim izi, sızma yüzeyi ve yedekten geri dönüş.

Yetkilendirme: rol yetmez, dört katman gerekir

“Rol bazlı yetkilendirme var” cümlesi çoğu sistemde yalnız ilk katmanı ifade eder. Gerçek bir yetki tasarımı dört katmandan oluşur ve her katman ayrı bir soruya cevap verir.

Katman	Cevapladığı soru	Örnek
Ekran yetkisi	Bu kişi hangi ekranı açabilir?	Muhasebe üretim planı ekranını açamaz
İşlem yetkisi	O ekranda ne yapabilir?	Teklifi görür ama iskonto oranını değiştiremez
Kayıt yetkisi	Kimin verisini görebilir?	Temsilci yalnız kendi müşterilerini listeler
Alan yetkisi	Kaydın hangi alanını görebilir?	Servis şefi personel kartını görür, maaşı görmez

Üçüncü ve dördüncü katman atlandığında sistem “güvenli” görünür ama tek bir Excel’e aktar tuşu tüm müşteri listesini bir kişinin eline verir. Yetki tasarımını yaparken ekran listesinden değil görev listesinden başlayın: her rolün gün içinde yaptığı işleri yazın, o işleri yapmaya yetecek en dar yetkiyi verin, sonra eksik çıkanı ekleyin.

Yetki tasarımının üç yaygın hatası şunlardır: yöneticiye “her ihtimale karşı” tam yetki vermek, geçici yetkiyi kalıcı bırakmak ve yetki değişikliğini sistem dışında (sözlü) yapmak. Üçü de aynı sonucu doğurur: matris zamanla gerçeği anlatmaz hâle gelir. Yetki matrisi altı ayda bir, iki kişinin katıldığı yarım saatlik bir toplantıda gözden geçirilmelidir.

Denetim izi: neyi kaydetmeli, neyi kaydetmemeli

Denetim izi (audit log), bir kaydın kim tarafından, ne zaman ve neye çevrildiğini gösteren yazıdır. Her tabloda tutulması gerekmez — her yerde tutulan kayıt okunmaz olur. Ölçüt şudur: kayıt sonradan tartışma konusu olabiliyorsa iz tutulur.

• Mutlaka: fiyat ve iskonto, stok hareketi, ödeme ve tahsilat, yetki değişikliği, iş emri kapanışı, kullanıcı oluşturma ve silme.
• Genellikle: müşteri kartı, sözleşme alanları, ürün tanımı, sistem ayarları.
• Gerekmez: oturum içi geçici hesaplamalar, önbellek tabloları, rapor çıktıları.

Kaydın kendisi kadar önemli olan iki ayrıntı var. Birincisi, iz eski ve yeni değeri birlikte tutmalıdır; yalnız “değiştirildi” yazan bir satır soruşturmada işe yaramaz. İkincisi, izi kullanıcı silememelidir. Yönetici hesabı denetim izini temizleyebiliyorsa iz yoktur, kayıt görüntüsü vardır.

Kayıtların ne kadar saklanacağını da baştan yazın. Uygulamada işe yarayan kurgu, mali kayıtlarda kanuni saklama süresine yaslanmak, diğerlerinde bir ila iki yıl tutup sonra özetlemektir.

Sızma yüzeyi: kurumsal sistemde kapılar nerede

Sızma yüzeyi, sisteme dışarıdan dokunulabilen her nokta demektir. Kurumsal iş yazılımlarında bu noktalar teknoloji seçiminden çok kurulum kararlarıyla belirlenir.

Kapı	Tipik açık	Kapatma kararı
Giriş ekranı	Sınırsız deneme, zayıf parola	Deneme sınırı, parola kuralı, yönetici hesaplarda ikinci doğrulama
Dosya yükleme	Her uzantı kabul ediliyor	Uzantı ve tür kontrolü, dosyaların web kökü dışında saklanması
Web kökü	Proje kökü doğrudan tarayıcıya açık	Yalnız genel dizin yayınlanır, yedekler asla web altında durmaz
Dışa açık uçlar	Belgelenmemiş, kimliksiz API adresi	Anahtar, hız sınırı ve erişim kaydı
Eski hesaplar	Ayrılan personel, biten tedarikçi	Ayrılış listesi ve altı aylık hesap taraması
Üçüncü parti servisler	Süresi dolan anahtar, paylaşılan parola	Hesaplar şirket adına, anahtarlar yalnız sunucuda

Bu tablodaki en sessiz madde üçüncü satırdır. Proje kökü web’e açıldığında yapılandırma dosyaları, veritabanı yedekleri ve sisteme yüklenmiş belgeler tarayıcıdan indirilebilir hâle gelir. Karmaşık bir saldırı değildir; tek bir dizin ayarının sonucudur ve kurulum sırasında bir kez doğru yapılırsa bir daha gündeme gelmez.

Yedek: alınıyor olması yetmez, geri dönüyor olması gerekir

Yedekleme konusundaki en pahalı yanılgı, yedeğin varlığını güvence saymaktır. Yedek ancak geri döndüğü kanıtlandığında yedektir. Provası şöyle yapılır:

1. Ayrı bir sunucu açın. Canlıya dokunmadan, geçici bir ortam.
2. Son yedeği yükleyin. Veritabanı ve dosya eklerini birlikte — çoğu kurulumda ikisi ayrı yerde durur.
3. Uygulamayı o veriyle açın. Giriş yapın, birkaç gerçek kaydı gözle doğrulayın.
4. İki sayıyı yazın. Dönüş kaç saat sürdü, kaç saatlik veri kayboldu?
5. Eksikleri listeleyin. Prova sırasında elle yapılan her adım, tarifnameye yazılması gereken bir eksiktir.

Provayı yılda en az bir kez tekrarlayın ve tarihini yazın. İki sayı (dönüş süresi ve kayıp penceresi) yönetimin anlayacağı tek güvenlik ölçüsüdür; şifreleme algoritmasının adından çok daha fazlasını söyler.

Personel çıkışı: tek listede toplanmalı

Yetki tasarımının en çok sızdıran yeri, çıkış anıdır. İşten ayrılan kişinin kapatılması gereken erişimleri tek bir listede toplayın: sistem kullanıcısı, kurumsal e-posta, sunucu ve veritabanı erişimi, kod deposu üyeliği, üçüncü parti servis hesapları, paylaşılan parolalar ve varsa mobil cihaz. Kullanıcıyı silmek yerine pasife alın — silinen kullanıcı, denetim izindeki geçmişi de okunmaz hâle getirir.

Bu yazının kapsamadığı iki konu

Dürüst sınır: burada anlatılanlar sistemin iç güvenliğidir. Verinin hangi ülkede durduğu, sunucu hesabının kimin adına açıldığı ve KVKK aktarım koşulları ayrı bir konudur; onu veri yerleşimi rehberinde ele aldık. İlişki bittiğinde kaynak kodun ve belgelerin size geçmesi de güvenlik değil sahiplik başlığıdır; onun sözleşme karşılığı kod sahipliği ve tedarikçi bağımlılığı yazısındadır.

Tedarikçiye sorulacak kontrol listesi

Teklif görüşmesinde bu sekiz maddeyi sorun ve cevapları yazılı isteyin:

• Yetki matrisi belgeleniyor mu; kayıt ve alan düzeyinde yetki var mı?
• Hangi tablolarda denetim izi tutuluyor, eski değer saklanıyor mu?
• Denetim izini yönetici silebiliyor mu?
• Yedekten geri dönüş en son ne zaman denendi, ne kadar sürdü?
• Dosya ekleri web kökünün dışında mı duruyor?
• Dışa açık API uçları kimlikle mi korunuyor?
• Kullanıcı çıkışında hangi adımlar uygulanıyor?
• Yönetici hesaplarında ikinci doğrulama zorunlu mu?

Bu sekiz maddenin cevabı, teklifteki teknoloji listesinden daha çok şey anlatır. Kurulum yaklaşımımızın tamamını kurumsal yazılım sayfasında yazdık; mevcut sisteminizin yetki matrisini ve yedek provasını birlikte gözden geçirmek isterseniz teklif formundan yazın.

Sıkça sorulan sorular

Rol bazlı yetkilendirme ile kayıt bazlı yetkilendirme arasındaki fark ne?

Rol, kişinin hangi ekranı açabildiğini belirler; kayıt yetkisi, o ekranda kimin verisini görebildiğini. Satış temsilcisine teklif ekranını açmak rol kararıdır, ona yalnız kendi müşterilerini göstermek kayıt kararıdır. İkincisi kurulmazsa tek bir dışa aktarım tuşu tüm müşteri listesini bir kişinin eline verir.

Denetim izi her tabloda tutulmalı mı?

Hayır, her tabloda tutmak kaydı okunmaz hâle getirir. Para, stok, fiyat, yetki ve müşteri verisi içeren tablolarda tutulur; geçici ve türetilmiş tablolarda tutulmaz. Ölçüt şudur: bir kayıt sonradan tartışma konusu olabiliyorsa, o kaydın kim tarafından ne zaman değiştirildiği yazılmalıdır.

Yedekten geri dönüş provası nasıl yapılır?

Ayrı bir sunucuya son yedek yüklenir, uygulama o veriyle ayağa kaldırılır ve birkaç gerçek kayıt gözle doğrulanır. Prova iki sayı üretir: dönüş kaç saat sürdü ve kaç saatlik veri kayboldu. Bu iki sayı yazılmadıysa yedek politikanız yoktur, yalnız yedek dosyanız vardır.

Personel ayrıldığında yetki kapatmak yeterli mi?

Kullanıcıyı silmek yerine pasife alın: silinen kullanıcı denetim izindeki geçmiş kayıtları da okunmaz hâle getirir. Ayrılış listesine sistem kullanıcısı, e-posta, sunucu erişimi, paylaşılan parolalar ve üçüncü parti servis hesapları birlikte girmelidir. Tek bir kalem unutulduğunda kapı açık kalır.

İki adımlı doğrulama her kullanıcı için zorunlu olmalı mı?

Yetki seviyesine göre karar verin. Yönetici, muhasebe ve dışa aktarım yetkisi olan kullanıcılarda zorunlu tutun; yalnız kendi iş emrini gören saha kullanıcısında zorunluluk saha hızını düşürür. Uygulamada işe yarayan kurgu, riskli işlemin kendisinde ikinci doğrulama istemektir.

Güvenlik denetimini kim yapmalı, tedarikçinin kendisi mi?

Tedarikçinin kendi işini denetlemesi başlangıç için yeterlidir ama tek başına kanıt sayılmaz. Yılda bir kez bağımsız bir gözle yetki matrisini, denetim izini ve geri dönüş provasını gözden geçirtin. KodDelta teslim paketinde yetki matrisi ve kabul testleri yazılı verildiği için bu inceleme dışarıdan da yapılabilir.

İlgili rehberler

• İnsan Onaylı Otomasyon: Onay Noktası Nereye Konur?
• Veriniz nerede tutulmalı? Yerleşim, KVKK ve çıkış planı
• Excel'de kaybettiğiniz zamanın maliyeti ne? Elle işlem maliyeti ve amortisman rehberi

Hizmet sayfası: Kurumsal yazılım hizmeti