Close
Quer visualizar esta página no seu idioma?
Todos os idiomas
Escolha seu idioma
Atlassian Cloud

Arquitetura e práticas operacionais do Atlassian Cloud

Saiba mais sobre a arquitetura do Atlassian Cloud e as práticas operacionais que a gente segue

Sumário

Introdução

Atlassian cloud apps and data are hosted on industry-leading cloud provider Amazon Web Services (AWS). Our products run on a platform as a service (PaaS) environment that is split into two main sets of infrastructure that we refer to as Micros and non-Micros. Jira, Confluence, Jira Product Discovery, Statuspage, Guard, and Bitbucket run on the Micros platform, while Opsgenie and Trello run on the non-Micros platform.

Infraestrutura na nuvem

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

We operate a comprehensive backup program at Atlassian. This includes our internal systems, where our backup measures are designed in line with system recovery requirements. With respect to our cloud apps, and specifically referring to you and your application data, we also have extensive backup measures in place. We use the snapshot feature of Amazon RDS (Relational database service) to create automated daily backups of each RDS instance.

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.

We don’t use these backups to revert customer-initiated destructive changes, such as fields overwritten using scripts, or deleted work items, projects, or sites. To avoid data loss, we recommend making regular backups. Learn more about creating backups in the support documentation for your product.

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 plataforma em nuvem

Arquitetura de serviços distribuídos

With this AWS architecture, we host a number of platform and product services that are used across our solutions. This includes platform capabilities that are shared and consumed across multiple Atlassian products, such as Media, Identity, and Commerce, experiences such as our Editor, and product-specific capabilities, like Jira Work Item service and Confluence Analytics.

Arquitetura da plataforma Atlassian

Figura 1

Os desenvolvedores da Atlassian fornecem esses serviços por meio do Kubernetes ou de uma plataforma como serviço (PaaS) desenvolvida a nível interno chamada Micros. Ambos fazem a orquestração automática da implantação de serviços compartilhados, infraestrutura, repositórios de dados e recursos de gerenciamento, incluindo requisitos de controle de conformidade e segurança (consulte a figura 1 acima). Em geral, um produto da Atlassian consiste em vários serviços “conteinerizados”, que são implantados na AWS usando o Micros ou Kubernetes. Os produtos da Atlassian usam os principais recursos da plataforma (veja a figura 2 abaixo), que variam do roteamento de solicitações a repositórios de objetos binários, autenticação/autorização, conteúdo transacional gerado pelo usuário (UGC) e armazenamento de relações de entidades, data lakes, registro comum, rastreamento de solicitações, observabilidade e serviços de análise. Esses microsserviços são criados usando pilhas técnicas aprovadas e padronizadas no nível da plataforma:

Visão geral dos microsserviços da Atlassian

Figura 2

Arquitetura de vários locatários

On top of our cloud infrastructure, we built and operate a multi-tenant micro-service architecture along with a shared platform that supports our products. In a multi-tenant architecture, a single service serves multiple customers, including databases and compute instances required to run our cloud apps. Each shard (essentially a container – see figure 3 below) contains the data for multiple tenants, but each tenant's data is isolated and inaccessible to other tenants. It is important to note that we do not offer a single tenant architecture.

Como a gente armazena dados na arquitetura de vários locatários

Figura 3

Os microsserviços da Atlassian implementam o mínimo de privilégio possível e são projetados para reduzir o escopo de qualquer exploração de dia zero e minimizar a probabilidade de movimento lateral no ambiente de nuvem que a gente oferece. Cada microsserviço tem o próprio armazenamento de dados que pode ser acessado apenas com o protocolo de autenticação para esse serviço específico, ou seja, nenhum outro serviço tem acesso de leitura ou de gravação a essa API.

A gente se concentrou no isolamento dos microsserviços e dos dados, em vez de oferecer uma infraestrutura dedicada por locatário, pois esse isolamento restringe o acesso ao âmbito limitado dos dados de um único sistema. A dissociação da lógica e a autenticação e autorização de dados ocorrem na camada do aplicativo, de modo a atuar como verificação de segurança adicional conforme as solicitações são enviadas para esses serviços. Assim, apenas o acesso aos dados exigidos por algum serviço específico var ficar limitado, caso algum microsserviço seja comprometido.

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

Visão geral do contêiner do site

Figura 4

3. Provisionamento de produtos no site do cliente na região designada.

Quando o produto é provisionado, ele vai ter a maior parte do conteúdo hospedado perto de onde os usuários o acessam. Para otimizar o desempenho do produto, a gente não limita a movimentação de dados quando eles são hospedados em todo o mundo e podem mover dados entre regiões conforme necessário.

Para alguns produtos da Atlassian, a gente também oferece residência de dados. A residência de dados permite que os clientes escolham se os dados do produto são distribuídos em todo o mundo ou mantidos no local em uma das localizações geográficas definidas que a gente oferece.

4. Criação e armazenamento dos principais metadados e configurações do(s) produto(s) e do site do cliente.

5. Criação e armazenamento dos dados de identidade do site e do(s) produto(s), como usuários, grupos, permissões etc.

6. Provisionamento de bancos de dados de produtos no site, por exemplo: família de produtos Jira, Confluence, Compass, Atlas.

7. Provisionamento dos aplicativos licenciados do(s) produto(s).

Visão geral de como o site do cliente é provisionado na arquitetura distribuída da Atlassian

Figura 5

A Figura 5 acima demonstra como o site do cliente é implantado na arquitetura distribuída, não apenas em um único banco de dados ou loja. Essa ação inclui vários locais físicos e lógicos que armazenam metadados, dados de configuração, dados do produto, dados da plataforma e outras informações relacionadas ao site.

Separação de locatário

While our customers share a common cloud-based infrastructure when using our cloud apps, we have measures in place to ensure they are logically separated so that the actions of one customer cannot compromise the data or service of other customers.

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.

Controles de segurança

Because our cloud apps leverage a multi-tenant architecture, we can layer additional security controls into the decoupled application logic. A per-tenant monolithic application wouldn’t typically introduce further authorization checks or rate limiting, for example, on a high volume of queries or exports. The impact of a single zero-day is dramatically reduced as the scope of services are narrowed.

Além disso, controles preventivos adicionais foram implementados nos produtos que a gente oferece e que são hospedados em sua totalidade na plataforma Atlassian. Os principais controles preventivos são:

  • Autenticação e autorização de serviço
  • Serviço de contexto de locatário
  • Gerenciamento de chaves
  • Criptografia de dados

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

Our platform uses a least privilege model for accessing data. This means that all data is restricted to only the service responsible for saving, processing, or retrieving it. For example, the media services, which allows you to have a consistent file upload and download experience across our cloud apps, have dedicated storage provisioned that no other services at Atlassian can access. Any service that requires access to the media content needs to interact with the media services API. As a result, strong authentication and authorization at the service layer also enforces strong separation of duties and least privilege access to data.

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

Os dados do cliente, incluindo anexos, armazenados nos serviços de nuvem, como Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello, são protegidos usando criptografia AES-256 padrão do setor em repouso.

A transmissão de informações de identificação pessoal (PII) é protegida por meio de criptografia e controles robustos de acesso a dados, projetados para garantir que os dados sejam transmitidos com segurança ao destino pretendido. A Política de Criptografia e Codificação da Atlassian descreve os princípios para implementar criptografia e codificação para mitigar os riscos relacionados ao armazenamento e à transmissão de PII. Os algoritmos de criptografia para proteger PII estão alinhados com o nível de classificação de PII, conforme especificado pelas políticas internas de gestão de ciclo de vida de informações e segurança de dados da Atlassian. Essa medida garante que os dados sigilosos sejam protegidos com base na classificação. Para saber mais sobre como a gente coleta, compartilha e usa os dados de clientes, consulte a página da Atlassian sobre privacidade.

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

Gerenciamento de chaves criptográficas

O Atlassian Cloud usa o AWS Key Management Service (KMS) para gerenciar as chaves criptográficas aplicadas à criptografia e descriptografia de dados. Por padrão, essas chaves KMS têm o respaldo de materiais de chave protegidos em módulos de segurança de hardware (HSMs) que são validados pelo Programa de Validação de Módulos Criptográficos do NIST. Graças à abordagem de segurança por padrão do AWS KMS com HSMs validados pelo FIPS, é possível implementar proteção reforçada no gerenciamento de chaves. Isso evita que os funcionários da AWS e da Atlassian recuperem materiais de chave em texto simples no KMS e nos HSMs.

A criptografia de envelope é aplicada aos dados em trânsito e em repouso. As chaves de dados são criadas de acordo com cada serviço, e apenas os serviços autorizados podem fazer a criptografia e descriptografia no modo de negação implícita. Em seguida, as chaves de dados são encapsuladas (criptografadas pelos recursos correspondentes da CMK do KMS) para fins de proteção.

A criptografia no nível do disco ou volume é implementada conforme necessário, em especial nos recursos como bancos de dados e repositórios de objetos administrados por meio de serviços gerenciados pela AWS. As chaves usadas nessa criptografia são provisionadas e protegidas pelas mesmas fontes do HSM.

Tanto as chaves KMS como as de dados são alternadas com frequência para diminuir possíveis superfícies de ataque. Quando uma chave KMS é alternada para uma nova versão, as chaves de dados que foram criptografadas usando as versões antigas ou anteriores das chaves KMS só podem ser descriptografadas por essas chaves antigas. Por outro lado, todas as novas chaves de dados criadas após a alternância da chave KMS são criptografadas e descriptografadas por meio da nova versão ativa da chave KMS. O gerenciamento da alternância de chaves de dados é regido por limites de uso, que podem ser especificados em termos de total de operações ou tempo de vida (TTL) máximo. Por exemplo, uma chave de dados pode ser alternada após atingir cinco milhões de operações ou depois de 24 horas (o que ocorrer primeiro). Os caches de chave segura e KMSs multirregionais são implementados para fornecer alta disponibilidade e o nível de desempenho esperado.

Para ver mais detalhes, visite este blog.

Customer-managed keys (CMK)

To give you greater control over the encryption of your Atlassian app data, we are gradually rolling out Customer-managed keys (CMK), our most advanced encryption offering, to eligible customers. CMK is an encryption key model that allows you to create and manage cryptographic keys in your own AWS KMS account, so that you can encrypt and decrypt app data at rest in the Atlassian cloud. It provides additional visibility and control over encryption key management without introducing performance overhead or negatively impacting user experience. This is due to the efficient, secure caching mechanism employed by Atlassian systems. Learn more about CMK here.