Pendekatan Keamanan dalam Pemodelan Data. Bagian 3

Ini adalah yang ketiga dari seri multi-bagian kami tentang penerapan pendekatan keamanan informasi untuk pemodelan data. Serial ini menggunakan model data sederhana, sesuatu untuk mengelola klub sosial dan kelompok minat, untuk menyediakan konten yang kami anggap aman. Nanti kita akan membahas pemodelan untuk otorisasi dan manajemen pengguna, serta bagian lain dari implementasi database yang aman.

Dalam situasi sosial, adalah umum untuk “membaca yang tersirat” – menyimpulkan asumsi dan pernyataan yang tidak diucapkan dalam percakapan. Hal yang sama terjadi dalam membuat perangkat lunak dan menyimpan data dalam database. Faktur dihitung dengan ID pelanggan yang disematkan, dan berapa banyak entitas data yang menggunakan tanggal-waktu sebagai bagian dari kunci? Sulit membayangkan mendokumentasikan atau menyusun semuanya secara menyeluruh tanpa beberapa jenis kelalaian. Tetapi dalam angsuran terakhir kami, kami melakukan latihan itu dengan tepat. Kami dapat menganggap kepekaan terhadap beberapa bagian dari basis data klub sosial kami. Namun untuk mengukur dan mengelola sensitivitas itu, kita harus menambah struktur model data kita agar data sensitif dan hubungannya menjadi jelas.

Menutup Kesenjangan Model Data

Pemodelan data untuk keamanan memerlukan beberapa jenis perubahan struktur yang berbeda. Kami mengeksplorasi ini pada gilirannya, menggunakan model data klub sosial sederhana (sangat!) sebagai basis kami untuk seri ini. Saat kami melanjutkan, kami telah menyempurnakan model dengan lebih banyak data. Dalam angsuran terakhir, kami menganalisis model untuk menganggap sensitivitas data di tempat kami menemukannya. Analisis ini juga mengungkapkan bahwa ada tempat di mana model data menunjukkan tautan yang sebenarnya tidak ditangkap secara eksplisit dalam kolom dan hubungan kunci. Pemodel harus mengharapkan ini dalam analisis keamanan. Bergerak maju dari penemuan ini, kami akan membuat hubungan ini sekonkret dan sejelas mungkin dengan membangun tabel dan hubungan di antara mereka. Ini akan memungkinkan kami untuk melampirkan atribut keamanan lebih lanjut.

Membangun Hubungan Data di Klub

Semua hubungan dalam data, serta entitas data itu sendiri, harus memiliki beberapa representasi untuk memberikan nilai atau kepekaan terhadapnya. Kolom baru, kunci baru, referensi baru, bahkan tabel baru mungkin diperlukan untuk mencapai hal ini. Ketika kami menganalisis tabel dan hubungannya di posting terakhir kami, kami mengisolasi dua tabel utama dengan data sensitivitas tinggi:

• Person
• Photo

Selain itu, kami memiliki empat data berisi yang cukup sensitif:

• Member
• Club
• Office
• Club_Office

Aspek sensitivitas ini sebagian intrinsik untuk setiap tabel, tetapi hubungan non-eksplisit membawa banyak sensitivitas. Untuk melampirkannya, kami mulai merekam hubungan dan memberi mereka struktur untuk memuat sensitivitas.

Hubungan yang Disematkan dalam Foto

Photo berisi banyak hubungan tertanam yang perlu kita tangkap. Terutama, kami tertarik pada hubungan dengan Person . Untuk menangkap hubungan Person-Photo, saya menambahkan Photo_Content tabel:

Ada banyak aspek berbeda yang digunakan Person mungkin berhubungan dengan Photo . Saya memutuskan untuk menambahkan tabel baru, Photo_Content_Role , untuk mengkarakterisasi hubungan Foto dengan Orang. Daripada memiliki tabel terpisah untuk setiap jenis hubungan, kami menggunakan tabel penghubung tunggal dan tabel Photo_Content_Role. Tabel ini adalah daftar referensi dengan hubungan standar seperti yang telah kami catat. Berikut adalah kumpulan data awal kami untuk Photo_Content_Role :

OK, jadi ini adalah umpan-dan-switch. Saya bilang Photo_Content akan menghubungkan orang untuk foto, jadi mengapa ada sesuatu tentang "objek yang digambarkan"? Logikanya, akan ada foto yang menggambarkan konten tanpa mengidentifikasi Orang . Haruskah saya menambahkan tabel lain untuk ini, dengan serangkaian peran konten yang terpisah? Saya memutuskan tidak. Sebagai gantinya, saya akan menambahkan baris orang nol ke Person tabel sebagai data benih, dan memiliki konten non-orang yang merujuk ke orang itu. (Ya, programmer, ini sedikit lebih banyak pekerjaan. Sama-sama.) 'Orang Null' akan memiliki id nol (0).

Pembelajaran Kunci No. 1:

Minimalkan tabel dengan data sensitif dengan melapisi struktur hubungan serupa ke dalam satu tabel.

Saya mengantisipasi mungkin ada hubungan tambahan yang akan ditemukan di hilir. Dan mungkin juga klub sosial memiliki perannya sendiri untuk dianggap sebagai Orang dalam Foto . Karena alasan itu, saya telah menggunakan kunci primer pengganti 'murni' untuk Photo_Content_Role , dan juga menambahkan kunci asing opsional ke Club . Ini akan memungkinkan kami untuk mendukung penggunaan khusus oleh klub individu. Saya menyebut bidang ini 'eksklusif' untuk menunjukkan bahwa itu tidak boleh tersedia untuk klub lain.

Pembelajaran Kunci No. 2:

Saat pengguna akhir mungkin memperluas daftar bawaan, berikan tabelnya sebuah kunci pengganti murni untuk menghindari tabrakan data.

Photo_Content_Role.max_per_person mungkin juga misterius. Anda tidak dapat melihatnya di diagram, tetapi Photo_Content_Role.id membawa batasan uniknya sendiri tanpa max_per_person . Intinya, kunci utama sebenarnya hanyalah id . Dengan menambahkan max_per_person ke id di kunci utama, saya memaksa setiap tabel perujuk untuk mengambil informasi yang dengannya ia dapat (harus!) memberlakukan batasan pemeriksaan kardinalitas. Berikut adalah batasan pemeriksaan di Photo_Content .

Pembelajaran Kunci No. 3:

Bila setiap baris tabel memiliki batasan individual, tabel perujuk harus menambahkan batasan unik baru, memperluas kunci alami dengan bidang batasan. Minta tabel anak merujuk ke kunci itu.

Mari kita lihat lagi Photo_Content . Ini terutama merupakan hubungan antara Photo dan Person , dengan hubungan yang ditentukan oleh peran konten terlampir. Namun, seperti yang saya sebutkan sebelumnya, di sinilah kami menyimpan semua informasi deskriptif tentang foto. Untuk mengakomodasi keterbukaan semacam ini, kami memiliki content_headline opsional dan content_detailed kolom. Ini jarang diperlukan untuk asosiasi biasa antara Orang dan Foto. Tapi judul seperti 'Bob Januskis Menerima Penghargaan Prestasi Tahunan' mudah diantisipasi. Juga jika tidak ada Orang — 'Objek Digambarkan', Orang 0 — kita harus meminta sesuatu di content_headline , seperti ‘Lereng Barat Laut Gunung Ararat.’

Hubungan Foto Terakhir yang Hilang:Album

Sejauh ini, kami belum menambahkan apa pun yang berhubungan dengan Photo s ke Photo s. Ini adalah hal besar untuk jaringan sosial dan layanan foto:Album s. Dan Anda tidak ingin mereka di kotak sepatu pepatah, bukan? Jadi mari kita isi celah yang mencolok ini – tetapi mari kita pikirkan juga.

Album melampirkan Photo dengan cara yang berbeda dari hubungan lain yang telah kita bahas. Photo s mungkin terkait dengan klub yang sama, tanggal yang sama, koordinat GPS terdekat, fotografer yang sama, dan seterusnya. Namun, Album dengan jelas menunjukkan bahwa Photo adalah bagian dari satu topik atau cerita. Dengan demikian, aspek keamanan yang relevan dari satu Photo dapat disimpulkan dari yang lain di Album . Juga, pemesanan dapat memperkuat atau mengurangi kesimpulan tersebut. Jadi jangan hanya memikirkan Album sebagai koleksi yang tidak berbahaya. Photo s bukan apa-apa.

Meskipun tidak berbahaya dari sudut pandang keamanan, Album adalah entitas langsung dengan Id pure murni kunci pengganti yang dimiliki oleh Club (bukan Person ). Album_Photo memberi kita satu set Photo s diurutkan berdasarkan Photo_Order . Anda akan melihat bahwa saya telah membuat Album id dan order kunci utama. Hubungannya benar-benar antara Photo dan Album , jadi mengapa tidak menjadikannya sebagai kunci utama? Karena kasus ganjil membutuhkan Photo untuk mengulang dalam Album tentu saja mungkin. Jadi saya memasukkan Photo_Order ke dalam kunci utama, dan setelah beberapa pemikiran, memutuskan untuk menambahkan kunci unik alternatif dengan album dan foto untuk mencegah Photo dari pengulangan dalam Album . Jika cukup menangis karena mengulang Photo dalam Album muncul, kunci unik lebih mudah dihapus daripada kunci utama.

Pembelajaran Kunci No. 4:

Untuk kunci utama, pilih kunci kandidat dengan risiko paling kecil untuk dibuang nanti.

Metadata Foto

Informasi terakhir yang berpotensi sensitif untuk ditambahkan adalah metadata (biasanya dibuat oleh perangkat apa pun yang telah mengambil foto). Data ini bukan bagian dari suatu hubungan, tetapi itu melekat pada foto. Definisi utama informasi yang disimpan kamera dengan foto adalah EXIF, standar industri dari Jepang (JEITA). EXIF dapat diperluas dan dapat mendukung lusinan atau ratusan bidang, tidak ada yang dapat diminta dari gambar yang kami unggah. Status tidak wajib ini karena bidang ini tidak umum untuk semua format foto dan dapat dihapus sebelum diunggah. Saya telah membuat Photo dengan banyak bidang yang umum digunakan, termasuk:

• camera_mfr
• model_kamera
• versi_perangkat lunak_kamera
• resolusi_x_gambar
• resolusi_gambar_y
• unit_resolusi_gambar
• waktu_penayangan_gambar
• camera_aperture_f
• GPSLatitude
• GPSBujur
• GPSAltitude

Bidang GPS, tentu saja, adalah bidang yang menambahkan sensitivitas tertinggi ke Photo .

Model Kami, dengan Semua Data Sensitif dan Berharga yang Ditetapkan

Kami menyelesaikan fase mengamankan database klub dengan perubahan ini. Semua koneksi dan data tambahan yang diperlukan ada, seperti yang digambarkan di bawah ini. Saya telah membuat Photo informasi merah, dan Album pirus cahaya untuk menyampaikan ide saya tentang pengelompokan logis. Penambahan elemen data adalah nyata, tetapi sangat diminimalkan.

Kesimpulan

Menempatkan model data apa pun ke dalam pijakan keamanan yang baik membutuhkan penerapan prinsip-prinsip keamanan yang teratur dan sistematis serta praktik basis data relasional. Dalam angsuran ini, kami telah meninjau model data dan dengan hati-hati mengisi struktur yang hilang yang tersirat, tetapi tidak diungkapkan dalam skema. Kami tidak dapat memberikan nilai atau memberikan perlindungan untuk data yang ada tanpa menambahkan data yang mengisinya dan mengikatnya dengan benar. Dengan ini, kami akan melanjutkan untuk melampirkan elemen penilaian data dan sensitivitas data yang akan memungkinkan kami untuk melihat dengan jelas semua data dari perspektif keamanan yang lengkap. Tapi itu ada di artikel kami berikutnya.