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. Tuttavia, sappiamo che alcuni utenti potrebbero richiedere che i propri dati rimangano in una posizione specifica, quindi offriamo il servizio di residenza dei dati. Attualmente, offriamo la residenza dei dati nelle regioni degli Stati Uniti e dell'UE, oltre che in Australia, e prevediamo di aggiungere altre regioni. Per informazioni e per ricevere aggiornamenti, consulta la nostra pagina sulla residenza dei dati.

I dati per Bitbucket si trovano in due diverse zone di disponibilità nella regione degli Stati Uniti orientali.

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

I dati dei clienti archiviati nei prodotti Atlassian Cloud sono crittografati mentre sono in transito su reti pubbliche utilizzando il protocollo 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à dati sui server che conservano i dati e gli allegati dei clienti in Jira Cloud, Jira Service Management Cloud, Bitbucket Cloud, Confluence Cloud, Jira Product Discovery, Statuspage, Opsgenie e Trello applicano la crittografia full-disk AES-256 standard di settore dei dati a riposo.

Le informazioni personali trasmesse utilizzando una rete di trasmissione dati sono soggette a controlli appropriati volti a garantire che i dati raggiungano la destinazione prevista. La policy di crittografia interna di Atlassian definisce i principi generali per l'implementazione di meccanismi di crittografia di Atlassian per mitigare i rischi connessi all'archiviazione delle informazioni personali e alla loro trasmissione su reti. Il tipo di algoritmo di crittografia utilizzato per crittografare le informazioni personali deve tenere conto del livello di classificazione delle informazioni personali in conformità alla gestione interna del ciclo di vita delle informazioni e della sicurezza dei dati di Atlassian. Per ulteriori informazioni su come raccogliamo, condividiamo e utilizziamo i dati dei clienti, consulta la nostra pagina sulla privacy.

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

Gestione delle chiavi

Atlassian utilizza AWS Key Management Service (KMS) per la gestione delle chiavi. Per garantire un ulteriore livello di privacy dei dati, KMS è l'iniziatore e l'archivio segreto di tali 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. Le chiavi gestite da Atlassian vengono utilizzate a rotazione in base alle modifiche pertinenti dei ruoli o allo stato del rapporto di lavoro.

Utilizziamo, inoltre, la crittografia della busta. AWS ha la chiave master che non possiamo mai vedere e qualsiasi richiesta di crittografia o decrittografia delle chiavi richiede i ruoli e le autorizzazioni AWS corretti. Inoltre, quando utilizziamo la crittografia della busta per creare o generare chiavi per singoli clienti, disponiamo di chiavi dati diverse per diversi tipi di dati attraverso i nostri archivi di dati. Applichiamo anche un approccio di crittografia al livello di applicazione interno che fornisce chiavi di dati di backup in altre regioni AWS. Le chiavi vengono sottoposte a rotazione automaticamente ogni anno e la stessa chiave di dati non viene utilizzata per più di 100.000 elementi di dati.

Presto offriremo la crittografia Bring Your Own Key (BYOK), che consentirà di crittografare i dati dei prodotti Cloud con chiavi autogestite in AWS KMS. Con BYOK, disporrai del controllo completo sulla gestione delle chiavi e potrai concedere o revocare l'accesso in qualsiasi momento, sia per i tuoi utenti finali che per i sistemi Atlassian.

AWS KMS può essere integrato con AWS CloudTrail nel tuo account AWS per fornirti i log di tutti gli utilizzi delle chiavi. Questa soluzione consente la crittografia dei dati a diversi livelli in tutte le applicazioni, come database, archiviazione di file, nonché le nostre cache interne e l'accodamento degli eventi. Durante l'intero processo, non sarà presente alcun impatto sull'usabilità del prodotto.