Kopexa

Personen

Personen im Space – Import, Verwaltung und verknüpfte Accounts (Entra, Figma, GitHub u. a.)

Du möchtest einer Person Zugang zu Kopexa geben?

Das geht hier nicht. Personen sind Einträge im Inventar, anmelden können sie sich damit nicht. Benutzer lädst du in den Organisationseinstellungen unter Organisation → Mitglieder ein und ordnest ihnen dabei gleich die Spaces zu. Wie das geht, steht unter Benutzer und Zugriff.

Personen repräsentieren Menschen im Kontext eines Space – z. B. Mitarbeitende, Werkvertragskräfte oder Partner.
Sie sind kein Asset-Typ, sondern eine eigene Entität innerhalb des Inventory-Kontexts, mit Fokus auf Identitäten, Accounts, Onboarding und Policy-Beziehungen.

Scope: Personen gehören zum Space (siehe Spaces).
Zentrale SSO-Domains verwaltest du auf Organisation-Ebene (siehe Domains).


Was kann ich mit Personen machen?

  • Import & Sync von Personen aus externen Quellen (z. B. Microsoft Entra ID).
  • Verknüpfte Accounts pflegen (z. B. Figma, GitHub, weitere Business-Apps).
  • Onboarding-Aufgaben zuweisen (z. B. Richtlinien lesen, Agent installieren).
  • Policy-Acknowledgements und Nachweise (Nachweis) dokumentieren.
  • Zuweisungen/Beziehungen zu Assets, Lieferanten, Risiken, Kontrollen und Aufgaben herstellen.

Navigation:

  • Personen im Space: /s/{space_id}/people

Import & Synchronisation

  • Entra (Azure AD): Personen können über den Entra-Connector importiert werden.
    Typische Datenpunkte: Name, E-Mail, Abteilung/Gruppe, Status.
  • Manuelle Pflege: Ergänzungen/Korrekturen direkt in Kopexa.
  • Konfliktbehandlung: Beim Import werden vorhandene Einträge anhand stabiler Identifikatoren abgeglichen, um Duplikate zu vermeiden.

Hinweis: Die Anmeldung per SSO richtet sich nach der Domain-Konfiguration der Organisation, siehe Domains.


Accounts (verknüpfte Dienste)

Jede Person kann mehrere Accounts besitzen, z. B.:

  • Entra Account (primäre Identität/Directory)
  • Figma Account (Design)
  • GitHub Account (Engineering)
  • Weitere SaaS-/Line-of-Business-Accounts

Ziele der Account-Verwaltung:

  • Transparenz: Wer hat wo Zugriff?
  • Rezertifizierung: Regelmäßige Prüfungen, ob Zugriffe noch erforderlich sind.
  • Compliance-Nachweise: Dokumentation von Entzug/Änderung (Nachweis).

Best Practice: Lege eindeutige externe IDs (z. B. figma_user_id, github_username) ab, um Audits und Entzug zu vereinfachen.


Status & Lifecycle

Typische Personen- und Account-Status:

Lifecycle-Ereignisse (Beispiele):

  • Onboarding: Aufgabenpaket (Richtlinien lesen, Tools, MFA-Hinweise)
  • Role/Team-Wechsel: Zugriffe anpassen, Policy-Re-acknowledgement
  • Offboarding: Zugriffe entziehen, Geräte/Accounts überführen, Nachweis erstellen

Beziehungen zu anderen Modulen

  • Assets: Zuweisung von Geräten/Applikationen/Services an Personen; relevante Verantwortlichkeiten und Eintritt/Austritt.
  • Lieferanten: Personen als Kontaktrollen; Zuordnung in Assessments oder Due-Diligence-Prozessen.
  • Risiken: Personenbezogene Risiken (z. B. übermäßige Rechte) dokumentieren und Maßnahmen ableiten.
  • Kataloge & Kontrollen: Zuweisung von Kontrollen (z. B. Rezertifizierungs-Intervalle, Least-Privilege).
  • Dokumente & Nachweis: Policy-Acknowledgements, Schulungsnachweise, Offboarding-Nachweise.
  • Aufgaben & Board: Aufgaben aus On-/Offboarding, Rezertifizierungen, Audit-Findings.

Berechtigungen (ReBAC)

Zugriffe werden über ReBAC mit OpenFGA gesteuert (siehe Security):

  • Sichtbarkeit und Bearbeitung von Personen hängt von Beziehungen (z. B. Space-Mitgliedschaft, Rolle) ab.
  • Feingranulare Regeln möglich, z. B.: „HR-Rolle darf Personendaten sehen/bearbeiten, aber keine technischen Accounts löschen.“

Sicherheit & Datenschutz

  • Datenminimierung: Speichere nur, was für Governance/Compliance erforderlich ist.
  • Trennung pro Space: Personendaten sind Space-isoliert.
  • Verschlüsselung & Backups: Siehe Security (SSE-OMK, 2-stündliche Backups, 30 d + 30 d Glacier).
  • Protokollierung: Relevante Änderungen (z. B. Account-Entzug) werden auditiert.

Best Practices

  • Primäre Identität festlegen: Entra (oder zentraler IdP) als „Source of Truth“.
  • Kontinuierliche Rezertifizierung: Regelmäßig prüfen, ob Accounts & Rollen noch nötig sind.
  • Automatisierung nutzen: On-/Offboarding-Tasks standardisieren; Nachweise automatisch erfassen.
  • Trennung beachten: SSO-/Domains auf Org-Ebene verwalten, Personen-Operationen im Space halten.
  • Least Privilege: Nur notwendige Informationen/Operationen pro Rolle freigeben.