これは、情報セキュリティとデータ特性のためのデータモデリングに関するマルチパートシリーズの第4回です。共通の関心を持つ組織（バードウォッチングクラブなど）をサポートする架空のWebサイトの単純なデータモデルは、セキュリティの観点からデータモデリングを調査するためのコンテンツを提供してくれました。
オスカーワイルドの演劇でウィンダミア卿夫人のファン 、ダーリントン卿は皮肉屋を「すべての価格と何の価値も知らない誰か」とタグ付けしています。悲しいことに、私たちのデータベースの情報は無意識のうちに同じように扱われる可能性があります。顧客アカウントは購入総額に見合う価値がありますか？ホリデーショッピングシーズン中に4時間のマーケティングデータを失った場合、どのような影響がありますか？
私たちのデータモデラーはこれらの評価を行いませんが、そうする人々に代わって関連データを保存する必要があります。暗黙のデータ構造のギャップを埋める必要があります。この記事では、この重要なセキュリティ要素をデータベースに追加する方法を説明します。
お金を見せて！
各データオブジェクトをどの程度保護する必要がありますか？ 守秘義務に照らして検討してください 、整合性 、および可用性 —情報システムのセキュリティを決定する重要な品質。また、これらの対策の「本質的な」基準と、このデータがセキュリティにどの程度影響を与える可能性があるかとの違いを考慮に入れる必要があります。
これを行う理由は2つあります。まず、クラブデータベースのデータを保護する方法を理解するのに役立ちます。一部のテーブルは暗号化する必要がありますか？他のスキーマを入れますか？おそらくダウンストリームで、仮想プライベートデータベースコントロールをアタッチしますか？この情報は、適切な保護手段を選択するのに役立ちます。
次に、生の会計の観点からデータを検討します。その合計値はどれくらいですか。データが破損した場合、何を失う可能性がありますか？個人データが開示された場合の当社の責任は何ですか？この情報をスキーマに追加すると、保存されているデータに重要な指標であるドルとセントが追加されます。これにより、請求書を支払う人々は、セキュリティのために何を支払うことができるか、そして金銭的にはそれがどれだけの価値があるかを判断できます。
すべての関係が綴られている
モデルの状態を要約してみましょう。前回の記事の時点で、データ構造が入力されています。個人、クラブ、メンバーシップ、写真、アルバム、コンテンツがすべて揃っています。彼らがどのように結びつくかはそこにあります。このスキーマは、暗黙の関係が可能な限り排除されている一方で、関係全体で明示的にキャプチャされたデータを格納する準備ができています。
価値と感度の帰属
次に、データに数値を付ける方法を理解します。 シングルを添付することはできません 保護する量を示すデータ項目の価値。ただし、メトリックのコレクションに入ることができず、またその必要もありません。 データの一部が私たちにどれだけの利益をもたらすか、そしてそのデータを失うか開示することでどれだけの費用がかかるかに焦点を当てます。
これには「値」と「感度」という用語を使用します。必要に応じて、正と負の測定値を使用します。多くの場合、価値は将来の価値または機会の観点から考慮されます。感度は非常に防御的です。これは、財務レベルのリスク（規制または法的罰則）および評判や信用の喪失に関連しています。
評価は完全性に直接関係します および可用性 。これは、データがどのようなメリットをもたらすか、またはデータへのアクセスが失われた場合にどの程度の損害が発生するかという観点から判断します。機密性については、主に機密保持の観点から取り上げます。 、それが明らかになった場合、損害または責任によって測定されなければなりません。
評価と感度の一般的な構造
次に、データベースに対する評価と感度について考えてみましょう。データモデルをもう一度見ると、これらの品質はクラブまたは個人にのみ関連していることがわかります。クラブや人は何かの価値から恩恵を受け、敏感なものが公表されると彼らは苦しみます。したがって、これらの評価のそれぞれは、クラブまたは個人に関して取得されます。データエンティティを見るとき、値（利益）を持つ各エンティティが感度（リスク）も持っていることを確認します。その逆も同様です。したがって、関係する各エンティティには、個別の評価フィールドと感度フィールドの両方があります。ほとんどの場合、これらはオプションまたはデフォルトになります。また、両方ともお金の観点から評価されます。つまり、100分の1米ドルに正確な通貨価値です。 （わかりやすくするために、1つの通貨のみを使用します。）それを祝うか、嘆くか、どちらにも使用できる唯一の指標はお金です。この共通性を活用するために、これらを「重要性」と呼びます。
データモデラーとして、私たちは実際にこれに数字を付けることはできません。サイトまたはデータベースのオペレーターとしても、これらの値を割り当てるのに十分な知識はありません。その上、データは完全に私たちのものではありません。クラブに固有のデータについては、そのクラブに独自のを割り当てさせる必要があります。 重要度レベルとそれらのレベルを使用するためのルール。次に、ルールをデータに適用します。
クラブが割り当てることができるエンティティの種類から始めましょう。
クラブデータ
クラブの実体は次のとおりです。
- クラブ
- Club_Office
- 役員
- メンバー
- アルバム
- Album_Photo
- 写真
Valuationを追加します およびSensitivity これらのそれぞれへの列。これらの列はクラブに接続されているためです 、それらの名前は特定のものです–例： club_sensitivity 。
クラブのフォーカステーブルのセットは次のとおりです 、人を含む ：
個人データ
次に、Personに対処する必要があります 実在物。ここでも、値を割り当てません。これは、その人の特権です。当然、重要度の列を人に追加する必要があります 。ただし、個人のプライバシーをより適切にサポートするために、このエンティティをより細かくスライスします。結局のところ、プライバシーはデータの機密性の鍵です。
まず、monickerという新しい列を追加します これは、ユーザー名やエイリアスのようなものです。クラブ会員は、実際の名前ではなく、それを識別に使用できます。名前とモニカーの関連付けの評価/感度の列のペアを提供します。これらはperson_name_valuationになります およびperson_name_sensitivity 。残りのフィールドは、これら2つのペアによって制御されます。
人 のクラブ活動は、クラブと同じくらい彼らの関心事です。 の。したがって、同じ重要度フィールドをメンバーに追加します および役員 。
これで、person_importanceを追加できます 写真へのフィールド エンティティですが、 photo_contentを見てください 桁。写真には複数の人物が写っている可能性があり、これはphoto_contentに保存されているものの一部です。 したがって、重要度フィールドをphoto_content。に配置します。 写真の代わりに。
「Sensitized」モデル
データモデルを変更して、必要なすべての場所でデータ値とデータ感度を評価しました。以下が最終的なスキーマです。
追加の関係や制約によって元のスキーマが歪まないように注意しました。このスキーマは、実際のビジネスルールを使用した実際のデータの正確な分析と見なしているため、これは非常に重要です。
データに固有の重要性を付加することは困難です。モデルまたはスキーマでサポートされていないデータベースに適用しようとすると、さらに悪化します。この記事では、モデルの本質的なビジネス部分を歪めない方法でこの情報を添付する手法を示します。
Valueの柔軟性と変更可能性 および感度 ここでの重要な目標です。これらの属性に実際の値を適用し始めると、それらを変更してアプローチを修正する必要があることがわかります。これが、これらの値をオフボードにするのではなく、テーブル自体に個別にアタッチする理由の1つです。欠点は、これらの値の場所が多いため、非常に複雑になることです。これは、モデルがどのように使用されているかにも表れます。次の記事では、情報セキュリティの複雑さを管理するという多面的な問題を取り上げます。
私たちのcomboxにコメントや批評を残してください。