Restrições e segurança · BreezeAuth Docs

A credencial de um usuário de serviço funciona sem que ninguém digite uma senha ou responda a um desafio de autenticação multifator, então ela merece o mesmo cuidado que a conta de um administrador. O BreezeAuth oferece vários controles para manter o poder e a exposição de cada usuário de serviço tão pequenos quanto possível. Combine-os.

Visão geral dos controles

Controle	O que limita	Onde configurar
Papel administrativo	O que o usuário de serviço pode fazer	O formulário Modificar do usuário de serviço
Status do usuário de serviço	Se o usuário de serviço pode funcionar	Aba Visão Geral do usuário de serviço › Alterar status
Status da credencial	Quais credenciais funcionam	O formulário Modificar da credencial › Ativa
Expiração da credencial	Até quando uma credencial funciona	A data em Expira em da credencial
Zonas de rede	De onde o usuário de serviço pode se conectar	Organização › Configurações de Segurança › Configurações de restrição de acesso por rede
Restrição por país	De quais países a organização pode ser acessada	Organização › Configurações de Segurança › Restringir o acesso por país

Alguns limites são fixos e não podem ser alterados: usuários de serviço não podem entrar no console de administração nem nas aplicações, não podem ser Proprietários e não podem ser adicionados a grupos nem atribuídos a aplicações.

Dar apenas o acesso necessário

O papel administrativo decide quais operações o usuário de serviço pode realizar pela API; todo o resto é recusado. Escolha o papel mais restrito que atenda à integração, por exemplo Auditor para relatórios somente leitura ou Provisionador SCIM para provisionamento de usuários, e evite Administrador, a menos que nada mais funcione. Veja Escolher um papel.

Crie um usuário de serviço por integração. Assim, cada um tem apenas o acesso de que precisa, as ações de cada um são fáceis de distinguir nos Logs de Auditoria, e desligar um não afeta os outros.

Desligar integrações na hora

Você pode cortar o acesso em dois níveis, e ambos valem já na próxima requisição à API, inclusive para tokens de acesso que já foram emitidos e ainda não expiraram:

Desative uma credencial para interromper uma instalação de uma integração, ou um secret que pode ter vazado. As outras credenciais do usuário de serviço continuam funcionando. Veja Desativar uma credencial.
Desative o usuário de serviço para interromper a integração inteira, sejam quais forem as suas credenciais. Veja Desativar ou reativar um usuário de serviço.

Os dois podem ser desfeitos com a reativação.

Limitar a vida útil das credenciais

Sempre que possível, defina uma data em Expira em para as credenciais. Uma credencial que expira sozinha limita o estrago de um secret que vazou sem que ninguém percebesse, e transforma a rotação em rotina. Os próprios tokens de acesso sempre têm curta duração, e não existem refresh tokens: quando uma credencial é desativada ou expira, nada derivado dela continua funcionando.

Restringir as redes de onde os usuários de serviço se conectam

As integrações normalmente rodam a partir de um lugar conhecido: o seu data center, uma conta de nuvem ou um servidor com endereços IP públicos fixos. Você pode fazer o BreezeAuth recusar requisições de qualquer outro lugar, de modo que um secret roubado seja inútil fora dessas redes.

Isso usa as zonas de rede: listas nomeadas de faixas de endereços IP que você define uma vez e reutiliza. Quando a restrição de acesso por rede da organização está ativa:

um usuário de serviço só consegue obter tokens de acesso a partir de uma zona de rede permitida;
cada requisição à API que ele faz também é verificada e recusada com network_not_authorized se vier de fora das zonas permitidas.

Para configurar:

Descubra os endereços IP públicos que os servidores da sua integração usam para acessar a internet. O seu provedor de nuvem ou de hospedagem, ou a sua equipe de rede, pode informá-los; servidores atrás de um NAT gateway normalmente compartilham o endereço fixo dele.
Crie uma zona de rede para eles, por exemplo “Servidores de integração”.
Restrinja o acesso à organização a essa zona e às zonas de onde as pessoas se conectam.

Atenção: a restrição de rede da organização vale para todos os membros, pessoas e usuários de serviço, e não apenas para os usuários de serviço. Antes de salvar, garanta que as zonas selecionadas incluem as redes de todos os administradores e das pessoas que usam a organização, ou elas perderão o acesso imediatamente, inclusive você.

Se a organização também usa Restringir o acesso por país, essa restrição vale para as requisições à API dos usuários de serviço: requisições vindas de um país não permitido são recusadas com access_not_allowed_from_country.

Monitorar a atividade

Os Logs de Auditoria registram quando usuários de serviço e credenciais são criados, alterados ou excluídos, cada vez que uma credencial é usada para obter um token de acesso e as ações que os usuários de serviço realizam. Na aba Credenciais de cada usuário de serviço, a coluna Último uso mostra quando cada credencial foi trocada por um token pela última vez.

Revise essas informações regularmente: uma credencial que nunca é usada pode ser excluída, e atividade em horários incomuns ou de lugares inesperados merece uma análise mais atenta.

Checklist de segurança

Cada integração tem o seu próprio usuário de serviço.
Cada usuário de serviço tem o papel mais restrito que funciona.
Os client secrets ficam em um gerenciador de segredos ou em variáveis de ambiente protegidas, nunca no código nem nos dispositivos dos usuários.
As credenciais têm data em Expira em e uma rotina de rotação.
Credenciais sem uso são desativadas e depois excluídas.
Se as integrações rodam a partir de endereços fixos, a organização restringe o acesso a zonas de rede conhecidas.
Alguém revisa os Logs de Auditoria e as datas de Último uso periodicamente.
Todos sabem como desativar uma credencial ou um usuário de serviço em uma emergência.