accounting

redesgovernança e riscosegurança

O terceiro A do AAA: registrar o que uma parte autenticada de fato fez, para faturamento, capacidade ou evidência.

É o que mais costuma ser configurado por último e o mais necessário sob pressão, porque autenticação e autorização respondem perguntas sobre o presente, e a contabilização é a única que responde sobre o passado. Em rede de operadora ela existe para gerar fatura; em rede corporativa existe para que alguém possa dizer qual conta emitiu qual comando em qual equipamento, que é exatamente a pergunta feita depois de uma queda ou de uma invasão, e exatamente o registro que ninguém habilitou. A RFC 2866 dá forma à contabilização do RADIUS: pacotes Accounting-Request na UDP 1813 com Acct-Status-Type Start (1), Stop (2) ou Interim-Update (3), mais Accounting-On (7) e Accounting-Off (8) quando um NAS inicia ou desliga, carregando Acct-Session-Id, os contadores de octetos e pacotes de entrada e saída, Acct-Session-Time e Acct-Terminate-Cause, cada um confirmado por um Accounting-Response e reenviado com recuo até ser confirmado. A RFC 8907 dá ao TACACS+ sua troca de contabilização com flags START, STOP e WATCHDOG, que num roteador significa cada comando que um administrador executou. O syslog (RFC 5424) e o log de alterações de configuração do próprio equipamento carregam o resto, e o catálogo de controles do NIST diz o que um registro precisa estabelecer: o que aconteceu, quando, onde, de que origem, com que resultado e a identidade de quem esteve envolvido.

A contabilização é a parte do AAA que produz um registro, e o registro é o ponto: a autenticação decide quem pode entrar e a autorização decide o que pode fazer, mas só a contabilização consegue dizer depois o que foi feito, por qual conta, em qual equipamento e quando. As operadoras a construíram para faturar, e é por isso que os atributos do RADIUS contam octetos; as empresas precisam dela para a pergunta que se segue a toda queda e a toda invasão, e descobrem no dia se ela chegou a ser ligada. Os protocolos que a carregam são os mesmos que carregam a autenticação, cada um com um lado de contabilização próprio.

A contabilização do RADIUS é a RFC 2866, publicada em junho de 2000 por Rigney como companheira Informational da RFC 2865. O servidor de acesso à rede envia pacotes Accounting-Request (código 4) à porta UDP 1813 e espera um Accounting-Response (código 5) para cada um; a RFC recomenda que o cliente continue tentando enviar o Accounting-Request até receber uma confirmação, usando alguma forma de recuo, e é por isso que a contabilização sobrevive a uma queda breve do servidor e por isso uma queda longa produz uma enxurrada de registros atrasados quando o servidor volta. O atributo Acct-Status-Type diz que tipo de registro é: 1 Start quando uma sessão começa, 2 Stop quando termina, 3 Interim-Update em intervalos durante ela, 7 Accounting-On e 8 Accounting-Off quando o próprio NAS começa ou para de servir, com outros valores para túneis e 15 para uma tentativa falha. Os atributos carregam as medidas: Acct-Session-Id para amarrar Start, atualizações e Stop, Acct-Input-Octets e Acct-Output-Octets, Acct-Input-Packets e Acct-Output-Packets, Acct-Session-Time em segundos, Acct-Terminate-Cause para o motivo do término, Acct-Delay-Time para quanto o registro esperou, Acct-Multi-Session-Id para ligar sessões relacionadas e Acct-Authentic para dizer quem a autenticou. O atributo Class que o servidor colocou no Access-Accept volta sem modificação, de modo que uma etiqueta que o motor de política anexou no login está em cada registro. O Request Authenticator de um pacote de contabilização é um MD5 sobre o pacote com dezesseis octetos zero no lugar do autenticador e o segredo compartilhado anexado, o que deixa o servidor detectar um registro de um cliente que não conhece o segredo, e nada mais; o registro inteiro vai, fora isso, em texto claro, como tudo no RADIUS sem RadSec.

A contabilização do TACACS+, na RFC 8907 de setembro de 2020, é o terceiro dos três tipos de pacote do protocolo, 0x03, e seus registros são sobre administradores e não sobre assinantes. O pedido de contabilização carrega flags, START (0x02) para o início de uma tarefa, STOP (0x04) para o seu fim e WATCHDOG (0x08) para informar que uma tarefa longa continua em andamento, e como o TACACS+ autoriza comandos um a um, um roteador configurado para contabilização de comandos envia um registro para cada comando que um administrador executa, com o nome de usuário, o equipamento, a linha de comando e a hora. Esse fluxo, guardado num servidor, é a resposta a quem mudou o quê; ele existe só para os equipamentos em que foi habilitado e só pelo período que o servidor reteve.

Os logs do próprio equipamento são o complemento. O syslog, na RFC 5424 de março de 2009, define uma mensagem de header, dados estruturados e texto livre, com uma prioridade calculada como facility vezes oito mais severidade, severidades de 0 Emergency a 7 Debug, facilities 4 e 10 reservadas a mensagens de segurança e autorização e 16 a 23 para uso local, e um timestamp derivado da RFC 3339; o documento especifica a mensagem e deixa o transporte a outros, UDP na RFC 5426 e TLS na RFC 5425, que toda implementação precisa suportar. O recurso Configuration Change Notification and Logging da Cisco mostra o que um equipamento consegue registrar sozinho: ele permite rastrear as alterações de configuração feitas por sessão e por usuário por meio de uma função de arquivo e guarda logs de configuração que rastreiam cada comando de configuração aplicado, quem o aplicou, o código de retorno do parser (PRC) do comando e a hora em que foi aplicado, com opções para ocultar senhas no log e para enviar cada entrada ao syslog. Ferramentas de backup de configuração fecham o ciclo guardando a configuração de cada equipamento num repositório com controle de versão e mostrando a diferença entre um dia e o seguinte; o Oxidized, que se descreve como uma ferramenta de backup de configuração de equipamentos de rede e um substituto do RANCID, suporta mais de 130 tipos de sistema operacional e grava em git, de modo que o diff entre dois commits é a mudança, mesmo quando a contabilização de comandos que nomearia o autor nunca foi habilitada.

O que um registro precisa conter está escrito. O catálogo de controles do NIST, a SP 800-53, exige no AU-3 que os registros de auditoria estabeleçam que tipo de evento ocorreu, quando ocorreu, onde ocorreu, a origem do evento, o resultado do evento e a identidade de quaisquer indivíduos, sujeitos ou objetos associados a ele; o AU-2 pede à organização que apresente uma justificativa de por que os tipos de evento selecionados para registro são considerados adequados para sustentar investigações posteriores de incidentes; o AC-6(9) diz simplesmente para registrar a execução de funções privilegiadas, porque, em sua discussão, o uso indevido de funções privilegiadas por pessoas de dentro ou por atacantes com contas comprometidas é uma preocupação séria e permanente. Lidos juntos, esses controles são a especificação da contabilização de uma empresa: Start e Stop do RADIUS para toda sessão de rede, registros de comando do TACACS+ para toda sessão administrativa, syslog com relógios sincronizados de todo equipamento e histórico de configuração que mostre o que os comandos fizeram. O artigo sobre quem fez o quê e quando os reúne num só projeto, e as regulações que o exigem, da SOX ao PCI DSS, têm verbetes próprios.

Também conhecido como: aaa, aaa accounting, radius accounting, command accounting, session accounting, who did what and when

← Todos os verbetes do glossário