Security & Data Governance.

Approccio basato sul rischio

STRAXA adotta misure proporzionate alla natura del servizio, ai dati trattati e ai rischi ragionevolmente prevedibili. La sicurezza viene gestita come processo continuo: progettazione, access control, logging, gestione dei segreti, monitoraggio, incident response e revisione delle dipendenze.

Isolamento logico dei clienti

I workspace costituiscono confini logici separati. Ove applicabile vengono utilizzate policy di Row Level Security, controlli server-side e verifiche di membership/ruolo per impedire accessi tra organizzazioni non autorizzate.

Least privilege

• account individuali e gestione dei ruoli;
• controlli di sessione e autorizzazione per operazioni sensibili;
• privilegi amministrativi limitati ai soggetti autorizzati;
• rimozione o riduzione degli accessi quando non più necessari;
• possibilità di introdurre controlli ulteriori, inclusi MFA/SSO, in funzione del piano e dell’evoluzione del prodotto.

Credenziali fuori dal client

Service role, chiavi API, token riservati e segreti sono gestiti lato server e non devono essere esposti volontariamente al browser. Le integrazioni compatibili utilizzano OAuth o meccanismi analoghi e richiedono gli scope necessari alla funzione. Password di provider terzi non vengono richieste quando esiste un flusso di autorizzazione ufficiale.

Site key pubblica, dati sensibili server-side

Il widget STRAXA Web utilizza una site key pubblica limitata che identifica l’installazione ma non concede accesso amministrativo al backend. Allowlist dominio, sessioni, rate limit, configurazioni sensibili e accesso ai dati restano governati lato server. Il go-live richiede controlli tecnici prima dell’attivazione production.

Guardrail sulle automazioni

Le azioni che possono incidere su campagne, budget o altri sistemi sono progettate con controlli di autorizzazione, audit e, ove previsto, approvazione umana. Per Meta Campaign Factory il modello operativo privilegia la creazione iniziale in stato PAUSED e una successiva attivazione controllata.

Tracciabilità

Eventi tecnici, amministrativi e di sicurezza possono essere registrati per diagnosi, accountability e ricostruzione delle operazioni. I log devono essere minimizzati rispetto alla finalità e non utilizzati come deposito indiscriminato di contenuti sensibili.

Controlli infrastrutturali

STRAXA si affida a infrastrutture cloud che mettono a disposizione cifratura in transito e misure di protezione a riposo secondo le relative configurazioni e documentazioni. Le garanzie effettive dipendono dal componente e dal provider; STRAXA non dichiara certificazioni o controlli che non siano propriamente acquisiti o verificati.

Continuità operativa

Backup e capacità di ripristino sono gestiti in funzione delle caratteristiche dei provider e del servizio. Le copie di backup sono soggette ai normali cicli tecnici e restano protette fino alla sovrascrittura o cancellazione. Le procedure vengono riesaminate all’aumentare della criticità del prodotto.

Dipendenze e segnalazioni

STRAXA monitora errori, dipendenze e vulnerabilità rilevanti e applica correzioni secondo priorità di rischio. Le segnalazioni responsabili possono essere inviate a info@straxa.it; si richiede di non includere dati di terzi, password o token nel primo contatto.

Rilevare, contenere, analizzare, ripristinare

Il processo di risposta a un incidente include, in funzione della gravità: identificazione, contenimento, conservazione delle evidenze pertinenti, analisi, mitigazione, ripristino e documentazione. Quando un incidente coinvolge Dati del Cliente trattati come responsabile, il Cliente viene informato senza ingiustificato ritardo secondo il DPA.

Necessità e riservatezza

L’accesso umano ai dati cliente deve essere limitato a necessità di supporto, sicurezza, manutenzione o obblighi legali, applicando il principio del minimo privilegio e obblighi di riservatezza. Ove appropriato, le operazioni amministrative rilevanti vengono tracciate.

Responsabilità condivisa

Le certificazioni o attestazioni di un provider non si trasferiscono automaticamente a STRAXA. La sicurezza finale dipende anche da configurazioni, ruoli, integrazioni, permessi e pratiche del Cliente. STRAXA valuta i fornitori materialmente rilevanti e mantiene un registro pubblico della filiera.

Sicurezza condivisa

• proteggere credenziali e dispositivi;
• assegnare ruoli appropriati;
• revocare account e integrazioni non più necessari;
• non inserire segreti nei prompt o in campi non destinati a contenerli;
• verificare gli Output prima di azioni ad alto impatto;
• mantenere sicuro il proprio sito quando installa STRAXA Web.

Nessuna dichiarazione non verificata

STRAXA non dichiara certificazioni ISO, SOC 2 o altre attestazioni proprie salvo che siano state effettivamente ottenute e pubblicate. Le misure descritte in questa pagina rappresentano il modello operativo corrente e non costituiscono una certificazione formale.

Segnalazioni

Per vulnerabilità, sospette esposizioni o incidenti: info@straxa.it. Specificare oggetto, impatto potenziale e modalità di riproduzione senza sfruttare la vulnerabilità oltre quanto necessario alla dimostrazione.

Dati identificativi

Russo Giovanni Battista · Ditta individuale

• Sede legale: Via Monte Carso 8, 81025 Marcianise (CE), Italia
• Sede operativa: Via Misericordia 32, 81025 Marcianise (CE), Italia
• Partita IVA: 04232450611
• Email e contatto privacy: info@straxa.it

Accesso, rettifica, cancellazione e chiarimenti

Per esercitare i diritti privacy o chiedere informazioni sul trattamento scrivere a info@straxa.it. Per proteggere l’account, STRAXA può richiedere le sole informazioni necessarie a verificare l’identità del richiedente.