Crittografia dei dati in transito
Tutto il traffico verso Teamleader passa attraverso una connessione crittografata SSL. Per di più, accettiamo unicamente traffico attraverso port 443. Seguendo questo link puoi trovare un rapporto sulla nostra configurazione SSL.
Durante la prima visita al sito, Teamleader invia un header HTTP Strict Transport Security (spesso abbreviato come HSTS) allo user agent, assicurando l’effettuazione di tutte le richieste future via HTTPS, anche in presenza di un link a Teamleader specificato come HTTP.
Pratiche di sicurezza AWS
Teamleader usa Amazon Web Services (AWS) per memorizzare i dati dell’utente. Questi server sono sottoposti a frequenti controlli volti ad assicurare l’adempimento dei più recenti standard di settore, con una gestione costante del rischio. Grazie all’uso di AWS come centro dati, la nostra infrastruttura software è accreditata da
- ISO 27001
- SOC 1 e SOC 2/SSAE 16/ISAE 3402 (precedentemente SAS 70 Type II)
- PCI Level 1
- C5 Operational Security
- ENS High
- IT-Grundschutz
Per ulteriori informazioni sui servizi di sicurezza AWS, fai clic qui.
Politica sulle password e sulla loro conservazione
Per accedere a Teamleader è necessario fornire una password sicura di almeno 6 caratteri. Non memorizziamo tali password come testo, ma salviamo unicamente hash di password cifrate unidirezionalmente attraverso Bycript, un algoritmo open source verificato che include un per-user-random-salt. Questo protegge gli utenti da attacchi rainbow tables e da furti da corrispondenze di password crittografate.
Nel caso di molteplici immissioni di password erronee da parte dell’utente, l’account sarà temporaneamente bloccato per evitare attacchi di forza bruta. Per proteggere ulteriormente l’accesso all’account, gli utenti possono attivare la verifica in due passaggi, utilizzando Google Authenticator o Authy attraverso le impostazioni di sicurezza dell’account utente.
Tracciamento e blocco delle richieste
Blocchiamo le richieste da indirizzi o intervalli IP conosciuti e vulnerabili.
Le richieste provenienti dallo stesso IP vengono bloccate e limitate per evitare potenziali abusi.
Protezione XSS e CSRF
Per bloccare attacchi Cross-Site Scripting (XSS) viene effettuato l’escape di tutto l’output nella nostra applicazione back-end prima che arrivi al browser, dove potrebbe potenzialmente causare attacchi XSS. Evitiamo di usare file raw di ritorno, in quanto tale azione potrebbe potenzialmente causare l’invio al browser di dati indesiderati.
La nostra applicazione blocca le richieste che non provengono dai nostri domini, in modo tale da contribuire a ridurre il rischio di attacchi Cross Site Request Forgery (CSRF). Per azioni importanti, utilizziamo inoltre i token CSRF.
Infine, abbiamo applicato l’header Content Security Policy (CSP) HTTP, il quale indica le risorse fidate (javascript, immagini, fogli di stile, etc.) che il browser dell’utente dovrebbe consentire di caricare ed eseguire. Un’intestazione CSP correttamente applicata elimina qualsiasi codice javascript malevolo (attacchi XSS), file nocivi dissimulati come immagini e attacchi simili basati sulla fiducia del browser rispetto alle risorse servite.
Programma di hacking etico
Abbiamo lanciato un programma di hacking etico in stretta collaborazione con Intigriti.com. Attualmente la nostra applicazione è sottoposta a costanti test da parte un gruppo di specialisti indipendenti dell’ambito della sicurezza, nell’obiettivo di identificare e rilevare potenziali vulnerabilità.
Organizzazione
Il nostro team usa password uniche ed efficaci per gli account Teamleader, e ha attivato la verifica in due passaggi per ciascuno dei dispositivi e servizi usati. Tutti i dipendenti di Teamleader sono invitati ad usare software di gestione delle password (LastPass, 1Password, …) per generare e memorizzare password sicure.
Ci assicuriamo inoltre di cifrare hard disk locali e di attivare il blocco automatico dello schermo. Qualsiasi accesso alle funzionalità di amministratore dell’applicazione è ristretto a un numero selezionato di persone.