Cada vez mais os sistemas de computação estão envolvidos no dia-a-dia da sociedade, por vezes através de novos modelos de negócio que só seriam possíveis com a tecnologia ou integrando-se a fluxos tradicionais, automatizando e otimizando parte de um trabalho. Dentro da ciência da computação, há vários campos que estudam cada aspecto deste impacto da tecnologia na sociedade, especialmente sobre a construção desses sistemas que servirão a variados propósitos. Uma classe especial desses sistemas de informação são os sistemas corporativos que, dentre outras definições, são sistemas robustos que lidam com informações sensíveis. A construção de aplicações corporativas é marcada pelo rigor em requisitos não-funcionais, como segurança, desempenho e disponibilidade, o que torna-se uma tarefa difícil para o time de desenvolvimento prover num software, principalmente quando a aplicação é disponibilizada para uma larga base de usuários, frequente ou quando recorrentemente ocasiona um pico de acessos.
Os casos demonstrados acima representam justamente a quebra dessas métricas tão importantes para os sistemas corporativos, e que podem tanto ocasionar um downtime da aplicação como também compremeter as informações pessoais dos usuários, com possíveis repercussões legais.
Mas a parte mais legal da ciência é que podemos estudar o que deu errado e estabelecer boas práticas para evitar que tais problemas ocorram novamente (ou pelo menos minimizar a chande algo dar errado), e isso tem sido feito há um bom tempo. Nesse post tentarei explicar alguns conceitos básicos de como arquiteturar um sistema corporativo na internet e também fornecer algumas dicas para que você possa estudar mais.
Quando começa-se a projetar uma aplicação que vai prover o acesso a usuários final, sempre é necessário planejar como será a solução de autenticação da aplicação, pois essa parte do sistema provavelmente terá o impacto mais extensivo ao longo dos fluxos de execução.
Uma boa dica geral para lidar com autenticação é tente terceirizar a responsabilidade, principalmente quando se trata de guardar senhas de usuários. Atualmente uma boa opção é utilizar o Login Social, onde, através do protocolo oAuth, os usuários podem se conectar no sistema identificando-se através de algum provedor de acesso, utilizando suas contas no Google, Facebook, Github ou em algum serviço especializado como OpenId. Essa solução pode apresentar problemas de privacidade e potencialmente pode haver algum usuário que não terá conta em nenhum dos serviços que você escolheu para servirem como provedor.
Mas, se você precisa (ou quer) manter todos os dados relativos a autenticação e deseja implementar um modelo de autenticação "clássico" usuário-e-senha uma boa estratégia é o uso de um padrão como o JWT (Json Web Token). Vai ser possível encontrar implementações compatíveis para os mais variados frameworks por ser uma tecnologia já bem consolidada na internet, valendo sempre uma atenção na hora de guardar a senha dos usuários que é, como falei, uma tarefa de muita responsabilidade. O uso de um algoritmo de hash como o bcript vai tornar o módulo de autenticação mais robusto, mas é também importante o uso de HTTPS, dica que vale para todo o sistema em si. Você pode saber mais sobre HTTPS aqui, e conseguirá certificados gratuitamente no Let's Encrypt.
Mesmo com as soluções acima implementadas, é notado que cada vez mais são frequentes, principalmente pela maior abrangência dos sistemas corporativos, os vazamentos de dados por parte de outras empresas ou falhas de seguranças em linguagens de programação e em frameworks, por isso tem-se tornado comum a implementação de uma segunda maneira de autenticação, principalmente baseado em "senhas temporárias" utilizando aplicativos como Google Auth ou Authy e também o serviço de SMS, onde o número de celular torna-se um verificador de identificação. Essa segunda maneira é utilizada como prova após o acesso convencional (com e-mail e senha, por exemplo), para garantir que mesmo que a senha do usuário tenha sido roubada não será possível acessar o sistema sem a segunda verificação.
Obs: Alguns serviços de autenticação também oferecem o acesso apenas através do serviço de verificação através do número de celular do usuário, já esta é uma informação pessoal de verificação, mas nos últimos anos têm sido comuns casos de clonagem de número SIM, deixando aberto a invasores utilizarem desse privilégio para acessar serviços em nome da vítima que teve seu número clonado (saiba mais sobre esses casos aqui). Recentemente procuradores da justiça federal do Brasil tiveram suas conversas no aplicativo Telegram publicadas após criminosos se apropriarem das contas através de uma falha no serviço de caixa postal (saiba mais aqui). Então, por enquanto, é recomendável evitar autenticação baseada em número de celular.
Dica: Você pode usar facilmente boa parte das soluções descritas aqui através dos serviços Auth0 e Firebase Auth, ambos com planos gratuitos.
Nos últimos anos, com a adoção cada vez maior dos serviços web pela população em geral, os desenvolvedores e as empresas de tecnologia têm notado que as senhas estão se tornando obsoletas, e tem sido comum a adoção de práticas de autenticação que não dependem do usuário necessariamente ter uma senha no serviço (e também sem a utilização de um provedor externo com Google ou Facebook). Isso pode ser implementado de diversas maneiras, como através do e-mail, mas os browsers e as grandes empresas têm trabalhado no padrão WebAuth, que faz o uso de chaves criptográficas para prover autenticação, além de se integrar com serviços biométricos como o Apple TouchID. Essa tecnologia oferece a robustez e a segurança para se tornar um dos padrões de autenticação na internet num futuro próximo, vale a pena checar.
Dica: No projeto de um sistema corporativo, é importante saber bem a diferença entre autenticação, que é o ato de verificar se um usuário é realmente "ele mesmo", e autorização, que verifica as permissões que um certo usuário ostenta dentro da aplicação.
Talvez esses pontos sejam a maior preocupação do ponto de vista estrutural de um sistema corporativo, impactando tanto a experiência do usuário final como o custo de operação do sistema. E com certeza é uma das tarefas mais complicadas tecnicamente pois envolve o gerenciamento de diversos recursos que podem ser ou não ser compartilháveis ou replicáveis ao longo do tempo.
Um exemplo da particularidade desse problema ocorre quando, por exemplo, são liberadas as notas dos candidatos do ENEM no sistema web e causam um pico de acesso repentino que faz a aplicação parar de responder em alguns casos ou apresentar lentidão para os usuários. Inicialmente poderia pensar-se na solução de criar uma infraestrutura fixa que possa sempre suportar o número máximo de acessos que o sistema recebe (por exemplo, em um dia de divulgação das notas), mas em todo o resto do ano estaria disperdiçando-se recursos desnecessários para uma carga "comum" e potencialmente gastando mais dinheiro do que seria necessário.