Bagaimana saya bisa mencegah programmer menangkap data yang dimasukkan oleh pengguna?


10

Saya sedang mengembangkan aplikasi web dengan fokus yang kuat pada keamanan. Tindakan apa yang dapat diambil untuk mencegah mereka yang bekerja pada aplikasi (programmer, DBA, staf jaminan kualitas) menangkap nilai yang dimasukkan pengguna yang harus dilindungi, seperti kata sandi, nomor jaminan sosial, dan sebagainya?


3
Saya menyarankan agar Anda memposting pertanyaan di: security.stackexchange.com/?as=1
NoChance

"Cegah" adalah kata yang sangat kuat. Anda tidak dapat mencegah aktor jahat melakukan hal buruk. Apa yang dapat Anda lakukan adalah mempelajari dan menerapkan prinsip-prinsip keamanan mendasar seperti "hak istimewa," "pemisahan tugas" dan "penolakan implisit," merancang berbagai hal dengan cara yang aman, dan mempekerjakan orang yang dapat Anda percayai. Memiliki rencana yang bisa diterapkan untuk mengurangi kerusakan ketika hal yang tak terhindarkan akhirnya terjadi.
Robert Harvey

Istilah teknis untuk teknologi yang Anda butuhkan: hashing dan enkripsi.
Robert Harvey

Jawaban:


22

Ini cukup sederhana. Bank selalu melakukannya.

Anda melibatkan tiga kelompok orang. Ini adalah kelompok keamanan. Dengan otorisasi yang berbeda.

Pengembang tidak dapat menetapkan otorisasi keamanan dan tidak dapat melihat data produksi.

Operator tidak dapat menetapkan otorisasi keamanan dan tidak dapat membuat perangkat lunak.

Orang-orang keamanan yang mengatur otorisasi dan tidak dapat membuat perangkat lunak atau mengoperasikan perangkat lunak.

Pengembang membuat perangkat lunak. Operator menginstalnya dan mengoperasikannya. Petugas keamanan memastikan bahwa kedua kelompok tetap terpisah.


8
OK, tapi pengembang masih bisa menambahkan sesuatu ke sistem yang mengirimkan data produksi melalui email ke akun pribadinya; atau menulis data produksi ke beberapa server di mana dia akan mengambilnya. Saya pikir satu-satunya cara mengatasi ini adalah dengan rezim peninjauan kode yang ketat.
Dawood ibn Kareem

3
Selalu ada tingkat kepercayaan yang diberikan kepada karyawan. Seseorang harus memiliki kunci untuk istana, dan jika Anda tidak dapat percaya bahwa mereka memahami kekuatan yang diberikan kepada mereka, maka mungkin kita tidak seharusnya memberikan kunci-kunci itu kepada orang itu sejak awal.
Chris

1
Ya, tetapi memiliki kunci yang memerlukan lebih dari satu orang (seperti rezim peninjauan kode) berarti bahwa Anda memerlukan dua untuk "sesat" sebelum Anda dikompromikan dan itu lebih kecil kemungkinannya daripada karyawan "hanya satu" yang tersesat dan menyalahgunakan kunci yang diberikan kepada mereka. Ini semua masalah keseimbangan kepercayaan dan konsekuensi dari kepercayaan yang disalahgunakan. Dan jangan lupa bahwa orang dan keadaan berubah. Seseorang yang dapat dipercaya ketika kunci diberikan dapat memiliki hal-hal yang terjadi dalam hidup dimana dia menjadi kurang dapat dipercaya ...
Marjan Venema

1
@EmmadKareem: Benar. Security person mengatur dan mengatur ulang grup dan kata sandi, tetapi tidak dapat melihat data. Hanya operator yang dapat melihat data nyata. Pikirkan data seperti uang aktual yang ditangani oleh teller yang sebenarnya. Programmer tidak menyentuh uang; hanya teller. Demikian pula, orang-orang keamanan tidak menyentuh uang; hanya teller yang menyentuh uang.
S.Lott

1
@EmmadKareem: DBA bukan pengembang. Ada dua kelompok: keamanan dan data. Data DBA adalah bagian khusus dari "operasi". Mereka seharusnya tidak memiliki otorisasi untuk mengubah keamanan; mereka tidak dapat menulis kode; mereka akan melihat data, dan harus diperlakukan seperti operator, bukan pengembang.
S.Lott

2

Programmer tidak memiliki akses ke server produksi. Tetapi seseorang harus memiliki akses. Tidak ada jalan lain. Dan selalu ada kemungkinan seseorang menjadi gila dan menyalahgunakan akses mereka.

Data yang hash / asin secara teoritis aman bahkan dari orang-orang yang memiliki akses penuh untuk melihatnya. Tetapi sebagian besar data tidak sesuai untuk hashing.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.