Nessun utente secondario non autorizzato
Vendora non chiede al cliente di creare credenziali condivise o utenti secondari fuori processo.
Sicurezza
Autorizzazione sicura, senza password condivise.
Vendora non richiede mai credenziali Seller Central o Vendor Central. L'accesso avviene tramite OAuth 2.0, SP Central o inviti autorizzati dal Partner Amazon.
OAuth 2.0
Website Authorization Workflow.
La Redirect URI pubblica è https://vendoraint.com/sp-api/auth/.
1
Avvio autorizzazione
Il venditore sceglie di autorizzare Vendora. Il backend genera un parametro state univoco, temporaneo e non prevedibile.
2
Header anti-CSRF
Le pagine esterne sono servite con Referrer-Policy: no-referrer per ridurre il rischio di leakage di parametri sensibili.
3
Consenso Amazon
Il venditore viene indirizzato all'URL regionale di consenso Seller Central o Vendor Central con application ID, state e redirect URI registrata.
4
Callback e verifica
Amazon reindirizza alla Redirect URI. Vendora verifica la corrispondenza dello state; in caso di mismatch la procedura è interrotta.
5
Scambio server-to-server
Il codice autorizzativo viene scambiato con token LWA tramite richiesta POST server-side. Il refresh token è cifrato tramite KMS e mai scritto in chiaro nei log.
SP Central
Flusso Authorize Partners.
Invito verificabile
Il cliente avvia l'invito da Seller Central, Vendora accetta il link SP Central entro la finestra prevista e il cliente conferma l'autorizzazione.
Permessi minimi
Richiediamo solo ruoli necessari al servizio sottoscritto. I privilegi sono riesaminati almeno trimestralmente.
Audit trail
Gli accessi sono tracciati in log centralizzati, protetti da alterazioni e conservati per almeno 12 mesi.
Controlli DPP
Misure dichiarate e auditabili.
Questi controlli devono essere coerenti con l'infrastruttura reale prima della pubblicazione in produzione.
| Ambito | Standard | Implementazione |
|---|---|---|
| Cifratura in transito | TLS 1.2+; TLS 1.3 raccomandato | HTTPS obbligatorio; HTTP e protocolli insicuri disabilitati |
| Cifratura a riposo | AES-256 / RSA-2048+ | Database, backup, secret e token protetti con KMS |
| Gestione accessi | MFA, privilegio minimo | ID univoci, no account condivisi, review trimestrale, offboarding 24h |
| Retention | PII 30 giorni; non-PII 18 mesi | Eliminazione sicura secondo NIST SP 800-88 |
| Vulnerability | Critiche 7 giorni; alto rischio 30 giorni | Scanning, patching, pen-test e backup geodistribuiti |