Berechtigungen und API-Zugriff
Least-Privilege in Secani über Organisationen, Workspaces, Governance Scopes, Agenten und OSCAL-API-Schlüssel.
Secani trennt Identität, Ressourcenmitgliedschaft und einzelne Fähigkeiten. Zugriff wird an der Grenze von Organisation, Workspace oder Governance Scope ausgewertet. Eine Anmeldung allein bedeutet daher keinen umfassenden Datenzugriff.
Berechtigungsgrenzen
| Grenze | Typische Inhalte | Effekte |
|---|---|---|
| Organisation | Mitglieder, Rollen, Einstellungen, Catalogs, API-Schlüssel | Lesen, sensibles Lesen, Schreiben, Administration |
| Workspace | Integrationen, Importe, Exporte, Scopes | Lesen, Schreiben, sensibles Lesen, Administration |
| Governance Scope | Controls, Nachweise, Risiken, Pflichten, Assessments, OSCAL | Lesen, sensibles Lesen, Schreiben, Freigabe, Administration |
Fähigkeiten tragen stabile, aufgabenbezogene Namen wie evidence.read, evidence.create, risk.read, risk.write, oscal.read und oscal.export. Lesen, sensibles Lesen, Schreiben, Freigaben und Administration sind getrennte Effekte.
Least-Privilege für Agenten
Nur ausdrücklich dafür freigegebene Fähigkeiten können einer Agentenregistrierung zugewiesen werden. Freigaben und Administration mit menschlicher Verantwortung bleiben eine harte Grenze. Dazu zählen unter anderem Nachweisfreigaben, Risikoakzeptanz, Veröffentlichung von Assurance-Ergebnissen, Berechtigungsverwaltung, Datenschutzoperationen und die Freigabe eigener Agentenvorschläge.
Beginne mit reinen Leserechten am kleinsten passenden Governance Scope. Ergänze sensibles Lesen oder Schreiben nur, wenn der konkrete Ablauf es benötigt. Freigaben bleiben bei einer benannten Person und Rechte werden nach Abschluss der Aufgabe entzogen.
Öffentliche OSCAL-API
Anonyme Requests benötigen weder Konto noch Zugangsdaten und erhalten die dokumentierten Basislimits. Ein optionaler sk_oscal_-Bearer-Schlüssel erhöht ausschließlich die Validierungs-Limits. Er gewährt keinen Zugriff auf Organisationen, Workspaces, Governance Scopes, Nachweise oder Administration.
Organisationsadministratoren erstellen und widerrufen OSCAL-API-Schlüssel in den Organisationseinstellungen. Das Geheimnis wird genau einmal angezeigt, gehört in einen Secret Manager und wird ausschließlich im Authorization: Bearer-Header gesendet. Ein ungültiger Schlüssel liefert 401 ERR_INVALID_API_KEY und fällt nicht auf anonymen Zugriff zurück.
Authentifizierung und Autorisierung
WorkOS stellt die Identität fest. Secani-Mitgliedschaften und Capability-Prüfungen entscheiden anschließend, auf welche Ressourcen diese Identität zugreifen darf. Clients behandeln 401 als fehlende oder ungültige Authentifizierung und 403 als unzureichende Autorisierung. Sie dürfen Zugriffsrechte nicht automatisch erweitern, sondern sollen das kleinste passende Profil bei einem Administrator anfragen.
Siehe OSCAL-API, Fehlerbehebung und OpenAPI-Spezifikation.