Dieses Dokument beschreibt die sicherheitsrelevanten Einstellungen der LANCOM Management Cloud (LMC). Es dient als Referenz für den sicheren Betrieb der LMC.
Im LMC unterscheiden wir zwischen drei verschiedenen Kontotypen:
Die Daten sind pro Konto streng getrennt und können nur abgerufen werden, wenn einem einzelnen Prinzipal eine Mitgliedschaft für den Zugriff auf dieses Konto gewährt wurde.
Konten werden nach Hierarchie sortiert: Ein Projekt muss in einer Organisation erstellt werden, und Organisationen werden unterhalb von Verteilungen erstellt. Es gibt einige Funktionen, mit denen Projekte aus der übergeordneten Organisation verwaltet werden können (z. B. Administratorvererbung, Gerätepools, die zum Zuweisen von Geräten zu Projekten verwendet werden können), die weiter unten beschrieben werden.
Insgesamt ist es als bewährte Praxis bekannt, einem bestimmten Auftraggeber nur die geringsten Rechte zu gewähren, die dieser Auftraggeber zur Erfüllung einer bestimmten Aufgabe in der Anmeldung benötigt. Im LMC-Kontext bedeutet dies, dass nur sehr vorsichtig Projektadministratorrechte vergeben und eine Behörde mit weniger Rechten angewendet wird, wann immer dies möglich ist. Folgende Berechtigungen können pro Kontoebene erteilt werden:
Bei LMC-verwalteten Prinzipalen kann einem Benutzer für jedes Konto, auf das er Zugriff hat, eine andere Berechtigung gewährt werden. Dies gilt auch für authentifizierte IdP-Prinzipale.
Falls die IdP-Autorisierung auch für ein Konto konfiguriert und aktiviert wird, werden die Autoritäten und daraus resultierenden Rechte eines Prinzipals durch Anwendung der Rollen abgeleitet, die im IdP zugewiesen sind (siehe auch Abschnitt „IdP-Prinzipal-Verwaltung“). Dies führt dazu, dass pro Prinzipal pro Kontoebene die gleiche oder gar keine Berechtigung erteilt wird, kann aber nicht dazu führen, dass z. B. ein Projektadministrator in einem Projekt und ein Hotspot-Administrator in einem zweiten Projekt derselben Organisation ist. Bei der Verwendung der IdP-Prinzipalverwaltung wird empfohlen, den Einladungsmechanismus nicht zu verwenden, um den im Kontext dieses bestimmten Kontos autorisierten IdP-Prinzipalbehörden Berechtigungen zuzuweisen. Die explizite Einladung von Benutzern führt zu sogenannten „direkten Mitgliedschaften“, die die Zugriffskontrolle durch den IdP außer Kraft setzen.
Mit der Administratorvererbung können die Sicherheit und die Verwaltungsfreundlichkeit für Anbieter von verwalteten Diensten erhöht werden, die in der Regel über eine Organisation verfügen und einzelne untergeordnete Projekte für ihre Kunden verwenden. Statt Prinzipale einzeln zu Projekten einzuladen und diese Prinzipale auch einzeln zu verwalten, ermöglicht die Administratorvererbung Mitgliedern der Organisation den Zugriff auf die untergeordneten Projekte, ohne explizit zu jedem einzelnen Projekt eingeladen zu werden. Dies vereinfacht die Zugriffskontrolle, da diese Prinzipale zentral in der Organisation verwaltet werden können (z. B. wenn ein Prinzipal das Unternehmen verlässt und nicht mehr auf LMC-Konten zugreifen darf). Die Erstellung direkter Mitgliedschaften pro Projekt für jeden der betroffenen Hauptbenutzer entfällt und der Aufwand für die Durchführung von Zugriffsbeschränkungen auf Projektebene wird reduziert.
Direkte Mitgliedschaften mit expliziten Einladungen und Administratorvererbung können in gemischten Szenarien pro Prinzipal und Konto verwendet werden. Dies führt dazu, dass einem einzelnen Prinzipal über Administratorvererbung Projektzugriff mit anderen Rechten gewährt wird als durch die Annahme einer Einladung und die Erstellung einer direkten Mitgliedschaft. In diesem Fall gewinnen Rechte, die über die direkte Mitgliedschaft gewährt werden, geerbte Rechte, was zu einem höheren Satz von Rechten aus der Projektmitgliedschaft führen kann, als sie über die Administratorvererbung gewährt werden. Deshalb empfehlen wir, Vererbungsszenarien für Direktmitgliedschaften nur sehr vorsichtig anzuwenden. Als sichere Standardeinstellung ist die Vererbung von LMC-Administratoren in Organisationen deaktiviert und muss von Organisationsadministratoren aktiviert werden. Bei der Aktivierung der LMC-Administratorvererbung muss eine Berechtigung auf Projektebene für diese Hauptbenutzer ausgewählt werden, die auf geerbte Hauptbenutzer für alle Projekte der Organisation angewendet wird.
Die IdP-Administratorvererbung kann separat von der LMC-Administratorvererbung auf Organisationsebene aktiviert werden. Im Zusammenhang mit der IdP-Authentifizierung funktioniert sie wie oben beschrieben als Vererbung des LMC-Administrators, ist jedoch auf die Prinzipale beschränkt, die über eine Konfiguration in dieser bestimmten Organisation IdP verwaltet werden. Wenn die IdP-Autorisierung in LMC zusätzlich aktiviert wird, erhalten LMC-Autoritäten Rechte gemäß den zurückgegebenen Werten von IDP und Gruppenzuordnungen, die beim IdP-Setup durchgeführt werden (weitere Details finden Sie im Abschnitt "IdP-Prinzipal-Verwaltung")
Projektadministratoren können sich sowohl von der Vererbung des LMC-Administrators als auch von der Vererbung des IdP-Administrators getrennt abmelden, indem sie die entsprechende Einstellung in den Projekteinstellungen aktivieren. Jede Änderung des Vererbungsstatus wird im Organisationsprotokoll angezeigt. Beide Varianten, sich von der Administrator-Vererbung abzumelden, sind in der Telekom Schwestercloud vertraglich nicht vorgesehen.
Für den LMC passen wir allgemeine Empfehlungen an, wie man sichere, einprägsame Passwörter wählt und was zu vermeiden ist, wie sie z.B. vom Bundesamt für Sicherheit in der Informationstechnik bereitgestellt werden:
In der Standardkonfiguration erfordert LMC eine mindestens achtstellige Kennwortlänge, einschließlich mindestens einer Zahl und eines Sonderzeichens. Es wird dringend empfohlen, zumindest ein Passwort gemäß den oben genannten Richtlinien zu erstellen. Zusätzlich kann die entsprechende Umgebungsvariable angepasst werden, um stärkere Prinzipalkennwörter zu erzwingen. Dies wird für jede private LMC-Installation empfohlen. Es wird als gute Praxis angesehen, für jeden Prinzipal pro LMC-Instanz unterschiedliche Passwörter zu wählen, wobei jede der im obigen Abschnitt erwähnten übereinstimmenden Empfehlungen (siehe auch „Allgemeine Empfehlungen“).
Im Allgemeinen wird dringend empfohlen, keine remote verwalteten Ressourcen ungeschützt zu lassen, d. h. nach Möglichkeit einen Kennwortschutz anzuwenden. Wenden Sie dabei nach Möglichkeit die oben genannten Passwort-Sicherheitsrichtlinien an (siehe auch „Allgemeine Empfehlungen“). In einigen Fällen kann ein projektweites Kennwort für die Gerätekonfiguration festgelegt werden. Wir empfehlen, diese Option nicht zu wählen, und sie sollte nur verwendet werden, wenn es wirklich erforderlich ist. Viel sicherer ist es, ein anderes Passwort pro Gerät zu haben. Wenn ein gemeinsames Kennwort für die Gerätekonfiguration pro Konto nicht vermieden werden kann, wird dringend empfohlen, für diese Option mindestens ein hochsicheres Kennwort zu wählen.
Um eine zusätzliche Schicht der Zugriffskontrolle und Sicherheit hinzuzufügen, können von LMC verwaltete Prinzipale die Zweitfaktor-Authentifizierung (2FA) für ihre Prinzipale aktivieren. Das zusätzlich bereitgestellte Geheimnis wird als zeitbasiertes Einmalpasswort (TOTP) generiert. Der gemeinsame geheime Schlüssel, der von der Authentifikator-App für die TOTP-Erstellung verwendet wird, wird von LMC generiert. Dieser gemeinsame geheime Schlüssel kann entweder in einer Authentifizierer-App auf einem mobilen Gerät oder in einer Passwort-Manager-Erweiterung eines Browsers auf einem beliebigen Computer enthalten sein. Die zweite Option wird nur empfohlen, wenn ein LMC-Prinzipal sicherstellen kann, dass nur er auf die Passwort-Manager-Erweiterung dieses bestimmten Browsers zugreift. Sicherheitsmaßnahmen zum Schutz von Browser-Passwort-Manager-Erweiterungen oder mobilen Geräten sind nicht Teil dieser Dokumentation.
Einige besonders sicherheitsempfindliche Kunden können eine Option für ihr Projekt aktivieren, was in der Folge die Bereitstellung einer 2FA vor dem Eintritt in das Projekt erfordert. Das Aktivieren oder Deaktivieren von 2FA-Einschränkungen für ein Projekt wird im Projektprotokoll angezeigt. LMC-verwaltete Prinzipale, die keinen zweiten Faktor bereitstellen können oder deren gemeinsamer geheimer Schlüssel von einer anderen Software erstellt wurde, können diese Projekte nicht eingeben. Prinzipale müssen für jede LMC-Instanz, auf die sie Zugriff haben, einen eigenen TOTP-Generator erstellen, da jede LMC-Instanz für jeden Prinzipal unterschiedliche gemeinsame geheime Schlüssel bereitstellt.
Für IdP-verwaltete Prinzipale muss der IdP gemäß den Sicherheitsrichtlinien des Unternehmens konfiguriert werden. Die Richtlinien für die Konfiguration sicherer IdP sind nicht Teil dieser Dokumentation. Der LMC überprüft die MFA-bezogenen Werte im bereitgestellten ID-Token nicht, da nach bewährter Praxis in der Industrie von IdP verwaltete Prinzipale als ausreichend gesichert betrachtet werden, um auch die meisten eingeschränkten 2FA-Ressourcen zu betreten. Bei LMC 2FA-eingeschränkten Ressourcen können Projektadministratoren wählen, ob a) keine Zugriffsbeschränkungen für ein Projekt festgelegt werden sollen, b) nur von LMC verwaltete Hauptbenutzer nach der Ausgabe ihres persönlichen zweiten Faktors in das Projekt eintreten dürfen, oder c) ein IdP-Login erforderlich ist oder der persönliche zweite Faktor eines Hauptbenutzers für den Zugriff auf das Konto angegeben werden soll. Die dritte Option ermöglicht die Eingabe des Projekts in Prinzipale aller IdPs, die in der jeweiligen LMC-Instanz konfiguriert sind, wenn diese zusätzlich Zugriffsberechtigungen entweder durch direkte Mitgliedschaft oder IdP-Autorisierung haben. Weitere Informationen zur IdP-Benutzerverwaltung finden Sie im Abschnitt „Alternative Authentifizierungsmethoden“.
Um eine weitere Schicht der Zugriffskontrolle auf Ressourcen mit hoher Kritikalität anzuwenden, müssen auch modernere Sicherheitsmaßnahmen außerhalb des LMC berücksichtigt werden. Diese sind nicht Gegenstand dieser Dokumentation.
In LMC gibt es mehrere Typen von API-Schlüsseln, jeder Typ wendet einen anderen Umfang und Zweck an.
SIEM-API-Schlüssel | Prinzipal-gebundene Einzelkontoschlüssel | Prinzipal-gebundene Kontoübergreifende Schlüssel | |
Kontenumfang | Einzelkonto | Ein Konto, einschließlich direkter Kinderkonten. | Auswahl eines, mehrerer oder aller Konten eines Prinzipals, auch für Geschwisterkonten möglich. |
Berechtigungen | SIEM-relevante APIs | Alle APIs, die gemäß Mitgliedschaftsangabe pro Konto zulässig sind, einschließlich Schreiboptionen. | Alle APIs, die gemäß Mitgliedschaftsangabe pro Konto zulässig sind, einschließlich Schreiboptionen. |
Maximale Lebensdauer | Unbegrenzte, aber regelmäßige Rotation empfohlen | 1 - 3560 Tage, Kurzzeitschlüssel und regelmäßiger Wechsel empfohlen. | 1 - 356 Tage, kurzlebige Schlüssel und regelmäßiger Wechsel empfohlen. |
Maximale Anzahl | Eine pro Projekt | Fünf pro Konto pro Kapital, insgesamt 100 pro Kapital. | Fünf pro Konto pro Kapital, insgesamt 100 pro Kapital. |
Anwendungsfälle | Abrufen von Geräteprotokollen eines einzelnen Kontos zur Nutzungsüberwachung, wobei ein bestimmter Satz von SIEM-relevanten APIs abgefragt wird. | z. B. Abrufen von Überwachungsdaten mehrerer untergeordneter Konten; Zuweisung von Netzwerken an mehrere Standorte über API-Skript; Anspruch, Lizenzierung und Zuweisung von Geräten an Standorte über API-Skript; Massengerätekonfiguration über API-Skript. | z. B. Abrufen von Überwachungsdaten mehrerer untergeordneter Konten; Zuweisung von Netzwerken an mehrere Standorte über API-Skript; Anspruch, Lizenzierung und Zuweisung von Geräten an Standorte über API-Skript; Massengerätekonfiguration über API-Skript |
SIEM-API-Schlüssel (Secure Information and Event Management) können an bestimmte Endpunkte des LMC ausgegeben werden und dienen nur dazu, Informationen zu bestimmten Ereignissen innerhalb eines einzigen Kontos zu sammeln. Jeder andere Endpunkt gibt einen sprechenden HTTP-Fehler zurück, wenn versucht wird, mit einem SIEM-API-Schlüssel darauf zuzugreifen. Diese Schlüssel können auch nicht für Schreib- oder Löschvorgänge verwendet werden. Nur Projektadministratoren können SIEM-API-Schlüssel erstellen oder widerrufen. Projektadministratoren müssen sicherstellen, dass die SIEM-API-Schlüssel eines Projekts gedreht werden, wenn ein Prinzipal mit Zugriff auf die SIEM-API-Schlüssel eines Projekts keinen Zugriff mehr auf dieses Projekt hat (siehe Abschnitt „Offboarding“).
Prinzipal-gebundene API-Schlüssel sind an einen einzelnen Prinzipal gebunden und erben oder spiegeln die Berechtigungen dieses Prinzipals innerhalb des LMC-Kontos, auf das ein Prinzipal mit diesem bestimmten API-Schlüssel zugreifen wird. Sie eignen sich ideal, wenn Aktionen einer bestimmten Person zuzuordnen sind (für Audit, Limits pro Prinzipal oder feinkörnige Autorisierung) oder für persönliche Automatisierungen, die Skripte wie Skripte, die eine API mit den LMC-Kontorechten eines bestimmten Prinzipals aufrufen, verwenden. Jeder Prinzipal verfügt in der Regel über eigene Schlüssel, die nur von diesem Prinzipal sichtbar und verwaltbar sind. Dies unterstützt Prüfpfade pro Prinzipal und erleichtert die Reaktion auf Vorfälle, indem einzelne Prinzipalschlüssel widerrufen werden, anstatt einen gemeinsamen SIEM-API-Schlüssel zu drehen.
Der Umfang eines prinzipiell gebundenen API-Schlüssels kann bei der Erstellung ausgewählt werden und entweder auf nur ein Konto (Organisation oder Projekt, „Single Account API Key“) beschränkt sein oder für den kontoübergreifenden Zugriff ausgewählt werden. Einzelne Kontoschlüssel können nur ein Projekt oder eine Organisation enthalten, auf das bzw. die sie Zugriff gewähren. Wenn Sie einen prinzipal-gebundenen API-Schlüssel besitzen, für den der Zugriff auf eine Organisation mit aktivierter LMC-Administratorvererbung aktiviert ist, können Prinzipale, die von einer Organisation an untergeordnete Projekte vererbt werden, auch auf alle untergeordneten Projekte mit einem API-Schlüssel zugreifen, wenn sich Projektadministratoren nicht aus der Administratorvererbung ausgeschlossen haben. Kontoübergreifende Zugriffsschlüssel können eine Auswahl von Geschwisterkonten oder allen Konten, denen ein Prinzipal angehört, unabhängig von ihrer Beziehung zu einem bestimmten Elternkonto enthalten. Aufgrund ihres potenziellen Umfangs müssen Cross-Account-Schlüssel sehr sorgfältig erstellt und sicher gespeichert werden.
Die Standardanzahl von prinzipal-gebundenen API-Schlüsseln ist auf 100 Schlüssel pro Prinzipal begrenzt, während die Anzahl von API-Schlüsseln pro Prinzipal pro Projekt auf fünf begrenzt ist.
Jede Prinzipal-gebundene oder SIEM-API-Schlüsselerzeugung oder -sperrung wird in den Konten protokolliert, auf die der Schlüssel zugreifen kann. Im Falle einer Administratorvererbung wird sie nur in der Organisation protokolliert, für die sie erstellt oder widerrufen wurde, aber noch in den untergeordneten Konten. Bei jeder API-Schlüsselerzeugung wird der Schlüsselwert selbst nur einmal angezeigt, sodass die Hauptbenutzer sicherstellen müssen, dass der Schlüssel sofort kopiert wird. Wenn dies vergessen wird, können Prinzipale nur diesen bestimmten Schlüssel widerrufen und einen neuen erstellen. Für jeden erstellten API-Schlüssel müssen Prinzipale je nach Umfang und Nutzung eine Ablaufoption für den Schlüssel auswählen:
Projektadministratoren können die Verwendung von API-Schlüsseln in dem jeweiligen Konto, für das sie verantwortlich sind, generell untersagen. API-Schlüssel können nicht neu für Konten erstellt werden, deren Administrator den Zugriff auf API-Schlüssel verweigert hat. Der Versuch, mit einem Schlüssel, der vor der Einschränkung erstellt wurde, auf diese Konten zuzugreifen, führt zu einer HTTP-Status-403-Fehlermeldung (nicht autorisiert). Jeder Kontozugriff mit einem beliebigen API-Schlüssel wird im entsprechenden Kontoprotokoll protokolliert. Jede Verwaltungsaktion, die in der Regel im Kontext eines Kontos protokolliert wird, wird als von einem API-Schlüssel ausgeführt angezeigt.
Seit Dezember 2025 können API-Schlüssel nicht mehr von IdP-verwalteten Prinzipalen in LMC erstellt und verwendet werden. Wenn dies nicht durch Compliance-Anforderungen verboten ist, ist eine Mischung aus IdP- und LMC-verwalteten Prinzipalen pro Konto durch die LMC-Technologie zulässig. In diesem Szenario können LMC-verwaltete Prinzipale mit persönlichen API-Schlüsseln für die Automatisierung verwendet werden. Die Verwendung von API-Schlüsseln muss dann von den Kontoadministratoren genau überwacht werden, ebenso wie ggf. das potenzielle manuelle Prinzipal-Offboarding (siehe auch Abschnitt „Manuelles Offboarding“). Weitere Sicherheitsverbesserungen für die Verwendung von API-Schlüsseln in LMC-IdP-Benutzerverwaltungsszenarien werden derzeit erforscht.
Das Identity Provisioning Tool (IdP) basierte Prinzipal-Management wurde in LMC eingeführt, um die rechtlichen Anforderungen der EU zu erfüllen und die LMC-Prinzipal-Verwaltung selbst zu vereinfachen. Um besonders geforderte Kriterien für die Zugriffskontrolle zu erfüllen, delegiert der LMC im ersten Schritt den Identitätsnachweis vollständig über OpenID Connect (OIDC) Auth Code Flow mit Proof Key for Code Exchange (PKCE) an den IdP. Der IdP überprüft die Anmeldeinformationen (E-Mail und Kennwort, wie in IdP gespeichert) und gibt dann ein signiertes ID-Token aus, das der LMC validiert und verwendet, um eine lokale Sitzung für eine bestimmte Prinzipalidentität einzurichten. Nach der Überprüfung der Identität eines Prinzipals wird die Inbuild-Sitzungsverwaltung von LMC angewendet.
Derzeit hat sich Microsoft EntraID mit OIDC V2 Endpunkten, Keycloak, Okta/ Auth0 und OpenTextAccess bewährt, und wir erwarten, dass jedes andere IdP-Tool auch funktioniert, wann immer der OIDC-Standard korrekt implementiert ist. In diesem Szenario
Um die IdP-Prinzipal-Authentifizierung für Prinzipale einer bestimmten Domäne zu aktivieren, kann die entsprechende IdP-Konfiguration in einem beliebigen Konto des LMC durchgeführt werden. Jede Änderung der Konfiguration wird im Kontoprotokoll dieses Kontos angezeigt.
Wenn die Verwaltung und Authentifizierung von IdP-Prinzipalen für eine bestimmte Domäne aktiviert ist, können Prinzipale dieser Domäne LMC-Konten selbst erstellen, indem sie
Darüber hinaus kann LMC konfiguriert werden, um auf Grundlage der vom IdP bereitgestellten Autorisierungsdaten und der in LMC durchgeführten Mappings zu bewerten, welche Autorisierung einem bestimmten Prinzipal erteilt wird. Der IdP muss dann Identitäts- und grobkörnige Signale (Gruppen/Rollen) liefern, woraus sich eine bestimmte LMC-Hauptrolle ergibt. Feinkörnige Prüfungen werden mit den eigenen RBAC-Regeln des LMC für jede UI- oder API-Operation durchgeführt, wobei die etablierte Prinzipalidentität und der Kontenkontext verwendet werden. LMC-Mitgliedschaften werden für diese Prinzipale nicht wirksam, und es werden keine Mitgliedschaften für einen Prinzipal gespeichert, um sicherzustellen, dass einem Prinzipal immer nur die Rechte gewährt werden, die aus den ID-Tokendaten der aktuellen Sitzung abgerufen werden. Es wird nicht empfohlen, diesen Prinzipalen zusätzliche direkte Mitgliedschaften im autorisierten IdP-Konto (oder in der Kontohierarchie) bereitzustellen, um von der IdP gewährte Rechte nicht außer Kraft zu setzen. Direkte Mitgliedschaften für autorisierte IdP-Prinzipale können jederzeit in einem gleichgeordneten Konto erstellt werden, um Zugriff auf das autorisierte IdP-Konto (oder die Kontohierarchie) zu gewähren.
Ab Januar 2026
Wenn ein IdP-Benutzerkonto deaktiviert wird oder sich die entsprechende Gruppenmitgliedschaft/App-Rolle im IdP ändert, führt die nächste LMC-Anmeldung oder Sitzungsvalidierung mit dem IdP zu aktualisierten Berechtigungen oder sogar zu einer Zugriffssperrung in LMC.
Die Authentifizierung und Autorisierung in LMC basiert auf signierten JSON Web Tokens (JWTs). Mit dem Signaturmechanismus können andere Mikrodienste die Integrität aller im Token gesendeten Informationen validieren. Browser-Instanzen, die von Prinzipalen (Clients) verwendet werden, können einen dedizierten Endpunkt anfordern, um neue Zugriffstoken entweder auf Basis von Benutzername und Kennwort oder auf Basis vorhandener Token zu erstellen. Einmal ausgestellt, kann der Client mit diesem Token (innerhalb des vordefinierten Zeitrahmens) nachweisen, dass er sowohl authentifiziert als auch zum Zugriff auf den angeforderten Teil der Geschäftslogik berechtigt ist. Dazu wird das Token als Teil jeder Anforderung in ihrem Header angewendet.
Es gibt einige Konsequenzen für das Benutzererlebnis, die durch das obige Konzept verursacht werden:
Die IdP-Sitzungsbehandlung folgt den oben beschriebenen Prinzipien.
Die Protokollierung in LMC erfolgt an mehreren Stellen, und der Protokollzugriff ist auf bestimmte Hauptrollen beschränkt (Organisationsadministrator auf Organisationsebene, Projektadministrator und technischer Administrator auf Projektebene). Jeder Log-Eintrag wird bei der Verarbeitung der entsprechenden Aktionen im LMC-Backend zusammengestellt. Protokollnachrichten haben unterschiedliche Vorlagen pro Typ sowie für die englische und deutsche Sprache. Jeder Service stellt seine eigenen Übersetzungsvorlagen für die entsprechenden Nachrichtentypen zur Verfügung. Protokolleinträge selbst können von keinem LMC-Prinzipal, Automatisierungsprinzipal oder Dienst, der einen Eintrag erstellt hat, geändert werden. Der Schutz von Protokolleinträgen auf Datenbankebene ist nicht Gegenstand dieser Dokumentation.
Kontoüberwachungsprotokolle auf Verteilungs-, Organisations- und Projektebene werden 365 Tage lang gespeichert. Anschließend werden die entsprechenden Datenbankeinträge durch automatisierte Datenbasis-Jobs gelöscht. Nur Kontoadministratoren oder technische Administratoren eines Projekts können auf Kontoüberwachungsprotokolle zugreifen. Üblicherweise werden Aktionen, die auf den Projekteinstellungen oder Verwaltungsseiten ausgeführt werden, protokolliert, z. B.:
Jeder Kontoüberwachungsprotokolleintrag enthält mindestens einen Übersichtsabschnitt, der auf den ersten Blick und ohne weitere Interaktion lesbar ist:
Bei expliziter Erweiterung des Protokolleintrags werden zusätzliche Informationen angezeigt:
Der Zugriff auf das Prüfprotokoll mit API-Schlüsseln ist auf prinzipal-gebundene Schlüssel von LMC-verwalteten Kontoadministratoren und technischen Administratoren eines Projekts beschränkt (siehe auch Abschnitt „Alternative Authentifizierungsmethoden“).
Auf Geräteprotokolle können nur Projektadministratoren, technische Administratoren und Projektmitglieder auf Projektebene zugreifen. Zum Anzeigen eines Geräteprotokolls muss die jeweilige Geräteentität ausgewählt und die Konfigurationsseiten eingegeben werden. Jeder Device Log Eintrag enthält mindestens einen Übersichtsausschnitt, der auf den ersten Blick und ohne weitere Interaktion lesbar ist:
Bei expliziter Erweiterung des Protokolleintrags werden zusätzliche Informationen angezeigt:
Geräteprotokolle können automatisiert abgerufen werden, indem entweder SIEM- oder prinzipal-gebundene API-Schlüssel verwendet werden (siehe auch Abschnitt „Alternative Authentifizierungsmethoden“).
Um sicherzustellen, dass ein LMC-Prinzipal nicht mehr auf Ressourcen zugreifen kann, die einem bestimmten Kunden gehören, nachdem ein Mitarbeiter die Arbeit für dieses bestimmte Unternehmen beendet hat, gibt es in diesem Fall meist zwei Möglichkeiten, Bedenken zu trennen.
Prinzipal-Offboarding für von LMC verwaltete Prinzipale erfordert manuelle Schritte, die von einem Kontoadministrator durchgeführt werden (Verteilung, Organisation und Projekt, falls zutreffend). Diese Aktionen müssen für jeden Prinzipal durchgeführt werden, der keinen Zugriff mehr auf den LMC haben soll und die folgenden Schritte umfassen:
Das Offboarding für IdP-verwaltete Prinzipale erfordert weniger manuelle Arbeit als das Offboarding von LMC-verwalteten Prinzipalen, muss jedoch mit der gleichen Aufmerksamkeit durchgeführt werden.
Für authentifizierte IdP-Prinzipale speichert der LMC direkte Mitgliedschaften.
| Beachten Sie Folgendes: Entfernen Sie die Mitgliedschaften eines Prinzipals immer manuell, auch wenn die IDp-Prinzipalauthentifizierung aktiviert ist, um zu verhindern, dass das Kennwort zurückgesetzt wird, wenn ein IdP von einem Kontoadministrator deaktiviert wird. |
Für zusätzlich IdP-autorisierte Prinzipale werden auch Zugriffsrechte über zurückgegebene Werte aus dem IdP gewährt. Die LMC speichert in diesem Fall keine Mitgliedschaften, sodass das Deaktivieren oder Entfernen eines Prinzipals oder seiner Rechte aus dem zuständigen IdP ausreicht, um den LMC-Zugriff für einen Prinzipal effektiv zu blockieren.
| Dennoch müssen direkte Mitgliedschaften von IdP-autorisierten Prinzipalen auch manuell entfernt werden. Das Entfernen des LMC-Prinzipals selbst ist optional und muss wie oben beschrieben erfolgen. |
|