2 Instalação Segura

Esta seção destaca o processo de planejamento e implementação de uma instalação e configuração seguras, bem como descreve as topologias de implantação recomendadas para o ACSLS.

Compreender seu Ambiente

Para compreender melhor suas necessidades de segurança, as seguintes perguntas devem ser feitas:

Quais recursos precisam ser protegidos?

Os principais recursos que o ACSLS gerencia são bibliotecas de fitas, 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.

Contra quem os recursos estão sendo protegidos?

Você deseja proteger os recursos de armazenamento em fita contra acessos internos e externos não autorizados.

O que acontecerá se as proteções dos recursos estratégicos falharem?

O ACSLS pode montar cartuchos em unidades de fita. Se um usuário conseguir 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 a bibliotecas de fitas poderão inserir e ejetar cartuchos de bibliotecas de fitas.

Procedimento Recomendado para Proteger o ACSLS

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.

Protegendo a Comunicação com a Internet do ACSLS

Esta seção descreve as recomendações para a implantação do ACSLS para um acesso seguro à Internet.

Proteger o ACSLS e as Bibliotecas de Fitas com o Firewall Corporativo

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 uma VPN.

Observação:

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.

Opção de Segurança de Firewall do ACSLS

Se os aplicativos cliente, que usam o ACSLS para montar fitas e gerenciar bibliotecas de fitas, estiverem separados do ACSLS por um firewall, recomendamos ativar a Opção de Segurança de Firewall. Mesmo se os aplicativos cliente não estiverem separados do ACSLS por um firewall, a implementação da 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, conforme 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.

O texto ao redor descreve s403_009.jpg.

Para obter detalhes, consulte o apêndice ”Firewall Security Option” no ACSLS Administrator’s Guide.

Portas Ethernet Usadas para a Comunicação do ACSLS

  • 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 os firewalls implementados pelo ipfilter no Solaris ou pelo iptables no Linux.

    • 22 ambas as direções – usada para acesso ssh.

    • 111 portmapper, a menos que o portmapper tenha sido desativado.

    • 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 - traps.

      Observação:

      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 de usuário acsss).

      Se a porta 5432 estiver sendo usada, o próximo número de porta mais alto disponível será usado.

      Observação:

      A porta 5432 só precisa estar acessível no localhost (127.0.0.1).

    • 7001 e 7002 - usadas pelo WebLogic e pelo 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 dos componentes Java com o processamento de ACSLS legado. Não é configurável.

  • Para que os aplicativos cliente se comuniquem com o ACSLS por meio do ACSAPI, as seguintes portas deverão estar abertas:

    • O aplicativo cliente deve ser capaz de se comunicar com a porta de escuta do ACSLS CSI. Por padrão, essa porta é a 30031 e é definida 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 ACSAPI com o seguinte comando do shell 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 ser capaz de se comunicar com essa porta.

      Observação:

      Em um servidor cliente ACSAPI, as portas 50001 e 50004 são usadas para a comunicação IPC entre o domínio AF_INET e 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.

  • Se o componente XAPI estiver instalado, o servidor XAPI usará uma porta de escuta fixa para receber as solicitações TCP de entrada dos clientes ELS. A porta de escuta XAPI é definida pela variável estática XAPI_PORT. Por padrão, a porta definida pela variável XAPI_PORT é a 50020. Ela deve estar no intervalo de 1024 a 65535, e não pode estar em conflito com qualquer outra porta usada pelo ACSLS ou por outros aplicativos.

    Consulte o apêndice XAPI Client Interface no ACSLS Administrator’s Guide para obter mais detalhes sobre a variável XAPI_PORT. Esse apêndice também fornece detalhes sobre como exibir e definir a variável estática XAPI_PORT.

  • Portas que devem estar abertas em uma biblioteca SL8500 ou SL3000:

    O ACSLS se comunica com essas portas nas conexões Ethernet 2A e 2B de uma 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 alternativo pode se comunicar com a biblioteca antes de ocorrer o seu failover para o nó alternativo

Configurando Firewalls executados no Servidor ACSLS

Além dos firewalls externos, a proteção de firewall pode ser implementada no servidor ACSLS por meio do ipfilter no Solaris ou do iptables no Linux. Esta seção descreve como gerenciar esses firewalls executados no servidor ACSLS.

  • Gerenciando o ipfilter no Solaris:

    Consulte as páginas man relativas ao ipf e ao ipfilter para obter informações detalhadas.

    • O firewall ipfilter é ativado (desativado) por 'root' com o comando:

      svcadm enable ipfilter (svcadm disable ipfilter)

    • Para conhecer o status atual do ipfilter:

      svcs ipfilter

    • As 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 do 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 baseados na 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.

      Talvez seja 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) por '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. Talvez seja necessário incluir uma instrução de exceção para a porta RPC do portmapper, 111.

Instalando e Configurando o Solaris

Esta seção descreve como instalar e configurar o Solaris com segurança.

As sugestões incluem:

  • Aplique todos os patches de segurança relevantes ao SO e aos serviços instalados com ele. Instale esses patches seletivamente porque a aplicação de todas as atualizações disponíveis poderá instalar novos recursos, inclusive novas releases do SO com as quais o ACSLS e o ACSLS HA não foram testados.

  • Desative o telnet e o rlogin. Use o ssh no lugar deles. Também desative o ftp e use o sftp.

    Desative os serviços telnet, rlogin e ftp executando os seguintes comandos como root.

    Para ver todos os serviços:

    svcs

    Para desativar o telnet, o rlogin e o ftp:

    svcadm disable telnet

    svcadm disable rlogin

    svcadm disable ftp

  • Não desative o ssh. Você deseja que os usuários façam login remotamente 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 nas bibliotecas de fitas. Consulte o Portas Ethernet Usadas para a Comunicação do ACSLS para saber quais portas 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 ajudá-lo a planejar quais eventos serão auditados, onde seus logs de auditoria devem ser salvos e como você deseja revisá-los.

Instalando e Configurando o Linux

Sugestões para instalar e configurar o Linux com segurança:

  • Aplique todos os patches de segurança relevantes ao SO e aos serviços instalados com ele. Instale esses patches seletivamente porque a aplicação de todas as atualizações disponíveis poderá instalar novos recursos, inclusive novas releases do SO com as quais o ACSLS e o ACSLS HA não foram testados.

  • Certifique-se de que o telnet e o rlogin não estejam instalados nem desativados. Use o ssh no lugar deles.

    Também certifique-se de que o ftp não esteja instalado nem desativado e, em vez dele, use o sftp.

    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 façam login remotamente 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, devem ser ativados para permitir a comunicação do cliente ACSLS.

    Ao iniciar o rpc no Linux, use 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 nas bibliotecas de fitas. Consulte o Portas Ethernet Usadas para a Comunicação do ACSLS para saber quais portas 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.

Auditando a Segurança no Linux

Determine as políticas de auditoria do Linux. A seção ”Configuring and Using Auditing” do Oracle Linux: Security Guide for Release 6 pode ajudá-lo 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 auditoria da segurança do Linux incluem:

  • Exiba o var/log/secure como root para ver o histórico de tentativas de login e outras mensagens de acesso.

  • O comando '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 negadas pelo SE Linux. Você precisa ser o usuário root para exibi-los.

Segurança do SELinux

O ACSLS 8.4 foi projetado para execução em ambientes SELinux (Security Enhanced Linux) opcionais. O SELinux fornece 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 atribuição de usuário, domínio e contexto. O agente que impõe o controle de acesso sobre todos os recursos do sistema é o kernel Linux.

Em um sistema Linux, o usuário root 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 atual de imposição do sistema, 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 do sistema 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.4 Administrator’s Guide.

Instalando e Configurando o ACSLS

Esta seção explica como instalar com segurança o ACSLS.

Executar uma Instalação Padrão do ACSLS

A execução de uma instalação padrão do ACSLS garante que você terá todos os componentes necessários.

Se você estiver migrando de uma release anterior do ACSLS para outra mais recente, verifique as configurações de variáveis dinâmicas e estáticas para ver se deseja usar opções mais seguras, principalmente no caso da Opção de Segurança de Firewall.

Usar Senhas Fortes para IDs de Usuário do ACSLS

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.

Restringir o Acesso aos Arquivos do ACSLS

Em geral, o ACSLS restringe o acesso aos arquivos do ACSLS somente ao grupo acsls, que inclui os IDs de usuário acsss, acssa, acsdb e 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 é executado com a opção unmask definida como 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.

Definir ’root’ como o ID de Usuário Efetivo para Três Arquivos do ACSLS

O script de instalação avisa os clientes que o id de usuário efetivo '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 iniciar e interromper os serviços do sistema necessários ao aplicativo ACSLS.)

  • db_command  (Esse binário inicia e interrompe o mecanismo de 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 abrangentes 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.

Revisar Configurações de Variáveis Estáticas e Dinâmicas do ACSLS

As variáveis estáticas e dinâmicas do ACSLS controlam o comportamento de várias funções do ACSLS. Defina essas variáveis usando o utilitário acsss_config. As configurações de segurança de muitas dessas variáveis são abordadas neste documento. Quando as opções referentes a uma variável são apresentadas 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.

Configurando o WebLogic

O ACSLS 8.1 e releases posteriores utilizam o WebLogic como servidor Web. O WebLogic é instalado com o ACSLS.

Consulte o Oracle Fusion Middleware; Understanding Security for Oracle WebLogic Server 11g Release 1 (10.3.6) para ver as opções de proteção de um servidor do WebLogic e as possibilidades de trilha de auditoria com o WebLogic.

Use o utilitário userAdmin.sh do ACSLS para criar e manter usuários do ACSLS GUI

O utilitário userAdmin.sh baseado em menus é usado para administrar as senhas de usuário do ACSLS GUI. Você pode adicionar, remover e listar usuários, bem como alterar as 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 ser executado por root e exige autenticação acsls_admin. A conta de usuário acsls_admin é configurada durante a instalação do ACSLS.

Usando o ACSLS GUI

Para usar o ACSLS GUI, é preciso instalar a versão mais recente do JRE e acessar o ACSLS GUI por meio de um navegador.

Instalar a Versão Mais Recente do JRE nos Sistemas Cliente GUI

Verifique se a última versão do Java Runtime Environment (JRE) está instalada nos sistemas que usarão o ACSLS GUI para acessar o ACSLS.

Acessando o ACSLS GUI

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.

Como 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 tiver certeza de que o URL é sua máquina ACSLS local, você poderá prosseguir com segurança. Nesse momento, você deverá ver a tela de login.

Usando o ACSLS GUI

O AcslsDomain no WebLogic é acessado com o protocolo seguro, https. Esse protocolo utiliza a comunicação criptografada entre o navegador e o servidor usando chaves privadas e certificados digitais. Estas são as opções para obtenção de um certificado digital:

Certificado de demonstração do ACSLS

O ACSLS é fornecido com um certificado chamado 'demo'. Isso garante um nível mínimo de segurança da criptografia, permitindo que os clientes comecem a usar o ACSLS GUI sem quaisquer etapas de configuração adicionais. Em geral, esse método de certificação de demonstração é suficiente quando a interação do cliente com a Biblioteca ACSLS ocorre exclusivamente em uma intranet protegida. No entanto, esse método utiliza uma chave de criptografia de 512 bits que não é suportada em certos navegadores, especialmente no Internet Explorer e no FireFox Versão 39 e acima.

Configurando um certificado digital autoassinado

O ACSLS Installation Guide fornece um método passo a passo para os administradores do ACSLS configurarem um certificado digital autoassinado de 2048 bits. Na seção 'Configuring an SSL Encryption Key', esse método fornece um certificado que é suportado em todos os navegadores. Os usuários que acessam um site https com um certificado autoassinado são aconselhados a não entrar no site a menos que tenham certeza de que o recurso Web é um site seguro. No contexto dos usuários do ACSLS e do servidor de controle da biblioteca, geralmente esse nível de confiança é bem compreendido e, na maioria dos casos, não é necessário que o site prove sua integridade usando a verificação de assinatura de terceiros.

Certificados digitais assinados por outra autoridade de assinatura

Cabe ao site de cada cliente determinar se é necessário fornecer uma autenticação de certificado de outra autoridade de assinatura, como Verisign ou Entrust.net. O procedimento para gerar esse tipo de certificado digital assinado é descrito no documento on-line da Oracle, Configuring Identity and Trust em:

http://docs.oracle.com/cd/E13222_01/wls/docs92/secmanage/identity_trust.html

Instalando o ACSLS HA

Se você estiver usando a solução ACSLS High Availability, siga as instruções fornecidas no ACSLS-HA Cluster: Installation, Configuration, and Operations.