Falando de arquitetura e ambientes...

Índice

...

...

O Identity é uma aplicação 100% SaaS cujo ambiente de produção está hospedado na nuvem brasileira da AWS (Amazon Web Services), a maior plataforma de computação em nuvem do mundo. O serviço de hospedagem segue as principais certificações de segurança, como PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS 140-2 e NIST 800-171, o que nos ajuda a atender aos requisitos de conformidade em todo o mundo.

Esta estrutura garante vários benefícios tanto para a aplicação quanto para o cliente, entre eles:

...

• Monitoramento do ambiente por uma equipe DevOps especializada.;
• Backups diários;
• Controle de versão da aplicação;
• Processo de recuperação automática;
• Registro das atividades.

Essas ações também ajudam a preservar a segurança e a disponibilidade do serviço durante os procedimentos de atualização da aplicação.

Atualização de Arquitetura

Tratativas de segurança

Além dos itens mencionados acima, o Identity conta com as seguintes ferramentas de segurança:

• Tratamentos para ataques de força bruta;
• Rede de distribuição de conteúdo (CDN);
• Firewall com configuração de rate limit, reputação de IPs e outros bloqueios;
• Todos os servidores em rede privada (não expostos para a internet);
• Regras de bloqueio disponibilizadas pela própria AWS;
• Ferramenta para geração e proteção das credenciais do cluster.

Tecnologia Docker com orquestração Kubernetes

Os serviços do Identity utilizam Nos próximos meses, os serviços do Identity serão migrados para a tecnologia de contêineres Docker e serão são controlados pela ferramenta de orquestração Kubernetes. Essa mudança representa uma grande evolução na arquitetura da ferramenta e proporcionará uma série de benefícios tanto àqueles envolvidos no desenvolvimento e gerenciamento do Identity, quanto aos nossos clientes e usuários.A  A estrutura em contêineres é mais eficiente que o modelo de máquinas virtuais (VMs) usado atualmente anteriormente, pois os serviços do Identity poderão podem assim compartilhar recursos como o sistema operacional e bibliotecas, aproveitando de forma mais eficaz o hardware dos servidores.

Outra vantagem é a portabilidade proporcionada pelo isolamento dos serviços em contêineres, um formato leve, autossuficiente e que pode ser executado em uma grande variedade de ambientes. Além disso, a inicialização mais rápida de um contêiner, comparada às VMs, aumentará aumenta significativamente a resiliência da aplicação.

O que muda nas integrações?

Essa migração exigirá uma atualização nos protocolos de segurança implementados pela ferramenta que, além recomendados pela AWS, proporcionam um nível maior proteção e confiabilidade aos nossos clientes e parceiros.

Requisitos para integrações

A Atualmente, para fins de integração, o Identity aceita conexões tanto via protocolo SSL 3 quanto TLS 1.0. Porém, a partir da atualização da arquitetura para o Docker, todas as integrações deverão devem utilizar o protocolo TLS 1.2. Outro requisito será é a extensão SNI (Server Name Indication), que deverá deve ser implementada pelas aplicações que desejam se comunicar com o Identity.Para que essa migração cause o menor impacto possível às operações dos nossos clientes, teremos um período de adaptação para que as atualizações necessárias possam ser realizadas nos sistemas que se integram ao Identity, como por exemplo, os ERPs TOTVS e o TOTVS Fluig.

Quando será feita a atualização?

A primeira etapa do processo de migração dos serviços do fluig Identity para uma estrutura de contêineres foi realizada no dia 13 de outubro de 2018 com a atualização do ambiente de produção (fluigidentity.com).

Os novos protocolos de segurança para integrações serão exigidos a partir de 2019.

...

Requisitos para aplicativos customizados

Para que a integração entre aplicativos customizados e o Identity em arquitetura Docker continuem funcionando, são necessárias algumas alterações:

• A primeira consiste na utilização do protocolo TLS v1.2 para as comunicações HTTPS, pois o SSL já foi quebrado e representa uma falha de segurança. A alteração já foi feita na biblioteca do rest-client do Identity e precisa ser atualizada nos sistemas que a utilizam. Caso os sistemas cliente utilizem a JDK 8u141 ou superior, essa alteração é opcional, visto que o Java 8 utiliza TLS por padrão. 

• A segunda alteração consiste em ativar o SNI para as conexões com o Identity, alteração que também já foi feita no do rest-client.

Das duas alterações a que causa o maior impacto é a ativação de SNI, visto que a JDK 7 possui bugs no tratamento de SNI, que devem ser contornados. A JDK 8u141 contempla as correções de SNI, sendo recomendado utilizar versões mais atuais.. 

<!-- Hotjar Tracking Code for http://tdn.totvs.com/display/fb -->
<script>
    (function(h,o,t,j,a,r){
        h.hj=h.hj||function(){(h.hj.q=h.hj.q||[]).push(arguments)};
        h._hjSettings={hjid:1280165,hjsv:6};
        a=o.getElementsByTagName('head')[0];
        r=o.createElement('script');r.async=1;
        r.src=t+h._hjSettings.hjid+j+h._hjSettings.hjsv;
        a.appendChild(r);
    })(window,document,'https://static.hotjar.com/c/hotjar-','.js?sv=');
</script>