Cada vez mais empresas estão migrando de sistemas internos tradicionais, com vários componentes de hardware e software, para um modelo que promove a terceirização dos principais processos para datacenters externos. Esses datacenters são projetados e gerenciados para atender às necessidades internas de computação, bem como às necessidades externas enfrentadas pelos clientes, como comunicação facilitada, demonstrações de produtos, processamento de pedidos e envio de produtos.

Um requisito dessa migração é manter as principais informações internas da empresa e os dados privilegiados dos clientes acessíveis apenas a usuários autorizados a acessarem e gerenciarem esses dados.

Este artigo descreve os fundamentos básicos para atualizar, escolher e implementar uma solução de conectividade SSH segura altamente efetiva para a Nuvem IBM. No início iremos examinar algumas tendências recentes de migração para a nuvem e, em seguida, verificar as principais áreas a serem consideradas ao fazer a transição de manipulação interna dos processos principais para uma solução baseada em nuvem. Por último, concluiremos com uma demonstração de uma solução existente de segurança SSH de servidor e cliente de ponta a ponta.

Desafios para proteger o acesso à nuvem

Uma das preocupações dos potenciais usuários de nuvem é o fato de que dados são expostos quando movidos de um local interno seguro para um local externo, que pode ser considerado menos seguro. Apesar de ser possível proteger a instância de nuvem usando o Windows Active Directory, o sistema de arquivos NTFS e firewalls, a transferência de dados pode ser difícil.

Problemas que, quando não abordados, podem criar violações de segurança reais e dispendiosas incluem:

• Transmissão de texto não criptografado: Todas as comunicações realizadas em texto não criptografado, incluindo nomes de usuários e senhas.
• Autenticação de cliente fraca: Métodos de acesso comumente implementados e não seguros autenticam usuários por meio de nomes de usuários e senhas que, muitas vezes, mostraram não serem confiáveis e não oferecerem suporte para métodos avançados, como chave pública/privada, Kerberos ou certificados digitais.
• Nenhuma autenticação de servidor: Não é possível que usuários confirmem se estão se comunicando com seu servidor desejado ou com um invasor, fingindo ser o servidor.
• Falta de integridade de dados: Qualquer pessoa pode alterar e corromper dados que estão sendo transmitidos entre o servidor e o cliente, sem detecção.

Nesses casos, o aumento repentino do acesso remoto a dados em nuvem também deve ser levado em consideração. Atualmente, é comum encontrar funcionários que:

• Usam smartphones e tablets para verificar o inventário em um warehouse
• Reúnem informações enquanto estão em campo
• Controlam produtos em diversos pontos de verificação
• Transmitem dados para um home office a partir de um carro ou uma sala de embarque de aeroporto

Uma estimativa prevê que, em 2014, o uso remoto da Internet irá superar o uso da Internet em desktop. Mais de 50 por cento de todas as procuras "locais" são feitas a partir de um dispositivo móvel.

Considerando o grande número de regulamentos de privacidade federal e de proteção de dados, além do aumento da perspicácia técnica apresentada por hackers, permitir aos funcionários o acesso remoto à rede a partir de dispositivos remotos está se tornando insustentável em uma configuração corporativa.

Todos estão cientes de usuários e empresas resistentes a mudanças que são relutantes em fazer a transição. Mas, à medida que empresas e seus funcionários redefinem o tempo de acesso geográfico do local de trabalho, o foco em como gerenciar de maneira mais segura essa migração de diversos pontos de acesso para dados armazenados na nuvem será essencial.

Quanto aos regulamentos de privacidade, a maioria de nós está ciente sobre os regulamentos federais estabelecidos na última década para a proteção da privacidade de consumidores e empresas, como:

• PCI-DSS (2004, atualizada em janeiro de 2009): Essa norma de segurança de dados do segmento de mercado de cartão de pagamento regula como as informações de cartão de crédito são processadas, armazenadas e transmitidas. A falta de criptografia, a autenticação fraca e a falta de integridade de dados renderizam um Telnet inadequado para fornecer suporte aos requisitos da norma em uma rede wireless.
  
  
• GLBA (1999): O Gramm-Leach-Bliley Act requer que o segmento de mercado financeiro proteja de forma adequada as informações de dados de clientes — novamente, uma expectativa não realista com Telnet ou FTP.
  
  
• Sarbox (2002): O Sarbanes-Oxley requer a implementação de controles internos sólidos, para garantir que relatórios financeiros reflitam corretamente a realidade econômica de qualquer empresa de capital aberto. A maior parte dos auditores que revisam sistemas de TI tende a exigir que as atividades de computação remota com Telnet ou FTP sejam encerradas.
  
  
• HIPAA (1996): Esse regulamento do segmento de mercado de assistência médica requer, entre outras coisas, que médicos criptografem e protejam as informações de seus pacientes — novamente, isso é impossível com Telnet ou FTP.
  
  
• Conformidade com FIPS: No Information Technology Management Reform Act (Lei Pública 104-106), o Secretário de Comércio aprova padrões e diretrizes desenvolvidos pelo National Institute of Standards and Technology (NIST) para sistemas Federais de computadores. Esses padrões e diretrizes são emitidos pelo NIST como Federal Information Processing Standards, para uso em todo o governo. O NIST desenvolve os FIPS quando há requisitos urgentes do governo Federal, mas não há soluções ou padrões do segmento de mercado aceitáveis, como, por exemplo, para segurança e interoperabilidade.

  Como parte deste programa, o Cryptographic Module Validation Program (CMVP) é o programa de credenciamento que valida módulos criptográficos para esse padrão. O CMVP é uma iniciativa em conjunto entre o National Institute of Standards and Technology (NIST) e o Communications Security Establishment (CSE) do Governo do Canadá. Módulos Criptográficos validados por meio do programa são submetidos a testes rigorosos por laboratórios credenciados independentes de Cryptographic Module Testing (CMT).

Indo além da divulgação do regulamento direto, o governo federal também iniciou recentemente um estudo com duração de seis meses em seus datacenters. Os resultados do estudo irão determinar a base para uma iniciativa abrangente de consolidação de datacenters públicos. Na sequência de um anúncio federal, a cidade de Nova York também iniciou uma iniciativa semelhante.

À medida que as agências governamentais trabalham para simplificar os recursos de datacenters e armazenamento e incluem cada vez mais funções na nuvem, muitos observadores do segmento de mercado acreditam que essas iniciativas de ampla escala irão levar a ainda mais regulamentos de proteção de dados e de privacidade destinados a assegurar segurança de computação remota.

Voltar para parte superior

SSH como uma abordagem de segurança de acesso à nuvem

Os componentes de SSH discutidos neste artigo o tornam o principal candidato para uma abordagem de segurança de acesso à nuvem.

Um protocolo de rede que permite a troca de dados usando um canal seguro entre quaisquer dois dispositivos de rede, o SSH foi criado e desenvolvido em 1995, para servir especificamente como um substituto para Telnet, FTP e outros shells remotos não seguros.

O SSH usa criptografia que garante a confidencialidade e a integridade de dados transmitidos por redes não seguras. Com a solução SSH correta, uma empresa é capaz de se proteger contra:

• Escuta de dados transmitidos por qualquer rede
• Manipulação de dados em elementos intermediários na rede, como os roteadores
• Spoofing de endereço IP
• Spoofing de DNS de nomes de hosts/endereços IP confiáveis
• Roteamento de origem de IP

Com o tempo, a função de SSH foi expandida e se tornou o padrão real do segmento de mercado para acesso remoto, transferência de arquivos e conexão de túnel seguros. Mas, mais importante do que isso, o SSH se tornou o transporte de entrega segura escolhido para a entrega de aplicativos de servidores para clientes móveis e de desktop.

A seguinte lista de RFCs detalha a função de SSH, que é um padrão RFC, no auxílio à proteção de comunicações de dados remotos:

• RFC 4250: Números Designados do Protocolo de SSH
• RFC 4251: A Arquitetura do Protocolo de Shell Seguro (SSH)
• RFC 4252: O Protocolo de Autenticação de Shell Seguro (SSH)
• RFC 4253: O Protocolo da Camada de Transporte de Shell Seguro (SSH)
• RFC 4254: O Protocolo de Conexão de Shell Seguro (SSH)
• RFC 4256: Autenticação Genérica de Troca de Mensagens para o Protocolo de Shell Seguro (SSH)
• RFC 4335: A Extensão de Quebra do Canal de Sessão de Shell Seguro (SSH)
• RFC 4344: Os modos de Criptografia da Camada de Transporte de Shell Seguro (SSH)

De roteadores Cisco a servidores de produção corporativos, o SSH pode ser usado entre plataformas, incluindo Microsoft® Windows, UNIX®, Apple Mac e Linux®, para tarefas como:

• Efetuar login em um shell em um host remoto (substituindo Telnet e rlogin).

  Usar qualquer cliente SSH padrão para obter acesso ao shell.

• Executar um único comando em um host remoto (substituindo rsh).

  Passar um comando à conexão SSH, para executar automaticamente o comando:

  ssh user@server c:\temp\batch_file_to_launch

  
  
• Copiar arquivos de um servidor local para um host remoto, usando Secure FTP (SFTP) e Secure Copy Protocol (SCP), fornecendo opções para cópias de arquivos.

  scp source_file user@sshServer:drive:\dest_directory\dest_file

  
  
• Transferir arquivos em conjunto com SFTP, como uma alternativa segura para FTP. Um equívoco comum é que isso é FTP seguro e que um cliente FTP pode ser usado para se conectar. Para se conectar a um servidor SFTP, é necessário um cliente SFTP.
• Em conjunto com o rsync, fazer backup, copiar e espelhar arquivos de forma eficiente e segura.
• Automatizar cópias de arquivos com script. Este código é um exemplo de script com o cliente SFTP de comandos da Pragma Systems:

  sftp user@sftp_server -b batchfile -L logfile

  
  

  O arquivo em lote pode conter transferências de arquivos:

  cd userlogs mput *.log cd \serverlogs mget *.logs

  
  
• Fazer encaminhamento ou tunelamento de uma porta. Um erro comum com encaminhamento de porta é se conectar ao host remoto ao invés de à porta local. O encaminhamento de porta permite que conexões locais efetuem tunelamento por meio da conexão SSH, criptografando toda a sessão. Além disso, uma boa maneira de encaminhar portas automaticamente é usar um arquivo em lote que configure o encaminhamento de porta que está sendo executado como um script de logon de usuário.
  • O tunelamento de tráfego da web pode ser feito por encaminhamento de porta. Abra um cliente SSH e se conecte ao encaminhamento de porta:
    

    ssh user@ssh_server -L 8080:internal_webserver:80

    
    .
    Em seguida, conecte-se localmente ao tráfego de túnel, por meio da porta http://localhost:8080.
  • É possível usar tráfego de email. Abra um cliente SSH e se conecte ao encaminhamento de porta:
    

    ssh user@ssh_server -L

    
    
• Encaminhar a partir de um host remoto (possível por meio de diversos hosts intermediários).
• Navegar pela web por meio de uma conexão proxy criptografada com clientes SSH que suportam o protocolo SOCKS.
• Montar de forma segura um diretório em um servidor remoto como um sistema de arquivos em um computador local, usando SSHFS.
• Executar o monitoramento e gerenciamento remotos automatizados de servidores, por meio de um ou mais mecanismos.
• Colaborar de formar segura com diversos usuários do canal do shell SSH, nos quais a transferência, troca, compartilhamento e recuperação de sessões desconectadas são possíveis.

Para essas tarefas e necessidades, o SSH parece ser a abordagem ideal para o acesso seguro à nuvem a qualquer momento, em todos os lugares. Mas ainda é necessário considerar se apenas o SSH é suficiente para suportar tudo que você precisa e deseja fazer do campo.

O SSH é o ideal se você:

• Precisar apenas de acesso à linha de comando.
• Desejar executar comandos únicos, em script ou interativamente.
• For capaz de realizar toda sua administração em uma linha de comando.
• Desejar que todo o tráfego seja protegido por uma única porta.
• Desejar abrir apenas uma única porta em um firewall.
• Desejar acesso rápido a seu servidor.

O acesso VPN ou Terminal Services pode ser necessário se você:

• Precisar executar programas gráficos.
• Desejar acesso total a diversos programas com contexto de usuário.

Então, quais são as melhores práticas para implementar o SSH na nuvem? Lembre-se destas:

• Uma conexão de GUI exige muito do processador. Para servidores, isso pode ser proibitivo. O acesso por linha de comando é menos intenso com uma conexão rápida.
  
  
• O SSH é ideal para administrar servidores e executar aplicativos do console remotamente. Quase toda a administração feita por uma GUI pode ser executada a partir da linha de comando. O Windows fornece o PowerShell e outras ferramentas de linha de comando para administração de linha de comando.
  
  
• Como é um padrão, a conexão entre plataformas é permitida. Linux, Windows e até mesmo dispositivos portáteis, como leitores de RF ou telefones celulares, podem se conectar para a transferência de arquivos ou execução de aplicativos.
  
  
• O SSH em uma instância de nuvem do Windows fornece ao Windows funcionalidades básicas que instâncias de nuvem do Linux atualmente fornecem, mas com a flexibilidade e facilidade de uso associadas aos sistemas comuns baseados em Windows.

Vamos tratar de um sistema existente, que pode atender aos requisitos do fornecimento de acesso SSH à nuvem. Em seguida, veremos como esse sistema trata requisitos reais, como regulamentos PCI.

Voltar para parte superior

Soluções reais para SSH

O Fortress SSH Server da Pragma Systems é fácil de instalar e simples de usar. É possível configurar o software usando uma janela de diálogo ou um programa de linha de comando. Ele também é fácil de customizar, permitindo scripts de login definidos pelo usuário e shells de login customizáveis. O Fortress SSH Server também é projetado para implementação transparente e simples entre grandes ambientes corporativos.

O caso de uso de implementação a seguir irá mostrar como o SSH do Fortress pode ser usado para satisfazer os requisitos de segurança do Payment Card Industry (PCI).

Como parte da listagem principal de requisitos do Payment Card Industry para a transferência segura de dados e de informações importantes de pagamento, uma das chaves para PCI é o Requisito 4.1-4.1.1: Criptografar transmissão de dados do dono do cartão em redes públicas abertas. Ou seja, informações sigilosas devem ser criptografadas durante a transmissão pelas redes que são fácil e comumente interceptadas, modificadas e desviadas por um hacker, enquanto em trânsito. Esses requisitos são:

• 4.1: Use protocolos de criptografia e segurança fortes, como secure sockets layer (SSL)/ transport layer security (TLS) e Internet protocol security (IPSEC) para proteger dados sigilosos do dono do cartão durante a transmissão por redes públicas e abertas.
  
  
• 4.1.1: Para redes wireless que transmitem dados do dono do cartão, criptografe as transmissões usando tecnologia de acesso WiFi protegido (WPA ou WPA2), IPSEC VPN ou SSL/TLS. Nunca dependa exclusivamente de wired equivalent privacy (WEP) para proteger a confidencialidade e o acesso a uma LAN wireless.
  
  Se você usar WEP:
  • Use, no mínimo, uma chave de criptografia de 104 bits e um valor de inicialização de 24 bits.
  • Use somente em conjunto com tecnologia de acesso WiFi protegido (WPA ou WPA2), VPN ou SSL/TLS.
  • Faça a rotação de chaves WEP compartilhadas trimestralmente (ou automaticamente, se a tecnologia permitir).
  • Faça a rotação de chaves WEP compartilhadas sempre que houver mudanças de pessoal que possui acesso às chaves.
  • Restrinja o acesso com base no endereço de media access code (MAC).

Ao revisar as Seções 4.1 e 4.1.1, é importante observar que o SSH (incluindo o Fortress SSH da Pragma) usa os mesmos mecanismos de criptografia que o SSL/TLS e IPSEC — e, em seguida, dá um passo adicional, fornecendo efetivamente recursos de segurança adicionais.

O SSL é uma versão mais antiga de TLS: TLS 1.0 é o equivalente de SSL 3.0. O SSH foi inventado para fornecer acesso remoto e transferência de arquivos seguros (por meio de SFTP), assim como o SSL/TLS foi projetado para proteger e-commerce na web e o IPSEC foi projetado para fornecer acesso VPN. O SSH e SFTP se tornaram padrões de RFC e são amplamente implementados e adotados no segmento de mercado.

Além disso, as Notas de Visão Geral de Solicitação de Comentários (RFC) para a Internet lista duas propriedades básicas do protocolo TLS Record:

1. A conexão é privada. A criptografia simétrica é usada para criptografia de dados (como DES [DES] ou RC4 [RC4]). As chaves para essa criptografia simétrica são geradas de forma exclusiva para cada conexão e são baseadas em um segredo negociado por outro protocolo, como o TLS Handshake Protocol. O Record Protocol também pode ser usado sem criptografia.
   
   
2. A conexão é confiável. O transporte da mensagem inclui uma verificação de integridade da mensagem usando um MAC com chave. Funções hash seguras (como SHA ou MD5) são usadas para computações MAC. O Record Protocol pode operar sem um MAC, mas, em geral, é usado nesse modo apenas enquanto outro protocolo estiver usando o Record Protocol como um transporte para negociar parâmetros de segurança.

Em síntese, o TLS fornece um mecanismo para evitar que as pessoas vejam os dados que estão sendo transferidos (a conexão é privada) e um mecanismo para verificar se os dados que estão sendo recebidos são os mesmos que foram enviados (a conexão é confiável). O segundo recurso pode parecer um recurso básico de verificação de erro, mas, na verdade, tem a intenção de evitar que um hacker modifique os dados na rota.

Além disso, o IPSEC está definido em RFC 4301-4309. A Seção 2.1: Metas/Objetivos/Requisitos/Descrição de Problema, determina que:

O IPSEC é projetado para fornecer segurança interoperável de alta qualidade, baseada em criptografia para IPv4 e IPv6. O conjunto de serviços de segurança oferecidos inclui controle de acesso, integridade sem conexão, autenticação de origem de dados, detecção e rejeição de reproduções (uma forma de integridade de sequência parcial), confidencialidade (por meio de criptografia) e confidencialidade limitada do fluxo de tráfego. Esses serviços são fornecidos na camada IP, oferecendo proteção de forma padrão para todos os protocolos que podem ser transportados por meio de IP (incluindo o próprio IP). Na verdade, o IPSEC fornece um superconjunto de funcionalidade SSL/ TLS.

A partir disso, é evidente que a criptografia e a integridade da mensagem são importantes para manter a conformidade com PCI-DSS.

Os recursos de segurança do Fortress SSH da Pragma Systems se assemelham muito ao IPSEC, utilizando os mesmos algoritmos para criptografia: processamento de message authentication code (MAC) e trocas de chaves. Indo além da função de criptografia, no entanto, o SSH fornece às empresas o equilíbrio perfeito entre segurança e facilidade de uso. O Fortress SSH fornece mais flexibilidade em autenticação do que o SSL/TLS ou IPSEC, e é tão seguro quanto o SSL/TLS ou IPSEC. A tecnologia Fortress SSH da Pragma aborda diretamente os princípios de PCI DDS 10.2.4-10.2.5 expressados no Requisito 10.2.4-10.2.5: Controlar e monitorar todo o acesso a recursos de rede e aos dados do dono do cartão. Fornece autenticação robusta, incluindo senha, chave pública e mecanismos de autenticação Kerberos. O Fortress SSH também facilita rapidamente o controle e criação de log de tentativas inválidas de login e de conexões válidas.

Os mecanismos de criação de log e a capacidade de controlar as atividades dos usuários são fundamentais. A presença de logs em todos os ambientes permite o controle e a análise completos, se houver alguma falha. Determinar a causa de um comprometimento é muito difícil sem logs de atividades do sistema.

Voltar para parte superior

Conclusão

Neste artigo, descrevi os desafios de obter acesso seguro à nuvem e como o SSH pode ser usado para implementar um sistema seguro de acesso à nuvem (incluindo os componentes necessários para fazer isso). Além disso, enumerei algumas das melhores práticas para implementar um sistema de acesso SSH efetivo para um ambiente em nuvem e forneci um exemplo real do produto Fortress SSH da Pragma Systems.

Recursos

Aprender

• O developerWorks fornece uma biblioteca abrangente de recursos de uso do SSH, que podem ser interessantes, com relação a este artigo:
  • Tunneling with SSH é um clássico que demonstra a conectividade do Windows com o UNIX em um mundo seguro.
  • Three locks for your SSH door explica como especificar quem pode usar o SSH, aplicação de técnicas de port-knocking e como ocultar o fato de que o acesso SSH existe.
  • More locks for your SSH door estende o recurso anterior, demonstrando como aprimorar o acesso SSH, eliminando senhas e usando pares de chaves públicas/privadas. Também explora como reconhecer e bloquear possíveis ataques, incluindo ataques de força bruta e de dicionários, negando acesso ao servidor a origens identificadas como não seguras.
  • Acesso Multiusuário Seguro a Instâncias da Nuvem IBM com VNC e SSH mostra como configurar instâncias de nuvem e clientes para acesso gráfico remoto seguro.
  • Proteger o acesso para dispositivo Android demonstra como configurar um dispositivo móvel Android para acessar uma instância da Nuvem IBM de forma segura.
  
  
• Para saber mais sobre como realizar tarefas na nuvem IBM, visite estes recursos:
  • Knowledge path: Build an effective cloud policy
  • Faça upload e download de arquivos a partir de uma instância do Windows
  • Instalar o servidor da web IIS no Windows 2008 R2
  • Crie uma instância da nuvem IBM com a linha de comando do Linux
  • Crie uma instância da nuvem IBM com a linha de comando do Windows
  • Estenda a sua rede corporativa com a nuvem IBM
  • Aplicativos de alta disponibilidade na nuvem IBM
  • Parametrize imagens de nuvem para instâncias customizadas dinamicamente
  • Abordagens focadas no Windows para fornecimento na nuvem IBM
  • Implemente produtos usando o serviço de implementação rápida
  • Integre a política de autenticação usando um proxy
  • Configure o Linux Logical Volume Manager
  • Implementar uma topologia complexa usando uma ferramenta de utilitário de implementação
  • Forneça e configure uma instância que envolve uma VLAN pública e privada
  • Proteger o acesso à IBM Cloud para dispositivos Android
  
  
• Nos recursos do desenvolvedor em nuvem do developerWorks, descubra e compartilhe o conhecimento e a experiência dos desenvolvedores de aplicativos e serviços que estão criando os seus projetos de implementação de nuvem.
  
  
• Veja uma lista das imagens do produto disponíveis para IBM SmartCloud Enterprise.
  
  
• Descubra como acessar o IBM SmartCloud Enterprise.
  
  

Obter produtos e tecnologias

• Visite o site da Nuvem IBM para obter ofertas de nuvem atuais.
  
  

Discutir

• Faça parte de um grupo de computação em nuvem no developerWorks.
  
  
• Leia todos os ótimos blogs sobre nuvem no developerWorks.
  
  
• Faça parte da comunidade do developerWorks, uma rede profissional e conjunto de ferramentas comunitárias para conectar, compartilhar e colaborar.
  
  

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Desafios para proteger o acesso à nuvem
• SSH como uma abordagem de segurança de acesso à nuvem
• Soluções reais para SSH
• Conclusão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais