ENISA: Agência Europeia para a Segurança das Redes e da Informação

A Agência Europeia para a Segurança das Redes e da Informação (ENISA) é um centro de especialização em redes e informações. Ela colabora junto aos estados membros da UE e ao setor privado para oferecer orientações e recomendações sobre boas práticas de segurança cibernética. A ENISA também auxilia no desenvolvimento e implementação de políticas e leis da UE relacionadas à segurança da informação nacional.

A Estrutura de Garantia da Informação (IAF) de computação em nuvem da ENISA é um conjunto de critérios de garantia que as organizações podem analisar com os provedores de serviços em nuvem (CSPs) para garantir que tenham proteções suficientes para os dados do cliente. A IAF tem como objetivo avaliar o risco da adoção da nuvem e reduzir a carga de garantia dos CSPs.

A Atlassian se alinha à IAF por meio da adesão da Atlassian à Cloud Control Matrix (CCM) da Cloud Security Alliance (CSA), que mapeia domínios e controles da CCM de acordo com os critérios de garantia da IAF, bem como a certificação de conforme a ISO 27001.

A Atlassian mantém as seguintes garantias baseadas em CCM:

• Autoavaliação do CSA Star 1

A orientação a seguir apresenta critérios de garantia para ajudar as empresas a escolher um provedor de serviços em nuvem. Se você tiver alguma dúvida sobre informações específicas, entre em contato com a equipe de vendas Enterprise da Atlassian https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

A maioria das perguntas relacionadas ao pessoal vai ser semelhante às que você faria à sua própria equipe de TI ou a outra equipe que está lidando com a TI. Como na maioria das avaliações, há um equilíbrio entre o risco e o custo.

6.01. (a)

Quais políticas e procedimentos você tem em vigor ao contratar os administradores de TI ou outras pessoas com acesso ao sistema? Isso deve incluir:

• Verificações pré-contratação (identidade, nacionalidade ou status, histórico e referências profissionais, condenações criminais e vetting (para funcionários seniores em cargos de alto privilégio)).

De acordo com as leis da residência, a nova equipe da Atlassian deve concluir uma verificação de antecedentes. De acordo com as leis da residência, os funcionários recém-contratados como resultado de uma aquisição têm uma verificação de antecedentes feita após a data de aquisição. Uma verificação criminal também é feita em todos os novos contratados e contratados independentes, assim como uma verificação educacional, de emprego ou de crédito são adicionadas se a função ou o nível do cargo exigirem. A gente faz verificações completas de antecedentes para cargos executivos seniores e contábeis.

6.01. (b)

Existem políticas diferentes dependendo de onde os dados são armazenados ou onde os aplicativos são executados?

• Por exemplo, as políticas de contratação em uma região podem ser diferentes das de outra.
• As práticas precisam ser consistentes em todas as regiões.
• Pode ser que dados confidenciais sejam armazenados em uma região específica com pessoal adequado.

A Atlassian mantém restrições ao pessoal que precisa acessar os sistemas, aplicativos e infraestrutura dela para as funções e responsabilidades profissionais, com base no menor privilégio e isso é aplicado por meio dos processos de autenticação dela. Todo o acesso é feito por meio de sessões autenticadas e com base nas permissões estabelecidas.

Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gerenciamento de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gerenciamento do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gerenciamento do hipervisor. As listas de acesso ao console de gerenciamento de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e a Loja de identidades.

Em termos gerais, os controles relacionados ao controle de acesso são abordados na Política de Gerenciamento de Acesso, que tem um trecho disponibilizado em: https://www.atlassian.com/trust

6.01. (c)

Qual programa de educação em segurança você administra para todos os funcionários?

A Atlassian oferece treinamento em segurança da informação como um elemento do treinamento de integração (“Dia 1”) para novos contratados e de forma contínua para todos os funcionários.

Além desse treinamento geral de segurança da informação, um treinamento mais direcionado está disponível para os desenvolvedores sobre codificação segura e é suportado por meio do programa de engenheiros de segurança incorporado.

A gente também oferece treinamento tópico contínuo relacionado a malware, phishing e outras questões de segurança. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

A gente mantém registros formais de conclusão do treinamento interno da equipe. Os funcionários devem reconhecer o Código de Conduta e fazer a reafirmação uma vez por ano. Esta política é oferecida a todos os funcionários. Os requisitos de conscientização sobre segurança, confidencialidade e privacidade são apresentados nos treinamentos diários e estão disponíveis para todos os funcionários no Confluence.

6.01. (d)

Existe um processo de avaliação contínua?

• Com que frequência isso ocorre?
• Entrevistas adicionais.
• Acesso de segurança e avaliações de privilégios.
• Revisões de políticas e procedimentos.

A Atlassian obteve as certificações SOC2, ISO27001 e ISO27018 para os serviços em nuvem. A gente fez auditorias internas/de prontidão e auditorias externas pelo menos uma vez por ano. A Atlassian é certificada pela ISO em vários produtos, o que exige avaliações de risco e análises regulares das práticas de dados.

Para obter mais informações, consulte: https://www.atlassian.com/trust/compliance. Os clientes devem baixar e revisar com frequência as atualizações dos certificados e relatórios de conformidade da Atlassian neste site.

A Atlassian tem uma estrutura política documentada com a Política de Segurança como política principal. O Programa de Gestão de Políticas (PMP) inclui obrigações relacionadas a propriedade, disponibilidade e ciclo de revisão e descreve os objetivos gerais da Atlassian. As políticas da Atlassian são revisadas pelo menos uma vez por ano e aprovadas pela gerência sênior. Mais informações sobre o PMP da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

A gente também publicou trechos de cada uma das políticas de alto nível com o tl:dr, que podem ser encontrados em: https://www.atlassian.com/trust/security/ismp-policies

Todos os sistemas e projetos passam por uma avaliação de impacto no que se refere a informações de identificação pessoal.

Os contratos da Atlassian com terceiros incluem provisões de segurança e privacidade, conforme pertinente. Os novos fornecedores da Atlassian precisam concordar com as políticas de privacidade e segurança nos contratos da Atlassian. As equipes jurídicas e de compras da Atlassian analisam os contratos, SLAs e políticas internas do fornecedor para gerenciar os riscos associados à segurança, disponibilidade e confidencialidade. O Programa de gestão de riscos empresariais (ERM) da Atlassian faz uma avaliação anual de risco que incorpora a probabilidade e o impacto de todas as categorias de risco e está alinhada com o modelo de risco COSO. A gente também faz avaliações de risco funcional conforme necessário com base no perfil de risco. As avaliações de risco são revisadas como parte da renovação da política e sempre que o relacionamento com o fornecedor passar por uma mudança significativa.

6.02.

As perguntas a seguir se aplicam quando o provedor de nuvem terceiriza atividades essenciais para a segurança da operação (por exemplo, um provedor de SaaS que terceiriza a plataforma subjacente para um provedor terceirizado, um provedor de nuvem que terceiriza os serviços de segurança para um provedor de serviços gerenciados de segurança, a utilização de um provedor externo para gerenciamento de identidade de sistemas operacionais etc.). Também se aplicam a terceiros com acesso físico ou remoto à infraestrutura do provedor de nuvem. A estimativa é que esse questionário possa ser aplicado inúmeras vezes a provedores de serviços de nuvem terceirizados (ou subcontratados).

6.02. (a)

Defina os serviços terceirizados ou subcontratados da cadeia de suprimentos de prestação de serviços que são essenciais para a segurança (incluindo disponibilidade) das operações.

A Atlassian trabalha com subcontratados terceirizados para oferecer sites, desenvolvimento de aplicativos, hospedagem, manutenção, backup, armazenamento, infraestrutura virtual, processamento de pagamentos, análise e outros serviços. A lista com os subprocessadores utilizados no momento pela Atlassian e autorizados pelo Cliente está disponível em https://www.atlassian.com/legal/sub-processors.

6.02. (b)

Descreva os procedimentos utilizados para garantir o acesso de terceiros à infraestrutura (física e/ou lógica).

• Os terceirizados e subcontratados são auditados e com que frequência?

As equipes jurídicas e de compras da Atlassian analisam contratos, SLAs e políticas internas do fornecedor para gerenciar os riscos associados à segurança, disponibilidade e confidencialidade. A gente também faz avaliações de risco funcional conforme necessário com base no perfil de risco. As avaliações de risco são revisadas como parte da renovação da política e sempre que o relacionamento com o fornecedor mudar bastante. A Política de Gerenciamento de Dados de Terceiros e Fornecedores da Atlassian aborda esse processo e há um trecho dela disponibilizado em: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

As provisões do SLA garantidas por terceiros são inferiores às dos SLAs que você oferece a seus clientes? Se não forem, você dispõe de outros fornecedores?

Dependendo do acordo de licença, os termos para os clientes da nuvem devem ser revisados na assinatura mensal ou na renovação anual da assinatura. As equipes jurídicas e de compras da Atlassian analisam contratos, SLAs e políticas internas do fornecedor para gerenciar os riscos associados à segurança, disponibilidade e confidencialidade. O Programa de gestão de riscos empresariais (ERM) da Atlassian faz uma avaliação anual de riscos que incorpora a probabilidade e o impacto de todas as categorias de risco e está alinhada com o modelo de risco COSO. Também fazemos avaliações de risco funcional conforme necessário com base no perfil de risco. As avaliações de risco são revisadas como parte da renovação da política e sempre que o relacionamento com o fornecedor mudar bastante.

6.02. (d)

Quais medidas são adotadas para garantir que os níveis de serviço de terceiros sejam cumpridos e mantidos?

As equipes jurídicas e de compras da Atlassian analisam contratos, SLAs e políticas internas do fornecedor para gerenciar os riscos associados à segurança, disponibilidade e confidencialidade. A gente também faz avaliações de risco funcional conforme necessário com base no perfil de risco. As avaliações de risco são revisadas como parte da renovação da política e sempre que o relacionamento com o fornecedor mudar bastante. A Política de Gerenciamento de Dados de Terceiros e Fornecedores da Atlassian aborda esse processo e há um trecho dela disponibilizado em: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

O provedor de nuvem pode confirmar se a política e os controles de segurança se aplicam (com base no contrato) aos provedores terceirizados?

Todos os sistemas e projetos passam por uma avaliação de impacto no que se refere às informações de identificação pessoal (PII). Os contratos da Atlassian com terceiros têm provisões de segurança e privacidade, conforme o caso. Os novos fornecedores precisam concordar com as políticas da Atlassian relativas à privacidade e à segurança nos contratos.

As equipes jurídicas e de compras da Atlassian analisam contratos, SLAs e políticas internas do fornecedor para gerenciar os riscos associados à segurança, disponibilidade e confidencialidade. O Programa de Gestão de Riscos Empresariais (ERM) da Atlassian faz uma avaliação anual de riscos que incorpora a probabilidade e o impacto de todas as categorias de risco e está alinhada com o modelo de risco COSO. A gente também faz avaliações de risco funcional conforme necessário com base no perfil de risco. As avaliações de risco são revisadas como parte da renovação da política e sempre que o relacionamento com o fornecedor mudar bastante.

6.03.

É esperado que qualquer contrato comercial com provedores externos inclua níveis de serviço para todos os serviços de rede. No entanto, além do contrato estabelecido, o cliente final ainda deve garantir que o provedor utilize controles apropriados para mitigar a divulgação não autorizada.

6.03. (a)

Descreva o procedimento e a política de controle de alterações. O processo usado para reavaliar os riscos decorrentes de alterações e esclarecer se os resultados estão disponíveis para os clientes finais também deve fazer parte desta etapa.

A Atlassian tem um Programa de Gestão de Riscos Empresariais (ERM) alinhado com o modelo de risco COSO e a ISO 31000. O Programa de ERM implementa a estrutura e metodologia de gestão de riscos em toda a Atlassian e faz avaliações de risco anuais, avaliações periódicas de riscos específicos do ambiente de produto e avaliações de risco funcional, conforme necessário, com base no perfil de risco.

Em específico, a estrutura de gestão de riscos da Atlassian apresenta padrões, processos, funções e responsabilidades, tolerâncias de risco aceitáveis e diretrizes para a conclusão das atividades de avaliação de riscos. Os processos e práticas de gestão de riscos impulsionam a conclusão das avaliações de risco, que são repetíveis e produzem resultados válidos, consistentes e comparáveis. As avaliações de risco feitas pela Atlassian incorporam a probabilidade e o impacto para todas as categorias de risco, bem como o tratamento de todo e qualquer risco acima do apetite por risco definido pela empresa. Em todas as etapas do Programa de ERM, a equipe de Risco e Conformidade se comunica com as partes interessadas relevantes e consulta os especialistas apropriados.

Os funcionários com funções nos processos de gestão de riscos da Atlassian têm informações e treinamento adequados sobre as próprias responsabilidades e sobre como desempenhar as respectivas atividades. Todos os riscos são monitorados e gerenciados usando o Jira, ferramenta própria da Atlassian, com propriedade no nível de gerenciamento com planos e projetos de tratamento associados. Para obter mais informações, acesse: https://www.atlassian.com/trust/security/security-management-program ou https://www.atlassian.com/trust/compliance/risk-management-program

O processo de gerenciamento de alterações da Atlassian é um pouco diferente dos tradicionais. A gente conta com o controle "Análise por pares e build verde" (PRGB) em todas as alterações, sejam elas de código, aplicativo ou infraestrutura. A Revisão por Pares é configurada na ferramenta de implementação contínua, na qual as ramificações mais importantes devem ter vários revisores para cada Pull Request. Em geral, são dois desenvolvedores e o líder da equipe. A parte "Build verde" do controle significa que a integração durante a fase de IC deve passar por todos os testes de integração, funcionais, de segurança, entre outros, que tiverem sido desenvolvidos. Se não for aprovado nos testes (build vermelho), o código não vai ser mesclado e vai ser necessário fazer outra revisão para solucionar as falhas. Quando o build verde for aprovado, o binário vai receber uma assinatura criptográfica, e o ambiente de produção da Atlassian vai executar apenas binários assinados com a nossa chave. O processo de teste inclui componentes de avaliação automatizados e manuais. A gente adora falar sobre o que a gente faz bem. A abordagem da Atlassian sobre o uso de "Assistência de Qualidade" (em vez da tradicional "Garantia de Qualidade") é algo que a gente adora: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Defina a política de acesso remoto.

Os requisitos de acesso remoto são definidos na Política de Gerenciamento de Acesso e nos padrões associados. Os dados do cliente podem ser replicados nas estações de trabalho dos funcionários para fins de suporte ou migração e com um ticket ativo de suporte ao cliente. Regras rígidas de firewall estão em vigor, limitando assim o acesso ao ambiente de produção à rede VPN da Atlassian e sistemas autorizados. O acesso à VPN da Atlassian requer autenticação multifator.

Todos os dispositivos (de propriedade da Atlassian ou BYOD) usados pelos funcionários da Atlassian que podem acessar QUALQUER ferramenta da Atlassian são registrados no gerenciamento de dispositivos usando perfis de segurança e a verificação da postura de segurança do software MDM. A Atlassian usa um modelo de segurança de Confiança Zero para todos os dispositivos Atlassian. Saiba mais aqui:https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

O provedor mantém procedimentos operacionais documentados nos sistemas de informação?

Os princípios básicos de segurança operacional da Atlassian incluem a criação de documentos de procedimentos operacionais padrão. A gente também publicou trechos de cada uma das políticas de alto nível com o tl:dr, que podem ser encontrados em: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Há um ambiente de staging para reduzir riscos, como ambientes de desenvolvimento, teste e operacionais? Eles são separados?

A Atlassian tem políticas de segurança da informação que proíbem o uso de dados de produção em ambientes que não sejam de produção, e qualquer tentativa de migração de dados entre ambientes é identificada por meio do processo de gerenciamento de alterações. Primeiro, o código é movido do sistema de build centralizado com testes de unidade. Depois, o código passa pela validação da ramificação de função com mais testes de automação e análises feitas pelo gerente de projeto, equipe de desenvolvimento e controle de qualidade. Logo após, passa pelo teste de aceitação do usuário (UAT), segurança e validação de desempenho. Os desenvolvedores não podem promover o código direto no ambiente de produção. Informações detalhadas estão disponíveis em https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

A gente mantém a separação lógica e física dos ambientes de produção e não produção (desenvolvimento), e são usados métodos para isolar esses ambientes.

O ambiente de staging é separado na estrutura lógica — mas não física — e é gerenciado sob controle de alterações de nível de produção e processos de acesso. Para obter mais informações sobre as práticas de segurança de código da Atlassian, acesse: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Defina os controles de host e de rede utilizados para proteger os sistemas que hospedam os aplicativos e as informações do cliente final. Os controles devem incluir informações de certificação de acordo com padrões externos (por exemplo, ISO 27001/2).

A Atlassian Network Engineering usa tecnologias de IPS integradas nos firewalls de nuvem e escritório, e a Atlassian implementou tecnologias de IDS nos ambientes de escritório. A proteção contra ameaças de rede é feita pela AWS, incluindo proteção contra DDoS e algumas funções do Web Application Firewall. Todos os dados dos serviços são criptografados em trânsito usando o TLS para a devida proteção contra divulgação ou modificações não autorizadas, seja por HTTPS ou SMTPS.

A Atlassian obteve as certificações SOC2, ISO 27001 e ISO 27018 para os serviços em nuvem. A gente fez auditorias internas/de prontidão e auditorias externas pelo menos uma vez por ano.

Para obter mais informações, consulte: https://www.atlassian.com/trust/compliance. Os clientes devem baixar e revisar com frequência as atualizações dos certificados e relatórios de conformidade da Atlassian neste site.

6.03. (f)

Especifique os controles utilizados para proteção contra códigos mal-intencionados.

A Atlassian implementou a Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) nos dispositivos Windows e Mac. A gente não usa antimalware nas máquinas Linux. O antimalware está incluído na política de gerenciamento de vulnerabilidades da Atlassian.

A gente mantém uma Política de Gerenciamento de Ameaças e Vulnerabilidades. O Programa de Gestão de Políticas (PMP) inclui obrigações relacionadas a propriedade, disponibilidade e ciclo de revisão e descreve os objetivos gerais da Atlassian. As políticas da Atlassian são revisadas pelo menos uma vez por ano e aprovadas pela gerência sênior. Mais informações sobre o PMP da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

A gente também publicou trechos de cada uma das políticas de alto nível com o tl:dr, que podem ser encontrados em: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Há configurações seguras implementadas para permitir apenas a execução de código móvel e funcionalidades autorizadas (por exemplo, executar apenas comandos específicos)?

Todos os servidores são configurados usando o sistema centralizado de configuração de puppet no ambiente operacional padrão, incluindo a remoção de pacotes selecionados da imagem padrão e atualizações críticas de pacotes. Todas as funções de servidor têm como padrão negar tudo para solicitações de rede recebidas, com portas selecionadas abertas apenas para outras funções de servidor que exigem acesso a essa porta para a função.

A rede corporativa é separada da rede de produção, e as imagens de máquinas são reforçadas para permitir apenas as portas e os protocolos necessários. No momento, todos os sistemas de produção estão hospedados nas regiões dos EUA do provedor de nuvem. Todos os dados em trânsito fora das redes de nuvem privada virtual (VPC) reforçadas são criptografados em canais padrão do setor.

Além disso, um sistema IDS está instalado em todos os servidores de produção, o que inclui monitoramento e alerta em tempo real sobre quaisquer alterações nos arquivos ou configurações do sistema de produção e eventos de segurança anômalos.

Além disso, foi implementada uma solução centralizada de gerenciamento de sistema (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) nos notebooks Mac. Os notebooks da Atlassian utilizam a criptografia de disco total. Também foi implementada uma solução de gerenciamento de dispositivos móveis nos smartphones (https://www.vmware.com/products/workspace-one.html). Todos os dispositivos devem estar registrados para acessar sistemas e aplicativos internos. Se um dispositivo móvel não estiver registrado, ele não vai poder acessar nenhum recurso interno e vai ser adicionado em uma rede de convidados que só pode acessar a Internet. O acesso é gerenciado por meio de controles baseados em funções para garantir que apenas os usuários que precisam acessar os dados do cliente/locatário tenham acesso a essas informações.

6.03. (h)

Explique as políticas e os procedimentos de backup. Inclua os procedimentos para o gerenciamento de mídias removíveis e os métodos de destruição segura de mídias que não são mais necessárias. (Dependendo dos requisitos dos negócios, talvez o cliente queira implementar uma estratégia de backup independente, o que é relevante quando for necessário ter acesso urgente ao backup.)

Na Atlassian, a gente opera um programa de backup abrangente. Ele inclui os sistemas internos, onde as medidas de backup são elaboradas de acordo com os requisitos de recuperação do sistema. Com relação aos produtos de nuvem da Atlassian e, em específico, a você e aos dados do seu aplicativo, a gente também tem amplas medidas de backup implementadas. A gente usa a função de captura instantânea do Amazon RDS (Relational Database Service) para criar backups diários automatizados de cada instância do RDS. Os instantâneos do Amazon RDS são mantidos por 30 dias com suporte para recuperação pontual e são criptografados usando a criptografia AES-256. Os dados de backup não são armazenados fora do local, mas são replicados para vários data centers dentro de uma região específica do AWS. A gente também faz testes trimestrais dos backups. No caso do Bitbucket, os dados são replicados para outra região da AWS, e os backups diários e independentes são feitos 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. Os clientes também devem fazer os próprios backups periódicos para poder reverter as alterações iniciadas pelo cliente. Para obter mais informações, consulte: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

A Atlassian mantém um padrão de Retenção e Destruição de Dados, que designa por quanto tempo a gente precisa manter diferentes tipos de dados. Os dados são classificados de acordo com a Política de Ciclo de Vida de Informações e Segurança de Dados da Atlassian, e os controles são implementados com base nisso. Para dados de clientes, após a rescisão do contrato com a Atlassian, os dados pertencentes à equipe do cliente vão ser removidos do banco de dados de produção ativo e todos os anexos de arquivos enviados para a Atlassian vão ser removidos em 14 dias. Os dados da equipe vão permanecer em backups criptografados até ultrapassarem a janela de retenção de backup de 90 dias e serem destruídos de acordo com a política de retenção de dados da Atlassian. Caso uma restauração do banco de dados seja necessária no prazo de 90 dias após a solicitação de exclusão de dados, a equipe de operações vai excluir de novo os dados assim que for possível após a restauração completa do sistema de produção ativo. Para obter mais informações, consulte: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

Os logs de auditoria são usados no caso de um incidente precisar de investigação, bem como para solucionar problemas. Para esses propósitos, o cliente final vai precisar de garantia de que essas informações estejam disponíveis.

6.03. (i)

O provedor pode especificar quais informações são registradas nos logs de auditoria?

• Por quanto tempo esses dados são retidos?
• É possível segmentar os dados nos logs de auditoria para que eles possam ser disponibilizados ao cliente final e/ou às autoridades policiais sem comprometer outros clientes e ainda serem admissíveis no tribunal?
• Quais controles são empregados para proteger os registros contra acesso não autorizado ou adulteração?
• Qual método é usado para verificar e proteger a integridade dos logs de auditoria?

Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são somente leitura. A equipe de segurança da Atlassian cria alertas na plataforma de análise de segurança (Splunk) e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar itens de disponibilidade ou desempenho. Os logs são retidos por 30 dias em backup dinâmico e 365 dias em backup estático.

A Atlassian restringe a capacidade de visualizar e ler logs de auditoria ao pessoal autorizado na plataforma de registro centralizada.

A Atlassian mantém um padrão de Retenção e Destruição de Dados, que designa por quanto tempo a gente precisa manter diferentes tipos de dados. Os dados são classificados de acordo com a Política de Ciclo de Vida de Informações e Segurança de Dados da Atlassian, e os controles são implementados com base nisso. Para dados de clientes, após a rescisão do contrato com a Atlassian, os dados pertencentes à equipe do cliente vão ser removidos do banco de dados de produção ativo e todos os anexos de arquivos enviados para a Atlassian vão ser removidos em 14 dias. Os dados da equipe vão permanecer em backups criptografados até ultrapassarem a janela de retenção de backup de 90 dias e serem destruídos de acordo com a política de retenção de dados da Atlassian. Caso uma restauração do banco de dados seja necessária no prazo de 90 dias após a solicitação de exclusão de dados, a equipe de operações vai excluir de novo os dados assim que for possível após a restauração completa do sistema de produção ativo. Para obter mais informações, consulte: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

Como os logs de auditoria são revisados? Quais eventos registrados resultam na tomada de medidas?

Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são somente leitura. A equipe de segurança da Atlassian cria alertas na plataforma de análise de segurança (Splunk) e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar itens de disponibilidade ou desempenho. Os logs são retidos por 30 dias em backup dinâmico e 365 dias em backup estático.

A Atlassian restringe a capacidade de visualizar e ler logs de auditoria ao pessoal autorizado na plataforma de registro centralizada.

6.03. (k)

Qual fonte de tempo é usada para sincronizar sistemas e fazer o carimbo de data e hora preciso do log de auditoria?

O Atlassian Cloud usa a sincronização temporal da AWS para todas as instâncias implementadas.

6.03.01. (a)

Defina os controles usados para proteger a integridade do sistema operacional e dos aplicativos usados pelo software. Inclua todos os padrões seguidos, por exemplo, OWASP, SANS Checklist, SAFECode.

A equipe de engenheiros de segurança faz a revisão contínua de todo o código-fonte dos produtos como parte do ciclo de desenvolvimento. São empregadas técnicas automatizadas e manuais. A gente também utiliza um processo obrigatório de revisão dupla por pares, em que vários desenvolvedores sêniores ou líderes revisam todos os commits para ramificação mestre. Fluxos de trabalho ágeis permitem identificar e corrigir qualquer vulnerabilidade com rapidez, em especial nos serviços de nuvem da Atlassian.

O processo seguro de revisão de código da Atlassian faz a varredura automatizada (isto é, a análise da composição do software) de vulnerabilidades conhecidas, inclusive as usadas em ataques do mundo real. Além disso, o programa de gerenciamento de vulnerabilidades verifica imagens de hosts e contêineres em busca de vulnerabilidades conhecidas usando o Snyk. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/vulnerability-management.

A gente colabora com o BugCrowd para manter um Programa de Recompensas por Bugs e fazer avaliações contínuas de vulnerabilidade dos aplicativos e serviços disponíveis para o público. O programa está disponível em: https://bugcrowd.com/atlassian. A gente compartilha os resultados dos testes de intrusão em andamento do Programa de Recompensas por Bugs em: https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Como você confirma se os novos lançamentos são adequados ou não apresentam riscos (backdoors, Trojans etc.)? Eles são revisados antes do uso?

O processo de gerenciamento de alterações da Atlassian é um pouco diferente dos tradicionais. A gente conta com o controle "Análise por pares e build verde" (PRGB) em todas as alterações, sejam elas de código, aplicativo ou infraestrutura. A Revisão por Pares é configurada na ferramenta de implementação contínua, na qual as ramificações mais importantes devem ter vários revisores para cada Pull Request. Em geral, são dois desenvolvedores e o líder da equipe. A parte "Build verde" do controle significa que a integração durante a fase de IC deve passar por todos os testes de integração, funcionais, de segurança, entre outros, que tiverem sido desenvolvidos. Se não for aprovado nos testes (build vermelho), o código não vai ser mesclado e vai ser necessário fazer outra revisão para solucionar as falhas. Quando o build verde for aprovado, o binário vai receber uma assinatura criptográfica, e o ambiente de produção da Atlassian vai executar apenas binários assinados com a nossa chave. O processo de teste inclui componentes de avaliação automatizados e manuais. A gente adora falar sobre o que a gente faz bem. A abordagem da Atlassian sobre o uso de "Assistência de Qualidade" (em vez da tradicional "Garantia de Qualidade") é algo que a gente adora: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Após a implementação, a gente usa varreduras automatizadas regulares de vulnerabilidades e um programa de recompensas por bugs líder do setor (https://bugcrowd.com/atlassian) para oferecer a garantia contínua dos aplicativos. As alterações na configuração do sistema são gerenciadas por um processo automatizado que inclui revisão.

O processo seguro de revisão de código da Atlassian faz a varredura automatizada (isto é, a análise da composição do software) de vulnerabilidades conhecidas, inclusive as usadas em ataques do mundo real. Além disso, o programa de gerenciamento de vulnerabilidades verifica imagens de hosts e contêineres em busca de vulnerabilidades conhecidas usando o Snyk. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

Quais práticas são seguidas para manter os aplicativos seguros?

Os aplicativos exigem uma "Análise por pares e build verde" (PRGB). Depois dela, os artefatos dos aplicativos recebem uma assinatura criptográfica, são implementados pelo pipeline de IC/CD e apenas os aplicativos assinados pela Atlassian podem ser executados no ambiente de produção.

A Atlassian executa práticas de desenvolvimento seguras em todas as fases do ciclo de vida do desenvolvimento. Consulte: https://www.atlassian.com/trust/security/security-in-development.

Na fase de design, as práticas incluem modelagem de ameaças, revisão de design e a biblioteca de padrões de segurança atualizada com frequência garantem que os requisitos de segurança adequados sejam considerados. Durante o desenvolvimento, a gente conta com um processo obrigatório de revisão de pares como a primeira linha de revisão de segurança. Esse processo tem suporte de verificações de análise estática automatizadas (SAST) e testes manuais de segurança (tanto por equipes internas quanto por parceiros de terceiros, conforme determinado pelo processo de avaliação de riscos). O desenvolvimento também tem suporte de programas de treinamento de segurança de aplicativos e uma base de conhecimento de segurança mantida pela equipe de segurança. Os processos formais de prontidão operacional e controle de alterações garantem que só as alterações aprovadas sejam implementadas na produção. Após a implementação, a gente usa varreduras automatizadas regulares de vulnerabilidades e um programa de recompensas por bugs líder do setor (https://bugcrowd.com/atlassian) para oferecer a garantia contínua dos aplicativos. As alterações na configuração do sistema são gerenciadas por um processo automatizado que inclui a revisão de todas as alterações antes da implementação na produção. O setor de operações de serviço da Atlassian pode implementar correções assim que um risco importante for identificado. A gente tem critérios internos para determinar com que rapidez qualquer correção vai ser implementado. A Atlassian é capaz de aplicar correções em todas as máquinas em até 12 horas. Também há um sistema IDS implementado que inclui o monitoramento dos arquivos de configuração do sistema.

6.03.01. (d)

As versões de software passam por testes de intrusão para garantir que não contenham vulnerabilidades? Se forem descobertas vulnerabilidades, como elas são corrigidas?

A Atlassian executa práticas de desenvolvimento seguras em todas as fases do ciclo de vida do desenvolvimento. Consulte: https://www.atlassian.com/trust/security/security-in-development.

Durante o desenvolvimento, a gente conta com um processo obrigatório de revisão de pares como a primeira linha de revisão de segurança. Esse processo tem suporte de verificações de análise estática automatizadas (SAST) e testes manuais de segurança (tanto por equipes internas quanto por parceiros de terceiros, conforme determinado pelo processo de avaliação de riscos). O desenvolvimento também tem suporte de programas de treinamento de segurança de aplicativos e uma base de conhecimento de segurança mantida pela equipe de segurança.

Os processos formais de prontidão operacional e controle de alterações garantem que só as alterações aprovadas sejam implementadas na produção. Após a implementação, a gente usa varreduras automatizadas regulares de vulnerabilidades e um programa de recompensas por bugs líder do setor (https://bugcrowd.com/atlassian) para oferecer a garantia contínua dos aplicativos.

6.03.02. (a)

Explique o procedimento de gestão de correções seguido.

A gente mantém uma Política de Gerenciamento de Ameaças e Vulnerabilidades. O Programa de Gestão de Políticas (PMP) inclui obrigações relacionadas a propriedade, disponibilidade e ciclo de revisão e descreve os objetivos gerais da Atlassian. As políticas da Atlassian são revisadas pelo menos uma vez por ano e aprovadas pela gerência sênior. Mais informações sobre o PMP da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

A gente também publicou trechos de cada uma das políticas de alto nível com o tl:dr, que podem ser encontrados em: https://www.atlassian.com/trust/security/ismp-policies

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. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

Você pode garantir que o processo de gerenciamento de correções abranja todas as camadas das tecnologias de entrega em nuvem, ou seja, rede (componentes de infraestrutura, roteadores e switches etc.), sistemas operacionais de servidores, software de virtualização, aplicativos e subsistemas de segurança (firewalls, gateways antivírus, sistemas de detecção de intrusões etc.)?

As alterações na configuração do sistema são gerenciadas por um processo automatizado que inclui a revisão de todas as alterações antes da implementação na produção. O setor de operações de serviço da Atlassian pode implementar correções assim que um risco importante for identificado. A gente tem critérios internos para determinar com que rapidez qualquer correção vai ser implementado. A Atlassian é capaz de aplicar correções em todas as máquinas em até 12 horas. Há um sistema IDS implementado que inclui o monitoramento dos arquivos de configuração do sistema.

Os produtos Atlassian Cloud podem ser atualizados para a AMI mais recente com a rapidez necessária. Os aplicativos SaaS são atualizados várias vezes por semana. A gente tem mecanismos de implementação rápidos e controlados para atualizar o código e as configurações de sistema. A Atlassian usa um controle de alterações para lidar com alterações não programadas e emergenciais.

6.03.03. (a)

Defina os controles usados para mitigar ataques de DDoS (negação de serviço distribuída).

• Defesa em profundidade (análise profunda de pacotes, limitação de tráfego, descarte de pacotes etc.).
• Você tem defesas contra ataques “internos” (originados das redes dos provedores de nuvem), bem como ataques externos (originados da Internet ou das redes de clientes)?
<

Os requisitos de segurança de rede são definidos na Política de Segurança da Comunicação, que é revisada uma vez por ano conforme o Programa de Gestão de Políticas (PMP). Para ver mais informações sobre o PMP da Atlassian, consulte: https://www.atlassian.com/trust/security/security-management-program

A plataforma Atlassian Cloud tem pouca área de superfície exposta pelos firewalls. A gente analisa as regras de firewall de forma periódica. A gente implementou o IDS nos escritórios e no ambiente de hospedagem na nuvem. Na plataforma Atlassian Cloud, o encaminhamento de registros se integra a uma plataforma de análise de segurança. No nível do contêiner da plataforma Cloud, a integridade do arquivo é mantida, pois as instâncias não podem ser modificadas. A Atlassian Network Engineering usa tecnologias IPS integradas nos firewalls e a gente implementou tecnologias IDS nos ambientes de escritório e nuvem. As capacidades de DDoS são oferecidas pelo provedor/operadora de serviços de Internet.

O desempenho dos firewalls também é avaliado com frequência por meio dos programas de avaliação de vulnerabilidades (https://www.atlassian.com/trust/security/vulnerability-management) e testes de intrusão (https://www.atlassian.com/trust/security/security-testing).

6.03.03. (b)

Quais níveis de isolamento são usados?

• Para máquinas virtuais, máquinas físicas, rede, armazenamento (por exemplo, redes de área de armazenamento), redes de gerenciamento e sistemas de suporte de gerenciamento, etc.
<

A Atlassian é um aplicativo SaaS de múltiplos locatários. A multilocação é uma função fundamental do Atlassian Cloud. Ela permite que vários clientes compartilhem uma instância da camada de aplicativos Jira ou Confluence, isolando os dados do aplicativo de cada locatário do cliente. O Atlassian Cloud faz isso por meio do Serviço de Contexto do Locatário (TCS). Cada ID de usuário é associado apenas a um locatário, que é usado para acessar os aplicativos Atlassian Cloud. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

A gente mantém a separação lógica e física dos ambientes de produção e não produção (desenvolvimento), e são usados métodos para isolar esses ambientes.

O ambiente de staging é separado na estrutura lógica — mas não física — e é gerenciado sob controle de alterações de nível de produção e processos de acesso.

6.03.03. (c)

A arquitetura oferece suporte à operação contínua na nuvem quando a empresa está separada do provedor de serviços e vice-versa (por exemplo, há uma dependência crítica do sistema LDAP do cliente)?

Uma política de Continuidade de Negócios e Recuperação de Desastres e um Plano de Continuidade de Negócios e Recuperação de Desastres estão em vigor e são revisados todos os anos pelo comitê diretor de Continuidade de Negócios/Recuperação de Desastres. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e e https://www.atlassian.com/trust/security/data-management.

A Atlassian utiliza as instalações de data center com alta disponibilidade da AWS em várias regiões do mundo para garantir a operação contínua. Para mais informações, consulte: https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

A infraestrutura de rede virtual usada pelos provedores de nuvem (em arquitetura 802.1q de marcação de PVLANs e VLAN) é protegida de acordo com os padrões específicos do fornecedor e/ou das melhores práticas (por exemplo, a falsificação de MAC, ataques de envenenamento de ARP, etc., são evitados por meio de uma configuração de segurança específica)?

Os requisitos de segurança de rede são definidos na Política de Segurança da Comunicação, que é revisada a cada ano de acordo com o Programa de Gerenciamento de Políticas (PMP). Mais informações sobre o PMP da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

O Plataforma Atlassian Cloud tem muito pouca área de superfície exposta pelos firewalls. A gente analisa as regras de firewall de forma periódica. Foi implementado o IDS nos escritórios e no ambiente de hospedagem na nuvem. Para a Plataforma Atlassian Cloud, o encaminhamento de registros se integra a uma plataforma de análise de segurança. No nível do contêiner do Cloud Platform, a integridade do arquivo é mantida, pois as instâncias não podem ser modificadas. A Atlassian Network Engineering usa tecnologias IPS integradas nos firewalls e a gente implementou tecnologias IDS nos ambientes de escritório e nuvem. As funções de DDoS são oferecidos pelo provedor/operadora de serviços de Internet.

O desempenho dos firewalls também é avaliado com regularidade por meio dos programas de avaliação de vulnerabilidade (https://www.atlassian.com/trust/security/vulnerability-management) e teste de intrusão (https://www.atlassian.com/trust/security/security-testing) .

Além disso, na Atlassian, a gente monitora a configuração dos ambientes de AWS usados em relação às linhas de base de configuração estabelecidas.

6.03.04. (a)

O provedor garante que as imagens virtuais sejam reforçadas por padrão?

Todos os servidores são configurados usando o sistema centralizado de configuração da puppet no ambiente operacional padrão, incluindo a remoção de pacotes selecionados da imagem padrão e atualizações críticas de pacotes. Todas as funções de servidor têm como padrão negar tudo para solicitações de rede recebidas, com portas selecionadas abertas apenas para outras funções de servidor que exigem acesso a essa porta para a função.

A rede corporativa é separada da rede de produção, e as imagens de máquinas são reforçadas para permitir apenas as portas e os protocolos necessários. No momento, todos os sistemas de produção estão hospedados nas regiões dos EUA do provedor de nuvem. Todos os dados em trânsito fora das redes de nuvem privada virtual (VPC) reforçadas são criptografados em canais padrão do setor.

Além disso, um sistema IDS está instalado em todos os servidores de produção, o que inclui monitoramento e alerta em tempo real sobre quaisquer alterações nos arquivos ou configurações do sistema de produção e eventos de segurança anômalos.

Na Plataforma Atlassian Cloud, contêineres individuais não têm uma imagem; quando o contêiner é iniciado, uma imagem é selecionada de um repositório padrão. A gente mantém auditorias contínuas para cada uma das imagens e proporciona uma reaplicação das imagens por meio das ferramentas de configuração quando necessário. Como resultado, as alterações não são feitas nas imagens da máquina virtual.

Os builds de imagens do sistema operacional base do AWS Linux AMI têm portas, protocolos e serviços limitados. A gente compara os builds com a versão atual da AMI para garantir as configurações apropriadas.

As imagens do Docker são gerenciadas em um ambiente de alterações muitíssimo controlado para garantir a revisão e a aprovação apropriadas de todas as alterações.

6.03.04. (b)

A imagem virtual reforçada é protegida contra acesso não autorizado?

Todos os servidores são configurados usando o sistema centralizado de configuração da puppet no ambiente operacional padrão, incluindo a remoção de pacotes selecionados da imagem padrão e atualizações críticas de pacotes. Todas as funções de servidor têm como padrão negar tudo para solicitações de rede recebidas, com portas selecionadas abertas apenas para outras funções de servidor que exigem acesso a essa porta para a função.

A rede corporativa é separada da rede de produção, e as imagens de máquinas são reforçadas para permitir apenas as portas e os protocolos necessários. No momento, todos os sistemas de produção estão hospedados nas regiões dos EUA do provedor de nuvem. Todos os dados em trânsito fora das redes de nuvem privada virtual (VPC) reforçadas são criptografados em canais padrão do setor.

Além disso, um sistema IDS está instalado em todos os servidores de produção, o que inclui monitoramento e alerta em tempo real sobre quaisquer alterações nos arquivos ou configurações do sistema de produção e eventos de segurança anômalos.

Na Plataforma Atlassian Cloud, contêineres individuais não têm uma imagem; quando o contêiner é iniciado, uma imagem é selecionada de um repositório padrão. A gente mantém auditorias contínuas para cada uma das imagens e proporciona uma reaplicação das imagens por meio das ferramentas de configuração quando necessário. Como resultado, as alterações não são feitas nas imagens da máquina virtual.

Os builds de imagens do sistema operacional base do AWS Linux AMI têm portas, protocolos e serviços limitados. A gente compara os builds com a versão atual da AMI para garantir as configurações apropriadas.

As imagens do Docker são gerenciadas em um ambiente de alterações muitíssimo controlado para garantir a revisão e a aprovação apropriadas de todas as alterações.

A equipe de suporte global mantém uma conta em todos os sistemas e aplicativos hospedados para fins de manutenção e suporte. Essa equipe de suporte acessa aplicativos e dados hospedados apenas 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.

6.03.04. (c)

O provedor pode confirmar que a imagem virtualizada não contém as credenciais de autenticação?

Todos os servidores são configurados usando o sistema centralizado de configuração da puppet no ambiente operacional padrão, incluindo a remoção de pacotes selecionados da imagem padrão e atualizações críticas de pacotes. Todas as funções de servidor têm como padrão negar tudo para solicitações de rede recebidas, com portas selecionadas abertas apenas para outras funções de servidor que exigem acesso a essa porta para a função.

A rede corporativa é separada da rede de produção, e as imagens de máquinas são reforçadas para permitir apenas as portas e os protocolos necessários. No momento, todos os sistemas de produção estão hospedados nas regiões dos EUA do provedor de nuvem. Todos os dados em trânsito fora das redes de nuvem privada virtual (VPC) reforçadas são criptografados em canais padrão do setor.

Além disso, um sistema IDS está instalado em todos os servidores de produção, o que inclui monitoramento e alerta em tempo real sobre quaisquer alterações nos arquivos ou configurações do sistema de produção e eventos de segurança anômalos.

Na Plataforma Atlassian Cloud, contêineres individuais não têm uma imagem; quando o contêiner é iniciado, uma imagem é selecionada de um repositório padrão. A gente mantém auditorias contínuas para cada uma das imagens e proporciona uma reaplicação das imagens por meio das ferramentas de configuração quando necessário. Como resultado, as alterações não são feitas nas imagens da máquina virtual.

Os builds de imagens do sistema operacional base do AWS Linux AMI têm portas, protocolos e serviços limitados. A gente compara os builds com a versão atual da AMI para garantir as configurações apropriadas.

As imagens do Docker são gerenciadas em um ambiente de alterações muitíssimo controlado para garantir a revisão e a aprovação apropriadas de todas as alterações.

A equipe de suporte global mantém uma conta em todos os sistemas e aplicativos hospedados para fins de manutenção e suporte. Essa equipe de suporte acessa aplicativos e dados hospedados apenas 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.

6.03.04. (d)

O firewall do host é executado apenas com as portas mínimas necessárias para oferecer suporte aos serviços na instância virtual?

Todos os servidores são configurados usando o sistema centralizado de configuração da puppet no ambiente operacional padrão, incluindo a remoção de pacotes selecionados da imagem padrão e atualizações críticas de pacotes. Todas as funções de servidor têm como padrão negar tudo para solicitações de rede recebidas, com portas selecionadas abertas apenas para outras funções de servidor que exigem acesso a essa porta para a função.

A rede corporativa é separada da rede de produção, e as imagens de máquinas são reforçadas para permitir apenas as portas e os protocolos necessários. No momento, todos os sistemas de produção estão hospedados nas regiões dos EUA do provedor de nuvem. Todos os dados em trânsito fora das redes de nuvem privada virtual (VPC) reforçadas são criptografados em canais padrão do setor.

O Plataforma Atlassian Cloud tem muito pouca área de superfície exposta pelos firewalls. A gente analisa as regras de firewall de forma periódica. Foi implementado o IDS nos escritórios e no ambiente de hospedagem na nuvem. Para a Plataforma Atlassian Cloud, o encaminhamento de registros se integra a uma plataforma de análise de segurança. No nível do contêiner do Cloud Platform, a integridade do arquivo é mantida, pois as instâncias não podem ser modificadas. A Atlassian Network Engineering usa tecnologias IPS integradas nos firewalls e a gente implementou tecnologias IDS nos ambientes de escritório e nuvem. As funções de DDoS são oferecidos pelo provedor/operadora de serviços de Internet.

O desempenho dos firewalls também é avaliado com regularidade por meio dos programas de avaliação de vulnerabilidade (https://www.atlassian.com/trust/security/vulnerability-management) e teste de intrusão (https://www.atlassian.com/trust/security/security-testing) .

6.03.04. (e)

Um serviço de prevenção de intrusões (IPS) baseado em host pode ser executado na instância virtual?

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.03.05.

De um modo geral, os provedores de serviços de PaaS são responsáveis pela segurança da pilha de software da plataforma, e as recomendações neste documento são uma boa base para garantir que um provedor de PaaS tenha considerado os princípios de segurança ao projetar e gerenciar a plataforma de PaaS. Muitas vezes, é difícil obter informações detalhadas dos provedores de PaaS sobre como eles protegem as plataformas com exatidão. No entanto, as perguntas a seguir, com outras seções deste documento, devem ajudar na avaliação das ofertas.

6.03.05. (a)

Solicite informações sobre como os aplicativos multilocatários são isolados uns dos outros — é necessária uma descrição de alto nível das medidas de contenção e isolamento.

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.03.05. (b)

Que garantia o provedor de PaaS pode dar de que o acesso aos dados é restrito aos usuários corporativos e aos aplicativos que você tem?

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.03.05. (c)

A arquitetura da plataforma deve ser um repositório clássico — o provedor garante que o repositório da plataforma PaaS seja monitorado em busca de novos bugs e vulnerabilidades?

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.03.05. (d)

Os provedores de PaaS devem ser capazes de oferecer um conjunto de funções de segurança (reutilizáveis entre os clientes). Estão incluídos autenticação de usuário, login único, autorização (gestão de privilégios) e SSL/TLS (disponibilizado por uma API)?

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.03.06.

O modelo SaaS determina que o provedor gerencie todo o conjunto de aplicativos oferecidos aos usuários finais. Portanto, os provedores de SaaS são os principais responsáveis por proteger esses aplicativos. Os clientes são responsáveis pelos processos de segurança operacional (gestão de usuários e de acessos). No entanto, as perguntas a seguir, em conjunto com outras seções deste documento, devem ajudar na avaliação de ofertas:

6.03.06. (a)

Quais controles administrativos são oferecidos e podem ser usados para atribuir privilégios de leitura e gravação a outros usuários.

Os clientes das ofertas Enterprise e Premium Cloud têm acesso a um painel de controle administrativo centralizado. Os administradores da organização podem gerenciar o acesso e as permissões dos usuários em todas as instâncias do produto. Confira o blog aqui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Os clientes da Atlassian podem usar o provedor de identidade terceirizado escolhido se for suportado pela Atlassian. Uma página de Suporte da Atlassian detalha essas funções e como conectar ao provedor de identidade escolhido. Consulte: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

O controle de acesso SaaS é refinado e pode ser personalizado de acordo com a política da empresa?

Os clientes das ofertas Enterprise e Premium Cloud têm acesso a um painel de controle administrativo centralizado. Os administradores da organização podem gerenciar o acesso e as permissões dos usuários em todas as instâncias do produto. Confira o blog aqui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Os clientes da Atlassian podem usar o provedor de identidade terceirizado escolhido se for suportado pela Atlassian. Uma página de Suporte da Atlassian detalha essas funções e como conectar ao provedor de identidade escolhido. Consulte: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

Em caso de sobrecarga de recursos (processamento, memória, armazenamento, rede)?

• Quais informações são apresentadas sobre a prioridade relativa atribuída à solicitação feita por mim no caso de uma falha no provisionamento?
• Existe um tempo de espera nos níveis de serviço e nas alterações nos requisitos?
<

A Atlassian planeja a capacidade com 6 a 12 meses de antecedência, com um planejamento estratégico de alto nível em 36 meses.

A Atlassian mantém dados de análise para a arquitetura de expansão e redução do Cloud AWS e do Azure e usa esses dados para projetar o crescimento dos produtos Atlassian. No entanto, esses dados não são passados aos clientes no momento.

6.03.07. (b)

Quanto você pode evoluir? O provedor oferece garantias sobre o máximo de recursos disponíveis em um período mínimo?

A Atlassian planeja a capacidade com 6 a 12 meses de antecedência, com um planejamento estratégico de alto nível em 36 meses.

A Atlassian mantém dados de análise para a arquitetura de expansão e redução do Cloud AWS e do Azure e usa esses dados para projetar o crescimento dos produtos Atlassian. No entanto, esses dados não são passados aos clientes no momento.

6.03.07. (c)

Com que rapidez você pode evoluir? O provedor oferece garantias sobre a disponibilidade de recursos complementares em um período mínimo?

A Atlassian planeja a capacidade com 6 a 12 meses de antecedência, com um planejamento estratégico de alto nível em 36 meses.

A Atlassian mantém dados de análise para a arquitetura de expansão e redução do Cloud AWS e do Azure e usa esses dados para projetar o crescimento dos produtos Atlassian. No entanto, esses dados não são passados aos clientes no momento.

6.03.07. (d)

Quais processos estão em vigor para lidar com tendências em grande escala no uso de recursos (por exemplo, efeitos sazonais)?

A Atlassian planeja a capacidade com 6 a 12 meses de antecedência, com um planejamento estratégico de alto nível em 36 meses.

A Atlassian mantém dados de análise para a arquitetura de expansão e redução do Cloud AWS e do Azure e usa esses dados para projetar o crescimento dos produtos Atlassian. No entanto, esses dados não são passados aos clientes no momento.

6.04.01.

Os controles a seguir se aplicam aos sistemas de gestão de identidade e acesso do provedor de nuvem (aqueles sob controle).

6.04.01. (a)

Alguma conta tem privilégios em todo o sistema para todo o sistema em nuvem e, em caso afirmativo, para quais operações (leitura/gravação/exclusão)?

A equipe de suporte global mantém uma conta em todos os sistemas e aplicativos hospedados para fins de manutenção e suporte. Essa equipe de suporte acessa aplicativos e dados hospedados apenas 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.

6.04.01. (b)

Como as contas com o mais alto nível de privilégio são autenticadas e gerenciadas?

A Atlassian mantém restrições apenas ao pessoal que precisa desse acesso para as devidas funções e responsabilidades. Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gestão de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gestão do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gestão do hipervisor. As listas de acesso ao console de gestão de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e o armazenamento de identidades.

6.04.01. (c)

Como as decisões mais críticas (por exemplo, desprovisionamento simultâneo de grandes blocos de recursos) são autorizadas (simples ou duplas e por quais funções na organização)?

A Atlassian mantém restrições apenas ao pessoal que precisa desse acesso para as devidas funções e responsabilidades. Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gestão de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gestão do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gestão do hipervisor. As listas de acesso ao console de gestão de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e o armazenamento de identidades.

Os controles de segregação de funções estão em vigor para os principais produtos e incluem, mas não se limitam a:

• Avaliações de controles de acesso
• Grupos de segurança gerenciados por aplicativos de RH
• Aprovação de alterações/revisão/implementação por pares (PRGB)
• Controles de fluxo de trabalho

6.04.01. (d)

Há alguma função de alto privilégio atribuída à mesma pessoa? Essa alocação quebra as regras de segregação de funções ou de privilégios mínimos?

A Atlassian mantém restrições apenas ao pessoal que precisa desse acesso para as devidas funções e responsabilidades. Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gestão de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gestão do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gestão do hipervisor. As listas de acesso ao console de gestão de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e o armazenamento de identidades.

Os controles de segregação de funções estão em vigor para os principais produtos e incluem, mas não se limitam a:

• Avaliações de controles de acesso
• Grupos de segurança gerenciados por aplicativos de RH
• Aprovação de alterações/revisão/implementação por pares (PRGB)
• Controles de fluxo de trabalho

6.04.01. (e)

Você usa o controle de acesso baseado em funções (RBAC)? O princípio do menor privilégio é seguido?

A Atlassian tem um fluxo de trabalho estabelecido que vincula o sistema de gestão de RH e o sistema de provisionamento de acesso. A gente usa o controle de acesso baseado em funções com base em perfis de usuário predefinidos. Todas as contas de usuário devem ser aprovadas pela gerência antes de ter acesso a dados, aplicativos, infraestrutura ou componentes de rede.

A Atlassian mantém restrições ao pessoal que precisa acessar os sistemas, aplicativos e infraestrutura dela para as funções e responsabilidades profissionais, com base no menor privilégio e isso é aplicado por meio dos processos de autenticação que ela tem.

6.04.01. (f)

Quais alterações, se houver, são feitas nos privilégios e funções do administrador para permitir acesso extraordinário em caso de emergência?

A equipe de suporte global mantém uma conta em todos os sistemas e aplicativos hospedados para fins de manutenção e suporte. Essa equipe de suporte acessa aplicativos e dados hospedados apenas 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.

6.04.01. (g)

Existe uma função de “administrador” para o cliente? Por exemplo, o administrador do cliente tem um papel na adição de novos usuários (mas sem permitir a alteração do armazenamento subjacente!)?

A Atlassian oferece aos clientes a função de “administrador da organização”, que administra usuários e grupos dos produtos do cliente. Para mais informações, consulte: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Quais verificações são feitas na identidade das contas dos usuários no momento do registro? Algum padrão foi seguido? Por exemplo, a Estrutura de Interoperabilidade do Governo Eletrônico?

• Existem diferentes níveis de verificação de identidade com base nos recursos necessários?

Novos Atlassians em todo o mundo precisam concluir uma verificação de antecedentes. Devido à aquisição, os funcionários recém-contratados são submetidos a uma verificação de antecedentes após a data de aquisição. Uma verificação criminal também é feita em todos os novos contratados e contratados independentes, assim como uma verificação educacional, de emprego ou de crédito são adicionadas se a função ou o nível do cargo exigirem. A gente faz verificações completas de antecedentes para cargos executivos seniores e contábeis.

A Atlassian tem um fluxo de trabalho estabelecido que vincula o sistema de gestão de RH e o sistema de provisionamento de acesso. A gente usa o controle de acesso baseado em funções com base em perfis de usuário predefinidos. Todas as contas de usuário devem ser aprovadas pela gerência antes de ter acesso a dados, aplicativos, infraestrutura ou componentes de rede.

6.04.02. (b)

Quais processos estão em vigor para o desprovisionamento de credenciais?

No momento, o processo de desprovisionamento incorpora a rescisão do contrato de trabalho, contrato ou acordo. Os usuários que se transferem dentro da própria empresa costumam manter os direitos de acesso para permitir engajamento e suporte contínuos. Para que a equipe seja muito responsiva e flexível, focada no cliente, de acordo com os valores da empresa, o foco é detectar o uso não autorizado do acesso, em vez de restringir o acesso, o que pode diminuir a capacidade de resposta.

6.04.02. (c)

As credenciais são provisionadas e desprovisionadas ao mesmo tempo em todo o sistema de nuvem ou há algum risco em fazer o desprovisionamento delas em vários locais distintos?

A Atlassian tem um fluxo de trabalho estabelecido que vincula o sistema de gestão de RH e o sistema de provisionamento de acesso. A gente usa o controle de acesso baseado em funções com base em perfis de usuário predefinidos. Todas as contas de usuário devem ser aprovadas pela gerência antes de ter acesso a dados, aplicativos, infraestrutura ou componentes de rede.

O aplicativo de RH é sincronizado com o armazenamento de identidades interno a cada 8 horas, removendo todas as contas de funcionários ou prestadores de serviços que não estão mais empregados.

6.04.03. (a)

Quais controles de armazenamento e proteção de dados se aplicam ao diretório do usuário (por exemplo, AD, LDAP) e ao acesso a ele?

Os dados são classificados e tratados de acordo com o ciclo de vida das informações e a política de segurança de dados, e os controles são implementados com base nisso. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices

Todos os sistemas e projetos passam por uma avaliação de impacto no que se refere às informações de identificação pessoal (PII). Os contratos da Atlassian com terceiros incluem provisões de segurança e privacidade, conforme pertinente. Os novos fornecedores da Atlassian precisam concordar com as políticas de privacidade e segurança nos contratos da Atlassian.

A Atlassian é certificada pela ISO em vários produtos, o que exige avaliações de risco e análises regulares das práticas de dados.

A avaliação de impacto da transferência de dados pode ser encontrada em: https://www.atlassian.com/legal/data-transfer-impact-assessment

A Atlassian mantém um padrão de Retenção e Destruição de Dados, que designa por quanto tempo a gente precisa manter diferentes tipos de dados. Os dados são classificados de acordo com a Política de Ciclo de Vida de Informações e Segurança de Dados da Atlassian, e os controles são implementados com base nisso.

Para dados de clientes, após a rescisão do contrato com a Atlassian, os dados pertencentes à equipe do cliente vão ser removidos do banco de dados de produção ativo e todos os anexos de arquivos enviados para a Atlassian vão ser removidos em 14 dias. Os dados da equipe vão permanecer em backups criptografados até que esses backups saiam da janela de retenção de backup de 90 dias e sejam destruídos de acordo com a política de retenção de dados da Atlassian. Caso uma restauração do banco de dados seja necessária dentro de 90 dias após a solicitação de exclusão de dados, a equipe de operações vai excluir de novo os dados assim que for possível após a restauração completa do sistema de produção ativo. Para mais informações, consulte: a armazenamento de identidades.a armazenamento de identidades.https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Os dados do diretório do usuário podem ser exportados em um formato interoperável?

Os administradores podem exportar o diretório de usuários do painel de administração. Os guias estão disponíveis no site de suporte da Atlassian aqui: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

A necessidade de saber é a base para o acesso aos dados do cliente no provedor de nuvem?

A Atlassian mantém restrições apenas ao pessoal que precisa desse acesso para as devidas funções e responsabilidades. Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gestão de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gestão do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gestão do hipervisor. As listas de acesso ao console de gestão de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e o armazenamento de identidades.

Os controles de segregação de funções estão em vigor para os principais produtos e incluem, mas não se limitam a:

• Avaliações de controles de acesso
• Grupos de segurança gerenciados por aplicativos de RH
• Aprovação de alterações/revisão/implementação por pares (PRGB)
• Controles de fluxo de trabalho

6.04.04.

Para chaves sob o controle do provedor de nuvem:

6.04.04. (a)

Existem controles de segurança em vigor para ler e escrever essas chaves? Por exemplo, políticas de senha forte, chaves armazenadas em um sistema separado, módulos de segurança de hardware (HSM) para chaves de certificado raiz, autenticação baseada em cartão inteligente, acesso protegido direto ao armazenamento, vida útil curta da chave etc.

A Atlassian mantém políticas de criptografia e diretrizes de implementação. Esta política é revisada e atualizada todos os anos de acordo com o Programa de Gestão de Políticas (PMP). Para mais informações, consulte: https://www.atlassian.com/trust/security/security-management-program.

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura de nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego. O serviço AWS KMS está em conformidade com SOC 1, SOC 2 e SOC 3. Para mais informações, consulte: https://aws.amazon.com/kms/

6.04.04. (b)

Existem controles de segurança em vigor para usar essas chaves para assinar e criptografar dados?

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura de nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves mestras no KMS, após a criação, permitem uma rotação automática para gerar material de chave mestra a cada 365 dias (todos os anos).

6.04.04. (c)

Existem procedimentos em vigor no caso de um compromisso importante? Por exemplo, listas de revogação de chaves.

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura na nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego. O serviço AWS KMS está em conformidade com SOC 1, SOC 2 e SOC 3. Para mais informações, consulte: https://aws.amazon.com/kms/

6.04.04. (c)

Existem procedimentos em vigor no caso de um compromisso importante? Por exemplo, listas de revogação de chaves.

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura na nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego. O serviço AWS KMS está em conformidade com SOC 1, SOC 2 e SOC 3. Para mais informações, consulte: https://aws.amazon.com/kms/

6.04.04. (d)

A revogação de chaves é capaz de lidar com problemas de simultaneidade em vários locais?

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura na nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego. O serviço AWS KMS está em conformidade com SOC 1, SOC 2 e SOC 3. Para mais informações, consulte: https://aws.amazon.com/kms/

6.04.04. (e)

As imagens do sistema do cliente estão protegidas ou criptografadas?

A Atlassian usa a versão 1.2 do Transport Layer Security (“TLS”) padrão do setor para criar uma conexão segura usando a criptografia Advanced Encryption Standard (“AES”) de 256 ­bits. Os servidores que armazenam dados de usuários utilizam criptografia AES de disco inteiro, padrão do setor. Os dados do locatário são criptografados nos backups do AWS RDS ou RDS e também são criptografados no armazenamento de longo prazo (S3), bem como em todos os anexos. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

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) versão 1.2 ou superior 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 Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello utilizam a criptografia em repouso de disco completo AES-256, padrão do setor.

Na criptografia de dados 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 de dados 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.

6.04.05. (a)

A criptografia pode ser usada em vários lugares — onde ela é usada?

• Dados em trânsito?
• Dados em repouso?
• Dados no processador ou na memória?

A Atlassian mantém políticas de criptografia e diretrizes de implementação. Esta política é revisada e atualizada todos os anos de acordo com o Programa de Gerenciamento de Políticas (PMP). Para mais informações, consulte: https://www.atlassian.com/trust/security/security-management-program .

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura na nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego.

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) versão 1.2 ou superior 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 Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie e Trello utilizam a criptografia em repouso de disco completo AES-256, padrão do setor.

Na criptografia de dados 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 de dados 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.

6.04.05. (b)

Existe uma política bem definida sobre o que deve ser criptografado e o que não deve ser criptografado?

A Atlassian mantém políticas de criptografia e diretrizes de implementação. Esta política é revisada e atualizada todos os anos de acordo com o Programa de Gerenciamento de Políticas (PMP). Para mais informações, consulte: https://www.atlassian.com/trust/security/security-management-program.

A Atlassian mantém procedimentos documentados de gestão de chaves para a infraestrutura na nuvem. As chaves de criptografia dos anexos da Amazon, armazenadas no S3, são gerenciadas pelo Amazon KMS. O processo de criptografia, gestão de chaves e descriptografia é inspecionado e verificado dentro da própria empresa pela Amazon com regularidade como parte do processo de auditoria existente. As chaves gerenciadas pela Atlassian são revezadas de acordo com alterações relevantes de funções ou status de emprego.

6.04.05. (d)

Quem tem as chaves de acesso?

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

6.04.05. (e)

Como as chaves são protegidas?

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

6.04.06. (a)

Quais formas de autenticação são usadas para operações que exigem alta garantia? Isso pode incluir login em interfaces de gerenciamento, criação de chaves, acesso a contas de vários usuários, configuração de firewall, acesso remoto etc.

• A autenticação de dois fatores é usada para gerenciar componentes críticos na infraestrutura, como firewalls?

A gente segue as diretrizes descritas na Publicação Especial 800-63B do NIST. Veja: https://pages.nist.gov/800-63-3/sp800-63b.html

O processo de alocação de senhas é abordado na Política de Senhas da Atlassian. As novas senhas não vão ser comunicadas por meios eletrônicos, exceto nas instâncias em que uma senha inicial de uso único é enviada. Nesses casos, o usuário vai ser forçado a alterar a senha de uso único na primeira utilização.

Em termos gerais, os controles relacionados ao controle de acesso são abordados na Política de Gerenciamento de Acesso, que tem um trecho disponibilizado em: https://www.atlassian.com/trust/security/ismp-policies

A Atlassian mantém restrições ao pessoal que precisa acessar os sistemas, aplicativos e infraestrutura dela para as funções e responsabilidades profissionais, com base no menor privilégio e isso é aplicado por meio dos processos de autenticação dela. Todo o acesso é feito por meio de sessões autenticadas e com base nas permissões estabelecidas.

A Atlassian mantém restrições apenas ao pessoal que precisa desse acesso para as devidas funções e responsabilidades. Todos os sistemas de nível 1 são gerenciados por meio da solução centralizada de login único (SSO) e de diretório da Atlassian. Os usuários recebem direitos de acesso apropriados com base nesses perfis, orientados por meio do fluxo de trabalho do sistema de gerenciamento de RH. A Atlassian utiliza a autenticação multifator (MFA) para acessar todos os sistemas de nível 1. A gente habilitou a autenticação de dois fatores no console de gerenciamento do hipervisor e na API da AWS, além de um relatório diário de auditoria sobre todo o acesso às funções de gerenciamento do hipervisor. As listas de acesso ao console de gerenciamento de hipervisores e à API da AWS são revisadas a cada trimestre. A gente também mantém uma sincronização de 8 horas entre o sistema de RH e a loja de identidades.

6.04.07. (a)

Você oferece detecção de anomalias (a capacidade de detectar tráfego IP incomum e com potencial malicioso e comportamentos do usuário ou da equipe de suporte)? Por exemplo, análise de logins fracassados e bem-sucedidos, hora incomum do dia e vários logins etc.

A plataforma Atlassian Cloud tem pouca área de superfície exposta pelos firewalls. A gente analisa as regras de firewall de forma periódica. Foi implementado o IDS nos escritórios e no ambiente de hospedagem na nuvem. Para a plataforma Atlassian Cloud, o encaminhamento de registros se integra a uma plataforma de análise de segurança. No nível do contêiner da plataforma Cloud, a integridade do arquivo é mantida, pois as instâncias não podem ser modificadas. A Atlassian Network Engineering usa tecnologias IPS integradas nos firewalls, e foram implementadas tecnologias IDS nos ambientes de escritório e nuvem. As capacidades de DDoS são oferecidas pelo provedor/operadora de serviços de internet.

Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são apenas para leitura. A equipe de segurança da Atlassian cria alertas na plataforma de análise de segurança (Splunk) e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar itens de disponibilidade ou desempenho. Os registros são retidos por 30 dias em backup dinâmico e 365 dias em backup estático.

6.04.07. (b)

Quais provisões existem em caso de roubo das credenciais de um cliente (detecção, revogação, evidência de ações)?

No contexto dos serviços de nuvem da Atlassian, os clientes podem ser responsáveis por alguns ou todos os aspectos do gerenciamento de acesso dos usuários do serviço sob seu controle.

Assim, a Atlassian permite que os clientes gerenciem o acesso dos usuários do serviço sob o controle do cliente do serviço, por exemplo, oferecendo direitos administrativos para gerenciar ou encerrar o acesso. A Atlassian também verifica as credenciais dos clientes em relação aos bancos de dados de credenciais vazados e força os usuários a atualizarem suas senhas.

A Atlassian não oferece Prevenção de Perda de Dados (DLP) como parte das implementações do Cloud. No entanto, existem fornecedores no Atlassian Marketplace, como o Nightfall, que a Atlassian recomenda para clientes que querem ter essa capacidade de DLP. Veja a página do produto Marketplace para Nightfall aqui: https://marketplace.atlassian.com/vendors/1217783/nightfall. O Nightfall inclui a verificação automática de informações confidenciais, incluindo credenciais, segredos e chaves de API.

A Atlassian lançou o Beacon, que está em versão beta e adiciona funções de DLP. Até o Beacon ser lançado da versão beta, a Atlassian ainda recomenda o Nightfall. Veja mais informações sobre o Atlassian Beacon em: https://www.atlassian.com/software/beacon.

Há uma Política e um Plano de Resposta a Incidentes de Segurança documentados, cujos princípios fundamentais incluem:

• antecipação de incidentes de segurança e preparação para resposta a incidentes
• contenção, erradicação e recuperação de incidentes
• investimento em pessoas, processos e tecnologias para garantir a capacidade de detecção e análise de incidentes quando eles ocorrerem
• tornar a proteção dos dados pessoais e de clientes a principal prioridade durante incidentes de segurança
• utilização regular do processo de resposta a incidentes de segurança
• aprender e melhorar a função de gerenciamento de incidentes de segurança
• comunicar incidentes críticos de segurança ao grupo de liderança da Atlassian

6.04.08.

As perguntas a seguir se aplicam aos sistemas de gerenciamento de identidade e acesso oferecidos pelo provedor de nuvem para uso e controle pelo cliente da nuvem.

6.04.08.01. (a)

O sistema permite uma infraestrutura de IDM federada que seja interoperável tanto para alta garantia (sistemas OTP, quando necessário) quanto para baixa garantia (por exemplo, nome de usuário e senha)?

O Atlassian Access suporta os padrões de federação de identidade em todos os produtos Atlassian (Confluence, Jira, Jira Align, Bitbucket etc.). O Atlassian Access é capaz de fazer a sincronização automática do Active Directory à Atlassian com o Okta, o Azure AD ou o OneLogin. Para obter mais informações, consulte: https://www.atlassian.com/enterprise/cloud/access. Configuração de SSO de produto específico (SAML genérico v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• O Opsgenie oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• O Trello oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• O Statuspage oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

O provedor de nuvem é interoperável com provedores de identidade terceirizados?

Os clientes da Atlassian podem usar o provedor de identidade terceirizado escolhido se for compatível com a Atlassian. Uma página de Suporte da Atlassian detalha essas funções e como conectar ao provedor de identidade escolhido. Consulte: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Existe a capacidade de incorporar o login único?

A Atlassian suporta o uso das identificações do Google, Microsoft e Apple para autenticação na maioria dos produtos. A gente também oferece suporte ao SAML para os serviços de nuvem da Atlassian por meio do Atlassian Access. Veja: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

O sistema de credenciais do cliente permite a separação de funções e responsabilidades e de vários domínios (ou uma única chave para vários domínios, funções e responsabilidades)?

A Atlassian é um aplicativo SaaS de múltiplos locatários. A multilocação é uma função fundamental do Atlassian Cloud. Ela permite que vários clientes compartilhem uma instância da camada de aplicativos Jira ou Confluence, isolando os dados do aplicativo de cada locatário do cliente. O Atlassian Cloud faz isso por meio do Serviço de Contexto do Locatário (TCS). Cada ID de usuário é associado apenas a um locatário, que é usado para acessar os aplicativos Atlassian Cloud. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Os clientes das ofertas Enterprise e Premium Cloud têm acesso a um painel de controle administrativo centralizado. Os administradores da organização podem gerenciar o acesso e as permissões dos usuários em todas as instâncias do produto. Confira o blog aqui: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

A Atlassian oferece aos clientes a função de “administrador da organização”, que administra usuários e grupos dos produtos do cliente. Para mais informações, consulte: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Como você gerencia o acesso às imagens do sistema do cliente e garante que as chaves criptográficas e de autenticação não estejam contidas nelas?

A equipe de suporte global mantém uma conta em todos os sistemas e aplicativos hospedados para fins de manutenção e suporte. Essa equipe de suporte acessa aplicativos e dados hospedados apenas 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.

6.04.08.03. (a)

Como o provedor de nuvem se identifica para o cliente (ou seja, há autenticação mútua)?

• Quando o cliente envia comandos de API?
• Quando o cliente faz login na interface de gerenciamento?

A Atlassian utiliza autenticação mútua para se identificar perante o cliente. A documentação da API Atlassian pode ser encontrada em: https://developer.atlassian.com/cloud/. O Atlassian Service Authentication Protocol (ASAP) é um protocolo de autenticação de serviço a serviço que utiliza um token de acesso implementado usando o JSON Web Token (JWT) e assinado usando chaves RSA de uma autoridade confiável da Atlassian. Para saber mais, consulte o Protocolo de Autenticação de Serviços Atlassian. Não são usadas as noções tradicionais de “contas de serviço”, a gente confia na autenticação e autorização de serviço a serviço.

6.04.08.03. (b)

Sua autenticação é compatível com mecanismos federados?

O Atlassian Access suporta os padrões de federação de identidade em todos os produtos Atlassian (Confluence, Jira, Jira Align, Bitbucket etc.). O Atlassian Access é capaz de fazer a sincronização automática do Active Directory à Atlassian com o Okta, o Azure AD ou o OneLogin. Para obter mais informações, consulte: https://www.atlassian.com/enterprise/cloud/access. Configuração de SSO de produto específico (SAML genérico v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• O Opsgenie oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• O Trello oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• O Statuspage oferece suporte a vários provedores de SSO. Para obter mais informações, consulte: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

É importante garantir que o provedor mantenha atualizada a lista de recursos de hardware e software (aplicativos) sob o controle do provedor de nuvem. Assim, é possível verificar se todos os sistemas têm controles adequados e se não servem como porta de entrada para a infraestrutura.

6.05. (a)

O provedor faz o inventário de todos os recursos por algum meio automático, facilitando a gestão adequada deles?

Os sistemas de produção estão localizados em infraestruturas oferecidas por provedores de serviços na nuvem. Esses sistemas não são monitorados em nível de hardware devido à natureza do serviço. Os microsserviços subjacentes em que os produtos são executados são monitorados no banco de dados de "Serviço" personalizado. Esse banco de dados passa por atualização automática quando um serviço é implementado.

A equipe de tecnologia do local de trabalho mantém os recursos de todos os terminais em inventário e faz seu monitoramento com o Jira Software.

6.05. (b)

O cliente usou uma lista de recursos no período específico?

A Atlassian é um aplicativo SaaS de múltiplos locatários. A multilocação é uma função fundamental do Atlassian Cloud. Ela permite que vários clientes compartilhem uma instância da camada de aplicativos Jira ou Confluence, isolando os dados do aplicativo de cada locatário do cliente. O Atlassian Cloud faz isso por meio do Serviço de Contexto do Locatário (TCS). Cada ID de usuário é associado apenas a um locatário, que é usado para acessar os aplicativos Atlassian Cloud. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

As perguntas a seguir devem ser usadas quando o cliente final implementar os dados que exigem proteção adicional (por exemplo, considerados sensíveis).

6.05. (c)

Os recursos são classificados com relação à sensibilidade e ao nível crítico?

• Se sim, o provedor emprega a segregação adequada entre sistemas com classificações diferentes e para um único cliente que tem sistemas com classificações de segurança diferentes?

A Atlassian classifica os recursos e serviços em quatro níveis, os quais têm requisitos próprios de disponibilidade, nível de serviço e continuidade. Para mais informações, consulte: https://www.atlassian.com/trust/security/data-management.

6.06.

Esse conjunto de perguntas servem para entender os riscos envolvidos em parcerias com fornecedores.

6.06. (a)

Existem procedimentos e APIs documentados para exportar dados da nuvem?

Os dados do cliente estão disponíveis por meio do aplicativo Web e da API. As informações sobre produtos específicos estão abaixo.

• Confluence, Jira e Jira Align: saiba mais informações sobre a API Atlassian em: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: os dados do quadro estão disponíveis para exportação pelos membros do conselho no formato JSON por meio da API REST do Trello. Os anexos de arquivos podem ser recuperados separados direto do Amazon S3 usando o hiperlink exclusivo do arquivo. As edições Trello Business Class e Enterprise simplificam a exportação de todos os dados e anexos para empresas. Cada empresa Business Class e Enterprise exporta com um clique todos seus Quadros. Como opção, anexos de arquivo enviados direto para o Trello podem ser incluídos no arquivo de exportação. Na exportação, os dados de cada quadro são incluídos no formato JSON e Valores Separados por Vírgula (“CSV”).
• Opsgenie: a API pode ser encontrada em: https://docs.opsgenie.com/docs/api-overview
• Statuspage: a API pode ser encontrada em: https://doers.statuspage.io/api/v1/
• Bitbucket: qualquer código-fonte ou repositório pode ser baixado ou exportado do Bitbucket para fins de interoperabilidade. Consulte: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: tem a função de exportação de CSV. Você pode ler mais da documentação aqui: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

O fornecedor oferece formatos de exportação interoperáveis para todos os dados armazenados na nuvem?

A Atlassian facilita para os clientes a exportação de dados hospedados em seus produtos. Ferramentas completas de gestão e portabilidade de dados estão disponíveis para exportar dados do usuário e do produto. Para mais informações sobre a exportação de dados do Atlassian Cloud, consulte a documentação de importação e exportação aqui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Além disso, consulte: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para saber mais sobre a exportação de dados em formatos comuns, como CSV, HTML e XML.

6.06. (c)

No caso de o SaaS, as interfaces de API usadas são padronizadas?

Saiba mais informações sobre as APIs Atlassian Cloud em: https://developer.atlassian.com/explore-the-apis/

Informações sobre produtos específicos de API:

• Trello: a documentação da API está disponível em: https://developer.atlassian.com/cloud/trello
• Jira Align: a API pode ser encontrada em: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: a API pode ser encontrada em: https://doers.statuspage.io/api/v1
• Opsgenie: a API pode ser encontrada em: https://docs.opsgenie.com/docs/api-overview
• Halp: não tem uma API pública no momento.

6.06. (d)

Há algum método para exportar aplicativos criados pelo usuário em formato padrão?

Isso não se aplica, pois a Atlassian opera um modelo de Software como um serviço (SaaS).

6.06. (e)

Existem processos para testar se os dados podem ser exportados para outro provedor de nuvem, caso o cliente quiser alterar o provedor, por exemplo?

A Atlassian facilita para os clientes a exportação de dados hospedados em seus produtos. Ferramentas completas de gestão e portabilidade de dados estão disponíveis para exportar dados do usuário e do produto. Para mais informações sobre a exportação de dados do Atlassian Cloud, consulte a documentação de importação e exportação aqui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Além disso, consulte: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para saber mais sobre a exportação de dados em formatos comuns, como CSV, HTML e XML.

6.06. (f)

O cliente pode extrair os dados para verificar se o formato é universal e pode ser migrado para outro provedor de nuvem?

A Atlassian facilita para os clientes a exportação de dados hospedados em seus produtos. Ferramentas completas de gestão e portabilidade de dados estão disponíveis para exportar dados do usuário e do produto. Para mais informações sobre a exportação de dados do Atlassian Cloud, consulte a documentação de importação e exportação aqui: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Além disso, consulte: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/ para saber mais sobre a exportação de dados em formatos comuns, como CSV, HTML e XML.

6.07.

Oferecer continuidade é importante para empresas. Embora seja possível definir contratos de nível de serviço especificando o tempo mínimo de disponibilidade dos sistemas, ainda existem várias considerações adicionais.

6.07. (a)

O provedor tem o método e as informações sobre o impacto de interrupções documentadas?

• O que são RPO (objetivo de ponto de recuperação) e RTO (objetivo de tempo de recuperação) para serviços? Dê informações conforme com o nível crítico do serviço.
• As atividades de segurança da informação são abordadas como devem no processo de restauração?
• Quais são as linhas de comunicação com os clientes finais em caso de interrupção?
• As funções e responsabilidades das equipes foram identificadas com clareza ao lidar com a interrupção?

Uma política de Continuidade de Negócios e Recuperação de Desastres e um Plano de Continuidade de Negócios e Recuperação de Desastres estão em vigor e são revisados todos os anos pelo comitê diretor de Continuidade de Negócios/Recuperação de Desastres. Para mais informações (inclusive em relação a RPOs, RTOs e resiliência por meio do uso de zonas de disponibilidade), consulte: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance/

6.07. (b)

O provedor categorizou a prioridade da recuperação e qual seria a prioridade relativa (o cliente final) a ser restaurada? Nota: esta pode ser uma categoria (HIGH/MED/LOW).

Todos os proprietários de serviço, processos ou sistema crítico para a missão devem garantir que a continuidade de negócios e/ou a recuperação de desastres esteja alinhada com a tolerância para interrupção em caso de desastre. Os planos do BCDR são testados todos os trimestres e os itens identificados são resolvidos. Para mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Quais dependências relevantes para o processo de restauração existem? Inclua provedores e firme parceiras com terceiros.

A Atlassian tem um procedimento e registro dos esforços de restauração de dados. Em alto nível, isso está contido na política interna de Backups Standard e de Continuidade de Negócios e Recuperação de Desastres. No entanto, para cada serviço da Atlassian há vários documentos internos, que incluem runbooks, cronogramas e procedimentos para restaurações iniciados pelo cliente e restaurações iniciadas pela Atlassian.

6.07. (d)

No caso de o site primário ficar indisponível, qual é a separação mínima para a localização do site secundário?

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance/

6.07.01.

O gerenciamento de incidentes e resposta fazem parte do gerenciamento da continuidade dos negócios. O objetivo desse processo é reduzir a um nível aceitável o impacto de eventos inesperados e com potencial disruptivo. Para avaliar como a empresa minimiza essas ocorrências ou reduz o impacto negativo de incidentes de segurança da informação, as seguintes perguntas devem ser feitas ao provedor de nuvem:

6.07.01. (a)

O provedor tem um processo formal para detectar, identificar, analisar e responder a incidentes?

A Atlassian tem a Política e o Plano de Resposta a Incidentes de Segurança documentados, cujos princípios fundamentais incluem:

• antecipação de incidentes de segurança e preparação para resposta a incidentes
• contenção, erradicação e recuperação de incidentes
• investimento em pessoas, processos e tecnologias para garantir a capacidade de detecção e análise de incidentes quando ocorrerem
• tornar a proteção dos dados pessoais e de clientes a principal prioridade durante incidentes de segurança
• utilização regular do processo de resposta a incidentes de segurança
• aprender e melhorar a função de gerenciamento de incidentes de segurança
• comunicar incidentes críticos de segurança ao grupo de liderança da Atlassian


Conforme essa política, a Atlassian mantém um plano de resposta a incidentes de segurança. Para mais informações sobre o processo de resposta a incidentes de segurança, consulte: https://www.atlassian.com/trust/security/security-incident-management

Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são somente para leitura. A equipe de segurança da Atlassian cria alertas na plataforma de análise de segurança (Splunk) e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar itens de disponibilidade ou desempenho. Os logs são retidos por 30 dias em backup dinâmico e 365 dias em backup estático.

Para mais informações sobre o Programa de Detecções, consulte: https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

O processo é testado para verificar se o tratamento de incidentes é eficaz? O provedor de nuvem também garante, durante o teste, que todos na empresa de suporte saibam o processo e as funções do tratamento do incidente (tanto durante o incidente quanto após a análise)?

Para os serviços Atlassian Cloud, os planos de Continuidade de Negócios e Recuperação de Desastres são testados pelo menos todos os trimestres. A disponibilidade em várias regiões é monitorada em tempo real. Testes automatizados de failover regional são feitos todas as semanas no ambiente de pré-produção. Testes automatizados de restauração de dados de configuração são feitos todos os dias na produção. Todos os serviços da Atlassian testam a cada trimestre a resiliência da zona de disponibilidade no ambiente de pré-produção. Para mais informações sobre nosso programa Business Continuity, consulte: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Os planos de Recuperação de Desastres são testados e validados por auditores externos como parte do Programa de Conformidade. Para mais informações, consulte: https://www.atlassian.com/trust/compliance/resources

O plano de resposta a incidentes de segurança foi testado com atividades de incidentes ao vivo. A Atlassian implementa abordagem de melhoria contínua para otimizar a capacidades de resposta.

Depois que um incidente de alta gravidade 1 ou 2 for resolvido, o ticket original do incidente é encerrado e o processo de revisão pós-incidente (PIR) é iniciado. Para incidentes de alta gravidade, a equipe de segurança analisa a causa raiz e propõe possíveis melhorias no sistema e/ou no tratamento do item.

6.07.01. (c)

Como é estruturada a capacidade de detecção?

• Como o cliente da nuvem pode relatar anomalias e eventos de segurança ao provedor?
• Segundo o provedor, em quais instalações os serviços RTSM de terceiros selecionados pelo cliente podem intervir nos sistemas (quando apropriado) ou coordenar a capacidade de resposta a incidentes com o provedor de nuvem?
• Existe um serviço de monitoramento de segurança em tempo real (RTSM) instalado? O serviço é terceirizado? Que tipo de parâmetros e serviços são monitorados?
• São gerados (mediante solicitação) relatórios periódicos sobre incidentes de segurança (por exemplo, de acordo com a estrutura ITIL)?
• Por quanto tempo os registros de segurança são mantidos? Esses registros são armazenados com segurança? Quem tem acesso aos registros?
• É possível que o cliente crie um HIPS/HIDS na imagem da máquina virtual? É possível integrar as informações coletadas pelos sistemas de detecção e prevenção de intrusões do cliente ao serviço de RTSM do provedor de nuvem ou de terceiros?

O Atlassian Cloud Platform tem muito pouca área de superfície exposta pelos firewalls. A gente analisa as regras de firewall de forma periódica. O IDS foi implantado nos escritórios e no ambiente de hospedagem na nuvem. Para a Atlassian Cloud Platform, o encaminhamento de registros se integra a uma plataforma de dados de análise de segurança. No nível do contêiner do Cloud Platform, a integridade do arquivo é mantida, pois as instâncias não podem ser modificadas. A Atlassian Network Engineering usa tecnologias IPS integradas nos firewalls e a gente implementou tecnologias IDS nos ambientes de escritório e nuvem. As funções de DDoS são oferecidos pelo provedor/operadora de serviços de Internet. Para obter mais informações sobre o Programa de Detecções, acesse: https://www.atlassian.com/trust/security/detections-program Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são somente para leitura. A equipe de segurança da Atlassian cria alertas na plataforma de dados de análise de segurança (Splunk) e monitora indicadores de comprometimento. As equipes de SRE usam essa plataforma para monitorar itens de disponibilidade ou desempenho. Os logs são retidos por 30 dias em backup dinâmico e 365 dias em backup estático. A Atlassian restringe a capacidade de visualizar e ler registros de auditoria ao pessoal autorizado em na plataforma de registro centralizada. Também há canais de relatórios externos através dos quais a gente pode tomar conhecimento de vulnerabilidades ou incidentes, incluindo o Programa de Recompensas por Bugs, o portal de suporte ao cliente e números de telefone e caixas de entrada de e-mail de segurança definidos. A Atlassian incentiva os clientes a denunciar qualquer acesso não autorizado ou comportamento mal-intencionado. Para obter mais informações: https://www.atlassian.com/trust/security/security-incident-management e https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Como os níveis de gravidade são definidos?

A Atlassian usa o Common Vulnerability Scoring System (CVSS) como método para avaliar o risco de segurança e a priorização de cada vulnerabilidade descoberta. Os níveis de segurança utilizados são baseados na pontuação CVSS autocalculada da Atlassian, incluindo:

• Crítico;
• Alto;
• Médio;
• Baixo.


Para obter mais informações, incluindo quais faixas de pontuação determinam a gravidade, acesse: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Como os procedimentos de escalonamento são definidos? Quando (caso se aplique) o cliente de nuvem é envolvido?

A Atlassian tem a Política e o Plano de Resposta a Incidentes de Segurança documentados, cujos princípios fundamentais incluem:

• antecipação de incidentes de segurança e preparação para resposta a incidentes
• contenção, erradicação e recuperação de incidentes
• investimento em pessoas, processos e tecnologias para garantir a capacidade de detecção e análise de incidentes quando ocorrerem
• tornar a proteção dos dados pessoais e de clientes a principal prioridade durante incidentes de segurança
• utilização regular do processo de resposta a incidentes de segurança
• aprender e melhorar a função de gerenciamento de incidentes de segurança
• comunicar incidentes críticos de segurança ao grupo de liderança da Atlassian


Conforme essa política, a Atlassian mantém um plano de resposta a incidentes de segurança. Para mais informações sobre o processo de resposta a incidentes de segurança, consulte: https://www.atlassian.com/trust/security/security-incident-management

A Atlassian entende o quanto é importante que você seja notificado na hora de qualquer violação de dados. É por isso que a gente criou uma ampla equipe multifuncional e um processo para lidar com incidentes de segurança, conforme descrito em: https://www.atlassian.com/trust/security/security-incident-management

A Atlassian tem um sólido histórico de notificação oportuna e proativa de incidentes e de trabalhar com os clientes em todas as mitigações necessárias.

Como é fundamental que as equipes de resposta a incidentes de segurança da Atlassian atuem com rapidez na triagem e mitigação de um incidente à medida que ele se desenvolve, a gente não concorda com o cronograma de 72 horas. Em vez disso, os clientes recebem informações “sem demora injustificada”, que seguem a exigência legal do GDPR para processadores de dados, que atende às necessidades legais da maioria dos clientes.

Os incidentes podem variar de simples a muito complexos, portanto, embora seja possível oferecer o que é necessário de acordo com a lei, a gente não concorda com um cronograma “único para todos”.

6.07.01. (f)

Como os incidentes são documentados e as evidências coletadas?

Os tickets do Jira são criados para fins de rastreamento e correção, e as datas de vencimento são atribuídas de acordo com o SLO com base na gravidade e na origem da vulnerabilidade. Há um processo contínuo para emitir tickets de vulnerabilidades identificadas para proprietários de sistemas, e a equipe de gerenciamento de segurança analisa todas as vulnerabilidades relatadas e garante que medidas sejam tomadas contra elas.

Depois que um incidente de alta gravidade 1 ou 2 for resolvido, o ticket original do incidente é encerrado e o processo de revisão pós-incidente (PIR) é iniciado. Para incidentes de alta gravidade, a equipe de segurança analisa a causa raiz e propõe possíveis melhorias no sistema e/ou no tratamento do item.

6.07.01. (g)

Além da autenticação, contabilidade e auditoria, quais outros controles são feitos para evitar (ou minimizar o impacto de) atividades mal-intencionadas de pessoas com informações privilegiadas?

A Atlassian implementou o IDS nos escritórios e no ambiente de hospedagem na nuvem. O encaminhamento de registros se integra a uma plataforma de dados de análise de segurança da Plataforma Atlassian Cloud. Os principais registros do sistema são encaminhados de cada sistema para uma plataforma de registro centralizada, na qual os registros são somente para leitura. A equipe de segurança da Atlassian cria alertas na plataforma de dados de análise de segurança (Splunk) e monitora indicadores de comprometimento. Para obter mais informações sobre o Programa de Detecções, acesse: https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

O provedor utiliza métricas e indicadores de incidentes (ou seja, número de incidentes detectados ou relatados por mês, número de incidentes causados pelos subcontratados do provedor de nuvem e o número total desses incidentes, tempo médio para resposta e resolução, etc.)?

• Quais desses dados o provedor disponibiliza ao público (observação: nem todos os dados de relatórios de incidentes podem ser divulgados, pois isso pode comprometer a confidencialidade do cliente e revelar informações críticas de segurança)?

No momento, as métricas internas da Atlassian não são divulgadas, mas são compartilhadas as ações pós-incidente para incidentes operacionais de Gravidade 0 ou Gravidade 1 na Statuspage, disponível em: https://status.atlassian.com/.

6.07.01. (j)

Com que frequência o provedor testa os planos de recuperação de desastres e continuidade de negócios?

Para os serviços Atlassian Cloud, os planos de Continuidade de Negócios e Recuperação de Desastres são testados pelo menos todos os trimestres. A disponibilidade em várias regiões é monitorada em tempo real. Testes automatizados de failover regional são feitos todas as semanas no ambiente de pré-produção. Testes automatizados de restauração de dados de configuração são feitos todos os dias na produção. Todos os serviços da Atlassian testam a cada trimestre a resiliência da zona de disponibilidade no ambiente de pré-produção. Para mais informações sobre o programa Business Continuity, consulte: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Os planos de Recuperação de Desastres são testados e validados por auditores externos como parte do Programa de Conformidade. Para mais informações, acesse: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

O provedor coleta dados sobre os níveis de satisfação com os SLAs?

A Atlassian monitora o desempenho e a disponibilidade de todas as instâncias do Cloud, porém, no momento, não há um SLA definitivo de disponibilidade para aplicativos. A equipe de suporte disponibiliza um SLA de tempo de resposta inicial e, embora não haja um SLA oficial de resolução para suporte, a meta interna é resolver todos os casos atribuídos à equipe em 48 horas. As estatísticas de status mais recentes do sistema Cloud são exibidas aqui: https:status.atlassian.com.

Garantias de SLA estão disponíveis nas ofertas Premium e Enterprise.

6.07.01. (l)

O provedor faz testes de central de ajuda? Por exemplo:

• Testes de representação (a pessoa do outro lado da linha que está solicitando uma redefinição de senha é de fato quem diz ser?) ou os chamados ataques de “engenharia social”.

A Atlassian oferece treinamento em segurança da informação como parte do treinamento de integração (“Dia 1”) para novos contratados e de forma contínua para todos os funcionários.

Além desse treinamento geral de segurança da informação, um treinamento mais direcionado está disponível para os desenvolvedores sobre codificação segura e é suportado por meio do programa de engenheiros de segurança incorporado.

A gente também oferece treinamento tópico contínuo relacionado a malware, phishing e outras questões de segurança. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

A gente mantém registros formais de conclusão do treinamento interno da equipe. Os funcionários devem reconhecer o Código de Conduta e fazer a reafirmação uma vez por ano. Esta política é oferecida a todos os funcionários. Os requisitos de conscientização sobre segurança, confidencialidade e privacidade são apresentados nos treinamentos de integração e estão disponíveis para todos os funcionários no Confluence.

6.07.01. (m)

O provedor faz testes de intrusão? Com que frequência? O que de fato é testado durante o teste de intrusão – por exemplo, o isolamento de segurança de cada imagem é verificado para garantir que não seja possível “dividir” uma imagem em outra e também obter acesso à infraestrutura do host? Os testes também devem verificar se é possível acessar, através da imagem virtual, os sistemas de gerenciamento e suporte dos provedores de nuvem (por exemplo, os sistemas de provisionamento e controle de acesso do administrador).

A Atlassian tem uma Equipe Vermelha interna que faz operações contínuas de teste de intrusão em toda a infraestrutura, serviços de nuvem e funcionários.

Consultorias terceirizadas são contratadas para fazer testes de intrusão anuais em aplicativos externos. Esses testes são complementados por testes de segurança menores e contínuos feitos pela equipe interna de testes de segurança da Atlassian. As cartas de avaliação dos testes de intrusão podem ser encontradas a seguir, junto com mais informações sobre o processo de testes e a abordagem adotada nos testes de segurança externos, acesse: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

O provedor faz testes de vulnerabilidade? Com que frequência?

A equipe de segurança da Atlassian sempre faz verificações contínuas de vulnerabilidade de rede da infraestrutura interna e externa usando um leitor de vulnerabilidade reconhecido pelo setor. Para obter mais informações sobre o programa de Gerenciamento de Vulnerabilidades, acesse: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Qual é o processo usado para corrigir vulnerabilidades (correções, reconfiguração, atualização para versões posteriores do software, etc.)?

Os tickets do Jira são criados para fins de rastreamento e correção, e as datas de vencimento são atribuídas de acordo com o SLO com base na gravidade e na origem da vulnerabilidade. Há um processo contínuo para emitir tickets de vulnerabilidades identificadas para proprietários de sistemas, e a equipe de gerenciamento de segurança analisa todas as vulnerabilidades relatadas e garante que medidas sejam tomadas contra elas.

Mais informações sobre o programa de Gerenciamento de Vulnerabilidades podem ser encontradas em: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

Assim como acontece com a segurança dos funcionários, muitos dos possíveis itens surgem porque a infraestrutura de TI é gerenciada por terceiros — o mesmo caso da terceirização tradicional, em que o impacto de uma violação de segurança física pode afetar vários clientes (empresas).

6.08. (a)

Quais garantias são oferecidas ao cliente em relação à segurança física do local? Ofereça exemplos e padrões seguidos, por exemplo, Seção 9 da ISO 27001/2.

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.

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.

6.08. (a) (i)

Quem, além da equipe de TI autorizada, tem acesso (físico) não supervisionado à infraestrutura de TI?

• Por exemplo, faxineiros, gerentes, seguranças, prestadores de serviços, consultores, fornecedores, etc.

Os escritórios da Atlassian são orientados pela Política de Segurança Física e Ambiental interna, que inclui o monitoramento de pontos físicos de entrada e saída. A gente publica trechos de todas as operações internas de tecnologia e políticas de segurança em: https://www.atlassian.com/trust/security/ismp-policies

Os escritórios da Atlassian têm controles de acesso, como leitores de crachás e vigilância por câmera, e têm a capacidade de restringir o acesso a horas/dias específicos, conforme necessário. Os registros de acesso aos prédios de escritórios são mantidos pela Administração do Edifício e estão disponíveis para a equipe de experiência no local de trabalho para fins de investigação.

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance

6.08. (a) (ii)

Com que frequência os direitos de acesso são revisados?

• Com que rapidez os direitos de acesso podem ser revogados?

A Atlassian avalia o desempenho e a eficácia do ISMS usando métricas adequadas. O desempenho do Atlassian Trust Management System (ATMS) e dos controles relevantes é monitorado por meio de revisões de auditoria interna e externa. A equipe de conformidade da Atlassian gerencia o cronograma de auditorias internas/auditorias internas de prontidão, assim como o cronograma de auditoria externa (documentados a nível interno na página Roteiros de Auditoria). As auditorias internas se concentram nas áreas de alto risco da Atlassian e são feitas com regularidade de acordo com cronogramas predeterminados e conforme o Cronograma de Auditoria Empresarial acordado entre a Equipe de Risco e Conformidade e a Equipe de Auditoria Interna. No momento, as métricas internas não são divulgadas. O ATMS é avaliado por empresas terceirizadas todo ano e também após qualquer alteração importante. A Atlassian obteve as certificações SOC 2, ISO27001 e ISO7018 para os principais serviços em nuvem. A gente também monitora cada um dos pilares do ATMS por meio de reuniões periódicas de revisão operacional, incluindo métricas específicas para cada um. Isso inclui análises semanais de integridade de conformidade do ATMS e outras reuniões que são documentadas a nível interno na página ATMS: Análise de Integridade de Conformidade e na página Anotações de reunião do ATMS. Para obter mais informações, acesse https://www.atlassian.com/trust/compliance.

Há um programa oficial de gerenciamento de segurança em vigor e o Programa de Gerenciamento de Segurança da Informação (ISMP) é revisado todo ano. Mais informações sobre o Programa de Gerenciamento de Segurança da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

Você avalia os riscos de segurança e os perímetros com frequência?

• Com que frequência?

A Atlassian avalia o desempenho e a eficácia do ISMS usando métricas adequadas. O desempenho do Atlassian Trust Management System (ATMS) e dos controles relevantes é monitorado por meio de revisões de auditoria interna e externa. A equipe de conformidade da Atlassian gerencia o cronograma de auditorias internas/auditorias internas de prontidão, assim como o cronograma de auditoria externa (documentados a nível interno na página Roteiros de Auditoria). As auditorias internas se concentram nas áreas de alto risco da Atlassian e são feitas com regularidade de acordo com cronogramas predeterminados e conforme o Cronograma de Auditoria Empresarial acordado entre a Equipe de Risco e Conformidade e a Equipe de Auditoria Interna. No momento, as métricas internas não são divulgadas. O ATMS é avaliado por empresas terceirizadas todo ano e também após qualquer alteração importante. A Atlassian obteve as certificações SOC 2, ISO27001 e ISO7018 para os principais serviços em nuvem. A gente também monitora cada um dos pilares do ATMS por meio de reuniões periódicas de revisão operacional, incluindo métricas específicas para cada um. Isso inclui análises semanais de integridade de conformidade do ATMS e outras reuniões que são documentadas a nível interno na página ATMS: Análise de Integridade de Conformidade e na página Anotações de reunião do ATMS. Para obter mais informações, acesse https://www.atlassian.com/trust/compliance.

Há um programa oficial de gerenciamento de segurança em vigor e o Programa de Gerenciamento de Segurança da Informação (ISMP) é revisado todo ano. Mais informações sobre o Programa de Gerenciamento de Segurança da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

Você faz avaliações de risco regulares que incluem coisas como edifícios vizinhos?

A Atlassian avalia o desempenho e a eficácia do ISMS usando métricas adequadas. O desempenho do Atlassian Trust Management System (ATMS) e dos controles relevantes é monitorado por meio de revisões de auditoria interna e externa. A equipe de conformidade da Atlassian gerencia o cronograma de auditorias internas/auditorias internas de prontidão, assim como o cronograma de auditoria externa (documentados a nível interno na página Roteiros de Auditoria). As auditorias internas se concentram nas áreas de alto risco da Atlassian e são feitas com regularidade de acordo com cronogramas predeterminados e conforme o Cronograma de Auditoria Empresarial acordado entre a Equipe de Risco e Conformidade e a Equipe de Auditoria Interna. No momento, as métricas internas não são divulgadas. O ATMS é avaliado por empresas terceirizadas todo ano e também após qualquer alteração importante. A Atlassian obteve as certificações SOC 2, ISO27001 e ISO7018 para os principais serviços em nuvem. A gente também monitora cada um dos pilares do ATMS por meio de reuniões periódicas de revisão operacional, incluindo métricas específicas para cada um. Isso inclui análises semanais de integridade de conformidade do ATMS e outras reuniões que são documentadas a nível interno na página ATMS: Análise de Integridade de Conformidade e na página Anotações de reunião do ATMS. Para obter mais informações, acesse https://www.atlassian.com/trust/compliance.

Há um programa oficial de gerenciamento de segurança em vigor e o Programa de Gerenciamento de Segurança da Informação (ISMP) é revisado todo ano. Mais informações sobre o Programa de Gerenciamento de Segurança da Atlassian podem ser encontradas em: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

Você controla ou monitora o pessoal (incluindo terceiros) que acessa áreas seguras?

Os escritórios da Atlassian são orientados pela Política de Segurança Física e Ambiental interna, que inclui o monitoramento de pontos físicos de entrada e saída. A gente publica trechos de todas as operações internas de tecnologia e políticas de segurança em: https://www.atlassian.com/trust/security/ismp-policies

Os escritórios da Atlassian têm controles de acesso, como leitores de crachás e vigilância por câmera, e têm a capacidade de restringir o acesso a horas/dias específicos, conforme necessário. Os registros de acesso aos prédios de escritórios são mantidos pela Administração do Edifício e estão disponíveis para a equipe de experiência no local de trabalho para fins de investigação.

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance

6.08. (a) (vi)

Quais políticas ou procedimentos você tem para carregar, descarregar e instalar equipamentos?

Nas instalações do escritório da Atlassian, as docas de carga estão isoladas das áreas de trabalho e são monitoradas por CFTV e pela equipe do prédio em todos os momentos. Os parceiros de hospedagem de data center gerenciam a segurança física. A gente confia nas certificações de conformidade dos parceiros para comprovar que os controles estão vigentes.

6.08. (a) (vii)

As entregas são inspecionadas quanto a riscos antes da instalação?

Nas instalações do escritório da Atlassian, as docas de carga estão isoladas das áreas de trabalho e são monitoradas por CFTV e pela equipe do prédio em todos os momentos. Os parceiros de hospedagem de data center gerenciam a segurança física. A gente confia nas certificações de conformidade dos parceiros para comprovar que os controles estão vigentes.

6.08. (a) (viii)

Há um inventário físico atualizado dos itens no data center?

Um trecho da Política de Gestão de Recursos está disponível em https://www.atlassian.com/trust/security/ismp-policies. A Atlassian mantém um inventário de todos os recursos de produção junto com os proprietários dos recursos. Todos os sistemas estão localizados em data centers baseados na AWS. Os sistemas na AWS não são monitorados em nível de hardware devido à natureza do serviço.

Todos os microsserviços são rastreados em um banco de dados de serviços personalizado, que é atualizado à medida que qualquer serviço é implantado. A equipe de tecnologia do local de trabalho (WPT) mantém os recursos de todos os terminais em inventário e usa o Jira Software para monitoramento.

Todos os microsserviços são categorizados em níveis, que têm expectativas de tempo de atividade, disponibilidade e RTO e RPO associadas a cada nível. Para mais informações, consulte: https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

Os cabos de rede passam pelas áreas de acesso público?

• Você usa cabos ou conduítes blindados?

Os escritórios da Atlassian são orientados pela Política de Segurança Física e Ambiental interna, que inclui o monitoramento de pontos físicos de entrada e saída. A gente publica trechos de todas as operações internas de tecnologia e políticas de segurança em: https://www.atlassian.com/trust/security/ismp-policies

Os escritórios da Atlassian têm controles de acesso, como leitores de crachás e vigilância por câmera, e têm a capacidade de restringir o acesso a horas/dias específicos, conforme necessário. Os registros de acesso aos prédios de escritórios são mantidos pela Administração do Edifício e estão disponíveis para a equipe de experiência no local de trabalho para fins de investigação.

6.08. (a) (x)

Você examina as instalações com regularidade para procurar equipamentos não autorizados?

Um trecho da Política de Gestão de Recursos está disponível em https://www.atlassian.com/trust/security/ismp-policies. A Atlassian mantém um inventário de todos os recursos de produção junto com os proprietários dos recursos. Todos os sistemas estão localizados em data centers baseados na AWS. Os sistemas na AWS não são monitorados em nível de hardware devido à natureza do serviço.

Todos os microsserviços são rastreados em um banco de dados de serviços personalizado, que é atualizado à medida que qualquer serviço é implantado. A equipe de tecnologia do local de trabalho (WPT) mantém os recursos de todos os terminais em inventário e usa o Jira Software para monitoramento.

6.08. (a) (xi)

Existe algum equipamento externo?

• Como ele é protegido?

Um trecho da Política de Gestão de Recursos está disponível em https://www.atlassian.com/trust/security/ismp-policies. A Atlassian mantém um inventário de todos os recursos de produção junto com os proprietários dos recursos. Todos os sistemas estão localizados em data centers baseados na AWS. Os sistemas na AWS não são monitorados em nível de hardware devido à natureza do serviço.

Todos os microsserviços são rastreados em um banco de dados de serviços personalizado, que é atualizado à medida que qualquer serviço é implantado. A equipe de tecnologia do local de trabalho (WPT) mantém os recursos de todos os terminais em inventário e usa o Jira Software para monitoramento.

6.08. (a) (xii)

Os funcionários usam equipamento portátil (por exemplo, laptops, smartphones) que pode dar acesso ao data center?

• Como eles são protegidos?

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance/

Membros autorizados e treinados das equipes de engenharia da Atlassian que passaram por verificações de antecedentes se autenticam na VPN usando senhas fortes exclusivas e autenticação de dois fatores baseada em TOTP. Em seguida, acessam o ambiente de produção apenas por meio de conexões de terminal ssh usando certificados RSA pessoais protegidos por senha. Um sistema IDS está instalado em todos os servidores de produção, o que inclui monitoramento e alerta em tempo real sobre quaisquer alterações nos arquivos ou configurações do sistema de produção e eventos de segurança anômalos. Para os membros autorizados e treinados da equipe de operações com acesso ao sistema de produção, todas as estações de trabalho que executam o Windows ou OS X usadas para acessar o terminal ssh ao ambiente de produção devem estar executando um software antivírus atual e ativo. Os dados do cliente não são replicados nas estações de trabalho ou dispositivos móveis dos funcionários.

6.08. (a) (xiii)

Quais medidas estão em vigor para controlar os cartões de acesso?

Os escritórios da Atlassian são orientados pela Política de Segurança Física e Ambiental interna, que inclui o monitoramento de pontos físicos de entrada e saída. A gente publica trechos de todas as operações internas de tecnologia e políticas de segurança em: https://www.atlassian.com/trust/security/ismp-policies

Os escritórios da Atlassian têm controles de acesso, como leitores de crachás e vigilância por câmera, e têm a capacidade de restringir o acesso a horas/dias específicos, conforme necessário. Os registros de acesso aos prédios de escritórios são mantidos pela Administração do Edifício e estão disponíveis para a equipe de experiência no local de trabalho para fins de investigação.

6.08. (a) (xiv)

Quais processos ou procedimentos estão em vigor para destruir mídias ou sistemas antigos quando necessário?

• dados sobrescritos?
• destruição física?

A equipe de tecnologia do local de trabalho cuida desse processo. Ela faz a limpeza e desmagnetização adequadas do equipamento. A gente não gerencia nenhuma mídia física que ofereça suporte aos produtos e serviços de nuvem da Atlassian.

6.08. (a) (xv)

Quais processos de autorização estão em vigor para a movimentação de equipamentos de um local para outro?

• Como você identifica funcionários (ou prestadores de serviços) autorizados a fazer isso?

Os parceiros de hospedagem de data centers da Atlassian (AWS) gerenciam a segurança física, e a gente confia no SOC2 deles para comprovam que os controles estão vigentes.

Os produtos Atlassian Cloud não movem os dados do cliente de um ponto físico a outro. A destruição ou limpeza dos discos rígidos com dados do cliente é feita antes que eles sejam retirados dos data centers protegidos da AWS. Em sistemas hospedados na AWS, os dados podem ser movidos entre regiões em um cenário de redundância, mas vão permanecer dentro da AWS. Para ver mais informações sobre as regiões da AWS, consulte: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvi)

Com que frequência são feitas auditorias para monitorar a remoção não autorizada de equipamentos?

Os parceiros de hospedagem de data centers da Atlassian (AWS) gerenciam a segurança física, e a gente confia no SOC2 deles para comprovam que os controles estão vigentes.

Os produtos Atlassian Cloud não movem os dados do cliente de um ponto físico a outro. A destruição ou limpeza dos discos rígidos com dados do cliente é feita antes que eles sejam retirados dos data centers protegidos da AWS. Em sistemas hospedados na AWS, os dados podem ser movidos entre regiões em um cenário de redundância, mas vão permanecer dentro da AWS. Para ver mais informações sobre as regiões da AWS, consulte: https://www.atlassian.com/trust/reliability/infrastructure.

6.08. (a) (xvii)

Com que frequência são feitas verificações para garantir que o ambiente esteja em conformidade com os requisitos legais e regulamentares apropriados?

As equipes jurídica e de conformidade da Atlassian monitoram nossas obrigações regulatórias. Consulte https://www.atlassian.com/legal/ para conhecer o Programa Jurídico. Mais informações sobre o programa de conformidade podem ser encontradas em: https://www.atlassian.com/trust/compliance.

6.09. (a)

Que procedimentos ou políticas estão em vigor para garantir que problemas ambientais não causem uma interrupção no serviço?

Os escritórios da Atlassian são orientados pela Política de Segurança Física e Ambiental interna, que inclui o monitoramento de pontos físicos de entrada e saída.

Os data centers parceiros mantêm várias certificações de conformidade. Essas certificações abrangem a segurança física, a disponibilidade do sistema, o acesso à rede e ao backbone de IP, o provisionamento de clientes e o gerenciamento de problemas. O acesso aos data centers é limitado ao pessoal autorizado e verificado por medidas biométricas de verificação de identidade. As medidas de segurança física incluem: guardas de segurança no local, monitoramento por circuito fechado de TV, sensores de invasão e outras medidas de proteção contra invasões. As informações de garantia de proteção física da AWS podem ser encontradas em: http://aws.amazon.com/compliance/

Uma política de continuidade de negócios e recuperação de desastres e um plano de continuidade de negócios e recuperação de desastres estão em vigor e são revisados a cada ano pelo comitê diretor de continuidade de negócios/recuperação de desastres. Todos os proprietários de serviço, processos ou sistema crítico para a missão devem garantir que a continuidade de negócios e/ou a recuperação de desastres esteja alinhada com a tolerância para interrupção em caso de desastre. Os planos do BCDR são testados todos os trimestres e os itens identificados são resolvidos. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management e https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Quais métodos você usa para evitar danos causados por incêndio, inundação, terremoto etc.?

• Em caso de desastre, que outras medidas de segurança são implementadas para proteger o acesso físico?
• Tanto nos locais primários quanto nos secundários?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (c)

A temperatura e a umidade são monitoradas no data center?

• Considerações ou monitoramento do ar-condicionado?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (d)

Os edifícios têm proteção contra raios?

• Inclusive as linhas elétricas e de comunicação?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (e)

Há geradores autônomos em caso de falha de energia?

• Por quanto tempo eles podem funcionar?
• Há suprimentos de combustível adequados?
• Existem geradores de failover?
• Com que frequência você verifica o equipamento da UPS?
• Com que frequência você verifica os geradores?
• Você tem vários fornecedores de energia?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (f)

Todas as concessionárias (eletricidade, água etc.) conseguem lidar bem com as condições climáticas?

• Com que frequência isso é reavaliado e testado?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (g)

O ar-condicionado que você usa tem capacidade para dar suporte ao seu ambiente?

• Com que frequência ele é testado?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (h)

Você segue os cronogramas de manutenção recomendados pelos fabricantes?

A Atlassian confia que os parceiros de hospedagem de dados comprovem os controles ambientais e de segurança dos próprios data centers. Para a AWS, consulte https://aws.amazon.com/compliance/programs.

6.09. (i)

Você só permite que funcionários autorizados de manutenção ou reparo entrem no local?

• Como você verifica a identidade deles?

O acesso físico às instalações do escritório é protegido por acesso por crachá eletrônico, recepção em horário comercial com login obrigatório para visitantes e CFTV em todos os pontos de entrada e saída do prédio. As docas de carga são monitoradas por CFTV e funcionários do prédio em todos os momentos. Os parceiros de hospedagem de data center gerenciam a segurança física. A gente confia nas certificações de conformidade dos parceiros para comprovar que os controles estão vigentes.

6.09. (j)

Quando o equipamento é enviado para reparo, os dados são limpos primeiro?

• Como isso é feito?

A equipe de tecnologia do local de trabalho cuida desse processo. Ela faz a limpeza e desmagnetização adequadas do equipamento. A gente não gerencia nenhuma mídia física que ofereça suporte aos produtos e serviços de nuvem da Atlassian.

6.10.

Os clientes e possíveis clientes de serviços de provedores de nuvem devem levar em conta as respectivas obrigações nacionais e supranacionais de conformidade com as estruturas regulatórias e garantir o cumprimento adequado de tais obrigações.

As principais perguntas jurídicas que o cliente deve fazer ao provedor de nuvem são:

6.10. (a)

Em que país o provedor de nuvem está localizado?

A Atlassian tem 12 escritórios em 8 locais, incluindo Sydney, Amsterdã, Ancara, Boston, Bangalore, São Francisco, Mountain View, Austin (Texas), Nova York, Manila, Gdansk e Japão. Para obter mais informações, consulte: https://www.atlassian.com/company/contact.

6.10. (b)

A infraestrutura do provedor de nuvem está localizada no mesmo país ou em países diferentes?

Para o Atlassian Cloud, no momento a gente está hospedado em zonas de disponibilidade redundantes da AWS. Para obter informações sobre regiões específicas, consulte: https://www.atlassian.com/trust/reliability/infrastructure.

6.10. (c)

O provedor de nuvem vai usar outras empresas com infraestrutura localizada fora do provedor de nuvem?

Os produtos e dados em nuvem da Atlassian são hospedados na provedora de hospedagem em nuvem líder do setor, a Amazon Web Services (AWS). Os produtos da Atlassian são executados em um ambiente de plataforma como serviço (PaaS) que é dividido em dois conjuntos principais de infraestrutura, chamados de "micros" e "não micros". Jira, Confluence, Statuspage, Access e Bitbucket são executados na plataforma micros, enquanto Opsgenie e Trello são executados na plataforma não micros.

6.10. (d)

Onde vai ser a localização física dos dados?

A Atlassian usa a Amazon Web Services (AWS) nas regiões leste e oeste dos EUA, Irlanda, Frankfurt, Singapura e Sydney (Confluence e Jira).

Informações específicas do produto:

• Trello: disponível na AWS do Leste dos EUA (Ohio).
• Jira Align: a localização física dos dados do cliente pode ser solicitada por meio da solicitação de um ticket de suporte. Consulte: https://support.atlassian.com/jira-align/.
• Statuspage: disponível nas regiões Oeste dos EUA (Oregon, Califórnia) e Leste dos EUA (Ohio) da AWS.
• Opsgenie: tem contas da AWS nos EUA e na Europa. O cliente deve optar pela AWS dos EUA (Oregon, Califórnia) ou UE (Frankfurt) ao se inscrever.
• Halp: hospedado na AWS nas regiões Leste dos EUA-2 e Oeste dos EUA-2.
• Bitbucket: os repositórios e as principais funções do aplicativo são hospedados na AWS do Leste e Oeste dos EUA.


Para obter mais informações sobre residência de dados, consulte: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

A jurisdição sobre os termos do contrato e sobre os dados vai ser dividida?

A legislação padrão que rege o Contrato do Cliente Atlassian é a legislação da Califórnia. Entre em contato com a equipe de vendas Enterprise para receber mais informações.

6.10. (f)

Algum dos serviços do provedor de nuvem vai ser subcontratado?

A Atlassian trabalha com subcontratados terceirizados para oferecer sites, desenvolvimento de aplicativos, hospedagem, manutenção, backup, armazenamento, infraestrutura virtual, processamento de pagamentos, análise e outros serviços. Esses provedores de serviços podem ter acesso ou processar PII com a finalidade de oferecer esses serviços para a gente.

A Atlassian informa, por meio de notificação aos clientes relevantes, o uso de subcontratados que possam processar as próprias PII antes que o processamento ocorra. Uma lista externa de subcontratados com os quais a Atlassian trabalha é apresentada na página de subcontratados da Atlassian em: https://www.atlassian.com/legal/sub-processors. Nesta página, os visitantes são convidados a assinar um feed RSS para serem notificados quando a gente adicionar novos subcontratados da Atlassian.

6.10. (g)

Algum dos serviços do provedor de nuvem vai ser terceirizado?

Quando a Atlassian contrata fornecedores terceirizados, ela tem a intenção de garantir que esses contratos não comprometam de forma alguma os clientes ou os dados deles. Os departamentos jurídico e de compras da Atlassian analisam contratos, SLAs e políticas internas do fornecedor para determinar se o fornecedor atende aos requisitos de segurança, disponibilidade e confidencialidade. Para obter mais informações, consulte: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

Como os dados informados pelo cliente e pelos clientes do cliente vão ser coletados, processados e transferidos?

A Atlassian processa informações em compatibilidade com os propósitos para os quais elas foram coletadas ou autorizadas pelo indivíduo e, em especial, de acordo com a Política de Privacidade Externa da Atlassian.

A privacidade do usuário é importante para a Atlassian, assim como manter a transparência sobre como a gente coleta, usa e compartilha informações sobre os usuários. Para obter mais informações, consulte a página "Privacidade na Atlassian" como parte do Atlassian Trust Center em https://www.atlassian.com/trust/privacy e a Política de Privacidade em https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

O que acontece com os dados enviados ao provedor de nuvem após a rescisão do contrato?

A Atlassian mantém um padrão de Retenção e Destruição de Dados, que designa por quanto tempo a gente precisa manter diferentes tipos de dados. Os dados são classificados de acordo com a Política de Ciclo de Vida de Informações e Segurança de Dados da Atlassian, e os controles são implementados com base nisso. Para dados de clientes, após a rescisão do contrato com a Atlassian, os dados pertencentes à equipe do cliente vão ser removidos do banco de dados de produção ativo e todos os anexos de arquivos enviados para a Atlassian vão ser removidos em 14 dias. Os dados da equipe vão permanecer em backups criptografados até que esses backups saiam da janela de retenção de backup de 90 dias e sejam destruídos de acordo com a política de retenção de dados da Atlassian. Caso uma restauração do banco de dados seja necessária dentro de 90 dias após a solicitação de exclusão de dados, a equipe de operações vai excluir de novo os dados assim que for possível após a restauração completa do sistema de produção ativo. Para obter mais informações, consulte: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/