Comunicação entre microsserviços - distinguindo chamadas internas com segurança

5

Estou reestruturando e reescrevendo minha solução monolítica de BaaS em microsserviços em relação a regras de escalabilidade e responsabilidade única. Devido às dependências internas, os serviços são colocados em diferentes camadas lógicas. Veja a figura abaixo;

Em vez de acessar diretamente o armazenamento do banco de dados ou do valor-chave, cada serviço em Tier 2 deve usar Tier 1 Data Storage Service . A meta das chamadas de serviço interno está localizada no Serviço de configuração, hospedado independentemente do API Gateway. O API Gateway é implantado e configurado por produto. O produto tem um apikey e um apisecret.

Cenário 1:

  • Os usuários finais podem fazer login no produto hospedado. (http *: // host / autenticação / login)

Cenário 2:

  • Business Service serve uma lógica customizada: MyClass.MyOperation () (http *: // host / business / myclass / myoperation)
  • Os usuários finais de Business Service devem ser autenticados por meio de Authentication Service para usar a lógica de negócios (autenticação baseada em token)

Na arquitetura monolítica, eu era capaz de interceptar chamadas de negócios dispersas através de interceptores configurados dentro da tarefa http em execução. Portanto, consegui receber AuthenticationToken da solicitação de serviço de negócios e decidir se o usuário final foi autenticado por meio do serviço de autenticação consultando diretamente o armazenamento de valor-chave.

Seguindo a arquitetura micoservice, antes de executar a lógica de negócios Business Service deve fazer uma solicitação com a transferência de todos os cabeçalhos de solicitação originais para o Authentication Service , aguarda sua resposta, analisa o resultado da autenticação e executa a lógica de negócios desejada. tarefa de resposta. Única responsabilidade, bastante justa.

Pergunta:

  • Considerando que cada Tier 2 services pode ser distribuído em qualquer lugar dentro da rede, que opções eu tenho para distinguir com segurança as solicitações internas e externas entre o gateway e os microservices?
  • Essa abordagem poderia ser usada para impedir o loop de serviço interno?
por denolk 30.03.2016 / 09:10
fonte

2 respostas

3

A melhor coisa a fazer é garantir que todas as solicitações sejam de uma fonte autenticada. Isso pode significar uma solicitação do usuário, mas também um usuário 'serviço' que corresponda a cada microsserviço. Se um hacker conseguir acessar seu nível 2 e você tiver uma API não autenticada, ele poderá causar estragos.

Cada microsserviço deve ter seu próprio usuário distinto para uso em solicitações não solicitadas, mas geralmente todas as chamadas de API devem passar pelo token de usuário que você recebeu da solicitação original.

    
por 30.03.2016 / 10:21
fonte
2

Certifique-se de ter algum tipo de contexto (por falta de uma palavra melhor) em todas as chamadas internas. Isso deve conter um token de autenticação do originador de qualquer solicitação e pode ser simplesmente transmitido sempre que você fizer solicitações internas.

Em seguida, você precisa executar a autorização, com base no token de autenticação (idealmente, verificando o token TODAS as vezes), conforme apropriado dentro de cada micro-serviço.

Para chamadas que não são devidas a um usuário externo, verifique se cada um dos seus serviços adquire um token de autenticação apropriado, identificando-o como o originador da solicitação.

Dependendo exatamente da aparência da sua arquitetura interna, pode ser apropriado para um micro-serviço receber uma solicitação identificando-se como originador para resultar em erro.

    
por 30.03.2016 / 11:32
fonte