Übersicht über das einheitliche Datenmodell

Unterstützt in:

Google SecOps SIEM

Dieses Dokument bietet einen Überblick über das Unified Data Model (UDM). Weitere Informationen zu UDM-Feldern, einschließlich einer Beschreibung der einzelnen Felder, finden Sie in der Liste der UDM-Felder. Weitere Informationen zur Parserzuordnung finden Sie unter Wichtige UDM-Felder für die Parserzuordnung.

Das UDM ist eine Standarddatenstruktur von Google Security Operations, in der Informationen zu Daten gespeichert werden, die von Quellen empfangen wurden. Es wird auch als Schema bezeichnet. Google Security Operations speichert die empfangenen Originaldaten in zwei Formaten: als ursprüngliches Rohprotokoll und als strukturierten UDM-Eintrag. Der UDM-Eintrag ist eine strukturierte Darstellung des ursprünglichen Logs.

Wenn für den angegebenen Logtyp ein Parser vorhanden ist, wird anhand des Rohlogs ein UDM-Eintrag erstellt. Kunden können Rohprotokolle auch in ein strukturiertes UDM-Format umwandeln, bevor sie die Daten über die Ingestion API an Google Security Operations senden.

Zu den Vorteilen von UDM gehören:

• Speichert denselben Datensatztyp von verschiedenen Anbietern mit derselben Semantik.
• Es ist einfacher, Beziehungen zwischen Nutzern, Hosts und IP-Adressen zu identifizieren, da die Daten in das standardmäßige UDM-Schema normalisiert werden.
• Es ist einfacher, Regeln zu schreiben, da sie plattformunabhängig sein können.
• Die Unterstützung von Protokolltypen von neuen Geräten ist einfacher.

Hinweis: Die Google Security Operations-Regeln-Engine verwendet dieselben UDM-Feldnamen. Sie können diese Feldnamen auch beim Erstellen von Regeln verwenden.

Sie können zwar auch mit einer Suche in Rohlogs nach Ereignissen suchen, aber eine UDM-Suche ist aufgrund ihrer Spezifität schneller und genauer.

Google Security Operations verwendet das UDM-Schema für alle erfassten Ereignisse. UDM enthält Tausende von Feldern, mit denen Ereignisse beschrieben und kategorisiert werden. So kann UDM beispielsweise Endpunktprozess-Ereignisse genauso einfach verarbeiten wie Netzwerkkommunikationsereignisse.

UDM-Struktur

UDM-Ereignisse bestehen aus mehreren Abschnitten. Der erste Abschnitt in jedem UDM-Ereignis ist der Metadatenabschnitt. Sie enthält eine grundlegende Beschreibung des Ereignisses, einschließlich des Zeitstempels, zu dem es eingetreten ist, und des Zeitstempels, zu dem es in Google Security Operations aufgenommen wurde. Außerdem enthält sie die Produktinformationen, die Version und die Beschreibung. Der Datenaufnahme-Parser klassifiziert jedes Ereignis unabhängig vom jeweiligen Produktprotokoll anhand eines vordefinierten Ereignistyps. Mit den Metadatenfeldern allein können Sie schnell in den Daten suchen.

Neben dem Metadatenabschnitt werden in anderen Abschnitten weitere Aspekte des Ereignisses beschrieben. Wenn ein Abschnitt nicht erforderlich ist, wird er nicht berücksichtigt, was Speicherplatz spart.

• principal: Entität, von der die Aktivität im Ereignis ausgeht. Abschnitte, die auf die Quelle (src) und das Ziel (target) verweisen, sind ebenfalls enthalten.
• intermediary: Systeme, durch die Ereignisse geleitet werden, z. B. ein Proxyserver oder ein SMTP-Relay.
• observer: Systeme wie Paketsniffer, die den Traffic passiv überwachen.

Beispiele für UDM-Suchanfragen

In diesem Abschnitt finden Sie Beispiele für UDM-Suchanfragen, die einige der grundlegenden Syntax, Funktionen und Möglichkeiten der UDM-Suche veranschaulichen.

Beispiel: Suche nach erfolgreichen Microsoft Windows-Anmeldungen vom Typ 4624

In der folgenden Suche werden die erfolgreichen Anmelde-Ereignisse von Microsoft Windows 4624 zusammen mit dem Zeitpunkt der Generierung der Ereignisse basierend auf nur zwei UDM-Feldern aufgeführt:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Beispiel: Nach allen erfolgreichen Anmeldungen suchen

Die folgende Suche listet alle erfolgreichen Anmeldevorgänge auf, unabhängig von Anbieter oder Anwendung:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Beispiel: Nach erfolgreichen Nutzeranmeldungen suchen

Im folgenden Beispiel wird gezeigt, wie Sie nach userid "fkolzig" suchen und ermitteln, wann sich der Nutzer mit dieser Nutzer-ID erfolgreich angemeldet hat. Sie können diese Suche über den Bereich „Ziel“ durchführen. Der Bereich „Ziel“ enthält Unterabschnitte und Felder, in denen das Ziel beschrieben wird. In diesem Fall ist das Ziel beispielsweise ein Nutzer mit einer Reihe von zugehörigen Attributen. Das Ziel kann aber auch eine Datei, eine Registrierungseinstellung oder ein Asset sein. In diesem Beispiel wird mithilfe des Felds target.user.userid nach "fkolzig" gesucht.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Beispiel: In Netzwerkdaten suchen

Im folgenden Beispiel werden Netzwerkdaten nach RDP-Ereignissen mit einer target.port von 3389 und einer principal.ip von 35.235.240.5 gesucht. Außerdem enthält es ein UDM-Feld aus dem Netzwerkabschnitt, die Datenübertragungsrichtung (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Beispiel: Nach einem bestimmten Prozess suchen

Wenn Sie die auf Ihren Servern erstellten Prozesse untersuchen möchten, suchen Sie nach Instanzen des Befehls net.exe und nach dieser bestimmten Datei im erwarteten Pfad. Das Feld, nach dem Sie suchen, ist target.process.file.full_path. Geben Sie dazu den Befehl, der ausgeführt werden soll, in das Feld target.process.command_line ein. Sie können auch ein Feld im Abschnitt „Info“ hinzufügen, das die Beschreibung des Microsoft Sysmon-Ereigniscodes 1 (ProcessCreate) enthält.

Hier ist die UDM-Suche:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Optional können Sie die folgenden UDM-Suchfelder hinzufügen:

• principal.user.userid: Identifizieren Sie den Nutzer, der den Befehl ausführt.
• principal.process.file.md5: MD5-Hash ermitteln
• principal.process.command_line: Befehlszeile.

Beispiel: Suche nach erfolgreichen Nutzeranmeldungen, die mit einer bestimmten Abteilung verknüpft sind

Im folgenden Beispiel wird nach Anmeldungen von Nutzern (metadata.event_type ist USER_LOGIN) gesucht, die der Marketingabteilung (target.user.department ist marketing) Ihres Unternehmens zugewiesen sind. Obwohl target.user.department nicht direkt mit Nutzeranmeldeereignissen verknüpft ist, ist es in den LDAP-Daten zu Ihren Nutzern enthalten.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Logische Objekte: Ereignis und Entität

Das UDM-Schema beschreibt alle verfügbaren Attribute, in denen Daten gespeichert werden. In jedem UDM-Eintrag wird angegeben, ob es sich um ein Ereignis oder eine Entität handelt. Daten werden in verschiedenen Feldern gespeichert, je nachdem, ob der Datensatz ein Ereignis oder eine Entität beschreibt und welcher Wert im Feld „metadata.event_type“ oder „metadata.entity_type“ festgelegt ist.

• UDM-Ereignis: Hier werden Daten für eine Aktion gespeichert, die in der Umgebung stattgefunden hat. Das ursprüngliche Ereignisprotokoll beschreibt die Aktion so, wie sie vom Gerät aufgezeichnet wurde, z. B. Firewall und Webproxy. Das ist das UDM-Ereignisdatenmodell.
• UDM-Entität: Kontextbezogene Darstellung von Elementen wie Assets, Nutzern und Ressourcen in Ihrer Umgebung. Sie stammen aus einer Wahrheitsquelle. Das ist das UDM-Entitätsdatenmodell.

Hier sind zwei visuelle Darstellungen des Ereignisdatenmodells und des Entitätsdatenmodells.

Abbildung: Ereignisdatenmodell

Hinweis: Der Begriff „Noun“ (Substantiv) beschreibt den Attributtyp. Die Begriffe „principal“, „target“, „src“, „intermediary“, „observer“ und „about“ sind die Feldnamen, in denen Daten gespeichert werden.

Abbildung: Entitätsdatenmodell

Hinweis: Der Begriff „Noun“ (Substantiv) beschreibt den Attributtyp. Die Begriffe „Asset“, „Nutzer“ und „Ressource“ sind die Feldnamen, in denen Daten gespeichert werden.

Struktur eines UDM-Ereignisses

Das UDM-Ereignis enthält mehrere Abschnitte, in denen jeweils ein Teil der Daten für einen einzelnen Datensatz gespeichert wird. Die Abschnitte sind:

• Metadaten
• Hauptkonto
• target
• src
• Beobachter
• Vermittler
• über
• network
• security_result

• extensions

  

  Abbildung: Ereignisdatenmodell

Im Abschnitt metadata werden der Zeitstempel gespeichert, die event_type definiert und das Gerät beschrieben.

In den Abschnitten principal, target, src, observer und intermediary werden Informationen zu den am Ereignis beteiligten Objekten gespeichert. Ein Objekt kann ein Gerät, ein Nutzer oder ein Prozess sein. In den meisten Fällen wird nur ein Teil dieser Abschnitte verwendet. Die Felder, in denen Daten gespeichert werden, richten sich nach dem Ereignistyp und der Rolle, die jedes Objekt im Ereignis spielt.

Im Bereich Netzwerk werden Informationen zu Netzwerkaktivitäten gespeichert, z. B. E-Mails und Netzwerkkommunikation.

• E-Mail-Daten: Informationen in den Feldern to, from, cc, bcc und anderen E-Mail-Feldern.
• HTTP-Daten: z. B. method, referral_url und useragent

Im Abschnitt security_result wird eine Aktion oder Klassifizierung gespeichert, die von einem Sicherheitsprodukt wie einem Antivirenprogramm erfasst wurde.

In den Abschnitten about und extensions werden zusätzliche anbieterspezifische Ereignisinformationen gespeichert, die in den anderen Abschnitten nicht erfasst werden. Der Abschnitt Erweiterungen enthält eine Reihe von Schlüssel/Wert-Paaren im freien Format.

In jedem UDM-Ereignis werden Werte aus einem ursprünglichen Rohprotokollereignis gespeichert. Je nach Ereignistyp sind bestimmte Attribute erforderlich, andere sind optional. Ob ein Attribut erforderlich oder optional ist, wird durch den Wert von „metadata.event_type“ bestimmt. Das Google Security Operations-Team liest „metadata.event_type“ und führt nach Erhalt der Protokolle eine feldspezifische Validierung für diesen Ereignistyp durch.

Wenn in einem Abschnitt des UDM-Eintrags keine Daten gespeichert sind, z. B. im Abschnitt „Erweiterungen“, wird dieser Abschnitt nicht im UDM-Eintrag angezeigt.

Metadatenfelder

In diesem Abschnitt werden die Felder beschrieben, die in einem UDM-Ereignis erforderlich sind.

Das Feld „event_timestamp“

UDM-Ereignisse müssen Daten für das metadata.event_timestamp enthalten, also den GMT-Zeitstempel des Ereignisses. Der Wert muss mit einem der folgenden Standards codiert sein: RFC 3339 oder Proto3-Zeitstempel.

In den folgenden Beispielen wird gezeigt, wie der Zeitstempel im RFC 3339-Format yyyy-mm-ddThh:mm:ss+hh:mm (Jahr, Monat, Tag, Stunde, Minute, Sekunde und der Offset von der UTC-Zeit) angegeben wird. Der Zeitversatz zu UTC beträgt minus 8 Stunden, was auf die Pacific Standard Time (PST) hinweist.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Sie können den Wert auch im Epochenformat angeben.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

Das Feld „event_type“

Das wichtigste Feld im UDM-Ereignis ist metadata.event_type. Dieser Wert gibt die Art der ausgeführten Aktion an und ist unabhängig von Anbieter, Produkt oder Plattform. Beispiele sind PROCESS_OPEN, FILE_CREATION, USER_CREATION und NETWORK_DNS. Eine vollständige Liste finden Sie im Dokument Liste der UDM-Felder.

Der Wert metadata.event_type bestimmt, welche zusätzlichen Pflicht- und optionalen Felder im UDM-Eintrag enthalten sein müssen. Informationen dazu, welche Felder für jeden Ereignistyp eingeschlossen werden sollten, finden Sie im Leitfaden zur Verwendung von UDM.

Die Attribute „principal“, „target“, „src“, „intermediary“, „observer“ und „about“

Die Attribute principal, target, src, intermediary und observer beschreiben Assets, die am Ereignis beteiligt sind. In jedem werden Informationen zu Objekten gespeichert, die an der Aktivität beteiligt sind, wie im ursprünglichen Rohprotokoll aufgezeichnet. Das kann das Gerät oder der Nutzer sein, der die Aktivität ausgeführt hat, oder das Gerät oder der Nutzer, das bzw. der das Ziel der Aktivität ist. Es kann sich auch um ein Sicherheitsgerät handeln, das die Aktivität beobachtet hat, z. B. einen E-Mail-Proxy oder einen Netzwerkrouter.

Die am häufigsten verwendeten Attribute sind:

• principal: Das Objekt, das die Aktivität ausgeführt hat.
• src: Das Objekt, das die Aktivität initiiert, sofern es sich von dem Hauptkonto unterscheidet.
• target: Objekt, auf das eine Aktion angewendet wird.

Für jeden Ereignistyp muss mindestens eines dieser Felder Daten enthalten.

Die Hilfsfelder sind:

• intermediary: Jedes Objekt, das beim Ereignis als Vermittler fungierte. Dazu können Objekte wie Proxy- und Mailserver gehören.
• observer: Alle Objekte, die nicht direkt mit dem betreffenden Traffic interagieren. Das kann ein Scanner für Sicherheitslücken oder ein Paketsniffer sein.
• about: Alle anderen Objekte, die eine Rolle bei dem Ereignis gespielt haben. Optional.

Die Hauptattribute

Stellt die handelnde Entität oder das Gerät dar, von dem die Aktivität ausgeht. Der Hauptbenutzer muss mindestens ein Maschinendetail (Hostname, MAC-Adresse, IP-Adresse, produktspezifische Kennungen wie eine CrowdStrike-Maschinen-GUID) oder Nutzerdetail (z. B. Nutzername) und optional Prozessdetails enthalten. Es darf keine der folgenden Felder enthalten: E-Mail-Adressen, Dateien, Registry-Schlüssel oder ‑Werte.

Wenn das Ereignis auf einem einzelnen Computer stattfindet, wird dieser Computer nur im Attribut „principal“ beschrieben. Der Computer muss nicht in den Attributen „target“ oder „src“ beschrieben werden.

Hinweis :Ein Sicherheitsgerät kann ein Ereignis aufzeichnen, das aber nicht im Hauptattribut beschrieben wird. Sie wird entweder im Attribut „Beobachter“ oder „Vermittlung“ beschrieben. Wenn die Sicherheitssoftware (z. B. Carbon Black) auf demselben Gerät ausgeführt wird, auf dem die Aktivität ihren Ursprung hat (z. B. ein Windows-Endpunkt, auf dem Malware erkannt wurde), ist das Windows-Gerät das Hauptkonto.

Das folgende JSON-Snippet veranschaulicht, wie das Attribut principal ausgefüllt werden könnte.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

Dieses Attribut beschreibt alles, was über das Gerät und den Nutzer bekannt ist, der der Hauptakteur des Ereignisses war. Dieses Beispiel enthält die IP-Adresse, die Portnummer und den Hostnamen des Geräts. Außerdem enthält sie eine anbieterspezifische Asset-ID von Sophos, eine eindeutige Kennung, die vom Sicherheitsprodukt des Drittanbieters generiert wird.

Die Zielattribute

Stellt ein Zielgerät dar, auf das im Ereignis verwiesen wird, oder ein Objekt auf dem Zielgerät. In einer Firewallverbindung von Gerät A zu Gerät B wird beispielsweise Gerät A als Haupt- und Gerät B als Ziel erfasst.

Bei einer Prozessinjektion durch Prozess C in den Zielprozess D ist Prozess C der Hauptprozess und Prozess D das Ziel.

Abbildung: Haupt- und Zielelement

Das folgende Beispiel zeigt, wie das Zielfeld ausgefüllt werden könnte.

target {
   ip: "192.0.2.31"
   port: 80
}

Wenn im ursprünglichen Rohprotokoll weitere Informationen verfügbar sind, z. B. Hostname, zusätzliche IP-Adressen, MAC-Adressen und proprietäre Asset-IDs, sollten diese auch in den Ziel- und Hauptfeldern enthalten sein.

Sowohl der Haupt- als auch der Zielknoten können Akteure auf demselben Computer darstellen. Beispielsweise könnte Prozess A (Principal), der auf Computer X ausgeführt wird, auf Prozess B (Target) auf Computer X zugreifen.

Das Attribut „src“

Stellt ein Quellobjekt dar, auf das der Teilnehmer einwirkt, zusammen mit dem Geräte- oder Prozesskontext für das Quellobjekt (der Computer, auf dem sich das Quellobjekt befindet). Wenn Nutzer U beispielsweise Datei A auf Computer X in Datei B auf Computer Y kopiert, werden sowohl Datei A als auch Computer X im src-Teil des UDM-Ereignisses angegeben.

Das Zwischenattribut

Stellt Details zu einem oder mehreren Zwischengeräten dar, auf denen die im Ereignis beschriebene Aktivität verarbeitet wird. Dazu gehören möglicherweise Gerätedetails wie Proxyserver und SMTP-Relay-Server.

Das Attribut „observer“

Stellt ein Beobachtergerät dar, das kein direkter Vermittler ist, aber das betreffende Ereignis beobachtet und meldet. Dazu gehören beispielsweise ein Paketsniffer oder ein netzwerkbasierter Sicherheitsscanner.

Das Attribut „about“

Hier werden Details zu einem Objekt gespeichert, auf das im Ereignis verwiesen wird und das nicht in den Feldern „principal“, „src“, „target“, „intermediary“ oder „observer“ beschrieben ist. Beispielsweise könnte er Folgendes erfassen:

• E-Mail-Anhänge
• Domains, URLs oder IP-Adressen, die im E-Mail-Text eingebettet sind.
• DLLs, die während eines PROCESS_LAUNCH-Ereignisses geladen werden.

Das Attribut „security_result“

Dieser Abschnitt enthält Informationen zu Sicherheitsrisiken und Bedrohungen, die von einem Sicherheitssystem erkannt werden, sowie zu den Maßnahmen, die zur Minderung dieser Risiken und Bedrohungen ergriffen werden.

Hier sind einige Arten von Informationen, die im Attribut „security_result“ gespeichert werden:

• Ein E-Mail-Sicherheitsproxy hat einen Phishing-Versuch erkannt (security_result.category = MAIL_PHISHING) und die E-Mail blockiert (security_result.action = BLOCK).
• Eine E-Mail-Sicherheits-Proxy-Firewall hat zwei infizierte Anhänge erkannt (security_result.category = SOFTWARE_MALICIOUS) und diese in Quarantäne gestellt und desinfiziert (security_result.action = QUARANTINE oder security_result.action = ALLOW_WITH_MODIFICATION) und dann die desinfizierte E-Mail weitergeleitet.
• Ein SSO-System erlaubt eine Anmeldung (security_result.category = AUTH_VIOLATION), die blockiert wurde (security_result.action = BLOCK).
• In einer Malware-Sandbox wurde fünf Minuten nach der Zustellung (security_result.action = ALLOW) eines Anhangs (security_result.category = SOFTWARE_MALICIOUS) an den Posteingang des Nutzers Spyware erkannt.

Netzwerkattribut

In Netzwerkattributen werden Daten zu netzwerkbezogenen Ereignissen und Details zu Protokollen in Unternachrichten gespeichert. Dazu gehören Aktivitäten wie gesendete und empfangene E-Mails und HTTP-Anfragen.

Das Attribut „extensions“

In den Feldern unter diesem Attribut werden zusätzliche Metadaten zum Ereignis gespeichert, das im ursprünglichen Rohprotokoll erfasst wurde. Sie kann Informationen zu Sicherheitslücken oder zusätzliche authentifizierungsbezogene Informationen enthalten.

Struktur einer UDM-Entität

In einem UDM-Entitätseintrag werden Informationen zu jeder Entität innerhalb einer Organisation gespeichert. Wenn „metadata.entity_type“ den Wert „USER“ hat, werden im Datensatz Informationen zum Nutzer unter dem Attribut „entity.user“ gespeichert. Wenn „metadata.entity_type“ den Wert „ASSET“ hat, enthält der Eintrag Informationen zu einem Asset wie einer Workstation, einem Laptop, einem Smartphone oder einer virtuellen Maschine.

Abbildung: Ereignisdatenmodell

Metadatenfelder

Dieser Abschnitt enthält Felder, die in einer UDM-Entität erforderlich sind, z. B.:

• „collection_timestamp“: Datum und Uhrzeit, an dem bzw. in der der Datensatz erfasst wurde.
• entity_type: Der Entitätstyp, z. B. Asset, Nutzer oder Ressource.

Das Entitätsattribut

In den Feldern unter dem Entitätsattribut werden Informationen zur jeweiligen Entität gespeichert, z. B. Hostname und IP-Adresse bei einem Asset oder windows_sid und E-Mail-Adresse bei einem Nutzer. Der Feldname ist „entity“, der Feldtyp ist jedoch ein Nomen. Ein Nomen ist eine gängige Datenstruktur, in der Informationen sowohl in Entitäten als auch in Ereignissen gespeichert werden.

• Wenn „metadata.entity_type“ den Wert „USER“ hat, werden die Daten unter dem Attribut „entity.user“ gespeichert.
• Wenn „metadata.entity_type“ den Wert „ASSET“ hat, werden die Daten unter dem Attribut „entity.asset“ gespeichert.

Das Beziehungsattribut

In den Feldern unter dem Beziehungsattribut werden Informationen zu anderen Entitäten gespeichert, mit denen die Hauptentität in Beziehung steht. Beispiel: Die primäre Entität ist ein Nutzer und ihm wurde ein Laptop zugewiesen. Der Laptop ist eine zugehörige Entität. Informationen zum Laptop werden als „Entity“-Eintrag mit dem Attribut „metadata.entity_type“ = ASSET gespeichert. Informationen zum Nutzer werden als Datensatz vom Typ „Entität“ mit dem Metadatentyp „metadata.entity_type = USER“ gespeichert.

Der Nutzereintragssatz erfasst auch die Beziehung zwischen dem Nutzer und dem Laptop mithilfe von Feldern unter dem Attribut „Beziehung“. Im Feld „relation.relationship“ wird die Beziehung des Nutzers zum Laptop gespeichert, insbesondere, dass der Nutzer Inhaber des Laptops ist. Im Feld „relation.entity_type“ ist der Wert „ASSET“ gespeichert, da der Laptop ein Gerät ist.

In den Feldern unter dem Attribut „relations.entity“ werden Informationen zum Laptop gespeichert, z. B. der Hostname und die MAC-Adresse. Beachten Sie noch einmal, dass der Feldname „entity“ und der Feldtyp „Noun“ ist. Ein Nomen ist eine häufig verwendete Datenstruktur. In den Feldern unter dem Attribut „relation.entity“ werden Informationen zum Laptop gespeichert.

Im Feld „relation.direction“ wird die Richtung der Beziehung zwischen Nutzer und Laptop gespeichert, insbesondere ob die Beziehung bidirektional oder unidirektional ist.