Sicherheit

Die Seite „Zugriffsregeln: IP, Domain und Länder verwalten“ behandelt den in der URL bezeichneten Funktionsbereich. Der vorhandene Inhalt wird um den tatsächlichen Ablauf, die Voraussetzungen und die bekannten Grenzen ergänzt. Neue IP-, Domain- oder Länderregeln starten zwingend im Dry-Run. Eine Datenbankregel erzwingt eine Wartezeit von mindestens 24 Stunden vor der Aktivierung. Wenn eine Allow-Regel und eine Block-Regel gleichzeitig greifen, hat Allow Vorrang.

Zugriffsregeln können IP-Adressen, Domains oder Länder betreffen. Jede neue Regel startet zwingend im Dry-Run. Erst im Anschluss an mindestens 24 Stunden ist in der Lage sie aktiviert werden; diese Wartezeit ist als Datenbank-Constraint umgesetzt und nicht nur ein Hinweis in der Oberfläche.

Während des Dry-Runs wird beobachtet, welche Zugriffe die Regel betroffen hätte. Dadurch lassen sich Fehlkonfigurationen erkennen, bebevor echte Benutzer blockiert werden. Allow-Regeln haben Vorrang bevor Block-Regeln. Tritt mehreren Regeln ist zwingend zu deshalb die gesamte Kombination geprüft werden und nicht nur der zuletzt angelegte Eintrag.

Vor einer Aktivierung sollte der Administrator den eigenen Zugriff und notwendige Dienstzugriffe absichern. Eine zu weit gefasste Länder- oder IP-Sperre kann berechtigte Personen ausschließen. Änderungen sind einzeln im Vorfeld vonzunehmen und anschließend anhand der Protokolle zu kontrollieren.

Ist eine erwartete Sperre nicht wirksam, sind Status, Ende der 24-Stunden-Frist und mögliche Allow-Ausnahmen zu verifizieren. Bei unerwarteter Blockierung werden Regeltyp, Wert, Aktivierungszeit und betroffener Zugriff benötigt. Geheimnisse oder vollständige personenbezogene Logdaten dürfen dabei nicht weitergegeben werden.

Für die Seite „Zugriffsregeln: IP, Domain und Länder verwalten“ gilt damit: Der vorhandene Kurztext wird zu einer belastbaren Anleitung erweitert, ohne Möglichkeiten außerhalb des bestätigten Produktstands zu versprechen. Maßgeblich bleiben die verifizierten Faktenquellen und die sichtbare Zuständigkeit zwischen Tenant und Zentor. Bei Abweichungen sollten immer genau diese URL, der betroffene Mandant und der beobachtete Schritt genannt werden.

Bei der Arbeit mit „sicherheit“ sollte jeder Schritt zunächst mit einem kontrollierten Testfall geprüft werden. Entscheidend ist, dass die sichtbare Einstellung, der tatsächliche Systemstatus und das erwartete Ergebnis zusammenpassen. Bei Abweichungen helfen eine genaue Uhrzeit, der betroffene Mandant, der verwendete Kanal und die unveränderte Fehlermeldung bei der Analyse. Zugangsdaten, Tokens und personenbezogene Inhalte dürfen dabei nicht in Screenshots oder Supporttexte übernommen werden.