Instâncias duplicadas de gateway podem dividir seu histórico de auditoria?

Um bundle de app copiado não é uma forma inofensiva de criar um segundo gateway local. Ele testa se o software consegue manter uma única autoridade sobre credenciais, aprovações, revogações e evidências quando o macOS apresenta dois candidatos plausíveis.

A falha perigosa nem sempre é uma queda. Uma queda é barulhenta. A falha mais silenciosa envolve dois processos que parecem saudáveis, aceitam solicitações dos agentes e deixam evidências suficientes para tranquilizar a pessoa que os iniciou. Depois, uma alteração de credencial, uma revogação ou uma revisão de incidente revela a divisão: um processo sabia algo que o outro não sabia.

O Sallyport foi projetado como um único app assinado de barra de menus do macOS, sempre em execução, com um núcleo de cofre dentro do próprio processo. Por isso, iniciar os bundles estável, beta e copiado ao mesmo tempo deve ser tratado como um teste deliberado de concorrência e identidade, não como uma prática normal. O teste deve chegar a uma resposta objetiva: o sistema recusa a duplicata, coordena seu uso com segurança ou permite sua execução preservando um único cofre autoritativo e um único histórico verificável?

Dois bundles não significam automaticamente duas identidades

O nome exibido pelo Finder é o sinal de identidade mais fraco deste experimento. Sallyport.app, Sallyport Beta.app e Sallyport Copy.app podem parecer três aplicativos independentes para uma pessoa e ainda carregar o mesmo identificador de bundle e a mesma identidade de assinatura dentro dos bundles.

A Apple documenta o identificador de bundle como o identificador usado pelo macOS para reconhecer um app. O material sobre assinatura de código também explica que um requisito designado permite ao sistema reconhecer o código como o mesmo aplicativo entre atualizações. Esses conceitos são úteis, mas nenhum deles responde à pergunta principal. O reconhecimento da identidade pelo macOS não prova que dois processos ativos conseguem manter o estado com segurança.

Comece registrando o que foi realmente iniciado. Faça isso antes de abrir o cofre, conectar um agente ou aprovar qualquer coisa.

APP_A="/Applications/Sallyport.app"
APP_B="$HOME/Desktop/Sallyport Beta.app"

for app in "$APP_A" "$APP_B"; do
  echo "=== $app ==="
  plutil -p "$app/Contents/Info.plist" | grep -E 'CFBundleIdentifier|CFBundleShortVersionString|CFBundleVersion'
  codesign -dvv "$app" 2>&1 | grep -E 'Identifier=|TeamIdentifier=|Authority='
  codesign -d -r- "$app" 2>&1 | grep 'designated =>'
done

O formato da saída importa mais que o texto exato:

=== /Applications/Sallyport.app ===
"CFBundleIdentifier" => "..."
"CFBundleShortVersionString" => "..."
Identifier=...
TeamIdentifier=...
designated => identifier "..." and anchor ...

Guarde esse artefato junto do registro do teste. Se os dois bundles intactos informarem o mesmo identificador e o mesmo requisito designado, trate-os como duas cópias de uma identidade de código. Se forem diferentes, trate-os como identidades de código separadas. Não use rótulos como «estável» e «beta» no lugar de nenhum desses fatos.

Há uma segunda distinção que as equipes costumam confundir: identidade de código não é identidade de armazenamento. Dois processos com o mesmo requisito designado podem ser esperados para ler o mesmo material protegido. Dois processos com requisitos diferentes podem receber permissões separadas do sistema. Nenhum desses resultados informa se eles podem compartilhar com segurança um cofre criptografado ou acrescentar registros a uma cadeia de auditoria. A propriedade do armazenamento precisa ser testada separadamente.

Um histórico de auditoria dividido é pior que um registro incompleto

Um diário incompleto informa que faltam evidências. Um diário dividido pode contar duas histórias internamente consistentes, cada uma sem os registros mantidos pela outra. Isso torna a revisão de incidentes mais lenta e pode fazer uma sessão revogada parecer válida do ponto de vista de um dos processos.

Para um gateway de ações, o diário precisa responder a perguntas concretas depois do fato:

• Qual processo de agente solicitou a ação?
• Qual processo do gateway a autorizou ou recusou?
• Qual referência de credencial foi usada sem expor o segredo?
• Uma pessoa aprovou a sessão ou a chamada individual?
• A revogação aconteceu antes ou depois da ação?

Se os processos A e B escreverem sequências independentes, as duas sequências poderão ser verificadas individualmente. Isso não basta. A verificação de uma cadeia criptográfica mostra que os registros dentro dela não foram alterados sem detecção. Ela não prova, por si só, que outro escritor legítimo não iniciou uma cadeia separada em outro lugar.

Por isso, a diferença entre evidência de adulteração e completude é importante. Uma cadeia de hash protege a relação entre os registros presentes naquela cadeia. A completude exige uma regra clara de propriedade, um único ponto de acréscimo ou evidências duráveis de cada ramificação aceita e de como ela foi reconciliada. Se isso for feito de forma errada, uma pessoa responsável poderá executar a verificação com sucesso e ainda assim não perceber metade das ações.

O assunto vai além dos registros. Um histórico dividido costuma acompanhar uma autoridade dividida:

• Um processo acredita que o cofre está bloqueado enquanto outro mantém uma sessão desbloqueada.
• Um processo revoga uma execução de agente enquanto outro continua aceitando-a.
• Um processo registra uma aprovação por chamada enquanto outro não vê motivo para perguntar.
• Um processo grava o resultado final da ação enquanto o outro grava apenas a solicitação.

Não avalie o teste observando se as duas cópias conseguem concluir uma chamada HTTP ou um comando SSH. Uma chamada bem-sucedida prova apenas que existe um caminho. O teste passa quando uma pessoa que revisar o caso mais tarde consegue reconstruir todo o histórico da ação sem adivinhar qual cópia mantinha o estado ausente.

Defina o contrato de propriedade antes de iniciar a disputa

Um teste de instâncias duplicadas sem invariantes esperadas produz apenas relatos. Escreva o contrato primeiro e depois tente quebrá-lo.

Há três contratos defensáveis para cópias de um gateway local.

1. Propriedade exclusiva. O primeiro processo é dono do cofre e dos diários. As cópias seguintes recusam a operação, trazem o primeiro app para frente ou encerram com uma explicação clara.
2. Um processo ativo com transferência. Um novo lançamento encontra o proprietário e pede que ele execute o trabalho solicitado. O novo processo não desbloqueia, aprova nem acrescenta registros de forma independente.
3. Propriedade coordenada entre vários processos. Mais de um processo pode ser executado, mas todos usam um protocolo deliberado de estado compartilhado que preserva alterações atômicas no cofre e uma única ordem auditável de eventos.

O primeiro contrato costuma ser o mais fácil de analisar em um app de desktop que mantém estados de grande consequência. O terceiro pode ser válido, mas exige uma demonstração muito mais abrangente. «Eles apontam para a mesma pasta» não é um protocolo de coordenação.

Escreva os resultados esperados em uma tabela antes do teste. Mantenha cada resultado observável.

A formulação importa. «As cópias não devem entrar em conflito» não é testável. «Um bundle copiado não pode retornar uma resposta de ação bem-sucedida depois que um proprietário existente revogou a mesma execução de agente» é testável.

Separe também o comportamento do produto do comportamento do ambiente de teste. Seu script de shell pode impedir dois lançamentos acidentais, mas isso não prova que o app os impede. Seu proxy reverso pode serializar as solicitações, mas isso não prova que o cofre local lida com solicitações simultâneas. Não deixe o ambiente de teste resolver o bug que você pretendia encontrar.

Inicie cópias intactas antes de testar artefatos alterados

O experimento limpo começa com bundles de app intactos. Copie um bundle sem alterar os arquivos dentro dele, coloque as cópias em locais comuns separados e registre cada caminho. Alterar primeiro um executável ou o Info.plist costuma invalidar a assinatura do código, transformando o experimento em um teste de validação de assinatura.

A TN3127 da Apple explica por que esse limite importa: o macOS usa requisitos designados para decidir se o código satisfaz uma identidade estabelecida. Se você modificar um bundle e a assinatura deixar de ser válida, qualquer recusa poderá estar correta, mas não informará nada sobre a propriedade duplicada entre versões válidas.

Use uma pequena ficha de lançamento. Ela deve conter apenas fatos observáveis:

Test ID: duplicate-owner-01
Build A path: /Applications/Sallyport.app
Build B path: /Users/tester/Desktop/Sallyport Beta.app
Bundle IDs: [recorded value A] / [recorded value B]
Designated requirements: [recorded value A] / [recorded value B]
Launch order: A first, B second
Vault state before launch: locked
Agent process IDs: [record after start]
Expected contract: exclusive ownership

Em seguida, inicie A, espere até que ele chegue ao estado ocioso e inicie B. Registre o resultado antes de fazer qualquer outra coisa. Uma recusa precisa ser explícita o suficiente para informar qual processo existente é dono do estado. Uma saída silenciosa gera chamados de suporte e incentiva novas tentativas até que uma disputa seja produzida.

Confirme a separação real dos processos pelo sistema operacional, não pelas janelas do app. Uma segunda janela pode pertencer ao mesmo processo, enquanto um auxiliar em segundo plano pode criar um segundo processo mesmo quando há apenas um item visível na barra de menus.

pgrep -alf 'Sallyport|sp mcp|sp-ssh'
ps -axo pid,ppid,start,command | grep -E 'Sallyport|sp mcp|sp-ssh' | grep -v grep

Trate a saída como um artefato da linha do tempo. Salve-a imediatamente após cada fase de lançamento. Inclua os IDs dos processos pai quando possível. Eles ajudam a explicar se a segunda ação veio de um processo independente do app, de um componente iniciado pelo agente ou de um auxiliar filho.

Não use credenciais de produção neste trabalho. Aponte as solicitações HTTP para um endpoint de teste dedicado que aceite um método inofensivo ou para um serviço controlado. Para SSH, use uma conta dedicada com restrição de comando ou um host sem acesso à produção. Você está testando a propriedade do processo e o comportamento da auditoria. Não precisa de um endpoint destrutivo para descobrir se uma segunda cópia pode agir.

O bloqueio do cofre precisa ter um único proprietário visível

O bloqueio do cofre só é um limite absoluto se todo caminho de ação chegar ao mesmo bloqueio. Se um processo puder continuar desbloqueado depois que outro bloquear, encerrar ou perder o acesso, então «bloqueado» descreve uma janela, não o estado real do sistema.

Teste primeiro esta sequência com uma ação HTTP inofensiva:

1. Inicie a cópia A com o cofre bloqueado.
2. Conecte um processo de agente pelo componente MCP local e tente a ação inofensiva. Espere uma recusa.
3. Desbloqueie A pela interação local normal e repita a ação. Registre o resultado bem-sucedido e sua entrada de atividade.
4. Inicie a cópia B enquanto A continua disponível. Ainda não desbloqueie B.
5. Peça ao mesmo processo de agente e a um processo novo que tentem a mesma ação pelo caminho acessível de B, se houver um.
6. Bloqueie A ou encerre-o e repita as solicitações dos dois agentes.

O resultado aprovado depende do contrato de propriedade, mas o resultado inseguro é fácil de identificar: B executa a ação porque reteve ou adquiriu de forma independente uma autoridade que a pessoa não conseguia ver quando bloqueou A.

É aqui que uma recomendação comum falha: «Basta compartilhar o estado desbloqueado para que o beta não continue perguntando». As pessoas recomendam isso porque a autenticação local repetida incomoda durante o desenvolvimento. A ideia é errada, a menos que o estado compartilhado tenha um proprietário definido, uma duração clara e um caminho de revogação observado por todos os processos antes de agir. Economizar uma solicitação de confirmação não vale criar um segundo estado de desbloqueio invisível.

O modelo de cofre protegido por hardware acrescenta um limite útil ao teste. Enquanto o cofre está bloqueado, o agente deve receber uma recusa, não um segredo substituto, uma solicitação parcialmente preparada ou uma ação enfileirada que seja executada depois do desbloqueio. Um gateway de ações deve executar a ação aprovada e devolver seu resultado. Ele não deve entregar material de credenciais ao agente enquanto espera que a pessoa resolva o estado local.

Registre tanto a resposta da ação quanto as evidências no diário. Uma recusa que desaparece do histórico torna a depuração posterior desnecessariamente difícil. Um sucesso que aparece sem um registro anterior de desbloqueio ou aprovação é ainda pior.

A aprovação da sessão deve estar vinculada a um processo, não a um rótulo

A autorização por sessão existe para que uma pessoa avalie uma execução específica de agente. Ela perde o sentido quando a autorização passa de um processo para outro porque as duas execuções têm nome semelhante, são iniciadas no mesmo terminal ou se conectam pelo mesmo bundle copiado.

O registro da aprovação deve permitir responder: qual executável solicitou, quem o assinou, quando o processo começou e quando sua autoridade terminou? A autoridade de assinatura do processo é especialmente útil, porque um comando de terminal sozinho não identifica o código por trás dele.

Faça este teste com dois processos de agente deliberadamente separados. Não reutilize um processo de shell fingindo que são dois agentes.

# Terminal 1
sp mcp

# Terminal 2
sp mcp

Os comandos são intencionalmente simples. O importante é que eles partam de processos de agente separados no ambiente de teste e que cada um envie uma chamada inofensiva. Aprove a primeira sessão e deixe a segunda sem resposta. Se sua configuração exibir detalhes do processo no cartão de aprovação, capture a autoridade mostrada e compare-a com o processo iniciado.

Agora teste as seguintes transições:

• Encerre o processo de agente aprovado e inicie um processo substituto com o mesmo comando.
• Inicie ou ative um gateway copiado enquanto a primeira sessão continua aprovada.
• Revogue a primeira execução no diário de sessões.
• Peça aos dois processos que emitam mais uma solicitação inofensiva.

A regra esperada é simples: uma aprovação pertence a uma execução até que ela termine, e uma revogação encerra a autoridade dessa execução em todos os lugares. Um processo substituto não deve herdar a aprovação apenas porque parece familiar. Um gateway copiado não deve interpretar a mesma conexão de agente como permissão para contornar uma decisão que seu equivalente exigiria.

Não confunda aprovação por sessão com chaves por chamada. A aprovação de sessão responde se esse processo de agente pode usar o gateway durante sua execução. Uma chave por chamada responde se cada uso daquela credencial específica precisa de uma nova decisão humana. Uma diz respeito à duração do chamador; a outra, à sensibilidade da credencial. Se você misturar as duas nos registros do teste, interpretará o resultado de forma errada.

A aprovação por chamada revela caminhos duplicados ocultos

Uma credencial marcada para aprovação em cada uso é uma boa sonda de instâncias duplicadas, porque força o software a considerar cada ação separadamente. Use uma credencial de teste dedicada ou um destino SSH, defina a exigência de aprovação por chamada e envie solicitações simultâneas e inofensivas pelos dois caminhos candidatos.

O teste não é «recebi duas solicitações de aprovação?». Duas solicitações podem estar corretas ou podem mostrar que as duas cópias criaram autoridades independentes. A pergunta é se cada ação concluída tem uma aprovação correspondente e se alguma cópia consegue reutilizar a aprovação da outra.

Monte um pequeno registro de eventos durante o teste:

Use IDs de solicitação gerados pelo endpoint ou pelo ambiente de teste. Não dependa da ordem em que as janelas apareceram. O agendamento do desktop pode reordenar as solicitações visíveis, e um resultado HTTP pode retornar depois de uma solicitação posterior.

Um resultado ruim costuma parecer organizado no começo: aprove a solicitação A na cópia A e descubra depois que a cópia B consegue concluir a solicitação B sem sua própria aprovação. Isso indica que o estado de aprovação atravessou um limite sem uma decisão da pessoa responsável. O problema inverso também é grave: aprove B, mas o resultado é registrado no fluxo de atividade de A sem explicação para o motivo pelo qual A agiu.

Repita a disputa depois de bloquear o cofre, depois de encerrar uma cópia e depois de revogar a primeira execução do agente. Essas transições detectam estado antigo mantido em memória. Os erros mais reveladores costumam aparecer depois de uma mudança de estado, quando um processo atualizou sua visão e o outro ainda não.

A verificação da auditoria precisa de uma prova antes e depois

Um relatório que diz «o registro parecia correto» não é uma evidência. Capture uma linha de base, crie um conjunto controlado de ações, faça a verificação depois da execução e compare os registros esperados com os observados.

O desenho de auditoria descrito para este gateway tem uma vantagem: o mesmo registro criptografado, encadeado por hash e sem acesso de leitura projeta-se tanto no diário de Sessões quanto no diário de Atividade. Os diários devem ser, portanto, duas visões de um único histórico, não dois registros mantidos de forma independente que apenas se parecem.

Comece com um período de teste vazio ou claramente delimitado. Anote o horário inicial e gere uma sequência conhecida: recusa com o cofre bloqueado, ação de sessão aprovada, ação aprovada por chamada, recusa por chamada, revogação da sessão e ação recusada depois da revogação. Mantenha a sequência curta o suficiente para contabilizar cada evento.

Depois, execute o verificador offline:

sp audit verify

Guarde toda a saída do comando, incluindo um código de saída diferente de zero se houver falha. O verificador não deve precisar de acesso ao cofre para conferir a cadeia de texto cifrado. Essa propriedade permite que um investigador verifique a integridade sem primeiro desbloquear o armazenamento de credenciais, exatamente o que se deseja quando um teste de processos duplicados deu errado.

A verificação é apenas a primeira conferência. Compare três visões:

1. Seu registro externo do teste, incluindo cada ID de solicitação e o resultado esperado.
2. O diário de Sessões, incluindo aprovações, encerramentos de execuções e revogações.
3. O diário de Atividade, incluindo cada tentativa de ação e seu resultado.

Cada evento do registro deve corresponder à visão de diário adequada. Cada evento do diário no período delimitado deve corresponder a algo gerado intencionalmente. Investigue registros extras, mesmo quando a cadeia é verificada. Uma ação bem-sucedida inesperada pode ser uma nova tentativa, uma solicitação enfileirada ou uma evidência de que um segundo processo continuou ativo depois que você imaginou que ele havia encerrado.

Se duas cadeias independentes forem verificadas, informe isso como uma falha de completude do histórico, a menos que o projeto documentado para vários processos registre uma relação pai e uma mesclagem determinística. Não resolva isso concatenando os registros exportados depois do teste. Uma mesclagem manual produz um relatório, não um histórico de auditoria.

O comportamento de recuperação determina se um erro duplicado vira um incidente

Você deve esperar tentativas de propriedade interrompidas. Pessoas encerram versões beta à força. Laptops entram em repouso. Um ambiente de teste mata um processo entre uma aprovação e o resultado de uma ação. O aplicativo precisa lidar com esses casos sem permitir que um proprietário abandonado bloqueie o trabalho para sempre ou que um proprietário substituto suponha que nenhuma ação ocorreu.

Teste pelo menos quatro pontos de interrupção:

• Mate a cópia A depois que ela receber uma solicitação, mas antes de obter aprovação.
• Mate a cópia A depois da aprovação, mas antes de a ação externa terminar.
• Mate a cópia A depois que a ação terminar, mas antes que o resultado fique visível para o agente.
• Inicie a cópia B imediatamente depois de cada interrupção.

Para cada caso, escreva a regra de recuperação segura antes de executá-lo. Uma regra razoável pode ser B recusar até estabelecer que A terminou e recuperar o estado durável. Outra pode ser B retomar apenas a partir de registros de auditoria confirmados e marcar qualquer ação incerta como desconhecida, em vez de declarar sucesso ou falha. A regra correta depende da implementação, mas fazer suposições nunca é aceitável.

Não esconda a incerteza. Sistemas externos podem concluir uma solicitação HTTP ou um comando SSH no mesmo instante em que o processo local morre. Se o gateway não puder provar se a operação terminou, deve preservar essa ambiguidade nas evidências. Repetir uma gravação desconhecida pode criar uma segunda ação real. Fingir que a primeira nunca aconteceu cria uma história de auditoria falsa.

É também nesse ponto que a revogação imediata precisa ser examinada. Revogue uma execução de agente, encerre imediatamente o proprietário atual, inicie uma cópia e tente a mesma ação com esse agente. Se o processo substituto tratar a ausência do estado em memória como uma sessão nova, a revogação não foi durável o suficiente. Uma revogação que só funciona enquanto um processo permanece ativo não é uma revogação confiável durante uma falha.

Mantenha os testes estável e beta isolados, a menos que o compartilhamento seja deliberado

As versões estável e beta incentivam a convivência casual porque ambas são úteis. A estável executa o trabalho real. A beta precisa de pressão realista. Colocá-las contra o mesmo cofre e os mesmos diários sem um contrato de compatibilidade deliberado oferece os riscos da produção com a visibilidade limitada de um experimento.

Use uma destas duas configurações. A mais segura dá ao beta um cofre de teste, credenciais de teste, agentes de teste e um conjunto separado de evidências. Assim, é possível testar o comportamento do beta sem permitir que um processo experimental se torne parte do registro de ações de produção.

A configuração mais difícil faz com que estável e beta compartilhem o estado de forma intencional. Escolha-a somente quando a continuidade entre versões for o próprio tema do teste. Nesse caso, teste a diferença de versões nas duas direções: a estável possui o estado e o beta é iniciado, o beta possui o estado e a estável é iniciada, um processo é atualizado enquanto outro continua aberto e um processo reverte depois que o outro grava um novo histórico. Registre se cada transição é recusada, transferida ou coordenada.

Para o Sallyport, a sequência fixa de decisões oferece um critério útil de aceitação: o bloqueio do cofre continua absoluto, um novo processo de agente recebe sua própria autorização de sessão por padrão e as credenciais marcadas para aprovação por chamada continuam solicitando aprovação a cada uso. A implementação pode escolher propriedade exclusiva ou uma transferência segura, mas não pode enfraquecer esses controles silenciosamente para tornar conveniente o uso de dois bundles.

Conclua o teste com uma declaração objetiva que outro engenheiro possa contestar: qual processo era dono do cofre, o que aconteceu quando outra cópia apareceu, se alguma ação atravessou um limite de aprovação ou revogação e se uma única verificação offline cobriu todos os eventos gerados. Se a resposta depender de qual janela você estava observando, execute o teste novamente. As evidências ainda não são boas o bastante.