Como apresentar a gestão de mudanças no GitHub como evidência para ISO/IEC 27001 (ISMS) e SOC 2

Quando uma equipe de desenvolvimento passa por uma auditoria de ISMS (sistema de gestão de segurança da informação segundo a ISO/IEC 27001) ou de SOC 2, a gestão de mudanças quase certamente entra em pauta. Todo o código está no GitHub e as revisões acontecem. Mesmo assim, é uma área em que muitas equipes travam na hora de decidir o que mostrar e como.

Este artigo começa pelo que o auditor quer confirmar na gestão de mudanças e, em seguida, explica as configurações a ajustar no GitHub e como registrar as evidências.

O que o auditor quer confirmar na gestão de mudanças

Os trechos relevantes das normas são estes:

Nenhuma das duas diz "configure o GitHub desta forma". O que se avalia é se você consegue demonstrar, com registros, que as mudanças seguiram o procedimento definido.

Na prática, a verificação costuma seguir este fluxo:

1. O auditor pede a lista de mudanças que entraram em produção durante o período de observação
2. Ele seleciona uma amostra de mudanças dessa lista
3. Para cada mudança selecionada, confirma se uma pessoa diferente de quem a criou aprovou a mudança antes de ela chegar à produção
4. Se houve mudanças emergenciais, confirma se existem aprovação e registro posteriores

Ou seja, você precisa da lista de mudanças do período inteiro e do rastro de aprovação de cada mudança. Se faltar qualquer um dos dois, a explicação fica difícil.

Configurações a ajustar no GitHub

Antes de pensar em evidências, imponha o próprio procedimento pelas configurações do GitHub. Em vez de apenas escrever as regras em um documento, deixe-as num estado que o sistema não permita violar; assim a explicação na auditoria fica bem mais curta.

Na branch que vai para produção (por exemplo, main), configure o seguinte com proteção de branch ou rulesets:

• Exigir pull request antes do merge: fecha o caminho em que um push direto altera o código de produção
• Exigir pelo menos 1 aprovação: não é possível fazer merge sem a aprovação de alguém além do autor
• Descartar aprovações quando houver novos pushes: impede que se acrescentem mudanças às escondidas depois da aprovação
• Não abrir exceção para administradores: se só os administradores puderem contornar a proteção, você não pode afirmar que "todas as mudanças passaram por aprovação"
• Proibir a reescrita forçada do histórico (force push) e a exclusão da branch

Além disso, registre no procedimento de gestão de mudanças "qual branch é a de produção" e "em emergências, quem aprova, como, e o que deve ser registrado depois". A coerência entre as configurações e o procedimento escrito também é verificada na auditoria.

Por que capturas de tela não bastam

Uma forma comum de apresentar evidências é tirar capturas de tela da página do pull request ou da tela de configuração de proteção de branch e colá-las em um documento. Esse método tem fragilidades estruturais.

• Mostra apenas um instante. Uma captura da tela de configuração só prova que a configuração era aquela no momento em que foi tirada. Se a proteção foi removida e restaurada no meio do período de observação, esse fato não aparece
• É difícil confirmar data e origem. A data visível na imagem faz parte da própria imagem, e um terceiro não tem como verificar quando e de onde ela foi obtida
• Coletar dá trabalho toda vez. Procurar e capturar a tela de cada mudança da amostra é um esforço que se repete a cada auditoria

Do lado dos auditores, também cresce a preferência por registros com data atribuída automaticamente e rastreáveis, em vez desse tipo de evidência manual.

Como manter um registro do período inteiro

São dois pontos.

1. Registrar no momento em que a mudança acontece. Em vez de coletar tudo pouco antes da auditoria, registre quando, quem e o quê no instante em que ocorre um push ou o merge de um pull request. Se você coletar depois, perde o que foi apagado ou alterado nesse intervalo.

2. Guardar o registro de forma que a organização avaliada não possa reescrevê-lo depois. O histórico de eventos e o log de auditoria do GitHub são úteis, mas esses registros ficam dentro de um sistema administrado pela própria organização avaliada. Além disso, o período de retenção tem limite e, dependendo do plano, pode não cobrir um período de observação de 6 a 12 meses. Vale a pena conferir qual é a retenção no plano da sua organização.

Para demonstrar que os registros não foram reescritos depois, usa-se o método de encadear a impressão digital (hash) de cada registro à do registro anterior. Se um único registro no meio for alterado, todo o encadeamento a partir dele deixa de bater, de modo que qualquer adulteração é detectada.

O que o SPHIOR faz e o que não faz

A integração do SPHIOR com o GitHub cuida automaticamente dos dois pontos acima.

• Registra eventos como pushes e a criação e o merge de pull requests no momento em que acontecem
• Cada registro inclui o tipo de evento, quem o executou, o horário em que ocorreu e a impressão digital de todo o conteúdo recebido do GitHub. O conteúdo em si não é armazenado
• Os registros são selados com as impressões digitais encadeadas, e qualquer adulteração pode ser detectada. Você também pode exportar um pacote de verificação e conferir por conta própria

Por outro lado, há pontos que o SPHIOR não cobre:

• A ação de aprovação da revisão em si não é registrada no momento. Quanto à aprovação, use a configuração de proteção de branch descrita acima para impor que "não é possível fazer merge sem aprovação", e explique-a com essa configuração e o procedimento escrito
• O SPHIOR não determina se a auditoria será aprovada ou reprovada. O que ele gera são evidências complementares para apresentar ao auditor

No plano gratuito, os registros são mantidos por 90 dias. Quando precisar de registros do período de observação inteiro, você pode mudar para um plano com retenção mais longa (preços).

Resumo

• Na gestão de mudanças, o que se pede é a lista de mudanças do período e o rastro de aprovação de cada mudança
• No GitHub, imponha a aprovação com proteção de branch, sem exceção para administradores
• Uma captura de tela mostra apenas um instante. O caminho seguro é registrar cada evento quando ele acontece, de forma que não possa ser reescrito

Para não precisar capturar telas às pressas pouco antes da auditoria, o atalho é começar a registrar muito antes dela.