Controlli di sicurezza progettati per SP-API e dati restricted.

Protezione di rete

• I database di produzione non sono esposti su internet pubblica. Sono raggiungibili solo dalla rete applicativa.
• L'accesso ai servizi interni è limitato tramite rete privata, security group e regole firewall.
• Solo le porte strettamente necessarie sono esposte all'esterno.
• Produzione, staging e sviluppo girano su ambienti separati con credenziali e dati separati.
• Gli endpoint pubblici sono protetti da rate limiting e controlli anti-abuso; un layer Web Application Firewall protegge gli ingressi HTTP.
• L'accesso amministrativo è limitato a operatori autorizzati su workstation hardenizzate e tramite canali sicuri.

Cifratura in transito

• Tutto il traffico HTTP è servito su HTTPS con certificati TLS validi.
• Le richieste HTTP vengono reindirizzate a HTTPS.
• HSTS è abilitato sugli host di produzione.
• La comunicazione interna service-to-service usa TLS o passa su rete privata.
• Le chiamate SP-API avvengono esclusivamente su HTTPS, secondo i requisiti di autenticazione e firma di Amazon.

Cifratura a riposo

• I volumi di storage di produzione sono cifrati a riposo.
• I campi sensibili (incluse informazioni Amazon di destinatario e spedizione) sono cifrati a livello applicativo con AES-256.
• Credenziali, token SP-API e segreti di integrazione sono conservati in un secret store gestito, non in chiaro nel database applicativo.
• Le chiavi di cifratura sono gestite da una facility di key management, con accesso ristretto e uso auditato.
• La rotazione delle chiavi avviene su cadenza documentata e in caso di sospetto compromesso.

Controllo accessi

• Ogni operatore e membro del team ha un account utente individuale; gli account condivisi non sono permessi.
• Il controllo accessi basato sui ruoli (RBAC) impone il principio del privilegio minimo.
• L'autenticazione multifattore è richiesta per tutti gli account amministrativi e per l'accesso ai sistemi che trattano Amazon Information.
• L'accesso ai sistemi di produzione viene revisionato periodicamente; viene revocato a fronte di cambio ruolo o cessazione.
• Tutti gli eventi di accesso sono loggati e revisionati.

Gestione credenziali & secret

• Nessun secret viene committato nei repository sorgente. I repository vengono scansionati per esposizioni accidentali.
• I secret vengono iniettati a runtime da variabili d'ambiente alimentate da un secret store gestito.
• Secret e token vengono ruotati su pianificazione definita e a fronte di sospetto compromesso.
• I secret sono mascherati nei log applicativi e nei report di errore.
• La policy password richiede lunghezza e complessità adeguate; il riutilizzo di password compromesse è bloccato dove il sistema sottostante lo permette.

Logging & monitoring

• Log applicativi e di sicurezza centralizzati, con eventi strutturati per auditabilità.
• Audit log degli accessi ai sistemi che trattano Amazon Information.
• Alert su autenticazioni sospette, modifiche di configurazione e pattern di accesso anomali.
• Revisione periodica dei log di sicurezza da parte del team operations.
• Retention dei log impostata per supportare le investigazioni; almeno 12 mesi per i log security-rilevanti.

Vulnerability management

• Scansione automatica delle dipendenze ad ogni build, con alert su vulnerabilità note.
• Analisi statica del codice sul branch principale e sulle pull request.
• Patching del sistema operativo e delle base image come parte del normale ciclo di build.
• Le vulnerabilità critiche vengono risolte entro 7 giorni; quelle ad alta severità entro 30 giorni, secondo timeline severity-based.
• Le modifiche vengono validate in staging prima del deploy in produzione.
• Le pull request richiedono code review prima del merge.

Incident response

• Procedura di incident response documentata: rilevamento, contenimento, analisi, recovery e post-mortem.
• Ruoli e responsabilità definiti per gli incidenti di sicurezza.
• Per gli incidenti che coinvolgono Amazon Information, FireFeed notifica Amazon entro 24 ore dalla rilevazione confermata, secondo la Data Protection Policy di Amazon.
• I seller e gli interessati sono notificati secondo gli obblighi applicabili.
• Ogni incidente è seguito da un post-mortem e da un set tracciato di azioni correttive.

Backup & restore

• Backup cifrati dei dati di produzione su pianificazione regolare.
• Integrità dei backup monitorata.
• Drill di restore eseguiti periodicamente per validare la procedura di recovery.
• RTO e RPO definiti e revisionati.