私は研究のために政府機関の情報システムに概念スキーマを要求していました。セキュリティリスクであるという理由で、私の要求は拒否されました。
私は実際に広範なデータベースの経験がないので、その主張を確認することはできません。スキーマを公開することは、本当に大きなセキュリティリスクですか?つまり、これらはかなり抽象的であり、ハードウェアおよびソフトウェアの実装とは離婚しています。攻撃者が概念スキーマをどのように悪用できるかについての説明をいただければ幸いです。ありがとう。
私は研究のために政府機関の情報システムに概念スキーマを要求していました。セキュリティリスクであるという理由で、私の要求は拒否されました。
私は実際に広範なデータベースの経験がないので、その主張を確認することはできません。スキーマを公開することは、本当に大きなセキュリティリスクですか?つまり、これらはかなり抽象的であり、ハードウェアおよびソフトウェアの実装とは離婚しています。攻撃者が概念スキーマをどのように悪用できるかについての説明をいただければ幸いです。ありがとう。
回答:
gbnに同意しました(+1)が、プレイには他にも2つの可能性があると思います。
それらの概念スキーマが物理スキーマと多くの重複を持っている可能性は十分にあります。テーブル名を知ることにより、SQLインジェクション攻撃の計画を立てるのに十分な出発点が得られます。
概念スキーマが文書化されていない可能性が非常に高いです。プログラマが独自のデータベースを設計できるようにする組織は、多くの場合、データベース設計プロセスに厳密さを持たず、初期設計なしで物理的な実装に直行します。彼らはこれを認めたくないかもしれないし、存在しなかった概念文書を作り直す時間とトラブルに行きたくないかもしれない。
編集: OPは、概念スキーマを求められている組織は政府機関であるとコメントしています。これは私の心に別の可能性を追加します:
公務員はリスクテイクが好きなことで知られていないため、政府部門の中レベルの機能者は、階層の上位にいる誰かの注意や怒りを引き付ける可能性がある場合に備えて、首を張って情報を公開することはほとんどありません。
私はまだ#2が最も可能性が高いと思います。
秘密情報の背後にある概念スキーマも秘密にしておく必要があることに完全に同意します。
スパイがなんらかの形で亀裂をすり抜ける小さな情報を収集する場合、それらの情報をコンテキストに入れるという問題が残っています。概念スキーマはコンテキストを提供します。収集された情報の形式と内容は、データベース内のデータの形式と内容とは大幅に異なる場合がありますが、コンセプチュアルスキーマは、内容をデコードするための優れたガイドを提供します。
企業のデータリカバリに取り組んでいるとき、私は常に信頼できる概念スキーマを金鉱だと考えていました。確かに、これらのプロジェクトにはスパイ活動は含まれていません。ただし、同じ分析がどのように引き継がれるかを簡単に確認できます。
多くのベンダーは、データベーススキーマを胸に近づけようとしています。あまり頻繁ではないが、それは、データの完全性の完全な欠如や明らかに不十分なデータベース設計のような、汚い小さな秘密を隠すことです。その他の理由は次のとおりです。
多くのソフトウェア製品は、データベーススキーマの設計が不十分です。
サポートワークロードが発生しないようにしたい。
システム統合作業のために、顧客にコンサルティングサービスの購入を強制する試み。
出口コストを最大化して、顧客が競合他社の製品に移行するのを阻止したい
残念ながら、顧客のために働いているわけではありませんが、データベーススキーマを公開することがセキュリティリスクになる可能性があるように、ソフトウェアにどのようなアーキテクチャ上の欠陥があるかを問い合わせるという議論に沿った議論を使用できます。