Berapa banyak risiko keamanan yang diterbitkan skema konseptual?

Saya meminta skema konseptual dari sistem informasi lembaga pemerintah untuk penelitian saya. Permintaan saya telah ditolak dengan alasan itu merupakan risiko keamanan.

Saya tidak benar-benar memiliki pengalaman basis data yang luas sehingga saya tidak dapat memverifikasi klaim itu. Apakah mengungkapkan skema Anda benar-benar sebesar risiko keamanan? Maksud saya, itu cukup abstrak dan terpisah dari implementasi perangkat keras dan perangkat lunak. Penjelasan tentang bagaimana penyerang bisa mengeksploitasi skema konseptual akan dihargai. Terima kasih.

Setuju dengan GBN (jadi +1), tapi saya pikir ada dua kemungkinan lain yang berperan:

1. Sangat mungkin bahwa skema konseptual mereka memiliki banyak tumpang tindih dengan skema fisik mereka. Mengetahui nama tabel memberi Anda awal yang layak dalam merencanakan serangan injeksi SQL Anda.

2. Sangat mungkin mereka tidak memiliki skema konseptual yang didokumentasikan. Organisasi yang membiarkan pemrogram mendesain database mereka sendiri seringkali tidak memiliki kekakuan dalam proses desain database mereka, langsung menuju implementasi fisik tanpa desain awal. Mereka mungkin tidak mau mengakui hal ini, atau mereka mungkin tidak ingin pergi ke waktu dan kesulitan membuat kembali dokumen konseptual yang tidak pernah ada.

Sunting: OP telah berkomentar bahwa organisasi yang diminta untuk skema konseptual mereka adalah agen pemerintahan. Ini dalam benak saya menambah kemungkinan lain:

Pegawai negeri sipil tidak dikenal karena kecintaan mereka pada pengambilan risiko dan karenanya pejabat menengah di departemen pemerintah tidak mungkin untuk tidak mau keluar dan mengeluarkan informasi kalau-kalau itu bisa menarik perhatian atau kemarahan seseorang yang semakin meningkatkan hierarki. .

Saya masih berpikir bahwa # 2 adalah yang paling mungkin.

Saya menyarankan itu adalah risiko Kekayaan Intelektual tetapi mereka tidak ingin mengatakannya

Saya sepenuhnya setuju bahwa skema konseptual di balik informasi rahasia harus dirahasiakan juga.

Jika mata-mata mengumpulkan sedikit informasi rahasia yang entah bagaimana lolos dari celah, masih ada masalah dalam memasukkan informasi rahasia tersebut ke dalam konteks. Skema konseptual menyediakan konteksnya. Bentuk dan isi tidbits yang dikumpulkan mungkin sangat berbeda dari bentuk dan isi data dalam database, tetapi skema konseptual menyediakan panduan yang sangat baik untuk memecahkan kode barang.

Dalam mengerjakan pemulihan data untuk perusahaan, saya selalu menganggap skema konseptual yang dapat diandalkan sebagai tambang emas. Yang pasti, proyek-proyek ini tidak melibatkan spionase. Tetapi dapat dengan mudah melihat bagaimana analisis yang sama berjalan.

Banyak vendor mencoba untuk menjaga skema database mereka dekat dengan dada mereka. Seringkali tidak, ini tentang menjaga rahasia kecil mereka yang kotor seperti kurangnya integritas data atau desain database yang buruk. Alasan lain termasuk:

• Banyak produk perangkat lunak memiliki skema database yang dirancang dengan buruk.

• Keinginan untuk tidak memikul beban kerja dukungan.

• Upaya untuk memaksa pelanggan membeli jasa konsultasi untuk pekerjaan integrasi sistem.

• Keinginan untuk memaksimalkan biaya keluar untuk mencegah pelanggan bermigrasi ke produk pesaing.

Sayangnya Anda tidak bekerja untuk pelanggan, tetapi jika Anda adalah Anda dapat menggunakan argumen sepanjang garis menanyakan apa saja kekurangan arsitektur perangkat lunak sehingga mengekspos skema database mungkin menjadi risiko keamanan.