controle de acesso host based em ambientes distribuídosjamhour/rss/tccrss08a/fabiano fernandes...
Post on 16-Jul-2018
217 Views
Preview:
TRANSCRIPT
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
top related