Informasi apa yang tidak boleh muncul di log? [Tutup]

Saya akan menulis pedoman perusahaan tentang apa yang tidak boleh muncul dalam log (jejak aplikasi). Bahkan, beberapa pengembang mencoba untuk memasukkan sebanyak mungkin informasi dalam jejak, membuatnya berisiko untuk menyimpan log tersebut, dan sangat berbahaya untuk mengirimkannya , terutama ketika pelanggan tidak mengetahui informasi ini disimpan, karena dia tidak pernah peduli tentang hal ini. dan tidak pernah membaca dokumentasi dan / atau pesan peringatan.

Misalnya, saat berurusan dengan file, beberapa pengembang tergoda untuk melacak nama file . Misalnya sebelum menambahkan nama file ke direktori, jika kita melacak semua kesalahan, akan mudah untuk memperhatikan misalnya bahwa nama yang ditambahkan terlalu panjang, dan bahwa bug dalam kode lupa untuk memeriksa panjang file. string bersambung. Ini membantu, tetapi ini adalah data sensitif, dan tidak boleh muncul dalam log .

Di jalan yang sama:

• Kata sandi ,
• Alamat IP dan informasi jaringan (alamat MAC, nama host, dll.) ¹,
• Akses basis data,
• Input langsung dari pengguna dan data bisnis yang disimpan

tidak boleh muncul dalam jejak.

Jadi, jenis informasi apa yang harus dibuang dari log? Apakah ada pedoman yang sudah tertulis yang dapat saya gunakan?

^{¹ Jelas, saya tidak berbicara tentang hal-hal seperti log IIS atau Apache. Yang saya bicarakan adalah jenis informasi yang dikumpulkan dengan satu-satunya maksud untuk men-debug aplikasi itu sendiri, bukan untuk melacak aktivitas entitas yang tidak dipercaya.}

Sunting: Terima kasih atas jawaban dan komentar Anda. Karena pertanyaan saya tidak terlalu tepat, saya akan mencoba menjawab pertanyaan yang diajukan di komentar:

• Apa yang saya lakukan dengan log?

Log aplikasi dapat disimpan dalam memori, yang berarti di plain pada hard disk di localhost, di database, lagi di plain, atau di Windows Events. Dalam setiap kasus, kekhawatirannya adalah bahwa sumber-sumber itu mungkin tidak cukup aman. Misalnya, ketika pelanggan menjalankan aplikasi dan aplikasi ini menyimpan log dalam file teks biasa di direktori temp, siapa pun yang memiliki akses fisik ke PC dapat membaca log tersebut.

Log aplikasi juga dapat dikirim melalui internet. Misalnya, jika pelanggan memiliki masalah dengan suatu aplikasi, kami dapat memintanya untuk menjalankan aplikasi ini dalam mode penelusuran lengkap dan mengirimkan file log kepada kami. Juga, beberapa aplikasi mungkin mengirim laporan kerusakan secara otomatis kepada kami (dan bahkan jika ada peringatan tentang data sensitif, dalam kebanyakan kasus pelanggan tidak membacanya).

• Apakah saya berbicara tentang bidang tertentu?

Tidak. Saya hanya mengerjakan aplikasi bisnis umum, jadi satu-satunya data sensitif adalah data bisnis. Tidak ada yang terkait dengan kesehatan atau bidang lain yang dicakup oleh peraturan khusus. Tapi terima kasih untuk membicarakan hal itu, saya mungkin harus melihat beberapa bidang untuk petunjuk tentang apa yang dapat saya sertakan dalam pedoman.

• Bukankah lebih mudah untuk mengenkripsi data?

Tidak. Ini akan membuat setiap aplikasi jauh lebih sulit, terutama jika kita ingin menggunakan diagnostik C # dan TraceSource. Anda juga perlu mengelola otorisasi, yang bukan cara termudah untuk dilakukan. Akhirnya, jika kita berbicara tentang log yang dikirimkan kepada kita dari pelanggan, kita harus dapat membaca log, tetapi tanpa memiliki akses ke data sensitif. Jadi secara teknis, lebih mudah untuk tidak memasukkan informasi sensitif dalam log sama sekali dan tidak pernah peduli tentang bagaimana dan di mana log tersebut disimpan.

Saya percaya cara terbaik untuk menangani ini adalah memperlakukan file log hanya sebagai antarmuka pengguna ke aplikasi. Fakta bahwa informasi tersebut disimpan dalam file teks tidak membuat konten berbeda dari informasi yang ditampilkan pada layar biasa di antarmuka pengguna.

Pikirkan tentang bagaimana Anda akan melindungi informasi yang sama jika itu akan ditampilkan di antarmuka pengguna biasa. Anda harus mengidentifikasi siapa pengguna itu dan kemudian hanya memaparkan informasi yang berhak dilihat oleh pengguna ini.

Informasi dalam file log harus diperlakukan dengan cara yang sama. Pertama-tama Anda harus menjawab dengan tepat siapa yang harus dimasukkan untuk melihat file log dan informasi apa yang harus mereka lihat.

Melewati file log yang dirancang dengan buruk di sekitar adalah risiko keamanan yang sangat besar. Saya tidak percaya Anda akan mendapatkan solusi yang baik dengan memasukkan beberapa jenis data ke daftar hitam. Strategi yang lebih baik adalah memasukkan daftar putih apa yang bisa masuk di setiap file log dan mendesain file log dari bawah ke atas.

Informasi kartu kredit tidak boleh dicatat.

Nomor ID (seperti SSN di AS atau Teudat Zehut # di Israel).

Nama komputer jaringan, jalur berbagi jaringan.

Informasi kesehatan yang dapat diidentifikasi secara pribadi dicakup oleh Portabilitas dan Akuntabilitas Asuransi Kesehatan tahun 1996 (HIPAA). Artikel ini mencantumkan contoh-contoh berikut:

• Klaim perawatan kesehatan atau informasi pertemuan perawatan kesehatan, seperti dokumentasi kunjungan dokter dan catatan yang dibuat oleh dokter dan staf penyedia lainnya;
• Pembayaran perawatan kesehatan dan saran pengiriman uang;
• Koordinasi manfaat perawatan kesehatan;
• Status klaim perawatan kesehatan;
• Mendaftar dan membatalkan dalam rencana kesehatan;
• Kelayakan untuk rencana kesehatan;
• Pembayaran premi rencana kesehatan;
• Sertifikasi dan otorisasi rujukan;
• Laporan cedera pertama;
• Lampiran klaim kesehatan.

jika keamanan menjadi perhatian, enkripsi file log

Dari atas kepala saya....

Informasi kartu kredit tidak boleh dalam bentuk log. Data SSN (atau SIN) tidak boleh dalam log.

... tentu saja ada pengecualian, jika Anda kebetulan bekerja untuk beberapa penyimpanan data pusat untuk perusahaan kartu kredit atau lembaga pemerintah yang mengelola data SIN, maka Anda mungkin harus mencatatnya, karena itu adalah daging utama dari apa yang Anda Sedang memproses / mengelola.

Ya tapi

Untuk men-debug beberapa masalah, Anda memerlukan data nyata.

Jadi, Anda harus memainkan permainan keseimbangan: Anda sebenarnya harus mendiskusikan dan menyetujui dengan klien utama Anda apa yang mereka anggap sebagai data rahasia atau sensitif dan apa yang tidak. Jika beberapa klien tidak setuju, ambil skenario kasus terburuk untuk setiap aspeknya, kecuali Anda dapat membenarkannya untuk klien yang mungkin berlebihan dalam memberi label segala sesuatu yang sensitif.

Saya telah bekerja di bidang kontrol lalu lintas udara, keuangan, dan perbankan. Dalam setiap situasi ada data sensitif. Ada tugas yang tidak dapat dihindari untuk menangani data sensitif, dalam hal ini Anda harus memastikan bahwa Anda dapat bekerja dengan orang yang dapat dipercaya. Risiko ini dapat agak dikurangi dengan klausul hukum yang harus disepakati sebelum mengakses data tersebut (perjanjian non-pengungkapan, penggunaan data hanya untuk alasan bisnis yang valid, akses terbatas ke data, hukuman penuntutan karena gagal menghormati atau menegakkan perjanjian ...) - dan proses yang relevan yang memungkinkan untuk melacak hal-hal itu.

Jika data sangat penting maka Anda harus membayar harga dalam menyiapkan sistem yang melindungi integritas, koherensi, dan keamanan data ini.

Yang mengatakan Anda benar untuk mengajukan pertanyaan 'data mana'. Sungguh Anda menjawabnya sendiri: sebagian besar terkait bisnis. Jadi tanyakan klien Anda jika Anda tidak dapat menjawab sendiri - mengingat semua hal di atas dan mempertahankan beberapa cara untuk mengidentifikasi dan memperbaiki masalah yang mungkin muncul.

Saya akan mengatakan, catat pesan yang tampak lucu saat Anda mengkode. Anda tidak akan menemukan mereka lucu di telepon dan mereka akan berada di sana selamanya - seperti posting blog / facebook / twiter yang keliru!

Simpan pesan log yang membosankan :)