Sicherheitsansätze in der Datenmodellierung. Teil 3

Dies ist der dritte Teil unserer mehrteiligen Serie zur Anwendung von Informationssicherheitsansätzen auf die Datenmodellierung. Die Serie verwendet ein einfaches Datenmodell, etwas zur Verwaltung von Social Clubs und Interessengruppen, um die Inhalte bereitzustellen, die wir sichern möchten. Später werden wir uns mit der Modellierung für Autorisierung und Benutzerverwaltung sowie mit anderen Teilen einer sicheren Datenbankimplementierung befassen.

In sozialen Situationen ist es üblich, „zwischen den Zeilen zu lesen“ – die unausgesprochenen Annahmen und Behauptungen in einem Gespräch abzuleiten. Das Gleiche gilt für das Erstellen von Software und das Speichern von Daten in einer Datenbank. Rechnungen werden mit eingebetteter Kunden-ID aufgezählt, und wie viele Datenentitäten verwenden Datum und Uhrzeit als Teil des Schlüssels? Es ist schwer vorstellbar, alles ohne irgendwelche Auslassungen gründlich zu dokumentieren oder zu strukturieren. Aber in unserem letzten Teil haben wir genau diese Übung gemacht. Wir konnten mehreren Teilen unserer Social Club-Datenbank Sensibilität zuschreiben. Aber um diese Sensibilität zu quantifizieren und zu verwalten, müssen wir die Struktur unseres Datenmodells erweitern, um die sensiblen Daten und ihre Beziehungen klar zu machen.

Datenmodelllücken schließen

Die Datenmodellierung für die Sicherheit erfordert mehrere unterschiedliche Arten von Strukturänderungen. Wir untersuchen diese wiederum und verwenden ein (sehr!) einfaches Datenmodell für soziale Clubs als Grundlage für diese Serie. Im weiteren Verlauf haben wir das Modell mit weiteren Daten erweitert. In der letzten Ausgabe haben wir das Modell analysiert, um Datensensitivität dort zuzuschreiben, wo wir sie gefunden haben. Diese Analyse auch zeigte, dass es Stellen gab, an denen das Datenmodell Verknüpfungen anzeigte, die nicht explizit in Spalten und Schlüsselbeziehungen erfasst wurden. Damit sollte der Modellierer bei einer Sicherheitsanalyse rechnen. Ausgehend von diesen Entdeckungen werden wir diese Beziehungen so konkret und klar wie möglich machen, indem wir die Tabellen und die Verbindungen zwischen ihnen aufbauen. Dadurch können wir später Sicherheitsattribute hinzufügen.

Ausbau der Datenbeziehungen im Club

Alle Beziehungen in den Daten sowie die Datenentitäten selbst müssen eine gewisse Repräsentation aufweisen, um ihnen einen Wert oder eine Sensibilität zuzuschreiben. Dazu sind möglicherweise neue Spalten, neue Schlüssel, neue Referenzen und sogar neue Tabellen erforderlich. Als wir die Tabellen und ihre Beziehungen in unserem letzten Post analysiert haben, haben wir zwei Haupttabellen mit hochsensiblen Daten isoliert:

• Person
• Photo

Außerdem hatten wir vier mit mäßig vertraulichen Daten:

• Member
• Club
• Office
• Club_Office

Diese Aspekte der Sensibilität sind teilweise jeder Tabelle eigen, aber nicht explizite Beziehungen tragen einen Großteil der Sensibilität bei. Um es anzuhängen, beginnen wir, die Beziehungen aufzuzeichnen und ihnen eine Struktur zu geben, um die Sensibilität einzudämmen.

In Fotos eingebettete Beziehungen

Photo enthält viele eingebettete Beziehungen, die wir erfassen müssen. Uns interessiert vor allem die Beziehung zu Person . Um die Person-Foto-Beziehung zu erfassen, füge ich den Photo_Content Tabelle:

Es gibt viele verschiedene Aspekte, anhand derer eine Person kann sich auf ein Photo . Ich habe mich entschieden, eine neue Tabelle hinzuzufügen, Photo_Content_Role , um die Beziehung eines Fotos zu einer Person zu charakterisieren. Anstatt separate Tabellen für jede Art von Beziehung zu haben, verwenden wir eine einzelne Verbindungstabelle und die Tabelle Photo_Content_Role. Diese Tabelle ist eine Referenzliste mit Standardbeziehungen, wie wir sie bereits erwähnt haben. Hier ist unser erster Datensatz für Photo_Content_Role :

OK, das ist also ein Köder und Schalter. Ich sagte Photo_Content würde Menschen in Beziehung setzen zu Fotos, warum gibt es dann etwas über „abgebildetes Objekt“? Logischerweise wird es Fotos geben, auf denen wir den Inhalt beschreiben würden, ohne eine Person zu identifizieren . Soll ich dafür eine weitere Tabelle hinzufügen, mit einem separaten Satz von Inhaltsrollen? Ich entschied mich dagegen. Stattdessen füge ich dem Person Tabelle als Seed-Daten und haben nicht personenbezogene Inhalte, die sich auf diese Person beziehen. (Ja, Programmierer, es ist ein bisschen mehr Arbeit. Gern geschehen.) Die „Null-Person“ wird id haben Null (0).

Schlüssellernen Nr. 1:

Minimieren Sie Tabellen mit sensiblen Daten, indem Sie ähnliche Beziehungsstrukturen in einer einzigen Tabelle überlagern.

Ich gehe davon aus, dass es möglicherweise zusätzliche Beziehungen gibt, die stromabwärts entdeckt werden. Und es ist auch möglich, dass ein Social Club seine eigenen Rollen hat, die er einer Person zuordnen kann in einem Foto . Aus diesem Grund habe ich einen „reinen“ Ersatz-Primärschlüssel für Photo_Content_Role , und fügte außerdem einen optionalen Fremdschlüssel zu Club . Dadurch können wir Sondernutzungen einzelner Vereine unterstützen. Ich nenne das Feld „exklusiv“, um anzuzeigen, dass es anderen Clubs nicht zur Verfügung stehen soll.

Schlüssellernen Nr. 2:

Wenn Endbenutzer eine eingebaute Liste erweitern könnten, geben Sie ihrer Tabelle einen reinen Ersatzschlüssel, um Datenkollisionen zu vermeiden.

Photo_Content_Role.max_per_person kann auch mysteriös sein. Sie können es im Diagramm nicht sehen, aber Photo_Content_Role.id trägt seine eigene eindeutige Einschränkung ohne max_per_person . Im Wesentlichen ist der echte Primärschlüssel nur id . Durch Hinzufügen von max_per_person zu id im Primärschlüssel zwinge ich jede verweisende Tabelle, Informationen aufzunehmen, mit denen sie eine Einschränkung der Kardinalitätsprüfung erzwingen kann (sollte!). Hier ist die Check-Einschränkung in Photo_Content .

Schlüssellernen Nr. 3:

Wenn jede Zeile einer Tabelle individuelle Einschränkungen hat, müssen verweisende Tabellen eine neue eindeutige Einschränkung hinzufügen, wodurch ein natürlicher Schlüssel mit den Einschränkungsfeldern erweitert wird. Lassen Sie die untergeordnete Tabelle auf diesen Schlüssel verweisen.

Sehen wir uns Photo_Content . Dies ist in erster Linie eine Beziehung zwischen Photo und Person , mit der Beziehung, die durch die angehängte Inhaltsrolle angegeben ist. Wie ich jedoch bereits erwähnt habe, speichern wir hier alle beschreibende Informationen zum Foto. Um dieser Art von Offenheit Rechnung zu tragen, haben wir die optionale content_headline und content_detailed Säulen. Diese werden selten für eine gewöhnliche Zuordnung zwischen einer Person und einem Foto benötigt. Aber eine Schlagzeile wie „Bob Januskis erhält den Annual Achievement Award“ ist leicht vorhersehbar. Auch wenn keine Person vorhanden ist – „Abgebildetes Objekt“, Person 0 — wir müssen etwas in der content_headline verlangen , wie „Nordwesthang des Berges Ararat.“

Die letzte fehlende Fotobeziehung:Alben

Bisher haben wir nichts hinzugefügt, das sich auf Photo s zu Photo s. Es ist eine große Sache für soziale Netzwerke und Fotodienste:Album s. Und im sprichwörtlichen Schuhkarton willst du sie doch nicht haben, oder? Also lasst uns diese eklatante Lücke füllen – aber lasst uns auch darüber nachdenken.

Album hängt Photo s auf eine andere Weise als die anderen Beziehungen, die wir behandelt haben. Photo s können demselben Club, einem ähnlichen Datum, nahe gelegenen GPS-Koordinaten, demselben Fotografen usw. zugeordnet werden. Jedoch Album weist deutlich darauf hin, dass das beigefügte Photo s sind Teil eines einzelnen Themas oder einer Geschichte. Als solche werden die sicherheitsrelevanten Aspekte eines Photo kann von einem anderen im Album . Außerdem kann die Reihenfolge diese Schlussfolgerungen verstärken oder verringern. Denken Sie also nicht nur an Album als harmlose Sammlung. Zugehöriges Photo s ist alles andere als.

Obwohl aus Sicherheitssicht nicht harmlos, Album ist eine einfache Entität mit einer reinen Id Ersatzschlüssel, der einem Club (keine Person ). Album_Photo gibt uns eine Reihe von Photo s geordnet nach Photo_Order . Sie werden feststellen, dass ich das Album id und order der Primärschlüssel. Die Beziehung besteht wirklich zwischen dem Photo und das Album , warum also nicht diese zum Primärschlüssel machen? Weil in Einzelfällen ein Photo in einem Album sind sicherlich möglich. Also habe ich Photo_Order in den Primärschlüssel und entschied sich nach einiger Überlegung, einen alternativen eindeutigen Schlüssel mit Album und Foto hinzuzufügen, um ein Photo von der Wiederholung in einem Album . Wenn genug Schreie für die Wiederholung eines Photo in einem Album auftreten, ist ein eindeutiger Schlüssel leichter zu entfernen als ein Primärschlüssel.

Schlüssellernen Nr. 4:

Wählen Sie für den Primärschlüssel einen Kandidatenschlüssel aus, bei dem das geringste Risiko besteht, dass er später verworfen wird.

Foto-Metadaten

Die letzten potenziell sensiblen Informationen, die hinzugefügt werden müssen, sind die Metadaten (normalerweise erstellt von dem Gerät, das die Fotos aufgenommen hat). Diese Daten sind nicht Teil einer Beziehung, aber es ist dem Foto innewohnend. Die primäre Definition von Informationen, die eine Kamera zusammen mit einem Foto speichert, ist EXIF, ein Industriestandard aus Japan (JEITA). EXIF ist erweiterbar und kann Dutzende oder Hunderte von Feldern unterstützen, von denen keines von unseren hochgeladenen Bildern verlangt werden kann. Dieser nicht erforderliche Status liegt daran, dass diese Felder nicht allen Fotoformaten gemeinsam sind und vor dem Hochladen gelöscht werden können. Ich habe Photo mit vielen häufig verwendeten Feldern, darunter:

• camera_mfr
• camera_model
• camera_software_version
• Bild_x_Auflösung
• Bild_y_Auflösung
• Bildauflösungseinheit
• Bildbelichtungszeit
• camera_aperture_f
• GPSLatitude
• GPSLängengrad
• GPSHöhe

Die GPS-Felder sind natürlich diejenigen, die einem Photo .

Unser Modell, bei dem alle sensiblen und wertvollen Daten definiert sind

Mit diesen Änderungen schließen wir diese Phase der Sicherung der Vereinsdatenbank ab. Alle Verbindungen und die erforderlichen zusätzlichen Daten sind vorhanden, wie unten dargestellt. Ich habe Photo Informationen rot und Album helltürkis, um meine Vorstellung von logischen Gruppierungen zu vermitteln. Die Anreicherung von Datenelementen ist real, aber sehr stark minimiert.

Schlussfolgerung

Um ein Datenmodell auf eine gute Sicherheitsbasis zu stellen, ist eine geordnete und systematische Anwendung von Sicherheitsprinzipien sowie der Praxis relationaler Datenbanken erforderlich. In dieser Ausgabe haben wir das Datenmodell überprüft und die fehlende Struktur, die impliziert, aber nicht im Schema ausgedrückt wurde, sorgfältig ausgefüllt. Wir könnten den vorhandenen Daten keinen Wert zuweisen oder sie schützen, ohne die Daten hinzuzufügen, die sie ausfüllen und korrekt miteinander verknüpfen. Wenn dies vorhanden ist, werden wir fortfahren, die Elemente der Datenbewertung und Datensensibilität hinzuzufügen, die es uns ermöglichen, alle Daten aus einer vollständigen Sicherheitsperspektive klar zu sehen. Aber das ist in unserem nächsten Artikel.