Bemásolja a weclapp- vagy Shopify-API-tokenjét a ChatGPT-be?

A csábító rövidítés

Általában így kezdődik: „Itt a weclapp-API-tokenem, kérlek, kérd le a nyitott rendeléseimet.” Vagy egy Shopify Admin API-token kerül egy egyedi GPT-be, egy böngészőbővítménybe vagy egy no-code automatizálásba. Az MI ír néhány sor kódot, megjelennek az adatok, és az egész varázslatnak tűnik.

Érdemes azonban megállni egy pillanatra, mert az API-token nem egy riport megtekintésére szolgáló jelszó. Olyan kulcs, amely az Ön nevében jár el, gyakran adminisztrátori jogokkal, egészen addig, amíg érvényes.

Mi történik valójában a bemásolt tokennel?

Amint a token bekerül egy beszélgetésbe, a beszélgetés része lesz. A gyakorlatban ez a következőket jelenti:

• A csevegési előzményekben marad. Bárki, aki most vagy később megnyithatja a beszélgetést, kimásolhatja. Ide tartoznak a megosztott linkek, a csapat-munkaterületek és a szinkronizált eszközök is.
• Az MI-szolgáltató feldolgozza. Előfizetéstől és beállításoktól függően a beszélgetéseket megőrizhetik, vagy a modellek fejlesztésére is felhasználhatják. A tokent ugyanúgy kezelik, mint bármely más szöveget.
• Az MI megismételheti. Egy modell, amely látta a tokent, beleírhatja a generált kódba, összefoglalókba vagy válaszokba, amelyeket Ön aztán továbbít egy kollégának vagy egy külsős szakembernek.
• A token tulajdonosának teljes jogaival rendelkezik. A weclapp-tokenek annak a felhasználónak a nevében járnak el, aki létrehozta őket. A Shopify Admin API-tokenek az alkalmazásuk összes hatókörével bírnak, ami kiterjedhet az ügyfelekre, rendelésekre és visszatérítésekre is.
• Nehéz visszavonni. A biztonság kedvéért új tokent kell létrehozni, minden helyen frissíteni, ahol a régit használták, majd visszavonni a régit. A legtöbben ezt soha nem teszik meg.

Az üzleti kockázat közérthetően

Gondoljon az API-tokenre úgy, mint valamelyik üzleti rendszerének főkulcsára. Ha bemásolja egy beszélgetésbe, az olyan, mintha egy segítőkész vállalkozónak adná oda a kulcsot, és megengedné, hogy korlátlan ideig megtartson belőle egy másolatot.

A kockázatok nem egzotikus hackerforgatókönyvek. Hétköznapi üzleti helyzetekről van szó:

• Egy kolléga távozik a cégtől, de a kulcsot tartalmazó régi beszélgetés továbbra is megvan neki.
• Egy gyors kérdés miatt megosztanak egy beszélgetéslinket, és a kulcs is vele megy.
• Az MI „segítőkészen” lefuttat egy frissítést a tokennel, és 200 árat módosít, mert a kérés nem volt egyértelmű. Előtte senki sem ellenőrizte.
• Egy auditor vagy ügyfél megkérdezi, ki fért hozzá az ügyféladatokhoz, és Ön nem tud válaszolni.

A GDPR szerint az ügyféladatokhoz való ellenőrizetlen hozzáférés megfelelőségi kérdés is, nem csupán informatikai.

Biztonságosabb megoldás: a kulcs széfbe kerüljön, ne a beszélgetésbe

A biztonságos megoldás egyszerűen leírható:

1. A kulcs egyszer kerül egy védett tárolóba: egy adminisztrátor adja meg egy kifejezetten titkos adatokra szolgáló mezőben.
2. Az MI soha nem kapja meg a kulcsot. Egy megbízható szolgáltatást kér meg a kérés elküldésére, és ez a szolgáltatás teszi hozzá a hitelesítő adatokat.
3. Minden kérést ellenőriz a rendszer aszerint, hogy a kérést indító személy mit tehet meg.
4. A módosításokból javaslatok lesznek, amelyeket egy felelős személy hagy jóvá, mielőtt végrehajtanák őket.
5. A hozzáférést személyenként kezelik, így ha valaki távozik, nincs szükség új kulcsra.

Hogyan alkalmazza ezt a Steward?

A Steward pontosan erre a megközelítésre épül a weclapp, a Shopify és az ASA HOTEL esetében:

• Védett mezők, titkosított tárolás. A hitelesítő adatokat egyszer kell megadni a Beállítások → Kapcsolatok oldalon. A rendszer titkosítva tárolja őket, és soha többé nem jeleníti meg, még annak sem, aki megadta őket.
• Nincsenek hitelesítő adatok az MI kódjában. Amikor a Steward MI-je kódot ír az adatai elemzéséhez, ez a kód elszigetelt környezetben fut, az Ön hitelesítő adatai nélkül. Az üzleti eszközeihez intézett kérések a Stewardon keresztül mennek, amely hozzáadja a hitelesítő adatokat és érvényesíti a jogosultságokat.
• Projektszerepkörök. A Megtekintők követhetik az eredményeket, a Közreműködők használhatják a beállított kapcsolatokat és módosításokat készíthetnek elő, a Projektmenedzserek pedig jóváhagyhatnak. A meghívott projekttagoknak nem kell külön kapcsolati hozzáférés.
• Áttekintés a módosítások előtt. Az alapértelmezett Jóváhagyás kérése mód minden módosításból javaslatot készít. A jóváhagyási szabályok a kiválasztott műveleteknél kötelezővé teszik az ellenőrzést.
• Shopify hosszú élettartamú tokenek nélkül. A Shopify esetében a Steward a saját alkalmazásának Client ID-ját és titkos kulcsát javasolja. A Steward ezeket rövid élettartamú hozzáférési tokenekre cseréli.
• Közös, visszakövethető előzmények. A kérdések, javaslatok, jóváhagyások és eredmények a csapat projektjében maradnak.

Bemásolt token kontra Steward

	Beszélgetésbe másolt token	Steward-kapcsolat
Hol van a kulcs?	A csevegési előzményekben, akár megosztva	Titkosítva, soha nem jelenik meg
Látja az MI?	Igen	Nem
Kinek a jogai érvényesek?	A token tulajdonosáé, korlátozás nélkül	Személyenként és projektenként szűkítve
Módosítás előtt	Általában semmi	Alapértelmezés szerint javaslat és jóváhagyás
Ha valaki távozik	Mindenhol cserélni kell a tokent	Elég megszüntetni a hozzáférését
Ki mit tett?	Nehezen rekonstruálható	Közös előzmények jóváhagyásokkal

Már bemásolt egy tokent? Rövid ellenőrzőlista

1. Hozzon létre új tokent a weclappban (személyes beállítások), vagy cserélje le az alkalmazás hitelesítő adatait a Shopifyban.
2. Vonja vissza a régit, amint már semmi sem függ tőle.
3. Törölje a tokent tartalmazó beszélgetéseket, a megosztott linkekkel együtt.
4. Ellenőrizze a legutóbbi módosításokat a rendszerben, nincs-e köztük váratlan.
5. Csatlakoztassa megfelelően a rendszert, például a Stewardban, hogy többé senkinek ne legyen szüksége a nyers tokenre.

Első lépések

Olvassa el, miért választják a csapatok a Stewardot egy saját üzemeltetésű weclapp MCP-szerver helyett, vagy csatlakoztassa az első eszközét, és tegye fel az első kérdését Csak olvasás módban.