Günlüklerde asla görünmemesi gereken şeylerle ilgili şirket yönergeleri yazmak üzereyim (bir uygulamanın izi). Aslında, bazı geliştiriciler izlemeye mümkün olduğunca çok bilgi eklemeye çalışır, bu günlükleri saklamayı riskli hale getirir ve özellikle müşteri bu bilgilerin saklandığını bilmediğinde, bunları göndermek son derece tehlikelidir , çünkü bunu hiç umursamadı ve asla belgeleri ve / veya uyarı mesajlarını okumayın.
Örneğin, dosyalarla uğraşırken, bazı geliştiriciler dosyaların adlarını izlemeye cazip gelir . Örneğin, bir dizine dosya adı eklemeden önce, yanlışlıkla her şeyi izlersek, örneğin ekteki adın çok uzun olduğunu ve koddaki hatanın birleştirilmiş dize. Yararlı, ancak bu hassas verilerdir ve asla günlüklerde görünmemelidir .
Aynı şekilde:
- Şifreler ,
- IP adresleri ve ağ bilgileri (MAC adresi, ana bilgisayar adı, vb.) ¹,
- Veritabanı erişimi,
- Kullanıcıdan ve depolanmış iş verilerinden doğrudan girdi
asla izinde görünmemelidir.
Peki günlüklerden başka hangi tür bilgiler yasaklanmalıdır? Kullanabileceğim önceden yazılmış yönergeler var mı?
IIS Açıkçası, IIS veya Apache günlükleri gibi şeylerden bahsetmiyorum. Bahsettiğim şey, güvenilmeyen varlıkların etkinliğini izlemek için değil, uygulamanın kendisinde hata ayıklamak amacıyla toplanan bilgi türüdür.
Düzenleme: Cevaplarınız ve yorumlarınız için teşekkür ederiz. Sorum çok kesin olmadığından, yorumlarda sorulan soruları cevaplamaya çalışacağım:
- Kütüklerle ne yapıyorum?
Uygulamanın günlükleri bellekte depolanabilir, yani localhost üzerindeki sabit diskte düz olarak, bir veritabanında, yine düz olarak veya Windows Olayları'nda saklanabilir. Her durumda endişe, bu kaynakların yeterince güvenli olmayabileceğidir. Örneğin, bir müşteri bir uygulamayı çalıştırdığında ve bu uygulama günlükleri geçici dizinde geçici metin dosyasında sakladığında, PC'ye fiziksel erişimi olan herkes bu günlükleri okuyabilir.
Uygulama kayıtları internet üzerinden de gönderilebilir. Örneğin, bir müşterinin bir uygulamayla ilgili bir sorunu varsa, bu uygulamayı tam izleme modunda çalıştırmasını ve bize günlük dosyasını göndermesini isteyebiliriz. Ayrıca, bazı uygulamalar otomatik olarak kilitlenme raporunu bize gönderebilir (ve hassas verilerle ilgili uyarılar olsa bile, çoğu durumda müşteriler bunları okumaz).
- Belirli alanlardan mı bahsediyorum?
Hayır. Yalnızca genel iş uygulamaları üzerinde çalışıyorum, bu yüzden tek hassas veri iş verileridir. Sağlıkla veya belirli düzenlemelerin kapsadığı diğer alanlarla ilgili hiçbir şey yoktur. Ancak bunun hakkında konuştuğunuz için teşekkür ederim, muhtemelen bu alanlara, kılavuzlara neleri ekleyebileceğime dair bazı ipuçları için bakmalıyım.
- Verileri şifrelemek daha kolay değil mi?
Hayır. Özellikle C # diagnostics ve kullanmak istiyorsak, her uygulamayı çok daha zor hale getirir TraceSource. Ayrıca, yapılması en kolay düşünce olmayan yetkilerin yönetilmesi de gerekir. Son olarak, bir müşteriden bize gönderilen günlüklerden bahsediyorsak, hassas verilere erişmeden günlükleri okuyabilmeliyiz. Bu nedenle teknik olarak, hassas bilgileri asla günlüklere dahil etmek ve bu günlüklerin nasıl ve nerede saklandığını hiç umursamamak daha kolaydır.
debugbir dosya adı için uygun olabilir , ancakinfobir dosya adı için uygun olmayabilir .