Autorisations et accès à l'API

Secani sépare l'identité, l'appartenance aux ressources et les capacités individuelles. L'accès est évalué au niveau de l'organisation, de l'espace de travail ou de la portée de la gouvernance, de sorte qu'une personne ou un agent connecté reçoit uniquement le contexte requis pour le travail qui lui est assigné. Une connexion large n’implique pas un accès étendu aux données.

Limites des autorisations

Les fonctionnalités utilisent des noms stables et spécifiques aux tâches, tels que evidence.read, evidence.create, risk.read, risk.write, oscal.read, et oscal.export. La lecture, la lecture sensible, l'écriture, l'approbation et l'administration sont des effets distincts plutôt qu'un seul indicateur d'accès polyvalent.

Moindre privilège de l'agent

Seules les capacités explicitement marquées comme attribuables à un agent peuvent être accordées à un enregistrement d'agent. La responsabilité humaine reste une frontière dure : les capacités d'approbation des preuves, d'acceptation des risques, de publication des résultats d'assurance, de gestion des autorisations, d'exécution d'opérations de confidentialité ou d'approbation de la propre proposition d'un agent ne sont pas attribuables à l'agent.

Démarrez une intégration avec des fonctionnalités en lecture seule dans la portée de gouvernance la plus étroite. Ajoutez des fonctionnalités de lecture ou d'écriture sensibles uniquement lorsque le flux de travail les nécessite. Conservez l'approbation avec un humain nommé, examinez les modifications proposées avant l'exécution et retirez l'accès une fois la tâche terminée.

API OSCAL publique

L'API publique de validation OSCAL dispose de deux modes d'accès :

1. Les demandes anonymes ne nécessitent aucun compte ni identifiant et reçoivent les limites tarifaires de base documentées.
2. Un facultatif sk_oscal_ La clé du porteur augmente les limites du taux de validation. Il a le rôle de clé API fixe oscal-validator et seulement le oscal.validate capacité.

Le rôle est renforcé par le type d'informations d'identification dédié plutôt que par un jeton de produit étendu. La présentation de la clé ne peut pas demander ou transmettre une autre fonctionnalité, et elle n'accorde pas l'accès aux organisations, aux espaces de travail, aux étendues de gouvernance, aux preuves ou à l'administration du produit.

Les administrateurs de l'organisation créent et révoquent les clés API OSCAL dans les paramètres de l'organisation. Chaque secret est affiché exactement une fois. Stockez-le dans un gestionnaire de secrets, envoyez-le uniquement dans le Authorization: Bearer en-tête, et faites-le pivoter ou révoquez-le s’il est exposé. Une clé invalide échoue avec 401 ERR_INVALID_API_KEY; il ne revient jamais silencieusement à un accès anonyme.

Authentification contre autorisation

Secani utilise WorkOS pour l'authentification des utilisateurs. L'authentification établit qui appelle ; Les contrôles d'adhésion et de capacité de Secani déterminent à quoi cette identité peut accéder. La portée de connexion actuelle identifie l'utilisateur et ne doit pas être interprétée comme une autorisation de lire ou de modifier chaque ressource Secani.

Chaque client doit gérer 401 comme une authentification manquante ou invalide et 403 comme authentifié mais autorisation insuffisante. Ne réessayez pas automatiquement l’une ou l’autre des réponses avec un accès plus large. Demandez à un administrateur le plus petit ensemble de capacités et la limite de ressources permettant la tâche prévue.

Voir le Guide API OSCAL, Récupération d'erreur API, et canonique Spécification OpenAPI.