SCIM e aprovisionamento automático de contas

O serviço de aprovisionamento trabalha por ciclos. Um primeiro ciclo consulta todos os utilizadores e grupos da origem; depois, ciclos incrementais tratam apenas do que mudou desde o último marcador registado². Se um utilizador não tem conta correspondente na aplicação, ela é criada. Se tem, é atualizada².

A saída segue vários casos previstos. Um utilizador desativado ou eliminado para a «reciclagem» no diretório é desativado na aplicação de destino. Numa aplicação SCIM, desativar equivale a pedir que a propriedade «active» tenha o valor falso². Trinta dias após a eliminação no diretório, o utilizador é eliminado definitivamente, e o serviço envia então um pedido de eliminação à aplicação². Um utilizador cujos grupos ou direitos mudam também pode sair do âmbito, o que conta como uma saída da aplicação². Com grupos dinâmicos, a rapidez da remoção depende da velocidade com que o grupo reavalia os seus membros².

Tudo é registado nos registos de aprovisionamento, que guardam as leituras e escritas feitas nos sistemas de origem e de destino².

• Avise com antecedência. Comunique ao seu responsável e aos recursos humanos a sua entrada, mudança de funções ou saída, com a data exata, porque é a alteração do diretório que desencadeia tudo o resto.
• Responsáveis: declarem as mudanças de funções tal como as saídas. Uma mudança de função pode exigir a remoção de acessos, e não apenas a adição de novos¹.
• Não crie nenhuma conta fora do circuito oficial: nenhum registo pessoal num serviço com o endereço profissional, nenhuma conta aberta à mão na interface de administração de uma aplicação sem informar a equipa informática. Uma conta assim não está ligada ao diretório, pelo que ninguém a encerrará automaticamente.
• Devolva os seus acessos antes de sair: cartão, chaves de segurança, dispositivos e qualquer acesso recebido por outro canal que não a sua conta habitual.
• Ative a autenticação multifator nas contas que continuam abertas. A CISA coloca as chaves de segurança à cabeça dos métodos e o código por SMS ou correio eletrónico em último⁷.

Aplicação não ligada

Uma aplicação do catálogo suporta aprovisionamento manual ou aprovisionamento automático. No modo manual, não existe conector automático: as contas criam-se à mão, por exemplo no portal de administração da aplicação ou através de um ficheiro de folha de cálculo¹. Para estas aplicações, a saída passa por uma ação humana. Uma aplicação criada a partir de um simples registo OIDC não está ativada para aprovisionamento automático³.

Alterações feitas diretamente na aplicação

O serviço ignora as alterações feitas nas aplicações externas e não as anula: baseia-se no que muda no diretório³. Uma conta criada ou alterada localmente escapa, assim, ao circuito. A Microsoft indica que o aprovisionamento também pode detetar as contas existentes numa aplicação, incluindo locais ou órfãs¹. A MITRE recomenda remover as contas órfãs, por exemplo sem proprietário, em auditorias regulares, e desativar automaticamente as contas após um período de inatividade, por exemplo 30 dias⁴.

Contas locais, contas partilhadas, palavras-passe

O aprovisionamento de palavras-passe não é suportado³. Algumas aplicações no local não estão federadas com o diretório e exigem palavras-passe locais³. Uma conta partilhada ou uma palavra-passe local conhecida de quem sai não se encerra com a saída do titular: é preciso alterá-la ou eliminá-la à mão.

Atrasos e erros

O intervalo entre dois ciclos não é configurável³. Quando um erro impede a alteração de um utilizador, a operação é repetida no ciclo seguinte, e um administrador tem de consultar os registos para encontrar a causa². Se a maioria das chamadas falhar, por exemplo por credenciais de administração inválidas, a tarefa entra em quarentena, com ciclos abrandados para um por dia, e é depois desativada ao fim de mais de quatro semanas². Uma saída pode, assim, não ser repercutida a tempo sem que ninguém o note.

Tokens e sessões que sobrevivem

Segundo a MITRE, um atacante que controle uma conta na nuvem pode criar credenciais adicionais duradouras para se manter nela, e essas credenciais podem contornar controlos como a autenticação multifator⁵. As fontes aqui citadas não dizem se uma sessão aberta termina assim que uma conta SCIM é desativada. Do lado da aplicação, a OWASP indica que, quando uma sessão termina, a aplicação deve invalidá-la no cliente e no servidor, e que o lado do servidor é o mais importante e obrigatório do ponto de vista da segurança⁶. Recomenda também um tempo limite de inatividade e um tempo limite absoluto para todas as sessões⁶. Quando um colaborador sai, a equipa informática deve, portanto, verificar os tokens de acesso, as palavras-passe de aplicação e as sessões, além da própria conta.