Bigyan ang bawat integration ng sarili nitong key.

Tukuyin ang mga saklaw bago lumikha

Bigyan ang isang key ng mga aksyon at resource lamang na kailangan ng trabaho nito. Ang isang monitoring integration ay maaaring mangailangan ng read access; ang isang deployment tool ay maaaring mangailangan ng tinukoy na set ng lifecycle operations. Panatilihing hiwalay ang billing authority kung posible.

Ibunyag nang maingat at itago nang pribado

Ang tunay na key ay dapat ipakita sa pamamagitan ng secure na creation flow, protektado habang naka-rest at hindi kasama sa mga URL, browser bundle at source control. Itala ang may-ari, layunin at oras ng paggawa nang hindi inilalantad ang mismong secret.

Gawing praktikal ang revocation

Magbigay ng hiwalay na kredensyal sa bawat integration upang ma-revoke ang isa nang hindi hinihinto ang lahat. Mag-rotate nang sinasadya at i-verify na hindi na gumagana ang lumang key. Imbestigahan ang hindi inaasahang paggamit gamit ang bounded audit records.

Subukan ang mga limitasyon

Kasama sa kapaki-pakinabang na launch test ang isang pinapayagang operasyon, isang ipinagbabawal na operasyon, isang nag-expire o na-revoke na key at isang request sa labas ng resource boundary ng key. Ang authentication lamang ay hindi awtorisasyon.

Patakaran sa candidate key

Inilalarawan ng kontratang API ang hanggang sampung aktibong key bawat account, na may mga pinangalanang layunin, opsyonal na expiry at mga paghihigpit sa source-address. Pinaghihiwalay ng mga scope ang read, server management, billing at full control. Ang isang creation flow ay dapat magpakita ng secret nang isang beses at panatilihin lamang ang isang angkop na protektadong verification representation.

Mag-audit nang hindi inilalantad ang kahilingan

Ang isang kapaki-pakinabang na audit record ay maaaring magsama ng key identifier, ruta, oras at kinalabasan nang hindi pinapanatili ang mga password o buong request body. Ang access sa record ay nangangailangan pa rin ng proteksyon. Tukuyin ang retention at export sa halip na panatilihin ang sensitibong operational history nang walang hanggan.

Bigyan ang bawat automation ng sarili nitong kredensyal

Ang backup checker, deployment worker at billing integration ay hindi dapat magbahagi ng parehong full-access key. Pangalanan ang isang key ayon sa trabaho nito, ibigay ang pinakamaliit na scope at itala kung sino ang may-ari nito. Ang mga inilaan na grupo ay read, servers, billing at full; ang eksaktong pagmamapa ng operasyon nito ay dapat subukan kapag naging available ang API.

Paglikha, pag-iimbak at pag-rotate

Ang iminungkahing account model ay nagpapahintulot ng hanggang sampung aktibong key. Ipakita ang isang bagong secret nang isang beses, pagkatapos ay panatilihin lamang ang server-side verifier na kailangan upang i-authenticate ito. Itago ang kopya ng client sa isang secret manager o protektadong service environment. Mag-rotate sa pamamagitan ng pagpapakilala ng kapalit, pagsuri sa dependent worker, pagkatapos ay pagbawi ng lumang key; huwag kailanman ilagay ang isang key sa isang pampublikong URL o browser bundle.

Bawiin ang access, hindi ang ebidensya

Ang pag-disable ng key ay dapat pumigil sa mga susunod na request habang pinapanatili ang limitadong security record ng nakaraang paggamit nito. Kung maaaring na-leak ang isang credential, agad itong i-revoke, suriin ang mga apektadong resource at palitan ang anumang kaugnay na secret. Dapat ipakita ng key list ang safe identifier at last-use metadata kaysa sa recoverable plaintext secrets.

Kaunting dagdag na kalinawan.