Práticas de segurança

A equipe

A gente sabe que a maioria das empresas diria a mesma coisa, mas a gente tem muito orgulho mesmo da equipe de segurança que tem. A gente acredita que recrutou e desenvolveu uma equipe que tem alguns dos melhores e mais brilhantes talentos do setor. A equipe de segurança é liderada pelo CISO em São Francisco e inclui mais de 100 pessoas nos escritórios em Sydney, Amsterdã, Bengaluru, Austin, Mountain View, São Francisco e Nova York (com alguns membros da equipe trabalhando em modelo remoto). A equipe está em contínua expansão, uma vez que a Atlassian considera segurança uma prioridade. A gente tem várias subequipes, incluindo:

• Segurança de produtos – responsável pela segurança dos produtos e plataformas
• Segurança de ecossistemas – responsável pela segurança do Marketplace e de complementos
• Detection and Response – responsible for detecting and responding to security incidents
• Red team - responsible for adversary emulation and exercising Detection and Response
• Arquitetura de segurança – responsável pela definição dos requisitos de segurança dos produtos e plataformas
• Segurança corporativa – responsável pela segurança interna em relação à rede e aos aplicativos corporativos
• Confiança – responsável pelo monitoramento e resposta às expectativas dos clientes e pela transparência nos processos e práticas
• Desenvolvimento e SRE – responsável pela criação e execução de ferramentas para a equipe de segurança
• Conscientização e treinamento – responsável por garantir que os funcionários e parceiros saibam como trabalhar com segurança

Mesmo que a equipe de segurança continue crescendo, todos na Atlassian fazem parte da missão de alcançar uma segurança aprimorada e, durante a permanência na empresa, os funcionários recebem orientações claras sobre esse aspecto. A gente tem como meta liderar os colegas e atender a todos os requisitos dos clientes sobre segurança na nuvem, exceder os requisitos de padrões e certificações de segurança do setor e ter orgulho de publicar informações sobre como a gente faz para proteger os dados dos clientes. Durante a permanência na Atlassian, os funcionários recebem orientações claras sobre as metas e visão da empresa.

Outros programas que a gente usa para dar suporte à segurança

Apesar do foco nos fundamentos da segurança, a gente também tem uma série de programas em vigor para garantir uma abordagem abrangente e proativa em relação à segurança. Elas incluem:

Melhoria contínua do programa de segurança

A gente tem a intenção de garantir que o programa de segurança mantenha a posição inovadora e líder entre os colegas do setor. Então a gente sabe que vai sempre precisar avaliar a abordagem atual em relação à segurança (inclusive em comparação com colegas do setor) e identificar oportunidades de melhoria.

Para alcançar esse objetivo, a gente faz — e vai continuar fazendo — várias avaliações de maturidade do programa de segurança, usando empresas de consultoria de segurança independentes. Em 2020, a gente também fez uma avaliação de colegas do Programa geral de confiança e segurança. A gente separa e usa os resultados desses processos, incluindo as principais recomendações, para resolver quaisquer lacunas e oportunidades de melhoria.

We have also defined a series of programs across our various security – such as Product Security and Detection and Response – to guide our internal improvement. We have defined metrics to support each of these programs which we review through our Security Management Team. We use these metrics to identify and target areas for improvement across each of our core capabilities.

Mais informações

Este artigo oferece uma visão geral da abordagem em relação à segurança, e você pode ver mais informações sobre o programa de segurança no Atlassian Trust Center. Você também pode consultar diversas páginas e artigos técnicos específicos sobre diferentes áreas do programa de segurança disponível, incluindo:

• Como a Atlassian gerencia os dados dos clientes
• Abordagem em relação aos testes de segurança externos
• Nossa abordagem para gerenciar incidentes de segurança
• Nossa abordagem ao gerenciamento de vulnerabilidades
• Responsabilidades compartilhadas de segurança na nuvem
• Atlassian Trust Management System
• Nossas políticas de segurança e tecnologia da Atlassian

Segurança do acesso às redes por meio da confiança zero

A Atlassian protege o acesso à rede corporativa, aplicativos internos e ambientes de nuvem por meio de um conceito chamado de confiança zero. Em resumo, o princípio fundamental da confiança zero é "nunca confie, sempre verifique."

A confiança zero se afasta das abordagens tradicionais de segurança de rede que dependem com exclusividade da autenticação de um usuário para determinar se ele pode acessar recursos na rede. Essa abordagem apresenta o risco potencial de um dispositivo não confiável e não seguro comprometer a segurança. Como resultado, muitas empresas começaram a mudar para um modelo no qual apenas dispositivos confiáveis são capazes de acessar a rede usando abordagens como tecnologias de gerenciamento de dispositivos móveis ou restringindo o acesso em nível de rede a uma lista de dispositivos conhecidos.

Embora úteis, essas abordagens não têm granularidade. A abordagem de confiança zero da Atlassian garante com eficácia que a decisão relativa ao acesso dos usuários aos recursos e serviços nas redes seja feita não apenas com base nas credenciais de autenticação, mas também em uma política dinâmica que leva em consideração uma série de fatores para negar ou permitir o acesso por recurso com base na postura de segurança do dispositivo do usuário (seja qual for a localização).

Em outras palavras, a gente criou três níveis de recursos (com base na criticidade e confidencialidade) na rede em torno dos quais a confiança zero funciona:

• Nível aberto – Qualquer usuário corporativo que se autentica com sucesso na rede pode acessar esses serviços.
• Nível baixo – O acesso a esses recursos está disponível para um usuário corporativo autenticado apenas se este estiver acessando a rede de um dispositivo corporativo confiável (dispositivos que a Atlassian tem e gerencia) ou de um BYOD gerenciado (um dispositivo pessoal que foi cadastrado no programa MDM da Atlassian).
• Nível alto – Esses recursos só estão disponíveis quando acessados por um usuário corporativo autenticado de um dispositivo corporativo emitido pela Atlassian. O acesso aos serviços de produção da rede corporativa só é possível por meio de um dispositivo de alto nível e autenticação de SAML.

Gerenciamento do acesso aos sistemas e serviços com segurança

A Atlassian tem um processo bem definido para provisionamento (atribuição ou revogação) de acesso de usuário para todos os sistemas e serviços. A gente tem um fluxo de trabalho estabelecido (sincronização de 8 horas) vinculando o sistema de gerenciamento de RH e o sistema de provisionamento de acesso. A gente usa o controle de acesso baseado em funções de acordo com perfis de usuário predefinidos para garantir que a equipe tenha acesso adequado às funções de trabalho. Todas as contas de usuário devem ser aprovadas pela gerência antes de ter acesso a dados, aplicativos, infraestrutura ou componentes de rede.

Ao dar suporte à arquitetura de confiança zero, a gente controla o acesso aos aplicativos corporativos por meio de uma plataforma de login único. Para acessar os aplicativos, os funcionários precisam fazer a autenticação por meio desta plataforma, além de um segundo fator de autenticação. Os usuários precisam fazer a autenticação por meio de chaves U2F ou por meio de um autenticador de aplicativo móvel provisionado para funcionários da Atlassian. A gente removeu métodos de autenticação menos seguros, como SMS e OTPs baseados em telefone. A Atlassian adotou essa abordagem para garantir que o processo de autenticação seja muito resistente a ataques baseados em phishing e man-in-the-middle. Qualquer sistema que envie códigos em uma mensagem de texto pode ser comprometido por um invasor habilidoso.

Segurança de terminais

A Atlassian usa uma combinação de gerenciamento de terminais para implementar atualizações e correções em sistemas operacionais e aplicativos essenciais no conjunto de terminais. Várias soluções de proteção de terminais também foram implementadas para proteger contra ameaças como malware.

Como parte da abordagem de confiança zero, o pessoal da Atlassian que quiser acessar a maioria dos serviços por meio de dispositivos móveis pessoais vai precisar se inscrever no Programa de Gerenciamento de Dispositivos Móveis (MDM). Assim a gente pode garantir que todos os dispositivos móveis que se conectam à rede atendam aos requisitos mínimos de segurança, abrangendo aspectos como criptografia, bloqueio de dispositivos, software antimalware e versões do sistema operacional.

O pessoal qualificado que se inscrever e mantiver a conformidade com o programa de MDM vai receber um subsídio mensal da Atlassian pela participação.

Qualquer dispositivo que não apresenta conformidade vai gerar um e-mail notificando o membro da equipe sobre o não cumprimento. O pessoal recebe um período de carência de 24 horas para corrigir a não conformidade antes que o acesso por esse dispositivo seja removido.

Gerenciamento de configurações nos sistemas

A gente tem um grupo limitado de engenheiros e arquitetos com permissão para instalar software no ambiente de produção. Na maioria dos casos, a instalação de software não é possível. As ferramentas de gerenciamento de configuração são utilizadas nos ambientes de produção para gerenciar configurações e alterações nos servidores. As alterações diretas feitas nesses sistemas são definidas para serem substituídas pela configuração aprovada enviada por essas ferramentas de gerenciamento de configuração, garantindo consistência. A gente conta com as Amazon Machine Images (AMIs) padrão. Todas as alterações em nossas AMIs ou sistemas operacionais devem ser feitas por meio de nosso processo padrão de gerenciamento de mudanças. A gente rastreia e relata configurações de exceção e implementa o isolamento de recursos para que os problemas com serviços não afetem outros serviços. A gente também conta com o processo de Análise de Colegas / Build Verde (PRGB) para garantir que vários analisadores aprovem alterações de configuração enviadas por meio de ferramentas de gerenciamento de configuração. Todos os builds são assinados com criptografia e apenas builds assinados podem ser executados no ambiente de produção.

Uso de logs

A gente usa uma plataforma SIEM para agregar logs de várias fontes, aplicar regras de monitoramento a esses logs agregados e sinalizar qualquer atividade suspeita. Os processos internos definem como esses alertas são analisados, investigados e encaminhados. Os principais logs do sistema são encaminhados de cada sistema em que os logs são de somente leitura. A equipe de segurança da Atlassian cria alertas na plataforma de análise de segurança e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar problemas de disponibilidade ou desempenho. Os registros são retidos por 30 dias em backup dinâmico e 365 dias em backup estático.

Os principais logs do sistema são combinados em um sistema interno de análise de log e em um sistema de detecção de invasões.

Os logs são um componente essencial da estratégia geral de detecção e resposta a incidentes, que é aprofundada na seção "Como a gente identifica, protege e responde a ameaças à segurança".

Gerenciamento de continuidade de negócios e de recuperação de desastres

A gente se preocupa bastante com a resiliência dos produtos, até porque a gente — aqui de dentro da Atlassian — usa esses mesmos produtos. A gente sabe que podem ocorrer interrupções. Então a gente tem como meta integrar processos para estabelecer planos para interrupções e lidar com elas com o mínimo de impacto para os clientes quando surgirem. Os programas de continuidade de negócios (BC) e recuperação de desastres (DR) registram as várias atividades realizadas para atender a esses objetivos.

O envolvimento da liderança nas atividades de planejamento de BC e DR garante a supervisão necessária para assegurar que a responsabilidade pela resiliência chegue a todas as equipes. As atividades de planejamento de BC e DR buscam alcançar o equilíbrio correto entre custo, benefícios e riscos por meio de uma análise de "objetivos de tempo de recuperação" (RTO) e "objetivos de ponto de recuperação" (RPO) dos serviços. A partir dessa análise, a gente estabeleceu um sistema simples de 4 níveis para ajudar a agrupar serviços com base nos respectivos requisitos de recuperação. Mais informações sobre essa abordagem podem ser encontradas na página Como a Atlassian gerencia os dados do cliente.

Os programas de BC e DR envolvem as seguintes atividades:

1. medidas de redundância integradas para atender aos requisitos de resiliência

2. testes e verificações dessas medidas de redundância

3. aprendizado com testes para continuar sempre melhorando as medidas de BC e DR

A gente desenvolve os produtos para utilizar da melhor maneira possível os recursos de redundância, como zonas de disponibilidade e regiões, oferecidos pelos fornecedores de serviços na nuvem.

A gente está sempre de olho em uma ampla variedade de métricas com o objetivo de detectar possíveis problemas com antecedência. Com base nessas matrizes, os alertas são configurados para notificar os engenheiros de confiabilidade do site (SREs) ou as equipes de engenharia de produtos relevantes quando os limites são violados para que as ações imediatas possam ser tomadas por meio do processo de resposta a incidentes. Os SREs também desempenham um papel fundamental na identificação de lacunas no programa de DR e trabalham com a equipe de risco e conformidade para solucionar essas lacunas. Cada uma das equipes também inclui um entusiasta de DR para supervisionar e ajudar a gerenciar aspectos de recuperação de desastres relacionados a essa equipe.

Os testes de DR cobrem aspectos de processo e tecnologia, incluindo documentação relevante do processo. A frequência dos testes de DR é estabelecida de acordo com o nível de criticalidade de cada serviço. Por exemplo: os processos de backup e recuperação para os principais sistemas voltados para o cliente são testados a cada trimestre. A gente realiza testes de failover manuais e ad hoc nos sistemas. Esses testes variam de exercícios de simulação de mesa menos complexos a testes mais complexos de zona de disponibilidade ou failover regionais. Seja qual for a complexidade do teste, a gente se dedica na coleta e documentação dos resultados dos testes, analisando e identificando possíveis melhorias ou lacunas até que sejam encerrados com a ajuda de tickets do Jira para garantir a melhoria contínua do processo geral.

São realizadas Avaliações de consequências nos negócios (BIAs) para medir os riscos associados a serviços essenciais. Os resultados dessas BIAs auxiliam no desenvolvimento da estratégia para os esforços de DR e BC. Como resultado, os serviços essenciais conseguem desenvolver planos eficazes de DR e BC.

Disponibilidade de serviços

Além das medidas acima, a gente também publica o status de disponibilidade de serviço em tempo real para os clientes usando um produto próprio, o Statuspage. Se houver algum empecilho com qualquer um dos produtos, os clientes vão saber ao mesmo tempo que a gente.

Backups

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

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

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

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

Segurança física

Os controles de segurança física nos escritórios são guiados pela política de segurança física e ambiental que garante que uma segurança física robusta esteja implementada nos ambientes no local e na nuvem. Essa política abrange áreas como áreas de trabalho seguras, proteção dos equipamentos de TI onde quer que estejam, restrição do acesso aos edifícios e escritórios ao pessoal apropriado e monitoramento dos pontos físicos de entrada e saída. As práticas de segurança física incluem atendimento na recepção durante o horário de trabalho, requisitos para o registro de visitantes, acesso com crachá a todas as áreas não públicas e parcerias com a gestão dos edifícios dos escritórios para ter acesso depois do expediente e gravação de vídeo nos pontos de entrada e saída, tanto para entradas principais quanto para áreas de carregamento.

Os data centers de parceiros estão em conformidade com SOC-2, no mínimo. Essas certificações abordam uma série de controles de segurança, incluindo segurança e proteção física e ambiental. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem guardas de segurança no local, monitoramento por vídeo de circuito fechado, sensores de invasão e outras medidas de proteção contra invasões.

Criptografia de dados

Quaisquer dados de clientes armazenados em produtos 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.

As unidades de dados nos servidores que contêm dados e anexos de clientes no Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello utilizam a criptografia em repouso de disco completo AES-256, padrão do setor. Consulte o Roteiro do Atlassian Trust para ficar sempre em dia com as atualizações de plataforma.

Gerenciamento de chaves

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 pela AWS com frequência como parte dos processos internos de validação dessa solução. Um proprietário é atribuído a cada chave e fica responsável por garantir que o nível adequado de controles de segurança seja aplicado a elas.

Separação de locatário

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

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

• Os dados de cada cliente sejam mantidos em locais separados de outros locatários quando estiverem em repouso
• 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

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

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. Assim a gente tem a garantia de 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.

Mais informações sobre a arquitetura de nuvem estão disponíveis como parte dos recursos de suporte em nuvem.

Compartilhamento da responsabilidade pelo gerenciamento de dados do cliente

A Atlassian assume a responsabilidade pela segurança, disponibilidade e pelo desempenho dos aplicativos que entrega, dos sistemas em que são executados e dos ambientes nos quais esses sistemas estão hospedados. No entanto, a segurança é uma responsabilidade conjunta entre a Atlassian e os clientes em relação a quatro áreas em particular:

Controle do acesso aos dados do cliente

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 internos e prestadores de serviços durante o processo de integração, que trata das práticas recomendadas e da importância que elas têm no processamento de dados do cliente.

Aqui, só os membros autorizados da equipe da Atlassian 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. Salvo por solicitação e análise, todo acesso é restrito a grupos com privilégios, com autenticação adicional que exige 2FA.

Com controles de autenticação e autorização rigorosos em vigor, a equipe de suporte global facilita os processos de manutenção e suporte. Os aplicativos e dados hospedados só podem ser acessados para monitorar a saúde do aplicativo, fazer manutenção no sistema ou no aplicativo e mediante solicitação do cliente pelo sistema de suporte. Os clientes também recebem opções relativas ao consentimento explícito sobre quais engenheiros de suporte são adequados para acessar os dados por meio do verificador de controle de consentimento.

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.

Retenção e exclusão de dados

A gente implementou provisões para que seja possível responder a solicitações de usuários querendo excluir informações pessoais e ajuda os usuários finais com contas da Atlassian a excluir informações pessoais. Além dessas medidas, a gente conta com ferramentas de importação e exportação para que os clientes possam acessar, importar e exportar os dados usando as ferramentas da Atlassian.

Os sites do cliente são desativados 15 dias após o final do período de assinatura atual do cliente. 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 do cliente. Observe que, no caso do Jira, os dados só vão ser excluídos se você cancelar a assinatura de todos os produtos Jira que você assinou antes.

Outras informações estão disponíveis na página de Práticas de segurança ou nas perguntas frequentes sobre armazenamento de dados.