Como registar as aprovações de acesso à VPN sem histórico de navegação
Guarde a identidade, o aprovador e a expiração, e dispense a lista de destinos. Três condições decidem quanto da decisão de acesso precisa realmente de ficar registado.
Duas equipas pedem o mesmo artefacto e entendem dele coisas diferentes. O revisor quer a prova de que uma pessoa nomeada aprovou um papel até uma data, enquanto a equipa de rede tem um registo da firewall cheio de destinos e assume que isso conta. Não conta, e é por isso que as pastas de aprovações se enchem de nomes de anfitriões e ainda assim falham a primeira pergunta de auditoria. O que realmente precisa é pouco, e nada disso exige registar onde alguém navegou.
O tamanho do registo segue três condições: se a aprovação é concedida por pessoa ou por papel, se o direito pode sobreviver à relação laboral da pessoa e se um contrato ou quadro refere a revisão de acessos como evidência exigida.
Comece pela pergunta do revisor, não pela ligação
Escreva a pergunta que um auditor faria em voz alta antes de escolher um único campo. Quem aprovou o acesso para esta identidade, para quê, entre que datas e quem deveria retirá-lo no fim. Cada campo do formulário deve responder a parte dessa frase, e tudo o que não o faça é inventário cuja obrigação de proteger acabou de assumir.
Esse teste elimina a maior parte do que é acrescentado por hábito. As listas de destinos, as consultas de DNS, os gráficos de utilização de aplicações e as capturas de uma sessão ao vivo descrevem todas comportamento. O comportamento não é a aprovação, e recolhê-lo desloca o processo para uma classe de sensibilidade muito mais alta, o que contraria o objetivo com que começou.
Três condições decidem quanto conservar
As aprovações por pessoa exigem uma identidade e uma data de fim. As aprovações por papel exigem o papel, o âmbito que concede e o proprietário da população, porque listar quarenta pessoas numa linha cria quarenta registos para manter e quarenta ocasiões de falhar uma saída. Onde o direito pode sobreviver à relação laboral, acrescente um proprietário da remoção e uma cadência de revisão, já que uma data de expiração numa folha de cálculo raramente leva alguém a agir.
| Condition | Add to the record | Leave out |
|---|---|---|
| Approved per person | Identity, approver, expiry | Device telemetry |
| Approved per role | Role, scope, population owner | Per-user destinations |
| Outlives employment | Removal owner, review date | Session transcripts |
| Named in a contract | The cited artifact and its revision | A second, friendlier copy |
Quando um quadro refere a revisão de acessos como evidência exigida, conserve o artefacto que o processo de revisão já cita. Construir uma cópia paralela para a equipa de VPN é a forma como duas versões da mesma aprovação acabam em desacordo sobre uma data de fim.
Os campos que transportam a decisão
O conjunto viável é curto: a identidade aprovada, o requerente, o aprovador, o âmbito do papel ou do recurso, o motivo numa linha, a janela de validade, o proprietário da revisão ou da remoção e um ponteiro para o ticket onde o pedido foi argumentado. Refira o dispositivo ou a credencial com um identificador não secreto, como uma etiqueta de ativo ou o sujeito do certificado, nunca com a chave privada nem a palavra-passe que foram usadas.
Trate o resultado como dado pessoal mesmo que não contenha destinos. Um registo que diz que este trabalhador nomeado teve acesso administrativo ao segmento financeiro durante seis meses é sensível por si só, por isso delimite quem pode ler a pasta e defina uma retenção para a finalidade administrativa em vez de classificar o processo como anónimo.
Por onde a navegação se infiltra no processo de aprovação
Três fugas explicam a maior parte. Um ticket de apoio contém uma captura da janela de ligação do cliente, alguém cola uma exportação do SIEM para dar contexto, ou um relatório de inventário é associado à aprovação porque na altura a associação era fácil. Cada anexo acrescenta comportamento a um processo que só precisava de uma decisão. Assim que a captura está lá dentro, o revisor começa a perguntar a que chegava o utilizador, e o processo tem de ser reclassificado.
Substitua os anexos por ponteiros sempre que a ferramenta o permitir. Se a política insistir num anexo, peça o texto da decisão e o fio do pedido, não a gravação da sessão, e elimine o resto antes de guardar o processo. A mensagem do próprio aprovador é normalmente a melhor prova e a que menos revela.
Verifique o âmbito sem o rasto
É a política do gateway que transforma uma aprovação em acesso, por isso teste-a diretamente. Inicie sessão com uma conta dentro do âmbito aprovado e chegue a um recurso permitido, depois tente um destino fora do âmbito e confirme a recusa, com o cliente e o método que a política espera, não com um separador do navegador no mesmo anfitrião.
A monitorização de disponibilidade e o diagnóstico de incidentes podem manter a sua própria visibilidade, com a sua própria retenção e a sua própria lista de acesso. Manter estes dois propósitos separados é o que lhe permite responder ao revisor sem entregar um rasto de navegação, e mantém o diagnóstico útil quando algo se avaria a sério.
O que verificar antes da próxima revisão
Confirme que o formulário responde à frase do auditor e a mais nada. Verifique que cada linha leva um aprovador, uma janela e um proprietário da remoção. Depois olhe para a lista de acesso da própria pasta e pergunte se é menor do que a base de utilizadores da VPN.
O último passo é o que as pessoas saltam. Pegue numa aprovação expirada e siga-a até ao fornecedor de identidade para ver se a conta foi realmente desativada. Se a identidade ainda está ativa, o registo era exato e o processo não.