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 próxima à localização da maioria dos usuários no momento da inscrição. A gente sabe que alguns clientes têm a necessidade de armazenar os dados em uma localidade específica e, para eles, a gente oferece a residência de dados. Hoje, oferecemos residência de dados nas regiões dos EUA e da UE, bem como na Austrália, com planos para adicionar outras regiões. Para receber mais informações e se inscrever para receber atualizações, visite a página de residência de dados.

Os dados do Bitbucket ficam localizados na região US-East, e a região US-West é usada para a recuperação de desastres.

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 especificamente 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.

No caso do Bitbucket, os dados são replicados para outra região AWS, e backups diários e independentes são realizados em cada região.

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 seus 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.

O Bitbucket usa o NetApp CVS para o armazenamento de arquivos de repositórios. O CVS é o sistema de arquivos gerenciado pela NetApp e hospedado a partir dos data centers da NetApp. A NetApp segue as exigências das leis de segurança de dados globais que exigem medidas de segurança suficientes para armazenar, transmitir e processar os dados. A NetApp também faz uso das autoavaliações e dos auditores terceirizados para assegurar que as exigências de conformidade sejam cumpridas. Para saber mais, consulte as Práticas de segurança da NetApp e certificações de conformidade.

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 inquilino são isolados e inacessíveis a outros inquilinos. É 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 características 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

Todos os dados de clientes armazenados em produtos de nuvem da Atlassian são criptografados em trânsito em redes públicas usando o TLS 1.2 ou versão posterior com o Perfect Forward Secrecy (PFS) como proteção contra divulgação ou modificação não autorizada. A implementação do TLS garante o uso de criptografia forte e chaves longas, se compatível com o navegador.

As unidades de dados nos servidores que contêm dados e anexos de clientes nos Jira Software Cloud, Jira Service Management Cloud, Jira Work Management, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello usam a criptografia em repouso de disco inteiro AES-256, padrão do setor.

As informações de identificação pessoal transmitidas por alguma rede de transmissão de dados estão sujeitas aos controles necessários projetados para garantir que os dados cheguem ao destino pretendido. A Política de Criptografia interna da Atlassian define os princípios gerais para a implementação da Atlassian de mecanismos de criptografia para mitigar os riscos envolvidos no armazenamento das informações de identificação pessoal e na sua transmissão por meio de redes. O tipo de algoritmo de criptografia usado para criptografar as informações de identificação pessoal deve levar em consideração o nível de classificação dessas informações de acordo com o Gerenciamento do ciclo de vida da informação e da segurança de dados da Atlassian. Para saber mais sobre como a gente coleta, compartilha e usa os dados de clientes, consulte a página sobre privacidade da Atlassian.

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

Gerenciamento de chaves

Na Atlassian, a gente usa o AWS Key Management Service (KMS) para o gerenciamento das chaves. Para assegurar ainda mais a privacidade dos seus dados, o KMS é responsável por originar e armazenar em sigilo essas chaves. A criptografia, a descriptografia e o processo de gerenciamento de chaves são inspecionados e autenticados pelo AWS com frequência, como parte dos processos internos de validação. Um proprietário é atribuído a cada chave e é responsável por garantir que o nível adequado de controles de segurança seja aplicado nas chaves. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego.

A gente também usa a criptografia de envelope. O AWS tem a chave mestre a que a gente nunca tem acesso, e qualquer solicitação de criptografia ou descriptografia de chave exige as funções e as permissões corretas do AWS. E, quando a gente usa a criptografia de envelope para criar ou gerar chaves para clientes individuais, a gente tem chaves de dados diferentes para diferentes tipos de dados por meio dos repositórios de dados. Além disso, a gente implementa uma abordagem de criptografia na camada interna do aplicativo que disponibiliza chaves de dados de backup em outras regiões do AWS. As chaves são alternadas todo ano e a mesma chave de dados não é usada para mais de 100.000 elementos de dados.

Em breve, a gente vai oferecer a criptografia BYOK (traga sua própria chave), permitindo que você criptografe os dados do produto de nuvem com chaves autogerenciadas no AWS KMS. Com o BYOK, você tem controle total sobre o gerenciamento das chaves e pode conceder ou revogar acesso a qualquer momento, tanto para seus próprios usuários finais quanto para os sistemas Atlassian.

O AWS KMS pode ser integrado ao AWS CloudTrail em sua conta da AWS para oferecer registros de toda a utilização de chaves. Essa solução permite a criptografia de seus dados em diferentes camadas em todos os aplicativos, como bancos de dados, armazenamento de arquivos, além de nos caches internos e enfileiramento de eventos. Durante todo o processo, não há impacto na usabilidade do produto.