Team und Kontosicherheit

Anmeldung, Zwei-Faktor, Einladungen, API-Schlüssel, Protokoll.

Anmeldung ohne Passwort #

NODE64 verschickt einen Anmeldelink an deine E-Mail-Adresse. Er gilt kurz und nur einmal. Es gibt kein Passwort, das gestohlen, wiederverwendet oder erraten werden kann.

Der Preis: Wer Zugriff auf dein Postfach hat, hat Zugriff auf dein Konto. Deshalb der nächste Abschnitt.

Zwei-Faktor-Anmeldung #

Unter Einstellungen → Sicherheit richtest du TOTP ein – mit jeder Authenticator-App. Danach fragt NODE64 nach dem Anmeldelink zusätzlich nach dem sechsstelligen Code.

Beim Einrichten bekommst du Wiederherstellungs-Codes. Druck sie aus oder leg sie in deinen Passwortmanager. Ohne Zweitgerät und ohne Codes kommen wir nicht an dein Konto – das ist der Punkt an Verschlüsselung.

Als Kontoinhaber kannst du 2FA für alle Mitglieder verpflichtend machen.

Team #

Lade Mitglieder per E-Mail ein. Zwei Rollen:

RolleDarf
Owneralles: Geräte, Regeln, Team, API-Schlüssel, Konto löschen
MitgliedBefunde und Geräte sehen, je nach Gruppenrecht bearbeiten

Über Gerätegruppen steuerst du, wer welche Systeme sieht und wer sie ändern darf. Ein Mitglied ohne Schreibrecht kann Befunde lesen, aber nicht akzeptieren oder vertagen – eine Entscheidung über ein Risiko ist eine Änderung.

Ein Nutzer kann in mehreren Konten Mitglied sein und oben rechts zwischen ihnen wechseln.

API-Schlüssel #

Unter Einstellungen → API legst du Schlüssel mit festgelegten Rechten an. Der Schlüssel wird einmal angezeigt – danach nur noch sein Präfix. Wir speichern ihn nur als Hash; wenn du ihn verlierst, legst du einen neuen an.

Schlüssel lassen sich jederzeit widerrufen. Siehe API.

Prüfung von außen #

Der Agent sieht, was auf einem System lauscht. Er sieht nicht, was davon durch Router, Portweiterleitung und Anbieter-Firewall tatsächlich hindurchkommt. Der Abgleich beider Listen findet die Weiterleitung, von der niemand mehr wusste — und die findet man von innen auf keinem anderen Weg.

Drei Ergebnisse je Port:

  • innen offen, außen offen — erwartet, wenn der Dienst öffentlich sein soll.
  • innen offen, außen zu — gut. Genau so soll ein interner Dienst aussehen.
  • außen offen, innen nichts — der interessante Fall. Meist eine Portweiterleitung, die auf ein anderes Gerät im Netz zeigt: eines, das niemand überwacht und niemand aktualisiert.

Ein viertes Ergebnis heißt keine Antwort. Das ist kein Zwischending, sondern die ehrliche Auskunft, dass wir es nicht wissen: Eine Firewall, die Pakete verwirft statt sie abzulehnen, sieht genauso aus wie ein überlastetes Netz. Diesen Fall als „zu" auszugeben wäre eine Entwarnung, für die es keine Grundlage gibt.

Was geprüft wird — und was nicht #

Geprüft werden die Ports, die innen lauschen, plus eine kleine feste Liste der üblichen Verdächtigen (22, 80, 443, 3306, 5432, 6379, 9200, 27017). Kein vollständiger Portscan über 65535 Ports: Das ist ein anderes Werkzeug mit anderen Rechtsfragen, und es beantwortet die Frage nicht besser.

Die Bedingungen, und warum es sie gibt #

Eine Verbindung zu einer fremden Adresse aufzubauen ist unproblematisch, solange die Adresse einem selbst gehört — und wird zum Gegenteil, sobald sie es nicht tut. Deshalb:

  1. Kein Eingabefeld für die Adresse. Geprüft wird ausschließlich die öffentliche Adresse, von der ein Gerät dieses Kontos einen gültig authentifizierten Bericht geschickt hat. Eine eingetippte Adresse wäre eine Behauptung; diese hier ist ein Nachweis.
  2. Die Adresse muss frisch sein (höchstens 30 Minuten alt). Anschlüsse bekommen bei einer Zwangstrennung eine neue Adresse — eine vier Stunden alte kann längst jemand anderem gehören. Starten Sie die Prüfung also kurz nach einem Bericht.
  3. Geteilte Anschlüsse sind ausgeschlossen. Melden Geräte aus verschiedenen Konten von derselben öffentlichen Adresse, steht dahinter ein geteilter Anschluss (Carrier-Grade NAT). Dann gehört die Adresse nicht einem Kunden, und niemand kann für sie zustimmen.
  4. Jeder Lauf wird protokolliert — auch der abgelehnte, mit Adresse, Zeitpunkt und dem Konto, das ihn ausgelöst hat. Das Einschalten selbst steht ebenfalls im Protokoll.

Einschalten kann das nur der Kontoinhaber, unter Einstellungen › Sicherheit. Die Vorgabe ist aus: Alle anderen Schalter dort bestimmen nur, was NODE64 mit vorhandenen Daten tut; dieser löst eine Verbindung aus, und das ist eine andere Art von Entscheidung.

Protokoll #

Jede sicherheitsrelevante Handlung landet im Audit-Log: Anmeldungen, geänderte Adressen, 2FA an und aus, Einladungen, gelöschte Geräte, angelegte und widerrufene Schlüssel, akzeptierte Risiken, Änderungen an Alarmregeln. Mit Zeitpunkt, Urheber und IP-Adresse, filterbar nach Aktion.

Das Protokoll ist nicht löschbar. Es ist der Beleg, wenn jemand fragt „wer war das?".

Konto löschen #

Unter Einstellungen → Konto kannst du alle Daten als Archiv exportieren und das Konto löschen. Löschen heisst löschen: Geräte, Befunde, Uploads, Messergebnisse. Der Vorgang ist nicht umkehrbar, und wir behalten nichts zurück.

Etwas unklar?

Wenn hier etwas fehlt oder unverständlich ist, sag uns Bescheid – die Seite wächst mit den Fragen.

Frage stellen