Git efetua a auditoria

Question

Eu tenho um servidor git rodando sobre o ssh e cada usuário tem uma conta unix no sistema.

Dado que dois usuários têm acesso a um repositório, como posso ter certeza de qual usuário executou o commit, já que o nome de usuário e o email de commit são submetidos e controlados pelo cliente git.

Estou preocupado que um usuário possa tentar se passar por outro, mesmo que tenha os mesmos direitos de autorização.

    

Answer 1

Se você está preocupado com isso, há algumas maneiras de abordar o problema.

1. Faça seus usuários assinarem seus commits, há suporte para assinatura de GPG.
2. Não conceda aos usuários o direito de se comprometer com o repositório principal, faça com que eles se comprometam com seu próprio subrepositório e depois façam com que um usuário confiável traga as alterações para o repositório principal. É por isso que, se você olhar as mensagens de log de alguns projetos git (como o próprio git), verá que seus campos são separados para "Autor" - a pessoa que criou a alteração. e "Committer" - a pessoa que cometeu a mudança no repositório.

Answer 2

Eu vejo duas boas maneiras de obter esse tipo de informação. Uma delas é aumentando o registro do próprio sshd e o outro fazendo um monitoramento mais profundo do repositório git no disco. Como nenhum deles fornece individualmente as informações desejadas, você pode querer fazer as duas coisas e correlacionar os dados de log usando um mecanismo de análise de log externo ou sob demanda usando olhos humanos e timestamps.

Modificações sshd

Por padrão, como você já viu, você pode ver quando um usuário efetuou login e de onde, usando os logs de autenticação ssh. O que você quer fazer é alterar o nível com o logoff do sshd. Então edite seu /etc/ssh/sshd_config e encontre a linha que se parece com

#LogLevel INFO

e mude isso para

LogLevel VERBOSE

reinicie o serviço sshd. Isso aumenta o nível de log do sshd em 1 etapa, o que fornece muito mais informações. Confira este snippet de log do meu acesso remoto depois de fazer essa alteração.

Nov  2 08:37:09 node1 sshd[4859]: Connection from 10.10.10.5 port 50445
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4860]: Postponed publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: Found matching RSA key: f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06
Nov  2 08:37:10 node1 sshd[4859]: Accepted publickey for scott from 10.10.10.5 port 50445 ssh2
Nov  2 08:37:10 node1 sshd[4859]: pam_unix(sshd:session): session opened for user scott by (uid=0)
Nov  2 08:37:10 node1 sshd[4859]: User child is on pid 4862
Nov  2 08:40:27 node1 sshd[4862]: Connection closed by 10.10.10.5
Nov  2 08:40:27 node1 sshd[4862]: Transferred: sent 30632, received 7024 bytes
Nov  2 08:40:27 node1 sshd[4862]: Closing connection to 10.10.10.5 port 50445
Nov  2 08:40:27 node1 sshd[4859]: pam_unix(sshd:session): session closed for user scott 

As coisas importantes para notar aqui são duas vezes

1. Vemos a impressão digital da chave pública usada para me autenticar
2. Nós vemos o timestamp do meu logoff

Usando o padrão LogLevel (INFO), o sshd não registra nenhum desses itens. Obtendo a impressão digital de uma chave é um passo extra. Você precisa processar o arquivo authorized_keys apropriado com ssh-keygen como tal.

[root@node1 ssh]# ssh-keygen -l -f /home/scott/.ssh/authorized_keys
4096 f2:9e:a1:ca:0c:33:02:37:9b:de:e7:63:d5:f4:25:06 /home/scott/.ssh/authorized_keys (RSA)

Agora você conhece as seguintes informações:

1. Nome de usuário que efetuou login
2. Horário em que o usuário fez login
3. Qual chave pública foi usada para autenticação
4. Horário em que o usuário fez logoff

Agora que temos uma maneira de atribuir a ação do usuário em um horário específico, supondo que os dois usuários não tenham efetuado login ao mesmo tempo, podemos começar a analisar as alterações feitas no repositório.

Monitoramento de diretório com o Auditd

Como sysadmin1138 disse, isso poderia ser um excelente caso de uso para o subsistema auditd. Se você não está usando uma distro baseada no RedHat, provavelmente existe um análogo, mas você terá que encontrá-lo. A configuração do auditd é bastante intensa e possui um número reduzido de opções de configuração. Para ter uma ideia de algumas das opções, confira esta pergunta em nossa irmã site para profissionais de segurança da informação .

No mínimo, eu recomendaria configurar o que é chamado de "watch" no diretório em disco que contém seu repositório git em questão. O que isso faz é instruir o módulo do kernel a relatar tentativas de executar chamadas de acesso a arquivos, como open() ou creat() , em identificadores de arquivos que apontam para os arquivos ou diretórios que listamos.

Aqui está uma configuração de exemplo que faria isso e apenas isso. Portanto, tenha o cuidado de ler e entender seu /etc/audit/audit.rules existente para integrar as alterações adequadamente.

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.

# First rule - delete all
-D

# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024

-w /path/to/git/repos-p wa

# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2

    

Answer 3

A única abordagem técnica que você pode tomar é confiar na identidade da conexão ssh. Você poderia, então, reforçar que cada usuário apenas envia os commits que ele fez validando o committer de cada novo commit enviado.

Para que isso seja confiável, você quase certamente não deseja conceder aos seus usuários acesso irrestrito à caixa onde o repositório reside; você deve garantir o uso de algo como git-shell somente, caso contrário, as restrições serão facilmente corrigidas.

Os usuários ainda poderiam se representar como autores, no entanto. Você poderia restringir isso também, mas isso perderia os fluxos de trabalho comuns, como escolher e rebaixar e talvez até mesmo ramificar (dependendo da implementação do gancho), portanto, talvez você não queira fazer isso.

Em algum ponto, até certo ponto, você precisa confiar em seus desenvolvedores.

    

Answer 4

Muitos daemons ssh fazem uma entrada em /var/log/audit.log ou algo similar quando uma conexão ssh é recebida. A referência cruzada desse log com o log de confirmação deve fornecer uma idéia de qual usuário ssh foi usado para emitir uma confirmação. Esta é uma etapa de auditoria, a ser usada após o fato para verificação.

Na verdade, aplicar o usuário ssh correto ao usuário-git apropriado é uma das outras respostas aqui.

    

Answer 5

Se todos os usuários tiverem contas de shell com acesso de gravação ao repositório, você não poderá configurar um log de auditoria confiável: eles ainda poderão modificar o repositório sem gravar no log e poderão escrever o que quiserem. o log.

Para poder confiar no log de auditoria, você precisaria impedir o acesso direto de gravação em nível de arquivo ao repositório, em vez de usar algo como gitolite (que é executado em sua própria conta) para mediar o acesso ao repositório.