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, independente do tamanho e do setor, e contribuir com o progresso da humanidade por meio do poder do software. 

A gente sabe 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 a gente trabalha. 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 do 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 é prioridade no desenvolvimento dos 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, segurança de dados e gestão do ciclo de vida de informações.

Segurança

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

Infraestrutura

Gestão de recursos, controle de acesso, operações, segurança de comunicações

Data center e escritórios

Segurança física e ambiental

Corporativo

Governança de segurança, organização de segurança, segurança de funcionários, gerenciamento de dados do fornecedor e de terceiros, segurança móvel, continuidade dos negócios, auditoria/conformidade e 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.

Norma Patrocinador Controles Domínios

ISO27001

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ústria de Cartões de Pagamento

247 requisitos

6 domínios

CSA CCM

Cloud Security Alliance

133 controles

16 domínios

SOC2

Service Organisation Controls

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 mais informações, consulte Estrutura de controles comuns.

 

rede

A gente tem uma abordagem em camadas ao acesso à rede, com controles em cada uma dessas camada

A Atlassian implementa 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 proteção para identificar possíveis problemas de segurança.

Aplicação

A modelagem de ameaças é usada para garantir que os controles certos sejam desenvolvidos para as ameaças enfrentadas

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.

A gente usa a Ferramenta de modelagem de ameaças da Microsoft e a estrutura de modelo de ameaças STRIDE, 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.

A gente usa 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

A gente opera em data centers de 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 gente, que se concentra 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. A gente mantém 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 a gente exige e necessita.

Para ver mais informações sobre como a gente usa 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

A gente tem 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, a gente também tem 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. A gente faz testes trimestrais dos backups. Para obter mais informações, veja a página Infraestrutura. Para saber mais como a gente implementou um programa eficaz de backup, veja a página Gerenciamento de dados do cliente.

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

A gente tem planos de recuperação de desastres e continuidade de negócios comprovados e abrangentes

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 tem algumas práticas importantes para garantir níveis adequados de governança, supervisão e teste:

  1. Governança. O envolvimento da liderança é fundamental para o modo como a gente faz o programa de recuperação de desastres funcionar.  Com a liderança envolvida, a gente tem impulsionadores de negócios e técnicos que são levados em consideração na estratégia de resiliência.
  2. Supervisão e manutenção. A gente tem uma abordagem disciplinada de governança, riscos e conformidade ao monitorar e gerenciar o programa de recuperação de desastres. Isso nos permite operar com mais eficiência e rapidez ao monitorar, medir, relatar e remediar atividades importantes no programa de recuperação de desastres. Os engenheiros de confiabilidade do site estão comprometidos com reuniões contínuas sobre recuperação de desastres e representam os serviços essenciais. Eles discutem lacunas de recuperação e desastres identificadas com a equipe de risco e conformidade e se concentram nos níveis adequados de remediação, conforme necessário.
  3. Testes. A gente faz testes frequentes e se esforça para sempre melhorar como parte do ciclo de vida da recuperação de desastres a fim de garantir que os dados e o uso deles esteja sempre disponível e em execução.
    1. A gente testa os níveis de resiliência nas zonas de disponibilidade do AWS para gerenciar uma falha na zona de disponibilidade com mínimo tempo de inatividade.
    2. A gente leva os backups de dados para data centers regionais do AWS. Se uma região estiver indisponível, a gente protege os dados em uma região secundária no caso de um incidente catastrófico. 
    3. A gente testa as falhas de região do AWS. A gente entende que uma falha total da região é muito improvável de acontecer. Mas a gente continua testando a capacidade dos serviços de failover e aumentando a resiliência regional.
    4. Os procedimentos de backup e restauração estão implementados e são 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 de DR. Para ver mais informações 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.

A gente publica o status de disponibilidade do serviço em tempo real para garantir que você possa acessar os 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+ com 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 no Trello usam criptografia em repouso de disco inteiro da 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. A gente vai 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 segregados logicamente de outros locatários quando estiverem em repouso; e
  • Solicitações que foram processadas pelo Jira ou pelo Confluence tenham uma visão "específica do locatário" para que outros locatários não sejam afetados.

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 de nuvem da Atlassian.

Testes de segurança dos produtos

A gente tem programas de teste de segurança internos e externos com a recompensa 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. A gente tem uma abordagem estabelecida de análise de código estático e dinâmico nas fases de desenvolvimento e teste. Na fase de desenvolvimento, a gente se concentra 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). A gente mantém a pessoa que enviou atualizada ao mesmo tempo em que investiga e resolve 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

O método do teste de intrusão é muito direcionado e focado. Em geral, os testes são:

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

A gente não disponibiliza esses relatórios ou extratos para uso externo devido à quantidade de informações disponibilizadas aos testadores para fazer essas avaliações. Em seguida, a maioria desses sistemas e produtos vai ser incluída no programa público de recompensas por bugs, oferecendo a garantia externa que os clientes procuram. Para mais informações sobre como a gente valida o teste de segurança de produtos, veja a página Abordagem ao teste de segurança externo.

Gerenciamento de vulnerabilidades do produto

A gente conta com métodos inovadores para desenvolver software de qualidade

A gente saiu do quadrado 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*. A gente se concentra 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. A gente também está trabalhando para capacitar e treinar desenvolvedores a testar os próprios recursos de acordo com padrões de qualidade.

Embora a gente se esforce para reduzir o número de vulnerabilidades nos produtos, a gente também reconhece que são, até certo ponto, uma parte inevitável do processo de desenvolvimento. Com a parceria de recompensa por bugs, a gente procura 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 ver mais informações sobre como a gente valida o gerenciamento de vulnerabilidade de produtos, consulte Abordagem em relação aos testes de segurança externos.

*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 nos aplicativos é restrito a situações de necessidade

Na plataforma de SaaS, a gente trata os dados do cliente com confidencialidade total e implementa 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ó acessam os dados do cliente quando necessário para resolver um chamado em 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 conscientização e treinamento de segurança não só atende à conformidade, mas também gera um aumento verdadeiro do conhecimento na 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ça a importância de seguir boas práticas de segurança.

Entusiastas por segurança

A gente sabe que há ótimos crânios em segurança fora da equipe de segurança e busca aproveitar o entusiasmo e conhecimento que têm

Além do programa de conscientização, a gente também tem um programa interno de "Entusiastas por segurança".  A ideia por trás desse programa é tentar incorporar a segurança em cada equipe na Atlassian. A gente também quer 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

A gente passou a fazer o gerenciamento de mudanças no 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 a "Análise de colegas, build verde", um nome inventado por nós. 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. A gente aumenta o número de análises com base na importância da mudança ou do produto. A gente acredita nas equipes e nos engenheiros de desenvolvimento para identificar itens de segurança e desempenho e para sinalizar a mudança antes de seja aprovada. Parecido com isso, a gente usa 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 a gente faz todas as semanas.

Admissão de funcionários

A gente procura contratar os melhores

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

Customer Exit Procedure

If a contract between Atlassian and one of our customers using our cloud products ends, customer data will be removed from our cloud environment according to the timelines below.

Scenarios where customer contract can end include:

  • Missed payments: Where an existing customer misses a payment for their product subscription (whether monthly or annually);
  • Subscription cancellation: Where an existing customer cancels their subscription;
  • Evaluation period ends: Where the trial period for a customer evaluating one of our products chooses not to proceed to a paid subscription.

Missed payments

Where a customer misses a payment or the payment cannot be made, they are unsubscribed from all products 15 days after the due date for the payment. Once this occurs, their data is retained in cold backup for 60 days, after which it is deleted. Customers can ensure their data is not deleted by rectifying any missed payments within the 15 days. It is not possible to restore customer data after this timeline even if payment has been made.

Subscription cancellation

If a customer ends their subscription intentionally, customer data is deleted 60 days after current subscription period ends (for paid sites).

For Jira, if a customer unsubscribes from one Jira product (e.g. Jira Software) and retains another (e.g. Jira Service Desk), their Jira data will be retained. This includes situations involving evaluations; if the evaluation period for one Jira product ends, but the customer still has other Jira products on their subscription, their Jira data is retained. However, if they unsubscribe from all Jira products, their Jira data will be deleted immediately.

Similarly, if a customer removes Confluence from their Atlassian product subscription, this will immediately delete their Confluence data and remove Confluence access for all users.

Evaluation period ends

Where a customer’s evaluation period ends, and they choose not to proceed with a paid subscription, their data is deleted after 15 days (for evaluation sites)

Once customer data is deleted in any of the above scenarios, it cannot be recovered.

Data Destruction

Your data will be deleted 15 days (for evaluation sites) or 60 days (for paid subscription sites) after you have been unsubscribed due to missed payment for an Atlassian product subscription or you cancel your subscription.

What happens if I miss a payment or cancel an individual product subscription?

If payment fails for your Atlassian product subscription, you will be unsubscribed from all products 15 days after the payment due date, at which point users will no longer be able to access the product.

Canceling your Atlassian product subscription will prevent any further site renewals from being processed. Your site will remain accessible until 15 days after the end of your current subscription period, at which point your site will be deactivated. 

Data retention

Your site will be deactivated 15 days after the end of your current subscription period. Atlassian retains data for deactivated sites for 15 days (for evaluation sites) or 60 days (for paid subscription sites) after the end of your current subscription period. 

Evaluations for individual products on an annual Atlassian product subscription last for 30 days. If we fail to receive payment, you will be unsubscribed from Jira and Confluence products 17 days after the payment due date, at which point users will lose access to Jira and Confluence.

Confluence data will be deleted 15 days after the product is unsubscribed. If your evaluation for one Jira product (e.g. Jira Service Desk) ends but you still have other Jira products (e.g. Jira Software) on your annual subscription, your Jira data will not be deleted. Jira data will only be deleted if you unsubscribe from all Jira products. 

Your data cannot be recovered after it's deleted. We strongly recommend creating a Confluence site backup or Jira site backup, as noted below.

How should I prepare my data to move to another 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

Vai haver incidentes, mas a velocidade e a eficiência na resposta vão diminuir o máximo possível o impacto

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. A gente conta 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 conta com um programa de gerenciamento de vulnerabilidades abrangente para garantir que a gente busca os pontos negativos que podem estar 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 também usa empresas de consultoria especializadas em segurança para concluir testes de intrusão em infraestruturas e produtos de alto risco. Exemplos incluem uma nova infraestrutura configurada para nós (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 nossos testes de segurança, consulte : Nossa abordagem ao 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 sejam sempre testados

No centro da abordagem ao gerenciamento de bugs de segurança, está 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 com lançamentos frequentes, os testes contínuos são uma necessidade. A gente acredita que os vários pesquisadores de segurança independentes que participam da recompensa por bugs proporcionam o processo de teste de segurança externo e o jeito mais eficazes de conseguir isso.

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 pagamento médio estão disponíveis no Programa de recompensas por bugs.  

Para saber mais informações sobre nossos testes de segurança, consulte : Nossa abordagem ao teste de segurança externo.

Baixe os relatórios de teste atuais

Todas as vulnerabilidades de segurança identificadas nos relatórios abaixo são monitoradas no próprio Jira assim que aparecem no processo de captação do Programa de recompensa por bugs e são concluídas de acordo com o cronograma de SLA que consta na Política de Atualização de Segurança.

 

Conformidade

A gente executa o programa de segurança de acordo com uma variedade de normas conhecidas no setor e valoriza a importância desses atestados, pois oferecem garantia independente para os clientes de que a gente está no caminho certo. Leia mais sobre o Programa de gerenciamento de segurança.

SOC 2, ISO27001, PCI DSS e CSA STAR são as normas que a gente tem no momento. Veja mais informações esses programas na página Conformidade.

Norma

Patrocinador

Status

ISO27001

International Organization for Standardisation

A Atlassian tem a certificação ISO27001, referente ao escopo de operações descrito no certificado de reconhecimentos. Em suma, a equipe de segurança no momento está certificada pelas funções de engenharia de segurança, inteligência de segurança e projetos de segurança. O escopo da certificação no momento está sendo ampliado em toda a empresa.

ISO/IEC 27001 também aproveita os controles de segurança abrangente especificados na ISO/IEC 27002. A base dessa certificação é o desenvolvimento e a implementação de um programa rigoroso e gerenciamento de segurança, incluindo o desenvolvimento e a implementação de um Sistema de Gerenciamento de Segurança da Informação (ISMS). Essa norma de segurança internacional muito reconhecida e respeitada especifica que empresas que tenham a certificação também:

  • Avalie os riscos de segurança com sistematização, levando em conta o impacto de ameaças e vulnerabilidades de segurança
  • Desenvolva e implementem um pacote abrangente de controles de segurança de informações para solucionar riscos de segurança
  • Implemente um processo global de auditoria e gerenciamento de conformidade para garantir que os controles atendam às necessidades com frequência

Veja o certificado ISO/IEC 27001 da Atlassian.

ISO27018

International Organization for Standardisation

No momento, a Atlassian está expandindo os controles de segurança e privacidade por toda a empresa para atender aos requisitos da ISO27018 como parte do programa de conformidade com o RGPD.

A ISO/IEC 27018 é um código de prática que foca a proteção de dados pessoais na nuvem. Ela é baseada na norma de segurança da informação ISO/EIC 27002 e dá orientações extras de implementação para controles da ISO/EIC 27002 que valem para as informações de identificação pessoal (PII) na nuvem pública. Ela também fornece um conjunto de controles extra e orientações associadas com o objetivo de atender aos requisitos de proteção de PII na nuvem pública não atendidos pelo conjunto de controle atual da ISO/EIC 27002.

Veja o certificado ISO/IEC 27018 da Atlassian.

PCI-DSS

Payment Card Industries

A Atlassian segue a PCI DSS para receber compras relacionadas aos produtos. No entanto, os produtos da Atlassian não são destinados para processar ou armazenar dados de cartão de crédito dos clientes.

Ao pagar os produtos ou serviços da Atlassian com cartão de crédito, você pode ficar tranquilo que a gente lida com a segurança dessa transação com a atenção que merece. A gente é comerciante de nível 2 e se compromete com o Qualified Security Assessor (QSA) para avaliar a conformidade com a PCI DSS v3.2SAQ A.

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

CSA CCM / STAR

Cloud Security Alliance

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

O Security, Trust & Assurance Registry (STAR) da CSA é 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, assim, ajudando os clientes a avaliar a segurança dos provedores de nuvem que usam no momento ou planejam contratar. A Atlassian é registrada na CSA STAR e membro corporativo da Cloud Security Alliance (CSA), bem como 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 da Atlassian no CIAQ no CSA Star Registry.

SOC2/SOC3 

Service Organisation Controls

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ça controles e objetivos principais de conformidade. A finalidade desses relatórios é ajudar você e os auditores a entender os controles estabelecidos para prestar suporte às operações e à conformidade na Atlassian. 

A Atlassian tem as certificações SOC2 para muitos produtos. Baixe as certificações SOC2 e SOC3 da Atlassian aqui.

A gente também faz 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

A gente se dedica 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 (RGPD). O RGPD é 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 gente respeita os direitos dos clientes de acordo com o RGDP e que eles têm impacto direto no uso dos produtos e serviços da Atlassian, e é por isso que a gente se dedicou a ajudar os clientes a aplicar esses direitos sob o RGDP e a lei local.

Veja abaixo várias iniciativas do RGDP nos produtos na nuvem:

  • A gente investiu muito na infraestrutura e nas certificações de segurança (veja a seção de segurança e certificações).
  • A gente oferece compatibilidade com mecanismos internacionais de transferência de dados adequados mantendo as certificações do Privacy Shield e executando as Cláusulas contratuais padrão por meio do Anexo de processamento de dados atualizado.
  • A gente oferece portabilidade de dados e ferramentas de gerenciamento de dados, incluindo:
  • A gente também garantiu que os funcionários da Atlassian que acessam e processam dados pessoais de clientes da Atlassian fossem treinados para cuidar desses dados e obrigados a manter a confidencialidade e segurança desses dados.
  • Os fornecedores que gerenciam dados pessoais devem seguir os mesmos padrões e práticas de gerenciamento de dados, segurança e privacidade que a gente segue.
  • A gente se comprometeu a avaliar a repercussão de dados e consultorias com reguladores da UE quando necessários.

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

Privacidade

A gente respeita as preocupações dos clientes com a privacidade e entende que essas preocupações podem ser as mesmas que a gente tem 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.  A gente garante 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 apps 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 tomadas sobre a configuração dos produtos influenciam muito como a segurança é implementada.  As principais decisões são:

  • Todos os produtos: verificação de domínio e gerenciamento central. Verifique um ou vários domínios para comprovar que você ou sua empresa os tem. A verificação de domínios permite que a organização gerencie por conta própria todas as contas da Atlassian dos funcionários e aplique políticas de autenticação (como requisitos de senha e SAML). Depois de verificar o domínio, todos os usuários com contas atuais da Atlassian sob aquele domínio vão receber um e-mail explicando que eles estão fazendo a transição para uma conta gerenciada. Qualquer pessoa que se inscrever para uma nova conta da Atlassian com esse domínio vai ver que vai receber uma conta gerenciada.
  • Bitbucket: repositórios públicos e privados. Você indica se os repositórios são públicos (ou seja, qualquer um na Internet os pode ver) ou privados (ou seja, o acesso a esses repositórios vai ser restrito às pessoas que têm permissão de acesso).
  • Trello: equipes e painéis públicos e privados. No Trello, é possível escolher as configurações de visibilidade para painéis, incluindo a capacidade de tornar eles públicos (com algumas limitações, se a conta do Trello for gerenciada). Se um painel for público, qualquer pessoa na Internet poderá ver e ele talvez apareça nos resultados de mecanismos de pesquisa, como o Google. Saiba mais sobre as configurações de visibilidade de painéis do Trello aqui. Também é possível tornar a equipe pública para que o perfil dela fique público na Internet para qualquer pessoa. Saiba mais sobre as configurações de visibilidade da equipe no Trello aqui.
  • Todos os produtos: concessão de acesso. Os produtos foram projetados para permitir a colaboração e isso requer acesso. Mas é preciso ter cuidado ao dar permissões de acesso aos dados para outros usuários e para apps. Depois de conceder essas permissões, a gente não vai conseguir evitar que esses usuários façam 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 apps que escolhem instalar. Na instalação, o instalador (com frequência, um administrador de usuários) vai poder analisar as permissões concedidas aos apps. É 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 app faz dos dados do cliente.

Os clientes devem verificar o desenvolvedor do app e a adequação e sensatez das permissões solicitadas pelos apps antes da instalação. Assim que o complemento for instalado, monitorar a atividade do app 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 nossa abordagem sobre segurança e confiança.