Close

Práticas de segurança

A gente acredita que todas as equipes têm o potencial para fazer coisas incríveis. A nossa missão é estimular o potencial de todas as equipes, de qualquer tamanho ou setor, e contribuir com o progresso da humanidade por meio do poder do software. 

Sabemos que sua missão é tão importante para você quanto a nossa é para a gente, e as informações estão no centro de todos os negócios e vidas. É por isso que a confiança do cliente é a base do que a gente faz e a segurança é a nossa principal prioridade. O nosso programa de segurança é transparente para que você tenha todas as informações necessárias e se sinta seguro para usar os produtos e serviços da Atlassian.

Leia mais a respeito da abordagem da Atlassian sobre segurança e saiba como os clientes podem fazer a parte deles.

As informações nesta página se aplicam aos produtos Atlassian Cloud, Jira, Confluence e Bitbucket, a menos que indicado em contrário.

O que a gente faz

O Atlassian Trust Management System (ATMS) leva cada um dos requisitos de segurança dos clientes em consideração e cria um conjunto de exigências e iniciativas exclusivas da Atlassian e do ambiente em que trabalhamos. Veja mais informações sobre as iniciativas no site Atlassian Trust, em que você pode baixar ou solicitar os relatórios de certificação ISO 27001 e SOC2 e analisar o questionário CSA STAR, além de informações sobre o Atlassian Trust Management System (ATMS).

Segurança integrada

Aqui, a segurança não é um destino a ser alcançado, mas um processo contínuo, sempre em busca de aprimorar o desenvolvimento de software e os processos operacionais internos para aumentar a segurança dos programas e serviços. O jeito seguro deve ser o jeito fácil, e é por isso que a segurança é integrada ao DNA dos nossos produtos e infraestrutura. Veja como a segurança é integrada ao modo como a gente trabalha todos os dias.

Arquitetura

A segurança é primordial no desenvolvimento dos nossos aplicativos, redes e processos corporativos

A arquitetura de segurança do Atlassian Cloud foi projetada levando em conta uma grande variedade de normas e estruturas do setor e em conjunto com os processos internos de modelo de ameaças. Ela foi desenvolvida para equilibrar as necessidades de flexibilidade e controles eficazes para garantir confidencialidade, integridade e disponibilidade dos dados dos clientes. 

Aplicativos

Segurança de desenvolvimento de aplicativos e gerenciamento do ciclo de vida da informação.

Segurança

Cripto e criptografia, gerenciamento de ameaças e vulnerabilidades, gerenciamento de incidentes de segurança

Infraestrutura

Gerenciamento de ativos, controle de acesso, operações, segurança de comunicações

Data Center e escritórios

Segurança física e ambiental

Corporate

Governança de segurança, organização da segurança, segurança dos funcionários, gerenciamento de dados de terceiros e de fornecedores, segurança de dispositivos móveis, continuidade de negócios, auditoria/conformidade, privacidade.

Os controles de segurança que informam a arquitetura foram projetados para atender a uma série de normas diferentes e, por conta das várias das sobreposições entre elas, a gente criou nossa própria estrutura de controles. Ela oferece uma lista única de itens a priorizar e mapeia as diversas normas que a Atlassian segue, como mostrado abaixo na Tabela 1.

Standard Patrocínio Controles Domínios

ISO 27001

Organização Internacional de Normalização

26 requisitos

6 cláusulas

ISO27002

Organização Internacional de Normalização

114 requisitos

14 domínios

PCI-DSS

Indústrias de cartão de pagamento

247 requisitos

6 domínios

CSA CCM

Cloud Security Alliance

133 controles

16 domínios

SOC2

Controles de organização de serviço

116 requisitos

5 princípios

SOX 404 (IT)

Lei Federal dos EUA

22 requisitos

5 domínios

GAPP

AICPA

106 requisitos

10 domínios

Se quiser saber mais, leia mais sobre a nossa Estrutura de controles comuns.

 

rede

Praticamos uma abordagem em camadas para acesso à rede, com controles em cada camada da pilha

Implementamos controles em cada camada da pilha, dividindo a infraestrutura por zonas, ambientes e serviços.

As restrições por zona incluem a limitação do tráfego de rede do escritório, do data center e da plataforma. A separação por ambiente limita a conectividade de produção e desenvolvimento. Os serviços precisam ter autorização explícita para se comunicar a outros serviços por uma lista de permissões de autenticação.

O acesso a redes confidenciais é controlado com o roteamento de nuvem privada virtual (VPC), regras de firewall e rede definida por software. Toda a conectividade é criptografa por padrão.

A conectividade de funcionários requer certificados de dispositivos, autenticação multifatorial e uso de proxies para acesso à rede sigilosa. O acesso aos dados do cliente precisa de análise e aprovação explícitas.

Também são implementados sistemas de prevenção e detecção de invasão nas redes do escritório e de produção para identificar possíveis problemas de segurança.

Aplicação

É usada modelagem de ameaças para garantir o desenvolvimento dos controles certos para as ameaças que enfrentamos

Durante o planejamento e design do produto, a gente usa o modelo de ameaças para entender os riscos específicos de segurança associados a um produto ou recurso. Em geral, o modelo de ameaças é uma troca de ideias entre engenheiros, engenheiros de segurança, arquitetos e gerentes de produtos de um aplicativo ou serviço. As ameaças são identificadas e priorizadas, e essas informações alimentam os controles no processo de design e contam com testes e análises direcionadas nas fases posteriores de desenvolvimento.

Usamos a Ferramenta de Modelagem de Ameaças da Microsoft e a estrutura de modelo de ameaças STRIDE. STRIDE é a sigla em inglês para um conjunto comum de questões de segurança: engano, adulteração, reputação, divulgação de informações, recusa de serviço e aumento de privilégios.

Usamos a modelagem de ameaças no início e consegue, com frequência, garantir que a configuração e os controles de segurança relevantes sejam projetados para reduzir as ameaças específicas de cada produto ou recurso desenvolvido. 

Confiabilidade

A importância dos produtos varia de cliente para cliente – mas a gente sabe, depois de conversar com eles, que produtos como o Jira e o Confluence, no geral, acabam fazendo parte de processos corporativos fundamentais. Aqui na Atlassian, a gente usa nossos próprios produtos, por isso é fácil entender a importância da confiabilidade e recuperabilidade.

Confiabilidade e redundância em toda a plataforma

Operamos vários data centers em lugares diversos

A hospedagem dos aplicativos da nuvem é feita com parceiros de hospedagem na nuvem, AWS e NTT. Esses data centers foram projetados e otimizados para hospedar aplicativos, ter vários níveis de redundância integrada e executar em nó de hardware de front-end separado em que os dados do aplicativo são armazenados.

A alta disponibilidade dos dados e serviços é importante para a Atlassian. Assim, nos concentramos na resiliência dos produtos por meio de normas e práticas que reduzem o tempo de inatividade. As práticas de resiliência foram feitas com base no SOC2, na ISO 27002 e na ISO 22301.

Jira, Confluence, Statuspage, Trello, Opsgenie e Jira Align são hospedados com o provedor de hospedagem na nuvem líder do setor, o Amazon Web Services (AWS), que oferece desempenho ideal com redundância e opções de failover no geral. Mantemos várias regiões e zonas de disponibilidade de leste a oeste dos EUA, da União Europeia e da região Ásia-Pacífico.

Nosso parceiro de hospedagem de Bitbucket Data Center é o NTT, que tem as certificações SOC2 e ISO27001 de segurança e disponibilidade. Ele também oferece garantia suficiente de que aspectos, como a segurança física, o acesso à rede e IP backbone, provisionamento de clientes e gerenciamento de problemas, são controlados no nível que exigimos e necessitamos.

Para ver mais informações sobre como usamos vários data centers e zonas de disponibilidade para alta disponibilidade, consulte as páginas Gerenciamento de dados do cliente e Infraestrutura de hospedagem na nuvem.

Backups

Temos um programa abrangente de backup

Os dados do aplicativo são guardados em armazenamento resiliente, que é replicado em data centers. Além da resiliência em toda a plataforma, temos também um programa abrangente de backup para ofertas do Atlassian Cloud. No entanto, a restauração e a recuperação desses backups só são disponibilizadas na plataforma do Atlassian Cloud. 

Os backups do banco de dados do aplicativo do Atlassian Cloud são feitos nas seguintes frequências: backups diários automatizados são feitos e retidos por 30 dias com suporte para recuperação de ponto no tempo. Todos os dados de instância e backup são criptografados. 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. Fazemos testes trimestrais dos backups. Para mais informações, consulte nossa página de infraestrutura. Para saber mais como implementamos um programa eficaz de backup, veja a página Gerenciamento de dados do cliente.

Continuidade de negócios e recuperação de desastres

Temos planos de continuidade de negócios e recuperação de desastres abrangentes e comprovados

A meta é não ferrar os clientes e trabalhar para manter recursos eficazes de continuidade de negócios (BC) e recuperação de desastres (DR) para garantir que o impacto nos clientes seja minimizado caso haja interrupções das operações.

O programa de recuperação de desastres consiste em algumas práticas chave para garantir os níveis adequados de governança, supervisão e teste:

  1. Governança. O envolvimento da liderança é fundamental na forma como conduzimos o programa de recuperação de desastres.  Com a liderança envolvida, temos os fatores técnicos e comerciais participando da estratégia de resiliência.
  2. Supervisão e manutenção. A gente tem uma abordagem disciplinada de governança, risco e conformidade para monitorar e gerenciar o programa de recuperação de desastres. Ela nos permite operar com mais eficiência e eficácia ao monitorar, medir, gerar relatórios e solucionar atividades chave dentro do programa de recuperação de desastres. Os engenheiros de confiabilidade do site estão comprometidos em reuniões contínuas de recuperação de desastres e representam seus serviços críticos. Eles discutem lacunas de recuperação de desastres identificadas com a equipe de risco e conformidade, e se concentram nos níveis adequados de correção conforme necessário.
  3. Testes. A gente realiza testes regulares e busca sempre a melhoria contínua como parte do ciclo de vida de DR para garantir que seus dados e o uso deles tenha alta disponibilidade e bom desempenho.
    1. Com os testes dos níveis de resiliência por todas as zonas de disponibilidade AWS podemos lidar com uma falha na zona de disponibilidade com tempo de inatividade mínimo.
    2. Levamos os backups de dados por todos os data centers regionais AWS. Se uma região cair, protegemos seus dados em uma região secundária no caso de um incidente catastrófico. 
    3. Testamos as falhas regionais AWS. Entendemos que uma falha regional completa é muito improvável. Entretanto, continuamos a testar nossa capacidade de falhar nos serviços e continuamos a amadurecer nossa resiliência regional.
    4. Os procedimentos de backup e restauração são instalados e testados com frequência. Isso significa que, quando os dados precisam ser restaurados, a gente está com tudo pronto para atender você com uma equipe de suporte bem treinada e procedimentos comprovados.

Além da garantia de resiliência pela governança, supervisão e pelos testes, a Atlassian enfatiza a melhoria contínua pelo programa DR. Para saber sobre os testes de recuperação de desastres e o programa de continuidade de negócios, consulte a página Gerenciamento de dados do cliente.

O status de disponibilidade dos serviços é publicado em tempo real para garantir que você possa acessar seus dados quando quiser. 

Segurança de produtos

Um dos problemas do setor é lançar produtos seguros e manter uma velocidade saudável de comercialização. O objetivo é alcançar o equilíbrio perfeito entre velocidade e segurança, até porque a gente roda quase tudo no nosso próprio software. Há uma gama de controles de segurança que a gente implementa para proteger nossos produtos e seus dados.

Criptografia e gerenciamento de chaves

Criptografia em trânsito

Todos os dados de clientes armazenados em produtos e serviços de nuvem da Atlassian são criptografados em trânsito em redes públicas usando o Transport Layer Security (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.

Criptografia em repouso

As unidades de dados nos servidores que contêm dados e anexos de clientes no Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello utilizam a criptografia em repouso de disco completo AES-256, padrão do setor. No momento, o Bitbucket não oferece criptografia em repouso para repositórios.

Na criptografia em repouso, a Atlassian criptografa os dados do cliente, armazenados em um disco como os dados do item do Jira (informações, comentários e anexos) ou dados da página do Confluence (conteúdo da página, comentários e anexos). A criptografia em repouso ajuda a proteger contra acesso não autorizado e garante que os dados só possam ser acessados por funções e serviços autorizados com acesso monitorado por chaves de criptografia.

Gerenciamento de chaves de criptografia

A Atlassian usa o AWS Key Management Service (KMS) para gerenciar 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.

Isolamento do locatário

Embora os clientes compartilhem uma infraestrutura de TI comum, o isolamento de locatário garante que fiquem logicamente segregados para que as ações de um locatário não comprometam os dados ou serviços de outro.

Na Atlassian, o método de isolamento de locatário depende dos aplicativos. Vamos compartilhar essas diferenças aos poucos. Para o Jira e Confluence Cloud, que evoluíram nos últimos anos e se tornaram aplicativos completos de SaaS de múltiplos locatários, a Atlassian usa um conceito que chamamos "Contexto de locatário", implementado no código do aplicativo e gerenciado por algo que desenvolvemos e chamamos "Serviço de contexto de locatário" (TCS, na sigla em inglês). Esse conceito garante que neste ambiente compartilhado:

  • Os dados de cada cliente sejam mantidos em locais separados de outros locatários quando estiverem em repouso; e
  • Qualquer solicitação que seja processada pelo Jira ou Confluence tenham uma visualização "específica ao locatário" para que outros locatários não sejam impactados.

O TCS é independente do Jira e do Confluence, mas é fundamental para a operação deles. Em outras palavras, o TCS armazena um "contexto" para locatários de clientes individuais. Esse contexto 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 eles podem acessar e uma variedade de outras informações de configuração) e senhas criptografadas e exclusivas. O contexto de cada locatário é associado a um ID exclusivo, armazenado em uma central pelo TCS.

Quando um cliente acessa o Jira ou 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. Mais importante ainda, o contexto dado pelo TCS age muito bem como uma "lente" pela qual as interações com os dados do cliente ocorrem. Essa lente sempre vai estar limitada a um locatário específico. Isso garante que o locatário de cliente não acesse os dados de outros nem que as ações dele afetem o serviço de outro locatário.

Leia mais sobre a arquitetura do Atlassian Cloud.

Testes de segurança dos produtos

Temos programas de teste de segurança internos e externos com recompensas por bugs

A abordagem de gerenciamento de vulnerabilidade dos produtos conta com testes de segurança internos e externos. Os itens conhecidos são disponibilizados pelo rastreador de bugs público.

Teste interno

Essa abordagem abrange planejamento, desenvolvimento e teste. Cada teste usa o trabalho feito e vai, aos poucos, ficando mais complexo. Temos uma abordagem estabelecida de análise de código estático e dinâmico nas fases de desenvolvimento e teste. Na fase de desenvolvimento, nos concentramos na incorporação do código, buscando remover itens de segurança funcional e não funcional que possam ser identificados com precisão.

Na fase de teste, a equipe de desenvolvimento e engenharia de segurança mudam para uma abordagem controversa para tentar quebrar os recursos usando técnicas de teste manuais e automatizadas.

A equipe de segurança desenvolve uma ampla gama de ferramentas de teste de segurança para automatizar tarefas comuns e disponibilizar ferramentas de teste especializadas para as equipes de produtos. Essas ferramentas são vantajosas para a equipe de segurança e, com elas, os desenvolvedores fazem varreduras de segurança por conta própria, tomando as rédeas do resultado. A equipe de engenharia de segurança é formada por especialistas no assunto, mas, no fim, cada desenvolvedor na empresa é responsável pelo próprio código.

Teste externo

Assim que uma versão chega à produção, o teste externo entra em cena. Essa abordagem foi construída em torno do conceito de "garantia contínua", em vez de apenas confiar no teste de intrusão de ponto no tempo, a gente tem um modelo de teste sempre contínuo e ativo pelo uso de um modelo de recompensa por bugs público de crowd source.

Quando uma vulnerabilidade é identificada por um usuário durante o uso padrão de um produto, a gente recebe notificações e responde em seguida às vulnerabilidades enviadas (explicadas no relatório de informações de vulnerabilidade). Mantemos a pessoa que enviou atualizada ao mesmo tempo em que investigamos e resolvemos o item.

Consultores de segurança especializados são usados para concluir os testes de intrusão em produtos e infraestrutura de alto risco, como uma nova arquitetura de infraestrutura (por exemplo, o ambiente na nuvem), um produto novo ou uma rearquitetura fundamental nova (por exemplo, o uso extensivo de microsserviços).

Nesses casos, a Atlassian tem uma abordagem para testes de intrusão extremamente direcionada e focada. Em geral, esses testes são:

Caixa branca: os testadores vão receber a documentação do projeto e os briefings dos nossos engenheiros de produtos como base para os testes
Código assistido: os testadores vão ter acesso completo à base de códigos relevantes para ajudar a diagnosticar qualquer comportamento inesperado do sistema durante o teste e para identificar possíveis alvos
Com base em ameaças: o teste vai se concentrar em um cenário de ameaça específico. Por exemplo, presumir que uma instância comprometida existe e testar o movimento lateral a partir desse ponto inicial

Não disponibilizamos esses relatórios ou extratos para consumo externo devido à quantidade de informações disponibilizadas para os testadores para realizar essas avaliações. Em seguida, a maioria desses sistemas e produtos vai ser inclusa em nosso programa público de recompensa por bugs, oferecendo a garantia externa que os clientes procuram. Para saber mais informações sobre como validamos os testes de segurança de produto, consulte a página Abordagem ao Teste de Segurança Externo.

Gerenciamento de vulnerabilidades do produto

Adotamos abordagens inovadoras para criar software de qualidade

Saímos do ambiente tradicional do controle de qualidade (CQ) para garantir que novos recursos sejam introduzidos com rapidez e segurança, usando o método de "assistência de qualidade*. Nos concentramos em sugerir uma mentalidade de "toda equipe" em relação à qualidade tratando a função de CQ como um facilitador em vez de uma pessoa que, de fato, faz o trabalho de CQ. Também estamos trabalhando para capacitar e treinar desenvolvedores a testar os próprios recursos de acordo com padrões de qualidade.

Embora nos esforcemos para reduzir o número de vulnerabilidades nos produtos, também reconhecemos que são, até certo ponto, uma parte inevitável do processo de desenvolvimento. Com a parceria de recompensa por bugs, procuramos aumentar o custo para encontrar e explorar vulnerabilidades ao longo do tempo, o que deixa o investimento obrigatório de tempo e recurso para os "bandidos" encontrarem outras vulnerabilidades menos atraentes. Para saber mais informações sobre como validamos o gerenciamento de vulnerabilidade de produto, consulte a página Abordagem ao Teste de Segurança Externo.

*Observação: o termo "assistência de qualidade" foi usado pela primeira vez por Cem Kaner. Se você quiser saber mais sobre esse termo e o processo geral de qualidade, leia a série de postagens do blog que falam de CQ.

Práticas operacionais

Embora proteger os produtos seja uma prioridade, a gente também entende a importância de ter consciência do jeito que a gente faz as operações diárias. O conceito de "segurança integrada" é a mesma filosofia que a gente usa em processos internos e influencia o modo como a gente faz negócios.

Acesso aos dados dos clientes

O acesso aos dados do cliente armazenados dentro dos aplicativos é restringido com base em "necessidade de acesso"

Na plataforma de SaaS, tratamos os dados do cliente com confidencialidade total e implementamos controles rigorosos para governar esses dados. O treinamento de conscientização é oferecido a funcionários e contratados internos durante o processo de integração/indução, que trata das práticas recomendadas e a importância que elas têm no processamento de dados do cliente.  

Na Atlassian, só os funcionários autorizados têm acesso aos dados do cliente armazenados nos aplicativos. A autenticação é feita por chaves públicas protegidas por senhas individuais, e os servidores só podem aceitar conexões SSH de entrada da Atlassian e de locais de data center internos.

O acesso não autorizado ou inadequado aos dados do cliente é tratado como um incidente de segurança e gerenciado pelo processo de gerenciamento de incidentes. Esse processo inclui instruções para notificar os clientes afetados caso uma violação da política ocorra.

O acesso físico aos data centers, onde os dados dos clientes são armazenados, está limitado apenas a funcionários autorizados, com o acesso sendo autorizado por biometria. As medidas de segurança física dos data centers incluem guardas de segurança no local, monitoramento de vídeo de circuito fechado, sensores de invasão e outras medidas de proteção contra invasões.

Uma política mais abrangente para governar o acesso aos dados e metadados dos clientes está incluída na Política de Privacidade.

Acesso ao suporte

As equipes de suporte só vão acessar os dados do cliente quando necessário para resolver um chamado aberto

A equipe de suporte global tem acesso aos sistemas e aplicativos baseados na nuvem para facilitar a manutenção e os processos de suporte. Os aplicativos e dados hospedados só podem ser acessados para monitorar a integridade do aplicativo, fazer manutenção no sistema ou no aplicativo e mediante solicitação do cliente pelo sistema de suporte.

Treinamento e consciência

O programa de treinamento e conscientização de segurança não verifica apenas as caixas de conformidade, mas resulta em uma elevação genuína do conhecimento por toda a empresa

O programa de conscientização foi desenvolvido com a crença de que a segurança é responsabilidade de todos. Essas responsabilidades foram retiradas do Programa de Política de Segurança Interno, e o programa de treinamento e conscientização é usado como o meio principal para comunicar essas responsabilidades aos funcionários.

Candidatos e contratados precisam assinar um termo de confidencialidade antes de começar a trabalhar e, depois, durante o processo de integração, os cursos de conscientização de segurança são disponibilizados a eles.

Ainda seguindo o tema de "melhoria contínua", a gente espalha mensagens de segurança nos e-mails e postagens em blogs de toda a empresa. Em geral, essas mensagens são próprias para o momento, como uma ameaça que acabou de ser descoberta e publicada, e reforçam a importância de seguir boas práticas de segurança.

Entusiastas por segurança

A gente sabe que há pessoas que entendem muito de segurança fora da equipe de segurança e procura utilizar o entusiasmo e conhecimento que elas têm.

Além do programa de conscientização, temos também um programa interno de "Entusiastas da Segurança".  A ideia por trás desse programa é tentar incorporar a segurança em cada equipe na Atlassian. Também queremos tornar a segurança mais acessível e um dos modos de fazer isso é treinando as pessoas na empresa com conhecimento fundamental de segurança operacional ou de desenvolvimento. É tudo uma questão de pegar especialistas que amam segurança e têm talento para a coisa e os integrar à equipe em determinados horários para que sejam os defensores no resto da empresa.

Gerenciamento de mudança

Adotamos o gerenciamento de mudança do estilo de código aberto

Os processos de gerenciamento de mudanças tradicionais dependem de uma hierarquia de controle de mudanças no estilo pirâmide. Quando alguém quer fazer uma mudança, ela precisa ser apresentada a um comitê que vai aprovar ou não. A gente passou a fazer uma coisa que chamou de "Análise de Colegas, Build Verde". Cada mudança, seja no código ou na infraestrutura, deve ser analisada por um ou mais colegas para identificar itens que a mudança possa causar. Aumentamos o número de análises com base na importância da mudança ou do produto. A gente confia nas equipes e nos engenheiros de desenvolvimento para identificar itens de segurança e desempenho e para sinalizar a mudança antes que seja aprovada. Parecido com isso, usamos a ferramenta de integração contínua, o Bamboo, para identificar se uma mudança, depois de mesclada à ramificação principal, vai criar itens pelos testes de integração, unidade, funcionais ou de segurança. Se nenhum item for identificado no build e nas fases de teste, o Bamboo vai dar o sinal verde e identificar o processo de build como concluído. Se houver itens, o Bamboo vai mostrar um sinal vermelho e a mesclagem vai ser reavaliada para identificar as mudanças que estão causando esse sinal. O controle "Análise de Colegas, Build Verde" ajuda a identificar milhares de mudanças que fazemos todas as semanas.

Admissão de funcionários

Nos esforçamos para contratar os melhores

Assim como qualquer empresa, queremos atrair e reter os melhores e mais inteligentes talentos para trabalhar na Atlassian. Durante as reuniões semanais no Global Town Hall, sempre recebemos novatos e os desafiamos a "fazer o melhor trabalho da vida deles" e a "tentar mudar a Atlassian para melhor". Queremos que a riqueza de talentos nos torne uma empresa melhor a cada dia e semana. Durante o recrutamento, fazemos verificações de experiência profissional, visto, antecedentes e verificações financeiras. Ao aceitarem uma oferta, garantimos que todos os novatos tenham um plano de integração de 90 dias e acesso ao treinamento contínuo com base na função. 

Procedimento de saída do cliente

Se um contrato entre a Atlassian e um dos clientes que use os produtos em nuvem for encerrado, os dados do cliente vão ser removidos do ambiente em nuvem de acordo com os prazos abaixo.

Cenários onde o contrato do cliente pode terminar incluem:

  • Pagamentos inadimplentes: quando um cliente deixar de pagar a assinatura de produto (mensal ou anual);
  • Cancelamento de assinatura: quando um cliente existente cancelar a assinatura;
  • Período de avaliação termina: quando, após o período de avaliação de um produto, o cliente escolhe não continuar com uma assinatura paga.

Pagamentos inadimplentes

Quando um cliente não realiza um pagamento ou o pagamento não pode ser feito, a assinatura de todos os produtos é cancelada 15 dias após a data de vencimento do pagamento. Assim que isso ocorre, os dados são retidos no backup frio por 60 dias, após os quais vão ser excluídos. Os clientes podem garantir que os dados não sejam excluídos, regularizando os pagamentos inadimplentes dentro dos 15 dias. Não é possível restaurar os dados do cliente após esse prazo, mesmo que o pagamento tenha sido efetuado.

Cancelamento da assinatura

Se um cliente cancelar a assinatura intencionalmente, os dados do cliente vão ser excluídos 60 dias após o período de assinatura atual terminar (para sites pagos).

Para o Jira, se um cliente cancelar a assinatura de um produto Jira (por exemplo, Jira Software) e mantiver outra (por exemplo, Jira Service Desk), os dados do Jira vão ser retidos. Isso inclui situações que envolvam avaliações; se o período de avaliação de um produto Jira terminar, mas o cliente ainda tiver outros produtos Jira em sua assinatura, os dados do Jira vão ser retidos. No entanto, se cancelar a assinatura de todos os produtos Jira, os dados Jira vão ser excluídos na hora.

Da mesma forma, se um cliente retirar o Confluence de sua assinatura de produtos Atlassian, isso vai excluir os dados do Confluence e retirar o acesso ao Confluence de todos os usuários na hora.

Término do período de avaliação

Quando o período de avaliação de um cliente termina e ele opta por não prosseguir com uma assinatura paga, os dados vão ser excluídos após 15 dias (para sites de avaliação)

Depois que os dados do cliente são excluídos em qualquer um dos cenários acima, eles não podem ser recuperados.

Destruição de dados

Os dados vão ser excluídos 15 dias (para sites de avaliação) ou 60 dias (para sites de assinatura paga) após a assinatura ter sido cancelada devido a um pagamento inadimplente da assinatura de um produto Atlassian ou depois de você cancelar a assinatura.

O que acontece se eu não realizar um pagamento ou cancelar a assinatura individual de um produto?

Se o pagamento da assinatura de um produto Atlassian não for feito, a assinatura vai ser cancelada para todos os produtos 15 dias após a data de vencimento do pagamento, quando os usuários não vão mais poder acessar o produto.

O cancelamento da assinatura do produto Atlassian vai impedir o processamento de outras renovações do site. O site vai permanecer acessível até 15 dias após o término do período da assinatura atual, quando o site é desativado. 

Retenção de dados

O site é desativado 15 dias após o final de seu período de assinatura atual. A Atlassian retém os dados de sites desativados por 15 dias (para sites de avaliação) ou 60 dias (para sites de assinatura paga) após o final do período da assinatura atual. 

As avaliações de produtos individuais em uma assinatura anual de produto Atlassian dura 30 dias. Se não recebermos o pagamento, a assinatura dos produtos Jira e Confluence vai ser cancelada 17 dias após a data de vencimento do pagamento, quando os usuários perdem acesso ao Jira e ao Confluence.

Os dados do Confluence são excluídos 15 dias após o cancelamento da assinatura do produto. Se a avaliação de um produto Jira (por exemplo, Jira Service Desk) terminar, mas você ainda tiver outros produtos Jira (por exemplo, Jira Software) na assinatura anual, os dados do Jira não vão ser excluídos. Os dados do Jira só vão ser excluídos se você cancelar a assinatura de todos os produtos Jira. 

O site não pode ser recuperado depois de ser excluído. Recomendamos criar um backup do site do Confluence ou Jira, conforme observação abaixo.

Como devo preparar os dados para migrar para outro site?

Processos de segurança

A gente sabe que sempre há margem para erro. A gente quer ter iniciativa na detecção de itens de segurança, o que nos permite solucionar lacunas identificadas assim que possível para reduzir o dano.

Gerenciamento de incidentes de segurança

Incidentes vão acontecer, mas nossa velocidade e eficiência em reagir vão manter o impacto o mais baixo possível

A equipe de segurança na Atlassian agrega logs de várias fontes na infraestrutura de hospedagem e se certifica de usar uma plataforma SIEM para monitorar e sinalizar atividades suspeitas. Os processos internos definem como esses alertas são analisados, investigados e encaminhados. Contamos com clientes e toda a comunidade para relatar suspeitas de incidentes de segurança pelo Suporte da Atlassian.  

No caso de um incidente grave de segurança, a Atlassian tem acesso interno e externo a especialistas no assunto para investigar incidentes e os resolver. O banco de dados dos incidentes de segurança está catalogado na estrutura VERIS.

Leia mais sobre o processo de gerenciamento de incidentes de segurança e as responsabilidades compartilhadas durante um incidente de segurança.

Gerenciamento de vulnerabilidades

A gente tem um programa de gerenciamento de vulnerabilidade abrangente para garantir a busca por pontos fracos que podem se apresentar no ambiente

Além das práticas de gerenciamento de vulnerabilidade específicas do produto (apresentadas antes), a equipe de segurança faz varreduras de vulnerabilidade contínuas da rede da infraestrutura interna e externa usando um leitor de vulnerabilidades líder do setor. Mais informações sobre esse processo estão disponíveis nas Perguntas frequentes sobre confiança.

A gente usa empresas de consultoria especializadas em segurança para concluir os testes de intrusão em infraestruturas e produtos de alto risco. Exemplos disso incluem uma nova infraestrutura configurada para a gente (como o ambiente Cloud), um novo produto (como o Stride) ou uma rearquitetura fundamental (como o uso extensivo de microsserviços). 

Os processos internos foram implementados para analisar e agir em resposta às vulnerabilidades relatadas. O processo inclui SLAs predefinidos para corrigir vulnerabilidades com base no nível de gravidade CVSS. Leia mais sobre a Política de Atualização de Segurança.

Para saber mais informações sobre os testes de segurança, consulte: A abordagem do teste de segurança externo.

Para obter mais informações sobre o Programa de gerenciamento de vulnerabilidades, consulte: Gerenciamento de vulnerabilidades da Atlassian.

Recompensa por bugs

O programa de recompensa por bugs garante que os sistemas estejam sempre sendo testados

O elemento central da abordagem do gerenciamento de bugs de segurança é o programa de recompensa por bugs, que garante que os produtos sejam sempre testados em relação às vulnerabilidades de segurança. Em um ambiente de desenvolvimento ágil de verdade, com lançamentos frequentes, o teste contínuo é uma necessidade. A gente acredita que os vários pesquisadores de segurança independentes que participam do programa de recompensa por bugs proporcionam o processo de testes de segurança externo e o jeito de conseguir isso mais eficazes.

Mais de 25 produtos ou ambientes, abrangendo produtos de servidor, aplicativos móveis e produtos Cloud, estão no escopo do programa de recompensa por bugs com mais de 500 testadores registrados.  Os dados do número de vulnerabilidades relatadas, o tempo médio de resposta e o bônus médio estão disponíveis no programa de recompensas por bugs.

Para saber mais informações sobre os testes de segurança, consulte: A abordagem do teste de segurança externo.

Baixe os relatórios de testes atuais

Quaisquer vulnerabilidades de segurança identificadas nos relatórios abaixo são monitoradas em nosso Jira interno conforme forem aparecendo no processo interno de recompensa por bugs e são concluídas de acordo com os cronogramas de SLA presentes em nossa Política de correção de bugs.

 

Conformidade

Executamos o programa de segurança de acordo com uma variedade de normas conhecidas no setor. Valorizamos a importância desses atestados, pois oferecem garantia independente para os clientes de que estamos no caminho certo. Leia mais sobre o Programa de gerenciamento de segurança.

No momento, a gente tem certificados dos padrões SOC 2, ISO27001, PCI DSS e CSA STAR. Mais informações sobre esses programas estão disponíveis na página de Conformidade.

Standard

Patrocínio

Status

ISO 27001

Organização Internacional de Normalização

A Atlassian foi credenciada pela ISO27001 para o escopo de operações descrito em nosso certificado de credenciamento. Em resumo, a equipe de segurança está certificada por sua engenharia de segurança, inteligência de segurança e funções de projetos de segurança. No momento, o escopo do credenciamento está sendo expandido por toda a empresa.

O ISO/IEC 27001 também aproveita os controles de segurança abrangentes detalhados no ISO/IEC 27002. A base desta certificação é o desenvolvimento e a implementação de um programa rigoroso de gerenciamento de segurança, incluindo o desenvolvimento e a implementação de um Sistema de gerenciamento de segurança da informação (ISMS). Esse padrão de segurança reconhecido e respeitado mundialmente especifica que as empresas que conquistaram esse certificado também:

  • Avaliar sistematicamente nossos riscos de segurança da informação, levando em consideração o impacto das ameaças e vulnerabilidades de segurança
  • Desenvolver e implementar um conjunto abrangente de controles de segurança da informação para mitigar riscos de segurança
  • Implemente um processo de gerenciamento de auditoria e conformidade abrangente para assegurar que os controles atendam às suas necessidades de modo contínuo

Visualizar o certificado ISO/IEC 27001 da Atlassian.

ISO 27018

Organização Internacional de Normalização

No momento, a Atlassian está estendendo os controles de segurança e privacidade por toda a empresa para atender os requisitos da ISO27018 como parte de seu programa de conformidade GDPR.

ISO/IEC 27018 é um código de prática que foca a proteção de dados pessoais na nuvem. Ele se baseia no padrão de segurança da informação ISO/IEC 27002 e oferece orientações de implementação adicionais para controles do ISO/IEC 27002 aplicáveis às informações de identificação pessoal (PII) na nuvem pública. Ele também oferece um conjunto de controles adicionais e orientações associadas voltadas para atender aos requisitos de proteção de PII na nuvem pública não cumpridos pelo conjunto de controle existente do ISO/IEC 27002.

Visualizar o certificado ISO/IEC 27018 da Atlassian.

PCI-DSS

Indústrias de cartão de pagamento

A Atlassian é um comerciante em conformidade com PCI DSS para receber compras relacionadas a nossos produtos. No entanto, os produtos da Atlassian não têm a intenção de processar ou armazenar dados de cartão de crédito para nossos clientes.

Quando você paga pelos produtos ou serviços Atlassian com cartão de crédito, você pode ter certeza de que tratamos da segurança dessa transação com a devida atenção. Somos comerciantes de nível 2 e nos comprometemos com o Qualified Security Assessor (QSA) para avaliar nossa conformidade com PCI DSS. No momento, a gente está em conformidade com PCI DSS v3.2SAQ A.

Visualizar ou baixar nosso Atestado de Conformidade (AoC) com o PCI:

CSA CCM / STAR

Cloud Security Alliance

Um Questionário CSA STAR de nível 1 para a Atlassian está disponível para download no site de registro do STAR da Cloud Security Alliance.

O CSA Security, Trust & Assurance Registry (STAR) é um registro gratuito e acessível ao público que documenta os controles de segurança fornecidos por várias ofertas de computação em nuvem, ajudando os clientes, assim, a avaliar a segurança dos provedores de nuvem que usam ou estão considerando contratar. A Atlassian é registrada na CSA STAR e é membro corporativo da Cloud Security Alliance (CSA), completou o Questionário de Iniciativa de Avaliação de Consenso (CAIQ) do Cloud Security Alliance (CSA). A última versão do CAIQ, alinhado com a Cloud Controls Matrix (CCM) v.3.0.1 da CSA, responde a mais de 300 perguntas que um cliente ou um auditor de segurança de nuvem queira fazer a um provedor de nuvem

Veja as Entradas do CAIQ da Atlassian no Registro do CSA STAR.

SOC2/SOC3 

Controles de organização de serviço

Os relatórios de Controles de Organização de Serviço (SOC) da Atlassian são certificados por uma firma terceiriza e mostram como a Atlassian alcançam controles e objetivos chave de conformidade. A finalidade desses relatórios é ajudar você e seus auditores a entender os controles estabelecidos para prestar suporte às operações e à conformidade na Atlassian. 

Muitos dos produtos da Atlassian têm certificações SOC2. Baixe as certificações SOC2 e SOC3 da Atlassian aqui.

Também fazemos auditorias abrangentes de segurança pelo menos uma vez ao ano, que são feitas por firmas de auditoria famosas.

Os resultados dessas auditorias e programas de certificação, combinados com resultados do processo interno, como gerenciamento de vulnerabilidade, são inseridos no ciclo de melhoria contínua que ajuda a aprimorar o programa geral de segurança. 

Conformidade com o RGDP

Nos dedicamos 100% ao sucesso dos clientes e à proteção dos dados deles. Uma maneira de cumprirmos essa promessa é ajudando os clientes e os usuários da Atlassian a entender e, se for o caso, cumprir o Regulamento Geral de Proteção de Dados (GDPR). O GDPR é a mudança mais importante na lei de privacidade de dados europeia nos últimos 20 anos e entrou em vigor em 25 de maio de 2018.

A Atlassian entende que os clientes têm que cumprir requisitos do GDPR que recebem impacto direto do uso dos produtos e serviços da Atlassian, e é por isso que investiu tantos recursos para que os clientes possam cumprir esses requisitos de acordo com o GDPR e a lei local.

Abaixo estão várias iniciativas de GDPR para nossos produtos na nuvem:

  • A gente fez investimentos significativos em infraestrutura e certificações de segurança (veja a seção de segurança e certificações).
  • A gente apoia os mecanismos de transferência de dados internacional adequados, mantendo as Certificações Privacy Shield e executando as Cláusulas Contratuais Padrão por meio do Adendo de Processamento de Dados atualizado.
  • A gente oferece ferramentas de portabilidade de dados e gerenciamento de dados, incluindo:
  • A gente garante que a equipe da Atlassian que acessa e processa os dados pessoais dos clientes tenha sido treinada no manuseio desses dados e esteja comprometida a manter a confidencialidade e segurança deles.
  • A gente garante que todos os fornecedores que lidam com dados pessoais sigam os mesmo padrões e práticas de gerenciamento de dados, segurança e privacidade que a gente segue.
  • A gente se compromete a realizar avaliações de impacto de dados e consultoria com reguladores da UE quando for apropriado.

Conheça melhor a abordagem e investimento no GDPR na página Conformidade da Atlassian com o GDPR.

Privacidade

A Atlassian respeita as preocupações dos clientes com a privacidade e entende que essas preocupações podem ser as mesmas que temos ao usar aplicativos com base em SaaS. Assim, a gente tenta tratar dados de identificação pessoais e outras informações confidenciais da mesma maneira que gostaria que os prestadores de serviços fizessem com nossos dados.

A Atlassian e respectivas subsidiárias seguem a estrutura do Privacy Shield da UE e dos EUA e os princípios relacionados do Privacy Shield para coleta, uso e retenção de informações pessoais transferidas da União Europeia para os EUA.

A estratégia de privacidade é explicada na Política de Privacidade.

Atendimento a solicitações legais

A Atlassian publica um Relatório de Transparência anual, que apresenta informações sobre as solicitações governamentais recebidas para acessar dados de usuários, remover conteúdo ou suspender contas de usuários.

Responsabilidade compartilhada

Na nuvem, a segurança dos seus dados em nossos sistemas é uma responsabilidade conjunta.  Essa responsabilidade compartilhada é apresentada com mais informações no artigo técnico publicado há pouco chamado “A equipe de segurança do Atlassian Cloud (você faz parte dela)”.

No geral, a Atlassian lida com a segurança dos aplicativos, dos sistemas onde são executados e dos ambientes onde esses sistemas são hospedados.  Garantimos que esses sistemas e ambientes sigam normas apropriadas, como PCI DSS e SOC2, conforme exigido.

Vocês, nossos clientes, administram as informações das contas, os usuários que acessam essas contas e os dados de acesso relacionados, além de controlar quais aplicativos são instalados e seguros.  Sua empresa deve atender às obrigações de conformidade para usar nossos sistemas.

Árvore de responsabilidade

Em suma, aqui estão algumas coisas que a gente quer que os clientes saibam:

Principais decisões

As decisões que você toma sobre como configurar nossos produtos têm uma influência significativa na forma como a segurança é implementada.  As decisões chave são:

  • Todos os produtos – Verificação de domínio e gerenciamento central. É possível verificar um ou vários domínios para comprovar que eles são seus ou da sua organização. A verificação de domínio permite que a organização tenha um gerenciamento central de todas as contas da Atlassian dos funcionários e aplique políticas de autenticação (incluindo requisitos de senha e SAML). Após verificar seu domínio, todos os usuários com contas da Atlassian existentes sob esse domínio vão receber um e-mail explicando que estão sendo transferidos para uma conta gerenciada. Qualquer um que se inscreva em uma nova conta da Atlassian com esse domínio vai ver que está recebendo uma conta gerenciada.
  • Bitbucket – Repositório público versus repositório privado. Você define quais repositórios são públicos (permitindo a visualização a qualquer um na internet) ou privados (limitando o acesso àqueles que têm permissão para isso).
  • Trello – Times e quadros públicos versus privados. No Trello, é possível selecionar configurações de visibilidade para quadros, incluindo a capacidade de tornar quadros públicos (com algumas limitações se sua conta Trello for gerenciada). Se um quadro for definido como público, significa que ele pode ser visto por qualquer um na internet, além de ser exibido em resultados de pesquisa em mecanismos de pesquisa como o Google. Saiba mais sobre as configurações de visibilidade do quadro do Trello aqui. Você também pode optar por tornar seu time público para que o perfil dele possa ser visualizado por qualquer um na internet. Saiba mais sobre as configurações de visibilidade da equipe do Trello aqui.
  • Todos os produtos – Concedendo acesso. Nossos produtos são criados para permitir a colaboração. A colaboração requer acesso. Mas você precisa ter cuidado ao conceder permissões de acesso a seus dados para outros usuários e para aplicativos. Quando você conceder essas permissões, a gente não vai poder evitar que esses usuários realizem as ações permitidas por essas permissões, mesmo que você não aprove essas ações.

Acesso do usuário

Como uma solução SaaS, os clientes são responsáveis por garantir a adequação do acesso do usuário aos dados. Entender a classificação dos dados que entram no sistema e garantir que os usuários que tenham acesso a ele sejam autorizados a ver esses dados são considerações importantes nesse contexto.

Se for o caso, a autenticação por função vai facilitar alinhar as restrições de acesso que possam precisar ser impostas para seguir requisitos de manuseio e classificação de dados.

Incentivar os usuários a fazer a manutenção correta de senhas também vai diminuir as ameaças, como adivinhação de senha, e evitar que partes maliciosas reutilizem dados de acesso que vazaram.

Ecossistema

O ecossistema da Atlassian é composto pela Atlassian como provedor de serviços, pelos clientes e respectivos usuários e pelo Marketplace. Os clientes têm total controle dos aplicativos que escolhem instalar. Na instalação, o instalador (com frequência, um administrador de usuários) vai poder analisar as permissões concedidas aos aplicativos. É importante que os administradores do cliente prestem atenção a essas permissões. Assim que uma permissão for concedida, a gente vai ter pouquíssima visibilidade do uso que o aplicativo faz dos dados do cliente.

Os clientes devem verificar o desenvolvedor do aplicativo e a adequação e sensatez das permissões solicitadas pelos aplicativos antes da instalação. Assim que o complemento for instalado, monitorar a atividade do aplicativo e relatar atividades suspeitas vão nos ajudar a manter um ecossistema limpo.

Quer saber mais?

Nesta página, alguns outros documentos e recursos são citados. Com eles, você pode entender melhor a abordagem da Atlassian em relação a segurança e confiança.