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 ➔ 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 ➔ 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

4. • 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 CaitSith¹⁰. 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.

6. • 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 CaitSith¹¹. 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 CaitSith¹²aplicadas 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 relatórios de eventos

Para visualizar os eventos gerados pela aplicação, acesso no menu GO Endpoint Manager ➔ Relatórios ➔ Eventos:

ID: Numéro do identificador do evento.

Usuário: Usuário no sistema que gerou o evento na aplicação do senhasegura.go.

Área de Trabalho: Qual sistema operacional esta sendo usado.

Domínio: Domínio que esta sendo usado pela aplicação.

Evento: Qual tipo de evento foi gerado.

Ação do uso: Se houve alguma ação relacionada a este evento.

Executado: Se foi executado algo relacionado a este evento.

Credencial usada: Se esta sendo usada uma credencial relacionada a aplicação do senhasegura.go ela aparecerá aqui.

Tipo: Qual o tipo de evento.

Data/Tempo: Data e hora que o evento ocorreu na aplicação.

Ações: Visualizar o evento ocorrido.

Visualizar logs de comando de relatório

No módulo GO Endpoint Manager ➔ Relatórios ➔ Logs de comandos 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.

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