Definieer scopes vóór aanmaak
Geef een sleutel alleen de acties en resources die de taak vereist. Een monitoringintegratie kan leestoegang nodig hebben; een implementatietool kan een gedefinieerde set levenscyclusoperaties nodig hebben. Houd facturatiebevoegdheid waar mogelijk gescheiden.
Voorzichtig onthullen en privé opslaan
Een echte sleutel moet via een veilige aanmaakflow worden getoond, in rust worden beschermd en worden uitgesloten van URLs, browserbundels en versiebeheer. Leg de eigenaar, het doel en het aanmaaktijdstip vast zonder het geheim zelf bloot te leggen.
Maak intrekking praktisch
Geef afzonderlijke referenties per integratie uit, zodat één kan worden ingetrokken zonder alles stop te zetten. Roteer bewust en verifieer dat de oude sleutel niet meer werkt. Onderzoek onverwacht gebruik met begrensde auditrecords.
Test de limieten
Een nuttige lanceringstest omvat een toegestane bewerking, een verboden bewerking, een verlopen of ingetrokken sleutel en een verzoek buiten de resourcegrens van de sleutel. Authenticatie alleen is geen autorisatie.
Beleid voor kandidaatsleutels
Het API-contract beschrijft maximaal tien actieve sleutels per account, met benoemde doelen, optionele vervaldatum en beperkingen op bronadres. Scopes scheiden lezen, serverbeheer, facturering en volledige controle. Een aanmaakflow moet het geheim één keer tonen en alleen een passend beschermde verificatierepresentatie bewaren.
Audit zonder het verzoek bloot te leggen
Een bruikbaar auditrecord kan sleutelidentificatie, route, tijd en uitkomst bevatten zonder wachtwoorden of volledige verzoekbodies te bewaren. Toegang tot het record vereist nog steeds bescherming. Definieer bewaring en export in plaats van gevoelige operationele geschiedenis onbeperkt te bewaren.
Geef elke automatisering eigen inloggegevens
Een back-upcontrole, implementatieworker en factureringsintegratie mogen niet dezelfde volledige-toegangssleutel delen. Geef een sleutel een naam voor zijn taak, verleen de kleinste scope en leg vast wie eigenaar is. De bedoelde groepen zijn read, servers, billing en full; hun exacte bewerkingstoewijzing moet worden getest zodra de API beschikbaar komt.
Aanmaken, opslaan en roteren
Het voorgestelde accountmodel staat maximaal tien actieve sleutels toe. Toon een nieuw geheim één keer en bewaar daarna alleen de server-side verifier die nodig is om het te authenticeren. Bewaar de clientkopie in een secret manager of beschermde serviceomgeving. Roteer door een vervanger te introduceren, de afhankelijke worker te controleren en vervolgens de oude sleutel in te trekken; plaats nooit een sleutel in een openbare URL of browserbundel.
Trek de toegang in, niet het bewijs
Het uitschakelen van een sleutel moet toekomstige verzoeken stoppen en tegelijk een beperkt beveiligingsrecord van het eerdere gebruik bewaren. Als een inloggegeven mogelijk is uitgelekt, trek het dan snel in, onderzoek getroffen resources en vervang gerelateerde secrets. Een sleutellijst moet een veilige identificatie en metadata over het laatste gebruik tonen in plaats van herstelbare platte tekst secrets.
Een beetje meer duidelijkheid.
Kan deze pagina een werkende API-sleutel aanmaken?
Nee. Het aanmaken van sleutels vereist een geauthenticeerde accountbackend; deze informatiepagina geeft geen referenties uit.