| Principio 1: Protezione dei dati in transito |
| 1.1 Crittografia | Atlassian applica la crittografia alla rete wireless interna, inclusa la modifica delle impostazioni predefinite del fornitore. Il team Workplace Technology di Atlassian protegge le nostre reti wireless utilizzando l'autenticazione WPA2-AES e la crittografia PEAP-EAP-MSCHAPv2. Effettuiamo l'autenticazione sulla nostra rete wireless tramite 802.1x utilizzando il nostro archivio di identità interno. Eseguiamo regolarmente la scansione dei punti di accesso wireless non autorizzati e gestiamo un elenco dei punti di accesso non autorizzati che vengono trovati.
Atlassian utilizza la versione 1.2 dello standard di settore Transport Layer Security ("TLS") per creare una connessione sicura tramite la crittografia Advanced Encryption Standard ("AES") a 256 bit. I server che contengono dati degli utenti utilizzano la crittografia completa del disco AES standard del settore. I dati del tenant sono crittografati all'interno dei backup AWS RDS o RDS e sono anche crittografati nell'archiviazione a lungo termine (S3) e in tutti gli allegati.
Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management | Le nostre policy di sicurezza e privacy dei dati
Crittografia dei dati | Atlassian Trust Center Data
Crittografia | Architettura e pratiche operative di Atlassian Cloud |
| 1.2 Protezione della rete | Il Policy Management Program (PMP) di Atlassian include una policy per la sicurezza delle comunicazioni che stabilisce la responsabilità della gestione della rete.
Per l'accesso alla rete, Atlassian utilizza una directory centralizzata abilitata per LDAP che implementa il controllo degli accessi basato sui ruoli e su profili definiti. Agli utenti vengono concessi i diritti di accesso appropriati in base a questi profili, gestiti tramite il flusso di lavoro del nostro sistema di gestione delle risorse umane. Le regole di accesso alla rete di produzione interna vengono gestite utilizzando gruppi di sicurezza esplicitamente designati all'interno degli ambienti AWS VPC.
Il team Workplace Technology di Atlassian protegge le reti wireless utilizzando l'autenticazione WPA2-AES e la crittografia PEAP-EAP-MSCHAPv2. Effettuiamo l'autenticazione sulla nostra rete wireless tramite 802.1x utilizzando il nostro archivio di identità interno.
Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall nel cloud e in sede, e abbiamo implementato tecnologie IDS nei nostri uffici. La protezione dalle minacce di rete viene eseguita da AWS, inclusa la protezione DDoS e alcune funzioni del firewall delle applicazioni Web.
Tutti i dati per i nostri servizi sono crittografati in transito tramite TLS per proteggerli da divulgazioni o modifiche non autorizzate, indipendentemente dal fatto che il protocollo utilizzato sia HTTPS o SMTPS. Le implementazioni Atlassian di TLS impongono l'uso di chiavi di crittografia complesse. | Le nostre policy di sicurezza e privacy dei dati
Integrazione della sicurezza nella nostra infrastruttura di rete | Atlassian Trust Center |
| 1.3 Autenticazione | Atlassian applica restrizioni sul personale che necessita di questo accesso per il proprio ruolo e le proprie responsabilità lavorative. Tutti i sistemi di livello 1 sono gestiti tramite una soluzione centralizzata di Single Sing-On (SSO) e directory Atlassian. Agli utenti vengono concessi i diritti di accesso appropriati in base a questi profili, gestiti tramite il flusso di lavoro del nostro sistema di gestione delle risorse umane. Atlassian utilizza l'autenticazione a più fattori per accedere a tutti i sistemi di primo livello. Abbiamo abilitato l'autenticazione a due fattori per la console di gestione dell'hypervisor, l'API AWS e un report di audit giornaliero su tutti gli accessi alle funzioni di gestione dell'hypervisor. Gli elenchi di accesso alla console di gestione degli hypervisor e all'API AWS vengono esaminati trimestralmente. Effettuiamo anche una sincronizzazione di 8 ore tra il sistema delle risorse umane e l'archivio delle identità.
Atlassian supporta l'utilizzo delle identità Google, Microsoft e Apple per l'autenticazione della maggior parte dei prodotti. Supportiamo SAML per i nostri servizi Atlassian Cloud anche tramite Atlassian Access; per informazioni, consulta la pagina: https://www.atlassian.com/enterprise/cloud/access | Le nostre policy di sicurezza e privacy dei dati
Protezione dell'accesso alle nostre reti tramite ZeroTrust | Atlassian Trust Center Service
Autenticazione e autorizzazione | Architettura e pratiche operative di Atlassian Cloud |
| Principio 2: Protezione e resilienza degli asset |
| 2.1 Ubicazione fisica e giurisdizione legale | Ubicazione fisica
Oggi Atlassian gestisce data center e ospita dati negli Stati Uniti, in Germania, Irlanda, Singapore e Australia. Forniamo a tutti i clienti servizi sicuri, veloci e affidabili ospitando i loro contenuti in più regioni in tutto il mondo.
Tutti i sistemi Atlassian Cloud di produzione risiedono nelle regioni Stati Uniti orientali e Stati Uniti occidentali di Amazon AWS, nella regione AWS Irlanda, nella regione AWS Francoforte, nella regione AWS Sydney e nella regione AWS Singapore.
Al momento dell'iscrizione, la piattaforma Atlassian ottimizza la posizione dei dati dei clienti in base all'origine dell'accesso, garantendo prestazioni più affidabili e latenza ridotta.
Attualmente, la residenza dei dati è disponibile come parte dei nostri piani Cloud Standard, Premium ed Enterprise per Jira Software, Confluence e Jira Service Management. Puoi scegliere anche di ospitare determinati dati di prodotto in Australia, Europa o negli Stati Uniti. Ulteriori informazioni sui controlli della residenza dei dati.
Tieni d'occhio la nostra roadmap di Cloud per conoscere gli aggiornamenti più recenti, tra cui la residenza dei dati per località aggiuntive, app e molto altro. | Ubicazione fisica
Protezione dei dati | Atlassian Trust Center
Infrastruttura di hosting di Atlassian Cloud | Architettura e pratiche operative di Atlassian Cloud |
| Utilizzo dei tuoi dati
Consulta il Contratto con i clienti Atlassian, l'Informativa sulla privacy e l'Addendum al trattamento dei dati. | Utilizzo dei tuoi dati
Contratto con i clienti Atlassian | Atlassian
Informativa sulla privacy | Atlassian
Addendum al trattamento dei dati | Atlassian |
| Considerazioni aggiuntive
Fai riferimento all'impegno di conformità al GDPR e alle altre leggi sulla protezione dei dati assunto da Atlassian. | Considerazioni aggiuntive
L'impegno di Atlassian per il GDPR | Atlassian | Atlassian |
| 2.2 Sicurezza dei data center | Questo argomento è trattato nell'Addendum sul trattamento dei dati di Atlassian, in cui Atlassian si impegna a proteggere i tuoi dati, anche in relazione alla sicurezza del data center e della rete.
Atlassian anticipa le minacce fisiche ai suoi data center e ha implementato contromisure per prevenirne o limitarne l'impatto.
I nostri uffici Atlassian sono guidati dalla nostra policy interna di sicurezza fisica e ambientale, che include il monitoraggio dei punti fisici di ingresso e uscita.
I nostri partner dispongono di diverse certificazioni di conformità per i propri data center, che riguardano la sicurezza fisica e ambientale, la disponibilità dei sistemi, l'accesso alla rete e al backbone IP, il provisioning degli utenti e la gestione dei problemi. L'accesso ai data center è limitato al personale autorizzato e controllato mediante misure di verifica biometrica dell'identità. Le misure di sicurezza fisiche includono: presenza di personale di sorveglianza on-premise, monitoraggio video a circuito chiuso, mantrap e ulteriori misure di protezione contro le intrusioni.
AWS dispone di più certificazioni per la protezione dei propri data center. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance/ | Vedi
https://www.atlassian.com/trust/security/securitypractices#physical-security |
| 2.3 Crittografia dei dati | Atlassian applica la crittografia alla rete wireless interna, inclusa la modifica delle impostazioni predefinite del fornitore. Il team Workplace Technology di Atlassian protegge le nostre reti wireless utilizzando l'autenticazione WPA2-AES e la crittografia PEAP-EAP-MSCHAPv2. Effettuiamo l'autenticazione sulla nostra rete wireless tramite 802.1x utilizzando il nostro archivio di identità interno. Eseguiamo regolarmente la scansione dei punti di accesso wireless non autorizzati e gestiamo un elenco dei punti di accesso non autorizzati che vengono trovati.
Atlassian utilizza la versione 1.2 dello standard di settore Transport Layer Security ("TLS") per creare una connessione sicura tramite la crittografia Advanced Encryption Standard ("AES") a 256 bit. I server che contengono dati degli utenti utilizzano la crittografia completa del disco AES standard del settore. I dati del tenant sono crittografati all'interno dei backup AWS RDS o RDS e sono anche crittografati nell'archivio a lungo termine (S3) e in tutti gli allegati. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management | Le nostre policy di sicurezza e privacy dei dati
Crittografia dei dati | Atlassian Trust Center
Crittografia dei dati | Architettura e pratiche operative di Atlassian Cloud |
| 2.4 Sanificazione dei dati e smaltimento delle apparecchiature | Atlassian applica uno standard di conservazione e distruzione dei dati che indica per quanto tempo è tenuta a conservare dati di diversi tipi. I dati sono classificati in linea con la policy sulla sicurezza dei dati e la gestione del ciclo di vita delle informazioni di Atlassian, e i controlli sono implementati in base a quanto previsto da tale policy.
Per quanto riguarda i dati dei clienti, al momento della cessazione di un contratto Atlassian, i dati appartenenti a un team addetto ai clienti saranno rimossi dal database di produzione in tempo reale e tutti gli allegati caricati direttamente su Atlassian saranno rimossi entro 14 giorni. I dati del team rimarranno nei backup crittografati fino alla scadenza della finestra di conservazione dei backup di 90 giorni e saranno distrutti in conformità alla policy di conservazione dei dati di Atlassian. Qualora sia necessario eseguire il ripristino del database entro 90 giorni dalla richiesta di eliminazione dei dati, il team delle operazioni provvederà a eliminare di nuovo i dati non appena ragionevolmente possibile dopo il ripristino completo del sistema di produzione live. Per maggiori informazioni, consulta la pagina: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/ | Conservazione ed eliminazione dei dati | Atlassian Trust Center
Monitoraggio dell'archiviazione e spostamento dei dati tra prodotti | Assistenza Atlassian |
| 2.5 Resilienza fisica e disponibilità | I controlli di sicurezza fisica nei nostri uffici sono guidati dalla nostra policy di sicurezza fisica e ambientale che garantisce l'implementazione di una solida sicurezza fisica nei nostri ambienti on-premise e nel cloud. Questa policy si applica ad ambiti come le aree di lavoro sicure, la protezione delle nostre apparecchiature IT ovunque si trovino, la limitazione dell'accesso ai nostri edifici e uffici solo da parte del personale appropriato, e il monitoraggio dei punti fisici di ingresso e uscita. Le nostre pratiche di sicurezza fisica includono la presenza alla reception durante l'orario di lavoro, i requisiti per la registrazione dei visitatori, l'accesso con badge a tutte le aree non pubbliche; inoltre, collaboriamo con il nostro personale di amministrazione degli edifici degli uffici per l'accesso al di fuori dell'orario di lavoro e la registrazione video nei punti di ingresso e uscita, sia per gli ingressi principali che per le aree di carico.
I data center dei nostri partner sono conformi, come requisito minimo, allo standard SOC-2. Queste certificazioni riguardano una serie di controlli di sicurezza, tra cui sicurezza e la protezione fisica e ambientale. L'accesso ai data center è limitato al personale autorizzato e controllato mediante misure di verifica biometrica dell'identità. Le misure di sicurezza fisiche includono: presenza di personale di sorveglianza on-premise, monitoraggio video a circuito chiuso, mantrap e ulteriori misure di protezione contro le intrusioni.
Oltre alle misure indicate sopra, pubblichiamo anche lo stato di disponibilità del servizio in tempo reale per i clienti che utilizzano il nostro prodotto Statuspage. Qualora emergano problemi con uno dei nostri prodotti, i nostri clienti ne saranno informati tempestivamente. | Sicurezza fisica | Atlassian Trust Center |
| Principio 3: Separazione tra i clienti |
| | Sebbene i clienti condividano un'infrastruttura IT comune basata su cloud quando utilizzano i prodotti Atlassian, abbiamo implementato misure volte a garantirne la separazione logica, in modo che le azioni di un cliente non possano compromettere i dati o il servizio di altri clienti.
L'approccio adottato da Atlassian per raggiungere questo obiettivo varia a seconda delle applicazioni. Nel caso di Jira e Confluence Cloud, utilizziamo un concetto che definiamo "contesto del tenant" per ottenere l'isolamento logico dei nostri clienti. È implementato nel codice dell'applicazione ed è gestito da un servizio che abbiamo creato e chiamato "Tenant Context Service" (TCS). Questo concetto garantisce che:
- I dati di ogni cliente siano isolati logicamente dagli altri tenant quando sono inattivi.
- Le eventuali richieste elaborate da Jira o Confluence hanno una vista "specifica per tenant" in modo che non ci sia alcun impatto su altri tenant.
In generale, il funzionamento di TCS si basa sull'archiviazione di un "contesto" per i singoli tenant dei clienti. Il contesto di ciascun tenant è associato a un ID univoco archiviato centralmente da TCS e include un intervallo di metadati associati al tenant, ad esempio, i database in cui si trova il tenant, le licenze di cui il tenant dispone, le funzioni alle quali può accedere e una serie di altre informazioni di configurazione. Quando un cliente accede a Jira o a Confluence Cloud, TCS utilizza l'ID tenant per raccogliere i metadati, che vengono quindi collegati alle eventuali operazioni eseguite dal tenant nell'applicazione durante la sessione.
Il contesto fornito da TCS funge da "obiettivo" per mezzo del quale si verificano le interazioni con i dati dei clienti, e questo obiettivo è sempre limitato a un tenant specifico. In questo modo, un tenant del cliente non accede ai dati di un altro tenant e non può influire sul servizio di un altro tenant attraverso le proprie azioni.
Ulteriori informazioni sulla nostra architettura Cloud sono disponibili nell'ambito delle risorse di assistenza per Cloud. | Architettura e pratiche operative di Atlassian Cloud | Atlassian Trust Center |
| Principio 4: Framework di governance |
| | Atlassian riconosce che le entità regolamentate abbiano la necessità, come parte delle loro valutazioni del rischio, di esaminare i propri controlli interni, sistemi e meccanismi di sicurezza e privacy dei dati per i servizi. Atlassian è sottoposta ogni anno a diversi audit indipendenti di terze parti che vengono condotti sulle operazioni e i controlli interni dell'azienda.
Per visualizzare il nostro attuale programma di conformità, visita il Centro risorse per la conformità per accedere a tutte le verifiche e le certificazioni scaricabili dei nostri prodotti.
Atlassian dispone di un programma Enterprise Risk Management (ERM) allineato al modello di rischio COSO e a ISO 31000. Il programma ERM implementa un framework e una metodologia di gestione del rischio in Atlassian, ed esegue valutazioni annuali del rischio, valutazioni periodiche specifiche del rischio di un ambiente di prodotto e valutazioni funzionali del rischio secondo necessità in base al profilo di rischio.
In particolare, il framework di gestione del rischio di Atlassian fornisce standard, processi, ruoli e responsabilità, tolleranze di rischio accettabili e direttive per il completamento delle attività di valutazione del rischio. I nostri processi e pratiche di gestione del rischio sono alla base delle nostre valutazioni del rischio, che sono ripetibili e producono risultati validi, coerenti e comparabili. Le valutazioni del rischio eseguite da Atlassian comprendono la probabilità dell'evento di rischio e l'impatto per tutte le categorie di rischio, nonché il trattamento di tutti i rischi rispetto alla nostra propensione al rischio definita internamente. In tutte le fasi del programma ERM, il team Risk & Compliance comunica con gli stakeholder di pertinenza e si consulta con gli esperti in materia (SME) appropriati. | Le nostre policy sulla sicurezza e sulla privacy dei dati
Conformità e gestione dei rischi | Atlassian Trust Center
Atlassian Trust Management System (ATMS) | Atlassian Trust Center
Addendum sul trattamento dei dati | Atlassian Trust Center |
| Principio 5: Sicurezza operativa |
| 5.1 Gestione delle vulnerabilità | In Atlassian ci impegniamo costantemente per ridurre la gravità e la frequenza delle vulnerabilità nei nostri prodotti, nei nostri servizi e nella nostra infrastruttura, nonché per garantire che tali problematiche siano risolte il prima possibile. A tal fine, adottiamo un approccio multiforme e in continua evoluzione alla gestione delle vulnerabilità che utilizza processi sia automatizzati che manuali per identificare, monitorare e risolvere le vulnerabilità nei nostri prodotti e nella nostra infrastruttura.
Per tutte le nostre offerte di prodotti e servizi, disponiamo di un processo completo di correzione dei bug (attraverso il nostro prodotto Jira, che acquisisce i ticket e ci aiuta a gestire le richieste di risoluzione). Alla base di questo ci sono numerose policy di correzione dei bug di sicurezza, servizi di consulenza e SLO a cui aderiamo. Riceviamo le segnalazioni dei bug tramite il nostro canale di assistenza, il nostro programma Bug Bounty e security@atlassian.com. Ulteriori informazioni sono disponibili nel Trust Center (https://www.atlassian.com/trust) e nella pagina dedicata agli SLO di correzione dei bug di sicurezza (https://www.atlassian.com/trust/security/bug-fix-policy ).
Il team di sicurezza Atlassian utilizza diversi metodi per rilevare le vulnerabilità nell'infrastruttura interna ed esterna. I ticket Jira sono creati per finalità di monitoraggio e correzione, e le date di scadenza sono assegnate in conformità al nostro SLO in base sia alla gravità che all'origine della vulnerabilità. Disponiamo di un processo continuo che ci consente di inviare ticket per le vulnerabilità identificate ai responsabili dei sistemi e il nostro team di gestione della sicurezza esamina tutte le vulnerabilità segnalate e garantisce che vengano intraprese le opportune contromisure.
Maggiori informazioni sono disponibili nel nostro documento dedicato all'approccio di Atlassian alla gestione delle vulnerabilità.
Ulteriori informazioni sul nostro approccio ai test di sicurezza sono disponibili anche nella pagina: Il nostro approccio ai test di sicurezza esterni | Atlassian del nostro Trust Center. | Gestione delle vulnerabilità | Atlassian Trust Center
Policy di correzione dei bug di sicurezza | Atlassian Trust Center
Il nostro approccio ai test di sicurezza esterni | Atlassian Trust Center
Il nostro approccio alla gestione delle vulnerabilità | Atlassian Trust Center |
| 5.2 Monitoraggio protettivo | Consapevole della necessità di sviluppare il proprio approccio alla gestione degli imprevisti nel contesto di un panorama di minacce sempre più complesso, Atlassian ha introdotto il "Security Detections Program", cioè il suo programma per i rilevamenti di sicurezza. I rilevamenti sono il risultato di ricerche eseguite in modo proattivo e programmato sulla piattaforma di gestione degli imprevisti e degli eventi di sicurezza di Atlassian per individuare attività dannose rivolte ad Atlassian e i suoi clienti.
Il nostro team di rilevamento e risposta si concentra sulla creazione regolare di nuovi rilevamenti, sulla messa a punto e il miglioramento dei rilevamenti esistenti, nonché sull'automazione delle risposte ai rilevamenti. Svolge tale attività su diversi aspetti, tra cui prodotti, tipi di attacco e origini di log, in modo da garantire che la copertura dei nostri rilevamenti sia la più efficace e completa possibile.
L'obiettivo del programma è di assicurarci non solo di essere preparati per le minacce che affrontiamo oggi, ma di prevedere ed essere pronti a affrontare, con un sufficiente margine di anticipo, le potenziali minacce future. Il nostro team di rilevamento e risposta ha anche creato uno strumento per standardizzare i rilevamenti, al fine di garantire un elevato livello di coerenza e di qualità sui rilevamenti che eseguiamo: riteniamo che tale strumento sia una novità assoluta nel settore.
Abbiamo distribuito l'IDS nei nostri uffici e nel nostro ambiente di cloud hosting. Per la piattaforma Atlassian Cloud, l'inoltro dei log si integra con una piattaforma di analisi della sicurezza. I log di sistema chiave vengono inoltrati da ciascun sistema a una piattaforma centralizzata dove i log sono di sola lettura. Il team Atlassian Security crea avvisi sulla nostra piattaforma di analisi della sicurezza (Splunk) e monitora gli indicatori di compromissione. I nostri team SRE utilizzano la piattaforma per monitorare i ticket di disponibilità o prestazioni. I log vengono conservati per 30 giorni in un backup a caldo e per 365 giorni in un backup a freddo.
Ulteriori informazioni sul nostro programma di rilevamento sono disponibili alla pagina: https://www.atlassian.com/trust/security/detections-program | Programma di rilevamento Atlassian | Atlassian Trust Center
Utilizzo dei log | Atlassian Trust Center
Addendum sul trattamento dei dati | Atlassian Trust Center |
| 5.3 Gestione degli imprevisti | Atlassian adotta un approccio completo alla gestione degli incidenti di sicurezza. Consideriamo come imprevisto di sicurezza qualsiasi situazione che comporti un impatto negativo sulla riservatezza, l'integrità o la disponibilità dei dati dei nostri clienti, dei dati di Atlassian o dei servizi di Atlassian.
Disponiamo di un framework interno definito in modo chiaro che include playbook documentati per diversi tipi di imprevisti. Il framework comprende le misure che dobbiamo adottare in tutte le fasi di risposta agli imprevisti per garantire che i nostri processi siano coerenti, ripetibili ed efficienti. Tali misure includono il rilevamento e l'analisi degli imprevisti, nonché la categorizzazione, il contenimento, l'eliminazione degli imprevisti e il successivo ripristino. La coerenza è supportata dall'utilizzo dei nostri prodotti, tra cui Confluence, Jira e Bitbucket, come parte dei nostri processi di risposta agli imprevisti:
- Confluence è utilizzato per creare, documentare e aggiornare i nostri processi di risposta in una posizione centrale.
- Jira è utilizzato per creare ticket di monitoraggio dell'avanzamento nel processo di risposta per gli imprevisti di sicurezza (potenziali ed effettivi) dall'inizio alla fine.
- Bitbucket è utilizzato nei casi in cui sviluppiamo soluzioni basate su codice per rispondere a determinati problemi in situazioni limite che si verificano con determinati imprevisti.
La registrazione e il monitoraggio completi e centralizzati dei nostri prodotti e della nostra infrastruttura sono in grado di garantire il rilevamento rapido di potenziali imprevisti, con l'assistenza di un team di gestori degli imprevisti su chiamata altamente qualificati che hanno un'elevata esperienza nel coordinamento di una risposta efficace. Possiamo inoltre contare su una serie di esperti esterni che ci assistono nelle attività di indagine e risposta nel modo più efficace possibile.
Utilizziamo processi di notifica per i nostri clienti qualora si verifichi un imprevisto confermato che coinvolga i loro dati e ci avvaliamo di un solido processo di revisione post-imprevisto che ci consente di acquisire informazioni importanti sull'evento per migliorare le nostre pratiche e rendere più difficili in futuro i tentativi di accesso da parte di utenti malevoli. Per ulteriori informazioni, consulta il documento separato dal titolo Il nostro approccio alla gestione degli imprevisti di sicurezza nell'Atlassian Trust Center. | Gestione degli imprevisti | Atlassian Trust Center
Addendum sul trattamento dei dati | Atlassian Trust Center |
| 5.4 Gestione della configurazione e delle modifiche | Il nostro processo di gestione delle modifiche è leggermente diverso da quello tradizionale. I processi tradizionali di gestione delle modifiche si basano su una gerarchia piramidale di controllo delle modifiche. In altre parole, quando qualcuno vuole apportare una modifica, deve presentarla a un consiglio che alla fine la approva o la respinge.
Abbiamo adottato un approccio in stile open source che chiamiamo "Peer Review, Green Build" (PRGB). A differenza di un processo di gestione delle modifiche tradizionale, l'approccio PRGB richiede che ogni modifica, che si tratti di una modifica del codice o di una modifica dell'infrastruttura, venga esaminata da uno o più colleghi per identificare gli eventuali problemi che potrebbe causare. Aumentiamo il numero di revisori in base alla criticità della modifica o dei sistemi su cui la modifica avrà un impatto, affidandoci ai nostri tecnici per identificare i problemi e segnalarli prima che la modifica possa essere approvata. Questo processo è efficace per gestire le modifiche nell'ambiente in modo dinamico e adattabile. La parte "green build" del controllo si riferisce alla presenza di una build corretta o pulita nel nostro CI/CD in cui le nuove modifiche siano incluse. Se la modifica introduce componenti che non superano correttamente nessuno dei test di integrazione, funzione, unità o sicurezza, la build viene rifiutata e torna alla richiesta di modifica originale per risolvere eventuali problemi.
Il nostro approccio basato sull'utilizzo di un'"assistenza di qualità" (invece che sulla tradizionale "garanzia di qualità") è qualcosa che ci entusiasma: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance | Gestione delle modifiche al nostro ambiente | Atlassian Trust Center
Come passare dalla garanzia di qualità all'assistenza di qualità |
| Principio 6: Sicurezza del personale |
| | Valori aziendali
Le informazioni sui valori aziendali di Atlassian sono disponibili qui: https://www.atlassian.com/company/values
| Valori aziendali
Valori aziendali | Atlassian
|
| Controlli dei precedenti personali dei dipendenti
I nuovi Atlassiani a livello globale sono tenuti a completare un controllo dei precedenti personali. I neo dipendenti assunti a seguito di un'acquisizione devono essere sottoposti a un controllo dei precedenti personali dopo la data di acquisizione. Viene eseguito un controllo dei precedenti penali su tutti i neoassunti e i terzisti indipendenti, a cui si aggiungono la verifica dei titoli di studio, la verifica dei precedenti rapporti di impiego o i controlli creditizi qualora il ruolo o il livello della posizione lo richiedano. Eseguiamo controlli dei precedenti personali completi per i ruoli dirigenziali e contabili di alto livello. | Controlli dei precedenti personali dei dipendenti
Controlli dei precedenti | Atlassian Trust Center |
| Formazione in materia di sicurezza per tutti i dipendenti
Atlassian fornisce corsi di formazione in materia di sicurezza delle informazioni come elemento della formazione di onboarding ("giorno 1") per i principianti e su base continuativa per tutto il personale.
Oltre a questa formazione di carattere generale sulla sicurezza delle informazioni, viene fornita una formazione più mirata, destinata ai nostri sviluppatori, sulla codifica sicura, che è supportata dal nostro programma per i tecnici della sicurezza integrata.
Forniamo anche una formazione tematica continua in relazione al malware, al phishing e ad altri problemi di sicurezza. Sensibilizzazione alla sicurezza | Atlassian Trust Center | Formazione sulla sicurezza per tutti i dipendenti Atlassian
Security Awareness | Atlassian Trust Center |
| Principio 7: Sviluppo sicuro | Atlassian si avvale di pratiche sicure in tutte le fasi del ciclo di vita dello sviluppo. Consulta la pagina: https://www.atlassian.com/trust/security/security-in-development per maggiori informazioni.
Nella fase di progettazione, le pratiche includono la modellazione delle minacce, la revisione della progettazione e la nostra libreria di standard di sicurezza, regolarmente aggiornata, che garantisce l'applicazione dei requisiti di sicurezza appropriati.
Durante lo sviluppo, ci avvaliamo di un processo di peer review come prima linea della revisione della sicurezza. Tale processo è supportato da controlli automatizzati di analisi statica (SAST) e test di sicurezza manuali (condotti sia da team interni che da esperti di terze parti, come imposto dal nostro processo di valutazione del rischio). Lo sviluppo è anche supportato da programmi di formazione sulla sicurezza delle applicazioni e da una knowledge base di sicurezza gestita dal team di sicurezza.
I processi formali di preparazione operativa e controllo delle modifiche assicurano quindi che solo le modifiche approvate vengano distribuite in produzione. Dopo la distribuzione, ci avvaliamo di una scansione automatizzata delle vulnerabilità e di un programma Bug Bounty leader del settore (Programma Bug Bounty di Atlassian | Bugcrowd ) per eseguire una verifica continua delle nostre applicazioni.
Inoltre, puoi esaminare il report SOC 2 di Atlassian. L'obiettivo del report è valutare i sistemi di un'organizzazione rilevanti per la sicurezza, la disponibilità, l'integrità dell'elaborazione, la riservatezza e la privacy. | Addendum sul trattamento dei dati | Atlassian Trust Center |
| Principio 8: Sicurezza della supply chain | Qualora Atlassian coinvolga fornitori terzi (inclusi appaltatori e provider di servizi cloud), ci assicuriamo che le loro attività non compromettano in alcun modo i nostri clienti o i loro dati. A tale scopo, i nostri team legali e di approvvigionamento avviano un processo di revisione di qualsiasi attività di fornitori terzi proposti. Le eventuali attività che riteniamo siano a rischio elevato o critico sono soggette ad ulteriori revisioni da parte dei nostri team di sicurezza, rischio e conformità. Il processo di due diligence avviene anche tramite revisioni successive, sia al momento del rinnovo del contratto che annualmente a seconda del livello di rischio dell'attività.
Atlassian richiede inoltre ai suoi fornitori di rispettare i requisiti minimi di sicurezza nell'ambito dell'impegno assunto con noi. Questi requisiti vengono applicati tramite l'inclusione nei nostri contratti con i fornitori e variano a seconda del livello di rischio dell'attività. Includono:
- Integrazione di SAML con la piattaforma Single Sign-On di Atlassian.
- Crittografia dei dati in transito e inattivi utilizzando algoritmi non obsoleti.
- Meccanismi di registrazione sufficienti per fornire ad Atlassian informazioni pertinenti sui potenziali imprevisti di sicurezza.
| Gestione dei rischi associati ai fornitori | Atlassian Trust Center
Atlassian SOC 2 | Pagina 29 (Gestione dei fornitori) |
| Principio 9: Gestione sicura degli utenti |
| 9.1 Autenticazione degli utenti per l'accesso alle interfacce di gestione e i canali di assistenza | In Atlassian crediamo che la gestione del rischio sia una responsabilità condivisa tra cliente e Atlassian.
Utenti autenticati
Trattiamo tutti i dati dei clienti come ugualmente sensibili e abbiamo implementato controlli rigorosi che li disciplinano. Durante il processo di onboarding i nostri dipendenti interni e i terzisti seguono corsi di formazione di sensibilizzazione sull'importanza e le best practice della gestione dei dati dei clienti.
All'interno di Atlassian, solo gli Atlassiani autorizzati hanno accesso ai dati dei clienti memorizzati all'interno delle nostre applicazioni. L'autenticazione viene eseguita tramite singole chiavi pubbliche protette da passphrase e i server accettano solo connessioni SSH in ingresso da Atlassian e da sedi di data center interne. Tutti gli accessi sono riservati a gruppi con privilegi salvo richiesta di accesso da parte di gruppi diversi, che comporta un'autenticazione 2FA aggiuntiva.
Grazie ai rigorosi controlli di autenticazione e autorizzazione posti in essere, il nostro team di assistenza globale facilita i processi di manutenzione e assistenza. Le applicazioni e i dati in hosting sono accessibili allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione di sistemi o applicazioni, oppure su richiesta del cliente tramite il nostro sistema di assistenza. Ai nostri clienti vengono inoltre fornite varie opzioni di consenso esplicito in merito a quali tecnici di assistenza possano accedere ai loro dati tramite il nostro sistema di controllo dei consensi.
L'accesso non autorizzato o inappropriato ai dati dei clienti viene trattato come un imprevisto di sicurezza e gestito tramite il nostro processo di gestione degli imprevisti, che include istruzioni su come informare i clienti interessati qualora venga rilevata una violazione della policy. | Controllo dell'accesso ai dati dei clienti | Atlassian Trust Center
Addendum sul trattamento dei dati | Atlassian Trust Center |
| 9.2 Separazione e controllo degli accessi all'interno delle interfacce di gestione | Con questa architettura AWS, ospitiamo una serie di servizi di piattaforma e prodotto utilizzati nelle nostre soluzioni. Ciò include funzionalità di piattaforma condivise e utilizzate in più prodotti Atlassian, come Media, Identity e Commerce, esperienze come il nostro Editor, nonché funzionalità di prodotto specifiche, come il servizio Ticket di Jira e Confluence Analytics.
Gli sviluppatori Atlassian eseguono il provisioning di questi servizi tramite una piattaforma come servizio (PaaS) sviluppata internamente, denominata Micros, che orchestra automaticamente la distribuzione di servizi condivisi, infrastruttura, archivi dati e le relative funzionalità di gestione, inclusi i requisiti di sicurezza e controllo della conformità (vedi la figura 1 sopra). In genere, un prodotto Atlassian è costituito da più servizi "containerizzati" distribuiti su AWS tramite Micros. I prodotti Atlassian utilizzano le funzionalità principali della piattaforma (vedi la figura 2 di seguito) che vanno dal routing delle richieste agli archivi di oggetti binari, all'autenticazione/autorizzazione, al contenuto generato dagli utenti (UGC) transazionale e agli archivi di relazioni tra entità, data lake, registrazione comune, tracciamento delle richieste, osservabilità e servizi di analisi.
Oltre alla nostra infrastruttura cloud, abbiamo creato un'architettura di microservizi multi-tenant con una piattaforma condivisa che supporta i nostri prodotti. In un'architettura multi-tenant, un singolo servizio è utilizzato da più clienti e include le istanze di database e di calcolo necessarie per eseguire i nostri prodotti Cloud. Ogni partizione (essenzialmente un container, vedi la figura 3 di seguito) contiene i dati relativi a più tenant, ma i dati di ciascun tenant sono isolati e inaccessibili agli altri tenant. È importante notare che non offriamo un'architettura a singolo tenant.
Per saperne di più, visita la pagina https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Architettura multi-tenant | Architettura e pratiche operative di Atlassian Cloud
Addendum sul trattamento dei dati | Atlassian Trust Center |
| Principio 10: Identità e autenticazione |
| | Fai riferimento alle sezioni 9.1 e 9.2 per ulteriori informazioni sull'autenticazione e sulla gestione degli accessi. | N/D |
| Principio 11: Protezione dell'interfaccia esterna |
| | Fai riferimento al Principio 5 per ulteriori informazioni su come Atlassian Trust protegge i nostri clienti Cloud. | N/D |
| Principio 12: Amministrazione sicura dei servizi |
| | Nell'Addendum sul trattamento dei dati di Atlassian, ci impegniamo a proteggere i dati dei clienti, incluso il controllo degli accessi e la gestione dei privilegi.
Fai riferimento alle sezioni 9.1 e 9.2 per ulteriori informazioni sull'autenticazione e sulla gestione degli accessi. | N/D |
| Principio 13: Informazioni di audit per gli utenti |
| | Tutti gli accessi all'applicazione del Cliente sono registrati. Ogni interazione dell'interfaccia utente viene registrata nell'audit log dell'applicazione.
Atlassian limita, registra e monitora l'accesso privilegiato al nostro archivio di identità degli account Atlassian e ad altri sistemi di gestione della sicurezza delle informazioni.
I log sono archiviati in un sistema separato logicamente e l'accesso in scrittura ai log è limitato ai membri del team di sicurezza. Gli avvisi vengono inviati al team di sicurezza o al Service Desk quando nei log si identificano azioni o eventi specifici. Il nostro servizio di creazione di log centralizzato (che comprende la piattaforma Atlassian Cloud, Jira, Confluence e Bamboo) è integrato con la nostra infrastruttura di analisi della sicurezza per l'analisi automatizzata e vengono creati avvisi per identificare potenziali problemi.
Per Bitbucket, gli audit log vengono utilizzati per le indagini successive all'imprevisto. La configurazione del servizio gestito Puppet nel formato di configurazione dichiarativo garantisce che tutte le configurazioni di sistema gestite dai suoi manifesti siano configurate correttamente a ogni esecuzione. Qualora Puppet non venga eseguito su un determinato server, sono disponibili avvisi di monitoraggio. I nostri scanner delle vulnerabilità interni ed esterni includono avvisi relativi all'apertura imprevista di porte o altre modifiche alla configurazione (ad esempio, profili TLS dei server in ascolto).
Per ulteriori informazioni, consulta le seguenti pagine di Atlassian Access: Atlassian Access | Sicurezza e SSO per Jira, Confluence e così via.
Per Atlassian, i log sono archiviati in un sistema separato logicamente e l'accesso in scrittura ai log è limitato ai membri del team di sicurezza e del team Observability. Il nostro servizio di creazione di log centralizzato è integrato con la nostra infrastruttura di analisi della sicurezza per l'analisi automatizzata e vengono creati avvisi per identificare potenziali problemi.
Per i clienti Atlassian Cloud, gli audit log delle modifiche all'organizzazione sono disponibili in Atlassian Access. Gli audit log offrono visibilità sulle azioni di amministratore per utenti, gruppi, autorizzazioni, ecc. Ulteriori informazioni sono disponibili nella pagina: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
I prodotti Atlassian Cloud dispongono anche di un proprio sistema di audit log per le modifiche specifiche del prodotto. | N/D |
| Principio 14: Utilizzo sicuro del servizio |
| | In Atlassian crediamo che la gestione del rischio sia una responsabilità condivisa tra cliente e Atlassian.
È disponibile una serie di altre risorse a cui abbiamo fatto riferimento in questo documento o che è possibile consultare in altro modo per ottenere maggiori informazioni sul nostro approccio alla gestione delle vulnerabilità e, in generale, alla sicurezza.
| N/D |