Gestão do ciclo de vida de identidades de estudantes e pessoal

A gestão do ciclo de vida de identidades académicas rege o acesso de uma pessoa à medida que muda a sua situação como estudante, docente, investigador ou colaborador. No ensino superior, funciona melhor em três percursos: para estudantes, para docentes e instrutores e para pessoal não docente. Cada percurso tem os seus próprios desencadeadores e aprovações, unidos num único registo de identidade.

Um estudante que conclui o curso, um docente convidado cujo período letivo terminou e um colaborador que se demite desencadeiam, muitas vezes, o mesmo pedido de saída, embora cada um deva perder acessos diferentes em datas diferentes. Este guia apresenta uma matriz de ciclo de vida para as três populações, regras para funções sobrepostas e uma lista de verificação de implementação a 90 dias.

Porque é que a gestão do ciclo de vida de identidades académicas exige três percursos

O ensino exige ciclos de vida de acesso separados, porque o estatuto de estudante, as nomeações docentes e o emprego do pessoal são criados e alterados por sistemas e eventos diferentes. Um único processo genérico de integração e saída tem dificuldade em conceder o acesso certo a tempo e em removê-lo quando o motivo desse acesso termina.

• O acesso de um estudante está associado à matrícula, à inscrição em unidades curriculares e à situação académica.
• O acesso de um membro do pessoal não docente está associado a uma função e a um registo laboral.
• O acesso de um docente depende frequentemente de uma nomeação e de uma atribuição letiva específica, que podem começar e terminar num calendário distinto do do registo laboral.

Este padrão costuma ser descrito como Joiner-Mover-Leaver (JML): um quadro de referência para acompanhar quando alguém entra numa organização, muda de função e acaba por sair. No ensino, «leaver» (quem sai) é a designação errada para um estudante que conclui o curso mas mantém acesso limitado como alumni, ou para um docente cuja atribuição letiva termina enquanto a nomeação continua. Um fluxo JML genérico oculta estes casos, a menos que modele eventos específicos de cada função, períodos de tolerância e afiliações sobrepostas. O modelo de três percursos fá-lo.

A mesa-redonda de 2025 da InCommon sobre práticas de identidade no ensino superior concluiu que 27 % dos inquiridos tinham mais dificuldade com políticas e normas, 23 % com o controlo de acesso baseado em funções (RBAC) e 14 % com a compreensão de como as diferentes populações percorrem os seus ciclos de vida. A sondagem não permite identificar uma causa única. Mostra, porém, que a política, a conceção de funções e a responsabilidade pelo ciclo de vida merecem tanta atenção como a escolha da tecnologia.

A matriz do ciclo de vida de acesso académico

A matriz do ciclo de vida de acesso académico (AALM) transforma a conceção do ciclo de vida em oito decisões, repetidas para cada uma das três populações: evento desencadeador, fonte de autoridade, atributos de identidade, acesso de base, acesso condicional, responsável pela aprovação, ponto de revisão e ação de fim de acesso. O preenchimento destes oito campos para estudantes, docentes e instrutores e pessoal não docente dá à instituição um documento de política utilizável, em vez de um quadro abstrato.

O guia federal de gestão do ciclo de vida de identidades descreve a criação, a modificação e a eliminação como as fases centrais para provisionar, ajustar e revogar acessos segundo o princípio do menor privilégio, ou seja, os utilizadores recebem apenas o acesso que a sua função atual exige. A AALM adapta essa lógica ao ensino, onde a «modificação» abrange uma variedade muito maior do que uma mudança de função típica numa empresa.

As três secções seguintes mostram como os mesmos campos mudam consoante a população. O acesso de base, os atributos e as fontes de autoridade variam de instituição para instituição. A matriz deve ser tratada como ponto de partida para o planeamento: convém preencher os sistemas e os responsáveis pela aprovação da própria instituição antes de considerar definitiva qualquer linha.

Gestão de acessos de estudantes, da matrícula ao estatuto de alumni

A gestão de acessos de estudantes liga os eventos do estado académico a um modelo de direitos de acesso que adiciona, ajusta ou retira acessos sem criar uma nova identidade sempre que a situação de um estudante muda. A matrícula, a interrupção, a desistência, a conclusão do curso e a passagem ao estatuto de alumni alteram, cada uma, aquilo a que o estudante pode aceder, enquanto o registo da pessoa se mantém.

A cadeia de eventos do estudante

A cadeia estende-se, normalmente, do acesso prévio à chegada, concedido a candidatos, à matrícula ou ingresso, às alterações de curso e de unidades curriculares, à interrupção de estudos, à desistência, à conclusão do curso e à passagem ao estatuto de alumni. Convém avaliar, para cada evento, se deve criar uma nova identidade, alterar o acesso existente ou desencadear uma revisão de estado. Na maioria dos casos, o registo da pessoa já existe e o evento altera o acesso em vez de criar uma segunda identidade.

Ligar o acesso aos dados académicos

O SIS ou a secretaria académica funciona habitualmente como fonte de autoridade para os atributos do estado académico e alimenta o LMS, a jusante, com os dados de inscrição em unidades curriculares. Convém documentar o modo como esses dados chegam ao LMS (integração direta, middleware ou uma camada de governação de identidades), em vez de presumir um caminho fixo. Quando o registo de um estudante não corresponde de forma limpa, por exemplo após uma alteração de nome, uma candidatura duplicada ou uma transferência de estudante com duas contas anteriores, deve encaminhar-se para uma fila de exceções. Não se deve permitir que o sistema crie silenciosamente uma segunda conta.

Proteger os registos educativos e os dados de apoio financeiro

O 34 CFR § 99.31(c) exige que as instituições utilizem métodos razoáveis para identificar e autenticar as pessoas a quem divulgam informações de identificação pessoal constantes de registos educativos. A conservação de registos de pedidos e de divulgações enquadra-se no § 99.32. Esse requisito abrange a divulgação de informações dos registos educativos. Não substitui o registo habitual de acessos ao nível da aplicação.

Quando estão em causa dados de apoio financeiro, a orientação GEN-25-08 do Departamento de Educação aborda o acesso permitido a Federal Tax Information e a dados do FAFSA por parte de instituições elegíveis. Nenhuma das fontes define uma arquitetura técnica. O departamento jurídico da instituição deve confirmar de que forma cada uma se aplica aos sistemas existentes.

O acesso de docentes e instrutores exige um ciclo de vida próprio

O acesso de docentes e instrutores exige um ciclo de vida próprio, porque o acesso para lecionar depende de uma nomeação, de uma atribuição letiva concreta e de obrigações de lançamento de notas, e não de uma data normal de início e de fim de contrato. Os docentes convidados e os docentes visitantes tornam isto evidente: o respetivo acesso ao LMS pode ter de começar antes do contrato e prolongar-se para além do período letivo.

A EDUCAUSE descreve um cenário comum: um instrutor de curta duração precisa de acesso ao LMS antes da data oficial de início para preparar uma unidade curricular e pode precisar de acesso limitado depois do fim do período letivo para concluir o lançamento de notas. Um ciclo de vida genérico de colaborador, construído em torno de uma única data de contratação e de uma única data de cessação, trata mal este padrão. As instituições precisam de uma política documentada com um período de tolerância explícito.

O direito de acesso individual de um docente ao LMS ou ao e-mail pertence ao modelo de acessos da IAM/IGA. Uma camada de gestão de credenciais é mais relevante para as contas operacionais partilhadas que a TI ou um responsável designado controla diretamente, como sistemas de laboratório ou credenciais de fornecedores.

Ciclo de vida do pessoal não docente: Eventos laborais, mudanças de função e saídas

O acesso do pessoal não docente deve seguir eventos validados de emprego e de mudança de funções, com o superior hierárquico ou o responsável de negócio relevante a confirmar qualquer acesso para além do pacote padrão da função. Os desencadeadores típicos são a contratação, a transferência, a promoção, a licença e a cessação, e cada um deve reavaliar os direitos de acesso existentes, e não apenas adicionar novos.

Um modo de falha comum é a acumulação de privilégios (privilege creep): alguém recebe novo acesso após uma promoção e ninguém remove o acesso associado à função anterior. A recertificação regular de acessos, uma revisão agendada em que o superior hierárquico confirma que o acesso de cada pessoa continua a ser necessário, deteta este problema antes de se tornar uma constatação de auditoria.

O NIST SP 1800-35 apresenta o acesso autorizado seguro como uma decisão contínua, e não como uma concessão pontual, assente numa governação de identidades reforçada em recursos distribuídos, on-premises e na nuvem. Aplicar isto ao acesso do pessoal é uma opção de conceção, e não um requisito do NIST: tratar cada mudança de função como um desencadeador para reavaliar os direitos de acesso existentes.

Uma pessoa, várias funções: Governar transições e sobreposições

Um modelo de identidade com várias funções mantém um único registo por pessoa e concede apenas o acesso justificado por cada função ativa. Isto evita contas duplicadas e permite remover o acesso associado a uma função sem alterar o acesso proveniente de outra.

Seis cenários abrangem a maioria das sobreposições com que as instituições se deparam:

• Um estudante passa a colaborador, como quando estudantes trabalhadores assumem funções a tempo parcial
• Um membro do pessoal ou do corpo docente matricula-se como estudante
• Um docente é, em simultâneo, instrutor, investigador e administrador de departamento
• Um estudante trabalhador muda de departamento ou tem dois empregos ao mesmo tempo
• Um alumnus ou reformado recebe acesso limitado e com prazo definido a um serviço específico
• Um prestador de serviços ou colaborador externo precisa de um acesso que expira automaticamente numa data definida

A regra mais importante: quando uma afiliação termina, deve remover-se apenas o acesso associado a essa afiliação. Podem ocorrer dois erros. O sistema pode retirar acesso que outra função ativa continua a justificar ou pode deixar acesso em vigor depois de a afiliação ter terminado. A correspondência fiável de identidades (confirmar que dois registos pertencem à mesma pessoa) e uma fila de revisão documentada para os casos que as regras automáticas não conseguem resolver mantêm ambos os erros sob controlo.

Construir a camada de dados e de integração antes de automatizar

A automatização funciona quando uma instituição já identificou as suas fontes de autoridade, construiu uma correspondência fiável de identidades e definiu a precedência dos dados em caso de conflito entre sistemas. Sem estes três elementos, as regras de provisionamento atuam sobre registos desatualizados ou sem correspondência e concedem acesso demasiado cedo ou deixam-no em vigor durante demasiado tempo.

Deve atribuir-se a fonte de autoridade por atributo e não por sistema. Um modelo comum atribui os atributos do estado académico ao SIS ou à secretaria académica, os atributos laborais ao RH/HCM e ao processamento salarial e os atributos de atribuição letiva a um sistema de planeamento de horários ou de assuntos académicos. A titularidade varia de campus para campus, pelo que convém documentar a autoridade e a precedência ao nível do atributo para o ambiente da própria instituição.

Algumas credenciais não têm um responsável natural em nenhum destes sistemas. Uma credencial partilhada de administração na nuvem, utilizada por três engenheiros de infraestrutura, não pertence nem aos RH nem ao SIS. Uma camada de governação e administração de identidades (IGA) pode registar que a equipa de infraestrutura é responsável por ela. O segredo propriamente dito continua a exigir um sistema concebido para armazenar, rodar e auditar credenciais partilhadas. Trata-se de um controlo distinto.

Um fluxo de eventos básico é o seguinte:

• Ocorre um evento no sistema de registo
• A correspondência de identidades confirma a que pessoa se aplica
• Uma regra de política avalia o que deve mudar
• Realiza-se uma aprovação, quando exigida
• Executa-se o provisionamento ou a revogação
• Um evento de auditoria regista o que aconteceu

Qualquer passo que falhe, como uma identidade sem correspondência ou um evento desatualizado, deve seguir para uma fila de exceções visível, com um responsável atribuído. Não deve desaparecer em silêncio.

O NIST SP 800-63-4 estabelece requisitos para a verificação de identidade, a inscrição, a gestão de autenticadores, a autenticação e a federação. É uma referência útil para a camada de identidade subjacente a esta automatização, embora não prescreva uma arquitetura para o ensino.

Aplicar controlos de acesso e evidências proporcionais ao risco

Os controlos de acesso devem corresponder à sensibilidade do recurso e à função atual da pessoa, ao passo que as evidências de auditoria devem mostrar quem aprovou o acesso, quando foi alterado e se continua justificado. Os controlos de base abrangem o princípio do menor privilégio, o controlo de acesso baseado em funções (RBAC), a MFA, o SSO, as revisões agendadas, o acesso com limite de tempo e a segregação de funções.

A segregação de funções impede que uma mesma pessoa solicite e aprove o seu próprio acesso. As regras baseadas em políticas podem acrescentar contexto que uma função, por si só, não transporta, como as datas de nomeação ou as atribuições letivas. As contas órfãs, ou seja, contas que continuam ativas depois de terminada a afiliação que as justificava, devem ser assinaladas automaticamente, em vez de serem descobertas durante uma auditoria.

As credenciais operacionais partilhadas precisam da sua própria camada. Um programa de IAM/IGA pode governar a titularidade e a revisão de uma conta de serviço partilhada, de um sistema de laboratório ou das credenciais de um portal de fornecedores, determinando quem é responsável e quando o acesso é recertificado. Não armazena, não roda nem partilha o segredo em segurança. É aí que uma camada de gestão de credenciais assume o papel.

Lista de verificação de implementação da gestão do ciclo de vida de identidades académicas: Os primeiros 90 dias

Os primeiros 90 dias devem servir para definir a política, modelar as três populações, validar os dados de origem, pilotar um número reduzido de aplicações e medir as exceções por resolver antes de a automatização se alargar. A lista de verificação abaixo segue essa ordem e termina com a revisão jurídica e de privacidade. Cada passo produz um documento ou uma métrica que o grupo de governação pode rever.

A lista de verificação de 90 dias do ciclo de vida de identidades académicas (10 pontos)

• Constitua um grupo de governação: secretaria académica, RH, assuntos académicos, IAM/TI, segurança, responsáveis pelas aplicações e apoio ao utilizador
• Defina o registo da pessoa e as regras de correspondência de identidades entre sistemas
• Mapeie os estados do ciclo de vida e os respetivos desencadeadores para estudantes, docentes/instrutores e pessoal não docente
• Atribua uma fonte de autoridade e uma regra de precedência a cada atributo-chave
• Elabore a AALM para as primeiras cinco aplicações ou serviços
• Redija as regras de aprovação, de exceção, de período de tolerância e de saída de emergência
• Pilote o provisionamento e o desprovisionamento automatizados com monitorização ativa
• Defina as métricas de referência: tempo de provisionamento, tempo de desativação, acumulação de exceções, contas dormentes, acessos temporários em atraso e taxa de conclusão das revisões
• Realize exercícios de simulação (tabletop) para cenários de várias funções e de fim de período letivo antes da entrada em produção
• Peça aos responsáveis jurídicos e de privacidade que revejam a política antes de a aplicar em larga escala

A InCommon recomenda a mesma sequência: definir as necessidades locais do ciclo de vida, mapeá-las visualmente, estabelecer a governação, melhorar a qualidade dos dados de origem, planear as exceções e documentar as decisões.

Conclusão

O ciclo de vida de identidades académicas deve ser tratado primeiro como um problema de política e só depois como um problema de ferramentas. Três fluxos de eventos, três responsáveis, um único registo por pessoa: é isto que permite remover o acesso ao laboratório de um estudante que concluiu o curso sem afetar o emprego que passou a ter na secretaria académica.

Passo seguinte: reunir o grupo de governação e acordar as primeiras cinco aplicações a mapear, ordenadas pela sensibilidade dos dados que contêm.

Perguntas frequentes

Caos de palavras-passe nas instituições de ensino: Porque é importante

O caos de palavras-passe estende-se para além do apoio informático e alcança o resto da instituição de ensino, consome tempo ao pessoal, alarga a superfície de ataque e põe em risco a conformidade. Os três maiores riscos e como os eliminar.

PassworkPasswork Team

Saída de colaboradores: Guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas sobrevivem-lhe. Este guia abrange o procedimento completo de saída de colaboradores, dos desencadeadores à hora zero até à limpeza de NHI.

Passwork BlogAlex Muntyan

Políticas de cofres do Passwork: Guia de segurança empresarial para CIO

Os tipos de cofre (Vault Types) do Passwork associam os direitos de administração à própria política do cofre, e não a quem o criou, fechando uma lacuna que a maioria das empresas nem sabe que existe. Este guia oferece a CIO e CISO um modelo prático de governação de cofres, alinhado com os requisitos da NIS2 e da ISO 27001.

PassworkPasswork Team