Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Pendekatan Keamanan dalam Pemodelan Data. Bagian 4

Ini adalah yang keempat dalam seri multi-bagian kami tentang pemodelan data untuk keamanan informasi serta karakteristik data. Model data sederhana untuk situs web fiksi yang mendukung organisasi dengan minat bersama (klub pengamat burung, dll.) telah memberi kami konten untuk menjelajahi pemodelan data dari sudut pandang keamanan.

Dalam drama Oscar Wilde Penggemar Lady Windermere , Lord Darlington menandai orang yang sinis sebagai “seseorang yang mengetahui harga dari segala sesuatu, dan nilai dari ketiadaan”. Sayangnya, informasi dalam database kami dapat secara tidak sadar diperlakukan dengan cara yang sama. Apakah akun pelanggan sebanding dengan jumlah pembeliannya? Apa yang kita derita jika kita kehilangan empat jam data pemasaran selama musim belanja liburan?

Kami pemodel data tidak akan membuat penilaian tersebut, tetapi kami harus menyimpan data mereka yang relevan atas nama orang yang akan melakukannya. Kita harus mengisi celah dari struktur data implisit. Dalam artikel ini, kita akan melihat cara menambahkan elemen keamanan penting ini ke database kita.

Tunjukkan Uangnya!

Berapa banyak kita harus melindungi setiap objek data? Pertimbangkan mereka dalam hal Kerahasiaan , Integritas , dan Ketersediaan — kualitas kunci yang menentukan keamanan sistem informasi. Kita juga harus memperhitungkan perbedaan antara langkah-langkah ini atas dasar "intrinsik" dan seberapa besar data ini dapat memengaruhi keamanan.

Ada dua alasan untuk melakukan ini. Pertama, ini akan membantu kita untuk melihat bagaimana melindungi data di database klub kita. Haruskah beberapa tabel dienkripsi? Dimasukkan ke dalam skema lain? Mungkin di bagian hilir kami akan melampirkan kontrol Basis Data Pribadi Virtual? Informasi ini akan membantu kita untuk memilih perlindungan yang tepat.

Kedua, kita akan merenungkan data dari perspektif akuntansi mentah:Berapa nilai totalnya? Apa yang bisa kita hilangkan jika terjadi korupsi data? Apa tanggung jawab kami jika data pribadi diungkapkan? Saat kami menambahkan informasi ini ke skema kami, kami menambahkan metrik penting ke data kami yang tersimpan:dolar dan sen. Hal ini memungkinkan orang yang membayar tagihan menentukan apa yang mereka mampu untuk keamanan ––– dan, dengan cara moneter, berapa nilainya.

Semua Hubungan Dijabarkan

Mari kita rekap keadaan model kita. Pada artikel terakhir, struktur data telah diisi. Orang, klub, keanggotaan, foto, album, dan konten ada di sana. Bagaimana mereka mengikat bersama ada di sana. Skema ini siap untuk menyimpan data dengan hubungan yang ditangkap secara eksplisit, sementara hubungan implisit telah dihilangkan sejauh mungkin.



Mengatribusikan Nilai dan Sensitivitas

Sekarang kita akan mencari tahu cara memasukkan angka ke data. Kami benar-benar tidak dapat melampirkan satu nilai ke item data yang memberi tahu kami berapa banyak untuk melindunginya. Namun, kami juga tidak bisa — dan tidak perlu — masuk ke kumpulan metrik. Kami akan fokus pada berapa banyak yang dapat diperoleh dari sepotong data untuk kami, dan berapa banyak kerugian atau kerugian yang diakibatkan oleh hilangnya atau mengungkapkan data tersebut kepada kami.

Kami menggunakan istilah "nilai" dan "sensitivitas" untuk ini – pengukuran positif dan negatif, jika Anda mau. Nilai sering dianggap sebagai nilai atau peluang masa depan. Sensitivitas sangat defensif; itu berkaitan dengan risiko pada tingkat keuangan (hukuman peraturan atau hukum) dan hilangnya reputasi atau niat baik.

Penilaian berhubungan langsung dengan Integritas dan Ketersediaan . Kami akan menilai ini dalam hal manfaat apa yang dapat dihasilkan data, atau berapa banyak kerusakan yang akan terjadi jika akses ke data tersebut hilang. Kami menangani sensitivitas terutama dalam hal Kerahasiaan , yang harus diukur dengan kerusakan atau tanggung jawab jika terungkap.

Struktur Umum Penilaian dan Sensitivitas

Sekarang mari kita pertimbangkan penilaian dan sensitivitas terhadap database kami. Saat kami melihat model data lagi, kami menemukan bahwa kualitas ini relatif hanya untuk klub atau seseorang. Sebuah klub atau seseorang mendapat manfaat dari nilai sesuatu, dan mereka menderita ketika sesuatu yang sensitif dipublikasikan. Oleh karena itu, masing-masing penilaian ini terkait dengan klub atau seseorang. saat kami melihat entitas data kami, kami akan memastikan bahwa setiap entitas yang memiliki nilai (manfaat) juga membawa sensitivitas (risiko), dan sebaliknya. Jadi setiap entitas yang terlibat akan memiliki keduanya, bidang Penilaian dan Sensitivitas yang terpisah. Mereka akan menjadi opsional atau default dalam banyak kasus. Juga, keduanya akan ditimbang dalam bentuk uang:nilai mata uang, tepat hingga seperseratus dolar AS. (Demi kejelasan, kami hanya akan menggunakan satu mata uang.) Rayakan atau tangisi, uang adalah satu-satunya metrik kami yang dapat digunakan untuk keduanya. Untuk memanfaatkan kesamaan ini, kami akan menyebutnya "Penting".

Sebagai pemodel data, kami tidak dapat benar-benar memberi angka pada ini sendiri. Bahkan sebagai operator situs atau database, kami tidak cukup tahu untuk menetapkan nilai-nilai ini; selain itu, datanya tidak sepenuhnya milik kami. Untuk data yang khusus untuk klub, kita harus membiarkan klub itu menetapkan miliknya sendiri tingkat kepentingan dan aturannya untuk menggunakan tingkat tersebut. Kemudian kami menerapkan aturan mereka ke data mereka.

Mari kita mulai dengan jenis entitas yang dapat ditetapkan klub.

Data Klub

Entitas Klub adalah:

  • Klub
  • Kantor_Klub
  • Petugas
  • Anggota
  • Album
  • Foto_Album
  • Foto

Kami akan menambahkan Valuation dan Sensitivity kolom untuk masing-masing. Karena kolom ini dilampirkan ke Klub , nama mereka spesifik – mis. club_sensitivity .

Berikut adalah kumpulan tabel fokus kami untuk Klub , termasuk Orang :



Data Pribadi

Sekarang kita perlu menangani Person kesatuan. Sekali lagi, kami tidak menetapkan nilai di sini – itu adalah hak prerogatif orang tersebut. Secara alami, kita perlu menambahkan kolom Penting ke Orang . Tetapi untuk mendukung privasi pribadi dengan lebih baik, kami akan memotong entitas ini dengan lebih baik. Bagaimanapun, privasi adalah kunci untuk sensitivitas data.

Pertama, kita akan menambahkan kolom baru bernama monicker itu seperti nama pengguna atau alias. Anggota klub dapat menggunakannya untuk identifikasi daripada nama asli mereka. Kami akan memberikan pasangan kolom penilaian/sensitivitas untuk asosiasi nama-monicker. Ini akan menjadi person_name_valuation dan person_name_sensitivity . Bidang lainnya dikendalikan oleh dua pasangan ini.

Seseorang aktivitas klub sama menariknya dengan Klub 's. Oleh karena itu kami akan menambahkan bidang Penting yang sama ke Anggota dan Petugas .

Sekarang kita bisa menambahkan person_importance bidang ke Foto entitas, tetapi lihat photo_content kolom. Sebuah foto dapat melibatkan banyak orang, dan ini adalah bagian dari apa yang kami simpan di photo_content. Oleh karena itu, kami akan menempatkan bidang penting pada photo_content. bukan di Foto.

Model “Peka”

Kami telah memodifikasi model data kami untuk menganggap nilai data dan sensitivitas data di mana pun diperlukan. Berikut ini adalah skema terakhir kami.

Kami telah berhati-hati untuk menghindari distorsi skema asli dengan hubungan atau batasan tambahan. Ini penting karena kami menggunakan skema itu sebagai analisis akurat dari data nyata dengan aturan bisnis nyata.




Melampirkan segala jenis kepentingan yang melekat pada data Anda itu sulit. Lebih buruk lagi jika Anda mencoba menerapkannya ke database tanpa dukungan dalam model atau skema. Artikel ini menunjukkan teknik untuk melampirkan informasi ini dengan cara yang tidak mendistorsi bagian bisnis intrinsik model.

Fleksibilitas dan kemampuan memodifikasi Nilai dan Sensitivitas adalah tujuan utama di sini. Saat Anda mulai menerapkan nilai nyata pada atribut ini, Anda akan menemukan bahwa Anda perlu memodifikasinya dan merevisi pendekatan Anda. Itulah salah satu alasan untuk secara individual melampirkan nilai-nilai ini ke tabel itu sendiri, daripada melepaskannya. Kelemahannya adalah menjadi cukup rumit, karena banyak lokasi untuk nilai-nilai ini. Ini bahkan dapat muncul dalam bagaimana model digunakan. Kami akan membahas masalah multi-aspek dalam mengelola kompleksitas dalam keamanan informasi di artikel kami berikutnya.

Silakan tinggalkan komentar atau kritik di combox kami.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Menghubungkan Talend di Windows ke Database ODBC

  2. Grup Ketersediaan AlwaysOn:Kuorum

  3. Mengidentifikasi dan Memperbaiki Masalah Performa Catatan yang Diteruskan

  4. Pelajari Cara Membuat PK dari Pemicu Urutan di Pengembang SQL

  5. Memahami Apa yang Sebenarnya Diperbarui oleh sp_updatestats