Barvna shema: Svetla
Trenutno dejavna stran: start » de » Dokumentation » Datenintegration und Datenzugriff » WKL Database Gateway » Anleitungen » So prüfen Sie Anmeldemuster und Herkunft

So prüfen Sie Anmeldemuster und Herkunft

Sie wollen wissen, wann Anmeldungen am Dienst ankommen, woher sie stammen und ob sich darin ein Angriff abzeichnet – etwa eine Welle falscher Schlüssel aus einem fremden Land oder ein Schlüssel, der innerhalb eines Tages auf mehreren Kontinenten benutzt wird.

Lösungsübersicht

Der Dienst führt ein Anmeldeprotokoll in der Protokolldatei neben dem Verwaltungsspeicher: jede Anmeldeentscheidung mit Verfahren, Ergebnis, Grund einer Abweisung, Person und Herkunft. Die Herkunft ordnet er ohne Verbindung nach außen ein – über eine Geodatenbank, die auf dem Server liegt, und über die Netze, die Sie selbst benennen. Jede Minute wendet er Anmelderegeln auf die neuen Ereignisse an und speichert, was sie erkennen, als Befund – über Monate hinweg, gemessen an dem, was für die jeweilige Person üblich ist. Ausgewertet wird über die Verwaltungsschnittstelle:

Menge oder BefehlZeigtRecht
SignInHoursAnzahl je Stunde, Verfahren, Ergebnis, Land und Netzart – ohne Person und Adresseadmin
SignInOriginsHerkunft je eigenem Netz, Teilnetz, Land und Netzbetreiberadmin
SignInFindingsdie gespeicherten Befunde mit Regel, Stufe, Text und Vorschlagadmin; Person, Schlüssel und Vergleichswerte nur mit sign-in-events
sign-in-profilewas für eine Person über 90, 180, 365 oder mehr Tage üblich istsign-in-events
SignInEventsdie einzelnen Ereignisse mit Adresse und Personsign-in-events
SignInAdviceauffällige Muster der letzten sieben Tage, beim Lesen berechnetadmin; Person nur mit sign-in-events

Zeit aus Sicht des Servers. Stunde und Wochentag gelten nach der Uhr des Servers. Eine Anmeldung aus Tokio und eine aus Berlin im selben Augenblick fallen in dieselbe Stunde – genau das zeigt, wann der Dienst belastet wird und wann ein Angriff läuft, unabhängig von der Ortszeit des Aufrufers.

Umsetzung

  1. Geodatenbank bereitstellen. Ohne sie zeigt das Protokoll nur, ob eine Adresse aus einem eigenen, einem privaten oder einem öffentlichen Netz kommt, aber kein Land und keinen Netzbetreiber. Wählen Sie den Weg nach der Lage Ihres Servers:

    LageWeg
    Server erreicht das InternetQuelle wählen und den Dienst selbst laden lassen: POST /admin/v1/set-geoip-source mit { "source": "dbip-lite", "updateDays": 30 }, danach POST /admin/v1/update-geoip. Mit updateDays lädt er künftig von selbst nach.
    Nur der Arbeitsplatz der Verwaltung erreicht das InternetDie Verwaltungsanwendung lädt die Dateien und übergibt sie mit POST /admin/v1/upload-geoip.
    Weder Server noch Arbeitsplatz erreichen das InternetDateien auf anderem Weg besorgen und mit upload-geoip übergeben oder am Server mit dem Befehl `import-geoip` einspielen.

    Zur Wahl stehen DB-IP Lite (ohne Konto, Lizenz CC BY 4.0) und MaxMind GeoLite2 (mit Kontonummer und Lizenzschlüssel Ihres MaxMind-Kontos); siehe Quellen der Geodatenbank. Beide Lizenzen verlangen eine Namensnennung; der Dienst liefert den Text in GeoIpFiles.Attribution mit, und wer die Herkunft anzeigt, zeigt ihn dazu.

  2. Eigene Netze benennen. Tragen Sie die Netze Ihrer Standorte in der Konfiguration ein, damit das Protokoll „Werk 3“ statt einer privaten Adresse zeigt:

    "Gateway": {
      "SignInLog": {
        "Networks": [
          { "Name": "Zentrale", "Network": "10.1.0.0/16" },
          { "Name": "Werk 3",   "Network": "10.3.0.0/16" }
        ]
      }
    }
  3. Einzelereignisse nur für die Zuständigen freigeben. Die Mengen mit Zählungen und Mustern liest jede Regel mit admin. Adresse und Person je Anmeldung sind personenbezogene Daten; sie liest nur, wessen Regel zusätzlich die Ressource sign-in-events wörtlich nennt:

    { "Id": "sicherheit", "Resources": [ "admin", "sign-in-events" ], "Verbs": [ "GET" ], "ReadOnly": true }

    Im Verwaltungsspeicher ist das ein Eintrag resource = sign-in-events unter ClientRuleItems.

  4. Befunde melden lassen. Damit ein Angriff auch nachts jemanden erreicht, tragen Sie Empfänger ein und richten den Mailversand ein:

    "Gateway": {
      "SignInLog": {
        "TimeZone": "Europe/Berlin",
        "Alerts": { "Recipients": [ "sicherheit@example.com" ], "DigestHour": 7 }
      }
    }

    Befunde der Stufe act (Angriffsmuster, weitergegebener Schlüssel) gehen sofort als Mail hinaus, Befunde der Stufe ask (etwas ist für eine Person neu) einmal am Tag gesammelt. Ohne Empfänger stehen die Befunde nur im Dienstprotokoll und in SignInFindings.

  5. Befunde lesen. SignInFindings führt jeden Befund mit Regel, Stufe, Zeitpunkt, Text und Vorschlag; die Regeln und ihre Schwellen stehen in der Referenz. Ein Programm merkt sich die höchste gelesene Id und fragt danach nur Neues ab:

    GET /admin/v1/odata/SignInFindings?$filter=Id gt 4711

    Observed ist der beobachtete Wert, Usual das für die Person Übliche; EventIds führt zu den einzelnen Ereignissen in SignInEvents, solange sie noch in der Protokolldatei stehen.

  6. Profil einer Person nachsehen. Um einen Befund einzuordnen – „ist Italien für Frank neu oder nur selten?“ –, fragen Sie das Anmeldeprofil über den Zeitraum ab, der Sie interessiert:

    POST /admin/v1/sign-in-profile
    Content-Type: application/json
     
    { "person": "Frank Mustermann", "days": 365 }

    Die Befunde selbst vergleichen immer mit den 90 Tagen vor dem Ereignis; der Zeitraum des Profils ändert nur die Ansicht.

  7. Verteilung auswerten. Für eine Wochenübersicht gruppieren Sie SignInHours nach Weekday (1 = Montag) und HourOfDay; für eine Karte nehmen Sie Latitude/Longitude aus SignInOrigins. Origin nennt die Adresse oder das Netz in der Form, die eine Anmelderegel unter from annimmt.

Hinweise

  • Was gezählt wird. Eine erfolgreiche Anmeldung erscheint einmal je 15 Minuten, Person, Verfahren und Herkunft, nicht bei jeder Anfrage. Gleiche Abweisungen innerhalb einer Minute stehen als ein Ereignis mit Anzahl (Repeats). Eine Anfrage ohne Anmeldedaten, auf die der Dienst mit seinen Anmeldeverfahren antwortet, ist kein Fehlversuch: Jede Windows-Anmeldung beginnt so. Sie erscheint als challenge und zählt nicht unter „Abgewiesen“ im Dienststatus.
  • Nicht gezählt werden Anfragen eines angemeldeten Aufrufers, dem nur das Recht für ein Objekt fehlt, und Anfragen an eine nicht lesbare Datenbank – sie sagen nichts über die Anmeldung.
  • Herkunft hinter einem Proxy. Die Herkunft ist die Adresse, die beim Dienst ankommt; hinter einem vertrauten Proxy die weitergereichte. Ohne eingetragenen Proxy erscheinen alle Anmeldungen mit seiner Adresse.
  • Aufbewahrung. Einzelereignisse, Profile und Befunde bleiben, bis die Protokolldatei ihre Größe erreicht (Gateway:Store:LogMaxMegabytes, Vorgabe 4 096 MB); dann gehen die ältesten zuerst, die Befunde zuletzt. Stundenwerte bleiben 400 Tage (Gateway:SignInLog:HourDays). Koordinaten sind auf eine Nachkommastelle gerundet (etwa 10 km); eine Geodatenbank ortet ohnehin nur ungefähr und meist auf die Stadt des Netzbetreibers.
  • Mitbestimmung. Eine Auswertung, die das Anmeldeverhalten einzelner Beschäftigter über längere Zeit vergleicht, kann in Deutschland der Mitbestimmung unterliegen (technische Einrichtung zur Überwachung). Klären Sie den Einsatz vorher mit den Zuständigen in Ihrem Haus. Das ist ein Hinweis, keine Rechtsberatung. Der Dienst stellt keine Rangfolge von Personen auf, führt Uhrzeiten in Profilen nur im Stundenraster und zeigt ein Profil nur auf ausdrückliche Anfrage für eine Person.
  • Schlüssel stehen nie im Protokoll, nur ihre Kennung. Ein unbekannter SQL-Anmeldename wird festgehalten, damit ein Durchprobieren vieler Namen erkennbar ist.

Verwandte Themen

de/wiki/data-conectivity/database-gateway/how-to/check-sign-in-patterns.txt · Zadnja sprememba: uporabnika Wolfgang van der Stille