Pular para o conteúdo principal
Version: 3.25

Controle de acesso

Deste ponto em diante, o dispositivo alvo já está informando ao senhasegura quais usuários ele possuí e solicitando diretivas de bloqueio e auditoria. Iremos então aprovar o dispositivo e cadastrar nossa primeira diretiva.

Autorizando dispositivos​

Através do menu GO Endpoint Manager ➔ Workstations você terá a relação de dispositivos que estão utilizando as diretivas do senhasegura.go for Linux, dispositivos que tiveram permissão revogada e dispositivos que estão com permissão pendente de aprovação. Neste nosso exemplo, nosso dispositivo recém instalado está pendente. Veja na imagem.

Dispositivo pendente de aprovação

Repare que a coluna Status que representa este estado de pendente. Este estado pode variar entre ativado para dispositivos aprovados e desativado para dispositivos revogados.

Para aprovar o uso, clique na ação de registro Aprovar.

Uma vez aprovado, esta workstation passará a receber as diretivas que cadastraremos adiante.

Cadastrando diretivas a nível de kernel​

caution

Atenção! Diretivas proibitivas podem causar grandes danos ao dispositivo. Podendo levar ao bloqueio total de interatividade.

Através do menu GO Endpoint Manager ➔ Policies ➔ Linux ➔ Access Policies você poderá visualizar e gerenciar todas diretivas cadastradas. As diretivas são segregadas em três níveis.

  • Gerais: Diretivas que são aplicadas a todos dispositivos onde o senhasegura.go for Linux estiver ativo e aprovado

  • Por dispositivo: Diretivas aplicadas a dispositivos específicos

  • Por username: Diretivas que são aplicadas apenas nos dispositivos que contenha o username específico.

Para entendermos melhor seu uso, vamos apresentar o seguinte problema.

Dentro de uma corporação, o DBA é um funcionário contratado e de alta confiança. Já o suporte aos sistemas operacionais é realizado por uma empresa contratada.par A empresa contratada detém um usuário de alto privilégio para executar atualizações e manutenções no dispositivo. Sendo assim, estes funcionários terceirizados acabam tendo acesso ao arquivo de configuração do Oracle® orrendo o risco de altera-lo.par% O Gestor de Segurança da Informação e o DBA gostariam de proteger a escrita neste arquivo de forma centralizada sem ter que criar diversos grupos auxiliares servidor a servidor, correndo o risco de perder o controle dos membros destes grupos.

Neste caso, será necessário criar uma diretiva no senhasegura.go for Linux informando que apenas o usuário DBA tem permissão de escrita no arquivo alvo. Desta forma, nem mesmo o super usuário terá como alterar seu conteúdo. Mesmo que ele detenha autoridade sobre o arquivo.

Siga os passos a seguir para configurarmos este cenário.

  1. Acesse o relatório de diretiva através do menu GO Endpoint Manager ➔ Policies ➔ Linux ➔ Access Policies

  2. Clique na ação de relatório New Rule para criarmos uma diretiva global

  3. No formulário que se abre, preencha os campos da seguinte forma

    • Identification name: Nome da diretiva. Campo obrigatório. Este nome deve ser amigável para que seja fácilmente identificável. Não será repassado ao dispositivo alvo. Neste exemplo, preencheremos com "Deny TNS changes"

    • Enable audit: Indica se será habilitado a auditoria de ações que se enquadram nesta diretiva. O campo é obrigatório e por padrão vem ativo. Manteremos como ativo.

    • Enabled: Estado da diretiva. Campo obrigatório. Se ativo, a diretiva será considerada nos dispositivos alvo. Caso contrário, não será aplicada. Manteremos como ativo.

    • Guideline: Diretiva de kernel a ser monitorada. Campo obrigatório. Estas ações são provenientes das ações suportadas pela biblioteca CaitSith10. Utilizaremos a diretiva "Write file". Essa diretiva irá identificar o momento que uma tentativa de escrita em arquivo ocorrer.

    • Checker: Alvo da diretiva. Apesar deste campo não ser obrigatório, tenha muito cuidado ao não preenche-lo. O não preenchimento ou o preenchimento incorreto deste campo pode levar a completa inutilização do dispositivo.

      Neste exemplo, iremos preencher a variável path com o local do nosso arquivo alvo. Exemplo: path=˝/etc/oracle/tnsnames.ora˝

    • Include general denial rule?: Indicador se a diretiva de negar a todos deve ser considerada no momento que esta diretiva for aplicada. Por possibilitar ações a usuários específicos, é interessante que aos demais usuários este privilégio seja negado. Manteremos marcado em nosso exemplo. Campo obrigatório.

  5. Até este momento, cadastramos as características da diretiva a ser cadastrada. Agora iremos indicar os usuários que tem permissão ou proibição de execução da diretiva.

    • Allow or deny: Indica se cadastraremos uma diretiva de permissão ou negação ao usuário. Em nosso exemplo iremos cadastrar uma diretiva de Allow para nosso usuário DBA

    • Rule text: Agora colocaremos nosso username dba dentro do formato de diretivas do CaitSith11. Exemplo: task.uid=˝dba˝. Isso indica que se o processo que se enquadra a diretiva tiver o UID do username DBA, essa diretiva será aceita.

  7. Salve o registro e observe o resultado no dispositivo alvo!

Quaisquer comandos que passarem por um processo de filtragem e que foi definida uma regra para permitir a execução dentro de Access Policies (caitsith) ou Rules for sudo se a execução do comando foi permitida através das Acess Policies, será gravado.

Uma vez que o usuário rodar algum comando que esteja em Access Policies, o sistema automaticamente começará a gravar a sessão.

O início da sessão será vinculado com o PID do processo, e portanto, quando esse PID e todos os processos que foram gerados por esse PID e forem encerrados, a gravação deverá ser encerrada.

caution

Atenção! Os campos Checker e Rule text, apesar de não serem obrigatórios, requerem muito cuidado. O não preenchimento ou o preenchimento incorreto deste campo pode levar a completa inutilização do dispositivo. E seus valores devem estar envoltos de aspas-duplas conforme o exemplo.

Validando a diretiva no dispositivo alvo​

Voltaremos então ao nosso exemplo evidênciando:

  • que a regra foi criada no dispositivo destino;

  • que o usuário DBA tem permissão de escrita no arquivo; e

  • que o super usuário não poderá escrever no arquivo

Validando a diretiva​

Exiba o arquivo /sys/kernel/security/caitsith/policy para verificar as regras padrão CaitSith12aplicadas no dispositivo.

root\@debian:/root# cat /sys/kernel/security/caitsith/policy 
POLICY_VERSION=20120401 
stat Policy updated: 9036 (Last: 2019/12/24 00:31:57) 
stat Requests denied: 10 (Last: 2019/12/23 18:55:22) 
stat Memory used by policy: 4512 
stat Memory used by audit: 63808 
stat Memory used by query: 0 
quota memory audit 16777216 
quota memory query 1048576 
quota audit\[1\] allowed=0 denied=1024 unmatched=1024 
 
**1**00 acl write path="/etc/oracle/tnsnames.ora" 
audit 1 
100 allow task.uid=1002 
200 deny

A saída acima apresenta alguns status que não são importantes neste momento. Mas repare que o texto em destaque apresenta exatamente a regra que criamos anteriormente. O senhasegura.go for Linux realizou inclusive a tradução do username dba para seu correto UID, tendo em vista que nem sempre este será o UID em cada dispositivo.

Escrevendo no arquivo como usuário dba​

Agora iremos inserir um conteúdo ao arquivo alvo como usuário dba. Conforme a regra aplicada, deve ser aceita. Repare que o usuário dba consegue escrever no arquivo

O usuário dba consegue escrever no arquivo

Tentando escrever no arquivo como super-usuário​

Já o super-usuário não conseguirá escrever no arquivo, uma vez que este usuário está na regra de negação da diretiva criada. Mesmo sendo super-usuário, a tentativa de escrita falha.

O usuário root não consegue escrever no arquivo

Visualizar logs de comando de relatório

No módulo GO Endpoint Manager ➔ Reports ➔ Linux ➔ Command logs você visualiza o relatório dos comandos executados na aplicação, neste relatório temos estas informações:

ID: Numéro do identificador do evento.

Comandos do usuário: Comando digitado pelo usuário.

Comandos executados: Comando executado na máquina.

Status: Status atual do comando.

Data do evento: Quando o evento ocorreu na máquina.

No módulo GO Endpoint Manager ➔ Reports ➔ Linux ➔ Sudo usage você visualiza o relatório dos comandos executados com permissões de sudo, neste relatório temos estas informações:

Pontos de atenção e solução de problemas

Como dito anteriormente, diretivas escritas sem um recurso ou usuário alvo, acabam valendo para todo sistema, aumentando o risco de um bloqueio total no sistema.

O serviço secpack-maestro estará sempre em execução e atualizando as regras conforme elas forem cadastradas no senhasegura . Mas caso exista a necessidade de uma intervenção manual no dispositivo, execute o seguinte procedimento:

  1. Utilizando o usuário root, interrompa a execução do serviço secpack-maestro

    service secpack-maestro stop

  2. Execute o binário caitsith-loadpolicy para remover as diretivas desejadas. Removeremos como exemplo a diretiva criada anteriormente.

    echo 'delete 100 acl write path="/etc/oracle/tnsnames.ora"' \| /usr/sbin/caitsith-loadpolicy

  3. Valide que a diretiva foi removida verificando novamente o arquivo aplicado

    cat /sys/kernel/security/caitsith/policy

  4. Realize as mudanças no senhasegura para que a regra não seja aplicada novamente

  5. Inicie novamente o serviço secpack-maestro

    service secpack-maestro start