web-dev-qa-db-ja.com

企業は、データ自体と同じレベルでDBスキーマを保護する必要がありますか？

会社が、さまざまなユーザーにアクセスできるDBを保持している場合。会社がデータ自体を保護するためにいくら投資する必要があるか、およびDBスキーマ（テーブルとフィールド間の構造と内部関係）を保護するためにどれだけ投資する必要があるか。会社はデータ自体の保護のみに投資すべきですか？ DBスキーマの侵入に対する脅威はありますか？スキーマは価値のある意味を持っていますか、それとも将来の攻撃のためにDBの脆弱性を増加させることができますか？

privacydatabasesattack-prevention
3
Avi

@ John-Wuが正解です。データの保護よりもスキーマの保護を優先するための投資は行わないでください。

データは最も重要であり、攻撃者にとって妥協の標的となります。スキーマはせいぜい情報漏えいです。

とはいえ、データベース自体は、通常、スキーマメタデータを、理由がないわけではなく、データとは異なる、より高い特権レベルで扱います。 @ marcus-mullerが言うように、スキーマは攻撃者に役立つヒントを提供します。また、スキーマを表示する権限を持つユーザーはほとんどの場合データを表示できますが、データを表示する権限を持つユーザーはスキーマを表示できない場合があります。

したがって、スキーマは保護する必要がないと考えるべきではありません。しかし、データは最も重要です。

2
Jonah Benton

番号

データベーススキーマの保護は、 obscurityによるセキュリティ の一種です。

ソフトウェアは、ハッカーが設計を学習してもセキュリティが損なわれないように設計および構成する必要があります。実際、最良のケースでは、セキュリティの専門家が批評し、継続的に改善できるように、設計が公開されます。

5
John Wu

Security By Obscurityは悪い概念であるという@JohnWuの回答に同意しますが、1つあります。

はい。ある意味で。

複雑なデータベーススキームには通常、複雑な関係があります。しかし、簡単な例を考えましょう。

あなたはテーブルを持っています

+----+------------+-------+
| ID | CustomerNo | Order |
+----+------------+-------+
|  0 |          1 |  Nuts |
|  1 |          1 | Bolts |
|  2 |          2 |  Nuts |
|  3 |          1 |  Wire |
+----+------------+-------+

ここで、IDは自動増加する主キー、CustomerNoは顧客テーブルの主キー、Orderは注文テーブルの主キーを指します。このようにして、注文を顧客にマッピングします。

もちろん、あなたは各顧客に自分自身に「属する」行のみを表示させます。

それでも、問題が発生していますか？

正確に言うと、線形的に増加するIDフィールドを通じて、顧客1は、「通常の」顧客のように振る舞うのではなく、大量に注文するのではなく、毎分自動的に注文することによって、競争が注文を行う時期を簡単に把握できます。

そのようにして、彼らは毎週火曜日の午後4時30分に競技会が注文することを理解します。現在、ハードウェアの市場をよく理解しているため、毎週火曜日の午後4時20分に大きな売りのオプションを市場に出しているため、ナッツの市場価格が上がり、競合他社に害を及ぼし、また、決して得てはいけない知識から経済的に利益を得ています。そもそも。

これは、原則としてデータの清潔さの問題です。単調な主キーは、必要のない（部分的な）情報を提供します。したがって、お客様のAPIは、情報漏えいがゼロであることを確認する必要があります。そして、私は数学的にそれを意味します：情報には疑似単位、ビットがあり、情報理論と呼ばれる数学の分野全体があります、これは、ランダム性に基づいて特定のイベントの観測に含まれる情報の量を説明します（たとえば、そのテーブルに3人以上の顧客がいる場合、どの競合他社が午後4:30に注文したかはわかりませんが、これから確率を取得し、したがってゼロ以外の情報を取得します）。

顧客がデータベーススキームにアクセスできる場合、そのような情報を顧客から隠すことができる可能性はほとんどありません。実際、そのスキームは、おそらく彼らが得るべきではないであろう情報をあなたが彼らに与えなければ彼らを助けません。その意味では、まあ、あなたのスキームは秘密である必要はありませんが、おそらく顧客のアクセス可能なレコード内の「リレーショナル」のみと見なすデータの一部は、実際には顧客から秘密であるべきです。

1
Marcus Müller