Architettura e pratiche operative di Atlassian Cloud

Architettura di hosting di Atlassian Cloud

Utilizziamo Amazon Web Services (AWS) come fornitore di servizi cloud e le sue strutture di data center ad alta disponibilità in più regioni del mondo. Ogni regione AWS è una posizione geografica separata con più gruppi di data center, isolati e fisicamente separati, noti come zone di disponibilità (AZ).

Sfruttiamo i servizi di calcolo, archiviazione, rete e dati di AWS per sviluppare i nostri prodotti e i componenti della piattaforma e tali servizi ci consentono di utilizzare le funzionalità di ridondanza offerte da AWS, come le zone di disponibilità e le regioni.

Zone di disponibilità

Ogni zona di disponibilità è progettata per essere isolata dai guasti di altre zone e per fornire connettività di rete conveniente e a bassa latenza ad altre AZ nella stessa regione. Questa disponibilità elevata multizona rappresenta la prima linea di difesa per i rischi geografici e ambientali e ciò significa che i servizi in esecuzione nelle distribuzioni multi-AZ devono essere in grado di fronteggiare i guasti nelle AZ.

Jira e Confluence utilizzano la modalità di implementazione multi-AZ per Amazon RDS (Relational Database Service). In un'implementazione multi-AZ, Amazon RDS fornisce e mantiene una replica in standby sincrona in una zona di disponibilità diversa all'interno della stessa regione per fornire ridondanza e funzionalità di failover. Il failover delle zone di disponibilità è automatizzato e richiede in genere 60-120 secondi, in modo che le operazioni del database possano riprendere il più rapidamente possibile senza interventi amministrativi. Opsgenie, Statuspage, Trello e Jira Align utilizzano strategie di distribuzione simili, con piccole differenze nei tempi di replica e di failover.

Posizione dei dati

I dati di Jira e Confluence sono posizionati nella regione più vicina a quella in cui si trova la maggior parte dei tuoi utenti al momento dell'iscrizione. I dati di Bitbucket si trovano in due diverse zone di disponibilità nella regione degli Stati Uniti orientali.

Tuttavia, comprendiamo che alcuni utenti potrebbero richiedere che i propri dati rimangano in una posizione specifica, quindi offriamo opzioni di residenza dei dati. Attualmente, la residenza dei dati è disponibile per Jira, Jira Service Management, Jira Product Discovery e Confluence in 11 aree geografiche, cioè Stati Uniti, Unione europea, Regno Unito, Australia, Canada, Germania, India, Giappone, Singapore, Corea del Sud e Svizzera. Leggi la nostra documentazione per saperne di più sulla residenza dei dati e sui dati di prodotto inclusi nell'ambito. Inoltre, puoi seguire la nostra roadmap per avere aggiornamenti sulla residenza dei dati, comprese le espansioni a nuovi prodotti, aree geografiche e tipi di dati.

Backup dei dati

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, le snapshot di archiviazione vengono conservate per 7 giorni con il supporto per il ripristino tramite punto temporale.

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.

Sicurezza dei data center

AWS gestisce più certificazioni per la protezione dei data center. Queste certificazioni 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.

Architettura dei servizi distribuiti

Con questa architettura AWS, ospitiamo una serie di servizi di piattaforma e prodotto utilizzati nelle nostre soluzioni. Ciò include funzionalità di piattaforma condivise e utilizzate in più prodotti Atlassian, come Media, Identity e Commerce, esperienze come il nostro Editor, nonché funzionalità di prodotto specifiche, come il servizio Ticket di Jira e Confluence Analytics.

Architettura multi-tenant

Oltre alla nostra infrastruttura cloud, abbiamo creato un'architettura di microservizi multi-tenant con una piattaforma condivisa che supporta i nostri prodotti. In un'architettura multi-tenant, un singolo servizio serve più clienti, tra cui le istanze di database e di calcolo necessarie per eseguire i nostri prodotti Cloud. Ogni partizione (essenzialmente un container, vedi la figura 3 di seguito) contiene i dati relativi a più tenant, ma i dati di ciascun tenant sono isolati e inaccessibili agli altri tenant. È importante notare che non offriamo un'architettura a singolo tenant.

Provisioning e ciclo di vita del tenant

Quando viene eseguito il provisioning di un nuovo cliente, una serie di eventi attiva l'orchestrazione dei servizi distribuiti e il provisioning degli archivi di dati. Questi eventi possono essere generalmente ricondotti a uno dei sette passaggi del ciclo di vita:

1. I sistemi Commerce vengono immediatamente aggiornati con i metadati e le informazioni di controllo degli accessi più recenti relativi a quel cliente specifico, quindi un sistema di orchestrazione del provisioning allinea lo "stato delle risorse sottoposte a provisioning" con lo stato della licenza attraverso una serie di eventi tenant e di prodotto.

Eventi tenant

Questi eventi riguardano il tenant nel suo complesso e possono essere i seguenti:

• Creazione: un tenant viene creato e utilizzato per siti completamente nuovi
• Distruzione: un intero tenant viene eliminato

Eventi di prodotto

• Attivazione: dopo l'attivazione di prodotti concessi in licenza o app di terze parti
• Disattivazione: dopo la disattivazione di determinati prodotti o app
• Sospensione: dopo la sospensione di un determinato prodotto esistente che disattiva l'accesso a un determinato sito di proprietà
• Annullamento della sospensione: dopo l'annullamento della sospensione di un determinato prodotto esistente che consente l'accesso a un sito di proprietà
• Aggiornamento della licenza: contiene informazioni sul numero di postazioni di licenza per un determinato prodotto e sul suo stato (attivo/inattivo)

2. Creazione del sito del cliente e attivazione del set corretto di prodotti per il cliente. Il concetto di sito rimanda al container di più prodotti concessi in licenza a un determinato cliente (ad es. Confluence e Jira Software per ＜nome-sito＞.atlassian.net).

Separazione dei tenant

Anche se i clienti condividono un'infrastruttura IT comune basata su cloud quando utilizzano i nostri prodotti Cloud, abbiamo implementato misure volte garantire che questi siano separati logicamente in modo che le azioni di un cliente non possano compromettere i dati o il servizio di altri clienti.

L'approccio adottato da Atlassian per raggiungere questo obiettivo varia a seconda delle applicazioni. Nel caso di Jira e Confluence Cloud, utilizziamo un concetto che definiamo "contesto del tenant" per ottenere l'isolamento logico dei nostri clienti. È implementato nel codice dell'applicazione ed è gestito da un servizio che abbiamo creato e chiamato "Tenant Context Service" (TCS). Questo concetto garantisce che:

• I dati di ogni cliente siano isolati logicamente dagli altri tenant quando sono inattivi.
• Tutte le richieste elaborate da Jira o Confluence abbiano una vista specifica per tenant in modo che non ci sia alcun impatto su altri tenant.

In generale, il funzionamento di TCS si basa sull'archiviazione di un contesto per i singoli tenant dei clienti. Il contesto di ciascun tenant è associato a un ID univoco archiviato centralmente da TCS e include un intervallo di metadati associati al tenant, ad esempio, i database in cui si trova il tenant, le licenze di cui il tenant dispone, le funzioni alle quali può accedere e una serie di altre informazioni di configurazione. Quando un cliente accede a Jira o a Confluence Cloud, TCS utilizza l'ID tenant per raccogliere i metadati, che vengono quindi collegati alle eventuali operazioni eseguite dal tenant nell'applicazione durante la sessione.

Edge Atlassian

I tuoi dati sono protetti anche tramite ciò che definiamo edge, ovvero le "pareti" virtuali che costruiamo intorno al nostro software. Quando riceviamo una richiesta, questa viene inviata all'edge più vicino. Attraverso una serie di convalide, la richiesta è autorizzata o negata.

• Arrivano sull'edge Atlassian più vicino all'utente. L'edge verifica la sessione e l'identità dell'utente attraverso il tuo sistema di identità.
• L'edge determina la posizione dei dati del prodotto, in base ai dati contenuti nelle informazioni TCS.
• L'edge inoltra la richiesta alla regione di destinazione, dove arriva su un nodo di elaborazione.
• Il nodo utilizza il sistema di configurazione tenant per determinare le informazioni, come la licenza e la posizione del database, ed esegue una chiamata a vari altri archivi di dati e servizi (ad esempio la piattaforma multimediale che ospita immagini e allegati) allo scopo di recuperare le informazioni necessarie per soddisfare la richiesta.
• La richiesta originale dell'utente con le informazioni raccolte dalle sue precedenti chiamate ad altri servizi.

Autenticazione e autorizzazione del servizio

La nostra piattaforma utilizza un modello con privilegi minimi per l'accesso ai dati. Ciò significa che l'accesso a tutti i dati è limitato al solo servizio responsabile del salvataggio, dell'elaborazione o del recupero. Ad esempio, i servizi multimediali, che consentono di avere un'esperienza coerente di caricamento e download di file sui nostri prodotti Cloud, dispongono di un provisioning di archiviazione dedicato a cui nessun altro servizio Atlassian può accedere. Qualsiasi servizio che richieda l'accesso ai contenuti multimediali deve interagire con l'API dei servizi multimediali. Di conseguenza, un'autenticazione e un'autorizzazione forti a livello di servizio impongono anche una forte separazione dei compiti e un accesso ai dati con privilegi minimi.

Utilizziamo i web token JSON (JWT) per garantire l'autorità di firma al di fuori dell'applicazione; pertanto, i nostri sistemi di identità e il contesto del tenant sono la fonte di riferimento. I token non possono essere utilizzati per scopi diversi da quelli per cui sono autorizzati. Quando viene effettuata una chiamata a un microservizio o a una partizione, da parte tua o di una persona del tuo team, i token vengono passati al tuo sistema di identità e convalidati in base a esso. Questo processo garantisce che il token sia aggiornato e firmato prima della condivisione dei dati appropriati. Quando è combinato con l'autorizzazione e l'autenticazione necessarie per accedere a questi microservizi, se un servizio è compromesso, ha un ambito limitato.

Tuttavia, sappiamo che a volte i sistemi di identità possono essere compromessi. Per ridurre il rischio, utilizziamo due meccanismi. Innanzitutto, TCS e i proxy di identità sono altamente replicati. Abbiamo un sidecar TCS per quasi tutti i microservizi e utilizziamo sidecar proxy che si propagano all'autorità di identità, quindi esistono migliaia di questi servizi in esecuzione in ogni momento. Se è presente un comportamento anomalo in uno o più di essi, possiamo individuarlo rapidamente e risolvere il problema.

Inoltre, non aspettiamo che qualcuno trovi una vulnerabilità nei nostri prodotti o nella nostra piattaforma. Stiamo identificando attivamente questi scenari in modo da ridurre al minimo l'impatto per te ed eseguiamo una serie di programmi di sicurezza per identificare, rilevare e rispondere alle minacce alla sicurezza.

Servizio di contesto del tenant

Ci assicuriamo che le richieste a qualsiasi microservizio contengano metadati sul cliente, o il tenant, che richiede l'accesso. È ciò che viene definito Tenant Context Service. È popolato direttamente dai nostri sistemi di provisioning. Quando viene avviata una richiesta, il contesto viene letto e acquisito nel codice di servizio in esecuzione, che è utilizzato per autorizzare l'utente. Tutti gli accessi ai servizi, e quindi l'accesso ai dati, in Jira e Confluence richiedono questo contesto del tenant o la richiesta verrà rifiutata.

L'autenticazione e l'autorizzazione del servizio vengono applicate tramite l'Atlassian Service Authentication Protocol (ASAP). Un elenco esplicito degli elementi consentiti stabilisce quali servizi possono comunicare e i dettagli di autorizzazione specificano quali comandi e percorsi sono disponibili. Questo limita il potenziale movimento laterale di un servizio compromesso.

L'autenticazione e l'autorizzazione del servizio, così come l'uscita, sono controllate da una serie di proxy dedicati. Ciò elimina la possibilità che le vulnerabilità del codice dell'applicazione influiscano su questi controlli. L'esecuzione di codice in modalità remota richiederebbe la compromissione dell'host sottostante e l'elusione dei limiti del container Docker, non solo la capacità di modificare la logica dell'applicazione. Il nostro rilevamento delle intrusioni a livello di host, invece, segnala le discrepanze.

Questi proxy vincolano il comportamento in uscita in base al comportamento previsto dal servizio. I servizi che non devono emettere webhook o comunicare con altri microservizi a cui è vietato farlo.

Crittografia dei dati

Customer data in Atlassian cloud products is encrypted during transmission utilizing TLS 1.2 or higher, incorporating perfect forward secrecy (PFS) to safeguard against unauthorized information disclosure and data modification. We adhere to NIST-recommended TLS 1.2+ protocols, which enforce the use of strong ciphers and key lengths as supported by the browser.

Customer data, including attachments, stored on the cloud services such as Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie, and Trello are protected using industry-standard AES-256 encryption at rest.

Personally Identifiable Information (PII) transmission is protected through encryption and robust data access controls, which are designed to ensure that data is securely transmitted to its intended destination. Atlassian's Cryptography and Encryption Policy outlines principles for implementing encryption and cryptography to mitigate risks related to storing and transmitting PII. The encryption algorithms for protecting PII are aligned with the classification level of the PII, as specified by Atlassian's internal Data Security & Information Lifecycle Management policies. This ensures that sensitive data is adequately secured based on its classification. To learn more about how we collect, share, and use customer data, refer to our privacy page.

Per essere sempre aggiornato sulle ulteriori funzionalità di crittografia dei dati, consulta la nostra roadmap per i prodotti Cloud.