Web Uygulaması şifreleme anahtarı yönetimi

Question

Özetle, bazı bilgileri bir veritabanında şifreli veri olarak depolayan bir web uygulamasını ele alalım. Ben bilerek bunu genel ne tutmak için çalışırken, İşte bazı varsayımlar:

Şifrelenmiş veriler yalnızca veritabanında saklanır (başka yerlerde değil). Belirli bir kayıttaki bazı alanlar şifrelenir, bazıları değildir.
Web uygulaması şifrelenmiş verileri veritabanına yazmalıdır.
Web uygulaması şifrelenmiş verileri okuyabilmeli ve görüntüleyebilmelidir. Veriler yalnızca uygulamanın kimlik doğrulama ve yetkili yönetilen bölümünde görüntülenir.
Veriler, verilerin açığa çıkması/erişilmesi durumunda korunması gereken hassas bilgilerdir (anahtarlar olmadan *).

Sorular:

Şifreleme için kullanılan anahtarları nerede/nasıl saklarsınız? İlk olarak, web ve veritabanı sunucularının aynı olduğu bir sistemde, anahtarı nasıl yönetirsiniz? İkinci olarak, web sunucusunun ve DB sunucularının ayrı olduğu sistemlerde, anahtarı nasıl yönetirsiniz?
Anahtarlar yalnızca izin kısıtlamalı dosyalar mıdır? Ayrı bir araç/yazılımda mı saklanıyorsunuz? Bazen şifreleme anahtarlarının da şifreli olduğunu, ancak bunun nerede yardımcı olabileceği konusunda net olmadığını belirtmiştim.

Bunun oldukça basit bir güvenlik sorusu olduğunu biliyorum ve bu yüzden belki de özlediğim kaynaklar varsa, bu da çok, çok yardımcı olacaktır. Web uygulaması güvenliği (OWASP, PCI DSS, vb.) Hakkındaki bilgilere dayanarak bu bilgileri kavramaya çalışarak (yıllar boyunca) çok zaman geçirdim, ancak çoğu zaman bu bilgiler çok genel (ör. "," verileri şifreleme ") veya çok özel (" AES ile bir şeyi şifrelemek için bunu yapın ... ").

* Bunun kendi başına tam bir güvenlik çözümü olmadığını anlıyorum. Bu bilgiye ulaşmak ve kodunu çözmek için birkaç vektör olduğunu anlıyorum. Bunun bu açıdan zayıf bir soru olabileceğini kabul ediyorum :)

Bu soruya varsayımlar hakkında daha fazla bilgi eklemek için düzenlendi

Rakkhi · Accepted Answer

Şifreleme için kullanılan anahtarları nerede/nasıl saklıyorsunuz?

SQL veya Oracle veritabanı gibi bir şeyde yerleşik şifreleme kullanıyorsanız, standart yaklaşım, veritabanı bir şifreleme anahtarı oluşturur ve bunu başka bir anahtar koruma anahtarı veya Ana anahtarla şifreleyecektir. Bu, bir parola veya ör. .pem dosyası.

Bu genellikle yalnızca kök/Yönetici ve veritabanı hizmeti hesabının erişebileceği kısıtlı bir dizinde depolanır. Veritabanı başlatıldığında anahtar okunur ve belleğe yüklenir. Bu daha sonra şifreleme anahtarlarının şifresini çözmek için kullanılır.

İlk olarak, web ve veritabanı sunucularının aynı olduğu bir sistemde, anahtarı nasıl yönetirsiniz?

Anahtar, sunucudaki bir dizinde saklanır. Yenilemek veya iptal etmek genellikle veritabanı programı aracılığıyla yapılır.

İkinci olarak, web sunucusu ve DB sunucularının ayrı olduğu sistemlerde, anahtarı nasıl yönetirsiniz?

Anahtar yerel olarak sadece veritabanı sunucusunda saklanır. Daha güvenli bir seçenek, her iki senaryoda da bir Donanım Güvenlik Modülü (HSM) kullanmaktır. Bu, sunucuya bağlı ve sunucuda kısıtlı bir klasör yerine anahtarı depolamak için kullanılan bir donanım aygıtıdır.

Anahtarlar yalnızca izinle kısıtlanmış dosyalar mı? Ayrı bir araç/yazılımda mı saklanıyorsunuz? Bazen şifreleme anahtarlarının da şifreli olduğunu, ancak bunun nerede yardımcı olabileceğinden emin olmadığını belirttim.

Yönetici erişimini yönettiğiniz ve yetkisiz girişler, hizmet hesabı olarak girişler, yeni hesaplar veya klasöre erişim ile eklenen gruplar gibi şeyleri izlediğiniz sürece klasör kısıtlaması kabul edilebilir. Yukarıda belirtildiği gibi, koruduğunuz veriler ve karşılaştığınız tehditler buna ihtiyaç duyuyorsa HSM daha güvenli bir seçenektir.

Genellikle veritabanı örnek veya tablo anahtarları oluşturur ve bunu ana anahtarla şifreler. Ana anahtarı daha fazla şifrelemenin en az yararı vardır.

AviD · Answer

Önceki cevapta bazı iyi bilgiler sağlanmış olsa da, gerçekten fark edilmeyen kritik bir tasarım hatası vardır - ancak sorudaki örtülü varsayımlardan bazılarından gelir.

Fark aşağıdakiler arasında olmamalıdır:

Aynı sunucuda Web uygulaması ve DB
Farklı sunucularda Web uygulaması ve DB
uygulama vs db şifreleme

Tasarım şunlardan başlamalıdır:

Kimlerin şifreleme/şifre çözme anahtar (lar) ına erişmesi gerekiyor?

Veya aslında daha da doğru:

Verilerin gizliliğini korumaktan kim sorumludur?

Hangi sırayla geliyor:

Hangi tehditlere karşı korumaya çalışıyorsunuz?
Veya
Kimlerin verilerinizi okumasını engellemeye çalışıyorsunuz?

Sadece bu sorulara dayanarak, uygun şekilde tasarlanmış bir şifreleme sistemi tasarlayabilirsiniz. (@ D.W.'nin bahsettiği kripto peri tozunu önleyin).

Yani, bazı örnek senaryolar:

Şifrelemeden kullanıcı sorumlu olmalı ve uygulama yöneticilerinin verileri görmesini engellemelidir
İstemci uygulaması, kullanıcıyı dahil etmek zorunda kalmadan sorumlu olmalıdır - ancak bunun yine de istemci tarafında yapılması gerekir (örn. Bir yedekleme programı).
Uygulayıcı, iş mantığının bir parçası olarak seçilen verileri özel olarak ve özellikle şifreler (dba bile verileri göremez)
Veritabanı sunucusu depolanan verileri otomatik ve şeffaf bir şekilde şifrelemelidir. (Bu sadece uyarılar ile db dosyasının/fiziksel diskin çalınmasına karşı korur ...).

Basitlik açısından, şifrelemenin sunucu tarafında yapılması, sorumluluğun sunucuda olması ve son kullanıcının (ve yöneticinin) şifreleme üzerinde bir etkisi olmadığını varsayalım.

Ana soru, şifreleme uygulama sunucusu veya veritabanı sunucusu tarafından mı gerçekleştiriliyor? (Aslında o kadar basit değil, başka seçenekler de var ...)
Bu, çoğu güvenlik sorununun yaptığı gibi, bir ödünleşmeye geri dönüyor:

Kendi anahtarlarınızı yönetecek misiniz yoksa altyapı özeti bunu otomatik olarak mı tercih ediyorsunuz? (asıl soru ... aşağıda daha fazla bilgi ...)
Kötü amaçlı (veya ~~beceriksiz~~ deneyimsiz) programcılar?
Kötü niyetli yöneticilerden endişe duyuyor musunuz?
Yetkisiz uygulama kullanımı konusunda endişeli misiniz?
Yetkisiz SQL erişimi konusunda endişeli misiniz?
Yetkisiz doğrudan dosya erişiminden endişe duyuyor musunuz?
Fiziksel disk/sunucu hırsızlığı konusunda endişeli misiniz?

Ve bunun gibi. (Yukarıdaki soruların bazılarının alakasız olduğunu ve sunucu şifrelemesi ile çözülemeyeceğini unutmayın).

Şimdi, yukarıdakilere dayanarak, uygulama sunucusu şifrelemesi ile veritabanı şifrelemesi arasında karar verdiğinizi varsayalım.
Web sunucusu ve db aynı sunucuda olsun ya da olmasın, burada neredeyse hiçbir etkisi yoktur - uygulama şifreliyorsa, o zaman sadece db için "özel" veri gönderiyor, aksi takdirde tartışma. Ancak, bu yok yukarıdaki tehdit tartışmasını etkiler - bazı sorunlar tasarım tarafından kullanılmaz, bazıları geliştirilir ...

Web/Uygulama sunucusu şifrelemesi
- Verileri şifrelemek için kullandığınız şifreleme anahtarının (EK) kendisi bir anahtar şifreleme anahtarı ( KEK).
- Şifrelenmiş EK korumalı bir yerde saklanmalıdır - bu bir dosya, bir kayıt defteri anahtarı, ne olursa olsun - önemli olan, erişimin yalnızca uygulamanın kullanıcısına (ve belki de yöneticiye - aşağıya bakınız) erişimini kısıtlamasıdır.
- KEK'nin de korunmaya ihtiyacı var - bu biraz daha hileli.
  Windows kullanıyorsanız, DPAPI - OS düzeyinde anahtar yönetimi sağlar, böylece işletim sisteminiz olabilir KEK'inizi şifreleyin ve anahtarları sizin için şeffaf bir şekilde yönetin. (Sahne arkasında, DPAPI sonunda kullanıcının şifresini bilmeye dayanır (USER_MODE içinde), bu gerçek bilinen bir sırrın son, zayıf noktasıdır - ancak başka hiç kimse bilmek sunucunun şifresi ilk sırada, değil mi?)
  Başka bir seçenek, aşağıda daha ayrıntılı olarak ele alınan harici cihaz/HSM'dir.
- KEK ayrıca, kısıtlayıcı ACL'ler ve bunların hepsinin de erişim kontrolüne ihtiyacı var.
- EK'yi KEK'ten ayırmak için birkaç neden vardır: büyük miktarda veriyi tek bir anahtarla şifrelemek istemezsiniz; anahtarı değiştirmeniz gerekirse, çok daha kolay hale gelir (EK'yi yeni KEK ile yeniden şifreleyin); KEK'de daha güçlü, daha yavaş, daha karmaşık şifreleme/depolama kullanabilirsiniz; PCI uyumlu olmanız gerekiyorsa, KEK'e bölünmüş bilgi uygulayabilirsiniz; ve dahası.
- Hem EK hem de KEK, uzun vadeli şifrelenmemiş olarak depolanmamalıdır - platformunuza/dilinize bağlı olarak bu, ör. .NET veya Java'da bir String nesnesinde saklamayın. Bunun yerine, değiştirilebilir bayt dizilerinde saklayın ve her zaman en kısa zamanda attığınızdan emin olun.
- Bazı çerçeveler bir adım daha ileri gider ve belirli korumalı nesneler sağlar. Örneğin. .NET'te, anahtarları bellekte bile korumak için System.Security.Cryptography.ProtectedMemory ve/veya System.Security.Cryptography.ProtectedData sınıflarını kullanabilirsiniz.
Veritabanı şifreleme
- Veritabanı sunucunuzun şifrelemeyi gerçekleştirmesini sağladıysanız, bu çok daha kolay hale gelir: tablolar/alanlar, içinde depolanan tüm verileri otomatik olarak şifreleyecek şekilde yapılandırılır, anahtar yönetimi tamamen şeffaftır (DBA yerine uygulamanın PoV'sinden) ve yakında.
- Örneğin, Oracle ve MS SQL Server'ın her ikisi de otomatik yerleşik şifrelemeyi destekler. MSSQL için, anahtar yönetimi karmaşıktır, ancak yukarıda tarif ettiğim şeye benzer. Basitleştirilmiş: Veritabanında depolanan ve dba'nın tabloları veya alanları şifrelemek/şifrelerini çözmek için kullanmak üzere yapılandırabileceği bir EK vardır. Bu, bir KEK tarafından şifrelenen, sırasıyla bir sunucu seviyesi KEK tarafından şifrelenen ve MSSQL'in hizmet hesabındaki DPAPI kullanılarak şifrelenen korumalı bir tablodadır.
- Alternatif olarak, MSSQL aynı zamanda eşzamansız şifreleme, ör. ortak/özel anahtar çiftlerini saklama - bu, belirli senaryolarda yararlı olabilir.
Üçüncü seçenek: harici şifreleme depolama veya HSM (donanım güvenlik modülü) . Bu, paylaşılan bir donanım cihazı, sunucu veya bir donanım kartı veya dongle ... vb. Olabilir.
- Bu cihazlar, küçük veri parçalarını (örneğin KEK'iniz) çok güvenli bir şekilde korumak için tasarlanmıştır.
  Yine, EK'nin KEK'ten ayrılmasının bir başka nedeni - bu, KEK'yi güvenli bir şekilde yönetirken, veri kütlelerini EK ile verimli bir şekilde şifrelemenizi ve şifresini çözmenizi sağlayacaktır.
- HSM'ye genellikle özel bir sürücü veya API aracılığıyla erişilir, bunları veritabanı şifrelemesine de takmak mümkün olabilir (ürüne bağlı olarak, vb.).