Özel yazılım yaptırırken güvenlik gereksinimlerini belirlemenin doğru yolu, teknoloji listesinden değil iş risklerinden başlar. Önce hangi kullanıcıların sisteme nasıl gireceğini, hangi veriye ulaşacağını, hangi işlemi yapacağını ve hangi kayıtların izleneceğini netleştirirsiniz. Ardından kimlik doğrulama şifreleme loglama gereksinimleri için ayrı ama birbiriyle uyumlu kurallar yazarsınız. Kimlik doğrulamada kullanıcı adı, parola, çok faktörlü doğrulama, oturum süresi ve cihaz politikası belirlenir. Şifrelemede hangi verinin depoda, hangi verinin aktarımda korunacağı tanımlanır. Loglamada ise kim, ne zaman, hangi kayıt üzerinde ne yaptı soruları cevaplanır. Bu çerçeve, /hizmetler/ozel-yazilim-gelistirme kapsamında geliştirilen sistemlerde iş ihtiyacına göre şekillendirilir; hazır kalıp yaklaşımı yerine işletmenin süreçleri esas alınır. Güvenlik gereksinimini en başta yazarsanız, hem denetim hem de operasyon tarafında sonradan çıkacak revizyonları azaltırsınız. Ayrıca geliştiriciyle aynı dili konuşur, belirsizliği düşürür ve teslimat kalitesini artırırsınız.
Güvenlik kapsamını iş riskinden çıkarın
Kimlik doğrulama şifreleme loglama gereksinimleri için ilk adım, sistemi hangi risklerin tehdit ettiğini yazmaktır. Hangi veriyi koruduğunuzu, kimlerin erişeceğini ve yanlış erişimin ne sonuç doğuracağını belirleyin. Örneğin finansal kayıtlar ile duyurular aynı güvenlik seviyesinde olmaz. Bu yüzden kullanıcı gruplarını, veri sınıflarını ve işlem türlerini birlikte değerlendirin. Ardından kritik işlemleri işaretleyin: giriş, kayıt oluşturma, güncelleme, silme, onay verme, dışa aktarma ve yetki değişikliği gibi adımlar ayrı ele alınmalıdır. Her adım için “kim yapar, hangi koşulda yapar, hangi kayıt tutulur” sorusunu cevaplayın. Ayrıca mevzuat, iç denetim ve müşteri beklentisi gibi dış gereksinimleri de ekleyin. Böylece güvenlik, soyut bir teknik madde olmaktan çıkar ve iş akışının parçası haline gelir. /hizmetler/ozel-yazilim-gelistirme sayfasındaki yaklaşım da bu nedenle sistemin işleyişiyle güvenliği birlikte tasarlamayı esas alır. Kapsam netleşmeden teknik karar vermek, sonradan pahalı revizyonlara yol açar.
Kimlik doğrulama kurallarını erişim senaryosuna göre yazın
Kimlik doğrulama şifreleme loglama gereksinimleri içinde en çok hata, kimlik doğrulamayı tek başına “giriş ekranı” sanmaktır. Oysa nasıl giriş yapılacağı, kimin hangi güvenlik düzeyine ihtiyaç duyduğu ve oturumun nasıl korunacağı baştan tanımlanmalıdır. İç kullanıcı, dış kullanıcı, taşeron ya da bayi için aynı doğrulama yöntemi uygun olmayabilir. Bu yüzden kullanıcı tiplerini ayırın ve her biri için beklenen güvenlik seviyesini yazın. Ayrıca parola politikası, çok faktörlü doğrulama, oturum zaman aşımı, başarısız giriş denemeleri ve cihaz doğrulama gibi kuralları senaryo bazında belirleyin. Kritik işlerde ikinci doğrulama isteyebilir, düşük riskli ekranlarda daha sade bir akış kullanabilirsiniz. Ancak bu sadeleşme, güvenliği zayıflatmamalıdır; sadece iş ihtiyacını karşılamalıdır. Kullanıcı bazlı istisnalar varsa bunları nedenleriyle birlikte tanımlayın. Böylece sistem büyüdüğünde yeni kullanıcı türleri eklemek kolaylaşır. Güvenli giriş kurgusu, yalnızca IT kararı değil, iş sürekliliği kararıdır.
Şifreleme kapsamını veri türüne göre ayırın
Kimlik doğrulama şifreleme loglama gereksinimleri belirlenirken şifreleme, tüm veriye aynı yöntemle uygulanan tek bir kural gibi ele alınmamalıdır. Önce hangi verinin hassas olduğunu sınıflandırın: kişisel veri, finansal veri, sözleşme içeriği, operasyon kaydı, rapor çıktısı gibi gruplar oluşturun. Ardından bu verinin nerede korunacağını belirleyin: veritabanında, dosya alanında, yedeklerde veya aktarım sırasında. Aktarımda TLS benzeri bir koruma beklentisi tanımlanır; depolamada ise alan bazlı ya da dosya bazlı şifreleme gerekebilir. Ayrıca anahtar yönetimi, erişim yetkisi ve yedekleme güvenliği de gereksinim metnine girer. Şifreleme sadece “var” ya da “yok” diye yazılmaz; hangi katmanda, hangi kapsamda ve hangi istisnalarla uygulanacağı belirtilir. Örneğin rapor çıktıları e-posta ile gidiyorsa, dosya paylaşımında ayrıca koruma gerekebilir. Bu yaklaşım, veriyi korurken operasyonu kilitlemez. Böylece ekip, güvenliği iş akışına uygun biçimde uygular ve sonradan oluşacak uyumsuzlukları azaltır.
Loglama ve denetim izini işlem bazında tanımlayın
Kimlik doğrulama şifreleme loglama gereksinimleri içinde loglama, sadece hata kaydı tutmak değildir. Kim, ne zaman, hangi cihazdan, hangi işlemle sisteme girdi; hangi kaydı görüntüledi, değiştirdi, sildi ya da dışa aktardı; bunları açıkça tanımlamak gerekir. Ayrıca başarısız girişler, yetki reddi, şifre sıfırlama, rol değişikliği ve istisnai erişimler de kayıt altına alınmalıdır. Loglarda kişisel veri tutma ihtiyacı varsa bunu asgari düzeyde planlayın ve erişimi sınırlandırın. Denetim izi için değiştirilemez kayıt yapısı, zaman damgası ve işlem referansı isteyebilirsiniz. Ancak her ekranı aynı ayrıntıda loglamak zorunda değilsiniz; kritik risk taşıyan işlemler için daha derin kayıt, düşük riskli işlemler için özet kayıt yeterli olabilir. Ayrıca logların kim tarafından görüntüleneceğini de belirleyin. Loglama, yalnızca sorun çıktığında bakılan arşiv değildir; olay inceleme, iç kontrol ve mevzuat uyumu için canlı bir güvenlik katmanıdır. Bu nedenle kaydı teknik ekip kadar iş birimleri de anlayacak şekilde tarif edin.
Gereksinimleri sözleşmeye ve teslim kriterine dönüştürün
Kimlik doğrulama şifreleme loglama gereksinimleri netleştiğinde bunları yalnızca not olarak bırakmayın; kabul kriterine ve teslim kapsamına çevirin. Her güvenlik maddesi için “uygulandı” demek yeterli olmaz, nasıl doğrulanacağını da yazmak gerekir. Örneğin girişte hangi doğrulama adımı var, hangi veriler şifreli saklanıyor, hangi olaylar loglanıyor, hangi yetkiler yönetici onayı gerektiriyor gibi maddeleri test edilebilir biçimde tanımlayın. Ayrıca istisnaları da yazın; toplu işlem yapan kullanıcılar, dış entegrasyonlar veya geçici erişimler farklı kurallara tabi olabilir. Bu noktada özel geliştirme yaklaşımı önem kazanır; çünkü sistem, işletmenin süreçlerine göre şekillenir ve güvenlik maddeleri de aynı mantıkla uyarlanır. /karsilastirma/hazir-paket-mi-ozel-yazilim-mi sayfası, bu farkı değerlendirmek isteyenler için yararlı bir çerçeve sunar. Son olarak, güvenlik gereksinimlerini bakım sürecine bağlayın. Rol değişikliği, yeni ekran, yeni entegrasyon ya da yeni mevzuat geldiğinde bu listeyi güncelleyin. Böylece güvenlik, teslim anında biten bir madde değil, yaşayan bir standart olur.
Sık sorulan sorular
Kimlik doğrulama, şifreleme ve loglama aynı dokümanda mı yazılmalı?
Evet, ama tek başlık altında eritmeden yazın. Kimlik doğrulama şifreleme loglama gereksinimleri birbirine bağlıdır; yine de her biri için ayrı kurallar, ayrı kapsam ve ayrı test ölçütü tanımlayın. Böylece geliştirici hangi katmanda ne yapacağını net görür, siz de teslimde boşluk kalıp kalmadığını daha kolay kontrol edersiniz. Ayrı ama uyumlu yazmak en sağlıklı yöntemdir.
Hazır güvenlik ayarları özel yazılım için yeterli olur mu?
Genellikle hayır. Hazır ayarlar çoğu zaman genel kullanım içindir; oysa özel yazılımda veri türü, kullanıcı tipi ve iş akışı değişir. Bu yüzden kimlik doğrulama şifreleme loglama gereksinimleri işletmeye göre belirlenmelidir. Aynı parola politikası, aynı log seviyesi veya aynı şifreleme alanı her projede doğru sonuç vermez. İşe uygun tasarım daha güvenlidir.
Güvenlik gereksinimlerini kim yazmalı?
Tek başına teknik ekip yazmamalı. İş sahibi, operasyon ekibi, gerekiyorsa hukuk ve bilgi güvenliği tarafı birlikte çalışmalıdır. Çünkü kimlik doğrulama şifreleme loglama gereksinimleri hem teknik hem operasyonel hem de denetim boyutu taşır. İş birimleri riskleri anlatır, teknik ekip uygulanabilir hale getirir. Bu ortak çalışma, sonradan çıkan yanlış anlaşılmaları azaltır.