データモデリングにおけるセキュリティアプローチ。パート3

これは、データモデリングへの情報セキュリティアプローチの適用に関するマルチパートシリーズの第3回です。このシリーズでは、社交クラブや分科会を管理するためのシンプルなデータモデルを使用して、保護したいコンテンツを提供しています。後で、承認とユーザー管理のモデリング、および安全なデータベース実装の他の部分について説明します。

社会的な状況では、「行間を読む」のが一般的です。つまり、会話の中で口に出さない仮定や主張を推測します。ソフトウェアの作成やデータベースへのデータの保存でも同じことが起こります。請求書は顧客IDが埋め込まれた状態で列挙され、キーの一部として日時を使用するデータエンティティはいくつありますか？なんらかの省略なしにすべてを完全に文書化または構造化することを想像するのは難しいです。しかし、最後のインストールでは、まさにその演習を行いました。私たちは、社交クラブのデータベースのいくつかの部分に感度を帰することができました。ただし、その機密性を定量化して管理するには、機密データとその関係を明確にするために、データモデルの構造を強化する必要があります。

データモデルのギャップを埋める

セキュリティのためのデータモデリングでは、いくつかの異なる種類の構造変更が必要です。このシリーズのベースとして（非常に！）単純な社交クラブのデータモデルを使用して、これらを順番に調査しています。先に進むにつれて、より多くのデータでモデルを拡張しました。最後のインストールでは、モデルを分析して、データの機密性を見つけた場所に帰属させました。この分析も データモデルが、列とキーの関係で実際に明示的にキャプチャされていないリンクを示している場所があることを明らかにしました。モデラーは、セキュリティ分析でこれを期待する必要があります。これらの発見から前進し、テーブルとそれらの間の接続を構築することにより、これらの関係を可能な限り具体的かつ明確にします。これにより、セキュリティ属性をさらに追加できるようになります。

クラブでのデータ関係の構築

データ内のすべての関係、およびデータエンティティ自体は、それらに価値または感度を与えるために、何らかの表現を持っている必要があります。これを実現するには、新しい列、新しいキー、新しい参照、さらには新しいテーブルが必要になる場合があります。前回の投稿でテーブルとそれらの関係を分析したとき、高感度データを使用して2つのメインテーブルを分離しました。

• Person
• Photo

さらに、適度に機密性の高い4つのデータが含まれていました：

• Member
• Club
• Office
• Club_Office

感度のこれらの側面は、各テーブルに部分的に固有ですが、非明示的な関係には多くの感度があります。添付するために、関係の記録を開始し、感度を含む構造を提供します。

写真に埋め込まれた関係

Photo キャプチャする必要のある埋め込み関係がたくさん含まれています。主に、Person 。人と写真の関係をキャプチャするために、Photo_Content テーブル：

Person Photo 。新しいテーブルPhoto_Content_Role 、写真と人物の関係を特徴づける。関係の種類ごとに個別のテーブルを用意するのではなく、単一の接続テーブルとPhoto_Content_Roleテーブルを使用します。この表は、すでに述べたような標準的な関係を持つ参照リストです。 Photo_Content_Role ：

OK、これはおとり商法です。 Photo_Content 人を関連付ける 写真に、なぜ「描かれたオブジェクト」について何かがあるのですか？論理的には、人物を特定せずにコンテンツを説明する写真があります 。このために別のテーブルを追加する必要があります、 別のコンテンツロールのセットを使用しますか？私はしませんでした。代わりに、nullの人物行をPerson シードデータとしてテーブルを作成し、個人以外のコンテンツでその個人を参照します。 （はい、プログラマー、もう少し作業が必要です。どういたしまして。）「nullPerson」にはidがあります。 ゼロ（0）。

キーラーニングNo.1：

同様の関係構造を単一のテーブルにオーバーレイすることにより、機密データを含むテーブルを最小限に抑えます。

下流で発見される追加の関係があるかもしれないと私は予想します。また、社交クラブが人に帰属する独自の役割を持っている可能性もあります。 写真 。そのため、Photo_Content_Role 、およびオプションの外部キーをClub 。これにより、個々のクラブによる特別な使用をサポートできるようになります。このフィールドを「排他的」と呼んで、他のクラブが利用できないようにする必要があることを示します。

キーラーニング2：

エンドユーザーが組み込みリストを拡張する可能性がある場合は、データの衝突を避けるために、テーブルに純粋な代理キーを指定してください。

Photo_Content_Role.max_per_person 不思議かもしれません。図には表示されていませんが、Photo_Content_Role.id なしで独自の制約を実行します max_per_person 。本質的に、実際の主キーはidです。 。 max_per_personを追加する idへ 主キーでは、各参照テーブルに、カーディナリティチェック制約を適用できる（すべきである！）情報を取り込むように強制します。 Photo_Content 。

キーラーニング3：

テーブルの各行に個別の制限がある場合、参照するテーブルは、制約フィールドで自然キーを拡張して、新しい一意の制約を追加する必要があります。子テーブルにそのキーを参照させます。

Photo_Content 。これは主にPhoto およびPerson 、添付のコンテンツロールによって指定された関係を使用します。ただし、前に述べたように、ここにすべてを保存します 写真に関する説明情報。この種の制限に対応するために、オプションのcontent_headlineがあります。 およびcontent_detailed 列。これらは、人物と写真の間の通常の関連付けに必要になることはめったにありません。しかし、「BobJanuskisがAnnualAchievementAwardを受賞」のような見出しは簡単に予想できます。また、人物がいない場合—「描写されたオブジェクト」、人物 0 — content_headlineに何かが必要です 、「アララト山のノースウェストスロープ」など。

最後に欠けている写真の関係：アルバム

これまでのところ、Photo sからPhoto s。ソーシャルネットワークや写真サービスにとって重要なことです。Album s。そして、あなたはそれらをことわざの靴箱に入れたくないでしょう？それでは、この明白なギャップを埋めましょう。しかし、それについても考えてみましょう。

Album Photo s私たちがカバーした他の関係とは異なる方法で。 Photo sは、同じクラブ、同じ日付、近くのGPS座標、同じ写真家などによって関連付けられている場合があります。ただし、Album 同封のPhoto は、単一のトピックまたはストーリーの一部です。そのため、1つのPhoto Album 。また、順序付けにより、これらの推論が増幅または減少する場合があります。したがって、Album 無害なコレクションとして。 Photo sは何でもありません。

セキュリティの観点からは無害ではありませんが、Album は 純粋なIdを持つ単純なエンティティ Club （Person ）。 Album_Photo Photo s Photo_Order 。 Album id およびorder 主キー。関係は実際にはPhoto およびAlbum 、では、なぜそれらを主キーにしないのですか？ Photo Album 確かに可能です。だから私はPhoto_Order 主キーに挿入し、少し考えた後、Photo Album 。 Photo Album 発生した場合、一意のキーは主キーよりも簡単に削除できます。

キーラーニング4：

主キーには、後で破棄されるリスクが最も少ない候補キーを選択します。

写真のメタデータ

追加する可能性のある最後の機密情報はメタデータです（通常、写真を撮ったデバイスによって作成されます）。このデータはではありません 関係の一部ですが、それは写真に固有のものです。カメラが写真とともに保存する情報の主な定義は、日本（JEITA）の業界標準であるEXIFです。 EXIFは拡張可能であり、数十または数百のフィールドをサポートできますが、アップロードされた画像からは必要ありません。この必須ではないステータスは、これらのフィールドがすべての写真形式に共通であるとは限らず、アップロードする前に消去できるためです。 Photo 次のような多くの一般的に使用されるフィールドがあります：

• camera_mfr
• camera_model
• camera_software_version
• image_x_resolution
• image_y_resolution
• image_resolution_unit
• image_exposure_time
• camera_aperture_f
• GPSLatitude
• GPSLongitude
• GPSAltitude

GPSフィールドは、当然のことながら、Photo 。

すべての機密性の高い貴重なデータが定義されたモデル

これらの変更により、クラブデータベースを保護するこのフェーズを完了します。以下に示すように、必要なすべての接続と追加データが存在します。 Photo 情報は赤、Album 論理的なグループ化の私の考えを伝えるために明るいターコイズ。データ要素の拡張は実際のものですが、非常に最小限に抑えられています。

結論

データモデルを適切なセキュリティ基盤に置くには、セキュリティ原則の整然とした体系的な適用と、リレーショナルデータベースの実践が必要です。このインストールでは、データモデルを確認し、暗黙的に示されているがスキーマで表現されていない欠落している構造を注意深く埋めました。データを埋めて正しく結び付けるデータを追加せずに、既存のデータに価値を割り当てたり、保護を提供したりすることはできませんでした。これが整ったら、完全なセキュリティの観点からすべてのデータを明確に確認できるようにするデータ評価とデータ機密性の要素を添付します。しかし、それは次の記事にあります。