Panoramica sulla sicurezza

Prynt legge dati aziendali dai tuoi database per produrre documenti, quindi la sicurezza fa parte del progetto, non è un'opzione. Questa pagina riassume come la piattaforma protegge i tuoi dati, i tuoi account e i tuoi database. I dettagli di ogni area sono nelle pagine collegate.

Principi#

• I tuoi database restano privati. Il Gateway si collega in uscita dalla tua rete; nessuna porta in ingresso viene aperta.
• Sempre in sola lettura. Le query girano in transazioni in sola lettura dopo un controllo che rifiuta tutto ciò che non è una lettura. L'API accetta codici di template e parametri, mai SQL.
• Le credenziali si scrivono soltanto. Le password dei database non vengono mai più mostrate; con un gateway sono cifrate per lui nel tuo browser e Prynt non può leggerle.
• Privilegio minimo. I ruoli limitano ciò che ogni persona può fare, gli scope limitano ciò che ogni chiave API può fare.
• Tutto ciò che conta viene registrato in un registro attività in sola aggiunta.

Hosting e cifratura in transito#

• Prynt è un servizio gestito ospitato nell'Unione Europea.
• L'applicazione, l'API e questo sito sono serviti solo in HTTPS, con HTTP Strict Transport Security (un anno, sottodomini compresi).
• Le connessioni dirette ai database devono usare TLS (vedi connessioni dirette); i gateway si collegano in HTTPS e WebSocket sicuri.

Isolamento tra tenant#

I clienti sono organizzazioni; un'organizzazione ha uno o più workspace, ognuno con i propri template, sorgenti dati, chiavi API, webhook ed esecuzioni. L'isolamento è garantito due volte:

• dall'applicazione, che limita ogni query al workspace della richiesta;
• dal database, con la Row-Level Security di PostgreSQL sulle tabelle dei contenuti dei workspace (template e versioni, dataset, asset, query condivise, sorgenti dati e connessioni, chiavi API, webhook, esecuzioni e job di generazione). Una connessione senza contesto di tenant non vede alcuna riga.

Una chiave API appartiene a un solo workspace e non può mai leggere template o sorgenti dati di un altro workspace.

Ruoli e permessi#

Ogni membro ha un ruolo nell'organizzazione. I ruoli sono cumulativi: ognuno ha tutti i permessi dei ruoli sotto di lui. Nessuno può assegnare, cambiare o agire su un ruolo superiore al proprio, e la proprietà si trasferisce, non si assegna.

viewerruolo

Vede template e versioni, ne guarda l'anteprima e vede solo le proprie esecuzioni. templates.read

designerruolo

Cambia la grafica dei template con il catalogo campi: testi, loghi, colori, caratteri, campi e condizioni semplici; gestisce gli asset. Non vede mai SQL, sorgenti dati o connessioni e non pubblica: chiede la pubblicazione a chi approva. + templates.write, assets.manage

developerruolo

Gestisce dati e integrazione: sorgenti dati e gateway, SQL, dataset, query condivise, pubblicazione, chiavi API, webhook, tutte le esecuzioni, registro attività e utilizzo. + datasources.read, datasources.manage, sql.execute, datasets.manage, shared_queries.manage, templates.publish, apikeys.manage, webhooks.manage, runs.read, audit.read, usage.read

adminruolo

Gestisce anche membri e inviti, i workspace, le loro impostazioni e i loro ambienti. + org.members.manage, workspace.manage

ownerruolo

Esattamente uno per organizzazione: anche le sue impostazioni, l'eliminazione e il trasferimento della proprietà. + org.manage

data_partnerruolo

La tua software house, fuori dalla scala dei ruoli: dati e collegamenti dei workspace che le concedi, nient'altro. Può chiedere la pubblicazione, mai pubblicare. templates.read, templates.write, datasources.read, datasources.manage, sql.execute, datasets.manage, shared_queries.manage

• Un workspace può dare a un developer, designer o viewer un ruolo diverso solo in quel workspace. Owner e admin mantengono il proprio ruolo ovunque.
• La matrice è visibile nell'applicazione in Ruoli; i comandi che non puoi usare sono nascosti o disattivati, e l'API li rifiuta comunque.
• I membri sospesi conservano ruolo e storico ma non possono accedere a nulla finché non vengono riattivati.
• L'API genera solo versioni pubblicate. Le modifiche di un designer arrivano in produzione solo quando un membro che può pubblicare approva la sua richiesta di pubblicazione (un workspace può limitare chi approva ad alcuni ruoli); richieste e decisioni finiscono nel registro attività. Vedi Richieste di pubblicazione.

La tua software house (data partner)#

Invita la software house che conosce il tuo gestionale da Impostazioni dell'organizzazione → Membri → Invita la tua software house: riceve il ruolo data_partner e prepara una volta sola i dati dei tuoi modelli (collegamenti, query di sola lettura, catalogo campi, mappatura, elenchi di documenti), così le tue persone cambiano solo la grafica.

• Apre solo i workspace che scegli; gli altri per lei non esistono. Dai o togli l'accesso nelle impostazioni di ogni workspace.
• Non vede mai i tuoi membri, la fatturazione, la licenza, le impostazioni, le chiavi API o il registro attività, e non può pubblicare: può solo chiedere la pubblicazione, che approvi tu. Il ruolo si dà solo con un invito, mai cambiando il ruolo di un membro.
• Impostazioni dell'organizzazione → Software house elenca tutto quello che le sue persone hanno fatto nella tua organizzazione, compresi gli accessi ai dati (sorgente, righe, esito; mai i valori), anche dopo che le hai rimosse.
• Una software house può avere una propria organizzazione Prynt, abilitata come partner da Prynt: vede l'elenco dei suoi clienti (solo i nomi) e tiene cataloghi per gestionale che copia nei modelli di ogni cliente. Niente di un cliente arriva mai al partner o a un altro cliente.

Sei una software house? Leggi Prynt per le software house; per le aziende c'è Prynt per le aziende.

Account, 2FA e sessioni#

Password

• Almeno 10 caratteri, senza regole di composizione; sono rifiutate le password comuni o compromesse, quelle uguali alla tua email e quelle ripetitive o sequenziali, e così le tue ultime 5 password.
• Le password sono conservate come hash PBKDF2-HMAC-SHA512 con salt (100.000 iterazioni).
• L'indirizzo email va verificato prima del primo accesso. Dopo 10 accessi falliti l'account viene bloccato per 15 minuti.

Autenticazione a due fattori

• Attiva l'autenticazione a due fattori nelle impostazioni di sicurezza del tuo account con qualsiasi app di autenticazione (TOTP, 6 cifre). Ricevi 10 codici di recupero monouso, mostrati una sola volta.
• Puoi far ricordare un dispositivo per 30 giorni, e dimenticare i dispositivi ricordati in qualsiasi momento.
• Owner e admin possono richiedere l'autenticazione a due fattori a tutti i membri dell'organizzazione (Dati e privacy). Le chiavi API non sono interessate.

Sessioni

• Una sessione termina dopo 12 ore di inattività e comunque dopo 24 ore; se scegli di restare connesso all'accesso (opzione attiva come predefinita) dura fino a 30 giorni (7 giorni di inattività). Il cookie di sessione è HttpOnly, Secure e SameSite=Lax.
• Il tuo account elenca le sessioni aperte: chiudine una, oppure tutte tranne quella corrente. Cambiare la password chiude le altre sessioni; reimpostarla le chiude tutte.

L'accesso usa email e password (con l'autenticazione a due fattori quando è attiva); il single sign-on non è ancora disponibile.

Chiavi API#

• Le chiavi vengono mostrate una sola volta; Prynt ne conserva solo lo SHA-256 e confronta in tempo costante. Il prefisso visibile (prynt_live_… o prynt_test_…) identifica una chiave negli elenchi, nei log e negli scanner di segreti.
• Scope (render, templates.read, datasets.execute…), una scadenza facoltativa e la revoca immediata. Le chiavi test non possono mai usare un ambiente di produzione.
• Ogni chiave ha un limite di frequenza (600 richieste al minuto come predefinito).

Dettagli in Autenticazione.

Accesso ai tuoi database#

• Ogni query viene controllata prima dell'esecuzione (una sola istruzione che inizia con SELECT, WITH, VALUES o TABLE; niente INSERT, UPDATE, DELETE, MERGE, TRUNCATE, INTO o FOR UPDATE), poi gira in una transazione in sola lettura che viene sempre annullata.
• Le query hanno timeout e limiti di righe e di dimensione; i parametri sono sempre passati come bind, mai concatenati nell'SQL.
• I gateway ripetono il controllo di sola lettura e applicano limiti propri, ed eseguono solo richieste firmate da Prynt.
• Le connessioni dirette sono controllate rispetto alle reti private e riservate a ogni connessione, con TLS obbligatorio.
• Prynt avvisa quando un utente del database può scrivere o ha privilegi di amministrazione, e ti dà lo script per un utente in sola lettura.
• I designer non ricevono mai SQL. Gli elenchi di documenti reali che scelgono nell'anteprima eseguono sul server una query di ricerca memorizzata, in sola lettura e registrata; solo chi ha il permesso sql.execute può scriverla.

Vedi Sorgenti dati, Gateway e Connessioni dirette.

Segreti a riposo#

• Le password dei database delle connessioni dirette, i segreti di firma dei webhook e le chiavi dell'autenticazione a due fattori sono cifrati con envelope encryption: AES-256-GCM con una chiave dati per organizzazione, a sua volta protetta da una master key (o da una chiave in Azure Key Vault, che non lascia mai il vault). Ogni valore è legato alla sua organizzazione, al suo record e al suo scopo.
• Le credenziali per un gateway sono sigillate nel tuo browser con la chiave pubblica del gateway (ECDH P-256, HKDF-SHA256, AES-256-GCM): Prynt conserva una busta che non può aprire.
• Sessioni, chiavi API, codici di recupero e token di registrazione sono conservati solo come hash.

Registro attività#

Il Registro attività dell'organizzazione (permesso audit.read: developer, admin e owner) registra chi ha fatto cosa e quando: membri, ruoli e inviti, workspace e ambienti, template (pubblicati, rollback…), asset, query condivise, sorgenti dati, connessioni e gateway, SQL eseguito nel Designer, chiavi API, webhook, impostazioni di sicurezza, esportazioni ed eliminazioni. Ogni voce riporta chi ha agito (utente o chiave API), la risorsa, l'indirizzo IP e il correlation ID. Le voci sono in sola aggiunta: il database rifiuta di modificarle o eliminarle.

Privacy e strumenti GDPR#

• I tuoi dati: Account → Privacy scarica una copia dei tuoi dati personali (profilo, appartenenze, sessioni, stato dell'autenticazione a due fattori, le tue attività) ed elimina il tuo account. I contenuti che hai creato restano nei loro workspace senza il tuo nome; le voci del registro attività restano ma anonimizzate.
• I dati dell'organizzazione: l'owner può esportare tutto (membri, workspace, template con ogni versione, asset, query condivise, impostazioni delle sorgenti dati, esecuzioni, registro attività, utilizzo) in uno ZIP. Password, chiavi e segreti non sono mai inclusi; il link per scaricarlo vale 7 giorni.
• Eliminare un'organizzazione: l'accesso termina subito; tutto viene cancellato definitivamente dopo un periodo di tolleranza di 30 giorni, durante il quale l'owner può ripristinarla.
• I documenti generati non sono un archivio: i documenti conservati scadono (24 ore come predefinito), e i valori dei parametri contrassegnati come riservati restano fuori dal log delle esecuzioni.

Segnalare una vulnerabilità#

Se pensi di aver trovato una vulnerabilità di sicurezza in Prynt, contattaci in privato, con i passi per riprodurla, e lasciaci un tempo ragionevole per correggerla prima di renderla pubblica. Non accedere a dati che non sono tuoi e non degradare il servizio durante le prove.