ENISA: Agenzia europea per la sicurezza delle reti e dell'informazione

L'Agenzia europea per la sicurezza delle reti e dell'informazione (ENISA) è un centro di competenza in materia di reti e informazione. Lavora a stretto contatto con gli Stati membri dell'UE e il settore privato per fornire consigli e suggerimenti su pratiche di sicurezza informatica efficaci. L'ENISA supporta anche lo sviluppo e l'attuazione delle policy e delle leggi dell'UE relative alla sicurezza nazionale delle informazioni.

Il Cloud Computing Information Assurance Framework (IAF) dell'ENISA è un insieme di criteri di garanzia che le organizzazioni possono prendere in esame insieme ai provider di servizi cloud (Cloud Service Provider, CSP) per assicurarsi che questi ultimi prevedano protezioni sufficienti per i dati dei clienti. L'IAF ha lo scopo di valutare il rischio dell'adozione del cloud e ridurre l'onere della garanzia per i CSP.

Atlassian si allinea all'IAF grazie all'aderenza alla Cloud Controls Matrix (CCM) del Cloud Security Alliance (CSA), che mappa i domini e i controlli della CCM ai criteri di garanzia IAF, nonché alla certificazione rispetto a ISO 27001.

Atlassian mantiene le seguenti garanzie basate sulla CCM:

• Autovalutazione CSA STAR (Livello 1)

Le seguenti linee guida forniscono criteri di garanzia per assistere le organizzazioni nella scelta di un provider di servizi cloud. Per qualsiasi domanda su dettagli specifici, contatta il nostro team di vendita aziendale qui: https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

La maggior parte delle domande relative al personale sarà simile a quelle che faresti al tuo personale IT o ad altro personale che si occupa di IT. Come per la maggior parte delle valutazioni, c'è un equilibrio tra rischio e costo.

6.01. (a)

Quali policy e procedure applichi quando assumi i tuoi amministratori IT o altri dipendenti con accesso al sistema? Dovrebbero essere inclusi:

• Controlli pre-assunzione (identità, cittadinanza o status giuridico, storia professionale e referenze lavorative, condanne penali e verifiche, nel caso di personale senior con ruoli ad alto privilegio).

In conformità alle leggi del loro paese di residenza, i nuovi Atlassiani sono tenuti a completare un controllo dei precedenti personali. In conformità alle leggi del loro paese di residenza, 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.

6.01. (b)

Esistono policy diverse a seconda di dove vengono archiviati i dati o eseguite le applicazioni?

• Ad esempio, le policy di assunzione possono essere diverse tra una regione e l'altra.
• Le pratiche devono essere coerenti in tutte le regioni.
• È possibile che i dati sensibili vengano archiviati in una determinata regione con personale appropriato.

Atlassian applica restrizioni sul personale che ha bisogno dell'accesso ai nostri sistemi, alle applicazioni e all'infrastruttura per il proprio ruolo e le proprie responsabilità lavorative sulla base del privilegio minimo e ciò avviene attraverso i nostri processi di autenticazione. Tutti gli accessi avvengono tramite sessioni autenticate e sulla base di autorizzazioni stabilite.

Tutti i sistemi di livello 1 sono gestiti tramite una soluzione centralizzata di Single Sign-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à.

Più in generale, i controlli relativi al controllo degli accessi sono trattati nella Policy di gestione degli accessi, un estratto della quale è disponibile qui: https://www.atlassian.com/trust

6.01. (c)

Quale programma di formazione in materia di sicurezza svolgi per tutto il personale?

Atlassian fornisce corsi di formazione in materia di sicurezza delle informazioni come elemento della formazione di onboarding ("giorno 1") per i neo assunti 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. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Conserviamo registri formali sul completamento dei corsi di formazione da parte del personale interno. I dipendenti sono tenuti a prendere atto del Codice di condotta e a riaffermarlo con cadenza annuale. Questa policy viene fornita a tutti i dipendenti. I requisiti di consapevolezza in materia di sicurezza, riservatezza e privacy vengono presentati durante il primo giorno di formazione e sono disponibili per tutti i dipendenti in Confluence.

6.01. (d)

Esiste un processo di valutazione continua?

• Con quale frequenza avviene?
• Ulteriori interviste.
• Revisione degli accessi e dei privilegi di sicurezza.
• Revisione di policy e procedure.

Atlassian ha ottenuto le certificazioni SOC2, ISO27001 e ISO27018 per i nostri servizi cloud. Eseguiamo sia audit di idoneità interni/esterni sia audit esterni almeno una volta l'anno. Atlassian è certificato ISO per una serie di prodotti, il che richiede valutazioni periodiche dei rischi e revisioni delle pratiche relative ai dati.

Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/compliance. I clienti devono scaricare e controllare regolarmente gli aggiornamenti ai nostri certificati e ai nostri report di conformità da questo sito.

Atlassian possiede un framework di policy documentato, con la nostra Policy di sicurezza come policy principale. Il nostro Policy Management Program (PMP) è stato definito, include informazioni in materia di responsabilità, disponibilità e ciclo di revisione e delinea i nostri obiettivi generali. Le nostre policy vengono riviste almeno una volta l'anno e sono approvate dai dirigenti. Ulteriori informazioni sul nostro PMP sono disponibili qui: https://www.atlassian.com/trust/security/security-management-program

Abbiamo pubblicato anche alcuni estratti di ciascuna delle nostre policy di alto livello con tl:dr, che puoi trovare qui: https://www.atlassian.com/trust/security/ismp-policies

Tutti i sistemi e i progetti sono sottoposti a una valutazione d'impatto in relazione alle informazioni di identificazione personale.

I Contratti con terze parti di Atlassian includono, secondo i casi, disposizioni sulla sicurezza e sulla privacy. I nuovi fornitori di Atlassian sono tenuti ad accettare le policy in materia di privacy e sicurezza presenti nei nostri contratti. I nostri team legali e di approvvigionamento esaminano i contratti, gli SLA e le policy interne dei fornitori per gestire i rischi associati alla sicurezza, alla disponibilità e alla riservatezza. Il programma Enterprise Risk Management (ERM) di Atlassian esegue una valutazione annuale dei rischi che include la probabilità e l'impatto per tutte le categorie di rischio ed è allineato al modello dei rischi COSO. Se necessario, eseguiamo anche valutazioni dei rischi funzionali in base al profilo di rischio. Le valutazioni dei rischi vengono riviste nell'ambito del rinnovo delle policy e tutte le volte che il rapporto con il fornitore cambia in modo significativo.

6.02.

Le seguenti domande vengono poste quando il fornitore di servizi cloud subappalta a terzi alcune operazioni fondamentali per la sicurezza operativa (ad esempio, un provider SaaS che esternalizza la piattaforma subordinata a un fornitore terzo, un fornitore di servizi cloud che esternalizza i servizi di sicurezza a un fornitore di servizi di sicurezza gestiti, un fornitore esterno a cui ci si affida per la gestione delle identità dei sistemi operativi, ecc.). Queste domande vengono poste, inoltre, in caso di terze parti con accesso fisico o remoto all'infrastruttura del fornitore cloud. L'intero questionario si può applicare con una certa frequenza a fornitori di servizi cloud terzi (o ennesimi).

6.02. (a)

Definisci i servizi esternalizzati o subappaltati nella catena di fornitura dei servizi che sono fondamentali per la sicurezza (e la disponibilità) delle tue operazioni.

Atlassian lavora con subappaltatori di terzi per fornire servizi come siti web, sviluppo di applicazioni, hosting, manutenzione, backup, archiviazione, infrastruttura virtuale, elaborazione dei pagamenti e analisi. Una lista dei sub-responsabili attualmente ingaggiati da Atlassian e autorizzati dal Cliente è riportata all'indirizzo https://www.atlassian.com/legal/sub-processors.

6.02. (b)

Descrivi in dettaglio le procedure utilizzate per concedere a terzi l'accesso alla tua infrastruttura (fisica e/o logica).

• Effettui i controlli delle esternalizzazioni e dei subappaltatori? Con quale frequenza?

I nostri team legali e di approvvigionamento esaminano i contratti, gli SLA e le policy interne dei fornitori per gestire i rischi associati alla sicurezza, alla disponibilità e alla riservatezza. Se necessario, eseguiamo anche valutazioni dei rischi funzionali in base al profilo di rischio. Le valutazioni dei rischi vengono riviste nell'ambito del rinnovo delle policy e tutte le volte che il rapporto con il fornitore cambia in modo significativo. La nostra politica di gestione dei dati di & terze parti dei fornitori copre questo processo, di cui un estratto è disponibile qui: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

Le disposizioni SLA garantite dalle esternalizzazioni sono inferiori agli SLA che offri ai tuoi clienti? In caso contrario, hai una ridondanza di fornitori?

A seconda dell'accordo di licenza, le Condizioni d'uso per i clienti cloud devono essere esaminate al rinnovo dell'abbonamento mensile o annuale. I nostri team legali e di approvvigionamento esaminano i contratti, gli SLA e le policy interne dei fornitori per gestire i rischi associati alla sicurezza, alla disponibilità e alla riservatezza. Il programma Enterprise Risk Management (ERM) di Atlassian esegue una valutazione annuale dei rischi che include la probabilità e l'impatto per tutte le categorie di rischio ed è allineato al modello dei rischi COSO. Se necessario, eseguiamo anche valutazioni dei rischi funzionali in base al profilo di rischio. Le valutazioni dei rischi vengono riviste nell'ambito del rinnovo delle policy e tutte le volte che il rapporto con il fornitore cambia in modo significativo.

6.02. (d)

Quali misure vengono prese per garantire che i livelli di servizio di terze parti siano soddisfatti e mantenuti?

I nostri team legali e di approvvigionamento esaminano i contratti, gli SLA e le policy interne dei fornitori per gestire i rischi associati alla sicurezza, alla disponibilità e alla riservatezza. Se necessario, eseguiamo anche valutazioni dei rischi funzionali in base al profilo di rischio. Le valutazioni dei rischi vengono riviste nell'ambito del rinnovo delle policy e tutte le volte che il rapporto con il fornitore cambia in modo significativo. La nostra politica di gestione dei dati di & terze parti dei fornitori copre questo processo, di cui un estratto è disponibile qui: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

Il fornitore di servizi cloud può confermare che la politica e i controlli di sicurezza sono applicati (contrattualmente) ai suoi fornitori terzi?

Tutti i sistemi e i progetti sono sottoposti a una valutazione dell'impatto in relazione alle informazioni personali. I Contratti con terze parti di Atlassian includono, secondo i casi, disposizioni sulla sicurezza e sulla privacy. I nuovi fornitori di Atlassian sono tenuti ad accettare le policy in materia di privacy e sicurezza presenti nei nostri contratti.

I nostri team legali e di approvvigionamento esaminano i contratti, gli SLA e le policy interne dei fornitori per gestire i rischi associati alla sicurezza, alla disponibilità e alla riservatezza. Il programma Enterprise Risk Management (ERM) di Atlassian esegue una valutazione annuale dei rischi che include la probabilità e l'impatto per tutte le categorie di rischio ed è allineato al modello dei rischi COSO. Se necessario, eseguiamo anche valutazioni dei rischi funzionali in base al profilo di rischio. Le valutazioni dei rischi vengono riviste nell'ambito del rinnovo delle policy e tutte le volte che il rapporto con il fornitore cambia in modo significativo.

6.03.

Qualsiasi accordo commerciale con fornitori esterni dovrebbe includere i livelli di servizio per tutti i servizi di rete. Tuttavia, oltre all'accordo definito, il cliente finale dovrebbe comunque assicurarsi che il fornitore utilizzi controlli appropriati per mitigare la divulgazione non autorizzata.

6.03. (a)

Descrivi la tua procedura e la tua politica di controllo delle modifiche. Nella descrizione dovresti includere anche il processo utilizzato per valutare nuovamente i rischi a seguito di modifiche e chiarire se i risultati sono disponibili per i clienti finali.

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.

Il personale addetto ai processi di gestione del rischio di Atlassian è adeguatamente consapevole e formato circa le proprie responsabilità e lo svolgimento delle proprie mansioni. Tutti i rischi vengono monitorati e gestiti utilizzando il nostro strumento Jira, con proprietà a livello di gestione con piani e progetti di trattamento associati. Per maggiori informazioni, vedi: https://www.atlassian.com/trust/security/security-management-program o https://www.atlassian.com/trust/compliance/risk-management-program

Il nostro processo Atlassian Change Management è leggermente diverso dai processi di gestione delle modifiche tradizionali. Facciamo affidamento su un controllo Peer Review and Green Build (PRGB) per tutte le modifiche, che si tratti di modifiche al codice, alle applicazioni o all'infrastruttura. La Peer Review è configurata nel nostro strumento CD, dove è necessario designare i branch critici per avere più revisori per ogni richiesta pull. Di solito si tratta di due sviluppatori e del team leader. La parte Green Build del controllo indica che l'integrazione durante la fase CI deve superare tutti i test di integrazione, funzionalità, sicurezza e altro ancora che sono stati sviluppati. Se i test hanno esito negativo (una Red Build), il codice non verrà incorporato e sarà necessario revisionarlo nuovamente e risolvere i problemi. Una volta ottenuta una Green Build, il file binario viene firmato in modo crittografico e il nostro ambiente di produzione esegue solo i binari firmati con la nostra chiave. Il nostro processo di test include sia componenti di valutazione automatizzati sia manuali. Ci piace parlare di ciò che sappiamo fare bene. Il nostro approccio basato sull'utilizzo di un'"assistenza alla qualità" (invece che sulla tradizionale "garanzia di qualità") è qualcosa che ci entusiasma: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Definisci la politica di accesso remoto.

I requisiti di accesso remoto sono definiti nella Politica di gestione degli accessi e negli standard associati. I dati dei clienti possono essere replicati sulle postazioni di lavoro dei dipendenti per scopi di supporto o migrazione e con richieste di assistenza dei clienti attive. Sono in vigore rigide regole firewall che limitano l'accesso all'ambiente di produzione alla nostra rete VPN e ai sistemi autorizzati. Il nostro accesso alla VPN richiede l'autenticazione a più fattori.

Tutti i dispositivi (di proprietà di Atlassian o BYOD) utilizzati dai dipendenti Atlassian che possono accedere a QUALSIASI strumento Atlassian sono registrati nella gestione dei dispositivi utilizzando i profili di sicurezza del software MDM e il controllo del livello di sicurezza. Atlassian utilizza un modello di sicurezza Zero Trust per tutti i dispositivi Atlassian. Leggi qui per saperne di più: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

Il provider mantiene documentate le procedure operative dei sistemi informativi?

Tra i principi di base della sicurezza delle operazioni di Atlassian vi è lo sviluppo di documenti contenenti le procedure operative standard. Abbiamo pubblicato anche alcuni estratti di ciascuna delle nostre policy di alto livello con tl:dr, che puoi trovare qui: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Esiste un ambiente di staging per ridurre il rischio, ad esempio ambienti di sviluppo, di testing e operativi? Sono separati tra loro?

Atlassian ha politiche di sicurezza delle informazioni che vietano l'uso dei dati di produzione in ambienti non destinati alla produzione e, inoltre, qualsiasi tentativo di migrazione dei dati tra gli ambienti verrebbe identificato attraverso il processo di gestione delle modifiche. Il codice passa prima da un sistema di build centralizzato con il test delle unità e poi alla convalida del branch di funzione con ulteriore automazione dei test e revisioni dei gate da parte dei PM, del team di sviluppo e del team addetto al controllo di qualità. Successivamente, passa ai test UAT, di sicurezza e delle prestazioni. Gli sviluppatori non possono promuovere direttamente il codice alla produzione. Ulteriori dettagli sono disponibili all'indirizzo https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

Manteniamo la separazione logica e fisica degli ambienti di produzione e non di produzione (sviluppo) per tutti i nostri servizi critici.

Il nostro ambiente di staging è separato a livello logico, ma non a livello fisico, ed è gestito conformemente a processi di controllo e accesso delle modifiche a livello di produzione. Per ulteriori informazioni sulle nostre pratiche di sicurezza del codice, vedi: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Definisci i controlli dell'host e della rete utilizzati per proteggere i sistemi che ospitano le applicazioni e le informazioni del cliente finale. Dovresti includere dettagli sulla certificazione rispetto a standard esterni (ad esempio, ISO 27001/2).

Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall nel cloud e in sede. Inoltre, abbiamo implementato le tecnologie IDS nei nostri ambienti di ufficio. 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.

Atlassian ha ottenuto le certificazioni SOC2, ISO27001 e ISO27018 per i nostri servizi cloud. Eseguiamo sia audit di idoneità interni/esterni sia audit esterni almeno una volta l'anno.

Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/compliance. I clienti devono scaricare e controllare regolarmente gli aggiornamenti ai nostri certificati e ai nostri report di conformità da questo sito.

6.03. (f)

Specifica i controlli che utilizzi per proteggerti dal codice dannoso.

Atlassian ha implementato Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) per la nostra flotta Windows e Mac. Non utilizziamo anti-malware sulle nostre macchine Linux. Gli anti-malware sono inclusi nella nostra politica di gestione delle vulnerabilità.

Abbiamo una politica di gestione delle minacce e delle vulnerabilità. Abbiamo definito il nostro Policy Management Program (PMP), che include informazioni in materia di responsabilità, disponibilità e ciclo di revisione, oltre a delineare i nostri obiettivi generali. Le nostre policy vengono riviste almeno una volta l'anno e sono approvate dai dirigenti. Ulteriori informazioni sul nostro PMP sono disponibili qui: https://www.atlassian.com/trust/security/security-management-program

Abbiamo pubblicato anche alcuni estratti di ciascuna delle nostre policy di alto livello con tl:dr, che puoi trovare qui: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Le configurazioni sicure vengono implementate solo per consentire l'esecuzione del codice mobile e delle funzionalità autorizzati (ad esempio, eseguire solo comandi specifici)?

Tutti i server sono configurati con il nostro sistema di configurazione Puppet centralizzato sul nostro ambiente operativo standard, inclusa la rimozione di pacchetti selezionati dall'immagine predefinita e gli aggiornamenti dei pacchetti critici. Tutti i ruoli del server sono configurati per impostazione predefinita sul rifiuto di tutte le richieste di rete in entrata, con porte selezionate aperte solo agli altri ruoli del server che richiedono l'accesso a tale porta per la loro funzione.

La nostra rete aziendale è separata dalla rete di produzione e alle immagini delle macchine è applicata la protezione avanzata per consentire solo le porte e i protocolli necessari. Tutti i sistemi di produzione sono attualmente ospitati nelle regioni degli Stati Uniti del nostro fornitore di servizi cloud. Tutti i dati in transito al di fuori delle reti cloud private virtuali (VPC) con protezione avanzata sono crittografati su canali standard del settore.

Inoltre, su tutti i server di produzione è presente un sistema IDS, che include il monitoraggio e la creazione di avvisi in tempo reale sulle modifiche ai file o alla configurazione del sistema di produzione e sugli eventi di sicurezza anomali.

Inoltre, abbiamo implementato una soluzione centralizzata di gestione del sistema (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) per la nostra flotta di laptop Mac. Utilizziamo la crittografia completa del disco sui nostri laptop. Inoltre, abbiamo implementato una soluzione di gestione dei dispositivi mobili per i nostri smartphone (https://www.vmware.com/products/workspace-one.html). Tutti i dispositivi devono essere registrati per accedere ai sistemi e alle applicazioni interni. Se un dispositivo mobile non è registrato, non può accedere a nessuna risorsa interna e si trova su una rete ospite che può accedere solo a Internet. L'accesso è gestito tramite controlli di accesso basati sui ruoli per garantire che solo gli utenti che richiedono l'accesso ai dati dei clienti/tenant ne siano in possesso.

6.03. (h)

Le policy e le procedure dettagliate per il backup dovrebbero includere procedure per la gestione dei contenuti multimediali rimovibili e metodi per la distruzione sicura di quelli non più necessari. (A seconda delle sue esigenze aziendali, il cliente potrebbe voler mettere in atto una strategia di backup indipendente. Ciò è particolarmente rilevante laddove è richiesto un accesso urgente al backup.)

In Atlassian gestiamo un programma di backup completo, che include i nostri sistemi interni, in cui le misure di backup sono progettate in linea con i requisiti di ripristino del sistema. Per quanto riguarda i nostri prodotti Cloud, e in particolare i dati dei clienti e delle applicazioni, abbiamo implementato anche estese misure di backup. Utilizziamo la funzione snapshot di Amazon RDS (Relational Database Service) per creare backup giornalieri automatizzati di ogni istanza RDS. Le snapshot di Amazon RDS vengono conservate per 30 giorni con il supporto del ripristino point-in-time e vengono crittografate utilizzando la crittografia AES-256. I dati di backup non vengono archiviati fuori sede, ma vengono replicati in più data center all'interno di una determinata regione AWS. Eseguiamo anche test trimestrali dei nostri backup. Per Bitbucket, i dati vengono replicati in una regione AWS diversa e ogni giorno si eseguono backup indipendenti all'interno di ciascuna regione.

Non utilizziamo questi backup per ripristinare le modifiche distruttive avviate dal cliente, come campi sovrascritti con script o ticket, progetti e siti eliminati. Per evitare la perdita di dati, consigliamo di effettuare i backup con regolarità. Per sapere di più sulla creazione di backup, consulta la documentazione di supporto per il tuo prodotto. I clienti devono inoltre eseguire i propri backup periodici per poter ripristinare le modifiche avviate dal cliente. Per maggiori informazioni, vedi: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

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/

Gli audit log vengono utilizzati in caso di imprevisto che richieda indagini e la risoluzione dei problemi. A tal fine, il cliente dovrà avere la certezza che tali informazioni siano disponibili.

6.03. (i)

Il fornitore può comunicare nel dettaglio le informazioni registrate negli audit log?

• Per quanto tempo vengono conservati questi dati?
• È possibile segmentare i dati all'interno degli audit log, rendendoli disponibili al cliente finale e/o alle forze dell'ordine senza compromettere gli altri clienti ed essere comunque ammissibili in tribunale?
• Quali controlli vengono effettuati per proteggere i log da accessi non autorizzati o manomissioni?
• Che metodo viene utilizzato per verificare e proteggere l'integrità degli audit log?

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.

Atlassian limita la capacità di visualizzare e leggere gli audit log al personale autorizzato sulla nostra piattaforma di registrazione centralizzata.

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/

6.03. (j)

Come vengono esaminati gli audit log? Quali eventi registrati portano a un'azione intrapresa?

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.

Atlassian limita la capacità di visualizzare e leggere gli audit log al personale autorizzato sulla nostra piattaforma di registrazione centralizzata.

6.03. (k)

Quale fonte oraria viene utilizzata per sincronizzare i sistemi e fornire un indicatore data/ora accurato degli audit log?

Atlassian Cloud utilizza AWS Time Sync per tutte le istanze distribuite.

6.03.01. (a)

Definisci i controlli utilizzati per proteggere l'integrità del sistema operativo e delle applicazioni software in uso. Includi tutti gli standard seguiti, ad esempio OWASP, SANS Checklist, SafeCode.

Il team di tecnici della sicurezza esegue una revisione continua di tutto il codice sorgente dei nostri prodotti come parte del nostro ciclo di sviluppo. Vengono impiegate tecniche automatizzate e manuali. Utilizziamo anche un processo obbligatorio di dual peer review, in cui più sviluppatori senior o capi sviluppatore esaminano tutti i commit da padroneggiare. I flussi di lavoro agili ci consentono di identificare e correggere rapidamente eventuali vulnerabilità, soprattutto per i nostri servizi cloud.

Il processo di revisione sicura del codice di Atlassian include la scansione automatica (ad es. l'analisi della composizione del software) per le vulnerabilità note, comprese quelle sfruttate negli attacchi del mondo reale. Inoltre, il nostro programma di gestione delle vulnerabilità analizza gli host e le immagini dei container alla ricerca di vulnerabilità note utilizzando Snyk. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/vulnerability-management.

Collaboriamo con BugCrowd per mantenere un programma Bug Bounty, che consente di condurre valutazioni continue delle vulnerabilità delle nostre applicazioni e i nostri servizi disponibili al pubblico. Il programma è disponibile all'indirizzo: https://bugcrowd.com/atlassian. Condividiamo i risultati dei continui test di penetrazione del nostro programma Bug Bounty all'indirizzo: https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Come si verifica che i nuovi rilasci siano adatti allo scopo o che non presentino rischi (backdoor, trojan, ecc.)? Vengono esaminati prima dell'uso?

Il nostro processo Atlassian Change Management è leggermente diverso dai processi di gestione delle modifiche tradizionali. Facciamo affidamento su un controllo Peer Review and Green Build (PRGB) per tutte le modifiche, che si tratti di modifiche al codice, alle applicazioni o all'infrastruttura. La Peer Review è configurata nel nostro strumento CD, dove è necessario designare i branch critici per avere più revisori per ogni richiesta pull. Di solito si tratta di due sviluppatori e del team leader. La parte Green Build del controllo indica che l'integrazione durante la fase CI deve superare tutti i test di integrazione, funzionalità, sicurezza e altro ancora che sono stati sviluppati. Se i test hanno esito negativo (una Red Build), il codice non verrà incorporato e sarà necessario revisionarlo nuovamente e risolvere i problemi. Una volta ottenuta una Green Build, il file binario viene firmato in modo crittografico e il nostro ambiente di produzione esegue solo i binari firmati con la nostra chiave. Il nostro processo di test include sia componenti di valutazione automatizzati sia manuali. Ci piace parlare di ciò che sappiamo fare bene. Il nostro approccio basato su "assistenza alla qualità" (anziché sulla tradizionale "garanzia di qualità") è qualcosa che ci entusiasma: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Dopo la distribuzione, ci avvaliamo di una scansione automatizzata delle vulnerabilità e di un programma Bug Bounty leader del settore (https://bugcrowd.com/atlassian) per eseguire una verifica continua delle nostre applicazioni. Le modifiche alla configurazione del sistema sono gestite da un processo automatizzato che include la revisione.

Il processo di revisione sicura del codice di Atlassian include la scansione automatica (ad es. l'analisi della composizione del software) per le vulnerabilità note, comprese quelle sfruttate negli attacchi del mondo reale. Inoltre, il nostro programma di gestione delle vulnerabilità analizza gli host e le immagini dei container alla ricerca di vulnerabilità note utilizzando Snyk. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

Quali procedure vengono seguite per proteggere le applicazioni?

Le nostre applicazioni richiedono una Peer Review and Green Build (PRGB), seguita dalla firma in modo crittografico degli artefatti delle applicazioni e dalla distribuzione automatica dalla nostra pipeline CI/CD. Inoltre, solo le applicazioni firmate da Atlassian possono essere eseguite nel nostro ambiente di produzione.

Ci avvaliamo 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 (https://bugcrowd.com/atlassian) per eseguire una verifica continua delle nostre applicazioni. Le modifiche alla configurazione del sistema sono gestite da un processo automatizzato, che include la revisione di tutte le modifiche prima della distribuzione alla produzione. Atlassian Service Operations può distribuire le patch non appena viene identificato un rischio significativo. Disponiamo di criteri interni per determinare la velocità di implementazione di qualsiasi patch e possiamo applicarli entro 12 ore per tutte le macchine. Esiste anche un sistema IDS che include il monitoraggio dei file di configurazione del sistema.

6.03.01. (d)

È stato effettuato un test di penetrazione di una versione software per garantire che non contenga vulnerabilità? Se vengono scoperte delle vulnerabilità, qual è la procedura per porvi rimedio?

Ci avvaliamo 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.

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 (https://bugcrowd.com/atlassian) per eseguire una verifica continua delle nostre applicazioni.

6.03.02. (a)

Vengono forniti dettagli sulla procedura di gestione delle patch seguita?

Abbiamo una politica di gestione delle minacce e delle vulnerabilità. Abbiamo definito il nostro Policy Management Program (PMP), che include informazioni in materia di responsabilità, disponibilità e ciclo di revisione, oltre a delineare i nostri obiettivi generali. Le nostre policy vengono riviste almeno una volta l'anno e sono approvate dai dirigenti. Ulteriori informazioni sul nostro PMP sono disponibili all'indirizzo: https://www.atlassian.com/trust/security/security-management-program

Abbiamo pubblicato anche alcuni estratti di ciascuna delle nostre policy di alto livello con tl:dr, che puoi trovare all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies

Atlassian utilizza una combinazione di gestione degli endpoint per distribuire aggiornamenti e patch ai sistemi operativi e alle applicazioni chiave della nostra flotta di endpoint. Abbiamo inoltre implementato diverse soluzioni per proteggere gli endpoint da minacce come il malware. Per maggiori dettagli, vedi: https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

È garantito che il processo di gestione delle patch copra tutti i livelli delle tecnologie di distribuzione del cloud, come la rete (componenti dell'infrastruttura, router e switch, ecc.), i sistemi operativi dei server, il software di virtualizzazione, le applicazioni e i sottosistemi di sicurezza (firewall, gateway antivirus, sistemi di rilevamento delle intrusioni, ecc.)?

Le modifiche alla configurazione del sistema sono gestite da un processo automatizzato, che include la revisione di tutte le modifiche prima della distribuzione alla produzione. Atlassian Service Operations può distribuire le patch non appena viene identificato un rischio significativo. Disponiamo di criteri interni per determinare la velocità di implementazione di qualsiasi patch e possiamo applicarli entro 12 ore per tutte le macchine. Esiste anche un sistema IDS che include il monitoraggio dei file di configurazione del sistema.

I prodotti Atlassian Cloud possono essere aggiornati all'AMI più recente con la rapidità necessaria. Le nostre applicazioni SaaS vengono aggiornate più volte alla settimana. Per gli aggiornamenti del nostro codice e delle configurazioni di sistema disponiamo di meccanismi di distribuzione rapidi e controllati. Atlassian utilizza attivamente un controllo delle modifiche per identificare quelle non pianificate e di emergenza.

6.03.03. (a)

Definisci i controlli utilizzati per mitigare gli attacchi DDoS (distributed denial-of-service).

• Difesa approfondita (analisi approfondita dei pacchetti, limitazione del traffico, blocco dei pacchetti, ecc.).
• Esistono difese contro gli attacchi "interni" (provenienti dalle reti dei provider cloud) ed esterni (provenienti dalle reti Internet o dei clienti)?
<

I requisiti di sicurezza della rete sono definiti nella Policy di sicurezza delle comunicazioni, che viene rivista ogni anno in linea con il nostro Policy Management Program (PMP). Per maggiori informazioni sul PMP, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

La piattaforma Atlassian Cloud dispone di una superficie molto ridotta esposta ai firewall. Le regole dei firewall vengono riviste su base periodica. 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. A livello di container della piattaforma Cloud, l'integrità dei file viene mantenuta in quanto le istanze non sono modificabili. Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall e abbiamo implementato tecnologie IDS nei nostri uffici e negli ambienti cloud. Le funzionalità DDoS sono fornite dal nostro fornitore/gestore di servizi Internet.

Le prestazioni dei firewall vengono inoltre valutate regolarmente attraverso programmi di valutazione delle vulnerabilità (https://www.atlassian.com/trust/security/vulnerability-management) e test di penetrazione (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Quali livelli di isolamento vengono utilizzati?

• Per macchine virtuali, macchine fisiche, rete, archiviazione (ad esempio reti SAN), reti di gestione e sistemi di supporto alla gestione ecc.
<

Atlassian è un'applicazione SaaS multi-tenant. La multi-tenancy è una funzionalità chiave di Atlassian Cloud che consente a più clienti di condividere un'istanza del livello applicativo Jira o Confluence, isolando al contempo i dati dell'applicazione di ogni tenant del cliente. Atlassian Cloud realizza questo obiettivo tramite il Tenant Context Service (TCS). Ogni ID utente è associato esattamente a un tenant, che viene poi utilizzato per accedere alle applicazioni Atlassian Cloud. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Manteniamo la separazione logica e fisica tra gli ambienti di produzione e non di produzione (sviluppo) servendoci dei metodi per il loro isolamento.

Il nostro ambiente di staging è separato a livello logico (ma non a livello fisico) ed è gestito conformemente ai processi di accesso e controllo delle modifiche a livello di produzione.

6.03.03. (c)

L'architettura supporta il funzionamento continuo dal cloud quando l'azienda è separata dal fornitore di servizi e viceversa (ad esempio esiste una dipendenza critica dal sistema LDAP del cliente)?

Sono in vigore policy e piani di continuità aziendale e ripristino di emergenza che vengono rivisti su base annuale dal comitato direttivo per la continuità aziendale e il ripristino di emergenza. Per maggiori informazioni, consulta le pagine: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e e https://www.atlassian.com/trust/security/data-management.

Atlassian utilizza le strutture dei data center ad alta disponibilità di AWS in più regioni del mondo per garantire il funzionamento continuo. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

L'infrastruttura di rete virtuale utilizzata dai fornitori di servizi cloud (nelle PVLAN e nell'architettura VLAN con tagging 802.1q) è protetta secondo gli standard e/o le best practice specifici del fornitore (ad esempio lo spoofing del MAC, gli attacchi di avvelenamento ARP e così via sono evitati tramite una configurazione di sicurezza specifica)?

I requisiti di sicurezza della rete sono definiti nella Policy di sicurezza delle comunicazioni, che viene rivista ogni anno in linea con il nostro Policy Management Program (PMP). Per maggiori informazioni sul PMP, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

La piattaforma Atlassian Cloud dispone di una superficie molto ridotta esposta ai firewall. Le regole dei firewall vengono riviste su base periodica. Abbiamo implementato 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. A livello di container della piattaforma Cloud, l'integrità dei file viene mantenuta in quanto le istanze non sono modificabili. Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall e abbiamo implementato tecnologie IDS nei nostri uffici e negli ambienti cloud. Le funzionalità DDoS sono fornite dal nostro fornitore/gestore di servizi Internet.

Le prestazioni dei firewall vengono inoltre valutate regolarmente attraverso programmi di valutazione delle vulnerabilità (https://www.atlassian.com/trust/security/vulnerability-management) e test di penetrazione (https://www.atlassian.com/trust/security/security-testing) .

Inoltre, in Atlassian monitoriamo la configurazione dei nostri ambienti AWS rispetto agli standard di configurazione stabiliti.

6.03.04. (a)

Il fornitore di servizi garantisce che venga applicata la protezione avanzata alle immagini virtuali per impostazione predefinita?

Tutti i server sono configurati con il nostro sistema di configurazione Puppet centralizzato sul nostro ambiente operativo standard, inclusa la rimozione di pacchetti selezionati dall'immagine predefinita e gli aggiornamenti dei pacchetti critici. Tutti i ruoli del server sono configurati per impostazione predefinita sul rifiuto di tutte le richieste di rete in entrata, con porte selezionate aperte solo agli altri ruoli del server che richiedono l'accesso a tale porta per la loro funzione.

La nostra rete aziendale è separata dalla rete di produzione e alle immagini delle macchine è applicata la protezione avanzata per consentire solo le porte e i protocolli necessari. Tutti i sistemi di produzione sono attualmente ospitati nelle regioni degli Stati Uniti del nostro fornitore di servizi cloud. Tutti i dati in transito al di fuori delle reti cloud private virtuali (VPC) con protezione avanzata sono crittografati su canali standard del settore.

Inoltre, su tutti i server di produzione è presente un sistema IDS, che include il monitoraggio e la creazione di avvisi in tempo reale sulle modifiche ai file o alla configurazione del sistema di produzione e sugli eventi di sicurezza anomali.

Nella piattaforma Atlassian Cloud, i singoli container non dispongono di un'immagine e, quando il container viene avviato, ne viene selezionata una da un repository standard. Ciascuna delle immagini è sottoposta ad auditing continuo e forniamo una riapplicazione delle immagini tramite i nostri strumenti di configurazione quando necessario. Di conseguenza, non vengono apportate modifiche alle immagini delle macchine virtuali.

Le build di immagini del sistema operativo di base dell'AMI AWS Linux hanno porte, protocolli e servizi limitati. Confrontiamo le nostre build con la versione dell'AMI attuale per garantire le impostazioni appropriate.

Le nostre immagini Docker sono gestite in un ambiente di modifica strettamente controllato per garantire un'appropriata revisione e approvazione di tutte le modifiche.

6.03.04. (b)

L'immagine virtuale con protezione avanzata è protetta dagli accessi non autorizzati?

Tutti i server sono configurati con il nostro sistema di configurazione Puppet centralizzato sul nostro ambiente operativo standard, inclusa la rimozione di pacchetti selezionati dall'immagine predefinita e gli aggiornamenti dei pacchetti critici. Tutti i ruoli del server sono configurati per impostazione predefinita sul rifiuto di tutte le richieste di rete in entrata, con porte selezionate aperte solo agli altri ruoli del server che richiedono l'accesso a tale porta per la loro funzione.

La nostra rete aziendale è separata dalla rete di produzione e alle immagini delle macchine è applicata la protezione avanzata per consentire solo le porte e i protocolli necessari. Tutti i sistemi di produzione sono attualmente ospitati nelle regioni degli Stati Uniti del nostro fornitore di servizi cloud. Tutti i dati in transito al di fuori delle reti cloud private virtuali (VPC) con protezione avanzata sono crittografati su canali standard del settore.

Inoltre, su tutti i server di produzione è presente un sistema IDS, che include il monitoraggio e la creazione di avvisi in tempo reale sulle modifiche ai file o alla configurazione del sistema di produzione e sugli eventi di sicurezza anomali.

Nella piattaforma Atlassian Cloud, i singoli container non dispongono di un'immagine e, quando il container viene avviato, ne viene selezionata una da un repository standard. Ciascuna delle immagini è sottoposta ad auditing continuo e forniamo una riapplicazione delle immagini tramite i nostri strumenti di configurazione quando necessario. Di conseguenza, non vengono apportate modifiche alle immagini delle macchine virtuali.

Le build di immagini del sistema operativo di base dell'AMI AWS Linux hanno porte, protocolli e servizi limitati. Confrontiamo le nostre build con la versione dell'AMI attuale per garantire le impostazioni appropriate.

Le nostre immagini Docker sono gestite in un ambiente di modifica strettamente controllato per garantire la revisione e l'approvazione appropriate di tutte le modifiche.

Il nostro team di assistenza globale mantiene un account su tutti i sistemi e le applicazioni in hosting ai fini della manutenzione e del supporto. Questo team accede alle applicazioni e ai dati in hosting esclusivamente allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione dei sistemi o delle applicazioni e agisce in seguito alle richieste dei clienti ricevute tramite il sistema di assistenza.

6.03.04. (c)

Il fornitore di servizi può confermare che l'immagine virtualizzata non contenga le credenziali di autenticazione?

Tutti i server sono configurati con il nostro sistema di configurazione Puppet centralizzato sul nostro ambiente operativo standard, inclusa la rimozione di pacchetti selezionati dall'immagine predefinita e gli aggiornamenti dei pacchetti critici. Tutti i ruoli del server sono configurati per impostazione predefinita sul rifiuto di tutte le richieste di rete in entrata, con porte selezionate aperte solo agli altri ruoli del server che richiedono l'accesso a tale porta per la loro funzione.

La nostra rete aziendale è separata dalla rete di produzione e alle immagini delle macchine è applicata la protezione avanzata per consentire solo le porte e i protocolli necessari. Tutti i sistemi di produzione sono attualmente ospitati nelle regioni degli Stati Uniti del nostro fornitore di servizi cloud. Tutti i dati in transito al di fuori delle reti cloud private virtuali (VPC) con protezione avanzata sono crittografati su canali standard del settore.

Inoltre, su tutti i server di produzione è presente un sistema IDS, che include il monitoraggio e la creazione di avvisi in tempo reale sulle modifiche ai file o alla configurazione del sistema di produzione e sugli eventi di sicurezza anomali.

Nella piattaforma Atlassian Cloud, i singoli container non dispongono di un'immagine e, quando il container viene avviato, ne viene selezionata una da un repository standard. Ciascuna delle immagini è sottoposta ad auditing continuo e forniamo una riapplicazione delle immagini tramite i nostri strumenti di configurazione quando necessario. Di conseguenza, non vengono apportate modifiche alle immagini delle macchine virtuali.

Le build di immagini del sistema operativo di base dell'AMI AWS Linux hanno porte, protocolli e servizi limitati. Confrontiamo le nostre build con la versione dell'AMI attuale per garantire le impostazioni appropriate.

Le nostre immagini Docker sono gestite in un ambiente di modifica strettamente controllato per garantire la revisione e l'approvazione appropriate di tutte le modifiche.

Il nostro team di assistenza globale mantiene un account su tutti i sistemi e le applicazioni in hosting ai fini della manutenzione e del supporto. Questo team accede alle applicazioni e ai dati in hosting esclusivamente allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione dei sistemi o delle applicazioni e agisce in seguito alle richieste dei clienti ricevute tramite il sistema di assistenza.

6.03.04. (d)

Il firewall host viene eseguito solo con le porte minime necessarie per supportare i servizi all'interno dell'istanza virtuale?

Tutti i server sono configurati con il nostro sistema di configurazione Puppet centralizzato sul nostro ambiente operativo standard, inclusa la rimozione di pacchetti selezionati dall'immagine predefinita e gli aggiornamenti dei pacchetti critici. Tutti i ruoli del server sono configurati per impostazione predefinita sul rifiuto di tutte le richieste di rete in entrata, con porte selezionate aperte solo agli altri ruoli del server che richiedono l'accesso a tale porta per la loro funzione.

La nostra rete aziendale è separata dalla rete di produzione e alle immagini delle macchine è applicata la protezione avanzata per consentire solo le porte e i protocolli necessari. Tutti i sistemi di produzione sono attualmente ospitati nelle regioni degli Stati Uniti del nostro fornitore di servizi cloud. Tutti i dati in transito al di fuori delle reti cloud private virtuali (VPC) con protezione avanzata sono crittografati su canali standard del settore.

La piattaforma Atlassian Cloud dispone di una superficie molto ridotta esposta ai firewall. Le regole dei firewall vengono riviste su base periodica. Abbiamo implementato 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. A livello di container della piattaforma Cloud, l'integrità dei file viene mantenuta in quanto le istanze non sono modificabili. Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall e abbiamo implementato tecnologie IDS nei nostri uffici e negli ambienti cloud. Le funzionalità DDoS sono fornite dal nostro fornitore/gestore di servizi Internet.

Le prestazioni dei firewall vengono inoltre valutate regolarmente attraverso programmi di valutazione delle vulnerabilità (https://www.atlassian.com/trust/security/vulnerability-management) e test di penetrazione (https://www.atlassian.com/trust/security/security-testing) .

6.03.04. (e)

È possibile eseguire un servizio di prevenzione delle intrusioni (IPS) basato su host nell'istanza virtuale?

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.03.05.

In generale, i fornitori di servizi PaaS sono responsabili della sicurezza dello stack software della piattaforma e i suggerimenti contenuti in questo documento sono una buona base per assicurarsi che i fornitori PaaS abbiano tenuto in considerazione i principi di sicurezza durante la progettazione e la gestione della piattaforma PaaS. Spesso è difficile ottenere informazioni precise e dettagliate dai fornitori PaaS sulla modalità di protezione delle loro piattaforme, tuttavia le seguenti domande, insieme alle altre sezioni di questo documento, dovrebbero essere di aiuto nella valutazione della loro offerta.

6.03.05. (a)

Richiedi informazioni su come le applicazioni multi-tenant vengono isolate l'una dall'altra: è necessaria una descrizione approfondita delle misure di contenimento e isolamento.

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.03.05. (b)

Quale garanzia può dare il fornitore PaaS per assicurarti che l'accesso ai tuoi dati sia limitato ai soli utenti aziendali e alle applicazioni che possiedi?

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.03.05. (c)

L'architettura della piattaforma dovrebbe essere la classica "sandbox": il fornitore di servizi può garantire che la sandbox della piattaforma PaaS sia monitorata per rilevare nuovi bug e vulnerabilità?

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.03.05. (d)

I provider PaaS dovrebbero essere in grado di offrire una serie di funzionalità di sicurezza (riutilizzabili dai loro clienti): sono inclusi l'autenticazione degli utenti, il single sign-on, l'autorizzazione (gestione dei privilegi) e i protocolli SSL/TLS (resi disponibile da un'API)?

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.03.06.

Il modello SaaS impone che il provider gestisca l'intera suite di applicazioni fornite agli utenti finali. Pertanto, i provider SaaS sono responsabili soprattutto della protezione di queste applicazioni. I clienti, invece, di solito sono responsabili dei processi operativi di sicurezza (gestione degli utenti e degli accessi). Tuttavia, per valutare le offerte dei provider, può essere utile fare riferimento alle seguenti domande e ad altre sezioni di questo documento:

6.03.06. (a)

Quali controlli amministrativi sono forniti e possono essere utilizzati per assegnare privilegi di lettura e scrittura ad altri utenti?

I clienti delle nostre offerte Cloud Enterprise e Premium hanno accesso a un pannello di controllo amministrativo centralizzato. Gli amministratori della tua organizzazione possono gestire l'accesso e le autorizzazioni degli utenti in tutte le istanze del prodotto. Leggi il nostro post del blog qui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

I clienti Atlassian possono utilizzare il provider terzo di identità che preferiscono, purché sia supportato da Atlassian. Una pagina dell'Assistenza Atlassian descrive in dettaglio queste funzionalità e come connettere il provider di identità scelto. Vedi: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Il controllo degli accessi SaaS è dettagliato? Può essere personalizzato in base alla policy della tua organizzazione?

I clienti delle nostre offerte Cloud Enterprise e Premium hanno accesso a un pannello di controllo amministrativo centralizzato. Gli amministratori della tua organizzazione possono gestire l'accesso e le autorizzazioni degli utenti in tutte le istanze del prodotto. Leggi il nostro post del blog qui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

I clienti Atlassian possono utilizzare il provider terzo di identità che preferiscono, purché sia supportato da Atlassian. Una pagina dell'Assistenza Atlassian descrive in dettaglio queste funzionalità e come connettere il provider di identità scelto. Vedi: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

In caso di sovraccarico da risorse (elaborazione, memoria, archiviazione, rete):

• Quali informazioni vengono fornite sulla priorità relativa assegnata alla mia richiesta in caso di mancato provisioning?
• C'è un lead time per quanto riguarda i livelli di servizio e le modifiche ai requisiti?
<

Atlassian pianifica la capacità con 6-12 mesi di anticipo, con una programmazione strategica di alto livello che durerà 36 mesi.

Atlassian gestisce l'analisi per il ridimensionamento dell'architettura di Cloud AWS e Azure e utilizza questi dati per progettare lo sviluppo dei prodotti Atlassian. Tuttavia, in questa fase i dati in questione non vengono forniti ai clienti.

6.03.07. (b)

Qual è il livello di scalabilità? Il fornitore offre garanzie sul livello massimo di disponibilità delle risorse entro un periodo minimo?

Atlassian pianifica la capacità con 6-12 mesi di anticipo, con una programmazione strategica di alto livello che durerà 36 mesi.

Atlassian gestisce l'analisi per il ridimensionamento dell'architettura di Cloud AWS e Azure e utilizza questi dati per progettare lo sviluppo dei prodotti Atlassian. Tuttavia, in questa fase i dati in questione non vengono forniti ai clienti.

6.03.07. (c)

Con quanta rapidità puoi implementare la scalabilità? Il fornitore offre garanzie sulla disponibilità di risorse supplementari entro un periodo minimo?

Atlassian pianifica la capacità con 6-12 mesi di anticipo, con una programmazione strategica di alto livello che durerà 36 mesi.

Atlassian gestisce l'analisi per il ridimensionamento dell'architettura di Cloud AWS e Azure e utilizza questi dati per progettare lo sviluppo dei prodotti Atlassian. Tuttavia, in questa fase i dati in questione non vengono forniti ai clienti.

6.03.07. (d)

Quali sono i processi per gestire le tendenze su larga scala relativamente all'utilizzo delle risorse (ad esempio, effetti stagionali)?

Atlassian pianifica la capacità con 6-12 mesi di anticipo, con una programmazione strategica di alto livello che durerà 36 mesi.

Atlassian gestisce l'analisi per il ridimensionamento dell'architettura di Cloud AWS e Azure e utilizza questi dati per progettare lo sviluppo dei prodotti Atlassian. Tuttavia, in questa fase i dati in questione non vengono forniti ai clienti.

6.04.01.

I seguenti controlli si applicano ai sistemi di gestione delle identità e degli accessi sotto il controllo del provider di cloud.

6.04.01. (a)

Gli account hanno privilegi a livello di sistema per l'intero sistema cloud? Se sì, per quali operazioni (lettura/scrittura/eliminazione)?

Il nostro team di supporto globale mantiene un account su tutti i sistemi e le applicazioni in hosting ai fini della manutenzione e del supporto. Questo team accede alle applicazioni e ai dati in hosting esclusivamente allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione di sistemi o applicazioni e su richiesta del cliente tramite il nostro sistema di supporto.

6.04.01. (b)

Come vengono autenticati e gestiti gli account con il più alto livello di privilegi?

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 Sign-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à.

6.04.01. (c)

Come vengono autorizzate le decisioni più importanti (ad esempio, il de-provisioning simultaneo di grandi quantità di risorse) (SSO o autenticazione a due fattori, e da quali ruoli all'interno dell'organizzazione)?

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 Sign-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à.

La segregazione delle funzioni è in vigore per i nostri prodotti principali. L'elenco parziale include:

• Verifiche controllo degli accessi
• Gruppi di sicurezza gestiti da applicazioni per le risorse umane
• Approvazione delle modifiche/peer review/implementazione (PRGB)
• Controlli del flusso di lavoro

6.04.01. (d)

Ci sono ruoli con privilegi elevati assegnati alla stessa persona? Questa assegnazione viola la separazione dei compiti o le regole dei privilegi minimi?

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 Sign-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à.

La segregazione delle funzioni è in vigore per i nostri prodotti principali. L'elenco parziale include:

• Verifiche controllo degli accessi
• Gruppi di sicurezza gestiti da applicazioni per le risorse umane
• Approvazione delle modifiche/peer review/implementazione (PRGB)
• Controlli del flusso di lavoro

6.04.01. (e)

Utilizzi il controllo degli accessi basato sui ruoli (RBAC)? Viene seguito il principio del privilegio minimo?

Atlassian ha un flusso di lavoro consolidato che collega il nostro sistema di gestione delle risorse umane e il nostro sistema di provisioning degli accessi. Utilizziamo il controllo degli accessi basato sui ruoli, determinato dai profili utente predefiniti. Tutti gli account utente devono essere approvati dalla direzione prima di poter accedere a dati, applicazioni, infrastruttura o componenti di rete.

Atlassian applica restrizioni sul personale che ha bisogno dell'accesso ai nostri sistemi, alle applicazioni e all'infrastruttura per svolgere i propri compiti sulla base del privilegio minimo e ciò avviene attraverso i nostri processi di autenticazione.

6.04.01. (f)

Nel caso in cui un'emergenza renda necessario un accesso straordinario, vengono apportate modifiche ai privilegi e ai ruoli amministrativi? Se sì, quali?

Il nostro team di supporto globale mantiene un account su tutti i sistemi e le applicazioni in hosting ai fini della manutenzione e del supporto. Questo team accede alle applicazioni e ai dati in hosting esclusivamente allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione di sistemi o applicazioni e su richiesta del cliente tramite il nostro sistema di supporto.

6.04.01. (g)

Esiste un ruolo "amministrativo" per il cliente? Ad esempio, il cliente amministratore ha un ruolo nell'aggiunta di nuovi utenti (che non gli consente però di modificare lo spazio di archiviazione sottostante)?

Atlassian offre ai clienti il ruolo di "Amministratore dell'organizzazione" che amministra utenti e gruppi per i prodotti del cliente. Per maggiori informazioni, vedi: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Quali controlli vengono effettuati sull'identità degli account utente al momento della registrazione? Vengono seguiti degli standard, ad esempio, l'e-Government Interoperability Framework?

• Esistono diversi livelli di controllo dell'identità in base alle risorse richieste?

I nuovi utenti Atlassian 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 contraenti indipendenti, a cui si aggiungono la verifica dei titoli di studio, la verifica dei precedenti rapporti di impiego o i controlli sull'affidabilità creditizia 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.

Atlassian ha un flusso di lavoro consolidato che collega il nostro sistema di gestione delle risorse umane e il nostro sistema di provisioning degli accessi. Utilizziamo il controllo degli accessi basato sui ruoli, determinato dai profili utente predefiniti. Tutti gli account utente devono essere approvati dalla direzione prima di poter accedere a dati, applicazioni, infrastruttura o componenti di rete.

6.04.02. (b)

Quali procedure sono previste per il de-provisioning delle credenziali?

La nostra procedura di de-provisioning attualmente include la cessazione del rapporto di lavoro, del contratto o dell'accordo. In generale, gli utenti che vengono trasferiti internamente conservano i loro diritti di accesso per favorire la continuità del coinvolgimento e del supporto. Vogliamo consentire ai team di essere molto reattivi, flessibili e orientati verso i clienti, in linea con i valori della nostra azienda. Per questo il nostro obiettivo è rilevare l'uso non autorizzato degli accessi piuttosto che imporre un limite agli accessi che potrebbe rallentare la capacità di risposta.

6.04.02. (c)

Il provisioning e il de-provisioning delle credenziali avviene contemporaneamente in tutto il sistema cloud o ci sono rischi collegati al de-provisioning nelle sedi situate in aree geografiche diverse?

Atlassian ha un flusso di lavoro consolidato che collega il nostro sistema di gestione delle risorse umane e il nostro sistema di provisioning degli accessi. Utilizziamo il controllo degli accessi basato sui ruoli, determinato dai profili utente predefiniti. Tutti gli account utente devono essere approvati dalla direzione prima di poter accedere a dati, applicazioni, infrastruttura o componenti di rete.

La nostra applicazione per le risorse umane viene sincronizzata con il nostro Identity Store interno ogni 8 ore, rimuovendo tutti gli account di dipendenti o collaboratori esterni che non lavorano più per l'azienda.

6.04.03. (a)

Quali controlli di archiviazione e protezione dei dati si applicano alla directory degli utenti (ad esempio AD, LDAP) e all'accesso ad essa?

I dati sono classificati e gestiti nel rispetto della nostra policy sulla sicurezza dei dati e sulla gestione del ciclo di vita delle informazioni, e questo influisce sull'implementazione dei controlli. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices

Tutti i sistemi e i progetti sono sottoposti a una valutazione dell'impatto in relazione alle informazioni personali. I Contratti con terze parti di Atlassian includono, secondo i casi, disposizioni sulla sicurezza e sulla privacy. I nuovi fornitori di Atlassian sono tenuti ad accettare le policy in materia di privacy e sicurezza presenti nei nostri contratti.

Atlassian è certificato ISO per una serie di prodotti, il che richiede valutazioni periodiche dei rischi e revisioni delle pratiche relative ai dati.

La nostra valutazione sull'impatto del trasferimento dei dati è disponibile alla pagina: https://www.atlassian.com/legal/data-transfer-impact-assessment

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/

6.04.03. (b)

I dati delle directory utenti sono esportabili in un formato interoperabile?

Gli amministratori possono esportare la directory degli utenti dal pannello di amministrazione. Le guide sono disponibili sul sito del Supporto Atlassian qui: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

La condivisione dei soli dati essenziali è il principio guida per l'accesso ai dati dei clienti all'interno del provider cloud?

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 Sign-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à.

La segregazione delle funzioni è in vigore per i nostri prodotti principali. L'elenco parziale include:

• Verifiche controllo degli accessi
• Gruppi di sicurezza gestiti da applicazioni per le risorse umane
• Approvazione delle modifiche/peer review/implementazione (PRGB)
• Controlli del flusso di lavoro

6.04.04.

Per le chiavi controllate dal provider cloud:

6.04.04. (a)

Sono impostati dei controlli di sicurezza per leggere e scrivere queste chiavi? Ad esempio, policy sull'utilizzo di password forti, chiavi archiviate in un sistema separato, moduli di sicurezza hardware (HSM) per le chiavi dei certificati radice, autenticazione basata su smart card, accesso diretto protetto all'archiviazione, durata breve delle chiavi, ecc.

Atlassian rispetta le policy di crittografia e le linee guida di implementazione della stessa. Questa policy viene rivista e aggiornata ogni anno in linea con il nostro Policy Management Program (PMP). Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program.

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro. AWS KMS Service è conforme a SOC 1, SOC 2, SOC 3. Per maggiori informazioni, vedi: https://aws.amazon.com/kms/

6.04.04. (b)

Sono impostati dei controlli di sicurezza per l'utilizzo di queste chiavi per firmare e crittografare i dati?

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi master in KMS, al momento della creazione, abilitano una rotazione automatica per la generazione del materiale delle chiavi master ogni 365 giorni (cadenza annuale).

6.04.04. (c)

Sono previste procedure specifiche in caso di compromissione di una chiave? Ad esempio, elenchi di revoca delle chiavi.

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro. AWS KMS Service è conforme a SOC 1, SOC 2, SOC 3. Per maggiori informazioni, vedi: https://aws.amazon.com/it/kms/

6.04.04. (c)

Sono previste procedure specifiche in caso di compromissione di una chiave? Ad esempio, elenchi di revoca delle chiavi.

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro. AWS KMS Service è conforme a SOC 1, SOC 2, SOC 3. Per maggiori informazioni, vedi: https://aws.amazon.com/it/kms/

6.04.04. (d)

La revoca delle chiavi è in grado di risolvere i problemi di simultaneità per più siti?

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro. AWS KMS Service è conforme a SOC 1, SOC 2, SOC 3. Per maggiori informazioni, vedi: https://aws.amazon.com/it/kms/

6.04.04. (e)

Le immagini del sistema del cliente sono protette o crittografate?

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

Tutti i dati dei clienti archiviati nei prodotti e nei servizi Atlassian Cloud sono crittografati in transito su reti pubbliche utilizzando il protocollo Transport Layer Security (TLS) 1.2+ con Perfect Forward Secrecy (PFS) per proteggerli da divulgazioni o modifiche non autorizzate. La nostra implementazione di TLS impone l'uso di chiavi di crittografia e lunghezze di chiavi complesse se supportate dal browser.

Le unità su server che contengono dati e allegati del cliente in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie e Trello adottano la crittografia dei dati inattivi standard del settore eseguita sull'intero disco tramite AES-256.

Per la crittografia a riposo, in particolare crittografiamo i dati dei clienti archiviati su un disco, come i dati dei ticket di Jira (dettagli, commenti, allegati) o i dati delle pagine di Confluence (contenuto della pagina, commenti, allegati). La crittografia dei dati a riposo previene accessi non autorizzati e assicura che i dati siano accessibili solo da ruoli e servizi autorizzati con accesso controllato a quelle chiavi di crittografia.

6.04.05. (a)

La crittografia può essere utilizzata in più punti: dove viene utilizzata?

• Dati in transito?
• Dati a riposo?
• Dati nel processore o nella memoria?

Atlassian rispetta le policy di crittografia e codifica e le relative linee guida di implementazione. Questa policy viene rivista e aggiornata ogni anno in linea con il nostro Policy Management Program (PMP). Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program .

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro.

Tutti i dati dei clienti archiviati nei prodotti e nei servizi Atlassian Cloud sono crittografati in transito su reti pubbliche utilizzando il protocollo Transport Layer Security (TLS) 1.2+ con Perfect Forward Secrecy (PFS) per proteggerli da divulgazioni o modifiche non autorizzate. La nostra implementazione di TLS impone l'uso di chiavi di crittografia e lunghezze di chiavi complesse se supportate dal browser.

Le unità su server che contengono dati e allegati del cliente in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, OpsGenie e Trello adottano la crittografia dei dati inattivi standard del settore eseguita sull'intero disco tramite AES-256.

Per la crittografia a riposo, in particolare crittografiamo i dati dei clienti archiviati su un disco, come i dati dei ticket di Jira (dettagli, commenti, allegati) o i dati delle pagine di Confluence (contenuto della pagina, commenti, allegati). La crittografia dei dati a riposo previene accessi non autorizzati e assicura che i dati siano accessibili solo da ruoli e servizi autorizzati con accesso controllato a quelle chiavi di crittografia.

6.04.05. (b)

Esiste una policy ben definita per ciò che deve essere crittografato e ciò che non deve essere crittografato?

Atlassian rispetta le policy di crittografia e codifica e le relative linee guida di implementazione. Questa policy viene rivista e aggiornata ogni anno in linea con il nostro Policy Management Program (PMP). Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

Atlassian mantiene procedure documentate di gestione delle chiavi per la nostra infrastruttura Cloud. Le chiavi di crittografia per gli allegati Amazon, archiviate in S3, sono gestite da Amazon KMS. Il processo di crittografia, gestione delle chiavi e decrittazione viene ispezionato e verificato internamente da Amazon su base regolare come parte del processo di audit attualmente in vigore. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro.

6.04.05. (d)

Chi ha le chiavi di accesso?

Atlassian utilizza AWS Key Management Service (KMS) per la gestione delle chiavi. Il processo di crittografia, decrittografia e gestione delle chiavi viene ispezionato e verificato internamente da AWS su base regolare nell'ambito dei processi di convalida interni esistenti. A ogni chiave viene assegnato un responsabile, con il compito di verificare che alle chiavi venga applicato il livello appropriato di controlli di sicurezza.

6.04.05. (e)

Come vengono protette le chiavi?

Atlassian utilizza AWS Key Management Service (KMS) per la gestione delle chiavi. Il processo di crittografia, decrittografia e gestione delle chiavi viene ispezionato e verificato internamente da AWS su base regolare nell'ambito dei processi di convalida interni esistenti. A ogni chiave viene assegnato un responsabile, con il compito di verificare che alle chiavi venga applicato il livello appropriato di controlli di sicurezza.

6.04.06. (a)

Quali forme di autenticazione vengono utilizzate per le operazioni che richiedono un'elevata sicurezza? Ciò può includere l'accesso alle interfacce di gestione, la creazione di chiavi, l'accesso a più account utente, la configurazione del firewall, l'accesso remoto, ecc.

• Viene utilizzata l'autenticazione a due fattori per gestire i componenti critici all'interno dell'infrastruttura, come i firewall, ecc.?

Seguiamo le linee guida delineate nella pubblicazione speciale 800-63B del NIST. Vedi: https://pages.nist.gov/800-63-3/sp800-63b.html

Il processo di assegnazione delle password è descritto nella Atlassian Password Policy. Le nuove password non verranno comunicate elettronicamente, tranne nei casi in cui viene inviata una password iniziale monouso. In questi casi l'utente sarà costretto a cambiare la password monouso al primo utilizzo.

Più in generale, i controlli relativi al controllo degli accessi sono trattati nella Policy di gestione degli accessi; puoi consultarne un estratto qui: https://www.atlassian.com/trust/security/ismp-policies

Atlassian applica restrizioni sul personale che ha necessità di accedere ai nostri sistemi, alle applicazioni e all'infrastruttura per il proprio ruolo e le proprie responsabilità lavorative sulla base del privilegio minimo e ciò avviene attraverso i nostri processi di autenticazione. Tutti gli accessi avvengono tramite sessioni autenticate e sulla base di autorizzazioni stabilite.

Atlassian applica restrizioni sul personale che ha necessità di effettuare l'accesso per il proprio ruolo e le proprie responsabilità lavorative. Tutti i sistemi di livello 1 sono gestiti tramite una soluzione centralizzata di Single Sign-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 ogni 8 ore tra il sistema delle risorse umane e l'archivio delle identità.

6.04.07. (a)

È disponibile un servizio di rilevamento delle anomalie (ovvero la capacità di individuare traffico IP e comportamenti degli utenti o del team di supporto insoliti e potenzialmente dannosi)? Ad esempio, analisi degli accessi falliti e riusciti, dell'ora del giorno insolita e degli accessi multipli, ecc.

La piattaforma Atlassian Cloud dispone di un'area molto ridotta esposta ai firewall. Le regole dei firewall vengono riviste su base periodica. Abbiamo distribuito 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. A livello di container della piattaforma Cloud, l'integrità dei file viene mantenuta in quanto le istanze non sono modificabili. Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall e abbiamo implementato tecnologie IDS nei nostri uffici e negli ambienti cloud. Le capacità DDoS sono fornite dal nostro fornitore/gestore di servizi Internet.

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.

6.04.07. (b)

Quali disposizioni esistono in caso di furto delle credenziali di un cliente (rilevamento, revoca, prove delle azioni)?

Nel contesto dei servizi Atlassian Cloud, i nostri clienti possono essere responsabili di alcuni o di tutti gli aspetti della gestione degli accessi per gli utenti dei servizi sotto il loro controllo.

Di conseguenza, Atlassian consente ai nostri clienti di gestire l'accesso degli utenti del servizio sotto il controllo del cliente del servizio, ad esempio fornendo i diritti amministrativi per gestire o terminare l'accesso. Atlassian controlla inoltre le credenziali dei clienti rispetto ai database delle credenziali perse e obbliga gli utenti ad aggiornare la password.

Atlassian non fornisce la funzione DLP (Data Loss Prevention) direttamente come parte delle distribuzioni Cloud. Tuttavia, ci sono fornitori nell'Atlassian Marketplace, come Nightfall, che Atlassian consiglia ai clienti che desiderano questa capacità DLP. Consulta la pagina del prodotto Marketplace per Nightfall qui: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall include la scansione automatica di informazioni sensibili tra cui credenziali, segreti e chiavi API.

Atlassian ha lanciato Beacon, che è in versione beta e aggiunge funzionalità DLP. Fino al lancio di Beacon dopo la versione beta, Atlassian consiglia comunque Nightfall. Vedi ulteriori informazioni su Atlassian Beacon all'indirizzo: https://www.atlassian.com/software/beacon.

Abbiamo una politica e un piano documentati di risposta agli imprevisti di sicurezza, i cui principi chiave includono:

• Anticipare gli imprevisti di sicurezza e prepararsi per la risposta agli imprevisti.
• Contenere ed eliminare gli imprevisti, ed effettuare il ripristino dagli imprevisti.
• Investire nelle nostre persone, nei nostri processi e nelle nostre tecnologie per avere la certezza di disporre della capacità di rilevare e analizzare un imprevisto di sicurezza, qualora si verifichi
• Adoperarsi affinché la protezione dei dati personali e dei dati dei clienti siano la massima priorità durante gli imprevisti di sicurezza.
• Condurre regolarmente il processo di risposta agli imprevisti di sicurezza.
• Acquisire informazioni dalla funzione di gestione degli imprevisti di sicurezza e migliorarla.
• Comunicare gli imprevisti di sicurezza critici al gruppo dirigenziale Atlassian.

6.04.08.

Le seguenti domande si applicano ai sistemi di gestione delle identità e degli accessi offerti dal provider cloud per l'uso e il controllo da parte del cliente cloud.

6.04.08.01. (a)

Il sistema consente un'infrastruttura IDM federata che sia interoperabile sia per i sistemi ad alta affidabilità (sistemi OTP, dove richiesto) che a bassa affidabilità (ad es. Nome utente e password)?

Atlassian Access supporta gli standard di federazione delle identità tra i nostri prodotti Atlassian (Confluence, Jira, Jira Align, Bitbucket, ecc.). Sincronizza automaticamente Active Directory e Atlassian con Okta, Azure o Onelogin. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/enterprise/cloud/access. Configurazione SSO specifica del prodotto (SAML v2.0 generico, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie supporta più provider SSO. Per maggiori informazioni, vedi: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello supporta più provider SSO. Per maggiori informazioni, vedi: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage supporta più provider SSO. Per maggiori informazioni, vedi: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

Il provider cloud è interoperabile con provider di identità di terze parti?

I clienti Atlassian possono utilizzare il provider terzo di identità che preferiscono, purché sia supportato da Atlassian. Una pagina dell'Assistenza Atlassian descrive in dettaglio queste funzionalità e come connettere il provider di identità scelto. Vedi: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

C'è la possibilità di incorporare il Single Sign-On?

Atlassian supporta l'utilizzo delle identità Google, Microsoft e Apple per l'autenticazione della maggior parte dei prodotti. Supportiamo anche SAML per i nostri servizi Atlassian Cloud tramite Atlassian Access. Vedi: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Il sistema di credenziali del cliente consente la separazione di ruoli e responsabilità e per più domini (o un'unica chiave per più domini, ruoli e responsabilità)?

Atlassian è un'applicazione SaaS multi-tenant. La multi-tenancy è una funzionalità chiave di Atlassian Cloud che consente a più clienti di condividere un'istanza del livello applicativo Jira o Confluence, isolando al contempo i dati dell'applicazione di ogni tenant del cliente. Atlassian Cloud realizza questo obiettivo tramite il Tenant Context Service (TCS). Ogni ID utente è associato esattamente a un tenant, che viene poi utilizzato per accedere alle applicazioni Atlassian Cloud. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

I clienti delle nostre offerte Cloud Enterprise e Premium hanno accesso a un pannello di controllo amministrativo centralizzato. Gli amministratori della tua organizzazione possono gestire l'accesso e le autorizzazioni degli utenti in tutte le istanze del prodotto. Leggi il nostro post del blog qui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian offre ai clienti il ruolo di "Amministratore dell'organizzazione" che amministra utenti e gruppi per i prodotti del cliente. Per maggiori informazioni, vedi: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Come gestisci l'accesso alle immagini del sistema del cliente e ti assicuri che le chiavi di autenticazione e crittografia non siano contenute in tali immagini?

Il nostro team di supporto globale mantiene un account su tutti i sistemi e le applicazioni in hosting ai fini della manutenzione e del supporto. Questo team accede alle applicazioni e ai dati in hosting esclusivamente allo scopo di monitorare lo stato delle applicazioni ed eseguire la manutenzione di sistemi o applicazioni e su richiesta del cliente tramite il nostro sistema di supporto.

6.04.08.03. (a)

In che modo il provider di servizi cloud si identifica con il cliente, ad esempio esiste un'autenticazione reciproca?

• Quando il cliente invia comandi API?
• Quando il cliente accede all'interfaccia di gestione?

Atlassian utilizza l'autenticazione reciproca per identificarsi con il cliente. La documentazione dell'API Atlassian è disponibile all'indirizzo: https://developer.atlassian.com/cloud/. Atlassian Service Authentication Protocol (ASAP) è un protocollo di autenticazione service-to-service che utilizza un token di accesso implementato utilizzando JSON Web Token (JWT) e firmato utilizzando una chiave RSA da un'autorità affidabile di Atlassian. Per saperne di più, vedi Atlassian Service Authentication Protocol. Non utilizziamo le nozioni tradizionali di «account di servizio», ma ci affidiamo all'autenticazione e all'autorizzazione service-to-service.

6.04.08.03. (b)

Supporti un meccanismo federato per l'autenticazione?

Atlassian Access supporta gli standard di federazione delle identità tra i nostri prodotti Atlassian (Confluence, Jira, Jira Align, Bitbucket, ecc.). Sincronizza automaticamente Active Directory e Atlassian con Okta, Azure o Onelogin. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/enterprise/cloud/access. Configurazione SSO specifica del prodotto (SAML v2.0 generico, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie supporta più provider SSO. Per maggiori informazioni, vedi: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello supporta più provider SSO. Per maggiori informazioni, vedi: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage supporta più provider SSO. Per maggiori informazioni, vedi: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

È importante assicurarsi che il provider mantenga un elenco aggiornato delle risorse hardware e software (applicazioni) sotto il controllo dei provider di servizi cloud. Ciò consente di verificare che tutti i sistemi dispongano dei controlli appropriati e che i sistemi non possano essere utilizzati come backdoor nell'infrastruttura.

6.05. (a)

Il fornitore dispone di un mezzo automatizzato per l'inventario di tutte le risorse, facilitando così una gestione appropriata?

I nostri sistemi di produzione si trovano in un'infrastruttura ottenuta tramite fornitori di servizi cloud. Questi sistemi non sono tracciati a livello hardware a causa della natura del servizio. I microservizi sottostanti su cui vengono eseguiti i nostri prodotti sono tracciati in un database «Service» personalizzato. Questo database viene aggiornato automaticamente quando si distribuisce un servizio.

Il nostro team per le tecnologie sul luogo di lavoro gestisce un inventario delle risorse di tutti gli endpoint utilizzando Jira Software per finalità di monitoraggio.

6.05. (b)

Esiste un elenco di risorse che il cliente ha utilizzato in un determinato periodo di tempo?

Atlassian è un'applicazione SaaS multi-tenant. La multi-tenancy è una funzionalità chiave di Atlassian Cloud che consente a più clienti di condividere un'istanza del livello applicativo Jira o Confluence, isolando al contempo i dati dell'applicazione di ogni tenant del cliente. Atlassian Cloud realizza questo obiettivo tramite il Tenant Context Service (TCS). Ogni ID utente è associato esattamente a un tenant, che viene poi utilizzato per accedere alle applicazioni Atlassian Cloud. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Le seguenti domande devono essere utilizzate laddove il cliente finale stia distribuendo dati che richiederebbero una protezione aggiuntiva (ad es. Ritenuto sensibile).

6.05. (c)

Le risorse sono classificate in termini di sensibilità e criticità?

• In caso affermativo, il provider utilizza una separazione appropriata tra sistemi con classificazioni diverse e per un singolo cliente che dispone di sistemi con classificazioni di sicurezza diverse?

Atlassian mantiene una valutazione a 4 livelli sulle nostre risorse e sui nostri servizi, con requisiti di uptime, livello di servizio e continuità stabiliti per livello. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/data-management.

6.06.

Questa serie di domande dovrebbe essere presa in considerazione per comprendere i rischi legati al vincolo del fornitore.

6.06. (a)

Esistono procedure e API documentate per l'esportazione dei dati dal cloud?

I dati dei clienti sono disponibili tramite app Web e API. I dettagli per prodotti specifici sono riportati di seguito.

• Confluence & Jira & Jira Align: i dettagli sulla nostra API Atlassian sono disponibili all'indirizzo: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: i dati della bacheca sono disponibili per l'esportazione da parte dei membri della bacheca in formato JSON tramite l'API REST di Trello. I file allegati possono essere recuperati singolarmente direttamente da Amazon S3 utilizzando il collegamento ipertestuale univoco del file. Le edizioni Trello Business Class ed Enterprise offrono un processo di esportazione dei dati semplificato per tutti i dati e gli allegati dell'organizzazione. Ogni organizzazione di Business Class ed Enterprise include l'esportazione con un clic di tutte le bacheche all'interno dell'organizzazione. Facoltativamente, i file allegati caricati direttamente su Trello possono essere inclusi nel file di esportazione. All'interno dell'esportazione, i dati di ogni bacheca sono inclusi sia in formato JSON che in valori separati da virgola («CSV»).
• Opsgenie: l'API è disponibile all'indirizzo: https://docs.opsgenie.com/docs/api-overview
• Statuspage: l'API è disponibile all'indirizzo: https://doers.statuspage.io/api/v1/
• Bitbucket: qualsiasi codice sorgente o repository può essere scaricato o esportato da Bitbucket per scopi di interoperabilità. Vedi: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: ha una funzione di esportazione CSV. Puoi leggere altra documentazione qui: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Il fornitore fornisce formati di esportazione interoperabili per tutti i dati archiviati nel cloud?

Atlassian facilita le richieste da parte dei clienti di esportazione dei dati ospitati su prodotti Atlassian. Sono disponibili solidi strumenti di portabilità e di gestione dei dati per l'esportazione dei dati di prodotti e utenti. Per ulteriori informazioni sull'esportazione dei dati di Atlassian Cloud, consulta la nostra documentazione di importazione ed esportazione qui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Inoltre, vedi: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ per i dettagli sull'esportazione dei dati in formati comuni come CSV, HTML e XML.

6.06. (c)

Nel caso del SaaS, le interfacce API utilizzate sono standardizzate?

I dettagli sulle nostre API Atlassian Cloud sono disponibili all'indirizzo: https://developer.atlassian.com/explore-the-apis/

Dettagli specifici dell'API del prodotto:

• Trello: la documentazione dell'API è disponibile all'indirizzo: https://developer.atlassian.com/cloud/trello
• Jira Align: l'API è disponibile all'indirizzo: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: l'API è disponibile all'indirizzo: https://doers.statuspage.io/api/v1
• Opsgenie: l'API è disponibile all'indirizzo: https://docs.opsgenie.com/docs/api-overview
• Halp: al momento non dispone di un'API pubblica.

6.06. (d)

Esistono disposizioni per l'esportazione di applicazioni create dagli utenti in un formato standard?

Non applicabile poiché Atlassian utilizza un modello Software as a Service (SaaS).

6.06. (e)

Esistono processi per verificare che i dati possano essere esportati su un altro provider cloud, ad esempio se il cliente desidera cambiare fornitore?

Atlassian facilita le richieste da parte dei clienti di esportazione dei dati ospitati su prodotti Atlassian. Sono disponibili solidi strumenti di portabilità e di gestione dei dati per l'esportazione dei dati di prodotti e utenti. Per ulteriori informazioni sull'esportazione dei dati di Atlassian Cloud, consulta la nostra documentazione di importazione ed esportazione qui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Inoltre, vedi: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ per i dettagli sull'esportazione dei dati in formati comuni come CSV, HTML e XML.

6.06. (f)

Il cliente può eseguire l'estrazione dei dati per verificare che il formato sia universale e possa essere migrato su un altro provider di cloud?

Atlassian facilita le richieste da parte dei clienti di esportazione dei dati ospitati su prodotti Atlassian. Sono disponibili solidi strumenti di portabilità e di gestione dei dati per l'esportazione dei dati di prodotti e utenti. Per ulteriori informazioni sull'esportazione dei dati di Atlassian Cloud, consulta la nostra documentazione di importazione ed esportazione qui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Inoltre, vedi: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ per i dettagli sull'esportazione dei dati in formati comuni come CSV, HTML e XML.

6.07.

Fornire continuità è importante per un'organizzazione. Sebbene sia possibile stabilire accordi sul livello di servizio che specifichino il periodo minimo di tempo in cui i sistemi sono disponibili, rimangono una serie di considerazioni aggiuntive.

6.07. (a)

Il provider mantiene un metodo documentato con i dettagli dell'impatto di un'interruzione?

• Cosa sono l'RPO (obiettivo del punto di ripristino) e l'RTO (obiettivo del tempo di ripristino) per i servizi? Dettaglio in base alla criticità del servizio.
• Le attività di sicurezza delle informazioni sono state implementate in modo appropriato nel processo di ripristino?
• Quali sono le linee di comunicazione con i clienti finali in caso di interruzione?
• I ruoli e le responsabilità dei team sono chiaramente identificati quando si affronta un'interruzione?

Sono in vigore una politica di continuità aziendale e ripristino di emergenza e un piano di continuità aziendale e ripristino di emergenza che vengono rivisti su base annuale dal comitato direttivo per la continuità aziendale e il ripristino di emergenza. Per ulteriori informazioni (anche relative a RPO, RTO e resilienza tramite l'uso delle zone di disponibilità), vedi: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

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. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance/

6.07. (b)

Il fornitore ha classificato la priorità per il ripristino e quale sarebbe la nostra priorità relativa (il cliente finale) da ripristinare? Nota: questa può essere una categoria (HIGH/MED/LOW).

I responsabili di sistemi, processi o servizi mission critical devono garantire continuità aziendale e/o ripristino di emergenza adeguati che siano in linea con la tolleranza alle interruzioni prevista in caso di emergenza. I piani BCDR vengono testati trimestralmente e tutti i problemi identificati vengono risolti. Per maggiori informazioni, vedi: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Quali dipendenze esistono che sono rilevanti per il processo di ripristino? Includi fornitori e partner di outsourcing.

Atlassian ha una procedura e un registro delle azioni di ripristino dei dati. Ad alto livello, queste informazioni sono contenute nel nostro standard di backup interno e nella politica di continuità aziendale e ripristino di emergenza. Tuttavia, per ogni servizio Atlassian, abbiamo vari documenti interni che includono runbook, programmazioni e procedure per i ripristini avviati dai clienti e i ripristini avviati da Atlassian.

6.07. (d)

Nel caso in cui il sito primario non sia disponibile, qual è la distanza minima per l'ubicazione del sito secondario?

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 includotrapno: presenza di personale di sorveglianza on-premise, monitoraggio video a circuito chiuso, mantrap e ulteriori misure di protezione contro le intrusioni. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance/

6.07.01.

La gestione e la risposta agli imprevisti fanno parte della gestione della continuità aziendale. L'obiettivo di questo processo è contenere l'impatto di eventi imprevisti e che possono causare interruzioni a un livello accettabile per un'organizzazione. Per valutare la capacità di un'organizzazione di ridurre al minimo la probabilità che si verifichi un imprevisto di sicurezza delle informazioni o di ridurne l'impatto negativo, è necessario porre le seguenti domande a un fornitore di servizi cloud:

6.07.01. (a)

Il fornitore dispone di una procedura formale per rilevare, identificare, analizzare e rispondere agli imprevisti?

Abbiamo una politica e un piano documentati di risposta agli imprevisti di sicurezza, i cui principi chiave includono:

• Anticipare gli imprevisti di sicurezza e prepararsi per la risposta agli imprevisti.
• Contenere ed eliminare gli imprevisti, ed effettuare il ripristino dagli imprevisti.
• Investire nelle nostre persone, nei nostri processi e nelle nostre tecnologie per avere la certezza di disporre della capacità di rilevare e analizzare un imprevisto di sicurezza, qualora si verifichi.
• Adoperarsi affinché la protezione dei dati personali e dei dati dei clienti siano la massima priorità durante gli imprevisti di sicurezza.
• Condurre regolarmente il processo di risposta agli imprevisti di sicurezza.
• Acquisire informazioni dalla funzione di gestione degli imprevisti di sicurezza e migliorarla.
• Comunicare gli imprevisti di sicurezza critici al gruppo dirigenziale Atlassian.


In base a questa policy, Atlassian mantiene un piano di risposta agli imprevisti di sicurezza. Per ulteriori informazioni sulla nostra procedura di risposta agli imprevisti di sicurezza, vedi: https://www.atlassian.com/trust/security/security-incident-management

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

6.07.01. (b)

Questo processo è stato provato per verificare che i processi di gestione degli imprevisti siano efficaci? Il provider garantisce inoltre, durante le prove, che tutti i membri dell'organizzazione di supporto del provider di cloud siano a conoscenza del processo e del proprio ruolo durante la gestione degli imprevisti (sia durante l'incidente che dopo l'analisi)?

Per i nostri servizi Atlassian Cloud, i piani di continuità aziendale e ripristino di emergenza vengono testati almeno trimestralmente. La disponibilità in più regioni viene monitorata in tempo reale. I test automatici di failover regionale vengono eseguiti ogni settimana nell'ambiente di preproduzione. I test automatici di ripristino dei dati di configurazione vengono eseguiti quotidianamente in produzione. Tutti i servizi Atlassian eseguono test di resilienza della zona di disponibilità nell'ambiente di preproduzione ogni trimestre. Per ulteriori informazioni sul nostro programma di continuità aziendale, vedi: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

I nostri piani di ripristino di emergenza sono testati e convalidati dai nostri revisori esterni come parte del nostro programma di conformità; per ulteriori informazioni, vedi: https://www.atlassian.com/trust/compliance/resources

Abbiamo esercitato il nostro piano di risposta agli incidenti di sicurezza tramite attività in tempo reale sugli imprevisti. Manteniamo un approccio di miglioramento continuo per ottimizzare le nostre capacità di risposta.

Dopo che un incidente di elevata gravità 1 o 2 è stato risolto, il ticket originale dell'imprevisto viene chiuso e viene avviato un processo di revisione post-imprevisto (PIR). Per gli incidenti ad alta gravità, il team di sicurezza esegue un'analisi delle cause principali e propone potenziali miglioramenti al sistema e/o alla gestione del problema.

6.07.01. (c)

Come sono strutturate le funzionalità di rilevamento?

• Come può il cliente Cloud segnalare anomalie ed eventi di sicurezza al provider?
• Quali strutture abilita il provider per i servizi RTSM di terze parti selezionati dal cliente per intervenire nei loro sistemi (se necessario) o per coordinare le capacità di risposta agli imprevisti con il provider del cloud?
• Esiste un servizio di monitoraggio della sicurezza in tempo reale (RTSM)? Il servizio viene esternalizzato? Che tipo di parametri e servizi vengono monitorati?
• Fornisci (su richiesta) un report periodico sugli imprevisti di sicurezza (ad esempio, secondo la definizione ITIL)?
• Per quanto tempo vengono conservati i log di sicurezza? Questi log vengono archiviati in modo sicuro? Chi ha accesso ai log?
• È possibile per il cliente creare un HIPS/HIDS nell'immagine della macchina virtuale? È possibile integrare le informazioni raccolte dai sistemi di rilevamento e prevenzione delle intrusioni del cliente nel servizio RTSM del provider cloud o in quello di una terza parte?

La piattaforma Atlassian Cloud dispone di una superficie molto ridotta esposta ai firewall. Le regole dei firewall vengono riviste su base periodica. 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. A livello di container della piattaforma Cloud, l'integrità dei file viene mantenuta in quanto le istanze non sono modificabili. Atlassian Network Engineering utilizza tecnologie IPS integrate nei nostri firewall e abbiamo implementato tecnologie IDS nei nostri uffici e negli ambienti cloud. Le funzionalità DDoS sono fornite dal nostro fornitore/gestore di servizi Internet. Ulteriori informazioni sul nostro programma di rilevamento sono disponibili alla pagina: https://www.atlassian.com/trust/security/detections-program 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. Atlassian limita la capacità di visualizzare e leggere i log di controllo al personale autorizzato sulla nostra piattaforma di registrazione centralizzata. Atlassian gestisce anche canali di segnalazione esterni attraverso i quali può venire a conoscenza di vulnerabilità o imprevisti, tra cui il programma Bug Bounty, il portale di assistenza clienti nonché caselle e-mail e numeri di telefono sicuri. Inoltre, incoraggia i clienti a segnalare qualsiasi accesso non autorizzato o comportamento dannoso. Per saperne di più: https://www.atlassian.com/trust/security/security-incident-management and https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Come vengono definiti i livelli di gravità?

Atlassian utilizza il Common Vulnerability Scoring System (CVSS) come metodo per valutare il rischio per la sicurezza e stabilire le priorità per ciascuna vulnerabilità scoperta. I livelli di sicurezza utilizzati si basano sul punteggio CVSS calcolato automaticamente da Atlassian, cioè:

• critico;
• elevato;
• medio e
• basso.


Per maggiori dettagli, incluso quali intervalli di punteggi determinano la gravità, consulta: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Come vengono definite le procedure di escalation? Quando e se viene coinvolto il cliente Cloud?

Abbiamo una politica e un piano documentati di risposta agli imprevisti di sicurezza, i cui principi chiave includono:

• Anticipare gli imprevisti di sicurezza e prepararsi per la risposta agli imprevisti.
• Contenere ed eliminare gli imprevisti, ed effettuare il ripristino dagli imprevisti.
• Investire nelle nostre persone, nei nostri processi e nelle nostre tecnologie per avere la certezza di disporre della capacità di rilevare e analizzare un imprevisto di sicurezza, qualora si verifichi.
• Adoperarsi affinché la protezione dei dati personali e dei dati dei clienti siano la massima priorità durante gli imprevisti di sicurezza.
• Condurre regolarmente il processo di risposta agli imprevisti di sicurezza.
• Acquisire informazioni dalla funzione di gestione degli imprevisti di sicurezza e migliorarla.
• Comunicare gli imprevisti di sicurezza critici al gruppo dirigenziale Atlassian.


In base a questa policy, Atlassian gestisce un programma di risposta agli imprevisti di sicurezza. Per ulteriori informazioni sulla nostra procedura di risposta agli imprevisti di sicurezza, vedi: https://www.atlassian.com/trust/security/security-incident-management

Atlassian capisce quanto sia importante per te essere informato tempestivamente di qualsiasi violazione dei dati. Ecco perché Atlassian ha creato un team e un processo interfunzionali completi per gestire gli imprevisti di sicurezza, come descritto qui: https://www.atlassian.com/trust/security/security-incident-management

Atlassian ha una solida esperienza nella notifica tempestiva e proattiva degli imprevisti e nella collaborazione con i suoi clienti su tutte le mitigazioni necessarie.

Poiché è fondamentale che i team di risposta agli imprevisti di sicurezza di Atlassian si concentrino immediatamente sulla valutazione e sulla mitigazione di un imprevisto man mano che evolve, non possiamo garantire una timeline di 72 ore. Offriamo invece una notifica ai clienti "senza ritardo indebito", che segue il requisito legale previsto dal GDPR per i responsabili del trattamento dei dati, che soddisfa le esigenze legali della maggior parte dei nostri clienti.

Gli imprevisti possono variare da semplici a incredibilmente complessi, quindi, sebbene possiamo offrire ciò che è necessario per legge, non possiamo concordare una timeline "valida per tutti".

6.07.01. (f)

Come vengono documentati gli imprevisti e raccolte le prove?

I ticket Jira vengono 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.

Dopo che un imprevisto di elevata gravità 1 o 2 è stato risolto, il ticket originale dell'imprevisto viene chiuso e viene avviato un processo di revisione post-imprevisto (PIR). Per gli imprevisti ad alta gravità, il team di sicurezza esegue un'analisi delle cause principali e propone potenziali miglioramenti al sistema e/o alla gestione del problema.

6.07.01. (g)

Oltre all'autenticazione, alla contabilità e all'audit, quali altri controlli vengono attuati per prevenire (o ridurre al minimo l'impatto di) attività dannose da parte degli addetti ai lavori?

Atlassian ha 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. Ulteriori informazioni sul nostro programma di rilevamento sono disponibili alla pagina: https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

Il provider raccoglie metriche e indicatori degli imprevisti (ad esempio, numero di imprevisti rilevati o segnalati al mese, numero di imprevisti causati dai subappaltatori del provider del cloud e numero totale di tali imprevisti, tempo medio di risposta e risoluzione ecc.)?

• Quale di questi il provider può rendere pubblici (importante: non tutti i dati di segnalazione degli imprevisti possono essere resi pubblici poiché possono compromettere la riservatezza dei clienti e rivelare informazioni critiche per la sicurezza)?

Al momento, non rendiamo pubbliche le nostre metriche interne, ma condividiamo le azioni successive all'imprevisto per quelli operativi Sev 0 o Sev 1 sulla nostra Statuspage, vedi: https://status.atlassian.com/.

6.07.01. (j)

Con che frequenza il provider testa i programmi di ripristino di emergenza e continuità aziendale?

Per i nostri servizi Atlassian Cloud, i programmi di continuità aziendale e ripristino di emergenza vengono testati almeno trimestralmente. La disponibilità in più regioni viene monitorata in tempo reale. I test automatici di failover regionale vengono eseguiti ogni settimana nell'ambiente di pre-produzione. I test automatici di ripristino dei dati di configurazione vengono eseguiti quotidianamente in produzione. Tutti i servizi Atlassian eseguono test di resilienza della zona di disponibilità nell'ambiente di pre-produzione ogni trimestre. Per ulteriori informazioni sul nostro programma di continuità aziendale, vedi: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

I nostri programmi di ripristino di emergenza sono testati e convalidati dai nostri revisori esterni come parte del nostro programma di conformità; per ulteriori informazioni, vedi: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

Il provider raccoglie dati sui livelli di soddisfazione rispetto agli SLA?

Monitoriamo tutte le istanze Cloud per prestazioni e disponibilità, ma al momento non offriamo uno SLA formale sulla disponibilità delle applicazioni. Il nostro team di assistenza fornisce uno SLA iniziale sui tempi di risposta e, sebbene non abbiamo uno SLA ufficiale per la risoluzione dell'assistenza, il nostro obiettivo interno è risolvere tutti i casi assegnati entro 48 ore. Atlassian mostra le statistiche dell'ultimo stato del nostro sistema Cloud qui: https://status.atlassian.com.

Se scegli di utilizzare le nostre offerte Premium o Enterprise offriamo garanzie sugli SLA.

6.07.01. (l)

Il provider effettua test di help desk? Ad esempio:

• Test di impersonificazione (la persona dall'altra parte del telefono che richiede la reimpostazione della password è davvero chi dice di essere?) o i cosiddetti attacchi di "ingegneria sociale".

Atlassian fornisce corsi di formazione in materia di sicurezza delle informazioni come elemento della formazione di onboarding ("giorno 1") per starter 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. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Conserviamo registri formali sul completamento dei corsi di formazione da parte del personale interno. I dipendenti sono tenuti a prendere atto del Codice di condotta e a riaffermarlo con cadenza annuale. Questa policy viene fornita a tutti i dipendenti. I requisiti di consapevolezza in materia di sicurezza, riservatezza e privacy vengono presentati durante il primo giorno di formazione e sono disponibili per tutti i dipendenti in Confluence.

6.07.01. (m)

Il provider effettua test di penetrazione? Con quale frequenza? Cosa viene effettivamente testato durante il test di penetrazione? Ad esempio, viene testato l'isolamento di sicurezza di ogni immagine per garantire che non sia possibile "scappare" da un'immagine in un'altra e anche accedere all'infrastruttura host? I test dovrebbero anche verificare se è possibile accedere, tramite l'immagine virtuale, ai sistemi di gestione e assistenza dei provider cloud (ad esempio, i sistemi di provisioning e controllo degli accessi amministrativi).

Abbiamo un Red Team interno che conduce continue operazioni per i test di penetrazione su tutta la nostra infrastruttura, i servizi cloud e gli individui.

Ci avvaliamo di società di consulenza terze per eseguire test di penetrazione annuali su applicazioni rivolte all'esterno. Integriamo questi test anche con interventi minori e continui sulla sicurezza eseguiti dal nostro team interno apposito. Le lettere di valutazione per questi test di penetrazione sono disponibili qui, insieme a ulteriori informazioni sul nostro processo di test e sul nostro approccio ai test di sicurezza esterni: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Il provider effettua test di vulnerabilità? Con quale frequenza?

Il nostro team della sicurezza di Atlassian esegue regolarmente scansioni di vulnerabilità di rete dell'infrastruttura interna ed esterna utilizzando uno scanner di vulnerabilità riconosciuto dal settore. Per ulteriori informazioni sul nostro programma di gestione delle vulnerabilità, vedi: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Qual è il processo per correggere le vulnerabilità (correzioni rapide, riconfigurazione, aggiornamento a versioni successive del software ecc.)?

I ticket Jira vengono 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.

I dettagli sul nostro programma di gestione delle vulnerabilità sono disponibili all'indirizzo: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

Per quanto riguarda la sicurezza del personale, molti dei potenziali problemi sorgono perché l'infrastruttura IT è sotto il controllo di terse parti: come per l'esternalizzazione tradizionale, l'effetto di una violazione della sicurezza fisica può avere un impatto su più clienti (organizzazioni).

6.08. (a)

Quale garanzia fornisci al cliente in merito alla sicurezza fisica della posizione? Fornire esempi ed eventuali standard rispettati, ad esempio, sezione 9 della ISO 27001/2.

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.

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.

6.08. (a) (i)

Chi, oltre al personale IT autorizzato, ha accesso (fisico) senza accompagnamento all'infrastruttura IT?

• Ad esempio, addetti alle pulizie, dirigenti, personale addetto alla "sicurezza fisica", appaltatori, consulenti, fornitori ecc.

I nostri uffici Atlassian si basano sulla nostra policy interna di sicurezza fisica e ambientale, che include il monitoraggio dei punti fisici di ingresso e uscita. Abbiamo pubblicato estratti di tutte le nostre operazioni tecnologiche interne e delle policy di sicurezza all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies

Gli uffici di Atlassian dispongono di controlli degli accessi, tra cui lettori di badge e videosorveglianza, e hanno la possibilità di limitare l'accesso a orari/giorni specifici, se necessario. I registri di accesso agli edifici per uffici sono gestiti da Building Management e sono disponibili su Workplace Experience per scopi di indagine.

I nostri partner dispongono di diverse certificazioni di conformità per i propri data center, che riguardano la sicurezza fisica, 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. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance

6.08. (a) (ii)

Con che frequenza vengono esaminati i diritti di accesso?

• Quanto velocemente possono essere revocati i diritti di accesso?

Atlassian valuta le prestazioni e l'efficacia del suo ISMS utilizzando metriche adeguate. Monitoriamo le prestazioni dell'Atlassian Trust Management System (ATMS) e i controlli pertinenti tramite revisioni di audit interne ed esterne. Il team di conformità di Atlassian gestisce sia la programmazione di audit di idoneità interni sia quella di audit esterni, che sono documentati internamente nella nostra pagina dedicata all'audit delle roadmap. Gli audit interni sono incentrati sulle aree ad alto rischio di Atlassian e vengono svolti a cadenza regolare secondo programmazioni predeterminate e in base all'Enterprise Audit Schedule concordato tra il team addetto alla valutazione dei rischi e alla conformità e il team di audit interno. Al momento, non rendiamo pubbliche le nostre metriche interne. L'ATMS viene valutato con cadenza annuale da terze parti indipendenti e anche in seguito a modifiche significative. Atlassian ha ottenuto le certificazioni SOC2, ISO27001 e ISO27018 per i nostri servizi cloud principali. Inoltre, Atlassian monitora ciascuno dei pilastri dell'ATMS mediante riunioni periodiche di revisione operativa che includono metriche specifiche per ciascuno. Ciò include revisioni settimanali dello stato di conformità dell'ATMS e altre riunioni documentate internamente nelle pagine ATMS: analisi dello stato di conformità e Note della riunione. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/compliance.

Abbiamo un programma formale di gestione della sicurezza e rivediamo il nostro programma di gestione della sicurezza delle informazioni (ISMP) con cadenza annuale. Per maggiori informazioni sul nostro programma di gestione della sicurezza, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

Valuti regolarmente i rischi per la sicurezza e i perimetri?

• Con che frequenza?

Atlassian valuta le prestazioni e l'efficacia del suo ISMS utilizzando metriche adeguate. Monitoriamo le prestazioni dell'Atlassian Trust Management System (ATMS) e i controlli pertinenti tramite revisioni di audit interne ed esterne. Il team di conformità di Atlassian gestisce sia la programmazione di audit di idoneità interni sia quella di audit esterni, che sono documentati internamente nella nostra pagina dedicata all'audit delle roadmap. Gli audit interni sono incentrati sulle aree ad alto rischio di Atlassian e vengono svolti a cadenza regolare secondo programmazioni predeterminate e in base all'Enterprise Audit Schedule concordato tra il team addetto alla valutazione dei rischi e alla conformità e il team di audit interno. Al momento, non rendiamo pubbliche le nostre metriche interne. L'ATMS viene valutato con cadenza annuale da terze parti indipendenti e anche in seguito a modifiche significative. Atlassian ha ottenuto le certificazioni SOC2, ISO27001 e ISO27018 per i nostri servizi cloud principali. Inoltre, Atlassian monitora ciascuno dei pilastri dell'ATMS mediante riunioni periodiche di revisione operativa che includono metriche specifiche per ciascuno. Ciò include revisioni settimanali dello stato di conformità dell'ATMS e altre riunioni documentate internamente nelle pagine ATMS: analisi dello stato di conformità e Note della riunione. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/compliance.

Abbiamo un programma formale di gestione della sicurezza e rivediamo il nostro programma di gestione della sicurezza delle informazioni (ISMP) con cadenza annuale. Per maggiori informazioni sul nostro programma di gestione della sicurezza, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

Esegui valutazioni regolari dei rischi che includono, per esempio, gli edifici vicini?

Atlassian valuta le prestazioni e l'efficacia del suo ISMS utilizzando metriche adeguate. Monitoriamo le prestazioni dell'Atlassian Trust Management System (ATMS) e i controlli pertinenti tramite revisioni di audit interne ed esterne. Il team di conformità di Atlassian gestisce sia la programmazione di audit di idoneità interni sia quella di audit esterni, che sono documentati internamente nella nostra pagina dedicata all'audit delle roadmap. Gli audit interni sono incentrati sulle aree ad alto rischio di Atlassian e vengono svolti a cadenza regolare secondo programmazioni predeterminate e in base all'Enterprise Audit Schedule concordato tra il team addetto alla valutazione dei rischi e alla conformità e il team di audit interno. Al momento, non rendiamo pubbliche le nostre metriche interne. L'ATMS viene valutato con cadenza annuale da terze parti indipendenti e anche in seguito a modifiche significative. Atlassian ha ottenuto le certificazioni SOC2, ISO27001 e ISO27018 per i nostri servizi cloud principali. Inoltre, Atlassian monitora ciascuno dei pilastri dell'ATMS mediante riunioni periodiche di revisione operativa che includono metriche specifiche per ciascuno. Ciò include revisioni settimanali dello stato di conformità dell'ATMS e altre riunioni documentate internamente nelle pagine ATMS: analisi dello stato di conformità e Note della riunione. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/compliance.

Abbiamo un programma formale di gestione della sicurezza e rivediamo il nostro programma di gestione della sicurezza delle informazioni (ISMP) con cadenza annuale. Per maggiori informazioni sul nostro programma di gestione della sicurezza, consulta la pagina: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

Controlli o monitori il personale (comprese le terze parti) che accede alle aree sicure?

I nostri uffici Atlassian si basano sulla nostra policy interna di sicurezza fisica e ambientale, che include il monitoraggio dei punti fisici di ingresso e uscita. Abbiamo pubblicato estratti di tutte le nostre operazioni tecnologiche interne e delle policy di sicurezza all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies

Gli uffici di Atlassian dispongono di controlli degli accessi, tra cui lettori di badge e videosorveglianza, e hanno la possibilità di limitare l'accesso a orari/giorni specifici, se necessario. I registri di accesso agli edifici per uffici sono gestiti da Building Management e sono disponibili su Workplace Experience per scopi di indagine.

I nostri partner dispongono di diverse certificazioni di conformità per i propri data center, che riguardano la sicurezza fisica, 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. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance

6.08. (a) (vi)

Quali sono le policy o le procedure per il carico, lo scarico e l'installazione delle apparecchiature?

Negli uffici di Atlassian, le banchine di carico sono isolate dalle aree di lavoro e sono costantemente monitorate dalle telecamere a circuito chiuso e dal personale dell'edificio. I nostri partner di hosting dei data center gestiscono la sicurezza fisica e ci affidiamo alle loro certificazioni di conformità per convalidare l'efficacia dei controlli.

6.08. (a) (vii)

Le consegne vengono ispezionate per individuare eventuali rischi prima dell'installazione?

Negli uffici di Atlassian, le banchine di carico sono isolate dalle aree di lavoro e sono costantemente monitorate dalle telecamere a circuito chiuso e dal personale dell'edificio. I nostri partner di hosting dei data center gestiscono la sicurezza fisica e ci affidiamo alle loro certificazioni di conformità per convalidare l'efficacia dei controlli.

6.08. (a) (viii)

Esiste un inventario fisico aggiornato degli articoli presenti nel data center?

Un estratto della nostra politica di gestione delle risorse è disponibile all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario di tutte le risorse di produzione e dei loro proprietari. Tutti i nostri sistemi si trovano in data center basati su AWS non tracciati a livello hardware a causa della natura del servizio.

Tutti i microservizi sono tracciati in un database "Service" personalizzato, che viene aggiornato man mano che viene distribuito qualsiasi servizio. Il team Workplace Technology di Atlassian gestisce un inventario delle risorse di tutti gli endpoint utilizzando Jira Software per finalità di monitoraggio.

Tutti i microservizi sono classificati in livelli, che hanno aspettative di tempi di attività, disponibilità, RTO e RPO associate a ciascun livello. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

I cavi di rete attraversano le aree di accesso pubblico?

• Usi cavi o condotti rinforzati?

I nostri uffici Atlassian si basano sulla nostra policy interna di sicurezza fisica e ambientale, che include il monitoraggio dei punti fisici di ingresso e uscita. Abbiamo pubblicato estratti di tutte le nostre operazioni tecnologiche interne e delle policy di sicurezza all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies

Gli uffici di Atlassian dispongono di controlli degli accessi, tra cui lettori di badge e videosorveglianza, e hanno la possibilità di limitare l'accesso a orari/giorni specifici, se necessario. I registri di accesso agli edifici per uffici sono gestiti da Building Management e sono disponibili su Workplace Experience per scopi di indagine.

6.08. (a) (x)

Esegui regolarmente ispezioni nei locali per verificare che non vi siano apparecchiature non autorizzate?

Un estratto della nostra politica di gestione delle risorse è disponibile all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario di tutte le risorse di produzione e dei loro proprietari. Tutti i nostri sistemi si trovano in data center basati su AWS non tracciati a livello hardware a causa della natura del servizio.

Tutti i microservizi sono tracciati in un database "Service" personalizzato, che viene aggiornato man mano che viene distribuito qualsiasi servizio. Il team Workplace Technology di Atlassian gestisce un inventario delle risorse di tutti gli endpoint utilizzando Jira Software per finalità di monitoraggio.

6.08. (a) (xi)

Utilizzi apparecchiature off-site?

• Come vengono protette?

Un estratto della nostra politica di gestione delle risorse è disponibile all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies. Atlassian mantiene un inventario di tutte le risorse di produzione e dei loro proprietari. Tutti i nostri sistemi si trovano in data center basati su AWS non tracciati a livello hardware a causa della natura del servizio.

Tutti i microservizi sono tracciati in un database "Service" personalizzato, che viene aggiornato man mano che viene distribuito qualsiasi servizio. Il team Workplace Technology di Atlassian gestisce un inventario delle risorse di tutti gli endpoint utilizzando Jira Software per finalità di monitoraggio.

6.08. (a) (xii)

Il personale utilizza apparecchiature portatili (ad es. laptop, smartphone) che possono dare accesso al data center?

• Come vengono protette?

I nostri partner dispongono di diverse certificazioni di conformità per i propri data center, che riguardano la sicurezza fisica, 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. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance/

I membri autorizzati e formati dei team di Atlassian Engineering che sono stati sottoposti a controlli di background si autenticano sulla VPN utilizzando password complesse univoche e TOTP basati sull'autenticazione a due fattori, quindi accedono all'ambiente di produzione solo tramite connessioni terminali SSH utilizzando certificati RSA personali protetti da passphrase. Su tutti i server di produzione è presente un sistema IDS, che include il monitoraggio e la creazione di avvisi in tempo reale su eventuali modifiche ai file o alla configurazione del sistema di produzione e sugli eventi di sicurezza anomali. Per i membri autorizzati e formati del team operativo con accesso al sistema di produzione, qualsiasi postazione di lavoro con Windows oppure OS X utilizzata per l'accesso del terminale SSH all'ambiente di produzione deve eseguire un software antivirus attuale e attivo. I dati dei clienti non vengono replicati sulle postazioni di lavoro o sui dispositivi mobili dei dipendenti.

6.08. (a) (xiii)

Quali misure vengono adottate per controllare le schede di accesso?

I nostri uffici Atlassian si basano sulla nostra policy interna di sicurezza fisica e ambientale, che include il monitoraggio dei punti fisici di ingresso e uscita. Abbiamo pubblicato estratti di tutte le nostre operazioni tecnologiche interne e delle policy di sicurezza all'indirizzo: https://www.atlassian.com/trust/security/ismp-policies

Gli uffici di Atlassian dispongono di controlli degli accessi, tra cui lettori di badge e videosorveglianza, e hanno la possibilità di limitare l'accesso a orari/giorni specifici, se necessario. I registri di accesso agli edifici per uffici sono gestiti da Building Management e sono disponibili su Workplace Experience per scopi di indagine.

6.08. (a) (xiv)

Quali sono i processi o le procedure in vigore per distruggere i vecchi supporti o sistemi quando necessario?

• Dati sovrascritti?
• Distruzione fisica?

Il team Workplace Technology gestisce questo processo, le apparecchiature vengono disinfettate e smagnetizzate in modo appropriato. Atlassian non gestisce alcun supporto fisico che supporti i nostri prodotti e servizi cloud.

6.08. (a) (xv)

Quali sono i processi di autorizzazione in vigore per lo spostamento delle apparecchiature da un sito all'altro?

• Come si identifica il personale (o gli appaltatori) autorizzato a farlo?

I partner di hosting dei data center (AWS) di Atlassian gestiscono la sicurezza fisica e ci affidiamo alla loro certificazione SOC2 per convalidare l'efficacia dei controlli.

I prodotti Atlassian Cloud non spostano fisicamente i dati dei clienti. I dischi rigidi con i dati dei clienti vengono distrutti o sanificati prima di lasciare i data center AWS protetti. Per i sistemi ospitati in AWS, i dati possono essere spostati da una regione all'altra in uno scenario ridondante, ma rimangono sempre all'interno di AWS. Per ulteriori informazioni sulle nostre regioni AWS, vedi: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

Con che frequenza vengono effettuati gli audit delle apparecchiature per verificare che non vengano rimosse senza autorizzazione?

I partner di hosting dei data center (AWS) di Atlassian gestiscono la sicurezza fisica e ci affidiamo alla loro certificazione SOC2 per convalidare l'efficacia dei controlli.

I prodotti Atlassian Cloud non spostano fisicamente i dati dei clienti. I dischi rigidi con i dati dei clienti vengono distrutti o sanificati prima di lasciare i data center AWS protetti. Per i sistemi ospitati in AWS, i dati possono essere spostati da una regione all'altra in uno scenario ridondante, ma rimangono sempre all'interno di AWS. Per ulteriori informazioni sulle nostre regioni AWS, vedi: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

Con che frequenza vengono effettuati i controlli per garantire che l'ambiente sia conforme ai requisiti legali e normativi appropriati?

Il team legale e i team di conformità di Atlassian monitorano i nostri obblighi normativi. Per consultare il nostro Programma legale, visita la pagina: https://www.atlassian.com/legal/. Maggiori informazioni sul nostro programma di conformità sono disponibili all'indirizzo: https://www.atlassian.com/trust/compliance.

6.09. (a)

Quali sono le procedure o le policy in vigore per garantire che i problemi ambientali non causino un'interruzione del servizio?

I nostri uffici Atlassian si basano sulla 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, 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. Le informazioni sulla garanzia della protezione fisica di AWS sono disponibili all'indirizzo: http://aws.amazon.com/compliance/

Sono in vigore una politica di continuità aziendale e ripristino di emergenza e un piano di continuità aziendale e ripristino di emergenza che vengono rivisti su base annuale dal comitato direttivo per la continuità aziendale e il ripristino di emergenza. I responsabili di sistemi, processi o servizi mission critical devono garantire continuità aziendale e/o ripristino di emergenza adeguati che siano in linea con la tolleranza alle interruzioni prevista in caso di emergenza. I piani BCDR vengono testati trimestralmente e tutti i problemi identificati vengono risolti. Per maggiori informazioni, vedi: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Quali metodi usi per prevenire i danni causati da incendi, inondazioni, terremoti, ecc.?

• In caso di guasto, quali misure di sicurezza aggiuntive vengono adottate per proteggere l'accesso fisico?
• Sia nei siti principali che in quelli secondari?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (c)

Monitori la temperatura e l'umidità all'interno del data center?

• Considerazioni od osservazioni sulla climatizzazione?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (d)

Proteggi gli edifici dai fulmini?

• Anche le linee elettriche e di comunicazione?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (e)

Hai generatori autonomi in caso di interruzione di corrente?

• Per quanto tempo possono funzionare?
• Ci sono scorte di carburante adeguate?
• Esistono generatori di failover?
• Con che frequenza controlli le apparecchiature UPS?
• Con che frequenza controlli i generatori?
• Hai più fornitori di energia?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (f)

Le utenze (elettricità, acqua, ecc.) sono in grado di supportare il tuo ambiente?

• Con che frequenza vengono rivalutate e testate?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (g)

Il tuo impianto di climatizzazione è in grado di supportare il tuo ambiente?

• Con che frequenza viene testato?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (h)

Segui i programmi di manutenzione consigliati dai produttori?

Atlassian si affida a partner di hosting dei dati per convalidare la sicurezza dei data center e i controlli ambientali. Per AWS, vedi https://aws.amazon.com/compliance/programs.

6.09. (i)

Permetti solo al personale di manutenzione autorizzato di accedere al sito?

• Come verifichi la loro identità?

L'accesso fisico agli uffici è protetto dalla necessità dell'utilizzo del badge elettronico, dalla reception in orario di ufficio con accesso obbligatorio per i visitatori e dalle telecamere a circuito chiuso in tutti i punti di ingresso e uscita dell'edificio. Le banchine di carico sono costantemente monitorate dalle telecamere a circuito chiuso e dal personale dell'edificio. I nostri partner di hosting dei data center gestiscono la sicurezza fisica e ci affidiamo alle loro certificazioni di conformità per convalidare l'efficacia dei controlli.

6.09. (j)

I dati vengono rimossi dai dispositivi che vengono mandati in riparazione?

• Come si fa?

Il team Workplace Technology gestisce questo processo, le apparecchiature vengono disinfettate e smagnetizzate in modo appropriato. Atlassian non gestisce alcun supporto fisico che supporti i nostri prodotti e servizi cloud.

6.10.

I clienti reali e potenziali dei fornitori di servizi cloud dovrebbero tenere conto dei rispettivi obblighi nazionali e sovranazionali di conformità ai quadri normativi e garantire che tali obblighi siano adeguatamente rispettati.

Le principali domande legali che il cliente deve porre al fornitore di servizi cloud sono:

6.10. (a)

In che Paese si trova il fornitore di servizi cloud?

Atlassian ha 12 uffici in 8 Paesi, situati a Sydney, Amsterdam, Ankara, Boston, Bengaluru, San Francisco, Mountain View, Austin (Texas), New York, Manila, Danzica e Yokohama. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/company/contact.

6.10. (b)

L'infrastruttura del provider cloud si trova in un unico Paese o in Paesi diversi?

Per Atlassian Cloud, attualmente siamo ospitati in zone di disponibilità AWS ridondanti. Per ulteriori informazioni sulle regioni specifiche, vedi: https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

Il provider cloud utilizzerà altre società la cui infrastruttura si trova al di fuori di quella del provider cloud?

I prodotti e i dati Atlassian Cloud sono ospitati su Amazon Web Services (AWS), il provider di servizi cloud leader del settore. I nostri prodotti vengono eseguiti in un ambiente PaaS (Platform as a Service) suddiviso in due insiemi principali di infrastrutture che chiamiamo Micros e non Micros. Jira, Confluence, Statuspage, Access e Bitbucket vengono eseguiti sulla piattaforma Micros, mentre Opsgenie e Trello su quella non Micros.

6.10. (d)

Dove saranno collocati fisicamente i dati?

Atlassian utilizza Amazon Web Services (AWS) nelle seguenti località: Stati Uniti occidentali e orientali, Irlanda, Francoforte, Singapore e Sydney (Confluence Jira).

Dettagli specifici del prodotto:

• Trello: disponibile su AWS negli Stati Uniti orientali (Ohio).
• Jira Align: l'ubicazione fisica dei dati dei clienti può essere richiesta tramite ticket di assistenza. Vedi: https://support.atlassian.com/jira-align/.
• Statuspage: disponibile su AWS negli Stati Uniti occidentali (Oregon, California) e orientali (Ohio).
• Opsgenie: dispone di account AWS sia negli Stati Uniti che in Europa. Il cliente deve optare per AWS USA (Oregon, California) o UE (Francoforte) al momento dell'iscrizione.
• Halp: in hosting su AWS in negli Stati Uniti orientali e occidentali.
• Bitbucket: i repository e le funzionalità principali delle applicazioni sono in hosting su AWS negli Stati Uniti orientali e occidentali.


Per ulteriori informazioni sulla residenza dei dati, vedi: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

La giurisdizione sulle condizioni contrattuali e sui dati sarà divisa?

La legge predefinita che disciplina il contratto con il cliente Atlassian è la legge della California. Contatta il nostro il team delle vendite Enterprise per maggiori dettagli.

6.10. (f)

Qualcuno dei servizi del provider cloud verrà subappaltato all'esterno?

Atlassian lavora con subappaltatori di terzi per fornire servizi come siti web, sviluppo di applicazioni, hosting, manutenzione, backup, archiviazione, infrastruttura virtuale, elaborazione dei pagamenti e analisi. Questi fornitori di servizi possono avere accesso alle informazioni personali identificabili (PII) o elaborarle per svolgere la propria attività.

Atlassian comunica ai clienti pertinenti qualsiasi utilizzo di subappaltatori che possano elaborare le loro PII, tramite notifica, prima che avvenga l'elaborazione. Un elenco esterno di subappaltatori con cui collabora Atlassian è fornito nella pagina Atlassian Subprocessor all'indirizzo: https://www.atlassian.com/legal/sub-processors. In questa pagina, i visitatori sono invitati a iscriversi a un feed RSS per ricevere una notifica quando aggiungiamo nuovi Atlassian Subprocessor.

6.10. (g)

Qualcuno dei servizi del provider cloud verrà esternalizzato?

Quando Atlassian coinvolge fornitori terzi, ci assicuriamo che le loro attività non compromettano in alcun modo i nostri clienti o i loro dati. I reparti legali e di approvvigionamento di Atlassian esaminano i contratti, gli SLA e le politiche interne dei fornitori per determinare se questi ultimi soddisfano i requisiti di sicurezza, disponibilità e riservatezza. Per maggiori informazioni, consulta la pagina: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

Come verranno raccolti, elaborati e trasferiti i dati forniti dal cliente e dai clienti del cliente?

Atlassian elabora le informazioni in modo compatibile con gli scopi per i quali sono state raccolte o successivamente autorizzate dall'individuo e, in particolare, in conformità con l'Informativa esterna sulla privacy di Atlassian.

La privacy degli utenti è importante per Atlassian, così come la trasparenza sulle nostre modalità di raccolta, utilizzo e condivisione delle informazioni che riguardano gli utenti. Per ulteriori informazioni, consulta la nostra pagina dedicata alla privacy in Atlassian nell'Atlassian Trust Center, all'indirizzo https://www.atlassian.com/trust/privacy e la nostra Informativa sulla privacy all'indirizzo https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

Cosa succede ai dati inviati al provider di cloud dopo la cessazione del contratto?

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/