| StorageTek Automated Cartridge System Library Software Guia de Segurança Release 8.3 E50407-01 |
|
 Anterior |
 Próximo |
| StorageTek Automated Cartridge System Library Software Guia de Segurança Release 8.3 E50407-01 |
|
Anterior |
Próximo |
Esta seção destaca o processo de planejamento e implementação de uma instalação e configuração seguras, além de descrever as topologias de implantação recomendadas para o ACSLS.
Para melhor compreender suas necessidades de segurança, as seguintes perguntas devem ser feitas:
Os principais recursos que o ACSLS gerencia são bibliotecas de fita, unidades e cartuchos. Eles precisam estar protegidos contra o acesso inadvertido e mal-intencionado. Por exemplo, impedir que pessoas façam login por engano em um servidor ACSLS diferente usando senhas distintas para os IDs de usuário do ACSLS em vários servidores.
Você deseja proteger os recursos da unidade de fita contra acessos internos e externos não autorizados.
O ACSLS pode montar cartuchos em unidades de fita. Se um usuário consegue se conectar à unidade de fita por meio do caminho de dados, ele poderá ler os dados contidos na fita que não estão criptografados.
Usuários com acesso ao ACSLS e à biblioteca de fitas poderão inserir e ejetar cartuchos de uma biblioteca de fitas.
Ao proteger o ACSLS e os componentes de infraestrutura necessários, siga este procedimento para garantir que o ACSLS continuará a funcionar depois que as alterações forem feitas:
Instale o ACSLS.
Verifique se o ACSLS está funcionando corretamente. Inclua operações de configuração e auditoria de bibliotecas, montagem e desmontagem de fitas, inserção e ejeção de fitas e backup e restauração do banco de dados.
Implemente a alteração para aumentar a segurança.
Verifique se o ACSLS ainda funciona corretamente.
Esta seção descreve recomendações para a implantação do ACSLS para um acesso à Internet seguro.
O ACSLS e as bibliotecas de fitas que ele suporta devem ser implantados com a proteção do firewall corporativo. Se as pessoas que trabalham remotamente precisarem fazer login no servidor ACSLS, elas poderão acessá-lo por meio de um VPN.
|
Nota: Se você tiver um firewall de borda baseado em IPv4, ele deverá ser configurado para remover todos os pacotes de saída IPv4 do protocolo 41 e pacotes da porta UDP 3544 para impedir que os hosts da Internet usem qualquer tráfego tunelizado IPv6-over-IPv4 para alcançar hosts internos. |
Se aplicativos cliente, que usam o ACSLS para montar fitas e gerenciar bibliotecas de fitas, estiverem separados do ACSLS por um firewall, recomendamos habilitar a Opção de Segurança de Firewall. Mesmo se os aplicativos cliente não estiverem separados do ACSLS por um firewall, implementar a Opção de Segurança de Firewall fornece segurança adicional ao ACSLS, pois restringe as portas usadas para comunicação entre o ACSLS e seus aplicativos cliente, como mostrado abaixo. Por esses motivos, a variável estática CSI_FIREWALL_SECURE utiliza o padrão TRUE no ACSLS 8.1 e releases posteriores.
Para obter detalhes, consulte o apêndice ”Firewall Security Option” no ACSLS Administrator’s Guide.
As portas a seguir são usadas no servidor ACSLS. Certifique-se de que os firewalls estejam configurados para permitir o tráfego nessas portas. Isso incluía firewalls implementados pelo ipfilter no Solaris ou iptables no Linux.
22 ambas as direções – usada para acesso ssh.
111 portmapper, a menos que o portmapper tenha sido desabilitado.
115 usada para SFTP (Secure File Transfer Protocol).
161 porta padrão para o agente ACSLS SNMP - get/set/walk.
162 porta padrão para o agente ACSLS SNMP - interceptações.
|
Nota: As portas usadas pelo agente ACSLS SNMP são configuráveis pelo comando:AcslsAgtdSnmpConf [ -p port ] [-t trap port] [-d]. A opção -d exibe a configuração atual. Depois de alterar a configuração da porta, você deverá reiniciar o agente com o comando, agentRegister. |
5432 porta padrão para comunicação interna do ACSLS com o banco de dados PostgreSQL (a variável de ambiente PGPORT para o ID do usuário acsss).
Se a porta 5432 estiver sendo usada, o próximo número de porta mais alto disponível será usado.
|
Nota: A porta 5432 só precisa estar acessível no localhost (127.0.0.1). |
7001 e 7002 - usadas pelo WebLogic e ACSLS GUI.
30031 ou a porta de escuta do ACSLS CSI, definida por CSI_INET_PORT.
50003 porta usada para comunicação interna do ACSLS GUI e componentes Java com o processamento de ACSLS legado. Não é configurável.
Para aplicativos cliente se comunicarem com o ACSLS por meio do ACSAPI, as seguintes portas deverão estar abertas:
O aplicativo cliente deve estar apto a se comunicar com a porta de escuta do ACSLS CSI. Ele utiliza o padrão 30031 e é definido pela variável estática CSI_INET_PORT.
Você pode descobrir quais portas estão sendo usadas pelo ACSLS para escutar solicitações dos clientes do ACSAPI com o seguinte comando do shell do Unix:
rpcinfo -p | egrep "300031 | 536871166"
Os IDs de porta serão listados no último campo da tela.
O cliente ACSAPI (por exemplo, um servidor NetBackup ou SAM-QFS) define sua porta de entrada fixa usando a variável de ambiente SSI_INET_PORT. Especifique uma porta no intervalo de 1024-65535, excluindo as portas 50001 e 50004. O servidor ACSLS deve estar apto a se comunicar com essa porta.
|
Nota: Em um servidor cliente ACSAPI, as portas 50001 e 50004 são usadas para a comunicação IPC entre o domínio AF_INET com o mini Agente de Log de Eventos e entre aplicativos cliente e o SSI. |
Consulte o apêndice Firewall Security Option no ACSLS Administrator’s Guide para obter mais detalhes sobre a comunicação entre os aplicativos cliente e o ACSLS.
As portas que devem ser abertas em uma biblioteca SL8500 ou SL3000:
O ACSLS se comunica com essas portas em uma conexão Ethernet 2A e 2B da biblioteca SL8500 ou SL3000. Se a comunicação do ACSLS com essas portas for bloqueada, o ACSLS não poderá gerenciar a biblioteca.
50001 – Usada para toda a comunicação normal entre o ACSLS e a biblioteca
50002 – Usada pelo ACSLS HA para determinar se o nó HA pode se comunicar com a biblioteca antes de ser direcionado para o nó alternativo
Além dos firewalls externos, a proteção de firewall pode ser implementada no seu servidor ACSLS por meio do ipfilter no Solaris ou do iptables no Linux. Isso descreve como gerenciar esses firewalls que executam no seu servidor ACSLS.
Gerenciando o ipfilter no Solaris:
Consulte as páginas man relativas ao ipf e ipfilter para obter informações detalhadas.
O firewall ipfilter é ativado (desativado) pelo 'root' com o comando:
svcadm enable ipfilter (svcadm disable ipfilter)
Para conhecer o status atual do ipfilter:
svcs ipfilter
Políticas de firewall são definidas no arquivo: /etc/ipf/ipf.conf
Para permitir uma comunicação livre entre os componentes no host local (ex.: entre o ACSLS e o WebLogic ou entre a GUI e o banco de dados ACSLS), inclua uma instrução como:
pass in quick from 127.0.0.1 to 127.0.0.1
ou
pass in quick from 127.0.0.1 to all
Você precisa definir políticas que permitem acesso a todas as portas necessárias para o ACSLS. Por exemplo, para incluir uma política que permite que os navegadores da Web acessem o ACSLS GUI, você precisa abrir as portas 7001 e 7002.
pass in quick from any to any port = 7001
pass in quick from any to any port = 7002
Depois de descobrir quais portas são usadas pelo ACSLS para escutar solicitações de clientes ACSAPI, adicione instruções 'pass in quick' para cada uma dessas portas.
Pode ser necessário incluir uma instrução 'pass in quick' para a porta RPC do portmapper, 111.
A última instrução no seu conjunto de regras proposto, "block in from any", indica que nenhum tráfego deve alcançar o host, exceto se especificamente autorizado nas instruções anteriores.
Gerenciando o iptables no Linux:
O firewall iptables é ativado (desativado) pelo 'root' com o comando:
service iptables start (service iptables stop)
Para verificar o status do iptables:
service iptables status
O arquivo de política para o iptables é /etc/sysconfig/iptables:
Você precisa definir políticas que permitem acesso a todas as portas necessárias para o ACSLS. Por exemplo, para incluir uma política que permita o acesso remoto http/https ao ACSLS GUI, você deve atualizar esse arquivo para incluir exceções para as portas 7001 e 7002 usando instruções, como:
-A input -p tcp --dport 7001 -j ACCEPT
-A input -p tcp --dport 7002 -j ACCEPT
Depois de descobrir quais portas são usadas pelo ACSLS para escutar as solicitações de clientes ACSAPI, você precisará adicionar exceções para cada um desses arquivos de política do iptables. Pode ser necessário incluir uma instrução de exceção para a porta RPC do portmapper, 111.
Esta seção descreve como instalar e configurar o Solaris com segurança.
As sugestões incluem:
Desative o telnet e o rlogin. Use ssh no lugar deles. Também desative o ftp e use o sftp.
Desative os serviços de telnet, rlogin e ftp executando os seguintes comandos como root.
Para ver todos os serviços:
svcs
Para desativar o telnet, rlogin e ftp:
svcadm disable telnet
svcadm disable rlogin
svcadm disable ftp
Não desative o ssh. Você deseja que os usuários remotos consigam fazer login no ACSLS usando ssh, e não telnet ou rlogin. Além disso, não desative o sftp.
O ACSLS requer rpc-bind. Não desative-o.
Se o Solaris estiver instalado com a opção Secure by Default, será preciso alterar uma propriedade de configuração de rede para que rpc-bind permita aos clientes ACSAPI enviarem solicitações ao ACSLS.
Consulte o ACSLS Installation manual, capítulo "Installing ACSLS on Solaris", seção "Installing Solaris" para obter detalhes.
Algumas portas Ethernet no servidor ACSLS precisam estar abertas para comunicação com o ACSLS. Os aplicativos cliente usam portas Ethernet específicas para a comunicação com o ACSLS, e o ACSLS se comunica com portas específicas em bibliotecas de fita. Consulte o Portas Ethernet Usadas para a Comunicação do ACSLS para as portas que precisam estar disponíveis para a comunicação do ACSLS. No servidor ACSLS, certifique-se de que o ipfilter esteja configurado para permitir o tráfego nas portas usadas pelo ACSLS.
Determine a política de auditoria do Solaris. A seção ”Auditing in Oracle Solaris” no "Oracle System Administration: Security Services" pode ajudar a planejar quais eventos serão auditados, onde seus logs de auditoria devem ser salvos e como você deseja revisá-los.
Sugestões para instalar e configurar o Linux com segurança:
Certifique-se de que o telnet e o rlogin não estejam instalados ou desativados. Use ssh no lugar deles.
Certifique-se também de que o ftp não esteja instalado ou desativado e use o sftp em vez dele.
Para ver todos os serviços, faça login como root e:
service –-status-all
Para excluir os serviços permanentemente, use:
svccfg delete -f service-name
Não desative o ssh. Você deseja que os usuários remotos consigam fazer login no ACSLS usando ssh, e não telnet ou rlogin. Além disso, não desative o sftp.
Os serviços de rede, especificamente o rpcbind, deve ser ativado para permitir a comunicação do cliente ACSLS.
Ao iniciar o rpc no Linux, inicie-o com o indicador –i.
Algumas portas Ethernet no servidor ACSLS precisam estar abertas para comunicação com o ACSLS. Os aplicativos cliente usam portas Ethernet específicas para a comunicação com o ACSLS, e o ACSLS se comunica com portas específicas em bibliotecas de fita. Consulte o Portas Ethernet Usadas para a Comunicação do ACSLS para as portas que precisam estar disponíveis para a comunicação do ACSLS. No servidor ACSLS, certifique-se de que o iptables esteja configurado para permitir o tráfego nas portas usadas pelo ACSLS.
Determine as políticas de auditoria do Linux. A seção ”Configuring and Using Auditing” do Oracle Linux: Security Guide for Release 6 pode ajudar a planejar quais eventos serão auditados, onde seus logs de auditoria devem ser salvos e como você deseja revisá-los.
Alguns logs e comandos úteis para a segurança de auditoria no Linux incluem:
Exiba var/log/secure como root para ver o histórico de tentativas de login e outras mensagens de acesso.
O parâmetro 'last' | more fornece um histórico dos usuários conectados.
O /var/log/audit/audit.log.[0-9] mantém um log das tentativas de acesso que foram negadas pelo SE Linux. Você deve ser usuário root para visualizá-los.
O ACSLS 8.3 foi projetado para executar em ambientes Security Enhanced Linux opcionais. O SELinux oferece controle de acesso a arquivos, diretórios e outros recursos do sistema que vão além da proteção tradicional encontrada em ambientes Unix padrão. Além do acesso de permissão owner-group-public, o SELinux inclui controle de acesso baseado em função de usuário, domínio e contexto. O agente que impõe o controle de acesso sobre todos os recursos do sistema é o Linux kernel.
O usuário root em um sistema Linux pode ativar ou desativar a imposição com o comando setenforce.
setenforce [Enforcing | Permissive | 1 | 0 ]
Use Enforcing ou 1 para colocar o SELinux no modo de imposição. Use Permissive ou 0 para colocar o SELinux no modo permissivo
Para exibir o status de imposição do sistema atual, use o comando getenforce.
Três módulos de política do SELinux são carregados no kernel quando você instala o ACSLS: allowPostgr, acsdb e acsdb1. Esses módulos fornecem as definições e exceções de imposição necessárias para o ACSLS acessar seu próprio banco de dados e outros recursos de sistemas enquanto a imposição do SELinux está ativa. Com esses módulos instalados, você deve ser capaz de executar operações comuns do ACSLS, incluindo operações de banco de dados, como bdb.acsss, rdb.acsss, db_export.sh e db_import.sh sem a necessidade de desativar a imposição do SELinux.
Para obter mais informações, consulte a seção sobre o SELinux no Apêndice ”Troubleshooting” do StorageTek ACSLS 8.3 Administrator’s Guide.
Esta seção explica como instalar o ACSLS com segurança.
A execução de uma instalação padrão do ACSLS garante que você terá todos os componentes necessários.
Se você estiver migrando para uma release posterior do ACSLS a partir de uma release anterior do ACSLS, verifique as configurações relativas às variáveis dinâmicas e estáticas para ver se deseja usar mais opções de segurança, principalmente em relação à Opção de Segurança de Firewall.
O ACSLS requer os IDs de usuário do ACSLS: acsss, acssa e acsdb. Escolha senhas fortes para esses IDs e altere as senhas frequentemente.
Em geral, o ACSLS restringe o acesso aos arquivos do ACSLS somente ao grupo acsls, que inclui o acsss, acssa, acsdb e IDs de usuário root. Alguns arquivos de banco de dados e de diagnóstico só estão acessíveis para um único ID de usuário acsls. O ACSLS executa com uma configuração umask de 027.
Os arquivos do ACSLS não devem ser facilmente legíveis ou graváveis. No entanto, restringir o acesso além dos padrões de instalação poderá causar falha nas funções do ACSLS.
O script de instalação avisa os clientes que o id de usuário efetivo de 'root' deve ser definido (setuid) em três arquivos executáveis no sistema de arquivos /export/home/ACSSS:
acsss (Esse binário deve ser executado com privilégios 'root' porque é usado para inicializar e interromper serviços de sistema solicitados pelo aplicativo ACSLS.)
db_command (Esse binário inicia e interrompe o mecanismo do banco de dados PostgreSQL que controla e mantém o banco de dados do ACSLS.)
get_diags (Esse binário é acionado por um cliente para coletar informações de diagnóstico do sistema que podem ser necessárias no contexto de uma chamada de serviço de suporte.)
Durante a instalação do ACSLS com o pkgadd, os clientes são solicitados a responder à pergunta Do you want to install these as setuid/setgid files? Ao responder y à pergunta, você permitirá que esses três comandos sejam executados pelos usuários no grupo acsls, embora os utilitários executem determinadas operações do sistema que exigem privilégios root.
As variáveis estáticas e dinâmicas do ACSLS controlam o comportamento de muitas funções do ACSLS. Defina essas variáveis usando o utilitário acsss_config. As configurações de segurança para muitas dessas variáveis são abordadas neste documento. Quando as opções para uma variável são representadas pelo acsss_config, responder com um ponto de interrogação (?) exibirá uma explicação detalhada da variável. Essas informações também estão disponíveis no capítulo ”Setting Variables that Control ACSLS Behavior” do ACSLS Administrator’s Guide.
O ACSLS 8.1 e releases posteriores utilizam o WebLogic como servidor Web. O WebLogic é instalado com o ACSLS.
Consulte o Oracle Fusion Middleware Securing Oracle WebLogic Server 11g Release 1 (10.3.5) para ver as opções de segurança de um servidor WebLogic e as possibilidades de trilha de auditoria com o WebLogic.
O utilitário userAdmin.sh baseado em menus é usado para administrar senhas de usuário do ACSLS GUI. Você pode adicionar usuários, remover usuários, listar usuários e alterar senhas de usuários. O WebLogic deve estar em execução para usar esse utilitário. Caso contrário, esse utilitário iniciará o WebLogic e confirmará que ele está on-line antes de exibir o menu.
O utilitário userAdmin.sh deve estar sendo executado pelo root e exige autenticação acsls_admin. A conta de usuário acsls_admin é configurada durante a instalação do ACSLS.
Para usar o ACSLS GUI, é preciso instalar a versão mais recente do JRE e acessar o ACSLS GUI por meio de um navegador.
Verifique se a última versão do Java Runtime Environment (JRE) 1.6 está instalada nos sistemas que usarão o ACSLS GUI para acessar o ACSLS.
|
Nota: O ACSLS 8.3 requer o JRE 1.6 ou 1.7. |
Abra um navegador e insira um URL com o nome de host ou o endereço IP do servidor no seguinte formato:
https://myAcslsHostName.myDomainName:7002/SlimGUI/faces/Slim.jsp ou https://127.99.99.99:7002/SlimGUI/faces/Slim.jsp
É melhor usar o nome de host totalmente qualificado ou o endereço IP da máquina host. Algumas páginas, incluindo as páginas de ajuda do ACSLS, talvez não sejam exibidas corretamente se o URL não for totalmente resolvido pelo WebLogic.
Se você usar o http com a porta 7001, o WebLogic automaticamente redirecionará você para o https na porta 7002.
Já que o WebLogic está usando o protocolo seguro https, seu navegador poderá avisá-lo que o certificado de segurança do site não foi registrado e, portanto, não é confiável. Se você tiver certeza de que o URL é sua máquina ACSLS local, você estará seguro para prosseguir. Nesta etapa, você deverá ver a tela de login.
|
 Copyright © 2013, Oracle e/ou suas empresas afiliadas. Todos os direitos reservados. Avisos Legais |
|