Controle de acesso host based em ambientes distribuídos

Fabiano Fernandes Wowk

Especialização em Redes e Segurança de Sistemas

Pontifícia Universidade Católica do Paraná

Curitiba, 14 de novembro de 2009

Resumo

Este estudo de caso tem por objetivo demonstrar o uso de políticas de controle de

acesso em ambientes distribuídos. Neste estudo é utilizado um padrão de segurança proposto

para um ambiente hipotético, que será objeto de análise e implementação em um produto de

controle de acesso baseado em host.

1 Introdução

Ao efetuarmos uma análise dos controles de segurança em um ambiente hipotético,

que adota a plataforma de Servidores UNIX/Linux, identificamos que não são adotados

padrões de controle de acesso, ou preocupações quanto à restrição do uso de informação para

usuários com perfis de administrador de sistemas, ou qualquer limitação de poderes que os

mesmos possuem neste ambiente computacional.

O objetivo deste estudo de caso é efetuar uma análise dos controles de segurança

adotados na plataforma de Servidores UNIX/Linux, e propor uma padronização de segurança

e mostrar exemplos de caso de uso.

2 Descrição do Contexto

Para tratar do controle de segurança deste ambiente hipotético, alguns padrões de

segurança foram considerados inicialmente. Estes padrões não seguem uma norma de

segurança formal, sendo padrões comumente utilizados em projetos de segurança da

informação, descritos por Dan Sullivan [1]. Cada um dos padrões escolhidos para o contexto

deste trabalho são descritos e detalhados abaixo:

Administração Delegada – Estabelecer métodos e controles de maneira que todos os

usuários que possuam acesso aos sistemas Operacionais UNIX/Linux, possuam

identificação pessoal única (UserID) e que esta identificação possa ser validada por

técnica de autenticação adequada. Usuários privilegiados de acesso, tais como root,

usuários de aplicação e usuários genéricos, não devem permitir acesso de logon

diretamente, e podem ser somente utilizados pela aplicação hospedada no servidor

local, recomenda-se que a senha destes usuários seja armazenada em um cofre de

segurança ou local com dispositivo de controle de acesso físico, e geradas por um

processo de dupla custódia. As permissões de acesso necessárias para a

administração do ambiente (sistemas operacionais, ou aplicações utilizadas), devem

ser atribuídas os usuários ou grupos de usuários identificados pela identificação

pessoal única, descrita acima, possibilitando o uso de comandos irrestritos e até as

operações de substitute user (SU) desde que totalmente auditadas e que garantam a

rastreabilidade, permitindo atribuir a operação ao usuário responsável pela mesma.

Coleta de logs de auditoria centralizada – Implementar a unificação de logs de

segurança, e utilizar local armazenamento diferente do padrão do sistema operacional

(exemplo: /var/log/secure, /var/adm/sulog), impossibilitando desta forma a

adulteração de logs por usuários com privilégios de administração do sistema. Os logs

deverão estar acessíveis para usuários com perfil de auditores de segurança somente.

Gestão de política de segurança centralizada – Possibilitar o gerenciamento ou

visão das regras de controle de acesso de forma única, facilitando o gerenciamento

para os Administradores de Segurança.

Limitar os direitos de acesso aos recursos – Limitar direitos de acesso aos recursos

e aplicações disponibilizados nos servidores. Utilizando políticas de controle de

acesso associadas à perfis de atuação (Role Based Access Control - RBAC), descritos

por David Ferraiolo, D. Richard Kuhn, Ramaswamy Chandramouli [2].

Políticas de senhas rígidas nos servidores – Estabelecer uma política de senha única

e consistente nos servidores.

Regras de controle de acesso consistente em todos servidores - Estabelecer uma

política de segurança que possa abranger todos os sistemas operacionais UNIX/Linux

utilizados no ambiente, independente de versão ou local instalação.

Um resumo da situação atual, com base em controles de segurança considerados, é

exibido na Tabela 1, abaixo:

Padrões de

Segurança

Desvio/Problema com a Situação Atual

Administração

Delegada

Os procedimentos de Suporte para a plataforma UNIX/Linux não

estabelecem qualquer forma de acesso delegado às contas de

"superusuários" em plataformas UNIX/Linux, a senha para a conta

"root" em um servidor UNIX/Linux é geralmente conhecida por todos

os administradores de sistemas UNIX/Linux.

Coleta de logs de

auditoria

centralizada

Os logs de Auditoria são armazenados de forma independente em cada

servidor, residindo em armazenamento próprio de auditoria (arquivos

de logs). Os eventos de Auditoria variam entre os servidores,

conforme nível de auditabilidade ligado. Nenhuma solução é provida

para a normalização dos dados de auditoria.

Sessões não são mapeadas para a conta de “login” associada ao

administrador de sistemas, sendo que uma ação do administrador de

sistema enquanto estiver utilizando privilégios de “superusuário” não

é possível.

Para efeitos de auditoria devem ser coletados os dados armazenados

em cada servidor e juntar manualmente os resultados para entender o

histórico de acesso de cada usuário. Isso demanda um esforço

considerável e grande possibilidade de erro devido à manipulação

manual de informações.

Padrões de

Segurança

Desvio/Problema com a Situação Atual

Gestão de política

de segurança

centralizada

Cada equipe de administradores de sistemas pode gerenciar as

políticas de segurança de forma diferente para os seus servidores

designados. Os sistemas operacionais dos servidores têm diferentes

capacidades para impor políticas. Os procedimentos variam entre cada

equipe de administradores de sistemas. Desta forma não tem uma

ferramenta para gerenciar de forma centralizada ou rever as

configurações de política de segurança em todos os servidores.

Direitos de acesso

aos recursos

Não há regras consistentes de controles de acesso em todos os

servidores para proteger o conteúdo de aplicações ou informações

armazenadas nos servidores. Membros de grupos administradores de

sistemas podem acessar qualquer conteúdo do servidor diretamente, e

não são restritos por ferramentas nenhuma regra ou escopo de controle

de mudanças.

Políticas de senhas

rígidas nos

servidores

Cada servidor implanta seu próprio sistema de autenticação de forma

eficaz gerenciando as senhas localmente. Não existem controles para

aplicar políticas de senhas relacionadas ao conteúdo de senha ou

execução de expiração de senha para contas de sistema ou serviço de

forma consistente.

Fornecer regras de

controle de acesso

consistente em

todos os

servidores

Cada servidor que hospeda a aplicação ou contém armazenamento de

informação do cliente, possui um controle de acesso dependente do

sistema operacional, versão e release. Não sendo possível obter um

controle de acesso consistente em todas as plataformas.

Tabela 1: Situação atual do ambiente considerado para estudo de caso

Com base nas descrições do ambiente atual, foi montado um projeto para atendimento

das necessidades de segurança do sistema proposto.

3 Descrição do Projeto

Para atendimento da padronização de segurança proposta, os mecanismos de

segurança disponíveis nos sistemas operacionais mostram uma deficiência, sendo que as

principais deficiências são citadas abaixo.

Acesso usuário “root”: o acesso ao super-usuário é feito através da senha da conta

root, não importa se através de logon na console do sistema operacional, via serviço

de console remota SSH ou através do comando substitute user (SU), impossibilitando

desta forma o armazenamento seguro conforme previsto;

Cotrole de acesso aos super-usuários: ao possibilitar o acesso ao usuário

privilegiado não é possível utilizar mecanismos de auditoria e rastreabilidade

eficientes, pois os usuários ao efetuarem acesso com uma conta genérica, ou após uso

do comando SU, não são mais auditados pelo usuário real nos logs do sistema

operacional Unix;

Comandos remotos usam autenticações baseadas em host: não é possível bloquear

a habilitação de comandos remotos como rsh, rexec ou rcp, visto que os mesmos

utilizam autenticação por equivalência de hosts e podem burlar o controle de acesso

de um host remoto;

Controle de acesso por usuário em aplicação: não é possível prevenir o uso da

conta root e todos outros usuários privilegiados em aplicações como SSH, FTP,

Telnet;

Uso da conta root sem senha: não é possível possibilitar a elevação de privilégios

sem conhecer a senha do usuário destino;

Limitar o Administrador – o bloqueio ao acesso de substititute user (SU) do root

para outras contas do sistema operacional não é feito pelos sistemas operacionais;

Para suprir as deficiências dos sistemas operacionais, iremos utilizar um sistema de

controle de acesso baseado em host, para esta função foi escolhido um software comercial

denominado CA Access Control, pois o mesmo suporta as plataformas UNIX/Linux

desejadas e supre as deficiências principais listadas acima.

O produto CA Access Control foi desenvolvido para aumentar as funcionalidades de

gerenciamento de usuário e controle de acesso aos recursos do Sistema Operacional. O

desenvolvimento do produto foi iniciado em 1980 por vários ex-programadores da IBM que

se perguntaram por que não portar ou desenvolver um pacote de segurança semelhante ao

utilizado nos Mainframes IBM, chamado RACF (Remote Access Facility) para a plataforma

UNIX/Linux e chamá-lo de SEOS (Security Enhanced Operating System). Atualmente o

produto também suporta a plataforma Windows.

O conceito básico de funcionamento é a inserção de uma camada de segurança entre o

kernel do sistema e as chamadas de sistema (system calls) específicas de segurança. Essa

camada intercepta todas as chamadas de sistema que tem relação com a segurança e efetua

uma comparação com as regras de segurança disponíveis em uma base local. Desta forma, a

aplicação SEOS pode determinar se uma determinada requisição tem privilégios para acessar

os dados ou executar um comando.

A liberação ou bloqueio de acesso de recursos é definido através da criação de regras para

os objetos (recursos) que serão alvo da política de segurança. O usuário não percebe o

funcionamento da aplicação e da camada de segurança, pois as respostas de comandos são

fornecidas da mesma forma pelo sistema operacional (mensagens de sucesso ou erro). Cada

host que será protegido deve ter o produto instalado localmente, sendo que a política de

segurança será sempre armazenada localmente.

3.1 Abrangências dos recursos para controle de acesso

Os recursos disponíveis para controle através da aplicação CA Access Control, que foram

utilizados nesta análise são descritos abaixo. Estes recursos são definidos através da console

do produto, sempre gerando as permissões em linguagem própria denominada SELANG na

base de dados local de políticas de segurança.

Os recursos especificados nas regras de política de segurança podem ser criados sempre

em dois modos: enforcement – modo padrão que efetua o controle do recurso conforme

definido na regra de controle de acesso, warning mode – modo que não efetua o bloqueio

conforme definido na regra de controle de acesso (só gera um evento de auditoria para cada

acesso não conforme com a especificação de controle de acesso do recurso).

Este último é utilizado na implementação inicial de regras, permitindo ao administrador

de segurança a avaliar se operações legítimas não estão sendo bloqueadas por erro de

especificação na regra de controle de acesso.

Os recursos para controle de acesso considerado, conforme documentação [3,4,5,6] são

listados a seguir:

3.1.1 Proteções de Arquivos e Processos

Arquivos – Classe FILE – esta classe é utilizada no controle de acesso aos arquivos

e diretórios do sistema operacional, a criação de regras é baseada no conceito de ACL

para o objeto desejado, aonde devemos sempre atribuir uma permissão de acesso

padrão (default access) para o objeto, e como opcional podemos atribuir autorizações

específicas para usuários ou grupos de usuários do sistema operacional com a seguinte

granularidade:

o READ: autorização de leitura no(s) arquivo(s) ou diretório(s);

o WRITE: autorização de gravação no(s) arquivo(s) ou diretório(s);

o DELETE: autorização de remoção do(s) arquivo(s) ou diretório(s);

o RENAME: autorização de renomear o(s) arquivo(s) ou diretório(s);

o CREATE: autorização de criar o(s) arquivo(s) ou diretório(s);

o EXECUTE: autorização de executar o(s) arquivo(s) ou diretório(s);

o CHOWN: autorização para modificar dono do(s) arquivo(s) ou diretório(s);

o CHMOD: autorização para modificar permissões de acesso nativas do Sistema

Operacional do(s) arquivo(s) ou diretório(s);

o UTIME: autorização de atualizar data e hora do(s) arquivo(s) ou diretório(s);

o SEC: autorização de alterar parâmetros de ACL estendida do Sistema

Operacional quando disponível o(s) arquivo(s) ou diretório(s);

o CHDIR: autorização para mudar de diretório(s);

Um exemplo de uso desta proteção é a definição de permissão para somente

leitura do arquivo /etc/shadow (arquivo de armazenamento de senhas do sistema operacional

Linux) a todos os usuários do sistema operacional, os acessos ao recurso especificado serão

auditados quanto a falha. Após é concedida a permissão de alteração através do comando

/bin/passwd. Os comandos são descritos abaixo:

SELANG> newres FILE /etc/shadow defaultacc(r) owner(nobody) audit(f)

SELANG> auth FILE /etc/shadow access(READ,WRITE,UTIME) uid(*)

via(pgm(/bin/passwd)

Figura 1: Exemplo de controle de arquivo condicional

Processos – Classe PROCESS – esta classe é utilizada no controle de envio de sinais

(KILL, TERM, STOP) para os processos em execução, prevenindo o encerramento do

mesmo.

Um exemplo deste caso seria bloquear um usuário mesmo utilizando

privilégios de adminitrativos encerre o daemon SSH. Os comandos são descritos abaixo:

SELANG> newres PROCESS (/usr/sbin/sshd) defaccess(n) owner(nobody) audit(f)

Figura 2: Regra de controle de acesso de processo

Um exemplo do funcionamento deste exemplo é mostrado na figura abaixo:

Figura 3: Exemplo de utilização da regra de controle de processo

3.1.2 Definição de base computacional segura

Programas – Classe PROGRAM – esta classe é utilizada no controle de programas

(integridade e acesso dos usuários), sendo que a integridade dos mesmos é

monitorada, os atributos avaliados para a integridade são:

o Mtime – Data e hora da última modificação;

o Ctime – Data e hora da criação do arquivo;

o Mode – Permissão do arquivo;

o Size – Tamanho do arquivo;

o Device – Dispositivo em que o arquivo reside;

o Inode – Inode de alocação inicial do arquivo;

o Crc – Hash CRC do arquivo;

o Sha1 – Hash Sha1 do arquivo;

o Owner – Permissão de Dono do arquivo;

o Group – Permissão de Grupo do arquivo

Caso um dos parâmetros descritos acima seja alterado o programa se torna não

confiável (Untrusted), tendo sua execução negada para qualquer usuário.

Arquivos de Configuração ou Scripts - Classe SECFILE - Esta classe é utilizada

no controle de arquivos de configuração e scripts (integridade e acesso dos usuários),

sendo que a integridade dos mesmos é monitorada, os atributos avaliados para a

integridade são:

o Mtime – Data e hora da última modificação;

o Ctime – Data e hora da criação do arquivo;

o Mode – Permissão do arquivo;

o Size – Tamanho do arquivo;

o Device – Dispositivo em que o arquivo reside;

o Inode – Inode de alocação inicial do arquivo;

o Crc – Hash CRC do arquivo;

o Sha1 – Hash Sha1 do arquivo;

o Owner – Permissão de Dono do arquivo;

o Group – Permissão de Grupo do arquivo;

Caso um dos parâmetros descritos acima seja alterado o arquivo se torna não

confiável (Untrusted), sendo gerado um log de auditoria da modificação.

3.1.3 Controle de acesso à Identidade do Usuário

Substitute User (SU) – Classe SURROGATE – esta classe especifica quem pode

efetuar uma operação de substitute user (su), podemos definir os usuários ou grupos

de origem que terão acesso aos privilégios do usuário destino.

O acesso aos usuários destino através do comando “su” pode ser feita sem o conhecimento da

senha do usuário destino, somente com base na ACL definida na regra de controle de acesso,

podendo também solicitar a confirmação da identidade do usuário origem através da

confirmação de sua senha (ou método de autenticação utilizado).

Um exemplo deste caso seria perrmitir que o usuário Fabiano, tenha privilégios de “root”

efetuando a operação de “su” para o usuário root sem conhecimento da senha do usuário root.

Seguem comandos necessários:

SELANG> editres surrogate user.root defaccess(n) owner(nobody) audit(all)

SELANG >auth surrogate user.root uid(fabiano) access(r)

SELANG> auth surrogate user.root uid(fabiano) via(pgm(/opt/CA/AccessControl/bin/sesu))

access(r)

Figura 4: Regra de controle de acesso para identidade do usuário root

Um exemplo do funcionamento deste exemplo é mostrado na figura abaixo:

Figura 5: Exemplo de funcionamento da regra de controle de acesso para identidade do

usuário root

3.1.4 Restrições de Login de Usuários

Programas de Logon – Classe LOGINAPPL – esta classe define os programas que

podem ser utilizados para efetuar logon no sistema operacional, os mais comumente

utilizados são (/bin/login, /usr/sbin/sshd, /usr/sbin/vsftpd) todos os programas de

logon padrão existentes no sistema operacional tem regras criadas por padrão na

instalação do produto CA Access Control. Através delas podemos impedir que sejam

utilizados os usuários privilegiados para logon remoto, desta forma tornando a senha

dos mesmos sem efeito ou importância.

Um exemplo de uso desta restrição seria bloquear o acesso ao usuário oracle

através do comando do protocolo ssh.

SELANG> auth loginappl SSH uid(oracle) access(n)

Figura 6: Regra de controle de acesso para aplicação SSH

Um exemplo do funcionamento deste exemplo é mostrado na figura abaixo:

Figura 7: Funcionamento da regra de controle de acesso para aplicação SSH

Figura 8: Log de bloqueio da regra de controle de acesso para a aplicação SSH

3.1.5 Gerenciamento de senhas

Qualidade de senhas – Classe PASSWORD – estabelece uma política de senhas

independente do sistema operacional (a qualidade de senhas do sistema operacional

pode estar desligada), desta forma podemos ter senhas com qualidade em qualquer

tipo de sistema operacional suportado.

Um exemplo da gestão de qualidade de senhas é mostrado abaixo:

Figura 9: Regra de controle de acesso para qualidade de senha

Após avaliarmos e demonstrarmos algumas das principais funcionalidades do controle

de acesso baseado em Host do produto CA Access Control, estabelecemos as regras de

controle de acesso para atendimento dos padrões de segurança propostos.

Padrão de

Segurança

Descrição do que “Será Feito” Grupo de regras de

controle de acesso

Administração

Delegada

Todas as tarefas de administração serão

autorizadas pelo componente de segurança

de host, com base no grupo ou privilégios

do usuário autenticado. Qualquer tarefa de

manutenção no sistema que requisitar

acesso à conta de “superusuário”, seja por

administradores de sistema ou auditores,

deve ser garantida mediante delegação de

poderes da conta de “superusuário” ao

usuário autenticado

Administração Delegada

Logs de auditoria

centralizados

Pedidos de autenticação e autorização de

todos os recursos protegidos serão

registrados em um repositório único de

auditoria

Resposta da Auditoria

Gestão de política

centralizada

Uma aplicação de gerenciamento central de

políticas deve prover uma interface única

para a administração e definição de

políticas de controle de acesso para o

ambiente Unix/Linux

Gestão de Políticas de

Segurança

Direitos de acesso

aos recursos

A Solução irá fornecer fortes controles de

acesso limitando diretamente, o acesso

baseado em host para aplicações, e

informações do cliente, através princípio

need-to-know.

Controle de Acesso aos

Recursos do Sistema

Operacional

Políticas de senhas

rígidas nos

servidores

Através de definição de padrões de

segurança para complexidade da senha e as

opções de aplicação, exigindo

periodicamente que o usuário altere as

senhas e desabilitando o acesso depois de

várias tentativas.

Políticas de Senha

Comum

Regras de controle

de acesso

consistente em

todos os servidores

Uma estrutura de segurança comum com

ferramentas centralizadas para uso dos

administradores de segurança que definirão

políticas de controle de acesso para

autorização de acesso à aplicações,

conteúdos ou informações do cliente.

Estrutura de Controle de

Acesso baseada em Host

Tabela 2: Situação proposta para estudo de caso

Segue, detalhamento do grupo de regras de controle de acesso proposto:

Administração delegada

Regra 1 - Permitir somente acesso ao usuário destino via comando su, mediante regra de

autorização, objetivo: bloquear o usuário root de acessar perfis de outros usuários.

SELANG> editres SURROGATE USER._default audit(ALL) defaccess(NONE)

Regra 2 - Permitir somente acesso ao usuário ORACLE, dos integrantes do grupo DBA, e o

acesso do usuário root para comandos de start do banco de dados.

SELANG> editres SURROGATE USER.oracle audit(ALL) defaccess(NONE)

SELANG> auth SURROGATE USER.oracle gid(dba) access(R)

SELANG> auth SURROGATE USER.oracle uid(root) access(R)

SELANG> auth SURROGATE USER.oracle gid(dba) access(R)

via(pgm(/opt/CA/AccessControl/sesu))

SELANG> auth SURROGATE USER.oracle uid(root) access(R)

via(pgm(/opt/CA/AccessControl/sesu))

Regra 3 - Permitir somente acesso ao usuário ROOT, dos integrantes do grupo

SYSADMINS.

SELANG> editres SURROGATE USER.root audit(ALL) defaccess(NONE)

SELANG> auth SURROGATE USER.root gid(sysadmins)access(r)

via(pgm(/opt/CA/AccessControl/sesu))

Regra 4 – Não permitir logon com os usuários root ou oracle, através do SSH .

SELANG> auth loginappl SSH uid(root) access(n)

SELANG>auth loginappl SSH uid(oracle) access(n)

Resposta da Auditoria

Todos as regras criadas no sistema de controle de Acesso, geram logs de auditoria, que são

coletados localmente, com armazenamento específico em diretório próprio da aplicação

(/opt/CA/AccessControl/logs), estes logs são também consolidados em um servidor

específico designado para unificação de logs, e somente serão acessíveis para os participantes

do grupo Auditores. . Os Auditores recebem o parâmetro de AUDITOR dentro da base de

regras do CA Access Control, e necessitam ter os terminais de acesso (Nome ou IP da

máquina remota) autorizados para tais operações.

Gestão de políticas de segurança

A gestão de política de segurança torna-se possível em todos os servidores, e não há diferença

no método de implementação, uma vez que a linguagem SELANG será o ponto de referência

para a criação de regras, estas regras podem ser gerenciadas localmente, ou através de

consoles remotas de maneira unificada pelos administradores de aegurança designados. Esses

administradores de segurança recebem o parâmetro de ADMIN dentro da base de regras do

CA Access Control, e necessitam ter os terminais de acesso (Nome ou IP da máquina remota)

autorizados para tais operações.

Controle de acesso aos recursos do Sistema Operacional

Regra 1 – Permitir leitura no arquivo /etc/passwd e /etc/shadow e alterações somente pelo

comando passwd.

editres FILE /etc/passwd audit(FAILURE) defaccess(READ)

auth FILE /etc/passwd uid(*) access(all) via(pgm(/usr/sbin/passwd))

editres FILE /etc/shadow audit(FAILURE) defaccess(READ)

auth FILE /etc/shadow uid(*) access(all) via(pgm(/usr/sbin/passwd))

Regra 2 - Permitir o uso dos comandos passwd e sesu, registrando os respectivos binários

contra alterações.

SELANG> editres PROGRAM /opt/CA/AccessControl/bin/sesu audit(FAILURE)

defaccess(EXECUTE) owner('nobody') flags(ALL)

SELANG> editres PROGRAM /usr/sbin/passwd audit(FAILURE) defaccess(EXECUTE)

owner('nobody') flags(ALL)

Regra 3 – Bloquear qualquer uso de equivalência para logon via comandos R* (RSH,

REXEC, RCP) ou SSH, caso os arquivos já sejam existentes o acesso será negado, se não

existirem isso impossibilitará a criação dos mesmos.

editres FILE /home/*/.rhosts audit(FAILURE) defaccess(NONE)

editres FILE /home/*/.ssh/* audit(FAILURE) defaccess(NONE)

editres FILE /root/.rhosts audit(FAILURE) defaccess(NONE)

editres FILE /root/.ssh/* audit(FAILURE) defaccess(NONE)

Regra 4 – Controlar acesso ao diretório da aplicação Oracle, permitindo somente leitura e

execução dos arquivos nos subdiretórios e mudança de diretório para todos usuários. Os

usuários do grupo DBA podem ter acesso irrestrito.

editres FILE /export/oracle/* audit(FAILURE) defaccess(READ EXECUTE CHDIR)

auth FILE /export/oracle/* gid(DBA) access(all)

Políticas de senha comum

Com a política de controle de senhas através da ferramenta de controle de acesso,

conseguimos estabelecer uma política de senha independente dos recursos disponibilizados

pelo fornecedor do sistema operacional, sendo estabelecida a política abaixo.

Data for CA Access Control options

Password rules :

Alpha : 5

Alphanumeric : 2

Gracelogins : 6

History : 12

Interval : 40

Password min life : 2

Min length : 10

Max length : 25

Sub str length : 0

Lower : 1

Max rep : 2

Numeric : 1

Special : 1

Upper : 1

Old PW check : Yes

Name check : Yes

Dictionary format : file

Bidirectional : No

Prohibited chars :

Estrutura de Controle de Acesso baseada em Host

Através da adoção de controles de acesso baseados em host, os controles de segurança

tradicionais podem ser aprimorados, e até mesmo migrados para uma regra corporativa

padrão, possibilitando desta forma uma ampla visibilidade das regras de segurança adotadas,

independente de plataforma, versão de sistema operacional e procedimentos adotados pelos

administradores de segurança.

4 Procedimentos de teste e avaliação

4.1 Administração delegada

Regra 1 - Permitir somente acesso ao usuário destino via comando su, mediante regra de

autorização, objetivo: bloquear o usuário root de acessar perfis de outros usuários.

Figura 10: Controle de acesso do usuário root para outras identidades

Na figura acima demonstramos o funcionamento da regra, através do seguinte

procedimento. Efetuamos logon no sistema operacional com o usuário root, após executamos

o comando de substitute user (su) para um usuário normal do sistema operacional (neste caso

Fabiano), o procedimento retornou, que a operação não é possível conforme definição da

regra de acesso.

Abaixo trecho do log que demonstra o bloqueio da operação.

Figura 11: Log de bloqueio de acesso do usuário root para outras identidades

Regra 2 - Permitir somente acesso ao usuário ORACLE, dos integrantes do grupo DBA, e o

acesso do usuário root para comandos de start do banco de dados.

Validação da regra – Operação válida

Figura 12: Controle de acesso da identidade do usuário oracle

Na figura acima demonstramos o funcionamento da regra, através do seguinte

procedimento. Efetuamos logon no sistema operacional com o usuário normal denominado

dba_user, o qual é participante do grupo dba, após executamos o comando de substitute user

(su) para o usuário privilegiado de aplicação (neste caso oracle), foi solicitada a confirmação

da senha pessoal do usuário dba_user, conforme definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 13: Log de permissão de acesso para a identidade do usuário oracle

Validação da regra – Operação inválida

Figura 14: Log de bloqueio de acesso para a identidade do usuário oracle

Na figura acima demonstramos o funcionamento da regra, através do seguinte

procedimento. Efetuamos logon no sistema operacional com o usuário normal denominado

dba_user, o qual é participante do grupo dba, após executamos o comando de substitute user

(su) para o usuário root, sendo retornada a mensagem de negação da operação, conforme

definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 15: Log de bloqueio de acesso para a identidade do usuário root

Regra 3 - Permitir somente acesso ao usuário ROOT, dos integrantes do grupo

SYSADMINS.

Validação da regra – Operação válida

Figura 16: Demonstração de acesso a identidade do usuário root

Na figura acima demonstramos o funcionamento da regra, através do seguinte

procedimento. Efetuamos logon no sistema operacional com o usuário normal denominado

sysadm_user, o qual é participante do grupo sysadmin, após executamos o comando de

substitute user (su) para o usuário root, foi solicitada a confirmação da senha pessoal do

usuário sysadm_user, conforme definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 17: Log de permissão de acesso para a identidade do usuário root

Validação da regra – Operação inválida

Figura 18: Demonstração de acesso para a identidade do usuário oracle

Na figura acima demonstramos o funcionamento da regra, através do seguinte

procedimento. Efetuamos logon no sistema operacional com o usuário normal denominado

sysadm_user, o qual é participante do grupo sysadmin, após executamos o comando de

substitute user (su) para o usuário oracle, sendo retornada a mensagem de negação da

operação, conforme definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 19: Log de bloqueio de acesso para a identidade do usuário Oracle

Controle de acesso aos recursos do Sistema Operacional

Regra 1 – Permitir leitura no arquivo /etc/passwd e /etc/shadow e alterações somente pelo

comando passwd.

Validação da regra – Operação válida

Figura 20: Demonstração do controle de acesso de Arquivo, condicional.

Na figura acima demonstramos o funcionamento da regra, utilizando o usuário root,

efetuamos a troca de senha do usuário através do comando passwd, a operação foi bem

sucedida conforme definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 21: Log do controle de acesso de Arquivo

Validação da regra – Operação inválida

Figura 22: Demonstração do controle de acesso de Arquivo

Na figura acima demonstramos o funcionamento da regra, utilizando o usuário root,

tentamos remover o arquivo /etc/passwd, sendo retornada a mensagem de negação da

operação, note que as permissões do sistema operacional permitiriam a operação, mas ela foi

bloqueada conforme definição da regra de acesso.

Abaixo trecho do log que demonstra a operação.

Figura 23: Log de bloqueio através do controle de acesso de Arquivos

5 Conclusão

Durante o desenvolvimento deste estudo de caso, foram observadas situações de

controle de acesso que demandavam mais recursos, que o sistema operacional dispõe para a

mitigação do risco.

O principal fator foi com o excesso de privilégios de usuários internos e principalmente

perfis de administração de sistemas ou aplicações, os quais não são abordados pelas técnicas

tradicionais de segurança existentes nos sistemas operacionais, pois estes têm um foco muito

maior em manter a segregação de usuários autorizados ou não autorizados.

Com a adoção de segregação de perfis e limitação de poderes de administração, ou

auditoria detalhada, foi possível um maior controle sobre as ações de administração e dados

sensíveis do ambiente e aumento considerável do nível de segurança do ambiente.

6 Bibliografia

[1] Dan Sullivan (2004). The Definitive Guide To Security Management.

realtimepublishers.com

[2] David Ferraiolo, D. Richard Kuhn, Ramaswamy Chandramouli (2003). Role-based

access control

[3] CA Software. CA Access Control for UNIX and Linux Administrator Guide

[4] CA Software. CA Access Control for UNIX and Linux Reference Guide

[5] CA Software. CA Access Control for UNIX and Linux User Guide

[6] CA Software. CA Access Control Implementation Guide