SLA è l'acronimo di Service Level Agreement, uno strumento contrattuale con il quale si definiscono le metriche di servizio che devono essere rispettate dal fornitore di servizi (Cloud Provider) nei confronti dei propri clienti.
Nello specifico lo SLA inerente il contratto di servizi offerti da CoreTech si riferisce:
Negli schemi riportati si può distinguere la differenza esistente tra i sistemi IaaS e quelli SaaS e le differenti responsabilità in capo a CoreTech quale cloud provider e in capo al cliente.
Per i servizi IaaS, CoreTech gestisce ed è responsabile di: Network, Storage, Servers e Virtualizzazione. Il cliente è invece responsabile di: Sistema Operativo e tutto quanto sopra questo installato.
Per i servizi SaaS, CoreTech gestisce ed è responsabile di tutto lo stack, dal Network all'Applicativo. Il cliente è invece responsabile dei propri dati e della sicurezza inerente la custodia degli stessi e dei parametri di autenticazione al servizio.
Per sua natura i servizi SaaS avendo N livelli aggiuntivi rispetto ai servizi IaaS, sono soggetti a potenziali maggiori disservizi dovuti alle componenti sovrastanti l'architettura, quali sistema operativo e applicativi installati.
Per tali ragioni gli SLA di servizi inerenti IaaS sono generalmente superiori a quelli relativi ai servizi SaaS.
I seguenti SLA servono allo scopo di dare indicazioni sui livelli di servizio che possono avere i sistemi ospitati nel cloud CoreTech. I server ospitati nel cloud CoreTech godono della stessa infrastruttura di rete, hardware e software dei sistemi dei quali sono riportati i livelli di servizio di cui alla presente pagina.
La gestione, la cura, il monitoraggio e la tempestività nella gestione dei server dei clienti rimane a carico del cliente e non di CoreTech, salvo diversamente concordato attraverso appositi servizi opzionali.
Pertanto CoreTech con la pubblicazione dei seguenti livelli di servizio garantisce che l'infrastruttura di rete è in grado di mantenere alti livelli di SLA e quindi minimi disservizi, ma non garantisce che il server di ogni cliente possa avere i medesimi SLA, in quanto è solo a cura del cliente la gestione dei server per problematiche che esulano dall'architettura cloud CoreTech.
Ottobre | Ultimi 60 giorni |
99,986% | 99,951% |
Migliore | Peggiore |
99,998% | 99,888% |
Ottobre | Ultimi 60 giorni |
99,975% | 99,869% |
Migliore | Peggiore |
99,993% | 99,759% |
Le sonde di monitoraggio sono locate presso altro data center su rete esterna.
Il monitoraggio dei sistemi indicati nell'esempio avviene costantemente ogni 60 secondi.
Gli SLA indicati sono calcolati dalla media degli SLA dei singoli server per ogni sistema preso in considerazione.
Per gli SLA indicati non sono stati dedotti i tempi di irraggiungibilità dei servizi dovuti ad attività pianificate, come riavvi dei sistemi operativi o aggiornamenti dei software. Le sonde di monitoraggio si riferiscono all'accesso HTTP/HTTPS e non al semplice PING del sistema (che ne determina solo la raggiungibilità).
Significa periodi di uno o più minuti di disservizio.
Minuti parziali o disservizio intermittenti per un periodo minore di un minuto non vengono conteggiati come disservizi.
Non si considera disservizio, le sospensioni, assistenze tecniche e manutenzioni come da contratto art 16 e art 34.
Le manutenzioni sono indicate preventivamente sulla pagina System Status
Significa numero di minuti totali in un mese, meno il numero di minuti totali di disservizio in un mese, diviso il numero totale di minuti in un mese.
I Disservizi sono calcolati su base mensile.
Esempio:
Calcolare UpTime:
Uptime | Downtime per mese |
100% | 0m |
99.999% | 0.4m |
99.99% | 4m |
99.9% | 43m |
99.8% | 1h 26m |
99.7% | 2h 10m |
99.6% | 2h 53m |
99.5% | 3h 36m |
99.4% | 4h 19m |
99.3% | 5h 2m |
99.2% | 5h 46m |
99.1% | 6h 29m |
99.0% | 7h 12m |
In caso di disservizio oltre i termini degli SLA garantiti in un mese, il cliente ha diritto a credito di servizio quale unica ed esclusiva forma di rimborso. Il cliente non può unilateralmente interrompere il pagamento dei corrispettivi mensili applicabili al servizio oggetto di reclamo per disservizio.
Il credito di servizio verrà erogato sotto forma di credito monetario applicato al futuro uso dei servizi cloud e applicato nei 60 giorni successivi all'accettazione della richiesta di rimborso.
Per ricevere qualsiasi richiesta di rimborso inerente l'evento imprevisto, il cliente dovrà avvertire CoreTech attraverso l'apertura di un ticket al Supporto Tecnico entro 7 giorni dal rilevamento dell'evento. Contestualmente all'apertura delle segnalazione al supporto, il cliente dovrà fornire i file di log del server dai quali si possa verificare la perdita di connettività verso l'esterno con data e ora in cui si sono verificati tali errori, comprese a titolo esemplificativo la descrizione dettagliata del problema rilevato, il numero e gli utenti interessati al problema (se applicabile), la descrizione dei tentativi effettuati per risolvere l'evento imprevisto quando si è verificato.
Se queste informazioni non verranno fornite, il cliente rinuncia al diritto di ricevere un credito di rimborso.
Per quanto riguarda un reclamo relativo ai servizi Cloud, CoreTech valuterà tutte le informazioni ragionevolmente in suo possesso quali registri e log dei propri sistemi, report dei sistemi di monitoraggio o altre informazioni. Al termine delle verifiche, entro e non oltre 20 giorni, determinerà in buona fede se al cliente spetta un Credito di Servizio.
Qualora la società abbia acquistato un servizio da un partner rivenditore, il Credito di Servizio dovrà riceverlo direttamente dal rivenditore e il rivenditore riceverà il credito direttamente da CoreTech.
IaaS | |
<99,95% (21m 54s) = 10% | |
<99,85% (1h 5m 44s) = 20% | |
<99,00% (7h 18m 17s) = 50% | |
SaaS | |
<99,8% (1h 26m) = 10% | |
<99,5% (3h 36m) = 20% | |
<99,00% (7h 18m 17s) = 50% | |
Esempio:
SLA <99,95%
Ovvero oltre i 21 minuti di disservizio
Credito di Rimborso 10% del servizio = a 10 Euro
Riconoscere il 10% del valore di servizio come rimborso significa riconoscere al cliente un multiplo del valore del tempo di down del servizio stesso ad esempio 10 Euro corrispondono a 4329 minuti di servizio. Quindi un cliente che ha un disservizio di 23 minuti, quindi 1 minuto in più di quanto previsto dal livello minimo di SLA (99,95%), riceverà un credito corrispondente a 4329 volte il prezzo pagato per il servizio al minuto.
Versione 3 del 09/05/2024
Descrizione | |
Servizio di cloud backup remoto
Link |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti.
In riferimento alla conformità e sicurezza dei dati, CoreTech e il cliente sono entrambi responsabili anche se su fronti diversi. Link |
|
Responsabilità CoreTech | |
Controllo giornaliero dello stato dei server e degli storage 1Backup. Mantenere i sistemi aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore.
Tenere sotto monitoraggio i server per garantire la continuità di servizio. |
|
Responsabilità Cliente | |
Controllare giornalmente l'esito dei backup.Configurare adeguatamente i job di backup e relative retention secondo le proprie esigenze. Effettuare una prova di restore almeno con frequenza mensile/bimestrale.
Impostare delle password di accesso al servizio complesse. Custodire con cura i dati di accesso degli agenti di Backup e limitarne la divulgazione. Custodire con cura la password di cifratura dei dati se diversa da quella usata per l’agente di Backup. Informare tempestivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti il servizio. |
|
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server.
Link |
|
Locazione geografica | Unione europea |
Etichettatura | |
Il software non offre livelli standard di classificazione delle informazioni. Il cliente può comunque apporre etichette ed, eventualmente, un livello di classificazione, tramite il nome macchina o creare gruppo idoneo per privacy. | |
Funzionalità presenti sul Pannello di Controllo | |
1Backup ha 2 pannelli di controllo utilizzabili. Uno Dedicato e uno su Sygma. Il cliente è autonomo fino alla chiusura del suo account Amministrativo associata all'istanza (account Reseller). La cancellazione dell'agente non comporta disdetta del servizio. Una volta richiesta la Cancellazione dell'agente arriva mail con tracciatura. | |
Pannello Admin | L'utente può scegliere gli algoritmi e la lughezza delle chiavi di cifratura del backup. L'utente può scegliere su quali dati eseguire il backup, schedularne la frequenza e destinazione. L'utente è autonomo nell'impostare le proprie politiche di Retention. La password dell'utente Admin e degli agent devono rispettare criteri mimini di sicurezza. Presenta il numero ed esito dei backup, numero ed esito dei restore, modifiche e cancellazione backup set e dati. |
SLA | |
SLA Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 24 ore di anticipo (salvo urgenze inerenti a problemi di sicurezza che richiedano un nostro intervento immediato) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% per maggiori informazioni visitare il sito https://www.coretech.it/it/service/systemStatus/SLA_servizi.php |
|
Backup | |
Il servizio viene offerto con 1 storage replicato (Backup Set) Il Backup Set viene replicato su Cloud Storage S3 - situato in un DataCenter fuori dall'italia in un paese dell'Unione Europea. L'utente è autonomo nell'impostare le proprie politiche di retention e di verificarne esito attraverso il monitoraggio. |
|
Tolleranza ai Problemi | |
Server Multipli |
I server che erogano il servizio di 1Backup sono differenti. Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici. Il cliente dovrebbe premunirsi di allocare gli agenti di Backup su server differenti. I Server di Backup godono dell’infrastruttura Stellar. Sito Stellar |
Configurazione Storage Raid6 | La configurazione dischi dello storage di destinazione dei backup è in RAID6. Lo storage su cui risiedono i backup dei dati ha doppio alimentatore e doppie connettività di rete. La controller dei dischi è doppia. |
Disaster Recovery | Backup set su altro Datacenter in modalità S3 |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Disponibili e interfaccia web o apposito client software.
Il cliente è l’unico a possedere le password di accesso alle caselle di archiviazione. CoreTech non può accedere ai dati in quanto sono cifrati. |
|
Cancellazione/Chiusura Contratto | |
L'utente è autonomo nella cancellazione dei propri dati. Se non cancellati, CoreTech provvederà alla loro cancellazione dopo 30 giorni dalla disdetta del servizio. Per richiedere Disdetta servizio, bisogna inviare via pec coretech@pec.coretech.it entro 30 gg dal rinnovo automatico del servizio. |
|
Portabilità | |
I dati si possono esportare solo mediante Restore a carico del cliente. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it, in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it. | |
Link Manuale Utilizzo | |
Pagina supporto - Link
Pagina prodotto - Link |
|
FAQ | |
Faq - Link
Termini e condizioni - Link |
|
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) Link |
|
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Con pannello admin si stabiliscono in autonomia gli utenti che possono accedere, le autorizzazioni e i metodi di autenticazione (inclusa lunghezza e complessità delle password). |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma). CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione cambia la password al primo utilizzo. |
Serve quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). Per gli utenti Sygma: - in caso di creazione dell'utenza, il cambio della password è obbligatorio; per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Si |
Bloccare l’utenza |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Si |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali). | Si |
Disabilitazione delle userid di default. | Si |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali. | Si, Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. |
Controllo automatico delle caratteristiche delle password; p.e. password non nel dizionario | Si, Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). |
Disponibilità di strumenti di MFA. | Disponibile a discrezione dell'amministratore. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Si |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | No |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Meccanismi Crittografici | L'algoritmo usato per crittografare i file è l'AES a 256-bit. Le comunicazioni con il server 1Backup sono su SSL a 128-bit. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS. I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di prestazioni accettabili | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. | I server sono suddivisi in cluster per ottimizzare le prestazioni. Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi: - modifiche reversibili, che quindi non richiedono conferma; - richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); - richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); - richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | N/A |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). | Sì. Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | In carico ai clienti |
Modalità di cancellazione dei dati | I backup sono cifrati. |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Archiviazione della posta elettronica in cloud. Il software genera copie 1:1 di tutte le email in un archivio centrale e garantisce la disponibilità a lungo termine di una grande quantità di dati per fornire assistenza nella conformità alle normative. Pagina Prodotto |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub. Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti.
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Link |
|
Responsabilità CoreTech |
Controllo giornaliero dello stato dei server e degli storage di Mail Archive.
Mantenere i sistemi aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore. Tenere sotto monitoraggio i server per garantire la continuità di servizio. Controllo giornaliero dei Backup per garantire integrità dei dati. |
Responsabilità Cliente |
Controllare l'esito dell'archiviazione in base alle esigenze o tempistiche impostate. Configurare adeguatamente i job di archiviazione. Effettuare una prova di restore almeno con frequenza mensile/bimestrale.
Impostare delle password di accesso al servizio complesse. Custodire con cura i dati di accesso alle caselle di archivio e limitarne la divulgazione. Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti il servizio. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server.
Link | |
Locazione geografica | Unione europea |
Etichettatura | |
È possibile etichettare i dati trattati su Mail Archive quando si crea archiviazione della casella di posta e si imposta un nome profico per quell'archivio. nominadolo come più utile. |
|
Funzionalità presenti sul Pannello di Controllo: | |
Interfaccia da Sygma o Client Admin sul server o pc stesso. Pieno controllo tramite la dashboard del App. Visualizzazione completa su Sygma. Customer portal permette di far visualizzare al cliente. Autonomia fino alla chiusura del suo account Master o istanza associata al partner. Dove è necessaria richiesta di disdetta servizio. Cancellazione del profilo di archiviazione - arriva mail di richiesta cancellazione a Commerciale che procede manualmente. |
|
Pannello Admin |
- Con pannello admin si stabiliscono in autonomia gli utenti che possono accedere ai profili di archiviazione, le autorizzazioni e i metodi di autenticazione (già presente lunghezza e complessità delle password). - a Password dell'utente Admin e gli agent devono rispettare criteri mimini di sicurezza |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 24 ore di anticipo. (salvo urgenze inerenti a problemi di sicurezza che richiedano un nostro intervento immediato) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% per maggiori informazioni visitare il sito https://www.coretech.it/it/service/systemStatus/SLA_servizi.php |
|
Backup | |
Il servizio Mailarchive è comprensivo del servizio di Backup replicato su Cloud Storage S3. Il Backup viene fatto utilizzando il servizio di 1Backup |
|
Backup dei dati | Giornaliero - retention di 60 giorni - Cifratura 1Backup. |
Backup VM del server | Giornaliero notturno – retention 3 giorni. |
Ripristino | Tramite richiesta al supporto clienti che provvederà al ripristino di quanto richiesto. |
Replica Geografica | Il Backup viene replicato su Cloud Storage S3 - situato in un DataCenter fuori dall'italia in un paese dell'Unione Europea. |
Tolleranza ai Problemi | |
Server Multipli | I server che erogano il servizio di storage Mailarchive sono differenti e multipli. Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici. Il cliente dovrebbe premunirsi di allocare i domini di archiviaizone della posta su server storage differenti. I Server MailArchive godono dell’infrastruttura Stellar. Sito Stellar |
Disaster Recovery | Dati replicati e backup set su altro Datacenter. |
Configurazione Storage Raid6 | La configurazione dischi dello storage di destinazione dei backup è in RAID6. Lo storage su cui risiedono i backup dei dati ha doppio alimentatore e doppie connettività di rete la controller dei dischi è doppia. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Disponibili e interfaccia web o apposito client software. Il cliente è l’unico a possedere le password di accesso alle caselle di archiviazione. CoreTech non può accedere ai dati in quanto sono cifrati | |
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 30 giorni dalla disdetta del servizio. | |
Portabilità | |
In autonomia tramite export del file pst della posta. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Link | |
Modalità di gestione delle violazioni di dati personali | |
Link | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it, in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it. | |
Link Manuale Utilizzo | |
Archiviazione email cloud - Link
KB Accesso Utente - Link |
|
FAQ | |
Faq - Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma,
- in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Da Sygma |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma |
Disponibilità di strumenti di MFA | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette") | Sì |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | N/A |
Meccanismi Crittografici | L'archivio è sempre cifrato con algoritmi stabiliti dal produttore del software Mailstore. Le comunicazioni sono su HTTPS con certificato valido. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS. I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. | I server sono suddivisi in cluster per ottimizzare le prestazioni. Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi: - modifiche reversibili, che quindi non richiedono conferma; - richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); - richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); - richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A. Sono sempre e comunque attivi permessi differenziati su Sygma e sul sito CoreTech. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A. Tutti i report sono controllati. Report interni con accesso a seconda delle mansioni di ciascuno. Report in particolare per i commerciali, con dati per reparto o per persona. Sono però impostati centralmente. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | Report con dati minimizzati. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). | Sì. Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | Dipende dalla configurazione stabilita dal cliente. |
Modalità di cancellazione dei dati | Il cliente non può cancellare le proprie email per le caratteristiche del servizi; a conclusione del servizio, è cancellata la singola istanza (senza cifratura; il file è comunque compresso e decuplicato). |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Web Hosting Scalabile Pagina Prodotto |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti.
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Link |
|
Responsabilità CoreTech |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti.
|
Responsabilità CoreTech |
- Controllo giornaliero dei Backup. La retention dei backup è di 35 giorni (5 settimane).
- Mantenere i server di Web Hosting aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore. - Verifica giornaliera relativamente allo stato di aggiornamento dell’antivirus integrato. - Tenere sotto monitoraggio il server web al fine di garantire la continuità di servizio. - Controllare la presenza di eventuali anomalie relative alla sicurezza che si evidenzino attraverso i log o alert del sistema. - Informare il produttore dei software attinenti ai web server qualora venga a conoscenza di falle relative alla sicurezza del sistema. - Disattivazione del servizio se a seguito di segnalazione da parte di altri service provider, il sito si sta comportando in modo anomalo (spam, phishing, contenuti inerenti al terrorismo, frode, sito hackerato). |
Responsabilità Cliente |
- Impostare delle password di accesso al pannello di gestione Plesk, al sito FTP o al sistema di gestione del sito web (esempio accesso admin di WordPress) con livello di difficoltà conforme alle policy definite e cambio password secondo gli standard di riferimento (es ISO 27002).
- Custodire con cura i dati di accesso Plesk, FTP e sito web e limitarne la divulgazione. - Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti la sicurezza del proprio sito web. - Procedere ad aggiornate periodicamente gli elementi attinenti la sicurezza del proprio sito web (ad esempio aggiornamento della versione di WordPress). - Effettuare almeno una volta al mese un backup personale del proprio sito web. - Verificare periodicamente la funzionalità integrata di Restore dei dati del proprio sito web. - Controllare settimanalmente eventuali anomalie relativamente all’utilizzo di risorse del proprio sito web. - Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. datacenter |
|
Locazione geografica | Unione europea |
Etichettatura | |
Non sono previste funzionalità di etichettatura. È possibile nominare le cartelle nel modo ritenuto più utile. |
|
Funzionalità presenti sul Pannello di Controllo: | |
- Interfaccia da Plesk. - Reseller vede solo i suoi siti e utenti. - Autonomia fino alla chiusura del suo account Reseller. - Dove serve richiesta di disdetta servizio. |
|
Pannello Admin |
- Abilitato in HTTPS. - Permette di impostatare i criteri di lunghezza e complessità delle password per chiunque accede al servizio. |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 24 ore di anticipo. (salvo urgenze inerenti a problemi di sicurezza che richiedano un nostro intervento immediato) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Il servizio RocketWeb è comprensivo di Backup con replica su Cloud Storage S3 Il Backup viene fatto attraverso Plesk e sucessivamente attraverso servizio 1Backup |
|
Backup dei dati | Giornaliero - Retention 35 giorni - Cifratura 1Backup. |
Backup VM del server | Giornaliero notturno – Retention 5 giorni. |
Ripristino | Tramite richiesta al supporto clienti che provvederà al ripristino di quanto richiesto. |
Replica Geografica | Il Backup viene replicato su Cloud Storage S3 (in UE).) |
Tolleranza ai Problemi | |
Server Multipli |
I server che erogano il servizio di sono differenti e multipli Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici I Servizi godono dell’infrastruttura Stellar Sito Stellar |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 Lo storage su cui risiedono i backup dei dati ha doppio alimentatore, doppie connettività di rete e doppia controller dei dischi |
Disaster Recovery | Dati replicati e backup set su altro Data Center. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente è in possesso dei dati di accesso al pannello di gestione Plesk e ai dati di accesso ftp del sito. Nel caso di Wordpress il cliente è l’unico ad avere i dati di accesso al backend amministrativo. CoreTech su richiesta del cliente può accedere ai dati contenuti nel sito dal pannello di gestione o direttamente dal file system. |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 30 giorni dalla disdetta del servizio | |
Portabilità | |
É possibile tramite accesso Ftp estrapolare tutti dati compresi i database. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email
supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB RocketWeb - Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Il cliente finale può richiedere (a pagamento) la creazione di più utenti FTP che possono accedere ad aree diverse del sito. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma). CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma, - in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | &EGrave; possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Da Sygma |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Da Sygma |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma |
Disponibilità di strumenti di MFA. | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Certificati con Certum. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | N/A |
Meccanismi Crittografici | I clienti possono abilitare l'https con propri certificati digitali. Coretech offre il servizio con Letsencrypt o con CA scelte dal cliente. Il server non è cifrato. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS. I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. | Dipende dal sistema. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. |
I server sono suddivisi in cluster per ottimizzare le prestazioni. Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. Per Rocketweb, l'utilizzo di tecniche di distribuzione non è significativo perché è offerto a chi ha necessità limitate (per cose più complesse, si acquistano server IaaS per poi installare quanto necessario). |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). |
Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). Attivo: WAF di Plesk. |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi: - modifiche reversibili, che quindi non richiedono conferma; - richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); - richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); - richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | N/A |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). | Si. Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | N/A |
Modalità di cancellazione dei dati | A conclusione del servizio, è cancellata la singola istanza (senza cifratura). |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Servizio di posta elettronica su server condiviso Pagina Prodotto |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Link |
|
Responsabilità CoreTech |
-Controllo giornaliero dei Backup. La retention dei backup è di 60 giorni.
-Verifica giornaliera relativamente allo stato di aggiornamento dell’antivirus integrato. -Verifica giornaliera relativamente alla presenza dei server nelle Black List pubbliche. -Mantenere i sistemi di posta aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore. -Tenere sotto monitoraggio il server di posta al fine di garantire la continuità di servizio. -Controllare la presenza di eventuali anomalie relative alla sicurezza che si evidenzino attraverso i log o alert del sistema. -Avvisare il cliente qualora, attraverso la lettura dei log del mailserver, si evidenzino situazioni che possano mettere in pericolo gli account di posta elettronica e i dati in esso contenuti. -Informare il produttore del software del mailserver qualora venga a conoscenza di falle relative alla sicurezza del sistema. -Modifica immediata di password, qualora l’account fosse stato hackertato e stesse spedendo spam, delete di tutte le mail in coda relative allo specifico account (sia esse valide o di spam). -Avviso al cliente per opportune verifiche e cambio password. -Su richiesta del cliente, disponibilità ad effettuare esportazione degli archivi di posta su supporti magnetici o in aree di interscambio (attività da quantificare economicamente). |
Responsabilità Cliente |
-Impostare delle password di accesso al servizio di posta con livello di difficoltà conforme alle policy definite e cambio password secondo gli standard di riferimento (es ISO 27002).
-Custodire con cura i dati di accesso alle caselle di posta e limitarne la divulgazione. -Informare i propri utenti circa il buon utilizzo della posta elettronica relativamente alla sicurezza e ai pericoli di phishing e virus. -Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti la casella di posta. -Effettuare periodicamente un backup del proprio archivio di posta su propri sistemi di memorizzazione per avere una copia dell'archivio nel caso si voglia procedere a cambiare fornitore. -Evitare l'utilizzo delle caselle di posta per fare SPAM o invii massivi di email non autorizzate dai destinatari. -Informare tempestivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. -Valutare nelle proprie procedure aziendali la periodicità o l'evento per il cambiamento delle password. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
Kerio |
Kerio: Sulla Webmail è possibile utilizzare il contrassegno come etichettatura.
SmarterMail: È possibile utilizzare software di posta elettronica più consoni al proprio utilizzo |
Funzionalità presenti sul Pannello di Controllo: | |
Interfaccia da Sygma, Kerio ha il suo Pannello Controllo di Gestione e Uguale SmarterMail.
Controllo tramite la dashboard di Sygma, per quanto non previsto gestione autonoma tramite pannelli controllo del prodotto. Autonomia fino alla chiusura del suo account Master, arriva mail di richiesta conferma (soggetto comunque alla disdetta servizio per non continuare a pagare). Cancellazione arriva mail con tracciatura con richiesta conferma. |
|
Pannello Admin |
Vedi sopra.
La password sono già impostate con requisiti di complessità delle password per tutti gli utenti e utilizzatori dei servizi . |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 24 ore di anticipo. (salvo urgenze inerenti a problemi di sicurezza che richiedano un nostro intervento immediato) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
il servizio di Posta Elettronica è comprensivo del servizio di Backup replicato su Cloud Storage S3 Il Backup viene fatto utilizzando il servizio di 1Backup |
|
Backup dei Dati | Giornaliero - Retention 60 giorni - Cifratura 1Backup |
Backup VM del server | Giornaliero notturno – Retention 5 giorni |
Ripristino | Tramite richiesta al supporto clienti che provvederà al ripristino di quanto richiesto |
Replica Geografica | Il Backup viene replicato su Cloud Storage S3 – La replica è localizzata in un secondo Data Center sito all’interno dell'Unione Europea (non in Italia) |
Tolleranza ai Problemi | |
Server Multipli |
I server che erogano il servizio di sono differenti e multipli Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici I Servizi Email godono dell’infrastruttura Stellar Sito Stellar |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 Lo storage su cui risiedono i backup dei dati ha doppio alimentatore, doppie connettività di rete e doppia controller dei dischi |
Disaster Recovery |
Dati replicati e backup set su altro Data Center. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente in possesso dei dati di accesso al servizio può accedere ai dati solo tramite webmail o client di posta Il cliil cliente è l’unico a possedere le password di accesso alle caselle di posta CoreTech, su richiesta del cliente, può accedere ai dati tramite file system |
|
Chiusura Contratto/Cancellazione Dati | |
I dati vengono cancellati dopo 30 giorni dalla disdetta del servizio | |
Portabilità | |
Export autonomo to pst di tutta la posta, con un qualsiasi client di posta o Su richiesta del cliente, disponibilità ad effettuare esportazione degli archivi di posta su supporti magnetici o in aree di interscambio (attività da quantificare economicamente) | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all\’indirizzo email
supporto@coretech.it
in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB Kerio Connect Cloud Link
KB RocketMail Link |
|
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera) | Interfaccia da Sygma. Kerio e SmarterMail hanno il loro pannello di controllo. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma: - in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia.
Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema) |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato.
Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. Per l'email, viene bloccato l'IP di origine dopo 5 tentativi errati di accesso. |
Modalità di recupero delle password di amministrazione | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | User-id personalizzata. |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA. |
Per gli AdS interni: Sì per Sygma;
Per la casella di posta dell'utente: - per Smartermail, disponibile a discrezione dell'amministratore; - per Kerio, c'è la funzionalità, ma potrà essere messa a disposizione dopo alcune verifiche di accessibilità e usabilità; - per KerioConnect, c'è la funzionalità, ma potrà essere messa a disposizione dopo alcune verifiche di accessibilità e usabilità. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Per l'email, CoreTech mette a disposizione certificati. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. |
Non presenti strumenti di firma. Gli utenti possono attivare in autonomia servizi di firma sull'email. |
Meccanismi Crittografici |
L'email è su TLS da 1 a 1.3. Il server non è cifrato. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS. I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Usato Greylog (agganciato a ElasticSearch) per servizi di email. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. |
Sicurezza di Greylog.
I dati sono registrati su un db NoSQL. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” |
Vedere "Infrastruttura". Per email, gli utenti massimi sono impostati su Crab e lo stesso tiene conto degli utenti attivi. |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. |
I server sono suddivisi in cluster per ottimizzare le prestazioni
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi:
- modifiche reversibili, che quindi non richiedono conferma; - richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); - richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); - richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | No per il tipo di servizio offerto. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | No per il tipo di servizio offerto. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | No per il tipo di servizio offerto. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | In carico al cliente. |
Modalità di cancellazione dei dati | A conclusione del servizio, è cancellata la singola istanza (senza cifratura). |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Cloud Server – macchina virtuale (VM) in ambiente Cluster Vmware Pagina Prodotto Sito Stellar |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Così come sotto riportato Link |
|
Responsabilità CoreTech |
-Mantenere l'infrastruttura software aggiornata con le versioni dei software più stabili e sicuri rilasciate dal produttore
-Tenere sotto monitoraggio l'infrastruttura dei sistemi di virtualizzazione, hypervisor e storage al fine di garantire la continuità di servizi -Controllare la presenza di eventuali anomalie relative alla sicurezza che si evidenzino attraverso i log o alert del sistema -Disattivazione del servizio se a seguito di segnalazione da parte di altri service provider, il server stesse attuando dei comportamenti anomali (spam, phishing, contenuti inerenti al terrorismo, frode, sito hackerato) -Informare il cliente in caso durante il monitoraggio o le analisi dei log dovessero essere riscontrati problemi sul server. |
Responsabilità Cliente |
-Impostare delle password di accesso al server e ai software in esso installato con livello di difficoltà conforme alle policy definite e cambio password secondo gli standard di riferimento (es ISO 27002)
-Custodire con cura i dati di accesso ai server e limitarne la divulgazione -Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti la sicurezza del proprio server -Configurare correttamente i job di backup dei propri dati con gli strumenti messi a disposizione da CoreTech e chiedere supporto in caso di dubbi sulle configurazioni -Verificare giornalmente gli esiti dei backup dei dati -Verificare periodicamente il corretto funzionamento del backup della VM consultando gli esiti dal pannello Sygma -Organizzare periodicamente con CoreTech i test di restore della VM al fine di accertarsi della corretta esecuzione dei backup della VM -Controllare periodicamente i registri eventi e log dei sistemi operativi presenti sul proprio server al fine di prevenire eventuali problemi -Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%.Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
Nome istanza personalizzabile + tag | |
Funzionalità presenti sul Pannello di Controllo | |
Interfaccia Sygma Controllo tramite la dashboard di Sygma, per quanto non previsto va richiesto autonomo nell'aumento delle risorse necessarie previo acquisto Cancellazione arriva mail con tracciatura con richiesta Conferma |
|
Pannello Admin |
Sygma Gestione Server completa (compreso Audit) La Password sono già impostate con requisiti di complessità delle password per tutti gli utenti e utilizzatori dei servizi |
SLA | |
IaaS Mensile 99,95% (21m 54s) |
|
Penali | |
SLA IaaS <99,95% (21m 54s) = 10% <99,85% (1h 5m 44s) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
il servizio di Stellar è comprensivo del servizio di Backup replicato su Cloud Storage S3 | |
Backup Dati |
CoreTech mette a disposizione lo strumento di 1Backup per i Backup dei dati delle VM È a carico del cliente la gestione completa delle pianificazioni del backup È a carico del cliente la retention dei dati di backup (periodo di conservazione) Il backup dei dati viene eseguito su uno storage differente da quello utilizzato per la VM stessa |
Backup VM |
1 Backup completo VM ogni 30 giorni (orario notturno). Il backup si sovrascrive ogni 30 giorni 1 Backup completo VM ogni 30 giorni (orario notturno). Il backup si sovrascrive ogni 30 giorni Il backup della VM viene eseguito su uno storage differente da quello utilizzato per la VM stessa Il cliente deve verificare il buon esito dei backup e verificare la consistenza provando periodicamente il ripristino |
Ripristino | Tramite richiesta al supporto clienti che provvederà al ripristino VM richiesta |
Replica Geografica | Il Backup viene replicato su Cloud Storage S3 – La replica è localizzata in un secondo Data Center sito all’interno dell'Unione Europea (non in Italia) - solo per Backup eseguito con Servizio 1Backup |
Servizio Opzionale - a pagamento |
È possibile richiedere Backup VM con retention o frequenza diversa da quella inclusa È possibile richiedere opzionalmente un disaster recovery in altro data center. È possibile richiede opzionalmente un progetto di Business Continuity |
Tolleranza ai Problemi | |
Server Multipli |
I Cloud Server Stellar sono configurati su Cluster di server a 3 nodi su storage condiviso Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici I server dispongono di doppio alimentatore e doppia controller Lo storage condiviso ha doppia controller e doppio alimentatore Ambiente Hypervisor Vmware |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 Lo storage su cui risiedono i backup dei dati ha doppio alimentatore, doppie connettività di rete e doppia controller dei dischi |
Funzione High Availability |
Funzione default, in caso di fault di uno dei nodi il cloud server viene avviato su uno degli altri hypervisor che costituiscono il cluster In questo caso la VM viene riavviata. |
Funzione Fault Tolerance |
Servizio che è possibile richiedere come opzione. In caso di fault di uno dei nodi il cloud server non viene riavviato, in quanto c’è una sincronizzazione continua della RAM e dei registri delle CPU tra gli hypervisor che costituiscono il cluster |
Disaster Recovery – Business Continuity | Il Backup VM incluso nel servizio standard consente un disaster recovery presso lo stesso data center. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente in possesso dei dati di accesso al server può accedere ai dati in esso contenuti CoreTech non ha visibilità diretta dei dati contenuti nel server ma solo del file immagine della macchina virtuale Vmware CoreTech può accede al server solo su richiesta del cliente che deve avvenire come da procedura |
|
Cancellazione/Chiusura Contratto | |
I dati (file immagini del server) vengono cancellati dopo 30 giorni dalla disdetta del servizio | |
Portabilità | |
Su richiesta export in ova della VM. 1 volta gratis, le successive a pagamento secondo tariffario orario. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB Stellar Link | |
FAQ | |
FAQ Stellar Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | In carico al cliente. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Project-Id-Version: coretech PO-Revision-Date: 2020-05-29 17:39+0200 Last-Translator: Language-Team: Language: it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Poedit 2.3 X-Poedit-Basepath: ../../.. X-Source-Language: it Plural-Forms: nplurals=2; plural=(n != 1); X-Poedit-SourceCharset: UTF-8 X-Poedit-KeywordsList: _ X-Poedit-SearchPath-0: traduzioni.php |
Per gli utenti Sygma - in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia.
Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema) |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione | In carico al cliente. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Non assegnata. User-id di default assegnata personalizzata. |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette") | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura |
Dati non cifrati.
Per i clienti Stellar (IaaS), è ovviamente attivabile la cifratura a livello di S.O. |
Trasmissione dei dati con cifratura | N/A |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. |
Non presenti strumenti di firma.
Gli utenti possono attivare in autonomia servizi di firma sull'email. |
Meccanismi Crittografici | La cifratura dei server è in carico al cliente. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS.
I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | N/A |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log |
Sicurezza di Greylog.
I dati sono registrati su un db NoSQL. |
Meccanismi per stabilire la durata della conservazione dei log | In carico al cliente. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi |
I server sono suddivisi in cluster per ottimizzare le prestazioni.
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. | N/A |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | N/A. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | N/A |
Modalità di cancellazione dei dati | In carico al cliente. |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Sygma, Platform Defined IT Work. Il Pannello Sygma è un sistema esclusivo di gestione clienti il quale, oltre ad integrare un database personalizzabile con tutte le informazioni ecessarie per una gestione ottimale dell'infrastruttura informatica dei vostri clienti, dispone di sistemi di integrazione anche con i sistemi di Posta, Firewall, VoIP, Backup Remoto e Archiviazione Email. Con Sygma è possibile governare il Cloud in ogni suo ambito e, contemporaneamente, organizzare i processi di lavoro. Grazie all'integrazione del Cloud, con Sygma si possono gestire da un’unica piattaforma Server, Backup, Posta Elettronica, Archiviazione Email, Account SMTP, Storage e diversi altri servizi. Il sistema di controllo remoto Sygma Connect è incluso nelle versioni Pro e Unlimited. Pagina Prodotto |
|
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti.
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Link |
|
Responsabilità CoreTech |
-Mantenere i sistemi aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore.
-Tenere sotto monitoraggio i server e i processi di sincronizzazione dei dati, per garantire la continuità di servizio. -Controllo giornaliero dei Backup per garantire integrità dei dati. -Backup Aggiuntivo (su altro datacenter). |
Responsabilità Cliente |
-Esportare i dati (ticket, activity ecc) per averne copia di backup.
-Effettuare esportazione dei dati almeno con frequenza mensile/bimestrale. -Impostare delle password di accesso al servizio complesse. -Custodire con cura i dati di accesso a Sygma e a tutti i servizi inclusi e limitarne la divulgazione. Con particolare attenzione alla cifratura password utilizzata per conservazione delle credenziali in Sygma. -Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. -Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti il servizio. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%.Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
tramite Tag e priorità , disponibile un filtro per Tag | |
Funzionalità presenti sul Pannello di Controllo | |
-Interfaccia Web e App Mobile.
-App Mobile permette di visualizzare i ticket, activity, backup e server. -Interfaccia Web è possibile Gestione completa di Sygma. -Accesso Rivenditore fa visualizzare tutti servizi acquistati con indicazione (personalizzata) del cliente finale. -Customer portal permette al cliente finale di visualizzare i propri servizi che il rivenditore ha condiviso. -Rivenditore può cancellare, disabilitare servizi e account dei propri clienti, utilizzando le proprie regole di cancellazione. -Cliente finale ha le autorizzazioni relative ai servizi, impostate dal proprio Rivenditore -Rivenditore Autonomia fino alla chiusura del suo account Master, dove invece è necessaria richiesta di disdetta servizio. |
|
Etichettatura | |
Responsabilità Cliente |
-Tramite interfaccia Sygma l'utente Admin può creare utenti che hanno accesso ad alcuni servizi dedicati, o su Sygma o su le singole console dei servizi.
-Utente admin stabilisce in autonomia le autorizzazioni e i metodi di autenticazione (già presente lunghezza e complessità delle password). -Tutte le Password Utenti devono rispettare criteri mimini di sicurezza -Opzione utilizzo OTP |
SLA | |
IaaS Mensile 99,95% (21m 54s) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Il servizio Sygma è comprensivo di Backup con replica su Cloud Storage S3 Il Backup viene fatto attraverso Plesk e sucessivamente attraverso servizio 1Backup |
|
Backup dei dati |
I dati dei server di front end sono replicati tra i nodi dei web server. I database sono replicati in configurazione master/slave. Retention 60 giorni Con ulteriore copia su altro Storage in altro Datacenter situato in Olanda |
Backup VM del server |
Backup del Server Database ogni 3 ore – Server di Front End backup giornaliero notturno. Altri server che costituiscono l’infrastruttura hanno pianificazioni di backup e retention differenti. |
Ripristino | ripristino disponibile su richiesta a dev@coretech.it - costo orario |
Replica Geografica | Il Backup viene replicato su Cloud Storage S3 – La replica è localizzata in un secondo Data Center sito all’interno dell'Unione Europea (non in Italia) |
Tolleranza ai Problemi | |
Server Multipli |
Il servizio di Sygma è composto da un'infrastruttura costituita da un elevato numero di server. Tali server sono macchine virtuali residenti su più cluster Vmware composti da 3 nodi fisici. È consigliabile per il cliente allocare i domini di archiviazione della posta su server storage differenti I Server Sygma godono dell’infrastruttura Stellar. L’infrastruttura può avere elementi di bilanciamento su altri data center o presso altri cloud provider. Sito Stellar |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 Lo storage su cui risiedono i backup dei dati ha doppio alimentatore, doppie connettività di rete e doppia controller dei dischi |
Disaster Recovery |
Dati replicati e backup set su altro Data Center. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente è in possesso dei dati di accesso alla piattaforma di gestione Sygma. Il cliente deve provvedere ad abilitare l’autenticazione a 2 fattori che la piattaforma mette a disposizione. CoreTech può accedere ad alcuni dati contenuti nei database del sistema. CoreTech non può accedere alle informazioni cifrate contenute nel database come le password. |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 60 giorni dalla disdetta del servizio. | |
Portabilità | |
Esportazione excel per lista ticket e attività oppure può richiedere sviluppo apposito a pagamento orario | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email
supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
Sygma Site Link
KB Sygma Link Forum Sygma Link |
|
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Ogni utente ha accesso a singole funzionalità e ai dati del singolo cliente. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma
- in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia.
Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato.
Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | &EGrave; possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | User-id scelta dall'utente. |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette") | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Certificati con Certum. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | N/A |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS
I clienti gestiscono i certificati: - in autonomia per i servizi che lo prevedono; - attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente | Usati certificati esterni |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra |
Meccanismi per garantire la sicurezza dei log | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi |
I server sono suddivisi in cluster per ottimizzare le prestazioni.
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. Servizi modulari sono: -RocketBox con server web, db e storage dati; -Sygma con server web e storage. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). |
Sviluppato internamente:
-input tutti validati, anche oggetto di check list di sviluppo; -WAF interno per Sygma (sulle chiamate pubbliche, mentre con maggiore prudenza per le attività degli utenti autenticati). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi:
-modifiche reversibili, che quindi non richiedono conferma; -richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); -richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); -richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. |
N/A.
Sono sempre e comunque attivi permessi differenziati su Sygma e sul sito CoreTech. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. |
N/A.
Tutti i report sono controllati. Report interni con accesso a seconda delle mansioni di ciascuno. Report in particolare per i commerciali, con dati per reparto o per persona. Sono però impostati centralmente. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | Report con dati minimizzati. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). |
Unici dati, relativi ai servizi, riguardano persone giuridiche e pertanto si mantengono.
Gli utenti interni vanno cancellati dopo 10 anni. Operazione manuale e prevista per Sygma. |
Modalità di cancellazione dei dati | I dati sono cancellati senza cifratura. |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Software controllo remoto Pagina Prodotto |
|
Piattaforma di gestione | |
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Così come sotto riportato Link |
|
Responsabilità CoreTech | Project-Id-Version: coretech PO-Revision-Date: 2020-05-29 17:39+0200 Last-Translator: Language-Team: Language: it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Poedit 2.3 X-Poedit-Basepath: ../../.. X-Source-Language: it Plural-Forms: nplurals=2; plural=(n != 1); X-Poedit-SourceCharset: UTF-8 X-Poedit-KeywordsList: _ X-Poedit-SearchPath-0: traduzioni.php |
Responsabilità Cliente | Project-Id-Version: coretech PO-Revision-Date: 2020-05-29 17:39+0200 Last-Translator: Language-Team: Language: it MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Poedit 2.3 X-Poedit-Basepath: ../../.. X-Source-Language: it Plural-Forms: nplurals=2; plural=(n != 1); X-Poedit-SourceCharset: UTF-8 X-Poedit-KeywordsList: _ X-Poedit-SearchPath-0: traduzioni.php |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Principalmente in Italia, poi Germania e Gran Bretagna |
Etichettatura | |
Il software non offre livelli standard di classificazione delle informazioni. Il cliente può comunque apporre etichette ed, eventualmente, un livello di classificazione, tramite il nome macchina o creare gruppo idoneo per privacy | |
Funzionalità presenti sul Pannello di Controllo | |
-Interfaccia da Sygma o Client Admin sul server o pc stesso. -Pieno controllo tramite l'App sul proprio client Visualizzazione completa su Sygma (elenco, impostazioni, stato e registrazioni sessioni se impostato su registrazioni) -Autonomia fino alla chiusura del suo account Master o istanza associata al partner. Dove è necessaria richiesta di disdetta servizio. (vedere Sygma) |
|
Pannello Admin | vedere Sygma |
SLA | |
IaaS Mensile 99,95% (21m 54s) |
|
Penali | |
SLA IaaS <99,95% (21m 54s) = 10% <99,85% (1h 5m 44s) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Tutti i dati degli utenti e dei Peer sono salvati in Sygma, non è pertanto necessario alcun Backup in quanto è già previsto per il servizio Sygma su cui si appoggia. |
|
Backup | |
Tutti i dati degli utenti e dei Peer sono salvati in Sygma, non è pertanto necessario alcun Backup in quanto è già previsto per il servizio Sygma su cui si appoggia. |
|
Tolleranza ai Problemi | |
Server Multipli |
Il servizio di Sygma Connect è composto da un'infrastruttura costituita da un elevato numero di server dislocati su diversi Datacenter ( esempio Aruba, Azure, Stellar) Il servizio è basato su Docker |
Configurazione Storage Raid6 | N/A |
Disaster Recovery | N/A |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente in possesso dei dati di accesso al server può accedere ai dati in esso contenuti CoreTech non ha visibilità diretta dei dati contenuti e non può accedere in remoto alle macchine almeno che non sia espressamente richiesto e autorizzato dal cliente (tramite id e password secondaria) |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 60 giorni dalla disdetta del servizio. | |
Portabilità | |
Da Sygma e possibile esportare elenco sessioni con dettagli necessari e log Da Sygma inoltre è disponibile la Rubrica con elenco dispositivi disponibili alla connessione remota. |
|
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB Sygma Connect Link
Forum Sygma Connect Link |
|
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Non applicabile. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma). CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma - in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Non assegnata |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Certificati con Certum. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | N/A |
Meccanismi Crittografici |
Le comunicazioni sono su https con TLS da 1 a 1.3. Il server non è cifrato. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS. I clienti gestiscono i certificati: -in autonomia per i servizi che lo prevedono; -attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni.. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. |
I server sono suddivisi in cluster per ottimizzare le prestazioni. Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | N/A |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. | N/A |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | N/A |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì. Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | N/A |
Modalità di cancellazione dei dati | N/A |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 3 del 09/05/2024
Descrizione | |
Mail Marketing RocketNews, Sistema Invio Newsletter. RocketNews è un alternativa a MailChimp e MailUp realizzata per soddisfare tutte quelle aziende che hanno le stesse esigenze di comunicazione delle grandi realtà ma hanno un numero di destinatari limitato. Con RocketNews le aziende possono inviare le loro Newsletter in autonomia. Pagina Prodotto |
|
Piattaforma di gestione | |
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Così come sotto riportato Link |
|
Responsabilità CoreTech |
-Controllo giornaliero dei Backup. La retention dei backup è di 35 giorni (5 settimane). -Mantenere i server di RocketNewslettr aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore. -Tenere sotto monitoraggio il server web al fine di garantire la continuità di servizio. |
Responsabilità Cliente |
-Impostare delle password di accesso al pannello di RocketNewsletter. -Custodire con cura i dati di accesso al servizio RocketNewsletter e limitarne la divulgazione. -Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti la sicurezza del proprio sito web. -Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
nominare liste newsletter e modelli in modo da determinare la tipologia di dati se più sensibili di altri. | |
Funzionalità presenti sul Pannello di Controllo | |
Interfaccia Web RocketNewsletter richiesta dell'aumento delle risorse necessarie. Cancellazione previa richiesta e CoreTech invia mail conferma avvenuta cancellazione |
|
Pannello Admin | L'utente è unico. |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 4 ore di anticipo |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
RocketNews è un servizio che ha alla base Rocketweb e quindi le caratteristiche di Backup corrispondono a Rocketweb SLA RocketWeb
|
|
Tolleranza ai Problemi | |
Server Multipli |
RocketNews è un servizio che ha alla base Rocketweb e quindi le caratteristiche di Tolleranza corrispondono a Rocketweb. - I server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici. - I Server di RocketNewsletter godono dell’infrastruttura Stellar. - La configurazione dischi dello storage di destinazione dei backup è in RAID6. Funzione High Availibility: lo storage su cui risiedono i backup dei dati ha doppio alimentatore e doppie connettività di rete. La controller dei dischi è unica. Funzione Fault Tollerance: Opzionale (dati replicati e backup set su altro Datacenter) |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 lo storage su cui risiedono i backup dei dati ha doppio alimentatore e doppie connettività di rete la controller dei dischi è doppia |
Disaster Recovery |
il Backup VM incluso nel servizio standard consente un disaster recovery presso lo stesso data center. È possibile richiedere opzionalmente un disaster recovery in altro data center. È possibile richiede opzionalmente un progetto di Business Continuity. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente in possesso dei dati di accesso e può inserire, cancellare, visualizzare, modificare, scaricare e caricare in autonomia immagini, contatti email, testo e template creati (o crearsi template) sulla piattarforma Sempre in autonomia il cliente può estrapolasi tutti i report inerenti agli invii fatti con tutti i dettagli ad essi associati Quando l'utente si cancella dal servizio il dato viene anonimizzato |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 30 giorni dalla disdetta del servizio | |
Portabilità | |
Il cliente in possesso dei dati di accesso e può scaricare e caricare in autonomia immagini, contatti e template base creati sulla piattarforma Sempre in autonomia il cliente può estrapolasi tutti i report inerenti agli invii fatti con tutti i dettagli ad esse associati |
|
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB RocketNews Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Rocket Newsletter: l'utente è unico. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma
- in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato.
Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | La user-id assegnata è personalizzata. |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA. | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Per l'email, CoreTech mette a disposizione certificati. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | N/A |
Meccanismi Crittografici | Le comunicazioni sono su https con TLS da 1 a 1.3. Il server non è cifrato. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS.
I clienti gestiscono i certificati: -in autonomia per i servizi che lo prevedono; -attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. |
I server sono suddivisi in cluster per ottimizzare le prestazioni.
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). |
Sviluppato internamente:
-input tutti validati (Rocket Newsletter è stato anche oggetto di VA), anche oggetto di check list di sviluppo -WAF di Plesk attivo per RocketWeb (e quindi Rocket Newsletter). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi:
-modifiche reversibili, che quindi non richiedono conferma; -richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); -richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); -richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | N/A |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | N/A |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | N/A |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | N/A |
Modalità di cancellazione dei dati | In carico all'utente. |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 2 del 09/05/2024
Descrizione | |
Servizio di file sharing Pagina Prodotto |
|
Piattaforma di gestione | |
Ruoli e Responsabilità | |
CoreTech agisce come Responsabile o Sub Responsabile per tutti i trattamenti, mentre è titolare per i soli dati dati di contatto dei clienti
In riferminto alla conformità e sicurezza dei dati, sia CoreTech che il cliente sono entrambi responsabili anche se su fronti diversi. Così come sotto riportato Link |
|
Responsabilità CoreTech |
-Controllo giornaliero dei Backup. La retention dei backup è di 35 giorni (5 settimane).
-Mantenere i server di Rocketbox aggiornati con le versioni dei software più stabili e sicuri rilasciate dal produttore. -Tenere sotto monitoraggio il server web al fine di garantire la continuità di servizio. |
Responsabilità Cliente |
-Impostare delle password di accesso al pannello di RocketBox.
-Custodire con cura i dati di accesso al servizio RocketBox e limitarne la divulgazione. -Intervenire tempestivamente in caso di segnalazioni da parte di CoreTech su problemi inerenti la sicurezza del proprio sito web. Verificare periodicamente la funzionalità integrata di Restore dei dati del proprio sito web. -CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
nominare i file come più opporturno | |
Funzionalità presenti sul Pannello di Controllo | |
Pannello Rocketbox. Controllo tramite la dashboard di Sygma, che permette di aumentare le risorse previo acquisto. | |
Pannello Admin |
-L'admin può creare gli utenti che possono accedere; gli utenti con cui si condivide possono agire secondo i criteri di condivisione impostati per ogni cartella.
-Le password sono impostate con requisiti di complessità delle password per tutti gli utenti e utilizzatori dei servizi. |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 4 ore di anticipo |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Il servizio Rocketbox e è comprensivo del servizio di Backup replicato su Cloud Storage S3 Il Backup viene fatto utilizzando il servizio di 1Backup SLA RocketBox
|
|
Backup dei Dati |
giornaliero - retention di 40 giorni - Cifratura 1Backup |
Backup VM del server |
ogni 15 giorni – retention 2 Backup dopo si sovrascrive |
Ripristino |
Tramite richiesta al supporto clienti che provvederà al ripristino di quanto richiesto |
Replica Geografica') ?> |
Il Backup viene replicato su Cloud Storage S3 - situato in un DataCenter fuori dall'italia in un paese dell'Unione Europea |
Tolleranza ai Problemi | |
Server Multipli |
I server che erogano il servizio di storage Rocketbox sono differenti e multipli Tali server sono macchine virtuali residenti su cluster Vmware composti da 3 nodi fisici I Servizi godono dell’infrastruttura Stellar Sito Stellar |
Configurazione Storage Raid6 |
La configurazione dischi dello storage di destinazione dei backup è in RAID6 Lo storage su cui risiedono i backup dei dati ha doppio alimentatore e doppie connettività di rete La controller dei dischi è doppia |
Disaster Recovery | Dati replicati e backup set su altro Datacenter. |
Supporto | |
Pagina Supporto - Link | |
Accesso ai Dati | |
Il cliente in possesso dei dati di accesso può accedere ai dati solo tramite interfaccia web o client di syncronizzazione o protocollo WEBDAV Sono disponibili sistemi per recuperare o modificare tale password tramite interfaccia web |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 30 giorni dalla disdetta del servizio | |
Portabilità | |
Dowload completo col client di Rocketbox in autonomia. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email
supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB RocketBox Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Con pannello admin si stabiliscono in autonomia gli utenti che possono accedere, le autorizzazioni e i metodi di autenticazione (inclusa lunghezza e complessità delle password). |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma)
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma -in caso di creazione dell'utenza, il cambio della password è obbligatorio; -per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia.
Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato. Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Sì. |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA. | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Certificati con Certum. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | Non presenti strumenti di firma. |
Meccanismi Crittografici |
Le comunicazioni sono su https con TLS da 1 a 1.3.
Il server non è cifrato. I clienti possono cifrare autonomamente i propri dati. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS.
I clienti gestiscono i certificati: -in autonomia per i servizi che lo prevedono; -attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. |
I server sono suddivisi in cluster per ottimizzare le prestazioni.
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. Servizi modulari sono: -RocketBox con server web, db e storage dati; -Sygma con server web e storage. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). | Pacchetto, gestito o tramite la propria interfaccia o tramite interfaccia Sygma (vedere sotto). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi: -modifiche reversibili, che quindi non richiedono conferma; -richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); -richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); -richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | No per il tipo di servizio. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | No per il tipo di servizio. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | No per il tipo di servizio. |
Modalità di cancellazione dei dati | A conclusione del servizio, è cancellata la singola istanza (senza cifratura). |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Versione 2 del 09/05/2024
Descrizione | |
Sigillo è la firma elettronica avanzata che consente di firmare i contratti con un workflow semplice e veloce. Il processo di invio dei contratti viene effettuato tutto via web browser, sia per chi invia il contratto che per chi lo riceve. | |
Ruoli e Responsabilità | |
&nbps; | |
Responsabilità CoreTech | Mantenere la piattaforma. |
Responsabilità Cliente | Usare diligentemente la piattaforma. |
Datacenter | |
TIER4 - È il livello più alto di garanzia che un datacenter può offrire, con una disponibilità del 99.9%. Identifica un datacenter completamente ridondato a livello di circuiti elettrici, di raffreddamento e rete. Questo indicatore si riferisce ad una architettura che permette di far fronte a incidenti tecnici gravi senza mai interrompere la disponibilità dei server. | |
Locazione geografica | Unione europea |
Etichettatura | |
N/A | |
Funzionalità presenti sul Pannello di Controllo: | |
Pannello Admin | N/A |
SLA | |
SaaS Mensile 99,8% (1h 26m) Sono escluse le attività di manutenzione ordinaria e straordinaria segnalate sul sito con 24 ore di anticipo. (salvo urgenze inerenti a problemi di sicurezza che richiedano un nostro intervento immediato) |
|
Penali | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Sigillo è un servizio che ha alla base Rocketweb e quindi le caratteristiche di Backup corrispondono a Rocketweb. | |
Tolleranza ai Problemi | |
Sigillo è un servizio che ha alla base Rocketweb e quindi le caratteristiche di Tolleranza corrispondono a Rocketweb. | |
Supporto | |
Standard | |
Accesso ai Dati | |
L'utente in possesso dei dati di accesso alla piattaforma è stato autorizzato e ha accesso a tutti i dati contenuti nei documenti e al tracciamento dei dati di firma. CoreTech non ha visibilità diretta dei dati contenuti e non può accedere in remoto alle macchine almeno che non sia espressamente richiesto e autorizzato dal cliente. |
|
Cancellazione/Chiusura Contratto | |
I dati vengono cancellati dopo 60 giorni dalla disdetta del servizio. | |
Portabilità | |
N/A | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Pagina Data Processing Agreement (DPA) - Link | |
Modalità di gestione delle violazioni di dati personali | |
Pagina Data Processing Agreement (DPA) - Link | |
Raccolta Prove | |
Qualora il cliente abbia necessità di raccogliere prove o richiedere assistenza può inviare la richiesta all’indirizzo email supporto@coretech.it in caso in cui l’assistenza richiesta non sia di competenza del supporto o per altre motivazioni può contattare il referente Privacy all’email privacy@coretech.it |
|
Link Manuale Utilizzo | |
KB Sigillo Link | |
Misure sicurezza | |
Pagina Data Processing Agreement (DPA) - Link | |
Gestione utenti | Per gli utenti dei clienti, è possibile gestire gli utenti di Sygma. |
Userid personali per gli utenti | Per i clienti, è possibile creare utenti con userid personali. |
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera). | Accesso assicurato ad ogni utente. |
Verifica delle autorizzazioni per accedere o visualizzare le elaborazioni. |
I clienti possono visualizzare gli utenti e le autorizzazioni dai pannelli di controllo dei singoli servizi acquistati (incluso Sygma).
CoreTech può visualizzare gli utenti AdS verificando i singoli sistemi. |
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata). |
Per gli utenti Sygma
- in caso di creazione dell'utenza, il cambio della password è obbligatorio; - per il reset password, l'utente avvia la procedura in autonomia. Per i servizi, sono assegnate user-id e password di amministrazione ai clienti, che la gestiscono in autonomia. |
Modifica della password da parte dell’utente |
Per i clienti: per il reset password, l'utente avvia la procedura di Sygma in autonomia. Per gli AdS interni, le password sono gestite tramite Sygma. |
Password nascosta nel campo dove inserire la password. | Sì. |
Possibilità di bloccare l’utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema). |
Su Sygma è abilitato l'invio dell'email ad ogni tentativo sbagliato.
Inoltre, dopo un certo numero di tentativi, si avvia una procedura di rallentamento. Per gli AdS di CoreTech, è usato Sygma. I virtualizzatori bloccano per 5 minuti le utenze dopo 5 tentativi falliti. Però al momento non sono lanciati allarmi. |
Modalità di recupero delle password di amministrazione. | È possibile contattare l'assistenza di CoreTech. |
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema. | Sì. |
Personalizzazione delle credenziali per gli amministratori di sistema (e userid personali) | Sì. |
Disabilitazione delle userid di default | Non applicabile |
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (affinché siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell’utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password. | Sygma. |
Controllo automatico della non banalità delle password; p.e. password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell’applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra). | Sygma. |
Disponibilità di strumenti di MFA. | Per gli AdS interni: Sì per Sygma. |
Messaggi di errore di autenticazione che non specificano dettagli (dicono solo, p.e., "credenziali non corrette"). | Sì. |
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività. | Dipende dal sistema. |
Configurazione affinché gli utenti non possano connettersi in specifici orari o da alcuni Paesi. | NO. |
Modalità di interfacciamento con altri programmi o con l’utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche. | In alcuni casi, sono usate credenziali di servizio, ma con controllo dell'IP di origine. |
Memorizzazione dei dati con cifratura. | Dati non cifrati. |
Trasmissione dei dati con cifratura | Tutte le connessioni sono cifrate. Certificati con Certum. |
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività. | Prodotto stesso di firma. |
Meccanismi Crittografici | Le comunicazioni sono su https con TLS da 1 a 1.3. Il server non è cifrato. I clienti possono cifrare autonomamente i propri dati. |
Accesso alla chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software. |
Internamente, le chiavi private sono usate con i certificati e i certificati sono modificabili solo dagli AdS.
I clienti gestiscono i certificati: -in autonomia per i servizi che lo prevedono; -attraverso gli AdS di CoreTech per altri servizi (p.e. email). |
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente. | Usati certificati esterni. |
Disponibilità di log applicativi e log delle attività degli amministratori di sistema. | Log applicativi dipendono dall'applicazione. |
Log degli utenti | Vedere sopra. |
Meccanismi per garantire la sicurezza dei log. | Sicurezza assicurata dall'applicazione. |
Meccanismi per stabilire la durata della conservazione dei log. | Impostati 6 mesi. |
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso. | Vedere "Infrastruttura". |
Clock sincronizzabile con un NTP server. | Vedere "Infrastruttura". |
Definizione di “prestazioni accettabili” | Vedere "Infrastruttura". |
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi. |
I server sono suddivisi in cluster per ottimizzare le prestazioni.
Ciascun servizio, poi, dove opportuno, è suddiviso in ulteriori server, preferibilmente in cluster diversi. |
Backup (frequenza, tempi di conservazione, locazione) | Vedere sopra. |
Verifica e sanamento (dall’inglese sanitization) dei dati in ingresso a livello server, soprattutto quando ricevuti da fonti non sicure come il web (per esempio, se è prevista una data, il sistema verifica che si tratti di una data e non di altri caratteri; se sono previsti input di un certo numero di caratteri, il sistema verifica che la loro lunghezza non sia eccedente). |
Sviluppato internamente:
-input tutti validati (Rocket Newsletter è stato anche oggetto di VA), anche oggetto di check list di sviluppo -WAF di Plesk attivo per RocketWeb (e quindi Rocket Newsletter). |
Filtri quando si modificano i dati, per esempio con messaggi “sei sicuro di voler modificare” o con richiesta di validazione da altri utenti. |
A seconda delle criticità dell'operazione, per confermarla sono attivi i seguenti meccanismi:
-modifiche reversibili, che quindi non richiedono conferma; -richiesta conferma per modifiche non reversibili non impattanti (p.e. cancellazione ticket); -richiesta conferma email per modifiche non reversibili impattanti (p.e. cancellazione VM); -richiesta di conferma con ulteriori dati di input, in alternativa al precedente. |
Limitazione delle possibilità di ricerca, in modo che un utente non possa visualizzare dati a cui non è autorizzato. | No per il tipo di servizio. |
Dati a video e stampati senza informazioni riservate o per le quali l’utente non ha le autorizzazioni ad accedere. | No per il tipo di servizio. |
Possibilità di anonimizzazione o pseudonimizzazione dei dati | No per il tipo di servizio. |
Tipo di messaggi e di avvisi lanciati dal sistema che forniscano sufficienti informazioni al personale autorizzato, ma non forniscano informazioni a malintenzionati (per esempio, fornendo troppi dettagli sul tipo di errore quando si inseriscono credenziali sbagliate). |
Sì.
Esempio: messaggi di errori e di conferma per password errate e per cambio password. |
Sistemi di cancellazione automatica dei dati, o di avviso, quando hanno superato il tempo di conservazione previsto (retention time). | Le informazioni sono dell'utente che quindi decide autonomamente se cancellarle. |
Modalità di cancellazione dei dati | A conclusione del servizio, è cancellata la singola istanza (senza cifratura). |
Garanzia della gestione delle vulnerabilità riscontrate e del patching (il produttore deve garantire un servizio di avviso e di invio delle correzioni). | I servizi erogati sono in cloud e pertanto CoreTech aggiorna i pacchetti a seconda delle specifiche del fornitore. |
Titolo del documento: | SLA_servizi |
---|---|
Versione del documento: | V. 2 |
Data di ultima modifica: | 04/11/2021 |
Gestione e qualità
Gestione dei dati e delle informazioni di sicurezza
Gestione della sicurezza
per i Cloud Provider
Gestione dei dati personali
in Cloud
Gestione delle informazioni
sulla Privacy
Protezione dei dati