Arquitetura e práticas operacionais do Atlassian Cloud

Arquitetura de hospedagem Atlassian Cloud

Usamos a Amazon Web Services (AWS) como provedora de serviços na nuvem e as instalações de data center de alta disponibilidade em várias regiões do mundo. Cada região da AWS é a localização geográfica separada com grupos de data centers múltiplos, isolados e separados fisicamente, conhecidos como zonas de disponibilidade (AZs).

A gente aproveita os serviços de computação, armazenamento, rede e dados da AWS para criar produtos e componentes de plataforma, o que permite que a gente utilize capacidades de redundância oferecidas pela AWS, como regiões e zonas de disponibilidade.

Zonas de disponibilidade

Cada zona de disponibilidade é projetada para estar isolada das falhas em outras zonas e para proporcionar conectividade de rede de baixo custo e baixa latência a outras AZs na mesma região. Essa alta disponibilidade de várias zonas é a primeira linha de defesa contra riscos geográficos e ambientais e significa que os serviços executados em implementações com várias AZs devem ter a capacidade de resistir às falhas de AZ.

O Jira e o Confluence usam o modo de implementação com várias AZs do Amazon RDS (Amazon Relational Database Service). Em implementações com várias AZs, o Amazon RDS provisiona e mantém uma réplica síncrona em espera em uma AZ diferente da mesma região para oferecer redundância e capacidade de tolerância a falhas. A tolerância a falhas da AZ é automatizada e costuma levar de 60 a 120 segundos e, portanto, as operações do banco de dados podem ser retomadas o mais rápido possível, sem intervenção administrativa. Opsgenie, Statuspage, Trello e Jira Align usam estratégias de implementação semelhantes, com pequenas variações no tempo de réplica e tolerância a falhas.

Localização dos dados

Os dados do Jira e do Confluence residem na região mais perto da localização da maioria dos usuários no momento da inscrição. Os dados do Bitbucket estão localizados em duas zonas de disponibilidade diferentes na região US-East.

No entanto, entendemos que alguns clientes podem exigir que os dados permaneçam em um local específico. É por isso que oferecemos diferentes opções de residência de dados. No momento, a residência de dados está disponível no Jira, Jira Service Management, Jira Product Discovery e Confluence em 11 regiões, incluindo EUA, União Europeia, Reino Unido, Austrália, Canadá, Alemanha, Índia, Japão, Cingapura, Coreia do Sul e Suíça. Leia nossa documentação para saber mais sobre a residência de dados e os dados relevantes do produto dentro do escopo. Além disso, siga nosso roteiro para ver as atualizações sobre a residência de dados, incluindo disponibilidade em novos produtos, regiões e tipos de dados.

Backups de dados

Na Atlassian, a gente opera um programa de backup abrangente. Ele inclui os sistemas internos, onde as medidas de backup são elaboradas de acordo com os requisitos de recuperação do sistema. Com relação aos produtos de nuvem da Atlassian e, em específico, a você e aos dados do seu aplicativo, a gente também tem amplas medidas de backup implementadas. A Atlassian utiliza a função de captura instantânea do Amazon RDS (Relational Database Service) para criar backups diários automatizados de cada instância do RDS.

Os instantâneos do Amazon RDS são mantidos por 30 dias com suporte para recuperação pontual e são criptografados usando a criptografia AES-256. Os dados de backup não são armazenados fora do local, mas são replicados para vários data centers dentro de uma região específica do AWS. A gente também faz testes trimestrais dos backups.

Para o Bitbucket, os instantâneos de armazenamento são retidos por 7 dias com suporte para recuperação pontual.

A gente não usa esses backups para reverter alterações destrutivas iniciadas pelos clientes, como a substituição de campos pelo uso de scripts ou a exclusão de itens, projetos ou sites. Para evitar a perda de dados, a gente recomenda que você faça backups frequentes. Saiba mais sobre como criar backups na documentação de suporte do produto que você usa.

Segurança de data center

O AWS tem várias certificações de proteção de data centers. Essas certificações abrangem a segurança física e ambiental, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problema. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões.

Arquitetura de serviços distribuídos

Com essa arquitetura da AWS, hospedamos vários serviços de plataforma e produto que são usados em nossas soluções. Entre eles estão capacidade de plataforma que são compartilhados e consumidos em vários produtos da Atlassian, como Mídia, Identidade e Comércio, assim como o Editor e capacidades específicas do produto, como o Jira Issue Service e o Confluence Analytics.

Arquitetura de vários locatários

Além da infraestrutura de nuvem da Atlassian, a gente criou e opera a arquitetura de microsserviço de vários locatários com plataforma compartilhada compatível com os produtos que a gente oferece. Na arquitetura de vários locatários, um único serviço atende a vários clientes, incluindo bancos de dados e instâncias de computação necessários para executar os produtos da nuvem. Cada fragmento (sobretudo um contêiner — veja a figura 3 abaixo) contém os dados de vários locatários, mas os dados de cada um deles são isolados e inacessíveis aos demais. É importante observar que a gente não oferece arquitetura de locatário único.

Provisionamento de locatário e ciclo de vida

Quando um novo cliente é provisionado, uma série de eventos aciona a orquestração de serviços distribuídos e o provisionamento de armazenamentos de dados. Esses eventos em geral podem ser mapeados para uma das sete etapas do ciclo de vida:

1. Os sistemas de comércio são atualizados de imediato com as informações de controle de acesso e os metadados mais recentes desse cliente; depois, o sistema de orquestração de provisionamento alinha o “estado dos recursos provisionados” com o estado da licença por meio da série de eventos de locatário e produto.

Eventos de locatário

Esses eventos afetam o locatário como um todo e podem ser:

• Criação: um locatário é criado e usado para novos sites
• Destruição: o locatário inteiro é excluído

Eventos de produtos

• Ativação: após a ativação de produtos licenciados ou aplicativos de terceiros
• Desativação: após a desativação de determinados produtos ou aplicativos
• Suspensão: após a suspensão de determinado produto existente, desativando assim o acesso a um determinado site próprio
• Cancelamento da suspensão: após o cancelamento da suspensão de determinado produto existente, permitindo assim o acesso ao site próprio
• Atualização de licença: contém informações sobre o número de licenças para determinado produto, bem como o status (ativo/inativo)

2. Criação do site do cliente e ativação do conjunto correto de produtos para o cliente. O conceito do site é o contêiner de vários produtos licenciados para determinado cliente. (por exemplo: Confluence e Jira Software para ＜ nome do site ＞.atlassian.net).

Separação de locatário

Embora os clientes compartilhem uma infraestrutura comum baseada em nuvem ao usar os produtos de nuvem, a gente implementou medidas para garantir que fiquem separados com lógica para que as ações de um cliente não comprometam os dados ou serviços de outros.

O método da Atlassian para alcançar esse objetivo varia de acordo com os aplicativos. No caso do Jira e Confluence Cloud, a gente usa o conceito de "contexto de locatário" para alcançar o isolamento lógico dos clientes. Ele é implementado no código do aplicativo e gerenciado por algo que a gente desenvolveu, chamado de "serviço de contexto de locatário" (TCS, na sigla em inglês). Esse conceito garante que:

• Os dados de cada cliente sejam mantidos em locais separados de outros locatários quando estiverem em repouso
• Todas as solicitações processadas pelo Jira ou pelo Confluence têm uma visualização "específica ao locatário" para que outros locatários não sejam impactados

Em outras palavras, o TCS armazena um "contexto" para locatários de clientes individuais. O contexto para cada locatário é associado a um ID exclusivo armazenado pelo TCS em caráter central e conta com uma gama de metadados associados a esse locatário (por exemplo, em quais bancos de dados o locatário está, quais licenças o locatário tem, quais recursos ele pode acessar e diversas outras informações de configuração). Quando um cliente acessa o Jira ou o Confluence Cloud, o TCS usa o ID de locatário para reunir esses metadados, que, depois, são vinculados a operações que o locatário fez no aplicativo durante a sessão dele.

Bordas da Atlassian

Seus dados também são protegidos por meio de algo que a gente chama de borda — paredes virtuais erguidas ao redor dos softwares da Atlassian. Quando as solicitações chegam, elas são enviadas para a borda mais próxima. Por meio de diversas validações, as solicitações são permitidas ou negadas.

• Elas chegam na borda da Atlassian mais próxima do usuário. A borda verifica a sessão e a identidade do usuário por meio do sistema de identidade usado.
• Ela determina o local dos dados do produto, com base nos dados provenientes das informações do TCS.
• A borda encaminha a solicitação para a região de destino, onde chega a algum ponto central de computação.
• O ponto central usa o sistema de configuração de locatários para determinar algumas informações, como a licença e o local do banco de dados, e requisita vários outros armazenamentos de dados e serviços (por exemplo, a plataforma de mídia que hospeda imagens e anexos) para recuperar as informações necessárias ao atendimento da solicitação.
• A solicitação original do usuário com informações coletadas de suas requisições anteriores para outros serviços.

Autenticação e autorização de serviço

A plataforma da Atlassian usa o modelo de privilégio mínimo para o acesso dos dados. Esse modelo deixa todos os dados restritos apenas ao serviço responsável por seu salvamento, processamento ou recuperação. Por exemplo, os serviços de mídia, que possibilitam ter experiências consistentes de download e upload de arquivos nos produtos de nuvem da Atlassian, têm provisão de armazenamento dedicado que nenhum outro serviço da Atlassian consegue acessar. Qualquer serviço que exija acesso ao conteúdo de mídia precisa interagir com a API de serviços de mídia. Ou seja, o processo robusto de autenticação e de autorização na camada de serviço também aplica forte separação de deveres e o menor privilégio de acesso aos dados.

A gente usa tokens web JSON (JWTs) para garantir a autoridade da assinatura fora do aplicativo, para que os sistemas de identidade e o contexto de locatário da Atlassian sejam a fonte de informações. Os tokens não podem ser usados para nada além do que estão autorizados. Quando você ou alguém da equipe faz alguma requisição a microsserviços ou fragmentos, os tokens são enviados ao seu sistema de identidade para serem validados por ele. Esse processo garante que o token esteja atualizado e assinado antes de compartilhar os dados necessários. Nos casos em que esse processo é combinado com a autorização e com a autenticação necessárias para acessar esses microsserviços, se algum serviço for comprometido, seu escopo vai ser limitado.

No entanto, a gente sabe que às vezes os sistemas de identidade podem ser comprometidos. Para mitigar esse risco, a gente usa dois mecanismos. Primeiro, o TCS e os proxies de identidade são bastante replicados. A gente usa uma réplica do TCS para quase todos os microsserviços, além de réplicas do proxy que se desdobram para a autoridade de identidade. Portanto, existem milhares desses serviços em execução o tempo todo. Se ocorrer algum comportamento anômalo em um ou mais deles, a detecção é rápida para encaminhar a solução.

Além disso, a gente não espera que alguém encontre alguma vulnerabilidade nos produtos ou na plataforma da Atlassian. A gente trabalha na identificação ativa dessas situações para que o impacto para você seja mínimo. A gente também executa vários programas de segurança para identificar, detectar e responder a ameaças de segurança.

Serviço de contexto de locatário

A Atlassian assegura que as solicitações para todos os microsserviços contenham metadados sobre o cliente - ou sobre o locatário - que está solicitando o acesso. Essa prática é chamada de serviço de contexto de locatário. O preenchimento automático desse contexto é feito com base nas informações dos sistemas de provisionamento da Atlassian. Quando alguma solicitação é iniciada, o contexto é lido e internalizado no código do serviço em execução, que é usado para autorizar o usuário. Todo o acesso ao serviço e, portanto, aos dados no Jira e no Confluence exige esse contexto de locatário — caso contrário, a solicitação é rejeitada.

A autenticação e a autorização do serviço são aplicadas por meio do protocolo de autenticação de serviço da Atlassian (ASAP). Uma lista de permissões explícita determina quais serviços podem se comunicar, e as informações da autorização especificam quais comandos e caminhos estão disponíveis. Assim, a gente limita o possível movimento lateral de algum serviço comprometido.

A autenticação e autorização de serviço, assim como a saída, são controladas por um conjunto de proxies dedicados. Dessa maneira, as vulnerabilidades do código do aplicativo perdem a capacidade de afetar esses controles. A execução remota de código exigiria comprometer o host subjacente e ignorar os limites do contêiner do Docker — não apenas a capacidade de modificar a lógica do aplicativo. Em vez disso, a detecção de intrusão no nível do host sinaliza discrepâncias.

Esses proxies restringem o comportamento de saída com base no comportamento pretendido do serviço. Serviços que não precisam emitir webhooks nem se comunicar com outros microsserviços que não têm permissão para essas atividades.

Criptografia de dados

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.

Para ficar atualizado sobre os recursos adicionais de criptografia de dados, consulte o roteiro da nuvem.