Définissez les portées avant la création
N'accordez à une clé que les actions et les ressources nécessaires à sa tâche. Une intégration de supervision peut nécessiter un accès en lecture ; un outil de déploiement peut nécessiter un ensemble défini d'opérations de cycle de vie. Séparez autant que possible l'autorité de facturation.
Révélez avec prudence et conservez en lieu sûr
Une véritable clé doit être affichée via un flux de création sécurisé, protégée au repos et exclue des URL, des bundles navigateur et du contrôle de source. Enregistrez le propriétaire, l'objectif et l'heure de création sans exposer le secret lui-même.
Rendre la révocation praticable
Émettez des identifiants distincts par intégration afin de pouvoir en révoquer un sans tout interrompre. Effectuez les rotations de manière délibérée et vérifiez que l'ancienne clé ne fonctionne plus. Analysez toute utilisation inattendue à l'aide de journaux d'audit limités.
Testez les limites
Un test de lancement utile comprend une opération autorisée, une opération interdite, une clé expirée ou révoquée et une requête hors du périmètre de ressources de la clé. L'authentification seule ne constitue pas une autorisation.
Politique de clé candidate
Le contrat API décrit jusqu'à dix clés actives par compte, avec des objectifs nommés, une expiration facultative et des restrictions d'adresse source. Les portées séparent la lecture, la gestion serveur, la facturation et le contrôle total. Un flux de création doit afficher le secret une seule fois et ne conserver qu'une représentation de vérification protégée de manière appropriée.
Auditez sans exposer la requête
Un enregistrement d'audit utile peut inclure l'identifiant de clé, la route, l'heure et le résultat sans conserver les mots de passe ni les corps de requête complets. L'accès à l'enregistrement nécessite toujours une protection. Définissez la conservation et l'exportation plutôt que de conserver indéfiniment un historique opérationnel sensible.
Attribuez à chaque automatisation ses propres identifiants
Un vérificateur de sauvegardes, un agent de déploiement et une intégration de facturation ne doivent pas partager la même clé à accès complet. Nommez une clé selon sa fonction, accordez la portée la plus restreinte et consignez son propriétaire. Les groupes prévus sont lecture, serveurs, facturation et complet ; leur correspondance exacte avec les opérations doit être testée lorsque le API sera disponible.
Création, stockage et rotation
Le modèle de compte proposé autorise jusqu'à dix clés actives. Affichez un nouveau secret une seule fois, puis ne conservez que le vérificateur côté serveur nécessaire à son authentification. Stockez la copie client dans un gestionnaire de secrets ou un environnement de service protégé. Effectuez la rotation en introduisant un remplacement, en vérifiant le worker dépendant, puis en révoquant l'ancienne clé ; ne placez jamais une clé dans un URL public ou un bundle navigateur.
Révoquez l'accès, pas la preuve
La désactivation d'une clé doit arrêter les requêtes futures tout en conservant un historique de sécurité limité de son utilisation passée. Si un identifiant a pu fuiter, révoquez-le rapidement, examinez les ressources concernées et remplacez les secrets associés. Une liste de clés doit afficher un identifiant sûr et des métadonnées de dernière utilisation plutôt que des secrets en clair récupérables.
Un peu plus de clarté.
Cette page peut-elle créer une clé API fonctionnelle ?
Non. La création de clés nécessite un backend de compte authentifié ; cette page d'information ne délivre pas d'identifiants.