Definér omfang før oprettelse
Giv kun en nøgle de handlinger og ressourcer, som dens opgave kræver. En overvågningsintegration kan have brug for læseadgang; et deployment-værktøj kan have brug for et defineret sæt livscyklushandlinger. Hold faktureringsmyndighed adskilt, hvor det er muligt.
Afslør forsigtigt, og opbevar privat
En rigtig nøgle bør vises gennem en sikker oprettelsesproces, beskyttes i hvile og udelukkes fra URLer, browserbundter og kildekodekontrol. Registrer ejeren, formålet og oprettelsestidspunktet uden at afsløre selve hemmeligheden.
Gør tilbagekaldelse praktisk
Udsted separate legitimationsoplysninger pr. integration, så én kan tilbagekaldes uden at stoppe alt. Rotér bevidst, og bekræft, at den gamle nøgle ikke længere virker. Undersøg uventet brug med afgrænsede revisionsposter.
Test grænserne
En nyttig lanceringstest omfatter en tilladt handling, en forbudt handling, en udløbet eller tilbagekaldt nøgle og en forespørgsel uden for nøglens ressourcegrænse. Godkendelse alene er ikke autorisation.
Politik for kandidatnøgler
API-kontrakten beskriver op til ti aktive nøgler pr. konto med navngivne formål, valgfri udløb og begrænsninger på kildeadresse. Scopes adskiller læsning, serveradministration, fakturering og fuld kontrol. En oprettelsesproces bør vise hemmeligheden én gang og kun bevare en passende beskyttet verifikationsrepræsentation.
Revidér uden at afsløre forespørgslen
En brugbar revisionslog kan indeholde nøgleidentifikator, rute, tid og resultat uden at opbevare adgangskoder eller hele request-bodies. Adgang til loggen kræver stadig beskyttelse. Definer opbevaring og eksport i stedet for at opbevare følsom driftshistorik på ubestemt tid.
Giv hver automatisering sin egen legitimationsoplysning
En backup-kontrollør, en udrulningsworker og en faktureringsintegration bør ikke dele den samme nøgle med fuld adgang. Navngiv en nøgle efter dens opgave, tildel den mindst mulige scope, og registrer, hvem der ejer den. De tilsigtede grupper er læsning, servere, fakturering og fuld; deres præcise operationstilknytning skal testes, når API bliver tilgængelig.
Oprettelse, lagring og rotation
Den foreslåede kontomodel tillader op til ti aktive nøgler. Vis en ny hemmelighed én gang, og bevar derefter kun den server-side verifikator, der er nødvendig for at autentificere den. Opbevar klientkopien i en hemmelighedsmanager eller et beskyttet service-miljø. Rotér ved at indføre en erstatning, kontrollere den afhængige worker og derefter tilbagekalde den gamle nøgle; anbring aldrig en nøgle i en offentlig URL eller browserbundle.
Tilbagekald adgangen, ikke beviset
Deaktivering af en nøgle bør stoppe fremtidige anmodninger, mens en begrænset sikkerhedsregistrering af dens tidligere brug bevares. Hvis en legitimationsoplysning kan være lækket, skal den tilbagekaldes hurtigt, påvirkede ressourcer undersøges, og relaterede hemmeligheder udskiftes. En nøgleliste bør vise en sikker identifikator og metadata om sidste brug frem for gendannelige klarteksthemmeligheder.
Lidt mere klarhed.
Kan denne side oprette en fungerende API-nøgle?
Nej. Oprettelse af nøgler kræver en autentificeret konto-backend; denne informationsside udsteder ikke legitimationsoplysninger.