Um registo de auditoria para um agente de programação partilhado é um registo append-only com uma linha por pedido e uma linha por aprovação, detido pelo proprietário da máquina e por ele exportável. Responde, a posteriori, a quem pediu ao agente para fazer o quê, quem o autorizou, o que realmente foi executado e quanto custou. Se o agente for utilizado apenas pelo seu proprietário, a transcrição do próprio runtime é suficiente. No momento em que uma segunda pessoa pode enviar pedidos, deixa de ser.
Este artigo lista os campos pela ordem em que o leitor precisa deles e, em seguida, aquilo que deve ficar de fora.
The request line
Cada pedido produz exatamente uma linha quando atinge um estado terminal.
The approval line
As aprovações têm a sua própria linha porque são decisões, e as decisões têm leitores diferentes das execuções.
Linhas de pedidos e linhas de aprovação, com um push aprovado a âmbar e uma eliminação expirada a vermelho.
What must not be in the log
- Segredos. A aprovação de credenciais regista que uma chave foi acedida, não a chave em si.
- Conteúdo de ficheiros. Os diffs são caminhos e contagens de linhas. A alteração está no repositório, onde se aplica o controlo de acessos do próprio repositório.
- Output completo de comandos. As últimas linhas bastam para explicar uma falha. Logs inteiros podem conter qualquer coisa.
- Outras salas. O registo de cada sala é delimitado a essa sala. O proprietário vê entre salas; os membros veem a sua sala.
Properties, not just fields
Append-only. Ninguém edita o registo, incluindo o proprietário. As correções são novas linhas.
Retido pelo proprietário. A pessoa cuja máquina executou o trabalho detém o registo e pode exportá-lo. Quem faz pedidos vê as suas próprias linhas na sala.
Completo sob revogação. Revogar uma autorização ou uma máquina cancela o trabalho em fila e deixa o trabalho em execução terminar, pelo que o registo nunca tem uma lacuna onde “algo correu mas deixámos de monitorizar”.
Ações do proprietário incluídas. O proprietário não está sujeito a aprovações no seu próprio agente, mas os seus pedidos são registados da mesma forma. Um registo que apenas regista utilizadores externos é um registo que só cobre metade do risco.
Reading the log
Três perguntas surgem com maior frequência, e os campos acima respondem a cada uma com um único filtro.
- “Quem fez esse push?” Filtrar linhas de aprovação por rule = push, ler who asked e who decided.
- “Porque é que este pedido demorou uma hora?” Comparar criado e iniciado; o tempo de espera pela aprovação costuma ser a resposta.
- “Quanto custou emprestar o meu agente este mês?” Somar a utilização nas linhas de pedido onde who asked não é o proprietário.
Frequently asked questions
A timeline da sala é o registo de auditoria? A timeline é o registo detalhado e legível por humanos de uma execução. O registo de auditoria é o resumo de uma linha por evento ao longo das execuções, concebido para filtragem e exportação. O muti guarda ambos; o registo deriva dos mesmos eventos que o daemon envia. Consulte o que o daemon envia.
Durante quanto tempo é guardado? As linhas de pedido e de aprovação são mantidas durante a vida da sala. Eliminar uma sala faz um soft-delete; o registo permanece para o proprietário.
Quem faz um pedido pode ver as linhas de outras pessoas? Vê a timeline da sala, que inclui os pedidos de todos nessa sala. A exportação cabe ao proprietário.
Os pedidos do proprietário precisam de aprovação para serem registados? Não. As execuções do proprietário são registadas sem aprovações, com rule = owner.
O registo é o que torna “pode revogar mais tarde” uma promessa real. Dê uma sala ao seu agente e este já inclui um.
Publicado a