Boas práticas de controle de acesso em soluções multiarrendatárias da nuvem usando o Tivoli Access Manager

Forneça percepção de arrendatário e conexão única ao mesmo tempo que protege seus recursos de aplicativo

Neste quarto artigo sobre as melhores práticas para o desenvolvimento de aplicativos multiarrendatários no IBM SmartCloud Enterprise, aprender a usar o IBM Tivoli Access Manager para fornecer percepção de arrendatário, proteger os recursos do seu aplicativo e fornecer conexão única.

Hoje em dia, as plataformas na nuvem e soluções baseados na nuvem são uma realidade. Cada vez mais empresas estão aproveitando softwares, soluções e serviços hospedados, terceirizando competências não fundamentais e reduzindo custos. Ao desenvolverem vários aplicativos de Software como Service (SaaS), os autores utilizaram o IBM Tivoli Access Manager como componente compartilhado na nuvem da IBM para satisfazer muitos requisitos em torno da segurança. Este artigo descreve a função fundamental que o Tivoli Access Manager desempenha em impor a segurança entre arrendatários.

Christina Lau, Senior Technical Staff Member, IBM Canada Ltd.

Christina LauChristina Lau é Distinguished Engineer em WebSphere, experiente em tecnologias emergentes, como computação remota e em nuvem. Atualmente, trabalha no desenvolvimento de tecnologias avançadas, que suportam o fornecimento de serviços de nuvem on-line em todo o portfólio de BPM, conectividade e ILOG.


nível de autor Contribuidor do
        developerWorks

Thomas Mikalsen, Senior Software Engineer, IBM

Thomas MikalsenThomas Mikalsen trabalha atualmente em tecnologias avançadas de suporte à computação em nuvem e no fornecimento baseado na nuvem de serviços de software. A formação de Tom inclui pesquisa, design e desenvolvimento de soluções de middleware corporativas e avançadas nas áreas de computação orientada a serviços, sistemas distribuídos e processamento de transações.



Bhadri Madapusi, Software Developer, IBM

Bhadri MadapusiBhadri Madapusi é desenvolvedor consultivo de software na WebSphere, atualmente concentrado em projetos para a nuvem. Bhadri tem mais de 10 anos de experiência em desenvolvimento de software. Antes, ele trabalhou em gerenciamento de processos de negócios e WebSphere Commerce.



26/Mai/2011

Introdução

O multiarrendamento é uma abordagem para apoiar vários clientes em um único ambiente de aplicativo compartilhado. Para explorar ainda mais a economia de escala, também é desejável apoiar múltiplos aplicativos SaaS dentro de uma única plataforma de entrega compartilhada SaaS. A própria plataforma de entrega SaaS se torna ativada para múltiplos arrendatários, e estes são aplicativos multiarrendatários. Dentro de uma plataforma dessas, impor restrições de segurança entre aplicativos e entre arrendatários de aplicativo é um requisito essencial e o Tivoli Access Manager pode desempenhar um papel-chave nisso. A Figura 1 mostra os componentes em geral do Tivoli Access Manager em execução na nuvem da IBM e seus relacionamentos com outros componentes de software.

Figura 1: Tivoli Access Manager em execução no ambiente de produção na nuvem da IBM
Figura 1: Tivoli Access Manager em execução no ambiente de produção na nuvem da IBM

Especificamente:

  • Tivoli Access Manager WebSEAL Server: Um componente de proxy de segurança que garante o acesso a servidores da Web e gerencia o espaço na Web de forma centralizada, ligando todos os servidores da Web em um espaço da Web lógico.
  • Apache Server: Atua como proxy reverso e distribui a carga de solicitações de entrada para os aplicativos SaaS. Reescreva a URL em cada solicitação de entrada para corresponder ao local interna relevante do recurso solicitado.
  • Tivoli Access Manager Policy Server: Apoia a definição de políticas e a administração de segurança com base nas políticas. Por exemplo, regras de senha.
  • Tivoli Access Manager LDAP (Lightweight Directory Access Protocol): Um servidor de diretório que armazena informações sobre seus usuários autorizados e os privilégios que cada usuário tem.
  • Servidor de gerenciamento de arrendatário: Usado para gerenciar informações sobre uma oferta de SaaS, as empresas e os usuários que estão inscritos para a oferta, o número de edições ou lugares em uma oferta, seus preços, etc.
  • Servidores de aplicativo SaaS: Cluster de servidores de aplicativo específicos de cada aplicativo SaaS.
  • As linhas verticais representam as configurações de firewalls. Os firewalls nesse desenho simulam a configuração tradicional de zona desmilitarizada (DMZ) para firewalls corporativos entre a intranet e a Internet. Sua função é adicionar controle de acesso adicional ao nível de IP.

O Tivoli Access Manager para e-business é um produto maduro que proporciona segurança robusta e baseada em políticas para ambientes da Web corporativos. Isso inclui a autenticação de usuários, controle de privilégios de acesso, auditoria, conexão única, alta disponibilidade e registro que são elementos de uma solução de gerenciamento de segurança. Há muitos documentos excelentes que descrevem seus recursos. No cenário a seguir, vamos nos concentrar nas áreas onde ele é específico para a nuvem e o gerenciamento de arrendatários.


Controle de acesso de alta granularidade

Em geral, é possível classificar recursos de aplicativos (por exemplo, uma URL como http://www.mycompany.com/logo.gif) como desprotegidos ou protegidos. Os recursos desprotegidos são acessíveis a qualquer usuário e não requerem autenticação. Exemplos de recursos desprotegidos podem ser imagens estáticas, páginas de login, páginas de registro, demos, material promocional de marketing, etc.

Recursos protegidos são acessíveis a um usuário apenas depois que ele é autenticado e os detalhes sobre ele, como suas funções, a que organizações ou equipes ele pertence, etc., são determinados. Exemplos de recursos protegidos podem ser perfis de usuário, documentos, e-mails, widgets de aplicativo, e assim por diante.

Para simplificar a especificação de recursos protegidos versus desprotegido no servidor de políticas do Tivoli Access Manager, geralmente é desejável agrupar recursos em um prefixo de URL comum, e proteger ou desproteger os recursos contidos como grupo. Por exemplo:

protect   /secure
unprotect /public

Essas regras podem ser acrescentadas facilmente ao servidor de políticas do Tivoli Access Manager, e impostas pelo Tivoli Access Manager WebSEAL.

Quando chega uma solicitação de HTTP, o WebSEAL trabalha com o servidor de políticas para determinar se o recurso solicitado está protegido. Se estiver protegido, o WebSEAL confirma se o usuário está autenticado antes de permitir que a solicitação chegue ao aplicativo - por exemplo, o usuário está inscrito para o serviço? Ele especificou a senha correta?

O WebSEAL também é usado para estabelecer um contexto de arrendatário para a solicitação. O contexto de arrendatário inclui metadados para identificar a que arrendatário o usuário pertence para que as restrições apropriadas possam ser aplicadas. Por exemplo, o arrendatário 1 pode se inscrever para os aplicativos SaaS 1 e 2, enquanto o arrendatário 2 se inscreve para os aplicativos SaaS 2 e 3. O contexto de arrendatário é propagado para o recebimento de dados como cabeçalhos de solicitação HTTP e informa os servidores de recebimento de dados sobre a identidade do usuário, sua função, identidade de arrendatário associada e autorizações. O servidor HTTP Apache impõe autorização de alta granularidade, enviando a solicitação HTTP para o serviço adequado com base na autorização do cliente, oferece suporte ao balanceamento de carga e permanência.


Controle de acesso de baixa granularidade

Um aplicativo talvez precise impor controles adicionais de granularidade mais baixa que restrinjam ainda mais o acesso a recursos protegidos. Esses controles adicionais podem ser baseados em funções de usuário e/ou autorizações de arrendatário obtidas a partir do contexto de arrendatário. Por exemplo, determinado usuário pode ter autorização para criar e editar um processo de negócio, mas não de implantá-lo. Determinado usuário pode ser designado a uma função administrativa para que possa excluir ativos criados por outros membros da mesma conta.


Login e página inicial exclusivos para cada aplicativo SaaS

O WebSEAL permite que suas várias páginas relacionadas à autenticação sejam customizadas usando páginas de modelo. No entanto, para uma plataforma de entrega SaaS multiarrendatário, o nível de customização oferecido pelo WebSEAL não é suficiente. E se quisermos páginas de login diferentes para cada aplicativo SaaS ou talvez até mesmo páginas de login específicas para o arrendatário? Felizmente encontramos uma solução por meio de redirecionamentos HTTP simples. A Figura 2 mostra a abordagem como um todo.

Figura 2: Página de login customizada para cada aplicativo SaaS apoiado por WebSEAL
Figura 2: Página de login customizada para cada aplicativo SaaS apoiado por WebSEAL

Um usuário navega até a página de login do aplicativo SaaS (seta 1). A página de login do aplicativo SaaS, então, usa o XMLHttpRequest (XHR) para postar credenciais para o Serviço de Login do WebSEAL (seta 2). A resposta (seta 3) é analisada pelo JavaScript na página de login do aplicativo SaaS para detectar o sucesso ou o fracasso do login.

Se um usuário tenta acessar diretamente uma página protegida sem primeiro efetuar login (por exemplo, usando um marcador ou por meio de um link), o servidor WebSEAL retornará sua página de login padrão. Essa página de login padrão pode ser customizada para redirecionar o usuário para a página de login correta do aplicativo SaaS.

Essa abordagem geral pode ser estendida para apoiar as páginas adicionais do WebSEAL a fim de executar indireto adequado - por exemplo, redefinição de senha, redirecionamento para páginas personalizadas diferentes para um usuário após o login bem-sucedido, etc.


Clusters do WebSEAL para acesso diferente

Uma coisa a notar é que um servidor WebSEAL pode ser configurada para oferecer suporte à autenticação de acesso básico ou à autenticação baseada em formulário, mas não a ambas. Portanto, é preciso implementar vários servidores WebSEAL, alguns configurados para autenticação de acesso básico e alguns para autenticação baseada em formulário a fim de suportar diferentes tipos de acesso de cliente, como formulários da Web, acesso remoto, Eclipse, etc.

Esses servidores do WebSEAL compartilham o servidor de políticas comum do Tivoli Access Manager e têm diante deles um proxy reverso de front-end Apache que encaminha o tráfego para o servidor WebSEAL correto usando o módulo mod_rewrite do Apache:

  • Se a solicitação tem um cabeçalho de acesso básico (isto é, HTTP:Autorização), ela encaminha a solicitação para o WebSEAL ativado para acesso básico.
  • Caso contrário, a encaminha para o WebSEAL ativado para formulário.

O proxy reverso de front-end também cuida do balanceamento de carga entre os servidores WebSEAL.


Usando firewalls para aumentar a segurança

A nuvem da IBM é uma nuvem pública, isso significa que cada máquina virtual, por padrão, é acessível de qualquer lugar do mundo. No entanto, não queremos que todas as nossas máquinas virtuais sejam diretamente acessíveis, por exemplo, a máquina virtual que executa nosso servidor de banco de dados só deve ser acessível por nossos servidores de aplicativos, o repositório de ativos que descrevemos no artigo anterior só deve ser acessível por nossos aplicativos SaaS, e assim por diante. Firewalls desempenham um papel fundamental em acrescentar essas camadas extras de proteção de segurança.

No artigo Introdução ao IBM Smart Business Development and Test on the IBM Cloud (consulte Recursos), os autores explicam os prós e contras de configurar regras de firewall no nível do hypervisor versus no nível das máquinas virtuais em si. Em vista da natureza dinâmica do nosso ambiente, onde precisamos adicionar ou remover máquinas virtuais facilmente com base no uso, utilizamos a abordagem de iptables para definir regras de firewall apropriadas para cada máquina virtual.

Um cenário simples de regras de firewall

A imagem do SO base só vem com uma porta aberta para a entrada: a porta 22, possibilitando usar SSH (shell seguro) nela. No entanto, quando instalamos um aplicativo em uma máquina virtual, abrimos portas extras para que seu aplicativo possa ser acessado. Por exemplo, na Figura 3, existem dois aplicativos, o acesso do aplicativo 1 se dá via HTTP, na porta 8081, e o do aplicativo 2, via HTTP, na porta 8082.

Figura 3: Exemplos de regras de firewall
Figura 3: Exemplos de regras de firewall

No entanto, provavelmente não vamos quer abrir essas portas para qualquer pessoa do mundo poder acessar sem passar pelo controle de acesso adequado. É aí que acrescentamos regras adicionais de firewall para proteção extra.

Na máquina virtual (9.8.7.6) onde o Aplicativo 1 está em execução, acrescente uma regra de firewall como:

-A INPUT -s 1.2.3.4 -p tcp -m tcp -dport 8081 -j ACCEPT

Isso abre a porta 8081, mas ela é acessível apenas pela máquina virtual 1.2.3.4, que é o servidor Apache.

De modo similar, na máquina virtual (5.1.2.3) onde o Aplicativo 2 está em execução, acrescente uma regra de firewall para abrir a porta 8082, como segue:

-A INPUT -s 1.2.3.4 -p tcp -m tcp -dport 8082 -j ACCEPT

Agora, supondo que o servidor Apache (1.2.3.4) possa ser acessado via porta 80, podemos acrescentar a seguinte regra de firewall ao servidor Apache para abrir apenas a porta 80, como segue:

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Outro padrão comum que é útil é ativar uma máquina virtual para aceitar a entrada de si mesmo, permitindo o suporte a loopback. Por exemplo, é possível implementar um agente de sistema operacional em uma máquina virtual de modo que ele possa relatar seu status para o IBM Tivoli Enterprise Portal; o agente neste caso talvez precise se conectar a serviços executados localmente. Para ativar esse suporte a loopback, acrescente a seguinte regra de firewall:

- A INPUT -i lo -j ACCEPT

Finalmente, é importante testar suas regras de firewall e salvá-las adequadamente. Certifique-se de que o iptables esteja inicializado com suas novas configurações quando a máquina virtual reiniciar e não com a configuração padrão. Dê os seguintes comandos para salvar as regras de firewall:

/sbin/service iptables save

Gerenciando cuidadosamente quem pode acessar o que usando autenticação e regras de firewall, é possível proteger suas máquinas virtuais que compõem sua solução de nuvem em execução na Internet pública.


Resumo

A segurança é frequentemente citada como um dos principais inibidores da adoção da nuvem. Neste artigo, mostramos como usar produtos maduros, como IBM Tivoli Access Manager para e-business, a fim de implementar uma solução de controle de acesso que pode proteger seus recursos de nuvem e suportar uma arquitetura multiarrendatário. A IBM também publicou um red paper: "Cloud Security Guidance IBM Recommendations for the Implementation of Cloud Security" (veja Recursos). Ele fornece insights adicionais sobre o que levar em conta para ter uma solução de nuvem segura.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tivoli, Cloud computing
ArticleID=661062
ArticleTitle=Boas práticas de controle de acesso em soluções multiarrendatárias da nuvem usando o Tivoli Access Manager
publish-date=05262011