Política de segurança
Política de segurança

A BlueShift conta com sua estrutura de governança conforme quadro abaixo. Esta estrutura tem por objetivo:
• Foco em expertise técnico;
• Agilidade no atendimento aos nossos clientes;
• Comitês ligados à presidência para evitar desvios de conduta e riscos de segurança em nossas operações.

Especificamente relacionada à questão de segurança da informação, contamos com gestor, equipe própria e comitê especifico do tema, para que as definições sejam rapidamente disseminadas e adotadas por toda organização.

A Blueshift conta com política de segurança da informação (aderente a ISO27001 e a PCI-DSS), manual de desenvolvimento seguro (aderente às boas práticas da OWASP), o que nos habilita a prestar serviços ao Banco Santander e Banco do Brasil.

A Blueshift não desenvolve sistemas em seu ambiente próprio, desenvolvemos projetos em nuvens públicas (Microsoft Azure, Google Cloud, AWS, Huawei Cloud) ou no ambiente do cliente.

Quando desenvolvendo em cloud, adotamos as melhores pratica de segurança e o provedor geralmente detém todas as certificações exigidas (por exemplo, certificações Microsoft: https://azure.microsoft.com/pt-br/overview/trusted-cloud/compliance/)

Quando desenvolvemos no site do cliente aderimos as regras de segurança e boas práticas definidas pelo cliente. Sempre sugerimos itens que possam reforçar as regras já previstas pelo cliente.

Sobre o monitoramento de segurança de informações e capacidade de detecção de ameaças, incluindo a tecnologia e os processos em vigor para detectar eventos de Segurança, a Blueshift desenvolve em cloud ou no ambiente do cliente, portanto, não desenvolvemos artefatos em ambiente próprio. Assim, adotamos os recursos de monitoramento de segurança e detecção disponibilizado pelo provedor de cloud ou pelo ambiente provido por nossos clientes.

Por exemplo, quando desenvolvemos em cloud Microsoft Azure utilizamos o ATP (proteção avançada contra ameaças), vide documento: https://docs.microsoft.com/pt-br/azure/security/fundamentals/threat-detection .

Os testes de detecção de ameaças, desta forma, são realizados pelo provedor do cloud ou pelo cliente onde o projeto é realizado. Como exemplo, caso o projeto será desenvolvido em Microsoft Azure há diversas ferramentas providas pelo provedor do cloud: https://azure.microsoft.com/pt-br/blog/integrated-vulnerability-assessment-with-azure-security-center/

Durante o desenvolvimento do sistema, em cloud ou no ambiente do cliente, adotamos as práticas de desenvolvimento seguro preconizadas pelo OWASP. Adicionalmente, nosso processo contempla:

• Modelo de teste em “V”

• Revisão por pares.

• Elaboração de GMUDs para avaliar impactos em outros sistemas e, com aprovação, programar a entrada em produção / failback.

Em nosso processo de onboarding de consultores avaliamos antecedentes criminais, existência de negativações, praticas anticorrupção e conhecimento sobre lavagem de dinheiro. Após este check inicial, solicitamos acesso ao ambiente cloud (da subscrição do cliente) ou ao ambiente de desenvolvimento on-premises (provido pelo cliente) ao time alocado ao projeto e com direitos de acesso conforme requisitos do escopo de desenvolvimento.

O acesso físico e lógico ao final das atividades ou se houver desligamento é retirado previamente, evitando eventuais riscos.

Todos os nossos consultores assinam NDA e código de conduta para atuar em nossos projetos.

A Blueshift não terceiriza nenhuma etapa do ciclo de desenvolvimento e acompanha as certificações e status de auditoria dos provedores de cloud. Como exemplo, avaliamos recorrentemente se alguma certificação é perdida ou mantida pelo provedor: https://azure.microsoft.com/pt-br/overview/trusted-cloud/compliance/ .

Nossos consultores ao ingressar na BlueShift e recorrentemente são treinados sobre práticas de desenvolvimento seguro, segurança da informação, praticas anticorrupção, lavagem de dinheiro e sigilo das informações.

A BlueShift em virtude de desenvolver no ambiente provido pelo cliente, tanto on premises quanto cloud, e por não reter dados em seu ambiente não tem em sua estrutura a figura do DPO (“data protection officer’). Este papel é provido pelo time ou área especifica do cliente que demandou o projeto.

Ademais, temos conhecimento dos requisitos da GDPR / LGPD para implementar medidas e processos que assegurem a proteção de dados. Ressaltamos, contudo, que não desenvolvemos nenhum artefato ou retemos dados em nosso ambiente, desenvolvemos em ambiente Cloud (subscrição do cliente) ou on premisses (ambiente do cliente).