Inilunsad ng Turnkey ang Managed Secrets para sa Pag-access ng mga Ahente ng AI sa mga Kredensyal

Ang Turnkey ay naglunsad ng Managed Secrets, na nagpapalawak sa imprastraktura nito ng mga wallet na nakabatay sa enclave upang saklawin ang mga API key, password, detalye ng pagbabayad at impormasyong kailangan sa pagbawi na kailangan ng mga application at ahente ng AI para gumana. Inililipat ng anunsyo noong Oktubre 29 ang kumpanya lampas sa pamamahala ng mga pribadong susi at tungo sa mas malawak na suliranin: kung paano bibigyan ng kapangyarihan ang software na kumilos nang hindi ikinakalat sa buong imprastraktura nito ang mga kredensyal na maaaring gamitin nang paulit-ulit.

Nagbibigay-daan ang produkto sa mga team na magtakda kung aling serbisyo ang maaaring kumuha ng kredensyal at kung kailangan ng kahilingan nito ng pag-apruba ng tao o ng maraming partido. Para sa mga pinansyal na application, maaaring mangahulugan ito ng pagbibigay ng exchange API key sa awtorisadong backend para sa pangangalakal, habang hindi ito inilalantad sa usapan ng isang assistant na AI o sa kapaligiran nitong ginagamit sa pagpapatakbo.

Paglilipat ng Pag-access sa mga Kredensyal sa Likod ng Hangganan ng Enclave

Maginhawang gamitin ng software ang mga kredensyal na nakaimbak sa mga variable ng kapaligiran o file ng configuration, ngunit maaaring malantad ang laman ng mga ito kapag nakompromiso ang prosesong bumabasa sa mga iyon. Maaaring pagsama-samahin ng vault ang imbakan at mga kontrol sa pag-access; ang natitirang tanong ay kung saan nagiging nababasa ang isang kredensyal at kung aling mga sistema ang kailangang pagkatiwalaan sa puntong iyon.

Isinasagawa ng Managed Secrets ang mga pagsusuri sa awtorisasyon sa loob ng mga ligtas na enclave ng Turnkey. Ine-encrypt ng kliyente ang isang lihim bago ito i-import, at muli itong ine-encrypt ng enclave para sa pag-iimbak. Kapag may dumating na kahilingan, sinusuri ng enclave ang mga naaangkop na patakaran at pag-apruba bago i-encrypt ang resulta gamit ang susi ng nilalayong tatanggap. Maaaring magkaibang serbisyo ang humihiling at ang tatanggap.

Mahalaga ang paghihiwalay na ito. Maaaring simulan ng isang application ang gawain at mangalap ng mga pag-apruba nang hindi nagkakaroon ng kakayahang i-decrypt ang kredensyal na gagamitin para matapos ito. Pinahihintulutan ng lagda ng nag-apruba ang pagpapalabas nito; hindi nito awtomatikong ipinagkakaloob ang pag-access sa inilabas na lihim.

Ang Kriptograpiyang Ginagamit sa Pag-import at Pag-export

Inilalarawan sa dokumentasyon ng secure channel ng Turnkey ang isang protocol na nakabatay sa Hybrid Public Key Encryption, o HPKE. Pinagsasama nito ang pagtatatag ng susi gamit ang pampublikong susi at ang naka-authenticate na encryption upang maipadala ang sensitibong impormasyon bilang ciphertext sa pamamagitan ng mga tagapamagitan na sistema. Bineberipika ng kliyente sa pag-import ang materyal ng susi na nilagdaan ng enclave, samantalang ini-encrypt naman sa pag-export ang datos gamit ang pampublikong susi na ibinigay sa nilagdaang kahilingan.

Nilalayong gamitin nang isang beses lamang ang mga susi ng tatanggap. Ayon sa Turnkey, kailangang sundin mismo ng mga kliyente ang tuntuning ito: hindi mapipigilan ng protocol ang isang depektibong kliyente na muling gamitin ang target na susi nito. Dahil dito, bahagi ng modelo ng seguridad ang implementasyon ng kliyente, kasama ng enclave.

Tinutukoy sa pahina ng produkto ng Managed Secrets ang AES-256-GCM encryption para sa bawat lihim habang nakaimbak ito. Sinusuportahan ng API nito ang mga indibidwal na kredensyal gayundin ang mga kahilingan para sa maraming lihim. Nabibigo ang buong batch export kapag walang awtorisasyon para sa alinman sa mga hiniling na lihim, kaya napipigilan ang pagpapalabas ng bundle na bahagya lamang ang pag-apruba.

Bakit Mahalaga Pa Rin ang Tatanggap

Inilalarawan ng pariralang “maaaring gumamit ng mga kredensyal ang mga ahente nang hindi nakikita ang mga ito” ang isang padron ng integrasyon, hindi isang garantiya na hindi kailanman makababasa ng plaintext ang bawat prosesong tumatanggap nito. Tahasang sinasabi sa dokumentasyon para sa mga developer ng Turnkey na maaaring umiral ang plaintext sa loob ng enclave at sa kliyenteng nag-i-import o nag-e-export ng isang lihim.

Kung hawak ng hiwalay na serbisyo sa pagpapatakbo ang susi ng tatanggap, maaari nitong i-decrypt at gamitin ang isang kredensyal habang inililihim ito sa modelo. Kung hawak naman ng sariling runtime ng ahente ang susi, maaari itong i-decrypt ng runtime na iyon. Kaya kailangan pa ring protektahan ang tatanggap, ang memorya nito at ang mga log nito.

May ikalawang hangganan: maaaring suriin ng mga patakaran ang konteksto ng kahilingan, gaya ng idineklarang domain ng pag-checkout, ngunit hindi hiwalay na bineberipika ng Turnkey kung totoo ang pahayag na iyon. Itinatakda ng nilagdaang pahayag kung sino ang nagpahayag nito. Kailangan pa rin ng mga application ng mapagkakatiwalaang pagsusuring nag-uugnay sa pahayag na iyon at sa aktuwal na operasyon.

Mga Pag-aprubang Nakaaangkop sa Nagbabagong Daloy ng Trabaho

Maaaring pahintulutan ng mga team ang direktang pagkuha, hilingin ang pag-apruba ng isang tao sa kahilingan, o mangailangan ng pagsang-ayon ng maraming papel ng ahente. Maaaring baguhin ang mga patakaran nang hindi muling ini-import ang pinagbabatayang lihim, kaya maaaring magsimula ang isang daloy ng trabaho sa mahigpit na pangangasiwa at sa kalaunan ay i-automate ang mga piling kahilingan.

Ipinakikita sa gabay ng Turnkey para sa programmable na pag-access ang isang ahente ng browser at isang ahente ng pagbabayad na kapwa lumalagda sa isang kahilingan. Ang ahente lamang ng pagbabayad ang tumatanggap ng mga detalye ng card na maaari nitong i-decrypt. Bago mag-apruba, tinitingnan ng bahagi ng browser kung tumutugma ang iminungkahing domain sa pahinang ginagamit nito. Ipinakikita ng halimbawang ito kung bakit mas mahalaga ang magkakahiwalay na papel at pagpapatunay kaysa sa basta pagbibilang ng dalawang pag-apruba.

Maaaring gumamit ang mga papel ng ahente ng mga kredensyal ng session na may limitadong saklaw at takdang pag-expire, kaya nabibigyan ang mga operator ng paraan upang bawiin ang access ng isang tumatakbong instance. Gayunman, hindi mabubura ng pagbawi sa access sa hinaharap ang lihim na na-decrypt na ng isang tatanggap; nananatiling hiwalay na kontrol sa pagpapatakbo ang pagpapalit ng mga kredensyal sa mga susunod na sistema.

Mula sa Imprastraktura ng mga Wallet Tungo sa Awtomasyong Pinansyal

Ginagamit ng kasalukuyang arkitektura ng seguridad ng Turnkey ang AWS Nitro Enclaves at pinagsasama ang paghihiwalay sa antas ng hardware, mga build na maaaring muling likhain, at malayuang pagpapatunay. Dahil maaaring muling likhain ang mga build, naihahambing ang mga build ng software; samantala, nagbibigay ang pagpapatunay ng ebidensiya tungkol sa code ng enclave na tumatakbo. Pinalalawak ng Managed Secrets ang pundasyong ito upang masaklaw ang mga kredensyal bukod sa mga susi sa pagpirma ng blockchain.

Tinutukoy ng kumpanya bilang mga nilalayong gagamit nito ang mga kompanya ng kalakalan, mga backend ng fintech, mga developer ng AI agent, at mga tagapag-ingat ng MPC. Nagbibigay-daan ang mga kredensyal para sa palitan at mga token ng OAuth sa patuloy na pag-access sa serbisyo; tumutulong naman ang mga backup ng keyshare at mga susi sa pagbawi upang mapanatili ang katatagan. Magkakaibang gamit ang mga ito na may magkakaibang kinakailangan sa pag-apruba at tatanggap, kahit iisa ang imprastraktura ng imbakan na ginagamit ng mga ito.

Para sa mga pangkat sa teknolohiyang pampinansyal, mahalaga rito ang mas malinaw na paghahati sa paghiling ng isang pagkilos, pagpapahintulot sa pag-access, at pagtanggap ng kredensyal na magagamit. Nagbibigay ang Managed Secrets ng imprastraktura para maisagawa ang paghahating ito. Nakadepende ang proteksiyong makakamit sa mahihigpit na patakaran, maaasahang mga tagapag-apruba, at isang serbisyong mahusay na napoprotektahan at siyang gagamit sa lihim.