Audit des permissions d'app Shopify POD en 8 étapes

Une intégration Shopify POD crée au moins trois frontières: l'utilisateur humain dans Shopify, l'app de fulfillment installée et l'utilisateur humain dans le compte fournisseur. Un contractor peut être limité dans Shopify tout en voyant des commandes chez le fournisseur; une app peut lire ou modifier des données sans qu'un staff ouvre l'écran. Auditez chaque couche séparément.

1. Créer l'inventaire en trois couches

Listez Shopify users, collaborators, fulfillment apps, automations, provider users, agencies et identités partagées. Créez une ligne par actor, system, store et role; notez owner, purpose, last use, source screen, role name, linked store, decision, rollback owner et next review. Ajoutez l'intégration comme non-human actor et excluez noms clients, adresses, mots de passe, tokens, payment data et captures non masquées.

Séparer les identités

2. Transformer les titres en tâches

Le job title ne définit pas l'accès requis. Réécrivez chaque devoir: ce role doit faire une action sur un objet dans un système pour un store et ne doit pas faire une action adjacente. Séparez publishing, file editing, order review, production approval, returns et billing. Un accès temporaire exige start/end date, trigger, expiration owner et evidence afin qu'une exception ne devienne pas un rôle large permanent.

3. Revoir les permissions Shopify

Revoyez le Shopify role séparément du provider role. Signalez customer profiles/exports, personal-data requests, finance ou payment settings, app install/development et user/role management. Certains workflows demandent des permissions combinées: testez la tâche réelle après modification. Les activity logs aident à corréler le temps, mais sont limités et peuvent afficher app, channel, system ou Shopify plutôt qu'un humain.

4. Revoir données et activité de l'app

Ouvrez la page d'information de la third-party app et notez access areas, view/edit, recent activity, unused access, privacy categories, developer policy, billing et compatibility. Reliez chaque zone à order import, product sync, file publishing, tracking, shipping profiles ou returns. Unused access est un signal d'enquête, pas une autorisation automatique de révocation. Documentez reauthorization prompt, requested change, reason, approver et post-test.

5. Revoir les rôles fournisseur

Revoyez provider users, roles, assigned stores et features visibles. La documentation Printful actuelle, par exemple, sépare Admin/Owner, Admin, Manager et Designer pour orders, returns, templates, files, stores, billing, statistics, warehouse, settings, branding et memberships. C'est un exemple actuel, pas une matrice universelle. Utilisez l'écran du fournisseur et testez cross-store drift.

6. Réduire un rôle sans risque

Choisissez une réduction peu ambiguë: dormant contractor, designer avec unused order access ou user affecté à un store non lié. Gardez current role, redacted screenshots, active tasks, expected allowed/denied action, change owner, rollback owner et support path. Changez un role ou store assignment sans supprimer l'identity. Revenez en arrière si la tâche acceptée disparaît, si un autre store apparaît ou si les orders changent.

7. Lancer tests positifs et négatifs

Exécutez une tâche représentative permise et trois negative cases: unassigned store, sensitive area et adjacent task exclue. Utilisez des records sûrs et ne montrez pas de customer data réel au mauvais rôle. Vérifiez ensuite le downstream Shopify ou buyer-visible state. Un save fournisseur qui n'atteint pas le bon connected product n'est pas une acceptation complète, même si le role setting est enregistré.

8. Répéter après changement

Répétez selon la fréquence de changement de l'équipe et de l'intégration. Rouvrez après hiring, contractor completion, app install, reauthorization, provider migration, store acquisition, republish, billing-owner change, incident ou unexpected activity. Clôturez seulement avec actor, system, store, role, required/prohibited task, positive/negative result, downstream evidence, owner, rollback point et next review.

Matrice role-to-task

Checklist d'accès

1. Lister Shopify users
2. Lister fulfillment apps
3. Lister provider users
4. Ajouter non-human actors
5. Nommer owners
6. Noter task
7. Réécrire role en action
8. Ajouter negative boundary
9. Signaler accès temporaire
10. Signaler customer data
11. Signaler finance
12. Signaler app management
13. Revoir app areas
14. Revoir view/edit
15. Revoir recent activity
16. Enquêter unused access
17. Revoir privacy categories
18. Revoir provider matrix
19. Vérifier stores
20. Choisir réduction
21. Sauver rollback packet
22. Éviter destructive tests
23. Lancer tâche permise
24. Tester unassigned store

FAQ — Questions d'accès Shopify POD

Chaque contractor a-t-il besoin de Shopify ?

Non. Partez de la tâche; si le provider role suffit, Shopify peut élargir inutilement le scope.

Faut-il révoquer unused access ?

Pas automatiquement. Vérifiez workflows saisonniers, documentation et planifiez un changement réversible.

Peut-on copier les rôles entre fournisseurs ?

Non. Les limites diffèrent; traduisez la tâche et testez le compte actuel.

Un test prouve-t-il compliance ?

Non. Il prouve seulement la tâche et la frontière négative enregistrées à ce moment.

Quand refaire l'audit ?

Selon une cadence et après changements de staff, app, role, store, provider, reauthorization ou activité étrange.

Prochaine étape — tester un rôle

Choisissez une app et un provider user, écrivez la task sentence, réduisez un accès et clôturez après une tâche permise et trois chemins refusés corrects.

Cadre général d'opérations ecommerce, pas conseil juridique, privacy, cybersécurité, compliance, emploi, finance, fiscalité ou platform policy. Rôles, scopes, logs, interfaces, plans et behavior changent. Vérifiez les documents officiels et protégez customer data.