Aplicações de clientes públicos e confidenciais

Artigo
11/23/2023

A Microsoft Authentication Library (MSAL) define dois tipos de clientes; clientes públicos e clientes confidenciais. Um cliente é uma entidade de software que tem um identificador exclusivo atribuído por um provedor de identidade. Os tipos de cliente distinguem-se pela sua capacidade de autenticação segura com o servidor de autorização e de manter informações confidenciais de prova de identidade para que não possam ser acedidas ou conhecidas por um utilizador no âmbito do seu acesso.

Aplicativos cliente públicos	Aplicativos cliente confidenciais
Aplicação de ambiente de trabalho	Aplicação Web
API sem navegador	Web API
Aplicação móvel	Serviço/daemon

Autorização de cliente público e confidencial

Ao examinar a natureza pública ou confidencial de um determinado cliente, estamos avaliando a capacidade desse cliente de provar sua identidade ao servidor de autorização. Isso é importante porque o servidor de autorização deve ser capaz de confiar na identidade do cliente para emitir tokens de acesso.

Os aplicativos cliente públicos são executados em dispositivos, como desktop, APIs sem navegador, aplicativos de navegador móveis ou do lado do cliente. Eles não podem ser confiáveis para manter segredos de aplicativos com segurança, pois só podem acessar APIs da Web em nome do usuário. Sempre que o código-fonte ou bytecode compilado de um determinado aplicativo é transmitido para qualquer lugar onde possa ser lido, desmontado ou inspecionado por partes não confiáveis, é um cliente público. Como eles também suportam apenas fluxos de clientes públicos e não podem manter segredos de tempo de configuração, eles não podem ter segredos de cliente.
Os aplicativos cliente confidenciais são executados em servidores, como aplicativos Web, aplicativos de API da Web ou aplicativos de serviço/daemon. Eles são considerados de difícil acesso por usuários ou invasores e, portanto, podem armazenar adequadamente segredos de tempo de configuração para afirmar a prova de sua identidade. O ID do cliente é exposto através do navegador da web, mas o segredo é passado apenas no canal traseiro e nunca diretamente exposto.

Segredos e sua importância na comprovação da identidade

A seguir estão alguns exemplos de como um cliente pode provar sua identidade para o servidor de autorização:

Identidades gerenciadas para recursos do Azure – Para cenários de autenticação somente de aplicativo, os desenvolvedores de aplicativos e serviços baseados no Azure têm a opção de descarregar gerenciamento, rotação e proteção secretos para a própria plataforma. Com identidades gerenciadas, as identidades são fornecidas e excluídas com recursos do Azure e ninguém, incluindo o Administrador Global, pode acessar as credenciais subjacentes. Usando identidades gerenciadas, você pode evitar o risco de vazamento de segredos e deixar o provedor lidar com a segurança para você.
ID do cliente e segredo – Neste padrão, um par de valores é gerado pelo servidor de autorização ao registrar um cliente. O ID do cliente é um valor público que identifica o aplicativo, enquanto o segredo do cliente é um valor confidencial usado para provar a identidade do aplicativo.
Comprovar a posse de um certificado – Infraestrutura de Chave Pública (PKI), que inclui padrões como X.509, é a tecnologia fundamental que permite uma comunicação segura pela internet e forma a espinha dorsal da privacidade na internet. A PKI é usada para emitir certificados digitais que verificam a identidade das partes envolvidas na comunicação on-line e é a tecnologia subjacente que alimenta protocolos como HTTPS, que é amplamente usado para proteger o tráfego da web. Da mesma forma, os certificados podem ser usados para proteger a comunicação serviço-a-serviço (S2S) no Azure habilitando a autenticação mútua entre os serviços. Trata-se de cada serviço apresentar um certificado ao outro como meio de prova da sua identidade.
Apresentação de uma asserção assinada – Usadas na federação de identidades de carga de trabalho, as asserções assinadas permitem a troca de um token de provedor de identidade de terceiros confiável com a plataforma de identidade da Microsoft para obter tokens de acesso para chamar recursos protegidos do Microsoft Entra. A federação de identidades de carga de trabalho pode ser usada para habilitar vários cenários de federação, incluindo o Serviço Kubernetes do Azure, o EKS da Amazon Web Services, as Ações do GitHub e muito mais.

Quando é que a comprovação da identidade do cliente é importante?

A comprovação da identidade do cliente é importante quando há a necessidade de verificar a autenticidade e a autorização de um aplicativo cliente antes de conceder acesso a dados ou recursos confidenciais. Alguns exemplos incluem:

Controlando o acesso à API – Se você tiver uma API que é medida (por exemplo, para faturamento) ou expõe dados ou recursos confidenciais, você verificará a identidade do cliente antes de conceder acesso. Por exemplo, isso é importante ao garantir que apenas aplicativos autorizados tenham acesso à API e que o cliente correto seja cobrado pelo uso limitado da API.
Protegendo os usuários contra a representação do aplicativo – Se você tiver um aplicativo implantado por serviço e voltado para o usuário (por exemplo, um aplicativo Web orientado por back-end) que acessa dados ou serviços confidenciais, usar segredos de cliente para proteger os recursos usados por esse aplicativo pode impedir que agentes mal-intencionados se passem por um cliente legítimo para enganar usuários e exfiltrar dados ou abusar do acesso.
Comunicação S2S – Se você tiver vários serviços de back-end (por exemplo, APIs downstream) que precisam se comunicar entre si, poderá verificar a identidade de cada serviço para garantir que eles estejam autorizados a acessar apenas os recursos necessários para executar sua função.

Em geral, provar a identidade do cliente é importante quando há a necessidade de autenticar e autorizar um cliente independente ou além de um usuário.

Clientes confidenciais: melhores práticas para a gestão de segredos

Use identidades gerenciadas para simplificar a implantação e a segurança – As identidades gerenciadas fornecem uma identidade gerenciada automaticamente na ID do Microsoft Entra para os aplicativos usarem ao se conectar a recursos que oferecem suporte à autenticação do Microsoft Entra. Os aplicativos podem usar identidades gerenciadas para obter tokens somente de aplicativo do Microsoft Entra ID sem precisar gerenciar credenciais. Isso pode remover muitas das complexidades associadas ao gerenciamento de segredos, aumentando sua segurança e resiliência. Se você estiver usando identidades gerenciadas, a maioria, se não todas, as práticas recomendadas a seguir já foram atendidas para você.

Use armazenamento seguro – armazene os segredos do cliente em um local seguro, como o Cofre da Chave ou um arquivo de configuração criptografado. Evite armazenar segredos do cliente em texto sem formatação ou como arquivos com check-in em sistemas de controle de versão.

Limitar o acesso - Limitar o acesso aos segredos do cliente apenas a pessoal autorizado. Use o controle de acesso baseado em função para restringir o acesso aos segredos do cliente apenas àqueles que precisam dele para executar suas funções operacionais.

Girar segredos do cliente – A rotação dos segredos do cliente conforme necessário ou programado pode minimizar o risco de um segredo comprometido ser usado para obter acesso não autorizado. Quando aplicado, o período de tempo durante o qual se sugere que uma chave permaneça em uso é influenciado pela força do algoritmo criptográfico usado e/ou pela adesão a normas ou práticas de conformidade regulamentar.

Use segredos longos e criptografia forte – Intimamente relacionado ao ponto anterior, o uso de algoritmos de criptografia fortes para dados em trânsito (no fio) e em repouso (no disco) ajuda a garantir que segredos de alta entropia permaneçam improváveis de serem forçados a bruto. Algoritmos como o AES-128 (ou superior) podem ajudar a proteger os dados em repouso, enquanto o RSA-2048 (ou superior) pode ajudar a proteger eficientemente os dados em trânsito. Devido à natureza em constante evolução da cibersegurança, é sempre uma boa prática consultar os seus especialistas em segurança e rever periodicamente a sua seleção de algoritmos.

Evite segredos de hardcoding – Não codifice segredos de cliente no código-fonte. Evitar segredos no código-fonte pode minimizar o valor de agentes mal-intencionados que obtêm acesso ao seu código-fonte. Também pode evitar que esses segredos sejam acidentalmente empurrados para repositórios inseguros ou disponibilizados a contribuidores do projeto que poderiam ter acesso à fonte, mas não acesso secreto.

Monitore repositórios em busca de segredos vazados – É um fato lamentável que check-ins ruins aconteçam ao lidar com código-fonte. Os ganchos de pré-confirmação do Git são uma maneira sugerida de evitar check-ins acidentais, mas também não substituem o monitoramento. O monitoramento automatizado de repositórios pode identificar segredos vazados e, com um plano em vigor para alternar credenciais comprometidas, pode ajudar a reduzir incidentes de segurança.

Monitore atividades suspeitas – Monitore logs e trilhas de auditoria em busca de atividades suspeitas relacionadas a segredos de clientes. Sempre que possível, use alertas automatizados e processos de resposta para notificar o pessoal e definir contingências para atividades incomuns relacionadas a segredos de clientes.

Arquitete seus aplicativos com o sigilo do cliente em mente – Seu modelo de segurança é tão forte quanto o elo mais fraco da cadeia. Não encaminhe credenciais de segurança ou tokens de clientes confidenciais para clientes públicos, pois isso pode mover dados secretos do cliente para um cliente público, permitindo a representação do cliente confidencial.

Use bibliotecas e SDKs atualizados de fontes confiáveis – A plataforma de identidade da Microsoft fornece vários SDKs e middleware de cliente e servidor projetados para aumentar sua produtividade enquanto mantém seus aplicativos seguros. Bibliotecas como Microsoft.Identity.Web simplificam a adição de autenticação e autorização a aplicativos Web e APIs na plataforma de identidade da Microsoft. Manter as dependências atualizadas ajuda a garantir que seus aplicativos e serviços se beneficiem das mais recentes inovações e atualizações de segurança.

Comparando os tipos de clientes e suas capacidades

A seguir estão algumas semelhanças e diferenças entre aplicativos cliente públicos e confidenciais:

Ambos os tipos de aplicativo mantêm um cache de token de usuário e podem adquirir um token silenciosamente (quando o token está presente no cache). Os aplicativos cliente confidenciais também têm um cache de token de aplicativo para tokens adquiridos pelo próprio aplicativo.
Ambos os tipos de aplicativo podem gerenciar contas de usuário e obter uma conta do cache de token de usuário, obter uma conta de seu identificador ou remover uma conta.
No MSAL, os aplicativos cliente públicos têm quatro maneiras de adquirir um token, por meio de fluxos de autenticação separados. Os aplicativos cliente confidenciais têm apenas três maneiras de adquirir um token e uma maneira de calcular a URL do ponto de extremidade de autorização do provedor de identidade. O ID do cliente é passado uma vez na construção do aplicativo e não precisa ser passado novamente quando o aplicativo adquire um token. Para obter mais informações, consulte Aquisição de tokens.

Os clientes públicos são úteis para permitir o acesso delegado pelo usuário a recursos protegidos, mas não conseguem provar sua própria identidade de aplicativo. Os clientes confidenciais, por outro lado, podem realizar autenticação e autorização de usuários e aplicativos e devem ser construídos com a segurança em mente para garantir que seus segredos não sejam compartilhados com clientes públicos ou outros terceiros.

Em alguns casos, como a comunicação S2S, a infraestrutura, como identidades gerenciadas, ajuda muito a simplificar o desenvolvimento e a implantação de serviços e remove grande parte da complexidade normalmente associada ao gerenciamento secreto. Quando as identidades gerenciadas não podem ser usadas, é importante ter políticas, medidas preventivas e contingências em vigor para proteger segredos e responder a incidentes de segurança relacionados a eles.

Consulte também

Para obter mais informações sobre configuração e instanciação de aplicativos, consulte: