Plataforma e infra-estrutura

  • Artigo

Capítulo 3: Problemas e requisitos

Publicado em: 11 de maio de 2004 | Atualizado em: 26 de junho de 2006

Para implementar uma infra-estrutura eficiente de gerenciamento de acesso e identidades na organização, você precisa escolher uma plataforma de tecnologia analisando de maneira criteriosa os requisitos da organização em relação aos recursos de tecnologia. Essa análise funcional assegura que a solução atenda às metas da sua empresa e, ao mesmo tempo, mantenha a plataforma protegida e gerenciável.

Este documento aborda essas questões usando a empresa fictícia Contoso Pharmaceuticals. O objetivo do cenário da Contoso Pharmaceuticals é trazer idéias sobre como resolver os problemas que uma organização típica pode enfrentar ao lidar com questões comuns de gerenciamento de acesso e identidades.

Nesta página

Apresentando a Contoso Pharmaceuticals
Problemas comerciais e de tecnologia
Ameaças e medidas defensivas
Requisitos de plataforma

Apresentando a Contoso Pharmaceuticals

A Contoso Pharmaceuticals é uma empresa fictícia sediada nos Estados Unidos, e sua matriz e a principal instalação de manufatura localizam-se em Orlando, na Flórida. Atualmente a Contoso possui 5.300 funcionários e uma receita anual de US$ 3,8 bilhões.

O sucesso da empresa se deve em grande parte a uma cultura corporativa cujo foco é o pioneirismo em pesquisa e desenvolvimento. A Contoso Pharmaceuticals é reconhecida por seu compromisso com o atendimento ao cliente e por suas instalações de produção de baixo custo. A empresa teve um sólido crescimento nos últimos dois anos, em parte impulsionado pela aquisição de uma empresa menor de suprimentos farmacêuticos do Reino Unido, a Fabrikam Ltd. (igualmente fictícia). Estão previstas várias outras aquisições como essa, que irão fortalecer a posição da empresa controladora no mercado.

Departamento de tecnologia da informação

O departamento de TI da Contoso é formado por várias centenas de profissionais técnicos e de gerência. Os 22 administradores de sistema em período integral gerenciam mais de 500 servidores de todos os tipos, incluindo computadores com sistemas operacionais de servidor baseados no Microsoft® Windows®, o Sun ONE Directory Server 5.1 (anteriormente iPlanet Directory Server) e mainframes que executam aplicativos personalizados e de terceiros. Os administradores também cuidam da infra-estrutura do Microsoft Exchange Server da empresa e de um site de portal interno da Contoso para os funcionários. Os demais servidores são dedicados a serviços de arquivos e impressão e funções de banco de dados.

Administrar os controladores de domínio Microsoft Windows Server™ 2003 e o serviço de diretório Microsoft Active Directory® da empresa é uma parte importante das operações diárias. Uma das várias tarefas executadas pelos administradores de domínio é a configuração de contas no Active Directory.

A Contoso tem uma equipe de suporte técnico grande e bem treinada, que permanece ativa 24 horas por dia, sete dias por semana. Os operadores de suporte técnico oferecem suporte para aplicativos como email, processadores de texto e aplicativos comerciais, além de assistência à redefinição de senhas para funcionários que não conseguem acessar os sistemas da empresa. A Contoso também possui diversos arquitetos de infra-estrutura e segurança, que estudam as necessidades de TI de cada departamento e da empresa como um todo para elaborar propostas de estratégias, investimentos e padrões de TI.

Sistemas operacionais

Uma grande variedade de plataformas e aplicativos de sistema compõe a infra-estrutura de TI da Contoso Pharmaceuticals. Embora servidores e clientes baseados no Windows formem a maior parte de seus sistemas, a Contoso também possui sistemas fundamentais para os negócios, entre os quais estão servidores que executam o Sun ONE Directory Server 5.1 e estações de trabalho com o Sun Solaris 9. Os sistemas com o Sun Solaris 9 atualmente são gerenciados com o NIS (Network Information System).

O projeto do Active Directory na intranet da Contoso possui uma única floresta, com um domínio raiz vazio e um único domínio filho. As contas de usuário, os serviços e as máquinas originais da Contoso foram todos migrados para o Active Directory a partir de domínios do Microsoft Windows NT® 4.0. A empresa também opera os servidores DNS externos que atendem ao domínio de Internet Contoso.com. Esses servidores DNS são separados dos servidores internos, que atendem à floresta do Active Directory da intranet.

Armazenamentos de identidades adicionais

Na recente aquisição da Fabrikam Ltd., a Contoso também adquiriu vários produtos de infra-estrutura, como o Lotus Notes Release 6.5.4 para mensagens e um servidor com o Sun ONE Directory Server 5.1, que oferece os serviços de autenticação e diretório para um aplicativo da Web desenvolvido de maneira personalizada. Esses sistemas ainda são necessários para dar suporte às atividades dos ex-funcionários da Fabrikam a curto prazo. O plano de longo prazo requer a migração da infra-estrutura da Fabrikam para o ambiente existente da Contoso.

Problemas comerciais e de tecnologia

A Contoso opera em um ambiente altamente competitivo, no qual o tempo para entrada no mercado é um fator muito importante. Os testes clínicos são grandes investimentos, e um atraso de um único dia na entrega dos resultados ou no envio de um produto para aprovação pelo FDA (Food and Drug Administration) dos EUA pode custar à empresa quase um 1 milhão de dólares. Portanto, a interação com usuários e parceiros é uma parte fundamental das operações da empresa. As regulamentações são outro fator digno de consideração, uma vez que as multas e penalidades podem variar de milhões a dezenas de milhões de dólares.

Um dos principais desafios que a Contoso enfrenta é expandir a qualidade e o escopo da interação da organização com clientes, parceiros e funcionários que trabalham remotamente. Novas maneiras de interagir com clientes para obter seus comentários e de comunicar as vantagens dos produtos da organização resultaram em muitos aprimoramentos. Esses aprimoramentos envolvem o processo de desenvolvimento de produtos para criar produtos mais apropriados às necessidades dos clientes, o que aumenta a participação da empresa no mercado. Todavia, historicamente o envolvimento da administração tornou esse processo oneroso e difícil de manter.

A Contoso sabe que aperfeiçoar as soluções de tecnologia que utiliza para colaborar com parceiros aumentará a eficiência do processo de desenvolvimento de produtos. Ao mesmo tempo, os funcionários estão trabalhando com mobilidade cada vez maior e precisam ter acesso facilitado aos dados necessários para realizarem seu trabalho, tanto pela rede corporativa quanto pela Internet.

A Contoso avalia que uma plataforma de gerenciamento de acesso e identidades deve aprimorar a capacidade de gerenciamento e a segurança da infra-estrutura, especificamente nas áreas de gerenciamento de identidades digitais. Como objetivo a longo prazo, a empresa deseja consolidar os armazenamentos de identidades duplicados para aplicativos separados em um armazenamento centralizado, que proporcionará maior eficiência administrativa e menor TCO (custo total de propriedade) e resultará em menos erros administrativos e mais segurança.

No entanto, os arquitetos e administradores da Contoso estão cientes de que há problemas de curto e médio prazos que eles precisam resolver para poder atingir essas metas, principalmente na área da segurança. A seção "Ameaças e medidas defensivas", mais adiante neste documento, resume essas preocupações com a segurança e as medidas defensivas que podem diminuir ou neutralizar as ameaças.

A Contoso Pharmaceuticals identificou as seguintes principais necessidades em seu plano de dois anos para melhorar o gerenciamento de acesso e identidades:

  • Oferecer a melhor infra-estrutura de tecnologia possível para rapidamente desenvolver, avaliar e comercializar os produtos da empresa.

  • Aumentar o nível de eficiência e segurança da infra-estrutura de TI da empresa, principalmente através do gerenciamento de identidades digitais, a fim de abrir caminho para um crescimento ainda maior sem a necessidade de acumular mais sobrecarga administrativa e aumentar a complexidade de TI.

  • Consolidar mecanismos de segurança e privacidade e tecnologias relacionadas para atender a exigências normativas do governo, como a Parte 11 do FDA 21 do CFR (Code of Federal Regulations) e a lei americana HIPAA (Health Insurance Portability and Accountability Act) de 1996.

Para atender a essas necessidades, a Contoso empreendeu uma revisão abrangente de seus aplicativos e processos mais importantes. A próxima seção identifica cada um desses principais ativos.

Principais ativos de TI

A Contoso Pharmaceuticals identificou vários ativos de TI que são da maior importância para a empresa. Os seguintes ativos contribuem com recursos-chave para resolver os principais problemas técnicos e comerciais da empresa:

  • O aplicativo Sales and Contacts, que pode ser acessado via extranet, e as contas de usuário dos funcionários de vendas.

  • O aplicativo Partner Research, que pode ser acessado via extranet, e o armazenamento de identidades de parceiros da extranet.

  • O aplicativo de envio de comentários Customer Trial, que pode ser acessado via extranet, e o armazenamento de identidades de clientes da extranet.

  • Dados de aplicativos e contas de usuário do SAP.

  • Infra-estrutura e contas de email do Microsoft Exchange.

  • Infra-estrutura e contas de email do Lotus Notes.

  • Aplicativos que usam contas de usuário do Sun ONE Directory Server 5.1 e do UNIX.

O diagrama a seguir resume esses principais ativos.

Figura 3.1. Principais ativos de TI da Contoso

Figura 3.1. Principais ativos de TI da Contoso

O aplicativo Sales and Contacts acessível via extranet

A equipe de vendas da Contoso passa um tempo considerável fora do escritório, visitando clientes e fazendo novos negócios. A equipe precisa manter o controle sobre as vendas e os contatos de vendas, o que é feito por meio de um aplicativo da Web e de um banco de dados hospedado na rede de perímetro da Contoso, também chamada de DMZ (zona desmilitarizada). As informações mantidas pelo aplicativo não são altamente confidenciais. Contudo, a exposição desses dados poderia acarretar problemas para a Contoso e seus parceiros de negócios, e teria um impacto ainda maior sobre a opinião pública acerca da integridade da empresa.

A indisponibilidade do aplicativo criaria o mais grave problema, pois comprometeria seriamente a eficiência da equipe de vendas.

Contas de usuário dos funcionários de vendas

As contas de usuário individuais dos funcionários de vendas podem acessar material confidencial dentro de um escopo específico via extranet. Essas contas também poderiam ser usadas indevidamente para preparar um ataque à organização Contoso e seus recursos de TI.

O aplicativo Partner Research acessível via extranet

A colaboração com parceiros de pesquisa é fundamental para o desenvolvimento de novos produtos, do qual a Contoso depende para seu futuro crescimento. Grande parte dessa colaboração se dá por meio de um único aplicativo, hospedado na rede de perímetro da Contoso. Embora sejam feitos backups periódicos dos dados do aplicativo, um ataque bem-sucedido contra ele poderia causar sérios problemas para a Contoso — os dados de pesquisas revelados poderiam gerar uma desvantagem em relação à concorrência e levar a uma possível ação normativa.

O armazenamento de contas de parceiros da extranet

As contas de parceiros têm menos acesso aos recursos de TI da Contoso do que as contas de funcionários. As contas de parceiros só permitem acessar o aplicativo Partner Research. No entanto, se uma única conta ou todo o armazenamento de contas for comprometido, isso poderia comprometer no mínimo uma parte do aplicativo. Novamente, isso poderia gerar desvantagem em relação à concorrência e levar a uma possível ação normativa.

O aplicativo Customer Trial acessível via extranet

O sucesso dos produtos da Contoso depende dos comentários fornecidos pelos clientes durante o ciclo de desenvolvimento dos produtos. Uma das formas pelas quais a Contoso tira proveito da tecnologia é oferecendo um aplicativo da Web através do qual os clientes podem fazer comentários sobre os produtos na fase de avaliação.

A Contoso coleta aproximadamente 50% dos comentários dos clientes através do aplicativo Customer Trial. Uma interrupção no funcionamento desse aplicativo prejudicaria seriamente a capacidade da empresa de realizar testes e encaminhar os resultados ao FDA, o que poderia levar a uma ação normativa se o FDA tivesse motivos para julgar que a segurança do aplicativo foi comprometida.

O armazenamento de contas de clientes da extranet

As contas de clientes têm menos acesso aos recursos de TI da Contoso do que as contas de funcionários. As contas de clientes só permitem acessar o aplicativo de envio de comentários Customer Trial. No entanto, se uma única conta ou todo o armazenamento de contas for comprometido, isso poderia comprometer no mínimo uma parte do aplicativo. Outro fator de contribuição seria o dano causado às relações com clientes devido à percepção de que práticas de segurança deficientes da Contoso poderiam levar ao vazamento de informações confidenciais dos clientes. Novamente, isso poderia resultar em uma ação normativa contra a empresa.

Dados de aplicativos e contas de usuário do SAP

A Contoso implementou diversos aplicativos de ERP (planejamento de recursos corporativos) baseados no SAP. Alguns deles fornecem funções comerciais críticas e distribuem dados confidenciais para os usuários. O comprometimento desses dados poderia impedir a empresa de competir no mercado ou resultar em altas multas por violação de exigências normativas.

Contas de usuário individuais podem ser utilizadas para acessar material confidencial no escopo do aplicativo do SAP. Isso poderia resultar no vazamento de informações financeiras para investidores que poderiam prejudicar a Contoso.

Email do Microsoft Exchange

A Contoso usa o Microsoft Exchange Server e o Microsoft Outlook® para o email interno e externo. O comprometimento desses dados poderia fazer com que a concorrência tivesse acesso a informações confidenciais e também levar a uma ação normativa.

Email do Lotus Notes

A Fabrikam Ltd. usava o Lotus Notes para o email interno e externo, e esse ambiente foi migrado durante a fusão com a Contoso. O comprometimento desses dados poderia fazer com que a concorrência tivesse acesso a informações confidenciais e também levar a uma ação normativa.

Sun ONE Directory Server 5.1 e contas de usuário do UNIX

O Sun ONE Directory Server 5.1 oferece serviços de diretório e suporte à autenticação para um aplicativo da Web personalizado que a Fabrikam utiliza. O comprometimento desse aplicativo e de seus dados poderia levar a uma desvantagem em relação à concorrência e a uma possível ação normativa.

As contas de usuário individuais do UNIX podem acessar material confidencial dentro de um escopo específico na Contoso. Essas contas também poderiam ser usadas indevidamente para preparar um ataque à organização Contoso e seus recursos de TI.

Concluindo a análise

Após concluir a análise de seus ativos de TI, a Contoso identificou os seguintes problemas na atual plataforma de gerenciamento de acesso e identidades:

  • Não existe uma estratégia clara para diminuir o custo e a complexidade do gerenciamento de identidades digitais no ambiente da Contoso.

  • A configuração e a desconfiguração de usuários para aplicativos de cliente não são padronizadas.

  • Os aplicativos em desenvolvimento complicam a infra-estrutura de TI ao adicionar mais armazenamentos de identidades.

  • Os mecanismos de autenticação geralmente são desenvolvidos de maneira personalizada para cada aplicativo ou são mecanismos obsoletos que constituem um padrão em sistemas herdados. Em ambos os casos, a implementação desses mecanismos é cara, e normalmente eles não são suficientemente seguros contra as muitas ameaças presentes nos ambientes de computação atuais.

  • A autorização de aplicativos é uma preocupação, pois os desenvolvedores costumam implementar mecanismos personalizados, o que aumenta o tempo e o custo de desenvolvimento e manutenção.

Ameaças e medidas defensivas

Muitos dos problemas de segurança do gerenciamento de acesso e identidades na verdade são vulnerabilidades de segurança. Uma vulnerabilidade é um ponto fraco de um sistema de informação ou de seus componentes que poderia ser explorado para gerar uma brecha na segurança. As vulnerabilidades podem resultar de problemas com pessoas, processos ou tecnologias. Os exemplos incluem procedimentos de segurança do sistema, design de hardware ou controles internos. As vulnerabilidades podem surgir em qualquer ponto das defesas de uma rede, e a avaliação normalmente faz parte de uma revisão geral da segurança.

Ameaças atuais

A Contoso Pharmaceuticals acaba de concluir uma importante revisão da segurança da sua rede. Parte da revisão incluiu a classificação das ameaças à rede. Ao criar o escopo do seu projeto de gerenciamento de acesso e identidades, a Contoso decidiu considerar acima de tudo os ataques em potencial de origens internas e externas. As ameaças internas abrangem aquelas cujo alvo é a intranet, enquanto as externas são específicas da extranet.

Problemas e vulnerabilidades de segurança

O ambiente da Contoso apresenta uma série de vulnerabilidades relacionadas aos problemas comerciais e de tecnologia abordados anteriormente neste capítulo. Do ponto de vista da segurança, a solução de gerenciamento de acesso e identidades da Contoso deve lidar com as seguintes questões:

  • A Contoso deve disponibilizar mais de suas informações comerciais através de aplicativos de Internet, mas os mecanismos de segurança implementados na rede interna não são fortes ou consistentes o bastante para permitir o acesso disseminado a essa rede.

  • As brechas na segurança da Contoso são difíceis de investigar porque existem apenas evidências incompletas, desconexas e dispersas, que estão disponíveis nos logs de auditoria de segurança.

  • Os armazenamentos de identidades de aplicativos existentes não são seguros, e um ataque às contas de usuário controladas por eles é tanto possível quanto provável de ocorrer.

  • Os mecanismos de autenticação de aplicativos existentes não são seguros, e um ataque aos mecanismos de autenticação é tanto possível quanto provável de ocorrer.

  • Os mecanismos de autorização de aplicativos existentes são mal projetados, e um ataque a eles é tanto possível quanto provável de ocorrer.

A primeira vulnerabilidade realça o desafio constante do gerenciamento de acesso e identidades: os sistemas que fazem interface com clientes, parceiros ou funcionários só trarão benefícios se essas pessoas puderem acessá-los. No entanto, o próprio ato de conceder acesso aumenta o risco à segurança.

Dividindo ainda mais essas categorias, a revisão da segurança da Contoso identificou as seguintes vulnerabilidades de processos e contas que ficam abertas para exploração por origens internas e externas:

  • Configuração de contas

  • Desconfiguração de contas

  • Contas de estações de trabalho UNIX

  • Autenticação do SAP

  • Proteção de dados de aplicativos do SAP

  • Contas de funcionários

  • Contas de parceiros

  • Contas de clientes

As vulnerabilidades de contas de funcionários, parceiros e clientes são parecidas, mas as de contas de funcionários têm implicações mais sérias.

Configuração de contas

A configuração ineficiente ou incompleta não é uma ameaça direta à segurança, porque nominalmente ela só prepara o terreno para a incapacidade de acessar recursos de aplicativos e da rede. Todavia, mecanismos inadequados de configuração de contas podem levar a outras práticas que constituem uma ameaça direta à segurança, como o compartilhamento de contas ou a permissão de acesso anônimo a ativos valiosos.

O compartilhamento de contas é o principal risco associado à vulnerabilidade da configuração de contas. Um relatório recente elaborado pelo suporte técnico da Contoso afirma que essa prática disseminada está produzindo muitos incidentes de suporte devido a tentativas de logon mal-sucedidas, que levam ao bloqueio de contas, e fazendo com que vários usuários utilizem simultaneamente a mesma identidade para acessar recursos.

Uma pesquisa anônima de acompanhamento realizada pelo departamento de TI da Contoso descobriu que o motivo número um pelo qual os usuários compartilham contas é que novos funcionários não têm suas contas configuradas com rapidez suficiente para acessar aplicativos e recursos de rede. Esse compartilhamento de identidades ocorreu principalmente entre os prestadores de serviços, que costumam completar vários meses de trabalho antes de receber o acesso apropriado de que precisam para desempenhar suas funções.

Os supervisores resolvem esse problema concedendo à equipe eventual nomes de usuário e senhas estabelecidos para diferentes usuários, que podem ou não ainda estar trabalhando na Contoso. Essa prática não padronizada impossibilita que os administradores de aplicativos ou da rede façam uma auditoria para saber quem ou o quê está usando recursos da rede ou acessando dados de aplicativos. Alguns supervisores até mesmo admitiram ter fornecido a subordinados informações sobre suas próprias contas e senhas, permitindo que a equipe tivesse acesso a recursos e dados com níveis de direitos elevados.

Desconfiguração de contas

A vulnerabilidade da desconfiguração de contas é uma preocupação muito mais séria. Ex-funcionários ou hackers externos podem usar contas antigas deixadas em diretórios ou armazenamentos de identidades de aplicativos para obter acesso não autorizado a dados confidenciais e valiosos ou danificá-los.

O principal risco associado à vulnerabilidade da desconfiguração de contas são as contas obsoletas. Uma auditoria recente realizada em um armazenamento de identidades baseado em aplicativos revelou que ainda havia contas ativas de funcionários que deixaram a empresa há mais de três anos. As contas obsoletas funcionam como uma porta dos fundos, pela qual um antigo usuário ou um invasor podem entrar para atacar dados de aplicativos.

Embora a vulnerabilidade dos antigos proprietários das contas seja óbvia, também é importante considerar que a senha da conta com três anos não foi alterada durante esse período. As contas obsoletas aumentam as oportunidades de os invasores empreenderem ataques de força bruta bem-sucedidos contra essas senhas estáticas, principalmente se não houver uma diretiva que imponha alterações de senhas e bloqueios de contas. Essas contas poderão então ser usadas para comprometer ou corromper dados de aplicativos que são essenciais para os processos comerciais da Contoso.

Contas de estações de trabalho UNIX

A Contoso possui 40 estações de trabalho com o Sun Solaris 9 que a equipe do departamento de contabilidade usa para realizar suas atividades diárias. As estações de trabalho Solaris são administradas por um único domínio NIS (Serviço de Informação de Rede).

A Sun Microsystems desenvolveu o NIS para centralizar a administração de sistemas UNIX. A funcionalidade geral do NIS é análoga aos domínios do Windows NT 4.0. O NIS é muito popular porque pode ser facilmente administrado e configurado por um administrador de UNIX experiente, pode ser razoavelmente bem dimensionado e possui suporte em quase todas as formas de UNIX. Infelizmente, o NIS não possui boas características de segurança.

Uma das maiores preocupações de segurança relacionadas ao NIS é que ele não oferece a capacidade de impor uma validade para as senhas ou a criação de senhas mais complexas. Além disso, todos os servidores membro de um domínio do NIS recebem uma cópia do arquivo de senhas que contém as senhas criptografadas de todos os usuários do domínio.

Senhas do UNIX antigas ou fracas são uma ameaça à segurança da rede porque permitem que um invasor rapidamente obtenha uma combinação de conta de usuário e senha. Quando comprometidas, as contas de usuário podem ser utilizadas para empreender um ataque a sistemas que podem estar protegidos somente contra ataques anônimos. Ferramentas que promovem ataques de força bruta e de dicionário contra arquivos de senhas são encontradas facilmente na Internet. As contas de usuário do UNIX na Contoso não estão sujeitas à imposição de diretivas de senhas, e o arquivo de diretivas de senhas do NIS é amplamente distribuído.

Autenticação do SAP

O SAP é um servidor de aplicativos ERP bastante conhecido e largamente implantado, e a Contoso implementou vários desses aplicativos. Diversos deles fornecem funções comerciais críticas e distribuem dados confidenciais para os usuários. Portanto, esses dados são fundamentais para os negócios da empresa. Interrupções na disponibilidade de aplicativos e os danos, a perda ou a exposição de dados poderiam custar milhões de dólares à Contoso.

Os mecanismos de autenticação herdados e os protocolos de acesso a dados fornecidos pelo SAP não protegem segredos de autenticação (senhas) quando eles são usados para acessar o aplicativo. As senhas de usuário do SAP podem ser interceptadas por qualquer pessoa que tenha um canal de entrada na rede no segmento de rede de um usuário.

Proteção de dados de aplicativos do SAP

Por padrão, os dados de aplicativos do SAP de cliente/servidor são enviados pela rede sem uma proteção. Qualquer invasor que consiga ver o tráfego de rede no segmento de rede do usuário do SAP pode comprometer dados de aplicativos do SAP roubando-os ou introduzindo dados incorretos, o que pode resultar em conseqüências graves para a consistência dos dados mantidos no sistema SAP.

Os dados trocados entre os usuários e o servidor de aplicativos do SAP são fundamentais para os negócios da empresa. Novamente, neste caso, interrupções na disponibilidade de aplicativos e os danos, a perda ou a exposição de dados poderiam custar milhões de dólares à Contoso.

Contas de funcionários

A vulnerabilidade das contas de funcionários envolve dois riscos principais: a autenticação usando senhas de texto não criptografado e o armazenamento dessas senhas em servidores não protegidos. Essas vulnerabilidades aplicam-se às redes internas e externas.

Quando os funcionários do departamento de vendas da Contoso são autenticados no aplicativo externo Sales and Contacts, eles muitas vezes usam suas credenciais de conta corporativa. Isso pode expor essas credenciais a ameaças externas (pelo comprometimento do servidor Web localizado na rede de perímetro) ou a administradores de aplicativos que não podem ser considerados confiáveis com essas informações.

Autenticação com senhas de texto não criptografado

Uma análise do uso de senhas no cenário da Contoso revelou que os funcionários do departamento de vendas da empresa usavam suas senhas de contas corporativas para acessar um aplicativo da Web hospedado em servidores da rede de perímetro. O aplicativo de vendas usa a autenticação Básica sobre SSL para conceder acesso ao aplicativo. Embora o SSL faça um bom trabalho de proteção da senha do usuário na rede, a senha de texto não criptografado está presente no servidor de aplicativos da Web. Se o servidor de aplicativos da Web fosse comprometido, as senhas de usuário de texto não criptografado poderiam ser acessadas.

Além disso, não havia uma diretiva oficial da empresa ou do departamento especificando se a senha usada para o aplicativo deveria ou não ser igual à senha da conta corporativa do usuário; por essa razão, muitos funcionários utilizam a mesma senha, porque é difícil ter que memorizar outra.

Com senhas de contas válidas, um invasor pode obter acesso não autorizado a arquivos e serviços que, de outra forma, não poderiam ser acessados. Se a senha da conta de extranet do usuário for igual à de sua conta corporativa, o invasor conseguirá obter uma quantidade ainda maior de informações.

Armazenamento de senhas de texto não criptografado em servidores não protegidos

Para autenticar usuários, o aplicativo Sales and Contact compara a senha de texto não criptografado adquirida via autenticação Básica com um valor de senha de um banco de dados Microsoft SQL Server localizado na rede de perímetro. Com senhas de contas válidas, um invasor pode obter acesso não autorizado a arquivos e serviços que, de outra forma, não poderiam ser acessados.

Os computadores que executam o SQL Server estão protegidos contra o acesso direto via Internet pela diretiva IPSec e pelo design da rede física. Um ataque externo a um SQL Server teria de ser um ataque em várias camadas, feito através dos servidores Web externos. No entanto, como não existe uma diretiva ou tecnologia em vigor para impedir que os administradores de aplicativos acessem senhas de funcionários, é muito mais fácil promover um ataque interno, pois basta que um administrador de aplicativos extraia as informações desejadas à medida que o aplicativo é executado.

Contas de parceiros

A Contoso possui um aplicativo para seus parceiros de pesquisa que usa a autenticação baseada em senhas. O aplicativo possui um armazenamento de identidades local de nomes de usuário e senhas que é mantido em um banco de dados hospedado em outro computador, separado dos servidores Web que hospedam o aplicativo. Esse esquema apresenta uma série de problemas de capacidade de gerenciamento de identidades, bem como vulnerabilidades de segurança.

A principal delas é a vulnerabilidade de segurança do banco de dados de contas. O banco de dados de contas armazena em um único local as senhas de texto não criptografado de todas as contas que utilizam o aplicativo. Se usuários não autorizados obtiverem acesso ao banco de dados, poderão comprometer todas as contas. Além disso, durante a autenticação, cada servidor Web faz uma solicitação não autenticada ao banco de dados para extrair a senha do usuário e compará-la com a credencial apresentada pelo usuário. Esse processo significa que a senha de texto não criptografado fica visível na rede de perímetro física, o que constitui um risco considerável.

Contas de clientes

A Contoso também possui um aplicativo para seus clientes que usa a autenticação baseada em senhas. As considerações e os riscos dessa vulnerabilidade são idênticos aos das vulnerabilidades das contas de parceiros.

Medidas defensivas de segurança

Tendo um bom conhecimento das vulnerabilidades da sua organização, você pode selecionar medidas defensivas para resolvê-las. Escolher as medidas defensivas de segurança apropriadas depende das vulnerabilidades que precisam ser resolvidas e também do nível de gravidade e da probabilidade de cada uma delas ser explorada.

A escolha das medidas defensivas corretas é particularmente importante, pois cada uma delas pode resolver diversas vulnerabilidades. Além disso, a implementação de uma medida defensiva pode ter resultados benéficos na resolução de outras vulnerabilidades menores que não faziam parte da avaliação inicial de ameaças. Essas medidas determinam os requisitos para a seleção de uma plataforma e como ela será usada.

Os requisitos de segurança do plano de ação da Contoso Pharmaceuticals incluem o uso dos seguintes recursos:

  • Configuração e desconfiguração automáticas de contas de usuário.

  • O protocolo de autenticação Kerberos versão 5.

  • Integração da GSS - API com o protocolo Kerberos.

  • Autenticação de certificados de cliente com criptografia.

  • Autenticação de senhas no Active Directory.

  • Autenticação do Microsoft Passport no Active Directory.

Ao final de cada seção das medidas defensivas, há uma lista que detalha as vulnerabilidades tratadas por elas.

A Contoso também executou ações que vão além da implementação dessas medidas defensivas de gerenciamento de acesso e identidades, incluindo:

  • Implementação de defesas extensivas contra ameaças de vírus, como listas de bloqueio e filtragem de anexos, bem como scanners de vírus de servidores e estações de trabalho.

  • Procedimentos operacionais aprimorados e diretivas de treinamento desenvolvidas para diminuir a ameaça de uso indevido acidental do sistema.

  • Aprimoramentos no design de serviços e da rede física para reduzir as ameaças mecânicas, como falta de energia, falhas de hardware e problemas de funcionamento da rede.

  • Planos de contingência bem-definidos em caso de desastres naturais, como incêndios, inundações e terremotos.

Configuração e desconfiguração automáticas

A configuração e a desconfiguração automáticas de contas não só trazem ganhos de produtividade significativos, como também podem fechar diversas brechas de segurança. A mais importante delas é quando um funcionário deixa a empresa, e a organização não desativa sua conta.

A configuração de contas pode ser automatizada graças a uma fonte oficial que informa o status do funcionário e a um conjunto conhecido de armazenamentos de identidades de aplicativos que os administradores podem gerenciar de maneira centralizada. Por exemplo, você pode criar um script para um aplicativo de RH que gere diariamente uma tabela com o status dos funcionários. Em seguida, você pode usar um produto de integração de identidades para consolidar o status dos funcionários no aplicativo de RH com os estados das identidades digitais em armazenamentos como diretórios e aplicativos.

Considerações sobre a implantação

Os produtos de integração de identidades normalmente vêm com uma série de conectores, ou agentes de gerenciamento, que funcionam como um canal de comunicação para a sincronização das informações de identidades. Você também precisa de uma ou mais fontes oficiais de identidades digitais. Geralmente, as fontes podem ser um único sistema de RH (ou um conjunto deles), bancos de dados de prestadores de serviços e outros, mas o cenário de cada organização será um pouco diferente.

O cenário da Contoso

A Contoso identificou o aplicativo de RH como a fonte oficial de informações sobre o status das identidades. A empresa optou por implantar um produto de configuração e integração de identidades para gerenciar os dados de identidades em diferentes armazenamentos, como o Active Directory, o Lotus Notes Release 6.5.4 e o Sun ONE Directory Server 5.1.

Quando o aplicativo de RH indicar a necessidade de configurar uma conta para um novo funcionário, o sistema adicionará ou ativará a conta correspondente nos outros sistemas. Quando o aplicativo de RH reportar o status de um funcionário como desligado, o sistema removerá ou desativará a conta correspondente nos outros sistemas.

Problemas de segurança resolvidos

A implementação de um produto de integração de identidades pode resolver os problemas de segurança relacionados à configuração e à desconfiguração de contas.

O documento "Agregação e sincronização de identidades" desta série ensina a implementar o Microsoft Identity Integration Server 2003 Enterprise Edition com Service Pack 1 (MIIS 2003 com SP1), um produto de integração de identidades que permite configurar e desconfigurar contas de funcionários automaticamente.

Usando o protocolo de autenticação Kerberos versão 5

O protocolo de autenticação Kerberos versão 5, introduzido para plataformas Microsoft no Microsoft Windows 2000, oferece muitas características de segurança desejadas em um protocolo de autenticação de rede. Ele é altamente seguro, pois utiliza o que há de mais inovador em termos de tecnologias criptográficas e designs de protocolo. O protocolo Kerberos também oferece melhor desempenho, uma vez que seu design se beneficia de um recurso de autenticação central, o KDC (Centro de distribuição de chaves), ao mesmo tempo em que reduz a carga sobre o KDC pelo uso de tíquetes relativamente duradouros.

Considerações sobre a implantação

No cenário da Contoso, o KDC fica em todos os controladores de domínio que executam o Windows Server 2003 Directory and Security Services. A interoperabilidade do Kerberos traz a vantagem adicional de uma experiência de SSO (logon único) em sistemas operacionais baseados no Windows e possivelmente até em clientes UNIX.

O cenário da Contoso

Os administradores da Contoso pretendem configurar as estações de trabalho UNIX para usar a versão 5 do protocolo Kerberos para a autenticação em controladores de domínio do Active Directory. Eles também planejam configurar o SAP R/3 para exigir a autenticação SNC (Secure Network Communications) em conjunto com o protocolo Kerberos versão 5.

Problemas de segurança resolvidos

A implementação do protocolo de autenticação Kerberos versão 5 ajuda a resolver problemas de segurança nas seguintes áreas:

  • Contas de estações de trabalho UNIX.

  • Autenticação do SAP.

  • Proteção de dados de aplicativos do SAP.

O documento "Gerenciamento de acesso à intranet" desta série descreve como implementar o protocolo Kerberos versão 5, inclusive como configurar a autenticação SNC no SAP R/3 e as estações de trabalho UNIX para autenticação usando o Kerberos e o Active Directory.

Usando a integração da GSS-API e do Kerberos com o SAP

O SAP R/3 versão 4.0 oferece suporte para SNC. Um modo de SNC permite a integração com a GSS-API, e através da GSS-API você pode usar o protocolo Kerberos versão 5.

Um modo de SNC permite a integração com a GSS-API, conforme descrito na norma IETF RFC-2078. A GSS-API oferece confidencialidade e integridade de dados quando usada com um protocolo de segurança que também oferece suporte a esses recursos. Esse protocolo é o Kerberos versão 5. A configuração do SAP Application Server e do cliente da GUI (interface gráfica do usuário) do SAP para usar o SAP SNC e o protocolo Kerberos versão 5 é uma medida que protegerá totalmente os dados de aplicativos do SAP contra interceptação.

Considerações sobre a implantação

O SAP R/3 não implementa o KDC, mas utiliza o KDC já instalado no ambiente de rede. No cenário da Contoso, o KDC fica em todos os controladores de domínio que executam o Windows 2000 Server ou o Windows Server 2003 com o Active Directory. É necessário configurar o SAP para usar o protocolo de autenticação Kerberos versão 5. No entanto, depois que é feita essa configuração, a interoperabilidade do Kerberos possui a vantagem adicional de oferecer a base para o SSO em sistemas operacionais de clientes baseados no Windows e UNIX.

O cenário da Contoso

No cenário da Contoso, os administradores configuraram o SAP R/3 para usar a autenticação SNC e implementaram a GSS – API com o protocolo Kerberos versão 5 para que as estações de trabalho cliente baseadas no Windows protejam totalmente os dados de aplicativos.

Problemas de segurança resolvidos

A implementação da GSS-API e do protocolo Kerberos versão 5 ajuda a resolver problemas de segurança nas seguintes áreas:

  • Autenticação do SAP.

  • Proteção de dados de aplicativos do SAP.

O documento "Gerenciamento de acesso à intranet" desta série descreve como configurar o cliente SAP R/3 para usar o SNC para a integração com a GSS-API e o protocolo Kerberos.

Usando a autenticação de certificados de cliente com criptografia

O protocolo TLS é a versão padrão da IETF (Internet Engineering Task Force) do SSL desenvolvido pela Netscape Communications, e está descrito na norma IETF RFC – 2246. O TLS executa a autenticação de clientes baseada em chaves públicas usando um certificado digital. Esse recurso é muito eficaz porque, se você tiver configurado uma relação de confiança de PKI (infra-estrutura de chave pública), poderá usar um certificado digital X.509 e a chave particular correspondente, em vez de senhas relativamente fracas, para a autenticação.

Para habilitar essa solução, crie uma conta de sombra que represente o usuário no Active Directory externo hospedado nos computadores da rede de perímetro. Como essa conta nunca usa sua própria senha para autenticação, é possível definir uma senha muito forte, que empregue, por exemplo, um valor aleatório de 24 caracteres gerado por criptografia.

Considerações sobre a implantação

Como a conta externa só pode ser acessada por meio de um certificado X.509 válido, é possível que os funcionários não consigam acessar um aplicativo comercial importante caso não tenham acesso ao certificado digital X.509 e à chave particular correspondente. Nesse caso, a organização deve considerar se o acesso temporário ao aplicativo de extranet pode ser concedido redefinindo a senha da conta — e informando essa senha ao funcionário — ou criando um mecanismo para emitir novos certificados pela extranet, ou ainda estabelecendo uma conexão VPN (rede virtual privada) com a rede interna.

Como os certificados de cliente tornaram desnecessário o uso de senhas, eles devem ser mantidos protegidos com o uso de diretivas de segurança de estações de trabalho.

O cenário da Contoso

Os arquitetos da Contoso configuraram o aplicativo Sales and Contact para exigir a autenticação de certificados de cliente e TLS. Isso envolveu a configuração de uma CA (autoridade de certificação) e a atribuição de certificados à equipe do departamento de vendas.

Problemas de segurança resolvidos

A implementação da autenticação de certificados de cliente com criptografia ajuda a resolver problemas de segurança nas seguintes áreas:

  • Autenticação com senhas de texto não criptografado.

  • Armazenamento de senhas de texto não criptografado em servidores não protegidos.

O documento "Gerenciamento de acesso à extranet" desta série ensina a configurar a autenticação de certificados de cliente com criptografia.

Autenticação de senhas no Active Directory

O Active Directory foi projetado para armazenar informações altamente confidenciais, como senhas de contas, de maneira segura. Na maioria dos casos, as senhas não são realmente armazenadas de forma que seja possível determinar a senha original. O Active Directory utiliza hashes criptográficos (criptografia unidirecional) da senha, o que é suficiente para oferecer a autenticação usando os protocolos fornecidos pelo Windows Server 2003. Os próprios hashes criptográficos são protegidos com chaves de criptografia, que só podem ser acessadas pelo sistema operacional, o que dificulta ainda mais o comprometimento de senhas altamente confidenciais.

O Active Directory também disponibiliza os mecanismos para executar a autenticação baseada em senhas com segurança. Ou seja, não é necessário enviar informações sobre senhas de texto não criptografado pela rede entre o servidor de aplicativos e o armazenamento de identidades. Um exemplo de mecanismo de autenticação seguro seria o LDAP sobre SSL ou TLS (LDAPS) de ligação segura.

Considerações sobre a implantação

O uso de outro armazenamento de contas para a autenticação geralmente requer uma alteração no código do aplicativo. Os aplicativos que usam uma tabela de banco de dados para a autenticação precisam ser atualizados para usar o Active Directory.

O cenário da Contoso

A Contoso atualizou o aplicativo Partner Research para que os parceiros usem o Active Directory como armazenamento de identidades para as contas de parceiros e o mecanismo para o gerenciamento de acesso.

Problemas de segurança resolvidos

A implementação da autenticação de senhas no Active Directory ajuda a resolver problemas de segurança nas seguintes áreas:

  • Autenticação com senhas de texto não criptografado.

  • Armazenamento de senhas de texto não criptografado em servidores não protegidos.

O documento "Desenvolvendo aplicativos ASP.NET com reconhecimento de identidades" desta série descreve como os aplicativos podem executar a autenticação e a autorização usando o Active Directory.

Autenticação do Microsoft Passport no Active Directory

Um estudo isolado sobre usabilidade indicou aos arquitetos da Contoso que os clientes são desafiados ao tentar gerenciar nomes de usuário e senhas de diferentes sites. A pesquisa indicou que um agente de identidades como o Microsoft Passport poderia fornecer autenticação para os clientes que visitam o site da Contoso sem exigir que eles mantenham uma identidade adicional.

Essa abordagem também atendeu aos requisitos de segurança do aplicativo de comentários Customer Trial da Contoso porque foi possível eliminar completamente as senhas das contas de clientes. A validação de uma credencial do Passport e o mapeamento da PUID para uma conta no Active Directory externo autentica os usuários no site da Contoso.

Considerações sobre a implantação

O uso de um serviço como o Microsoft Passport para a autenticação geralmente requer uma alteração no código do aplicativo. Além disso, para dar suporte a uma autorização específica, você deve configurar (por meios automatizados) inúmeras contas mapeadas do Passport no Active Directory usando um mecanismo escalonável e gerenciável.

O cenário da Contoso

A Contoso reescreveu seu aplicativo para que os clientes usem o Microsoft Passport e o Active Directory como mecanismo de autenticação e o armazenamento de identidades para as contas de clientes.

Problemas de segurança resolvidos

A implementação da autenticação do Microsoft Passport no Active Directory resolve os seguintes problemas:

  • Autenticação com senhas de texto não criptografado.

  • Armazenamento de senhas de texto não criptografado em servidores não protegidos.

O documento "Gerenciamento de acesso à extranet" desta série ensina a configurar a autenticação do Microsoft Passport no Active Directory.

Requisitos de plataforma

Os resultados da análise de requisitos comerciais e de segurança da Contoso determinaram os requisitos que a plataforma de gerenciamento de acesso e identidades deve atender na empresa. As principais áreas que a plataforma deve considerar estão descritas nas seções a seguir.

Gerenciamento de acesso

Os serviços de gerenciamento de acesso da plataforma escolhida devem fornecer serviços de autenticação, autorização e confiança que atendam aos seguintes requisitos:

  • Os sistemas operacionais de cliente e servidor para aplicativos de cliente/servidor e os serviços de arquivos e impressão devem interoperar a fim de executar a autenticação transparente e proporcionar uma experiência de logon único aos usuários.

  • Os direitos globais de autorização devem ser derivados de informações de identidades globais, embora essas informações possam ser globais somente em escopos específicos, como a intranet ou a rede de perímetro.

  • A infra-estrutura deve implementar mecanismos de autorização robustos e gerenciáveis.

  • A plataforma deve oferecer mecanismos de confiança flexíveis, dentro e fora da organização. Essas relações de confiança podem ser explícitas, por meio de uma configuração de PKI, ou implícitas, por meio de mecanismos do sistema operacional.

  • A infra-estrutura deve implementar mecanismos de configuração de confiança gerenciáveis e seguros a fim de integrar vários armazenamentos de identidades para futuras aquisições.

Serviços de diretório e segurança

Os serviços de diretório e segurança da plataforma escolhida devem dar suporte ao seguinte:

  • Armazenamento seguro de credenciais de identidades, capaz de interoperar com mecanismos de autenticação seguros e baseados em padrões.

  • LDAP, para interoperar com determinados aplicativos e serviços.

  • Criptografia forte de credenciais de usuários e serviços que não devem distribuir informações sobre credenciais (ainda que de forma criptografada) fora dos serviços.

  • Diferentes tipos de credenciais, para atender aos requisitos de inúmeros protocolos de autenticação, como Kerberos versão 5, biometria, SSL e TLS.

  • Mecanismos de autenticação de dois fatores, incluindo PKI e cartões inteligentes (para futura implantação).

  • Interoperabilidade transparente entre sistemas operacionais de cliente/servidor por meio de um conjunto conhecido de protocolos de aplicativos e de segurança.

Gerenciamento do ciclo de vida de identidades

Os serviços de gerenciamento do ciclo de vida de identidades da plataforma escolhida devem atender aos seguintes requisitos:

  • A infra-estrutura de gerenciamento de acesso e identidades deve utilizar um conjunto comum de protocolos baseados em padrões para gerenciar os armazenamentos de identidades da empresa.

  • Um único diretório deve ser capaz de agir como o armazenamento central de identidades da intranet. Ele deve oferecer serviços redundantes se houver falhas de hardware ou da rede.

  • Um diretório de extranet isolado na rede de perímetro armazenará as contas de usuário de clientes e parceiros.

Plataforma de aplicativos

A plataforma escolhida deve atender aos seguintes requisitos de aplicativos da Contoso:

  • Os aplicativos existentes e planejados devem usar a infra-estrutura para identidades digitais, que devem poder ser acessadas através de protocolos comuns baseados em padrões.

  • Os servidores de aplicativos devem ter suporte interno para protocolos de autenticação fortes, como o Kerberos versão 5, e suporte para a autenticação de certificados de cliente via SSL e TLS.

  • Os servidores de aplicativos devem poder implementar a autorização tradicional via ACL (lista de controle de acesso) e controle de acesso baseado em função.

Auditoria de segurança

A plataforma escolhida deve atender aos requisitos de auditoria de segurança da Contoso:

  • A plataforma deve oferecer recursos de auditoria detalhada para operações de autenticação, confiança, autorização e configuração.

  • A plataforma deve expor serviços gerenciáveis, porém específicos de auditoria para todos os aspectos da infra-estrutura de servidor e de aplicativos.

Neste artigo

Download

Obtenha a Série de gerenciamento de acesso e identidades da Microsoft

Notificações de atualização

Inscreva-se para receber informações sobre atualizações e novas versões

Comentários

Envie seus comentários ou suas sugestões

 Dd459052.pageLeft(pt-br,TechNet.10).gif 3 de 9 Dd459052.pageRight(pt-br,TechNet.10).gif