Administration, Identität und Governance

Team und Rollen: Mitglieder einladen, integrierte und benutzerdefinierte Rollen

Der Zugriff auf eine Plexicus-Organisation ist rollenbasiert, und die Seite Team zeigt eine Rolle pro Mitglied.

Ein Mitglied einladen

Öffne Settings Team , klick auf Add member und füll den Dialog Invite a team member aus: eine Email address und eine Role. Klick dann auf Send invitation.

Einladungen sind für neue Benutzer gedacht. Die eingeladene Person bekommt eine E-Mail, mit der sie ein Plexicus-Konto anlegt und deiner Organisation beitritt. Eine Adresse, zu der schon ein Plexicus-Konto gehört, lässt sich nicht einladen, und die Antwort ist bewusst allgemein gehalten, damit sie nicht verrät, ob dieses Konto existiert. Bitte neue Kolleginnen und Kollegen, auf deine Einladung zu warten, statt sich vorher selbst zu registrieren: Eine Selbstregistrierung legt normalerweise eine separate Organisation an, deren Admin diese Person ist. Jeder Benutzer gehört zu genau einer Organisation; einen Wechsel zwischen Organisationen gibt es nicht.

Das Mitglied erscheint als Invited, bis es die Einladung annimmt, danach als Active. Einladungslinks laufen ab. Verpasst jemand das Zeitfenster, lädst du die Adresse einfach erneut ein; lädst du eine noch offene Adresse mit einer anderen Rolle erneut ein, wird diese Einladung aktualisiert. Wähl beim Einladen eine integrierte Rolle und verschieb das Mitglied auf der Seite Team in eine benutzerdefinierte Rolle, sobald es beigetreten ist.

Mit SSO und Just-in-Time-Provisioning bekommen Personen ihr Konto bei der ersten Anmeldung über deinen Identity Provider. Du musst sie also nicht einzeln einladen (Lektion 2).

Rollen ändern und Mitglieder entfernen

Über das Rollen-Dropdown in der Zeile eines Mitglieds änderst du dessen Rolle. Die neue Rolle wird zugewiesen, die vorherige entzogen, und die Meldung „Role assignment updated“ bestätigt das. Remove in einer Zeile entfernt ein aktives Mitglied oder zieht eine offene Einladung zurück. Beide Aktionen landen im Audit-Log. Verlässt jemand aus dem Engineering das Unternehmen, entferne die Person noch am selben Tag und filtere danach das Audit-Log nach ihrer E-Mail-Adresse, um ihre letzten Aktionen zu prüfen.

Integrierte Rollen

Standardmäßig teilen die integrierten Rollen die Aufgaben so auf:

Rolle	Typisch für	Was sie darf	Was sie nicht darf
Admin	Plattformverantwortliche, Security-Leitung	Organisationseinstellungen und Connectors, Mitglieder, Rollen, Befunde, Repositories und Scans, AI Pentests, Ticketing und Automations, Abrechnung, das Audit-Log	Für die SSO-Konfiguration sind unter Umständen separate SSO-Administrationsrechte nötig (Lektion 2)
Cyberoper	Security Engineers	Befunde triagieren (aktualisieren, als False Positive markieren, löschen, an Entwickler senden), Berichte importieren, Behebungen und Issues erzeugen, AI Pentests anlegen, ausführen und abbrechen, Scans anfordern, Repositories, Registries und Verbindungen zur Quellcodeverwaltung verwalten; Automations lesen	Pull Requests öffnen, Mitglieder einladen, Rollen verwalten, das Audit-Log lesen
Developer	Engineers, die den Code fixen	Befunde, Behebungen, Repositories, Scan-Läufe und AI Pentest-Ergebnisse ansehen; Pull Requests und Issues öffnen, Tickets senden, Berichte und Exporte (PDF und JSON) herunterladen; Automations lesen	Den Status von Befunden ändern oder False Positives markieren, Fixes erzeugen, Scans starten, Pentests ausführen, die Organisation verwalten

Mit den Standardrollen bereitet ein Cyberoper einen Fix vor und prüft ihn, und ein Developer öffnet den Pull Request. Diese Übergabe behandelt Modul 7.

Benutzerdefinierte Rollen

Je nach Plan können Admins unter Settings Roles eigene Rollen anlegen. Die Tabelle listet jede Rolle mit Role Name, Description, Type (ein Badge Built-in oder Custom) und Members, also der Zahl der Personen, die diese Rolle haben.

Klick auf Create role, gib einen Role Name und eine Description ein und hake im Raster die Berechtigungen an. Das Raster ist nach Ressourcen gruppiert, etwa Client, Finding, Repository, Remediation und Scan, und jeder Eintrag steht für eine der Aktionen read, write oder admin. Save bleibt deaktiviert, bis die Rolle einen Namen und mindestens eine Berechtigung hat, und Namen müssen in deiner Organisation eindeutig sein.

Integrierte Rollen lassen sich weder umbenennen noch löschen. Auf der Seite Roles bietet ihre Zeile nur Duplicate. Damit öffnet sich das Formular zum Anlegen, vorbefüllt mit den Berechtigungen dieser Rolle. Benutzerdefinierte Rollen zeigen Edit und Delete.

Ein Beispiel: Du willst einen „Security Lead“, der wie ein Cyberoper arbeitet, aber keine Befunde löschen darf. Dupliziere Cyberoper, nenne die Kopie Security Lead, entferne in der Gruppe Finding das Häkchen bei der Berechtigung zum Löschen von Befunden, speichere und weise die Rolle auf der Seite Team zu.

Identität: Single Sign-on, SCIM, Zwei-Faktor-Authentifizierung und Passkeys

Benutzer melden sich mit GitHub, Google oder Microsoft an, mit E-Mail und Passwort, mit einem Passkey oder über Login via SSO, wo sie den SSO-Login-Slug deiner Organisation eingeben. Die Authentifizierungseinstellungen liegen unter Settings Authentication , mit Zeilen für Two-factor authentication, SAML / SSO, Passkey und Active sessions.

SSO einrichten

Öffne den SSO-Hub unter Settings Authentication SAML / SSO Configure SSO . Für die SSO-Konfiguration brauchst du SSO-Administrationsrechte, die laut Dokumentation Admins zugewiesen sind. Verweigert dir die Seite den Zugriff, frag den Plexicus-Support, wer in deiner Organisation diese Rechte hat. Der Hub zeigt den Status, den Modus und den SSO Login Slug, die Anbieterauswahl, Verified Domains, SCIM 2.0 Provisioning, den Link Advanced settings zur Seite Advanced SSO Settings sowie Disable SSO, das die Konfiguration löscht. Welche Anbieter du nutzen kannst, hängt von deinem Plan ab.

Option in der Auswahl	Protokoll	Was du angibst
Okta, Azure AD / Entra ID	SAML 2.0	Geführter Assistent
Google Workspace	OIDC (empfohlen) oder SAML 2.0	Geführter Assistent
Ironchip	SAML 2.0 oder OIDC	Geführter Assistent
Generic SAML 2.0	SAML 2.0	IdP Entity ID, IdP SSO URL und X.509-Zertifikat; signierte Assertions sind standardmäßig Pflicht
Generic OIDC	OpenID Connect	Client ID, Client Secret, Discovery URL und Scopes; PKCE ist standardmäßig aktiv

Der Slug hat 3 bis 64 Zeichen aus Kleinbuchstaben, Ziffern, Bindestrichen oder Punkten und muss über alle Plexicus-Organisationen hinweg eindeutig sein. Die Service-Provider-Werte, die die Assistenten anzeigen, etwa ACS URL, Entity ID und OIDC Redirect URI, enthalten ihn. Wenn du den Slug änderst, musst du sie deshalb in deinem Identity Provider aktualisieren. Jeder geführte Assistent endet mit Test, einer Dry-Run-Validierung, die nichts speichert, und Activate, das die Konfiguration speichert.

Erweiterte Einstellungen: Modus, JIT und Gruppen-Mapping

Auf der Seite Advanced SSO Settings (Link Advanced settings im Hub) wählst du den Authentication Mode. Änderungen greifen bei der nächsten Anmeldung des jeweiligen Benutzers.

Modus	Verhalten
Coexist (Standard)	SSO und Passwort-Login funktionieren beide
SSO Preferred	SSO ist der Standard; der Passwort-Login bleibt als Fallback
SSO Enforced	Als einziger Zugang gedacht; laut Produkt sind Passwort- und Passkey-Logins deaktiviert

JIT Provisioning ist standardmäßig aktiv und legt bei der ersten SSO-Anmeldung eines Benutzers ein Konto mit der Standardrolle an (developer, sofern du sie nicht änderst). Group → Role Mappings übersteuern das: Die erste passende IdP-Gruppe bestimmt die Rolle. Hat deine Organisation verifizierte Domains, werden nur E-Mail-Adressen aus diesen Domains bereitgestellt, und eine E-Mail-Adresse, die zu einer anderen Organisation gehört, wird abgelehnt. In aktuellen Releases werden die Mappings bei jeder SSO-Anmeldung neu ausgewertet: Verschiebst du jemanden in eine andere IdP-Gruppe, ändert sich die Rolle bei der nächsten Anmeldung, mit einem Eintrag im Audit-Log. Für Benutzer in einer gemappten Gruppe verwaltest du die Rolle in deinem Identity Provider; eine Änderung auf der Seite Team kann bei der nächsten Anmeldung überschrieben werden.

SCIM-Provisioning

Der Hub zeigt deinen SCIM Endpoint. Create SCIM Token stellt ein Token aus, das 365 Tage gültig ist und nur einmal angezeigt wird. Rotate stellt ein neues Token aus und lässt das alte noch 7 Tage funktionieren; Revoke sperrt ein Token sofort. Tokens mit weniger als 30 verbleibenden Tagen zeigen Expiring soon. SCIM deckt Benutzer und Gruppen ab: Ein Benutzer, den dein Identity Provider deaktiviert, verliert den Zugang ohne manuellen Schritt.

Zwei-Faktor-Authentifizierung und Passkeys

Um 2FA einzuschalten, klick auf den Schalter in der Zeile Two-factor authentication, scanne den QR-Code mit einer Authenticator-App und gib den 6-stelligen Code ein. Die Zeile zeigt dann Manage.

Mit einem Passkey meldest du dich per Fingerabdruck, Gesichtserkennung oder Sicherheitsschlüssel an: Klick in der Zeile Passkey auf Set up und dann in Link this device auf Continue. Unter SSO steht in der Zeile Passkey Managed by SSO, und Passkeys werden stattdessen in deinem Identity Provider konfiguriert. Die Zeile Two-factor authentication bleibt unverändert.

Das Audit-Log: was erfasst wird, Filter und Integrität

Das Audit-Log beantwortet für deine ganze Organisation die Frage „Wer hat wann was getan?“. Je nach Plan können Admins es unter Settings Audit Log öffnen; andere Rollen nicht.

Was du siehst

Jede Zeile hat einen Timestamp, einen Actor Type (User, System oder Integration), den Actor, die Action, den Resource Type, die Resource und Details. Das Augensymbol in Details öffnet den vollständigen Eintrag mit seinen Metadaten. Passwörter, Tokens, API Keys, Client Secrets, Zertifikate und Cookies werden durch [redacted] ersetzt, bevor ein Eintrag gespeichert wird. So wird das Log nicht zur zweiten Kopie deiner Secrets.

Filtern

Du kannst vier Filter kombinieren: eine Zeitraumauswahl Date range (mit Voreinstellungen wie Last 7 days, Last 14 days und Last 30 days), Actor email (Teilübereinstimmung), Action Type und Resource Type (User, Client, Repository, Finding, Remediation, Connector oder Role). Die Ergebnisse erscheinen mit 50 Einträgen pro Seite und Buttons zum Vor- und Zurückblättern, und ein Reset-Button setzt die Filter zurück.

Die Liste Action Type deckt die häufigsten administrativen Aktionen ab:

Ressource	Aktionen
Benutzer	user.invited, user.removed
Organisation	client.settings_updated
Repositories	repository.created, repository.deleted, repository.scan_triggered
Connectors	connector.added, connector.removed
Behebungen	remediation.created, remediation.updated
Befunde	finding.status_changed
Rollen	role.created, role.deleted, role.assigned, role.revoked

Das Log erfasst mehr als diese Liste. Es zeichnet auch An- und Abmeldungen auf, Passwortänderungen, das Anlegen und Widerrufen von API-Tokens, die Registrierung von Passkeys, CSV- und JSON-Exporte (SARIF) von Befunden, Änderungen an Automations, Änderungen an SCIM-Benutzern und -Gruppen, Änderungen an der SSO-Konfiguration und SSO-Anmeldungen sowie Rollenänderungen, die aus dem Mapping von IdP-Gruppen stammen. Auch das Öffnen des Audit-Logs wird erfasst. Wer es prüft, hinterlässt also selbst eine Spur.

Integrität prüfen

Das Log macht Manipulationen erkennbar. Jeder Eintrag speichert einen SHA-256-Hash, der mit dem vorherigen Eintrag deiner Organisation verkettet ist. Ändert oder löscht jemand einen Eintrag, bricht die Kette an dieser Stelle. Um das zu verbergen, müsste man jeden späteren Eintrag neu schreiben.

Du prüfst die Kette über die Plexicus API. Ein Admin kann den Endpunkt Verify Audit Log Chain Integrity unter /audit-logs/integrity-verification aufrufen. Er berechnet die Kette neu und gibt valid: true zurück, wenn alles übereinstimmt, oder valid: false mit einem Verweis first_break auf den ersten Eintrag, an dem die Kette bricht. Einträge, die geschrieben wurden, bevor die Hash-Verkettung dein Deployment erreicht hat, zählen als Einträge aus der Zeit vor der Kette und fließen nicht ins Ergebnis ein. Die Prüfung umfasst nur die Einträge, die deine Organisation noch aufbewahrt. API-Tokens und den Aufruf der API behandelt Modul 9.

Als Nachweis nutzen

Die Aufbewahrungsdauer hängt von deinem Plan ab und bei selbst gehosteten Installationen von deiner Konfiguration. Braucht ein Auditor einen längeren Zeitraum, hol dir die benötigten Einträge über die API List Audit Logs, bevor sie aus der Aufbewahrung fallen.

Das Audit-Log unterstützt Zugriffsüberprüfungen, Incident-Zeitleisten und Anfragen von Auditoren. Plexicus liefert die Aufzeichnung und den Nachweis ihrer Integrität; ob deine Kontrollen ein Framework erfüllen, entscheiden deine Auditoren.

Organisationseinstellungen: Profil, Regulierungen, Sprache, Eigentumsnachweis, KI und Pläne

Die gesamte Administration liegt unter Settings in der linken Seitenleiste, aufgeteilt in drei Gruppen. Organization enthält Organization, Team, Roles und Ownership Verification. Configuration enthält Integrations, Platform, Billing und BYOAI. My Account enthält dein eigenes Konto, die Authentifizierung, Tokens und das Audit Log. Roles und Audit Log sehen nur Admins; ruft jemand ohne Admin-Rechte die Adresse direkt auf, erscheint eine Seite „Page not found“. Billing und BYOAI erscheinen je nach Plan.

Unternehmensprofil und Regulierungen

Öffne Settings Organization . Die Seite hat drei Tabs, und jeder speichert mit Save changes nur seinen eigenen Bereich:

• Profile zeigt Organisationsnamen, Abrechnungs-E-Mail, Organisations-ID und Inhaber schreibgeschützt an, dazu bearbeitbare Unternehmensangaben: offizieller Firmenname, geschäftliche E-Mail, Unternehmens-URL, Muttergesellschaft, globale Unternehmenskennung und Kategorie.
• Locations enthält Hauptsitz, Niederlassungen, Service- und Datenverarbeitungsstandorte sowie Tochtergesellschaften.
• Regulations ist der Ort, an dem du die Frameworks pflegst, nach denen du auditiert wirst. Plexicus ordnet ihnen Befunde zu und erzeugt Nachweise (Modul 8); manche Frameworks hängen von deinem Plan ab.

Sprache

Zwei Spracheinstellungen werden leicht verwechselt. Scan & Report Language unter Settings Platform gilt organisationsweit: KI-Analysen, Beschreibungen von Fix-Pull-Requests sowie exportierte PDF- und JSON-Berichte werden in dieser Sprache erstellt. App Language, ein Tab unter Settings Account , ändert nur deine eigene Oberfläche. Beide bieten Englisch und Spanisch. Auf der Seite Platform liegen außerdem die Standardwerte für Scans und Fixes (Module 3 und 7).

Eigentumsnachweis

Auf der Seite Settings Ownership Verification verwalten Admins organisationsweite Domains. Ein Pentest-Ziel braucht entweder eine verifizierte Domain, die auch ihre Subdomains abdeckt, oder eine App-Verifizierung im AI Pentest-Assistenten. App Verification ist hier eine schreibgeschützte Übersicht der App-Verifizierungen und kann je nach Release leer sein. Verifizierte Domains legen außerdem fest, welche E-Mail-Domains das SSO-JIT-Provisioning akzeptiert. Modul 6 geht beide Methoden durch.

KI-Konfiguration

Standardmäßig laufen Scans auf den Plattformmodellen von Plexicus, und Kundencode wird nicht zum Training von KI-Modellen verwendet. Wenn dein Plan es enthält, kannst du die Modelle mit BYOAI unter Settings BYOAI über den Endpunkt deines Anbieters durch eigene ersetzen: ein Fast-Modell, ein Smart-Modell und einen erforderlichen Embeddings-Endpunkt, die du gemeinsam mit Save BYOAI configuration speicherst. Jeder Block hat Test connection, und ein einziges Reset to Plexicus default setzt alle drei zurück. Was jeder Slot tut, erklärt Modul 7.

Pläne und Leistungsumfang

Dein Plan bestimmt, welche Funktionen deine Organisation hat und wie viel KI-Nutzung ihr zusteht. Settings Billing (Billing & Usage) zeigt den Plan, das Verlängerungsdatum, dein KI-Nutzungskontingent mit der Nutzung dieses Monats und dem Datum der Zurücksetzung, die Nutzung der Pentest-Sessions und Invoice History. Dein Profilmenü zeigt dieselben Anzeigen. Wo dein Release es enthält, ergänzt eine Seite Usage unter Settings eine Aufschlüsselung pro Aktion und einen Verlauf. Die Kontingente werden am 1. jedes Kalendermonats (UTC) zurückgesetzt. Eine Funktion außerhalb deines Plans zeigt einen Upgrade-Hinweis oder einen Dialog Request Priority Access. Was das Kontingent verbraucht und was passiert, wenn es aufgebraucht ist, erklärt Modul 7.

Bei Plexicus SaaS nimmt Plexicus in der Anwendung keine Zahlungen entgegen. Ein Admin klickt unter Billing auf Request a plan change, wählt den Plan und das Abrechnungsintervall, beschreibt die erwartete Nutzung und sendet die Anfrage ab. Eine Organisation kann jeweils nur eine offene Anfrage haben, die du unter Settings Billing Plan requests verfolgst.

Status	Bedeutung
Received	Plexicus hat deine Anfrage erhalten
In contact	Das Team bearbeitet sie gemeinsam mit dir
Offer sent	Ein Angebot liegt zur Prüfung bereit
Invoiced	Du hast das Angebot angenommen, und die Rechnung wurde ausgestellt
Paid	Die Rechnung wurde bezahlt
Plan applied	Dein neuer Plan ist aktiv
Rejected / Cancelled	Die Anfrage wurde geschlossen; du kannst eine neue senden

Deployment-Optionen für Plattformverantwortliche

Plexicus läuft als SaaS oder selbst gehostet; Air-gapped ist eine Variante von Self-hosted.

Option	Wo es läuft	Wer es betreibt
EU SaaS	Von Plexicus gehostet unter app.plexicus.ai; SaaS-Daten bleiben standardmäßig in der EU	Plexicus, inklusive Updates
Self-hosted	Dein Kubernetes-Cluster, on-premises oder in einem Cloud-Konto unter deiner Kontrolle, installiert mit dem Plexicus Helm Chart	Dein Team
Air-gapped (Variante von Self-hosted)	Die selbst gehostete Installation ohne ausgehende Internetverbindung	Dein Team

Während Wartungsarbeiten zeigt die App eine Seite System Under Maintenance oder, während eine neue Version ausgerollt wird, Upcoming Update System, und einige Funktionen sind womöglich kurz nicht verfügbar.

Self-hosted mit dem Helm Chart

Self-hosted und on-premises sind dasselbe: ein Chart und eine Lizenz. Du brauchst einen beliebigen CNCF-konformen Kubernetes-Cluster ab v1.25. Plexicus übergibt dir ein Lieferpaket mit Zugangsdaten für die Registry, deiner signierten Lizenz, einer Umgebungsdatei mit deiner Chart-Version und den KI-Einstellungen sowie, für die Produktion, einer Values-Datei, die bereits deine Domain enthält. Du stellst den Cluster bereit, eine Domain mit DNS-Einträgen für die App und den API-Host, einen Ingress Controller, TLS über cert-manager oder eigene Zertifikate, eine Storage Class, die Volumes beibehält, und idealerweise ein SMTP-Relay. Ohne E-Mail-Versand legst du bei der Installation fest, dass sie ohne E-Mail betrieben wird. Einladungen werden dann über den Admin abgewickelt: Die Antwort auf die Einladung liefert dem einladenden Admin einen Verifizierungslink, den er direkt weitergibt. Ohne E-Mail braucht außerdem das Anlegen des allerersten Admins einen zusätzlichen Einrichtungsschritt aus der Installationsanleitung.

Eine selbst gehostete Installation sendet keine Telemetrie aus deinem Cluster heraus. Nur die Integrationen, die du konfigurierst, kommunizieren mit externen Systemen, und Funktionen, die von kommerziellen Diensten von Plexicus abhängen, etwa die Abrechnung, sind deaktiviert.

Die Lizenz wird als Cluster-Secret installiert, bevor du den Chart installierst; ohne sie starten die Kerndienste nicht. Wenn die Lizenz bald abläuft (in 30 Tagen oder weniger), zeigt die Login-Seite „License expiring soon“. Nach dem Ablauf folgt eine Kulanzfrist, standardmäßig 14 Tage, und danach „License expired“: Der Zugriff ist dann eingeschränkt, bis du über deinen Account Manager verlängerst.

Air-gapped-Installationen

Air-gapped ist der Helm-Weg plus drei Änderungen: jedes Image in eine interne Registry spiegeln, den Chart auf diesen Mirror ausrichten und die öffentliche Zertifizierungsstelle durch deinen internen Aussteller ersetzen. Übertrage die Lizenzdatei über deinen normalen sicheren Prozess; Lizenzprüfungen funktionieren auch offline. Lass Integrationen, die das öffentliche Internet brauchen, unkonfiguriert, und gib der Plattform einen KI-Endpunkt, den sie erreichen kann, einschließlich eines Embeddings-Endpunkts, sonst kann Deep Code Analysis nicht laufen. Für ein Upgrade spiegelst du zuerst das neue Release und führst dann das Upgrade mit genau dieser Version aus.

GitOps

Wenn du bereits ArgoCD betreibst, kann es denselben Chart aus Git abgleichen, statt dass du ihn manuell per helm install installierst. Die Referenzmanifeste werden im Chart mitgeliefert. Pinne den Chart auf eine exakte Version, halte die Values in Git und committe nie Secrets im Klartext: Nutze Sealed Secrets, einen External Secrets Operator oder verschlüsselte Dateien.

Backup und Wiederherstellung

Der Plattformzustand liegt an drei Orten: in der Hauptdatenbank (Befunde, Benutzer, Repositories, Scan-Ergebnisse), in der Datenbank für den Workflow-Verlauf und im Object Storage (Scan-Artefakte, KI-Ein- und -Ausgaben, Berichte). Sichere alle drei gemeinsam, denn ein reines Datenbank-Backup kann auf Artefakte verweisen, die du nicht mehr hast.

Plexicus ist ein Workload auf deinem Cluster. Cluster-Bereitstellung, Host-Härtung, DNS, TLS-Vertrauen, Network Policies, Monitoring und Backups bleiben in deiner Verantwortung.

Das Wichtigste in Kürze

• Lade Personen über Settings Team ein, bevor sie sich selbst registrieren, gib ihnen die engste passende Rolle und mach mit Duplicate aus einer integrierten Rolle eine benutzerdefinierte.
• SSO unterstützt SAML 2.0 und OIDC über geführte Assistenten oder generische Einrichtungen. Wechsle von Coexist zu SSO Enforced erst nach einem Dry Run, der innerhalb der letzten 24 Stunden erfolgreich war, und lass JIT, Gruppen-Mappings und SCIM die Konten mit deinem Identity Provider synchron halten.
• Benutzer können eine Authenticator-App und einen Passkey hinzufügen; nutzt deine Organisation SSO, werden Passkeys stattdessen in deinem Identity Provider verwaltet.
• Das Audit-Log ist Admins vorbehalten, lässt sich nach Zeitraum, Actor, Aktion und Ressource filtern, schwärzt Felder mit Secrets und ist durch eine SHA-256-Hash-Kette geschützt, die du über die API prüfst.
• Die Organisationseinstellungen umfassen das Unternehmensprofil, Regulierungen, zwei getrennte Spracheinstellungen, den Eigentumsnachweis, BYOAI und Anfragen für Planwechsel; bei SaaS nimmt Plexicus in der Anwendung keine Zahlungen entgegen.
• Self-hosted betreibt dasselbe Produkt aus dem Helm Chart mit einer signierten Lizenz; Air-gapped ergänzt die Spiegelung und einen internen Aussteller, und jedes Upgrade beginnt mit einem Backup aller drei Datenspeicher.