Güvenlik standartlarının gerekliliklerini dikkate alan yazılım tasarımı

Bu yazıda, yazılım geliştirme sürecinde güvenlik standartları gereksinimlerinin uygulanmasına değinmek istiyorum. Genel olarak, PCI DSS standardının gereksinimlerine göre hazırlanmış ve derlenmiştir. Bu gereksinimler, GDPR‘nin gereksinimlerinin karşılanması açısından kişisel verilerin işlenmesi ve depolanması için de uygulanabilir. Dünyanın farklı yerlerinde farklı değerlendirme ve analizler var. Bu gereksinimleri detaylandırmaya ve açıklamaya çalışalım.

PCI DSS
PCI DSS

PCI DSS Gereksinimleri

  1. Depolama alanını ve kritik verilerin süresini en aza indirin.

Bu yayın bağlamında hassas veriler, güvenliği PCI DSS + GDPR gereksinimleri tarafından düzenlenen verilerdir (kart ve kişisel veriler gibi). Bu tür veriler prensipte gerekli midir yoksa anonim hale getirilebilir mi? Bu ciltte kritik verileri depolamak gerçekten gerekli mi? Yinelenen veriler önlenebilir mi ve nasıl en aza indirilebilir? gibi sorulara cevap bulmak lazımdır.

  1. Veri tabanlarındaki kritik verilerin şifrelenmiş biçimde saklanması tavsiye edilir.

Kritik veriler şifrelenmiş olarak saklanmalıdır. Bir veri tabanı (veya dosya sistemi) aracılığıyla şifreleme yeterlidir. Ancak, veri aktarımının bir parçası olarak ek şifreleme kullanmak ve daha sonra veri tabanına şifrelenmiş biçimde yerleştirmek çok daha güvenlidir.

Bu durumda, güçlü bir şifreleme algoritması belirlemek, anahtar değiştirildiğinde verilerin yeniden şifrelenmesi olasılığını sağlamak ve ayrıca bir anahtarı depolamak veya oluşturmak için güvenli bir yöntem sağlamak gerekir.

  1. İstemci ağ veri akışları şifrelenmelidir.

Kritik veriler, şifrelenmiş bir kanal üzerinden iletilmelidir. Kritik ağ verileri, şifrelenmiş bir kanal üzerinden iletilmelidir. Resmi olarak TLS güvenlik protokolünü kullanmak yeterlidir, ancak aktarılan bilgilerin yazılım düzeyinde şifrelenmesini sağlamak daha iyidir. Uygulamanın veritabanlarına şifreli olarak bağlanması tavsiye edilir.

  1. Ödeme kartlarının fotoğrafları alınırsa, güvenlik gerekliliklerine uygun olmalıdır.

Doğrulama süreçleri için kullanıcı verilerinin toplanması genellikle, kart verilerinin (PAN, CVV) gösterilebileceği ödeme kartlarını gösteren grafik materyallerin toplanmasını içerir. Basit bir çözüm olarak bu tür verileri sistemlerden silmek ve müşteriden gerekli formatın kendi başına fotoğraf kopyalarını yeniden sağlamasını istemektir. Bir sonraki seçenek, kritik verileri kendiniz silmek ve fotoğrafı onsuz kaydetmektir. Daha da ilginç bir seçenek ise grafik görüntülerde CVV ve kart numaralarını tanımak ve bulanıklaştırmak için kendinizin yazabileceği veya satın alınan hizmetlerdir.

  1. Veri tabanları, uygulama alt ağından ayrı bir alt ağda olmalıdır.

Kritik veri sızıntısı riskini azaltmak için, veritabanları uygulamaların bulunduğu alt ağdan ayrı konumlandırılmalıdır. Her yerde bulunan sanallaştırma göz önüne alındığında, veritabanı ve uygulamaların ek olarak ayrılması olasılığının da göz önünde bulundurulması önerilir.

  1. Çalıştırma sürecinde tüm test parametreleri silinmelidir.

Kimlik bilgileri genellikle entegrasyonun bir parçası olarak kullanılır. Bu da bazı riskleri beraberinde getirir. Üretim ortamına aktarılırken test verilerinin kullanılması tavsiye edilir, bu tür veriler değiştirilmeli veya silinmelidir.

  1. Güvenli teknolojilerin ve güçlü şifreleme algoritmalarının kullanılmasını gerektirir.

Tüm şifreleme algoritmaları güçlü kabul edilmez.Ayrıca, hangi ülkenin bunu veya bu algoritmayı sipariş ettiğini ve algoritmanın kendisinde veya uygulamasında sürprizler olup olmadığını unutmayın.

  1. Kullanıcı şifrelerini saklamak yasaktır (sadece hash formatı müstesna)

Bu işin doğası gereği bu sıradan bir öneri gibi gelebilir. Ancak tam kullanıcı şifrelerine sahip kaynaklarda hala veri sızıntısı olduğu unutulmamalıdır. Bu şifreler karma olarak tutulabilir, ancak yine de bu kesinlikle gerekli bir işlem değildir. Hash’in kendisini sulandırmak daha iyidir.

  1. OWASP TOP 10 için kontrol edilmesi

Çözümü, işleme sokmadan önce büyük güvenlik açıkları için doğrulamak gerektir. Farklı güvenlik açıkları da denenebilir ama başlangıç ​​için en az OWASP TOP 10‘u kontrol etmeniz önerilir.

  1. Kişiselleştirilmiş hesapların kullanımı.

Hem test aşamasında hem de sistemi üretime aktarırken, yazılımda grup hesaplarının kullanımında dikkatli olmak gereklidir. Bu, soruşturma süreçlerini büyük ölçüde karmaşıklaştırır aynı zamanda kuvvetler ayrılığının olmasını sağlar.

  1. Dış sistemlere yeniden yönlendirme yeteneği ile eylemleri günlüğe kaydetme.

Sistem, kullanıcı eylemlerini günlüğe kaydetmek ve kart verilerine erişim için bir özellik sağlamalıdır. Günlük kaydı, uygun bir formatta dışa aktarmanın mümkün olacağı şekilde düzenlenmelidir. Daha sonra, günlüklerin bütünlüğünün ve bunların depolanmasının kontrolü ve korelasyon, büyük olasılıkla üçüncü taraf bir sistem kullanılarak uygulanmasını kolaylaştıracaktır. Günlükler kritik veri içermemelidir.

  1. Asgari gerekli haklarla kuvvetler ayrılığı sistemi.

Sistem, yetkilerin tanımlanması için bir sisteme sahip olmalıdır. Böyle bir sistem, rol temelli veya karma erişim modeline dayalı olabilir (matris de kullanılabilir, ancak destek ve önemli sayıda kullanıcı olduğunda çok karmaşıktır). Rollerin ayrılığı, kuvvetler ayrılığı matrisi temelinde inşa edilmelidir.

  1. Güvenli anahtarlarla şifreleme.

Anahtarlar yılda en az bir kez değiştirilmelidir. Anahtar iletimi güvenli kanallar aracılığıyla yapılmalıdır. Anahtar depolama, tehlikeye atılma olasılığını en aza indirecek şekilde sağlanmalıdır (güvenli anahtar depolama çözümleri, paylaşılan anahtar depolama, veriye dayalı anahtar oluşturma süreçleri).

  1. Parola gücü için gereksinimler.

Kaba kuvvet saldırılarına geçit vermeyen şifreler seçilmelidir. Şifrelerin depolanması ve iletilmesi, tehlikeye düşme olasılığını en aza indirecek şekilde (şifre saklama, ayrı saklama vb.) sağlanmalıdır.