Guia de segurança do Exchange 2010

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2016-11-28

Este guia foi escrito para o administrador de TI responsável por proteger a implantação do MicrosoftExchange Server 2010 e foi projetado para ajudá-lo a compreender e gerenciar o ambiente de segurança geral no qual o Exchange está instalado.

Antigamente, para cada versão do Microsoft Exchange, a equipe do Exchange publicava guias de segurança independentes com informações sobre segurança e permissões. Essa abordagem funcionava para bloquear serviços e diretórios depois da execução da Instalação do Exchange 2010. No entanto, desde o MicrosoftExchange Server 2007, a Instalação do Exchange só permite os serviços exigidos pela função de servidor instalada. O Microsoft Exchange deixou de ser instalado e teve a segurança reforçada. Ele foi projetado para ajudar você a estar mais protegido por padrão.

Portanto, diferentemente de versões anteriores do Microsoft Exchange, nas quais os administradores de TI tinham que executar vários procedimentos para bloquear seus servidores que executavam o Microsoft Exchange, o Exchange 2010 não precisa de bloqueio o reforço de segurança.

Escopo

O Exchange 2010 foi desenvolvido usando-se os princípios do Microsoft Ciclo de Vida do Desenvolvimento de Segurança (SDL). Uma revisão de segurança foi realizada para cada recurso e componente. Configurações padrão escolhidas com cuidado garantem uma implantação mais segura. O escopo deste guia é informar administradores sobre recursos relacionados à segurança e recursos que podem afetar considerações de segurança. Este guia está relacionado a tópicos referentes à segurança na documentação do Exchange 2010. Estes tópicos estão listados no Apêndice 1: Documentação adicional relacionada à segurança. Esse guia não aborda nenhuma etapa para reforçar o sistema operacional Windows Server.

Conteúdo

O que é há de novo

O Ciclo de Vida do Desenvolvimento de Segurança do Exchange 2010

Proteção – Práticas recomendadas

Mantendo a segurança – Práticas recomendadas

Uso da porta de rede e proteção de firewall

Parâmetros de limitação e políticas de limitação do cliente

Controle de Acesso Baseado em Função

Active Directory

Contas do Exchange Server

Sistema de arquivos

Services

Certificados

Considerações de NTLM

Autenticação de Fator Duplo

Federação

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Considerações da função de servidor

Apêndice 1: Documentação adicional relacionada à segurança

O que é há de novo

O Exchange 2010 inclui os seguintes recursos de segurança novos:

  • Controle de Acesso Baseado na Função   O Exchange 2010 inclui um novo controle de acesso baseado na função que permite à organização gerenciar de maneira granular as permissões atribuídas a participantes diferentes, como administradores de destinatário, administradores de servidor, registros e gerentes de descoberta e administradores de organização.

  • Políticas de Limitação   O Exchange 2010 apresenta mecanismos de limitação em servidores de Caixa de Correio, de Acesso do Cliente e de Transporte para proteger a organização contra ataques de negação de serviço e reduzir o impacto desses ataques.

  • Delegação Federada   O Exchange 2010 apresenta novos recursos de delegação federada que possibilitam permitir aos usuários colaborar com usuários de maneira segura em organizações externas. Usando a delegação federada, os usuários podem compartilhar calendários e contatos com usuários em organizações federadas externas. A colaboração entre florestas também é possível, sem a necessidade de configurar e gerenciar relações de confiança do Active Directory.

  • Gerenciamento de Direitos de Informação   O Exchange 2010 inclui novos recursos de proteção e controle de informações que permitem proteger conteúdo de mensagem confidencial em vários níveis enquanto mantêm a possibilidade da organização de descriptografar, pesquisar e aplicar políticas do sistema de mensagens a conteúdo protegido.

  • Sem Assistente de Configuração de Segurança   No Exchange 2010, a Instalação torna as alterações feitas na configuração necessárias à instalação e só permite os serviços obrigatórios para uma determinada função de servidor do Exchange, além de limitar a comunicação apenas às portas necessárias aos serviços e aos processos em execução em cada função de servidor. Isso remove a necessidade de ferramentas como o Assistente de Configuração de Segurança (ACS) de definirem essas configurações.

O Ciclo de Vida do Desenvolvimento de Segurança do Exchange 2010

No começo de 2002, a Microsoft apresentou a iniciativa Trustworthy Computing (Computação Confiável). Desde então, o processo de desenvolvimento na Microsoft e na equipe do Microsoft Exchange se concentrou em desenvolver softwares que ajudassem você a ter mais segurança. Para obter mais informações, consulte Trustworthy Computing (em inglês).

No Exchange 2010, o Trustworthy Computing foi implementado nas áreas fundamentais a seguir:

  • Design seguro   O Exchange 2010 foi projetado e desenvolvido de acordo com O ciclo de vida do desenvolvimento de segurança de Trustworthy Computing (em inglês). A primeira etapa na criação de um sistema de mensagens mais seguro foi projetar modelos de ameaças e testar todos os recursos conforme eram desenvolvidos. Vários aprimoramentos relacionados à segurança foram incorporados às práticas e processos de codificação. As ferramentas do tempo de compilação detectam estouros de buffer e outras ameaças à segurança em potencial. Nenhum sistema pode garantir a segurança completa. No entanto, com a inclusão de princípios de design seguros no projeto geral de desenvolvimento, o Exchange 2010 é mais seguro do que as versões anteriores.

  • Seguro por padrão   Um objetivo do Exchange 2010 era desenvolver um sistema no qual a maior parte das comunicações de rede fossem criptografadas por padrão. Com exceção de comunicações SMB (bloco de mensagens do servidor) e de algumas comunicações da UM (Unificação de Mensagens), o objetivo foi alcançado. Usando certificados auto-assinados, o protocolo Kerberos, SSL e outras técnicas de criptografia padronizadas, quase todos os dados do Exchange 2010 são protegidos na rede. Além disso, a instalação com base em funções possibilita a instalação do Exchange 2010 de modo que apenas os serviços e as permissões relacionadas a estes sejam instaladas com uma função de servidor específica e adequada. Em versões anteriores do Microsoft Exchange, todos os serviços para todas as funcionalidades tinham que ser instalados. 

  • Funcionalidade anti-spam e antivírus   O Exchange 2010 inclui um pacote de aplicativos de agentes antispam executados na rede de perímetro na função de servidor Transporte de Borda e que também podem ser instalados na função de servidor Transporte de Hub residente na rede interna. A funcionalidade antivírus foi aprimorada com a adição do MicrosoftForefront Protection 2010 para Exchange Server como uma solução da Microsoft.

  • Seguro na implantação   Durante o desenvolvimento do Exchange 2010, a versão pré-lançamento foi implantada no ambiente de produção de TI da Microsoft. Com base nos dados dessa implantação, o MicrosoftExchange Server Best Practices Analyzer foi atualizado para analisar configurações de segurança reais, e foram documentadas práticas recomendadas pré e pós-implantação na Ajuda do Exchange 2010.

    Antes, o gerenciamento de permissões era documentado e entregue depois que a documentação principal era concluída. No entanto, sabemos que o gerenciamento de permissões não é um processo suplementar. Ele deve ser incorporado no planejamento e na implantação geral da sua instalação do Exchange 2010. Por isso, simplificamos nossa documentação de permissão e a integramos à documentação básica para fornecer contexto remoto a administradores enquanto eles se planejam para e implantam o modelo administrativo. O Exchange 2010 inclui um novo modelo de permissões baseadas na função que permite conceder permissões granulares a administradores e usuários para permitir que eles realizem tarefas com o mínimo de permissões exigidas.

  • Comunicações   Agora que o Exchange 2010 foi lançado, a equipe do Exchange se dedica a manter o software atualizado e você bem informado. Mantendo o sistema atualizado com o Microsoft Update, você pode garantir que as atualizações de segurança mais recentes sejam instaladas em sua organização. O Exchange 2010 também inclui atualizações anti-spam. Além disso, ao assinar Notificações Técnicas de Segurança da Microsoft, você pode acompanhar os últimos problemas de segurança no Exchange 2010.

Proteção – Práticas recomendadas

Algumas práticas recomendadas básicas ajudarão a criar e a manter um ambiente mais seguro. Normalmente, a execução periódica de ferramentas de análise e a manutenção de software e de arquivos antivírus atualizados são as formas mais eficientes de otimizar o ambiente do Exchange 2010 em termos de segurança.

Recomendações de configuração e instalação

Estas práticas recomendadas ajudarão a criar um ambiente do Exchange 2010 mais seguro:

  • Instalação Delegada   O primeiro servidor do Exchange 2010 instalado na organização exige que a conta usada na execução da Instalação deva ser membro do grupo Administradores de Empresas. A conta usada é adicionada ao grupo de funções Gerenciamento da Organização criado pela Instalação do Exchange 2010. É possível usar a instalação delegada para permitir que os administradores que não sejam membros do grupo de funções Gerenciamento da Organização configurem servidores subsequentes. Para mais detalhes, consulte Provisionar a instalação do representante e do servidor Exchange 2010.

  • Permissões do sistema de arquivos   A Instalação do Exchange 2010 atribui o mínimo de permissões obrigatórias no sistema de arquivos no qual os binários e os dados do Exchange são armazenados. Você não deve fazer nenhuma alteração nas listas de controle de acesso (ACLs) nas pastas raiz e na pasta Arquivos de Programa no sistema de arquivos.

  • Caminhos de instalação   Recomendamos a instalação dos binários do Exchange 2010 em uma unidade de não sistema (um volume diferente de onde o sistema operacional está instalado). Os bancos de dados e os logs de transação do Exchange podem crescer rapidamente, devendo estar localizados em volumes de não sistema dimensionados para a capacidade e o desempenho. Muitos outros logs gerados por componentes do Exchange diferentes, como logs de transporte, também são armazenados no mesmo caminho de instalação dos binários do Exchange, podendo crescer de maneira significativa, dependendo da configuração e do ambiente do sistema de mensagens. No Exchange 2010, o tamanho máximo de muitos arquivos de log e o espaço de armazenamento máximo que uma pasta de arquivo de log podem ocupar são configuráveis, sendo definidos como um padrão de 250 Megabytes. Para evitar uma interrupção do sistema em potencial por conta de pouco espaço em disco, recomendamos avaliar os requisitos de registro em log para cada função de servidor e configurar as opções do registro em log, além dos locais de armazenamento de arquivo de log, de acordo com os requisitos.

  • Bloqueando clientes do Outlook herdados   Com base nos requisitos, é possível configurar o bloqueio do cliente Outlook para bloquear versões do cliente Outlook herdados. Determinados recursos do Exchange 2010, como Regras de Proteção e Arquivos Pessoais do Outlook, não oferecem suporte a clientes do Outlook herdados. Para obter mais informações sobre o bloqueio do cliente Outlook, consulte Configurar o bloqueio do cliente Outlook para o gerenciamento de registros de mensagens.

  • Desvinculando endereços SMTP de nomes de usuário   Por padrão, o Exchange gera endereços de email e aliases com base no nome do usuário da caixa de correio. Muitas organizações criam uma política de endereço de email adicional para desvincular endereços de email do usuário de nomes de usuário tendo em vista uma segurança ainda maior. Por exemplo, caso o nome de usuário Ben Smith seja bsmith e o domínio seja contoso.com, o endereço de email primário gerado pela política de endereço de email padrão é bsmith@contoso.com. É possível criar uma política de endereço de email adicional para gerar endereços de email que não usam o alias ou o nome de usuário. Por exemplo, a criação de uma política de endereço de email para usar o modelo %g.%s@domain gera endereços de email no formato Nome.Sobrenome@domínio. Para o usuário Ben Smith, a política gerará o endereço Ben.Smith@contoso.com. Ou será possível desvincular endereços de email de nomes de usuário especificando-se um alias diferente do nome de usuário quando você criar ou habilitar uma caixa de correio.

    Dica

    Se o endereço SMTP primário de um usuário não corresponder ao UPN da conta, o usuário não poderá utilizar o endereço de email para entrar no MicrosoftOfficeOutlook Web App e deverá fornecer um nome de usuário usando o formato DOMÍNIO\nome_de_usuário. Ao utilizar o MicrosoftOutlook, o usuário deve fornecer o nome de usuário no formato DOMÍNIO\nome_de_usuário caso credenciais sejam solicitadas quando o Outlook se conectar ao serviço Descoberta Automática.

Microsoft Update

O Microsoft Update é um serviço que oferece os mesmos downloads que o MicrosoftWindows Update – mais as atualizações mais recentes para outros programas da Microsoft. Ele pode ajudar a manter o servidor mais seguro e com melhor desempenho.

Um recurso fundamental do Microsoft Update é a Atualização Automática do Windows. Esse recurso instala automaticamente as atualizações de alta prioridade fundamentais para a segurança e confiabilidade do computador. Sem essas atualizações de segurança, seu computador fica mais vulnerável a ataques de criminosos da Internet ou de softwares mal intencionados (malware).

O modo mais confiável de usar o Microsoft Update é receber as atualizações automaticamente no computador com a Atualização Automática do Windows. Você pode ligar as Atualizações Automáticas quando se inscrever no Microsoft Update.

O Windows então analisará o software Microsoft instalado em seu computador e verá se há atualizações de alta prioridade atuais ou antigas que sejam necessárias e em seguida fará o download e instalação automaticamente. Depois disso, quando você se conectar à Internet, o Windows repetirá o processo de atualização se houver novas atualizações de alta prioridade.

Para habilitar o Microsoft Update, consulte Microsoft Update (em inglês).

O modo padrão do Microsoft Update exige que todos os servidores do Exchange estejam conectados à Internet para receber atualizações automáticas. Se você estiver executando servidores sem conexão à Internet, poderá instalar o WSUS (Windows Server Update Services) para gerenciar a distribuição de atualizações para os computadores da organização. Você poderá então configurar o Microsoft Update nos computadores internos do Microsoft Exchange para que entre em contato com o servidor WSUS interno para fazer atualizações. Para obter mais informações, consulte Microsoft Windows Server Update Services 3.0 (em inglês). 

O WSUS não é a única solução disponível para gerenciamento do Microsoft Update. Para obter mais informações sobre as versões de segurança, os processos, as comunicações e as ferramentas da Microsoft, consulte Microsoft Security Update Guide.

Tarefas que Deixaram de ser Obrigatórias no Exchange 2010

Não é mais necessário instalar ou executar as seguintes ferramentas:

  • A ferramenta de segurança URLScan não é obrigatória para o IIS 7. Em versões anteriores do Microsoft Exchange, era uma prática comum instalar ferramentas do IIS, como URLScan para proteger uma instalação do IIS. O Exchange 2010 exige o Windows Server 2008, que inclui o IIS 7. Muitos dos recursos de segurança originalmente disponíveis na UrlScan agora estão disponíveis nos recursos de Filtragem de Solicitações do IIS 7.

  • Não é mais necessário instalar o Analisador de Práticas Recomendadas do Exchange. Em versões anteriores do Microsoft Exchange, era uma prática comum instalar e executar o Analisador de Práticas Recomendadas do Exchange antes da instalação e regularmente depois disso. A Instalação do Exchange 2010 inclui os componentes do Analisador de Práticas Recomendadas do Exchange e os executa durante a instalação. Não é necessário executar o Analisador de Práticas Recomendadas do Exchange antes da instalação.

  • Você não precisa mais usar o Assistente de Configuração de Segurança (ACS) ou os modelos do Exchange para ACS. A Instalação do Exchange 2010 só instala os serviços necessários a uma determinada função de servidor do Exchange e cria regras do Firewall do Windows Segurança Avançada para abrir apenas as portas necessárias aos serviços e aos processos para essa função de servidor. Não é mais necessário executar o Assistente de Configuração de Segurança (ACS) para isso. Diferentemente do Exchange Server 2007, o Exchange 2010 não está incluído nos modelos do ACS.

Mantendo a segurança – Práticas recomendadas

Essas práticas recomendadas ajudarão a manter o ambiente do Exchange 2010 protegido.

Mantendo o software atualizado

Como mencionado anteriormente, executar o Microsoft Update é uma prática recomendada. Além de executar o Microsoft Update em todos os servidores, também é muito importante manter todos os computadores clientes atualizados e manter atualizações antivírus em todos os computadores da organização.

Além dos softwares da Microsoft, verifique se você está executando as atualizações mais recentes de todos os softwares executados na organização.

Atualizações de antispam

O Exchange 2010 também usa a infra-estrutura do Microsoft Update para atualizar os filtros anti-spam. Por padrão, com atualizações manuais, o administrador deve visitar o Microsoft Update para baixar e instalar as atualizações de filtro de conteúdo. Os dados de atualização do filtro de conteúdo são atualizados e disponibilizados a cada duas semanas.

Atualizações manuais do Microsoft Update incluem o Serviço de Reputação de IP da Microsoft ou dados de assinatura de spam. O Serviço de Reputação de IP da Microsoft e dados de assinatura de spam estão disponíveis somente com o Forefront Security para atualizações automáticas anti-spam do Exchange Server.

Para obter mais informações sobre como habilitar as atualizações automáticas anti-spam do Forefront, consulte Noções Básicas Sobre Atualizações de Antispam.

Executando software antivírus

Vírus, worms e outros conteúdos mal intencionados transmitidos por sistemas de email são uma realidade destrutiva enfrentada por muitos administradores do Microsoft Exchange. Portanto, você precisa desenvolver uma implantação de antivírus defensiva para todos os sistemas de mensagens. Esta seção fornece práticas recomendadas para a implantação de software antivírus para o Exchange 2010.

Você deve dar atenção adicional a duas alterações importantes no Exchange 2010 quando você selecionar um fornecedor de software antivírus:

  • Desde o Exchange Server 2007, o Microsoft Exchange é baseado em uma arquitetura de 64 bits.

  • O Exchange 2010 inclui funcionalidade do agente de transporte.

Essas duas alterações significam que os fornecedores de antivírus devem fornecer softwares específicos do Exchange 2010. Qualquer software antivírus desenvolvido para versões anteriores do Exchange provavelmente não funcionará corretamente com o Exchange 2010.

Para usar abordagem de defesa em profundidade, recomendamos que você implante um software antivírus projetado para sistemas de mensagens no gateway do protocolo SMTP ou nos servidores Exchange que hospedam caixas de correio, além de softwares antivírus no computador do usuário.

Você decide quais tipos de software antivírus usar e onde o software é implantado determinando o equilíbrio apropriado entre o custo e o risco que está disposto a assumir. Por exemplo, algumas organizações executam software antivírus para mensagens no gateway SMTP, varredura antivírus no nível dos arquivos no servidor Exchange e software de cliente antivírus no computador do usuário. Essa abordagem fornece proteção específica do sistema de mensagens no cliente. Outras organizações podem tolerar custos mais altos e melhorar a segurança, executando softwares antivírus para mensagens no gateway SMTP, varredura antivírus no nível dos arquivos no servidor Exchange e software cliente antivírus no computador do usuário, juntamente com um software antivírus compatível com o VSAPI 2.5 (Virus Scanning Application Programming Interface) do Exchange no servidor de Caixa de Correio do Exchange.

Executando software antivírus em Servidores de Transporte de Hub e de Transporte de Borda

O software antivírus baseado no transporte é implementado como ou inclui agentes de transporte. Os agentes de transporte agem em eventos de transporte, semelhantes aos coletores de eventos em versões anteriores do Microsoft Exchange. Para mais detalhes, consulte Noções Básicas Sobre Agentes de Transporte.

Dica

Mensagens que não são roteadas por transporte, como itens em postas públicas, Itens enviados e itens de calendário, que só podem ser analisadas em um servidor de Caixa de Correio, não são protegidas por análise de vírus somente em transporte.

Os desenvolvedores de terceiros podem gravar agentes de transporte personalizados para tirar proveito do mecanismo subjacente de análise de MIME do para verificação robusta antivírus no nível de transporte. Para uma lista dos parceiros de antispam ou antivírus do Exchange, consulte Fornecedores de Software Independentes.

Além disso, o Forefront Protection for Exchange Server é um pacote de software antivírus altamente integrado com o Exchange 2010 e oferece proteção antivírus adicional para o seu ambiente do Exchange. Para obter mais informações, consulte Microsoft Forefront Protection 2010 para Exchange Server.

O local mais importante para executar o software antivírus de mensagens seja na primeira linha de defesa de sua organização. Este é o gateway SMTP por meio do qual as mensagens externas entram no ambiente do sistema de mensagens. No Exchange 2010, a primeira linha de defesa é o servidor Transporte de Borda.

Se usar um servidor SMTP ou gateway do Exchange para receber email de entrada antes do Exchange, você deverá implementar funcionalidade anti-spam e antivírus suficiente nos hosts SMTP do Exchange.

No Exchange 2010, todas as mensagens são roteadas por meio de um servidor Transporte de Hub. Isso inclui mensagens enviadas ou recebidas fora da organização do Exchange e mensagens enviadas dentro da organização do Exchange. Mensagens enviadas para uma caixa de correio localizada no mesmo servidor Caixa de Correio do remetente. Para se proteger bem contra epidemias de vírus de dentro da organização e para fornecer uma segunda linha de defesa, também recomendamos que você execute o software antivírus com base em transporte no servidor de Transporte de Hub.

Executando software antivírus em servidores Caixa de Correio

Além da verificação de vírus em servidores de transporte, uma solução de verificação API de Verificação de Vírus do MicrosoftExchange (VSAPI) em execução nos servidores Caixa de Correio pode ser uma camada importante de defesa em muitas organizações. Você deve considerar a possibilidade de usar uma solução antivírus VSAPI se alguma das seguintes condições for verdadeira:

  • Sua organização não possui produtos antivírus de área de trabalho completos e confiáveis implantados.

  • Sua organização deseja a proteção adicional que a verificação dos bancos de dados de caixa de correio pode oferecer.

  • Sua organização desenvolver aplicativos personalizados com acesso programático a um banco de dados do Exchange.

  • Sua comunidade de usuários costuma postar mensagens em pastas públicas.

Soluções antivírus que usam o VSAPI do Exchange são executadas diretamente do processo do repositório de informações do Exchange. As soluções VSAPI são provavelmente as únicas que podem proteger contra vetores de ataque que colocam conteúdo infectado dentro do repositório de informações do Exchange, ignorando a verificação de transporte e no cliente padrão. Por exemplo, VSAPI é a única solução que verifica dados enviados a um banco de dados por CDO (objetos de colaboração de dados), WebDAV e Serviços Web do Exchange (EWS). Além disso, quando ocorre uma epidemia de vírus, freqüentemente uma solução VSAPI fornece o modo mais rápido de remover e eliminar vírus de um banco de dados de email infectado.

Exchange Server e antivírus do sistema de arquivos

Se você implantar o software antivírus do sistema de arquivos para proteger os servidores do Exchange, considere o seguinte:

  • Você deve excluir diretórios de servidor do Exchange nos quais as caixas de correio e os bancos de dados de pastas públicas do Exchange estão armazenados dos verificadores de vírus. Para detalhes, consulte Verificação Antivírus no Nível de Arquivo no Exchange 2010.

  • Verificadores antivírus do sistema de arquivos só protegem arquivos. Para proteger mensagens de email, você também deve considerar a implementação do antivírus com suporte ao Exchange ou produtos de segurança do sistema de mensagens, como incluir o MicrosoftForefront ou produtos apropriados de terceiros ou de parceiros. Para obter detalhes sobre a proteção anti-spam e antivírus, consulte Noções Básicas Sobre a Funcionalidade Antispam e Antivírus. Para obter detalhes, consulte Forefront Protection 2010 for Exchange Server: Visão geral.

  • Você deve manter assinaturas de antivírus e anti-spam atualizadas para obter uma proteção efetiva.

  • Os relatórios de software ou serviços de antivírus e anti-spam devem ser revisados regularmente para assegurar que a proteção esteja habilitada e funcionando conforme desejado, detectar incidentes rapidamente e realizar qualquer ação necessária.

Usando o Exchange Hosted Services

A filtragem de spam e vírus é aprimorada por ou também está disponível como um serviço dos Serviços Hospedados pelo Microsoft Exchange. O Exchange Hosted Services representa um conjunto de quatro serviços hospedados distintos:

  • Filtragem Hospedada, que ajuda as organizações a se protegerem contra malware proveniente de email

  • Arquivo Hospedado, que ajuda organizações a atender aos requisitos de retenção e conformidade

  • Criptografia Hospedada, que ajuda as organizações a criptografar dados para preservar a confidencialidade

  • Continuidade Hospedada, que ajuda organizações a preservar o acesso ao email durante e após interrupções

Esses serviços se integram a todos os servidores do Exchange locais gerenciados internamente. Para mais informações, consulte Forefront Online Protection para Exchange.

Usando filtragem de anexos

No Exchange 2010, a filtragem de anexos permite aplicar filtros nos servidores Transporte de Borda para controlar os anexos que os usuários recebem. A filtragem de anexos é muito importante no ambiente atual, em que vários tipos de anexo contêm vírus perigosos ou materiais inadequados que podem causar danos significativos ao computador do usuário ou à organização como um todo, danificando documentações importantes ou liberando informações confidenciais ao público.

Você pode usar os seguintes tipos de filtragem de anexos para controlar anexos que entram ou saem da organização por meio de um servidor Transporte de Borda:

Filtragem baseada no nome do arquivo ou na extensão do nome do arquivo   Você pode filtrar anexos especificando o nome exato do arquivo ou a extensão do nome do arquivo a ser filtrado. Um exemplo de um nome de arquivo exato é BadFilename.exe. Um exemplo de um filtro de extensão de nome de arquivo é *.exe.

Filtragem baseada no tipo de conteúdo MIME do arquivo   Também é possível filtrar anexos especificando o tipo de conteúdo MIME a ser filtrado. Os tipos de conteúdo MIME indicam o que é o anexo, uma imagem JPEG, um arquivo executável, um arquivo do Microsoft Office Excel 2010 ou algum outro tipo de arquivo. Os tipos de conteúdo são expressados como tipo/subtipo. Por exemplo, o tipo de conteúdo de imagem JPEG é expressado como image/jpeg.

Se um anexo corresponder a um desses critérios de filtragem, você poderá configurar as seguintes ações a serem executadas no anexo:

  • Bloquear mensagem inteira e anexo

  • Remover anexo, mas permitir mensagem

  • Excluir mensagem e anexo de maneira silenciosa

Para mais detalhes, consulte Noções Básicas Sobre Filtragem de Anexos.

Dica

Não é possível usar o agente Filtro de Anexos para filtrar anexos com base no conteúdo. É possível usar regras de transporte para inspecionar a mensagem e o conteúdo do anexo, além de realizar ações, como excluir ou rejeitar a mensagem ou proteger a mensagem e os anexos do IRM. Para detalhes, consulte Noções Básicas Sobre Regras de Transporte.

Filtragem de Arquivos Usando o Forefront Protection para Exchange Server

A funcionalidade de filtragem de arquivos fornecida pelo Forefront Protection for Exchange Server inclui recursos avançados não disponíveis no agente Filtro de Anexos incluído no Exchange 2010.

Por exemplo, é possível verificar nos arquivos de contêiner, que são arquivos que contem outros arquivos, a presença de tipos de arquivo ofensivos. Forefront A filtragem do Exchange Protection para Server pode verificar os seguintes arquivos de contêiner e agir sobre os arquivos incorporados:

  • PKZip (.zip)

  • GNU Zip (.gzip)

  • Arquivo compactado de extração automática (.zip)

  • Arquivos compactados (.zip)

  • Arquivo Java (.jar)

  • TNEF (winmail.dat)

  • repositório estruturado (.doc, .xls, .ppt, etc.)

  • MIME (.eml0)

  • SMIME (.eml)

  • UUEncode (.uue)

  • Arquivo de fita Unix (.tar)

  • Arquivo RAR (.rar)

  • MACBinary (.bin)

Dica

O agente Filtro de Anexos incluído no Exchange 2010 detecta tipos de arquivo, mesmo que tenham sido renomeados. A Filtragem de Anexo também assegura que os arquivos Zip e LZH compactados não contenham anexos bloqueados, comparando uma extensão de nome de arquivo com os arquivos contidos no Zip ou no LZH compactado. A filtragem de arquivos do Forefront Protection for Exchange Server tem o recurso adicional de determinar se um anexo bloqueado foi renomeado dentro de um arquivo de contêiner.

Também é possível filtrar arquivos pelo tamanho. Além disso, é possível configurar o Forefront Protection for Exchange para colocar os arquivos filtrados em quarentena ou para enviar notificações de email com base nas correspondências do filtro de arquivos do Exchange.

Para obter mais informações, consulte Protegendo sua organização do Microsoft Exchange com o Microsoft Forefront Security para Exchange Server (em inglês).

Executando o Exchange Best Practices Analyzer

O Best Practices Analyzer do Exchange é um das ferramentas mais eficazes que você pode executar regularmente para ajudar a verificar se seu ambiente do Exchange está seguro. O Best Practices Analyzer do Exchange examina automaticamente uma implantação do Microsoft Exchange Server e determina se está configurada de acordo com as práticas recomendadas do Microsoft. No Exchange 2010, o Analisador de Práticas Recomendadas do Exchange é instalado como parte da Instalação do Exchange e pode ser executado na seção Ferramentas do Console de Gerenciamento Exchange (EMC). Com o acesso de rede apropriado, o Analisador de Práticas Recomendadas do Exchange examina todos os servidores dos Serviços de Domínio Active Directory (AD DS) e os servidores do Exchange. O Analisador de Práticas Recomendadas do Exchange inclui verificações de herança das permissões. Além disso, ele testa a validação das permissões RBAC. Isso inclui testes para garantir que todos os usuários possam acessar o Painel de Controle do Exchange (ECP), se todas as funções RBAC padrão criadas pela Instalação do Exchange estão configuradas corretamente e se há pelo menos uma conta administrativa presente na organização do Exchange.

Uso da porta de rede e proteção de firewall

O Windows Server 2008 inclui o Firewall do Windows com Segurança Avançada, um firewall de inspeção do pacote com estado habilitado por padrão. O Firewall do Windows com Segurança Avançada fornece a seguinte funcionalidade:

  • Filtragem de todo o tráfego IP versão 4 (IPv4) e IP versão 6 (IPv6) que entra ou sai do computador. Por padrão, todo o tráfego de entrada é bloqueado, a menos que seja uma resposta a uma solicitação de saída anterior no computador (tráfego solicitado), ou seja especificamente permitido por uma regra criada para permitir esse tráfego. Por padrão, todo o tráfego de saída é permitido, exceto por regras de proteção do serviço que impeçam serviços padrão de se comunicarem de maneiras inesperadas. É possível optar por permitir tráfego com base em números de porta, endereços IPv4 ou IPv6, caminho e nome de um aplicativo, ou o nome de um serviço em execução no computador, ou outros critérios.

  • Proteção do tráfego de rede ou que deixa o computador usando o protocolo IPsec para verificar a integridade do tráfego de rede, autenticar a identidade dos computadores ou usuários de envio e recebimento, além de criptografar como opção para fornecer confidencialidade.

O Exchange 2010 foi projetado para ser executado com o Firewall do Windows Server com Segurança Avançada habilitado. A Instalação do Exchange cria as regras de firewall obrigatórias para permitir a comunicação dos serviços e dos processos do Exchange. Ela só cria as regras obrigatórias para os serviços e os processos instalados em uma determinada função de servidor. Para obter mais detalhes sobre o uso da porta de rede e as regras de firewall criadas para cada função de servidor do Exchange 2010, consulte Referência de porta de rede do Exchange.

No Windows Server 2008 e no Windows Server 2008 R2, o Firewall do Windows com Segurança Avançada permite especificar o processo ou serviço para o qual a porta é aberta. Isso é mais seguro porque restringe o uso da porta para o processo ou serviço especificado na regra. A Instalação do Exchange 2010 cria regras de firewall com o nome do processo especificado. Em alguns casos, uma regra adicional que não é restrita ao processo também é criada para fins de compatibilidade. É possível desabilitar ou remover as regras que não são restritas aos processos e manter as regras correspondentes também criadas pela Instalação do Exchange 2010 e restritas aos processos se a implantação oferece suporte para elas. Regras não restritas a processos são diferenciadas pela palavra (GFW) no nome da regra. Recomendamos realizar testes das regras o suficiente no ambiente para ser possível desabilitar as regras restritas a um processo.

Esta tabela lista as regras do Firewall do Windows criadas pela Instalação Exchange, incluindo as portas abertas em cada função de servidor.

Regras do Firewall do Windows

Nome da regra Funções de servidor Porta

MSExchangeRPCEPMap (GFW) (TCP-In)

Todas as funções

RPC-EPMap

MSExchangeRPC (GFW) (TCP-In)

Acesso para Cliente, Transporte de Hub, Caixa de Correio e Unificação de Mensagens

RPC dinâmico

MSExchange - IMAP4 (GFW) (TCP-In)

Acesso para cliente

143, 993 (TCP)

MSExchange - POP3 (GFW) (TCP-In)

Acesso para cliente

110, 995 (TCP)

MSExchange - OWA (GFW) (TCP-In)

Acesso para cliente

5075, 5076, 5077 (TCP)

MSExchangeMailboxReplication (GFW) (TCP-In)

Acesso para cliente

808 (TCP)

MSExchangeIS (GFW) (TCP-In)

Caixa de Correio

6001, 6002, 6003, 6004 (TCP)

MSExchangeTransportWorker (GFW) (TCP-In)

Transporte de Hub

25, 587 (TCP)

SESWorker (GFW) (TCP-In)

Unificação de Mensagens

qualquer um

UMService (GFW) (TCP-In)

Unificação de Mensagens

5060, 5061 (TCP)

UMWorkerProcess (GFW) (TCP-In)

Unificação de Mensagens

5065, 5066, 5067, 5068

Importante

Ao modificar a porta padrão usada por um serviço do Exchange 2010, você também deve modificar a regra de firewall do Firewall do Windows com Segurança Avançada para permitir a comunicação na porta não padrão que optou por usar. O Exchange 2010 não altera regras de firewall quando você altera portas padrão usadas para um serviço.

Parâmetros de limitação e políticas de limitação do cliente

O Exchange 2010 inclui parâmetros de limitação em funções de servidor Transporte, servidor de Acesso do Cliente e Caixa de Correio para controlar parâmetros diferentes de conexões relacionadas a cada protocolo. O Exchange 2010 também inclui políticas de limitação do cliente para controlar a carga em servidores de Acesso do Cliente. Esses parâmetros e políticas de limitação ajudam a controlar a carga e proteger servidores do Exchange 2010 de ataques de negação de serviço direcionados a protocolos diferentes.

Parâmetros de limitação em servidores de transporte

Em servidores de Transporte do Exchange 2010, os parâmetros de limitação de mensagem são implementados no servidor e nos conectores Enviar e Receber para controlar taxas de processamento da mensagem, taxas de conexão SMTP e valores de tempo limite da sessão SMTP. Juntos, esses parâmetros de limitação protegem servidores de transporte de serem sobrecarregados aceitando e entregando muitas mensagens, oferecendo proteção contra clientes não autorizados SMTP e ataques de negação de serviço.

É possível configurar as políticas de limitação a seguir em servidores Transporte do Exchange 2010 usando-se o cmdlet Set-TransportServer.

Parâmetros de limitação do servidor de transporte

Parameter Descrição

MaxConcurrentMailboxDeliveries

O parâmetro MaxConcurrentMailboxDeliveries especifica o número máximo de threads de entrega que o servidor de Transporte de Hub pode ter abertos ao mesmo tempo para entregar mensagens a caixas de correio. O driver de repositório no servidor de Transporte de Hub é responsável pela entrega de mensagens de e para servidores de Caixa de Correio. Esse limite se aplica à entrega de mensagens a qualquer caixa de correio na organização do Exchange.

Padrão   20 entregas

MaxConcurrentMailboxSubmissions

O parâmetro MaxConcurrentMailboxSubmissions especifica o número máximo de threads de entrega que o servidor de Transporte de Hub pode ter abertos ao mesmo tempo para aceitar mensagens de caixas de correio. O driver de repositório no servidor de Transporte de Hub é responsável pela entrega de mensagens de e para servidores de Caixa de Correio. Esse limite se aplica à aceitação de novas mensagens de qualquer caixa de correio na organização do Exchange.

Padrão   20 envios

MaxConnectionRatePerMinute

O parâmetro MaxConnectionRatePerMinute especifica a taxa máxima em que novas conexões de entrada podem ser abertas no servidor de Transporte de Hub ou servidor de Transporte de Borda. Essas conexões são abertas para qualquer Conector de recebimento que existe no servidor.

Padrão   1.200 conexões por minuto.

MaxOutboundConnections

O parâmetro MaxOutboundConnections especifica o número máximo de conexões de saída simultâneas que o servidor de Transporte de Hub ou o servidor de Transporte de Borda pode ter abertas ao mesmo tempo. As conexões de saída ocorrem usando os Conectores de envio existentes no servidor. O valor que é especificado pelo parâmetro MaxOutboundConnections se aplica a todos os Conectores de envio existentes no servidor de transporte.

Padrão   1.000 conexões.

Se você inserir um valor ilimitado, não será imposto um limite para o número de conexões de saída.

Esse valor pode ser configurado com a EMC.

MaxPerDomainOutboundConnections

O parâmetro MaxPerDomainOutboundConnections especifica o número máximo de conexões que um servidor de Transporte de Hub ou servidor de Transporte de Borda voltado para a Internet pode ter abertas para qualquer domínio remoto único. As conexões de saída com domínios remotos ocorrem usando os Conectores de envio existentes no servidor.

Padrão   20 conexões por domínio

Se você inserir um valor ilimitado, não será imposto um limite para o número de conexões de saída por domínio.

Esse valor pode ser configurado com a EMC.

PickupDirectoryMaxMessagesPerMinute

O parâmetro MaxPerDomainOutboundConnections especifica a taxa de processamento de mensagens para os diretórios Retirada e Repetição. Cada diretório pode processar arquivos de mensagem independentemente na velocidade que é especificada pelo parâmetro PickupDirectoryMaxMessagesPerMinute. Padrões   Por padrão, o Diretório de recebimento pode processar 100 mensagens por minuto, e o Diretório de repetição pode processar 100 mensagens por minuto simultaneamente.

O Diretório de recebimento e o Diretório de repetição verificam novos arquivos de mensagem a cada 5 segundos ou 12 vezes por minuto. Esse intervalo de sondagem de 5 segundos não é configurável. Isso significa que o número máximo de mensagens que podem ser processadas durante cada intervalo de sondagem é o valor atribuído ao parâmetro PickupDirectoryMaxMessagesPerMinute dividido por 12 (PickupDirectoryMaxMessagesPerMinute/12). Por padrão, só podem ser processadas aproximadamente oito mensagens por intervalo de sondagem de 5 segundos.

Parâmetros de limitação em conectores de envio

Os parâmetros de limitação a seguir estão disponíveis em conectores de envio. Use o cmdlet Send-Connector para configurar esses parâmetros.

Parâmetros de limitação do conector de envio

Parameter Descrição

ConnectionInactivityTimeOut

O parâmetro ConnectionInactivityTimeOut especifica o tempo máximo que uma conexão SMTP aberta com um servidor de mensagem de destino pode permanecer ociosa antes que a conexão seja fechada.

Padrão   10 minutos.

SmtpMaxMessagesPerConnection

O parâmetro SmtpMaxMessagesPerConnection especifica o número máximo de mensagens que esse servidor do conector de envio pode enviar por conexão.

Padrão   20 mensagens

Parâmetros de limitação em conectores de recebimento

É possível configurar os parâmetros de limitação a seguir em conectores de recebimento nos servidores Transporte do Exchange 2010 para controlar parâmetros de conexão, como tempos limite de inatividade, número máximo de conexões e número de erros do protocolo SMTP permitidos durante uma conexão. Use o cmdlet Set-ReceiveConnector para configurar esses parâmetros.

Parâmetros de limitação do conector de recebimento

Parameter Descrição

ConnectionInactivityTimeOut

O parâmetro ConnectionInactivityTimeOut especifica o tempo máximo que uma conexão SMTP aberta com um servidor de mensagem de origem pode permanecer ociosa antes que a conexão seja fechada.

Padrão em servidores Transporte de Hub   5 minutos.

Padrão em servidores Transporte de Borda   1 minuto.

ConnectionTimeOut

O parâmetro ConnectionTimeOut especifica o tempo máximo que uma conexão SMTP aberta com um servidor de mensagem de origem pode permanecer aberta, mesmo se o servidor de mensagem de origem estiver transmitindo dados.

Padrão em servidores Transporte de Hub   10 minutos

Padrão em servidores Transporte de Borda   5 minutos.

O valor especificado pelo parâmetro ConnectionTimeout deve ser maior que o valor especificado pelo parâmetro ConnectionInactivityTimeout.

MaxInboundConnection

O parâmetro MaxInboundConnection especifica o número máximo de conexões SMTP de entrada que esse Conector de recebimento permite simultaneamente.

Padrão   5.000

MaxInboundConnectionPercentagePerSource

O parâmetro MaxInboundConnectionPercentagePerSource especifica o número máximo de conexões SMTP que um Conector de recebimento permite simultaneamente a partir de um único servidor de mensagens de origem. O valor é expresso como a porcentagem de conexões restantes disponíveis em um conector de recebimento. O número máximo de conexões permitidas pelo Conector de recebimento é definido pelo parâmetro MaxInboundConnection. Padrão   2 por cento

MaxInboundConnectionPerSource

O parâmetro MaxInboundConnectionPerSource especifica o número máximo de conexões SMTP que um Conector de recebimento permite simultaneamente a partir de um único servidor de mensagens de origem.

Padrão   100 conexões

MaxProtocolErrors

O parâmetro MaxProtocolErrors especifica o número máximo de erros de protocolo SMTP que um Conector de Recebimento permite antes de fechar a conexão com o servidor de mensagens de origem.

Padrão   5 erros

Parâmetros de limitação para o serviço POP3

Os parâmetros de limitação a seguir estão disponíveis para o serviço POP3 do MicrosoftExchange em servidores Acesso do Cliente. Use o cmdlet Set-POPSettings para configurar esses parâmetros. Para detalhes, consulte Definir Limites de Conexão para POP3.

Parâmetros de limitação do serviço POP3

Parameter Descrição

MaxCommandSize

O parâmetro MaxCommandSize especifica o tamanho máximo de um único comando. Os valores possíveis são de 40 a 1.024 bytes.

Padrão   40 bytes.

MaxConnectonFromSingleIP

O parâmetro MaxConnectionFromSingleIP especifica o número de conexões que o servidor especificado aceita de um único endereço IP. Os valores possíveis são de 1 a 25.000.

Padrão   2.000 conexões

MaxConnections

O parâmetro MaxConnections especifica o número total de conexões que o servidor especificado aceita. Isso inclui conexões autenticadas e não autenticadas. Os valores possíveis são de 1 a 25.000.

Padrão   2,000 conexões.

MaxConnectionsPerUser

O parâmetro MaxConnectionsPerUser especifica o número máximo de conexões que o servidor de Acesso do Cliente aceita de um determinado usuário. Os valores possíveis são de 1 a 25.000.

Padrão   16 conexões.

PreAuthenticationConnectionTimeOut

O parâmetroPreAuthenticatedConnectionTimeout especifica o tempo a aguardar antes de encerrar uma conexão ociosa que não seja autenticada. Os valores possíveis são de 10 a 3,600 segundos.

Padrão   60 segundos.

Parâmetros de limitação para o serviço IMAP4

Os parâmetros de limitação a seguir estão disponíveis para o serviço IMAP4 do MicrosoftExchange em servidores Acesso do Cliente. Use o cmdlet Set-IMAPSettings para configurar esses parâmetros. Para detalhes, consulte Definir os Limites de Conexão para IMAP4.

Parâmetros de limitação do serviço IMAP4

Parameter Descrição

AuthenticationConnectionTimeOut

O parâmetro AuthenticatedConnectionTimeout especifica o período para aguardar antes de encerrar uma conexão autenticada ociosa. Os valores possíveis são de 30 a 86.400 segundos.

Padrão   1.800 segundos

MaxCommandSize

O parâmetro MaxCommandSize especifica o tamanho máximo de um único comando. O tamanho padrão é de 40 bytes. Os valores possíveis são de 40 a 1.024 bytes.

Padrão   40 bytes.

MaxConnectionFromSingleIP

O parâmetro MaxConnectionFromSingleIP especifica o número de conexões que o servidor especificado aceita de um único endereço IP. Os valores possíveis são de 1 a 25.000.

Padrão   2.000 conexões

MaxConnections

O parâmetro MaxConnections especifica o número total de conexões que o servidor especificado aceita. Isso inclui conexões autenticadas e não autenticadas. Os valores possíveis são de 1 a 25.000.

Padrão   2.000 conexões

MaxConnectionsPerUser

O parâmetro MaxConnectionsPerUser especifica o número máximo de conexões que o servidor de Acesso do Cliente aceita de um determinado usuário. Os valores possíveis são de 1 a 25.000.

Padrão   16 conexões.

PreAuthenticatedConnectionTimeOut

O parâmetroPreAuthenticatedConnectionTimeout especifica o tempo a aguardar antes de encerrar uma conexão ociosa que não seja autenticada. Os valores possíveis são de 10 a 3600 segundos.

Padrão   60 segundos

Diretivas de Aceleração de Cliente

No Exchange 2010, é possível usar políticas de limitação do cliente para gerenciar o desempenho do servidor Acesso do Cliente controlando-se parâmetros, como o número de conexões simultâneas para cada protocolo de acesso do cliente, a porcentagem de tempo que uma sessão do cliente pode usar para executar operações LDAP, RPC e operações de acesso do cliente. Existe uma política de limitação do cliente padrão que costuma ser suficiente para gerenciar a carga colocada em servidores Acesso do Cliente. É possível modificar os parâmetros de política padrão ou criar políticas personalizadas para atender aos requisitos da implantação.

Há políticas de limitação disponíveis para os seguintes grupos de usuários e os métodos de acesso:

  • Acesso anônimo

  • Acesso na instalação (CPA)

  • Exchange ActiveSync (EAS)

  • Serviços Web do Exchange (EWS)

  • IMAP

  • POP

  • Outlook Web App (OWA)

  • Acesso para Cliente do RPC (RCA)

As configurações de limitação a seguir estão disponíveis em políticas de limitação do cliente para cada um destes grupos de usuários (EAS, EWS, IMAP, OWA, POP, e RCA).

Configurações de política de limitação do cliente

Configuração de limitação Acesso anônimo CPA EAS EWS IMAP OWA POP RCA

Simultaneidade máxima

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Porcentagem de tempo no AD

Sim

N. D.

Sim

Sim

Sim

Sim

Sim

Sim

Porcentagem de tempo no CAS

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Porcentagem de tempo na RPC da caixa de correio

Sim

Sim

Sim

Sim

Sim

Sim

Sim

Sim

CPA   Acesso na instalação

EAS   Exchange ActiveSync

EWS   Serviços Web do Exchange

OWA   Outlook Web App

Além dessas configurações de limitação baseadas em grupos de usuários e métodos de acesso, as configurações de limitação a seguir estão disponíveis em uma política de limitação do cliente.

Parâmetros de política de limitação do cliente

Parameter Descrição

CPUStartPercent

O parâmetro CPUStartPercent especifica a porcentagem da CPU da base por processo com que os usuários governados por esta diretiva começam a ser retirados. Os valores válidos são de 0 a 100. Use $null para desativar a limitação com base na porcentagem da CPU para esta diretiva.

EASMaxDeviceDeletesPerMonth

O parâmetro EASMaxDeviceDeletesPerMonth especifica um limite do número de sociedade do Exchange ActiveSync que um usuário pode excluir por mês. Por padrão, cada usuário pode excluir um máximo de 20 sociedades por mês corrido. Quando o limite é atingido, a tentativa de eliminação de sociedade falha e uma mensagem de erro é exibida ao usuário.

EASMaxDevices

O parâmetro EASMaxDevices especifica um limite do número de sociedade do Exchange ActiveSync que um usuário pode ter por vez. Por padrão, cada usuário pode criar 10 Exchange ActiveSync parcerias com suas contas do Exchange. Após os usuários excederem este limite, eles devem excluir uma de suas parcerias existentes antes de criar quaisquer parcerias novas. Uma mensagem de erro de email que descreve a limitação é enviada ao usuário quando o limite é excedido. Além disso, um evento é registrado em log no log do Aplicativo quando um usuário excede o limite.

EWSFastSearchTimeOutInSeconds

O parâmetro EWSFastSearchTimeoutInSeconds especifica o tempo que as pesquisas usando os Serviços Web do Exchange continuam antes que atinjam o tempo limite. Se a pesquisa dura mais que o tempo indicado pelo valor da diretiva, a pesquisa para e é retornado um erro. O valor padrão dessa configuração é de 60 segundos.

EWSFindCountLimit

O parâmetro EWSFindCountLimit especifica o tamanho máximo do resultado das chamadas FindItem ou FindFolder que podem existir na memória no servidor Acesso para Cliente ao mesmo tempo para este usuário nesse processo atual. Se uma tentativa é feita para localizar mais itens ou pastas que seu limite de diretiva permite, é retornado um erro. No entanto, o limite não será reforçado exclusivamente se a chamada for feita dentro do contexto de uma visualização de página indexada. Especificamente, neste cenário, os resultados da pesquisa são truncados para incluir o número de itens e pastas que se encaixa dentro do limite da política. Você pode então continuar paginando em seus resultados definidos via chamadas FindItem ou FindFolder adicionais.

EWSMaxSubscriptions

O parâmetro EWSMaxSubscriptions especifica o número máximo de inscrições push and pull ativas que um usuário pode ter em um servidor de Acesso para Cliente específico simultaneamente. Se um usuário tentar criar mais inscrições que a máxima configurada, a inscrição falhará e um evento será registrado no Visualizador de Eventos.

ExchangeMaxCmdlets

O parâmetro ExchangeMaxCmdlets especifica o número de cmdlets que podem ser executados dentro de um período de tempo específico antes que sua execução diminua a velocidade. O valor especificado por este parâmetro deve ser menor que o valor especificado por PowerShellMaxCmdlets parameter.

O período de tempo usado para este limite é especificado pelo parâmetro PowerShellMaxCmdletsTimePeriod. Recomendamos que você defina valores para ambos os parâmetros ao mesmo tempo.

ForwardeeLimit

O parâmetro ForwardeeLimit especifica os limites para o número de destinatários que podem ser configurados nas Regras de caixa de entrada ao usar a ação encaminhar ou redirecionar. Este parâmetro não limita o número de mensagens que podem ser encaminhadas ou redirecionadas para destinatários que são configurados.

MessageRateLimit

O parâmetro MessageRateLimit especifica o número de mensagens por minuto que pode ser enviado para transportar. Para mensagens enviadas através da função de servidor da Caixa de Correio (Outlook Web App, Exchange ActiveSync ou Serviços Web do Exchange), isto resulta no adiamento de mensagens até que a cota para o usuário esteja disponível. Especificamente, mensagens aparecem na pasta Caixa de Saída ou Rascunhos para períodos mais longos de tempo quando usuários enviam mensagens em uma taxa maior que o parâmetro MessageRateLimit.

Para clientes POP ou IMAP enviarem mensagens diretamente para transporte usando SMTP, os clientes receberão um erro transitório se eles fizerem o envio em uma taxa que exceder o parâmetro MessageRateLimit. O Exchange tenta conectar e enviar as mensagens mais tarde.

PowerShellMaxCmdletQueueDepth

O parâmetro PowerShellMaxCmdletQueueDepth especifica o número de operações permitidas serem executadas pelo usuário. Esse valor afeta diretamente o comportamento dos parâmetros PowerShellMaxCmdlets e PowerShellMaxConcurrency. Por exemplo, o parâmetro PowerShellMaxConcurrency consome pelo menos duas operações definidas pelo parâmetro PowerShellMaxCmdletQueueDepth, mas as operações adicionais também são consumidas por execução Cmdlet. O número de operações depende dos cmdlets executados. Recomendamos que o valor para o parâmetro PowerShellMaxCmdletQueueDepth seja pelo menos três vezes maior que o valor de PowerShellMaxConcurrency parameter. Esse parâmetro não afetará as operações do Painel de Controle do Exchange ou dos Serviços Web do Exchange.

PowerShellMaxCmdlets

O parâmetro PowerShellMaxCmdlets especifica o número de cmdlets que podem ser executados dentro de um período de tempo específico antes que sua execução pare. O valor especificado por este parâmetro deve ser maior que o valor especificado pelo parâmetro ExchangeMaxCmdlets. O período de tempo usado para este limite é especificado pelo parâmetro PowerShellMaxCmdletsTimePeriod. Ambos os valores devem ser definidos ao mesmo tempo.

PowerShellMaxCmdletsTimePeriod

O parâmetro PowerShellMaxCmdletsTimePeriod especifica o período de tempo, em segundos, que a diretiva de otimização usa para determinar se o número de cmdlets a serem executados excede os limites especificados pelos parâmetros PowerShellMaxCmdlets e ExchangeMaxCmdlets.

PowerShellMaxConcurrency

O parâmetro PowerShellMaxConcurrency especifica informações diferentes dependendo de contexto:

No contexto do Remote PowerShell, o parâmetro PowerShellMaxConcurrency especifica o número máximo de sessões do Remote PowerShell que um usuário Remote PowerShell pode abrir ao mesmo tempo.

No contexto dos Serviços Web do Exchange, o parâmetro PowerShellMaxConcurrency especifica o número de execuções simultâneas cmdlet que um usuário pode ter ao mesmo tempo.

Este valor de parâmetro não se relaciona necessariamente com o número de navegadores abertos pelo usuário

RecipientRateLimit

O parâmetro RecipientRateLimit especifica os limites no número de destinatários que um usuário pode endereçar em um período de 24 horas.

Para obter mais detalhes sobre políticas de limitação do Exchange 2010, consulte Noções Básicas Sobre Diretivas de Limitação de Cliente.

Controle de Acesso Baseado em Função

Controle de Acesso Baseado na Função (RBAC) é o novo modelo de permissões do Exchange 2010 que permite controlar, em níveis ampliados e granulares, o que administradores e usuários podem fazer. Com o RBAC, não é mais necessário modificar Listas de Controle de Acesso (ACLs) em objetos do Active Directory como Unidades Organizacionais e contêineres para permitir a delegação granular de permissões a grupos como operadores de assistência técnica ou para funções como o gerenciamento de destinatários. Active Directory

Para mais detalhes, consulte Noções Básicas Sobre Controle de Acesso Baseado em Função. Para obter uma lista das funções de gerenciamento RBAC padrão incluídas no Exchange 2010, consulte Funções de Gerenciamento Integradas. Para obter uma lista dos grupos de funções válidas, consulte Grupos de Função Integrados.

Grupos de funções criadas pela Instalação do Exchange 2010 ou por você são criadas no Active Directory como grupos de segurança universal na UO Grupos de Segurança do MicrosoftExchange. É possível adicionar membros a um grupo de funções usando-se o cmdlet New-RoleGroupMember ou o Painel de Controle do Exchange (ECP). Quando você adiciona um membro a um grupo de funções, o usuário ou o grupo é adicionado ao grupo de segurança do Active Directory correspondente. É possível usar uma política Grupo Restrito para restringir a associação para grupos de funções RBAC críticos, como o Gerenciamento de Descoberta. Quando você implementa uma política Grupo Restrito, a associação do grupo é monitorada por controladores de domínio do Active Directory e todos os usuários não incluídos na política são automaticamente removidos.

Importante

Se você usar Grupos Restritos para restringir a associação do grupo para grupos de funções RBAC, todas as alterações feitas em um grupo de funções que use ferramentas do Exchange 2010 também deverão ser feitas na política Grupo Restrito do Active Directory. Para obter detalhes, consulte Group Policy Security Settings.

Active Directory

O Exchange Server armazena dados de configuração na partição Configuração e dados do destinatário na partição Domínio do Serviços de Domínio Active Directory (AD DS). Para obter detalhes sobre permissões necessárias à configuração de uma organização do Exchange 2010, consulte Referência de permissões de implantação do Exchange 2010. A comunicação com os controladores de domínio do Active Directory é protegida usando-se autenticação e criptografia Kerberos.

O Exchange 2010 fornece uma nova camada de autorização dentro do Exchange, conhecida como Controle de Acesso Baseado na Função (RBAC), em vez de contar com a aplicação de entradas de controle de acesso (ACEs) para cada conta que exija as permissões apropriadas. Em versões anteriores do Microsoft Exchange, a Instalação do Exchange contava com ACEs dentro do Active Directory para que administradores do Exchange pudessem gerenciar objetos dentro da partição do domínio. Os administradores do Exchange têm a possibilidade de realizar determinadas operações dentro de um escopo específico por meio do RBAC . O servidor do Exchange executa as ações autorizadas em nome do administrador ou dos usuários utilizando as permissões concedidas dentro do Active Directory por meio dos grupos de segurança Permissões do ExchangeWindows e Subsistema de Confiança do Exchange. Para obter mais informações sobre o RBAC, consulte Noções Básicas Sobre Controle de Acesso Baseado em Função.

No Exchange 2010, /PrepapareDomain não aplica nenhuma ACE para o grupo de segurança universal Permissões do ExchangeWindows ao contêiner AdminSDHolder no Active Directory. Se /PrepareDomain detectar alguma ACE concedida ao grupo de segurança universal Permissões do ExchangeWindows, as ACEs serão removidas. Isso tem as seguintes implicações:

  • Os membros do grupo de segurança universal Permissões do ExchangeWindows não podem modificar a associação de grupos de segurança protegidos, como Administradores de Empresa e Administradores de Domínio. Isso tem as implicações a seguir.

  • Os membros do grupo de segurança universal Permissões do ExchangeWindows não podem forçar a redefinição de senha de uma conta protegida por AdminSDHolder.

  • Os membros do grupo de segurança universal Permissões do ExchangeWindows não podem alterar as permissões de nenhum grupo ou conta protegida pelo AdminSDHolder.

Como uma prática recomendada, sugerimos que você não habilite a caixa de correio em contas protegidas pelo AdminSDHolder e mantenha contas separadas para administradores do Active Directory: uma conta para administração do Active Directory e uma conta para uso diário regular, inclusive email. Para obter informações detalhadas, consulte os seguintes tópicos:

Contas do Exchange Server

A Instalação do Exchange 2010 cria uma nova unidade organizacional (UO) no domínio raiz chamada Grupos de Segurança do MicrosoftExchange. A tabela a seguir mostra os novos grupos de segurança universais.

Grupos de segurança do Microsoft Exchange

Grupo de segurança Descrição

Todas as Organizações Hospedadas do Exchange

Esse grupo contém todos os grupos Caixas de Correio Hospedadas pela Organização do Exchange. Ele é usado na aplicação de Objetos de Configuração de Senha a todas as caixas de correio hospedadas. Esse grupo não deve ser excluído.

Servidores Exchange

Esse grupo contém todos os servidores do Exchange. Esse grupo não deve ser excluído. Desaconselhamos qualquer alteração feita na associação desse grupo.

Subsistema confiável do Exchange

Esse grupo contém servidores do Exchange. O Exchange executa cmdlets do Exchange em nome dos usuários por meio do serviço Gerenciamento. Os membros terão permissão para ler e modificar todas as configurações do Exchange, além de contas e grupos de usuários. Esse grupo não deve ser excluído.

Exchange Permissões do Windows

Esse grupo contém servidores do Exchange que executam cmdlets do Exchange em nome dos usuários por meio do serviço Gerenciamento. Os membros terão permissão para ler e modificar todas as contas e grupos do Windows. Esse grupo não deve ser excluído. Desaconselhamos qualquer alteração feita na associação desse grupo, e sugerimos o monitoramento da associação do grupo.

ExchangeLegacyInterop

Esse grupo se destina à interoperabilidade com servidores do Exchange 2003 dentro da mesma floresta. Esse grupo não deve ser excluído.

Além desses grupos de segurança, a instalação também cria os grupos de segurança a seguir que correspondem a grupos de funções RBAC com o mesmo nome.

Grupos de segurança que correspondem a grupos de funções RBAC

Grupo de segurança Grupo de seguranças RBAC

Instalação Representada

Instalação Representada

Gerenciamento de descoberta

Gerenciamento de Descoberta

Assistência técnica

Suporte técnico

Gerenciamento de Higienização

Gerenciamento de Higienização

Gerenciamento da Organização

Gerenciamento da Organização

Gerenciamento de Pasta Pública

Gerenciamento de Pasta Pública

Gerenciamento de Destinatários

Gerenciamento de Destinatários

Gerenciamento de Registros

Gerenciamento de Registros

Gerenciamento do Servidor

Gerenciamento do Servidor

Gerenciamento da UM

Gerenciamento da UM

Gerenciamento da Organização Somente para Exibição

Gerenciamento da Organização Somente para Exibição

Além disso, quando você cria um novo grupo de funções, o Exchange 2010 cria um grupo de segurança com o mesmo nome do grupo de funções. Para obter informações detalhadas, consulte os seguintes tópicos:

Os usuários são adicionados ou removidos desses grupos de segurança quando você adiciona ou remove usuários de grupos de funções usando os cmdlets Add-RoleGroupMember ou Remove-RoleGroupMember, ou usando o Editor de Usuário do Controle de Acesso Baseado em Função (RBAC) no ECP.

Sistema de arquivos

A Instalação do Exchange 2010 cria diretórios com o mínimo de permissões necessário para que o Exchange 2010 funcione. Não recomendamos nenhuma proteção adicional de permissões para as listas de controle de acesso (ACLs) padrão em diretórios criados pela instalação.

Services

A Instalação do Exchange 2010 não desabilita nenhum serviço do Windows por padrão. A tabela a seguir lista serviços habilitados por padrão em cada função de servidor. Apenas os serviços obrigatórios para a operação de uma determinada função de servidor do Exchange 2010 são habilitados por padrão.

Serviços instalados pela Instalação do Exchange

Nome do serviço Nome abreviado do serviço Contexto de segurança Descrição e dependências Tipo de inicialização padrão Funções de servidor Necessário (N) ou opcional (O)

Microsoft Exchange Topologia do Active Directory

MSExchangeADTopology

Sistema local

Fornece informações de topologia do Active Directory para os serviços do Exchange. Se esse serviço for parado, a maior parte dos serviços do Exchange não poderão ser iniciados. Esse serviço não tem dependências.

Automática

Caixa de Correio, Transporte de Hub, Acesso para Cliente, Unificação de Mensagens

N

Microsoft Exchange ADAM

ADAM_MSExchange

Serviço de Rede

Armazena dados de configuração e de destinatário no servidor de Transporte de Borda. Esse serviço representa a instância nomeada do Active Directory Lightweight Directory Service (AD LDS)  que é criada automaticamente pelo programa de instalação durante a instalação do servidor de Transporte de Borda. Esse serviço depende do serviço Sistema de Eventos COM+.

Automática

Transporte de Borda

N

Catálogo de Endereços do Microsoft Exchange

MSExchangeAB

Sistema local

Gerencia conexões de catálogo de endereço do cliente. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Acesso para cliente

N

Atualização do Microsoft Exchange Anti-spam

MSExchangeAntispamUpdate

Sistema local

Fornece o MicrosoftForefront Protection 2010 para o serviço de atualização de anti-spam do Exchange Server. Em servidores de Transporte de Hub, esse serviço depende do serviço de Topologia do Microsoft ExchangeActive Directory. Em servidores de Transporte de Borda, esse serviço é dependente do serviço Microsoft Exchange ADAM.

Automática

Transporte de Hub, Transporte de Borda

O

Serviço de Credencial do Microsoft Exchange

MSExchangeEdgeCredential

Sistema local

Monitora alterações de credencial nos serviços AD LDS e instala as alterações no servidor de Transporte de Borda. Esse serviço depende do serviço Microsoft Exchange ADAM.

Automática

Transporte de Borda

N

Microsoft Exchange EdgeSync

MSExchangeEdgeSync

Sistema local

Estabelece conexão com a instância dos serviços AD LDS nos servidores de Transporte de Borda assinados, por meio de um canal LDAP seguro, para sincronizar dados entre um servidor de Transporte de Hub e um servidor de Transporte de Borda. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory. Se a Inscrição de Borda não estiver configurada, o serviço poderá ser desabilitado.

Automática

Transporte de Hub

O

Distribuição de Arquivos do Microsoft Exchange

MSExchangeFDS

Sistema local

Distribui prompts de OAB (catálogo de endereços offline) e de Unificação de Mensagens personalizada. O serviço depende dos serviços Topologia e Estação de Trabalho do Microsoft ExchangeActive Directory.

Automática

Acesso para Cliente, Unificação de Mensagens

N

Autenticação Baseada em Formulários do Microsoft Exchange

MSExchangeFBA

Sistema local

Fornece autenticação baseada em formulários ao Outlook Web App e ao Painel de Controle do Exchange. Se o serviço for interrompido, o Outlook Web App e o Painel de Controle do Exchange não autenticarão usuários. Esse serviço não tem dependências.

Automática

Acesso para cliente

N

Microsoft Exchange IMAP4

MSExchangeIMAP4

Serviço de Rede

Fornece serviços IMAP4 a clientes. Se esse serviço for parado, os clientes não conseguirão se conectar ao computador utilizando o protocolo IMAP4. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Manual

Acesso para cliente

O

repositório de Informações do Microsoft Exchange

MSExchangeIS

Sistema local

Gerencia o Armazenamento de Informações do Exchange. Isso inclui bancos de dados de caixas de correio e de pastas públicas. Se o serviço for interrompido, os bancos de dados de caixas de correio e de pastas públicas neste computador não ficarão disponíveis. Se esse serviço estiver desabilitado, qualquer serviço que dependa dele diretamente falhará ao iniciar. Esse serviço depende dos serviços de RPC, Servidor, Log de Eventos do Windows e Estação de Trabalho.

Automática

Caixa de Correio

N

Serviço de Envio de Email do Microsoft Exchange

MSExchangeMailSubmission

Sistema local

Envia mensagens do servidor Caixa de Correio para os servidores Transporte de Hub do Exchange 2010. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Caixa de Correio

N

Assistentes de Caixa de Correio do Microsoft Exchange

MSExchangeMailboxAssistants

Sistema local

Executa o processamento em segundo plano de caixas de correio no repositório do Exchange. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Caixa de Correio

N

Serviço de Replicação de Caixa de Correio do Microsoft Exchange

MSExchangeMailboxReplication

Sistema local

Processa movimentações de caixa de correio e solicitações de movimentação. Esse serviço depende dos serviços de Compartilhamento de Porta Net.Tcp e de Topologia do Microsoft ExchangeActive Directory.

Automática

Acesso para cliente

O

Monitoramento do Microsoft Exchange

MSExchangeMonitoring

Sistema local

Permite aos aplicativos chamar os cmdlets de diagnóstico do Exchange. Esse serviço não tem dependências.

Manual

All

O

Microsoft Exchange POP3

MSExchangePOP3

Serviço de Rede

Fornece o serviço POP3 para clientes. Se esse serviço for parado, os clientes não conseguirão se conectar ao computador utilizando o protocolo POP3. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Manual

Acesso para cliente

O

Host de Serviço Protegido do Microsoft Exchange

MSExchangeProtectedServiceHost

Sistema local

Fornece um host para vários serviços do Exchange que devem ser protegidos de outros serviços. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Transporte de Hub, Acesso para Cliente

N

Serviço de Replicação do Microsoft Exchange

MSExchangeRepl

Sistema local

Oferece a funcionalidade de replicação para bancos de dados de caixa de correio em servidores de Caixa de Correio em um DAG (grupo de disponibilidade de banco de dados). Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Caixa de Correio

O

Acesso para Cliente RPC do Microsoft Exchange

MSExchangeRPC

Serviço de Rede

Gerencia conexões RPC do cliente para o Exchange. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Caixa de Correio, Acesso para Cliente

O (Caixa de Correio), R (Acesso para Cliente)

Indexador de Pesquisa do Microsoft Exchange

MSExchangeSearch

Sistema local

Conduz a indexação de conteúdo de caixa de correio, que melhora o desempenho da pesquisa de conteúdo. O serviço depende dos serviços Topologia do Microsoft ExchangeActive Directory e Pesquisa do Microsoft (Exchange Server).

Automática

Caixa de Correio

O

Microsoft Exchange Server Extension para Backup do Windows Server

WSBExchange

Sistema local

Permite que os usuários de Backup do Servidor do Windows façam backup e recuperem dados de aplicativo do Microsoft Exchange. Esse serviço não tem dependências.

Manual

Caixa de Correio

O

Host de Serviço do Microsoft Exchange

MSExchangeServiceHost

Sistema local

Proporciona um host para vários serviços do Exchange. Em funções de servidor internas, esse serviço depende do serviço de Topologia do Microsoft ExchangeActive Directory. Em servidores de Transporte de Borda, esse serviço é dependente do serviço Microsoft Exchange ADAM.

Automática

All

N

Mecanismo de Fala do Microsoft Exchange

MSSpeechService

Serviço de Rede

Fornece serviços de processamento de fala para Unificação de Mensagens. Esse serviço depende do serviço de WMI (Instrumentação de Gerenciamento do Windows).

Automática

Unificação de Mensagens

N

Atendedor do Sistema do Microsoft Exchange

MSExchangeSA

Sistema local

Encaminha pesquisas de diretório para um servidor de catálogo global para clientes herdados do Outlook, gera endereços de email e OABs, atualiza informações de disponibilidade para clientes herdados e mantém permissões e associações de grupo para o servidor. Se esse serviço estiver desabilitado, qualquer serviço que dependa dele diretamente falhará ao iniciar. Esse serviço depende dos serviços de RPC, Servidor, Log de Eventos do Windows e Estação de Trabalho.

Automática

Caixa de Correio

N

Limitação do Microsoft Exchange

MSExchangeThrottling

Serviço de Rede

Limita a taxa de operações de usuário. Esse serviço depende do serviço de Topologia do Microsoft Exchange Active Directory.

Automática

Caixa de Correio

N

Transporte do Microsoft Exchange

MSExchangeTransport

Serviço de Rede

Fornece o servidor SMTP e pilha de transporte. Em servidores de Transporte de Hub, esse serviço depende do serviço de Topologia do Microsoft ExchangeActive Directory. Em servidores de Transporte de Borda, esse serviço é dependente do serviço Microsoft Exchange ADAM.

Automática

Transporte de Hub, Transporte de Borda

N

Pesquisa de Log de Transporte do Microsoft Exchange

MSExchangeTransportLogSearch

Sistema local

Fornece capacidade de pesquisa remota para arquivos de log do Transporte do Microsoft Exchange. Em servidores de Transporte de Hub, esse serviço depende do serviço de Topologia do Microsoft ExchangeActive Directory. Em servidores de Transporte de Borda, esse serviço é dependente do serviço Microsoft Exchange ADAM.

Automática

Transporte de Hub, Caixa de Correio, Transporte de Borda

O

Unificação de Mensagens do Microsoft Exchange

MSExchangeUM

Sistema local

Habilita recursos de Unificação de Mensagens do Microsoft Exchange. Isso permite que mensagens de voz e de fax sejam armazenadas no Exchange e concede aos usuários acesso por telefone a email, caixa postal, calendário, contatos ou um atendedor automático. Se o serviço for parado, a Unificação de Mensagens ficará indisponível. Esse serviço depende do serviço de Topologia do Microsoft ExchangeActive Directory e do serviço de Mecanismo de Fala do Microsoft Exchange.

Automática

Unificação de Mensagens

N

Pesquisa do Microsoft (Exchange Server)

msftesql-Exchange

Sistema local

Essa é uma versão personalizada pelo Microsoft Exchange do Microsoft Search. Esse serviço depende do serviço de RPC.

Manual

Transporte de Hub, Caixa de Correio

O

Certificados

A Instalação do Exchange 2010 cria certificados autoassinados para proteger a comunicação em protocolos diferentes como HTTP, SMTP, POP3 e IMAP4. Os certificados autoassinados criados pela Instalação são válidos por cinco anos. Isso garante que os certificados autoassinados não precisem ser renovados para uma parte significativa de uma implantação do Exchange 2010 e que serviços do sistema de mensagens não sejam afetados pela expiração de certificados autoassinados.

Para mecanismos e protocolos de acesso do cliente, como Outlook Web App, POP3, IMAP4, Outlook Anywhere e Descoberta Automática, recomendamos que você:

  • Use certificados assinados por uma autoridade de certificação (CA) comercial confiável por clientes que acessam esses serviços.

  • Use o assistente Novo Certificado do Exchange ou o cmdlet New-ExchangeCertificate para criar solicitações de assinatura de certificado para CAs comerciais. As solicitações de certificado geradas usando-se essas ferramentas garantem que todos os requisitos de certificado do Exchange sejam atendidos.

  • Considere os requisitos de certificado de cada protocolo ou serviço para o qual você deseja permitir o acesso do cliente externo.

  • Monitore datas de validade do certificado e renove certificados de CAs em tempo hábil para evitar a interrupção do serviço.

  • Ao armazenar certificados exportados com a chave privada associada, proteja o arquivo exportado usando controles de acesso apropriados na pasta/arquivo onde ele está armazenado. Dependendo dos requisitos de segurança da organização, considere a habilitação da auditoria do acesso do arquivo para pastas nas quais arquivos de certificado com chaves privadas estão armazenados.

Considerações de NTLM

O protocolo de NTLM é significativamente menos seguro do que o protocolo Kerberos. No Exchange 2010, os protocolos POP3 e IMAP4 não oferecem suporte à autenticação NTLM quando SecureLogin está especificado como LoginType. Para obter detalhes, consulte Configurando a Autenticação para POP3 e IMAP4. Os serviços do Exchange 2010 que usam a Autenticação Integrada do Windows podem usar protocolos NTLM ou Kerberos. Kerberos é usado para comunicação de servidor Acesso do Cliente com um servidor Caixa de Correio do Exchange 2010 e entre servidores Acesso do Cliente para Outlook Web App, Exchange ActiveSync e Serviços Web do Exchange. Para obter detalhes sobre serviços que usem NTLM na autenticação, consulte Referência de porta de rede do Exchange.

Autenticação de Fator Duplo

Os mecanismos de autenticação de fator duplo usam outro autenticador além das credenciais de logon do usuário (nome de usuário e senha), como tokens gerados aleatoriamente ou um certificado digital em um cartão inteligente com um PIN. Muitas organizações implantam autenticação de fator duplo para permitir o acesso seguro à rede da organização.

O Exchange 2010 não inclui suporte nativo para autenticação de fator duplo. O Exchange 2010 usa o Internet Information Server (IIS) 7 para acesso cliente por meio de HTTP (Descoberta Automática, Outlook Web App, Outlook Anywhere, Exchange ActiveSync e Serviços Web do Exchange). Muitos produtos de autenticação de fator duplo que se integram ao IIS são disponibilizados por parceiros e terceiros, além de funcionarem com serviços de acesso cliente do Exchange como o Outlook Web App. Antes de implantar produtos de autenticação de fator duplo para serviços do Exchange, recomendamos que você os teste corretamente para garantir que eles atendam aos requisitos de segurança da organização e forneçam a funcionalidade desejada.

Federação

O Exchange 2010 apresenta novos recursos de federação para permitir uma colaboração segura entre organizações do Exchange federadas. As organizações do Exchange 2010 podem criar uma confiança de federação com o Microsoft Federation Gateway e, em seguida, estabelecer relacionamentos de organização com outras organizações federadas para compartilhar informações de disponibilidade e calendários. As organizações também podem permitir que os usuários compartilhem informações de disponibilidade, calendários e contatos com usuários em organizações federadas externas usando Políticas de Compartilhamento. Para obter mais detalhes sobre confianças de federação e compartilhamento federado, consulte Noções Básicas Sobre Federação e Noções básicas sobre Delegação Federada.

Depois de estabelecer uma confiança de federação com MFG, o compartilhamento entre duas organizações federadas não ocorre, a menos que você crie um relacionamento de organização. Porém, por padrão, o compartilhamento entre os usuários e os usuários em organizações federadas externas é habilitado usando-se a Política de Compartilhamento Padrão atribuída a usuários. A política permite o compartilhamento de calendário com informações de disponibilidade apenas com usuários em todas as organizações federadas externas. Se não quiser permitir que os usuários compartilhem informações de calendário e disponibilidade com usuários em todos os domínios federados externos, você deverá desabilitar a Política de Compartilhamento Padrão ou alterar o nome de domínio especificado na política apenas para os domínios com os quais você deseja permitir o compartilhamento. Você deve fazer essa alteração antes de criar uma confiança de federação com MFG. Para mais detalhes, consulte Desabilitar uma diretiva de compartilhamento e Configurar as Propriedades da Diretiva de Compartilhamento.

É possível desabilitar todos os recursos de federação para uma organização, inclusive Delegação Federada, removendo-se a confiança de federação da organização com MFG. Para mais detalhes, consulte Remover uma Confiança de Federação.

S/MIME (Secure/Multipurpose Internet Mail Extensions)

Secure/Multipurpose Internet Mail Extensions (S/MIME) é um padrão para criptografia de chave pública e assinatura de dados MIME que fornece autenticação, integridade de mensagem, não repúdio e privacidade de dados para dados do sistema de mensagens. Os usuários podem assinar ou criptografar mensagens, ou ambos, usando certificados S/MIME. Para obter mais informações sobre o S/MIME, consulte Compreendendo S/MIME.

S/MIME é uma tecnologia do lado do cliente sem nenhum requisito de interoperabilidade para servidores de email. De uma perspectiva da transferência de mensagem, as mensagens assinadas ou criptografadas S/MIME são transferidas da mesma forma como mensagens em texto não criptografado. A renderização real da mensagem é feita no lado do cliente depois das verificações de validação de certificado e mensagem. Para o Outlook Web App, o suporte a S/MIME é fornecido usando-se um controle ActiveX. Muito embora o Outlook Web App ofereça suporte à maioria dos navegadores mais populares, como o Microsoft Internet Explorer, o Mozilla FireFox e o Safari, os controles ActiveX são um recurso do Internet Explorer. Os usuários do Outlook Web App que utilizam outros navegadores não podem acessar recursos S/MIME e talvez precisem usar outro cliente de email com suporte a S/MIME. Para obter mais detalhes sobre o suporte a S/MIME no Outlook Web App, consulte Outlook Web App e S/MIME.

Para obter mais detalhes sobre o suporte oferecido para S/MIME no Outlook, consulte Visão geral de certificados e mensagens de emails criptigrafados no Outlook.

Enquanto S/MIME oferece benefícios de segurança a uma organização, ao avaliar a tecnologia, você deve considerar o seguinte:

  • As mensagens criptografadas S/MIME são opacas à organização. Um software de segurança do sistema de mensagens, como antivírus e anti-spam, não pode inspecionar o conteúdo da mensagem, inclusive o corpo da mensagens e todos os anexos.

  • Como o conteúdo da mensagem e os anexos são criptografados, as políticas do sistema de mensagens da organização, inclusive regras de transporte, não podem ser aplicadas a mensagens criptografadas por S/MIME.

  • A modificação de mensagens assinadas por S/MIME de acordo com as políticas do sistema de mensagens da organização, por exemplo, para aplicar um aviso de isenção de responsabilidade ou assinatura personalizada, invalida a mensagem.

  • O conteúdo do sistema de mensagens criptografadas não pode ser inspecionado para nenhuma violação de conteúdo, e a organização não pode proteger informações confidenciais. Isso inclui todas as informações de identificação pessoal (PII) que deixam a organização.

  • As mensagens criptografadas por S/MIME não podem ser indexadas pela Pesquisa do Exchange e, assim, não são pesquisáveis por descoberta.

  • Para atender aos regulamentos locais ou aos requisitos de descoberta durante o litígio, a organização pode precisar produzir cópias de todas as mensagens criptografadas não criptografadas.

O Exchange 2010 oferece recursos do Gerenciamento de Direitos de Informação (IRM) que permitem à organização aplicar proteção persistente ao conteúdo do sistema de mensagens confidenciais para que apenas os destinatários especificados possam acessar mensagens protegidas por IRM. A organização também pode implementar controles sobre como esse conteúdo é usado depois de entregue aos destinatários. Por exemplo, é possível impedir que as mensagens sejam impressas, respondidas ou encaminhadas dentro ou fora da organização. Além disso, a organização ainda pode descriptografar o conteúdo protegido por IRM para verificação pelo software antivírus ou anti-spam e outros agentes de transporte, aplicando políticas do sistema de mensagens usando regras de transporte e permite o arquivamento e a descoberta de mensagens protegidas por IRM. Os recursos do IRM também estão disponíveis em todos os navegadores da Web suportados pelo Outlook Web App e em dispositivos do Windows Mobile. Para obter mais detalhes sobre o IRM, consulte Noções Básicas Sobre o Gerenciamento de Direitos de Informação.

Considerações da função de servidor

Esta seção lista considerações relacionadas à segurança para a função de servidor do Exchange 2010.

Considerações do servidor Caixa de Correio

No Exchange 2010, as alterações arquitetônicas foram feitas no repositório do Exchange e na conectividade dos clientes MAPI, como o Outlook. Os clientes MAPI se conectam ao servidor Acesso do Cliente, que isolam o servidor Caixa de Correio do tráfego do cliente. Os servidores Caixa de Correio só se comunicam com servidores Acesso do Cliente que usem RPCSec e com servidores Serviços de Domínio Active Directory (AD DS) na organização. Os servidores Caixa de Correio não exigem conectividade com a Internet.

Armazenamento

O armazenamento é um componente crítico de servidores Caixa de Correio. Você deve planejar o subsistema de armazenamento do servidor Caixa de Correio para garantir o desempenho satisfatório e a disponibilidade do espaço de armazenamento para a implantação. Para obter mais detalhes sobre como se planejar para o armazenamento do servidor Caixa de Correio, consulte Design do Armazenamento do Servidor de Caixa de Correio.

Após a implantação do servidor Caixa de Correio, você deve monitorar o seguinte:

  • Disponibilidade do subsistema de armazenamento.

  • Disponibilidade de espaço livre em disco suficiente que contenha logs do banco de dados e da transação da caixa de correio. Um banco de dados de caixa de correio ou Pasta Pública é desmontado quando o volume que armazena os logs do banco de dados ou da transação ficam sem espaço livre em disco.

É possível usar o Microsoft Federation Gateway Systems Center Operations Manager para monitorar a disponibilidade do armazenamento e o espaço livre em disco. Para obter mais detalhes, consulte Systems Center Operations Manager 2007.

Ao se planejar para e monitorar o armazenamento, se pretender usar os recursos a seguir, você deverá considerar os requisitos de armazenamento:

  • Registro no diário   Quando você usar o registro no diário para manter mensagens para um arquivamento por longo tempo, dependendo do uso do registro no diário padrão (por banco de dados da caixa de correio) ou premium (regras de diário), as mensagens enviadas para e de todos os destinatários em um banco de dados da caixa de correio ou os destinatários especificados em uma regra de diário são entregues em um relatório de diário para a caixa de correio do registro no diário ou o destinatário especificado. O resultado pode ser um número grande de relatórios de diário entregues para uma caixa de correio do registro no diário. Ao planejar o armazenamento para servidores Caixa de Correio, você deve considerar tamanhos da caixa de correio do registro no diário. É possível controlar tamanhos da caixa de correio do registro no diário configurando-se cotas de caixa de correio suficientes para uma caixa de correio de registro no diário. Para obter mais detalhes sobre registro no diário e cotas da caixa de correio, consulte os seguintes tópicos:

  • Retenção de litígio   Quando você coloca uma caixa de correio em retenção de litígio, os itens excluídos pelo usuário utilizando a funcionalidade Recuperar Itens Excluídos no Outlook e no Outlook Web App e as mensagens excluídas por processos automatizados, como MRM, são mantidos até a retenção de litígio ser removida. No Exchange 2010, a cota de aviso de itens recuperáveis e a cota de itens recuperáveis são definidas como 20 GB e 30 GB. Para obter mais detalhes, consulte os seguintes tópicos:

Alta Disponibilidade

A alta disponibilidade dos servidores Caixa de Correio é essencial na garantia da disponibilidade do serviço do sistema de mensagens. O Exchange 2010 inclui grupos de disponibilidade do banco de dados (DAGs) para alta disponibilidade dos servidores Caixa de Correio. Os DAGs podem fornecer disponibilidade quando a implantação do Exchange apresenta uma falha do subsistema de armazenamento, do servidor, da conectividade de rede ou uma interrupção de um datacenter inteiro. Para obter mais detalhes sobre como se planejar e implementar uma implantação do Exchange 2010 altamente disponível, consulte Alta disponibilidade e resiliência do site.

Por padrão, no Exchange 2010, o tráfego de replicação (envio de logs) entre membros DAG localizados em locais do Active Directory diferentes é criptografado. É possível criptografar o tráfego de replicação entre servidores no mesmo local do Active Directory definindo-se a propriedade NetworkEncryption do DAG como Habilitada. Use o cmdlet Set-DatabaseAvailabilityGroup para modificar a propriedade de um DAG.

A replicação ocorre em uma única porta TCP, por padrão, porta TCP 64327. É possível modificar a porta usada na replicação. Para detalhes, consulte Configurar as Propriedades do Grupo de Disponibilidade do Banco de Dados.

Parâmetros para alta disponibilidade

Parameter Descrição

NetworkEncryption

O parâmetro NetworkEncryption especifica se a criptografia de rede está habilitada. Os valores válidos incluem:

  • Disabled   desabilitada em todas as redes

  • Enabled   habilitada em todas as redes

  • InterSubnetOnly   Habilitada apenas para comunicação entre sub-redes

  • SeedOnly   habilitada apenas para propagação

Padrão   InterSubnetOnly

ReplicationPort

O parâmetro ReplicationPort especifica uma porta TCP para atividade de replicação (envio de logs e propagação).

Padrão   Se o parâmetro não for especificado, a porta padrão para replicação é a TCP 64327.

Permissões e acesso da caixa de correio

Por padrão, o Exchange 2010 não permite que os administradores acessem caixas de correio. Se a organização usar aplicativos ou serviços que exijam acesso a uma caixa de correio, você deverá atribuir permissões de caixa de correio apropriadas a contas usadas por esses aplicativos ou serviços. Recomendamos que você não configure esses aplicativos ou serviços para usarem credenciais de administrador.

Muito embora todas as caixas de correio possam conter informações confidenciais importantes para uma organização, todas as caixas de correio merecem atenção especial de um ponto de vista da segurança, e as permissões para acessar essas caixas de correio devem ser controladas e monitoradas para atender aos requisitos de segurança da organização.

  • Caixas de correio de descoberta   As caixas de correio de descoberta são usadas pelo recurso Procura nas Várias Caixas de Correio do Exchange 2010. Isso permite que gerentes de descoberta membros do grupo de funções Gerenciamento de Descoberta pesquisem mensagens em todas as caixas de correio em uma organização do Exchange 2010. As mensagens retornadas por uma pesquisa de descoberta são copiadas para a caixa de correio Descoberta especificada. A instalação do Exchange 2010 cria uma caixa de correio de pesquisa de descoberta. Para mais detalhes, consulte Noções Básicas Sobre Pesquisa em Várias Caixas de Correio.

  • Caixas de correio de registro no diário   Quando você configura registro no diário para um banco de dados de caixa de correio ou cria regras de diário para mensagens de diário para e de destinatários especificados, relatórios de diário são entregues na caixa de correio de registro no diário especificada. Para obter mais detalhes, consulte os seguintes tópicos:

Além de proteger essas caixas de correio, observe que um administrador pode usar regras de transporte para inspecionar o conteúdo da mensagem e também entregar uma cópia da mensagem em outro destinatário, mesmo como um destinatário Cco. As permissões obrigatórias para gerenciar regras de transporte são listadas na entrada de regras de transporte no tópico Permissões de diretivas e conformidade no envio e recebimento de mensagens. Recomendamos que você use controles adequados para monitorar e controlar a criação e a modificação das regras de transporte e também audite regularmente ações de regra de transporte para todas as regras.

Considerações do servidor de Acesso do Cliente

No Exchange 2010, os seguintes clientes se conectam a servidores de Acesso do Cliente para acessar caixas de correio:

  • Clientes do Outlook que usam MAPI

  • Clientes do Outlook que usam o Outlook Anywhere

  • Navegadores da Web que usam o Outlook Web App,

  • Dispositivos móveis que usam o Exchange ActiveSync

  • Clientes do POP3 & IMAP4

  • Aplicativos que usam os Serviços Web do Exchange (EWS)

Por padrão, esses métodos de acesso do cliente são protegidos usando-se caminhos de dados criptografados. Também por padrão, os clientes do Outlook que se conectam ao servidor de Acesso do Cliente usando MAPI utilizam a criptografia RPC. O acesso do Outlook Web App, Outlook Anywhere e Exchange ActiveSync é protegido usando-se o protocolo SSL.

Para o acesso do cliente externo, você deve obter e instalar certificados assinados por uma autoridade de certificação (CA) confiável do cliente. Para mais detalhes, consulte Gerenciando SSL para um Servidor de Acesso para Cliente.

Por padrão, os serviços POP3 e IMAP4 são desabilitados em servidores de Acesso do Cliente do Exchange 2010. Se você habilitá-los, recomendamos usar os protocolos TLS ou SSL para ajudar a proteger a comunicação usando esses protocolos. Para obter mais detalhes, consulte os seguintes tópicos:

recomendamos que você use os firewalls apropriados e os controles de acesso ao publicar servidores de Acesso para Cliente para acesso externo. Microsoft O Forefront Threat Management Gateway (TMG) 2010 inclui assistentes de publicação para publicar com facilidade e segurança servidores de Acesso do Cliente do Exchange 2010 para acesso externo. Para obter mais detalhes, consulte Forefront Threat Management Gateway (TMG) 2010.

Importante

A localização dos servidores de Acesso do Cliente em redes de perímetro não é suportada.

Nos servidores de Acesso do Cliente, o Internet Information Server (IIS) é usado para fornecer ao protocolo HTTP acesso a serviços como o Outlook Web App, o Exchange ActiveSync, o Outlook Anywhere, a Descoberta Automática, o Painel de Controle do Exchange (ECP), os Serviços Web do Exchange e o catálogo de endereços offline (OAB). O PowerShell Remoto também usa o IIS, e todas as solicitações RPS, inclusive solicitações feitas pelo Console de Gerenciamento do Exchange(EMC), são registradas em logs do IIS. Os logs do IIS podem crescer para consumir uma grande quantidade de espaço em disco. O IIS, um componente Windows Server, não inclui um mecanismo para limpar logs anteriores com base no tamanho do diretório no qual os arquivos de log residem. Como prática recomendada, os logs do IIS devem ser movidos para um volume que não seja do sistema, para que o crescimento dos arquivos de log não resulte na falta de espaço em disco do volume do sistema, o que pode causar uma interrupção do serviço. Você deve monitorar o crescimento do arquivo de log e implementar um mecanismo para arquivar manualmente ou excluir logs conforme necessário. Para obter detalhes, consulte Configurando o log no IIS 7.

Considerações do servidor de transporte

O Exchange 2010 oferece duas funções de servidor de transporte projetadas para fins diferentes.

  • Transporte de Borda   A função de servidor Transporte de Borda é um servidor de transporte ingressado de não domínio, normalmente localizado em redes de perímetro, que transfere mensagens entre a organização do Exchange e os hosts SMTP externos. Muito embora projetado para redes de perímetro, também é possível localizar servidores Transporte de Borda na rede interna e ingressar o servidor em um domínio do Active Directory como um servidor membro.

  • Transporte de Hub   A função de servidor Transporte de Hub transfere mensagens dentro da organização, inclusive mensagens entre servidores do Exchange, mensagens de clientes SMTP, como usuários que utilizam POP3 e IMAP4, além de servidores de aplicativos e dispositivos.

Por padrão, no Exchange 2010, a comunicação SMTP é protegida usando-se TLS.

Comunicação SMTP entre servidores Transporte de Hub   Os servidores Transporte de Hub em uma organização do Exchange usam TLS para ajudar a proteger a comunicação SMTP dentro da organização. Recomendamos que você mantenha o protocolo TLS habilitado em servidores Transporte de Hub. No Exchange 2010, as organizações que usam dispositivos ou aplicativos que não sejam do Exchange na realização da criptografia TLS podem descarregar TLS a partir de servidores Transporte de Hub nesses dispositivos. Para mais detalhes, consulte Desabilitando TLS entre sites do Active Directory para otimização de WAN de suporte.

Comunicação SMTP entre servidores Transporte de Hub e Transporte de Borda   Todo o tráfego entre servidores Transporte de Hub e Transporte de Borda é autenticado e criptografado. O mecanismo subjacente de autenticação e criptografia é TLS mútuo. Em vez de usar a validação de X.509 para validar certificados, o Exchange 2010 usa a confiança direta para autenticar os certificados. Confiança direta significa que a presença do certificado no Active Directory ou no Active Directory Lightweight Directory Services (AD LDS) valida o certificado. O Active Directory é considerado um mecanismo de armazenamento confiável. Quando a confiança direta é usada, não importa se o certificado é autoassinado ou assinado por uma autoridade de certificação (CA). Quando você inscreve um servidor Transporte de Hub em um local do Active Directory, a Inscrição de Borda publica o certificado do servidor Transporte de Borda no Active Directory. Os servidores Transporte de Borda consideram o certificado publicado válido. O serviço EdgeSync do Microsoft atualiza AD LDS em servidores Transporte de Borda que tenham certificados de servidor Transporte de Hub, considerados válidos pelo servidor Transporte de Borda.

Comunicação SMTP entre servidores Transporte de Borda e hosts externos   No Exchange 2010, a comunicação SMTP entre servidores Transporte de Borda e hosts externos anônimos é protegida, por padrão, usando-se TLS oportunista. Você não precisa de um certificado emitido por uma CA confiável e nenhuma etapa de configuração é necessária. Os conectores de recebimento oferecem negociação TLS para conexões SMTP de entrada. Os conectores de envio também tentam a negociação TLS para todas as conexões SMTP de saída. O TLS oportunista não realiza a validação de certificado, o que permite o uso de certificados autoassinados. Para detalhes, consulte Funcionalidade TLS e terminologia relacionada do Exchange 2010.

Dica

Por padrão, os servidores Transporte de Hub não podem se comunicar com hosts SMTP externos porque não há nenhum conector de recebimento em servidores Transporte de Hub que permita a comunicação de hosts anônimos. É possível configurar servidores Transporte de Hub para se comunicarem com hosts anônimos. Para detalhes, consulte Configurar o Fluxo de Mensagens da Internet Diretamente por meio de um Servidor de Transporte de Hub. Não recomendamos essa topologia porque ela aumenta os riscos de segurança ao expor à Internet o servidor Exchange 2010 e todas as funções instaladas nele. Recomendamos implementar um gateway SMTP baseado em rede de perímetro, como o servidor de Transporte de Borda.

Comunicação SMTP entre servidores Transporte de Hub ou de Borda e hosts inteligentes   No Exchange 2010, é possível configurar um conector de envio a fim de rotear email para domínios remotos, inclusive Internet mail, até um gateway SMTP normalmente residente na rede de perímetro. Embora seja possível criar um conector de envio para rotear um email para um host inteligente sem usar nenhuma autenticação, recomendamos que você use uma autenticação apropriada a esses conectores. Se você usar autenticação Básica, recomendaremos usar autenticação Básica em TLS. Se você selecionar a opção protegida externamente, será pressuposto que a autenticação seja realizada usando-se um mecanismo que não seja do Exchange como IPsec. Ao configurar o conector com o endereço de um host inteligente, você pode usar o endereço IP do host inteligente ou seu fqdn. Recomendamos o uso do endereço IP do host inteligente porque ele oferece proteção contra o envenenamento DNS, em comparação com a praticidade de usar o FQDN.

Usando segurança de domínio para comunicação SMTP com parceiros    No Exchange 2010, é possível usar Segurança de Domínio para ajudar a proteger os caminhos de comunicação da mensagem com domínios de parceiro. A Segurança de Domínio usa TLS mútuo para fornecer criptografia baseada em sessão e autenticação. Para autenticação TLS mútua, os hosts de origem e de destino verificam a conexão realizando a validação do certificado X.509. Os servidores de transporte que se comunicam com domínios de parceiro configurados para Segurança de Domínio exigem um certificado assinado por um terceiro confiável ou uma autoridade de certificação interna. Se você estiver usando uma CA interna, a lista de certificados revogados (CRL) deverá ser publicada e alcançável pelo host de parceiro. Para obter informações detalhadas, consulte os seguintes tópicos:

O Exchange 2010 usa a porta SMTP padrão (porta TCP 25) para a comunicação SMTP. A Instalação do Exchange cria as regras de firewall obrigatórias no Firewall do Windows com Segurança Avançada para permitir a comunicação em portas padrão. Se você especificar uma porta diferente para um conector, o Exchange não modificará regras de firewall ou criará automaticamente uma nova regra para permitir a comunicação por uma porta não padrão. Você deve modificar manualmente a configuração do firewall para permitir a comunicação em portas não padrão. Quando você configura um conector de recebimento para uma porta não padrão, os clientes SMTP que enviam mensagens para o conector também devem ser configurados para usar a porta não padrão.

No Exchange 2010, é possível localizar a função de servidor Transporte de Hub em um servidor Caixa de Correio do Exchange 2010. Isso inclui um servidor Caixa de Correio membro de um grupo de disponibilidade do banco de dados (DAG). Recomendamos que você não localize a função de servidor Transporte de Hub em um servidor Caixa de Correio, especialmente em topologias nas quais nenhum servidor Transporte de Borda seja implantado, para isolar servidores Caixa de Correio da Internet. É possível localizar a função de servidor Transporte de Hub em servidores de acesso do cliente. Você deve seguir as diretrizes de dimensionamento para cada função de servidor ao colocar funções de servidor no mesmo servidor.

Ao especificar um host inteligente para um conector de saída em um servidor Transporte de Hub ou Transporte de Borda, recomendamos que você use endereços IP em lugar do nome de domínio totalmente qualificado (FQDN) de um host inteligente para se proteger do envenenamento e da falsificação do DNS. Isso também minimiza o efeito de qualquer interrupção de DNS na infraestrutura de transporte. Os servidores DNS usados em redes de perímetros só devem ser usados na resolução de saída. Os servidores DNS do perímetro podem conter registros para servidores Transporte de Hub. Também é possível usar arquivos de hosts em servidores Transporte de Borda para evitar a criação de registros para servidores Transporte de Hub em servidores DNS localizados em redes de perímetro.

Além das etapas abordadas nesta seção, você também deve considerar o uso de restrições quanto ao tamanho da mensagem suficiente em conectores, além de configurações de limitação de mensagem sem servidores de transporte. Para obter mais detalhes, consulte os seguintes tópicos:

Considerações de unificação de mensagens

Ao se planejar para implantar uma função de servidor Unificação de Mensagens (UM), você deve considerar os canais de comunicação diferentes usados na comunicação com gateways IP ou IP PBX.

Por padrão, quando você criar um plano de discagem de UM, ele executa sua comunicação em modo não seguro. Além disso, os servidores Unificação de Mensagens associados ao plano de discagem UM irão enviar e receber dados de gateways IP, PBXs IP e outros computadores do Exchange 2010 não usando nenhuma criptografia. No modo não seguro, tanto o canal de mídia RTP (Protocolo de Transporte em Tempo Real) e as informações de sinalização SIP não são criptografadas.

Você pode configurar um servidor de Unificação de Mensagens para usar TLS mútuo para criptografar o tráfego SIP e RTP que é enviado e recebido de outros dispositivos e servidores. Ao adicionar um servidor de Unificação de Mensagens em um plano de discagem da UM e configurar o plano de discagem para usar o modo SIP seguro, apenas o tráfego de sinalização SIP será criptografado e os canais de mídia de RTP continuarão a usar TCP. O TCP não é criptografado. Entretanto, se você adicionar um servidor de Unificação de Mensagens a um plano de discagem da UM e configurar o plano de discagem para usar modo seguro, o tráfego de sinalização SIP e os canais de mídia de RTP serão criptografados. Um canal de mídia de sinalização seguro que usa o SRTP (Protocolo de Transporte em Tempo Real Seguro) usa também TLS mútua para criptografar os dados VoIP.

Se o gateway IP ou o PBX IP usado oferecer suporte a IPSec, também será possível usar IPSec para ajudar a proteger a comunicação entre um servidor UM e o gateway IP ou PBX IP.

Para mais detalhes, consulte Noções Básicas Sobre a Segurança VoIP da Unificação de Mensagens.

O UM também envia mensagens como notificações de chamada perdida e mensagens de correio de voz para servidores Transporte de Hub. Por padrão, essa comunicação ocorre em SMTP que utiliza a criptografia TLS.

É possível configurar uma política de caixa de correio UM para acesso com menos PIN. Isso permite que um chamador acesso correio de voz sem precisar inserir um PIN, com base no ID de Chamador da chamada. A falsificação do ID de Chamador é insignificante. Também recomendamos que você não habilite acesso com menos PIN ao correio de voz. Além disso, recomendamos que você revise as configurações de PIN padrão e as defina de acordo com os requisitos de segurança da organização. As configurações a seguir podem ser definidas para uma política de caixa de correio UM usando o cmdlet Set-UMMailboxPolicy.

Parâmetros para controlar o PIN de usuário para acesso ao correio de voz

Parameter Descrição

AllowCommonPatterns

O parâmetro AllowCommonPatterns especifica se PINs óbvios devem ser permitidos. Exemplos de PINs óbvios incluem os subconjuntos do número de telefone ou de números sequenciais ou repetidos. Se esse parâmetro estiver definido como $false, os números sequenciais e repetidos e o sufixo do ramal de caixa de correio são rejeitados. Se definido como $true, apenas o sufixo do ramal de caixa de correio é rejeitado.

AllowPinlessVoiceMailAccess

O parâmetro AllowPinlessVoiceMailAccess especifica se usuários associados à diretiva de caixa de correio do UM são necessárias para usar um PIN para acessar sua mensagem de voz. Ainda é necessário usar um PIN para acessar o email e o calendário.

Padrão   desabilitado ($false).

LogonFailusresBeforePINReset

O parâmetro LogonFailuresBeforePINReset especifica o número de tentativas sequenciais de logon malsucedidas antes de o PIN da caixa de correio ser automaticamente redefinido. Para desabilitar esse recurso, defina esse parâmetro como Unlimited. Se esse parâmetro não estiver definido como Unlimited, ele deve ser definido como menor que o valor do parâmetro MaxLogonAttempts. O intervalo varia de 0 a 999.

Padrão   5 falhas.

MaxLogonAttempts

O parâmetro MaxLogonAttempts especifica o número de vezes que usuários possam tentar fazer logon sem êxito, em sequência, antes de a caixa de correio do UM ser bloqueada. O intervalo varia de 1 a 999.

Padrão   15 tentativas.

MinPINLength

O parâmetro MinPINLength especifica o número mínimo de dígitos necessários em um PIN para usuários habilitados para UM. O intervalo varia de 4 a 24.

Padrão   6 dígitos

PINHistoryCount

O parâmetro PINHistoryCount especifica o número de PINs anteriores que são lembrados e não são permitidos durante uma redefinição de PIN. Esse número inclui a primeira vez em que o PIN foi definido. O intervalo varia de 1 a 20.

Padrão   5 PINs

PINLifetime

O parâmetro PINLifetime especifica o número de dias até que uma nova senha seja exigida. O intervalo é de 1 a 999. Se você especificar Unlimited, o PIN do usuário não expirará.

Padrão   60 dias

No Exchange 2010, as mensagens de correio de voz podem ser marcadas como protegidas. As mensagens do correio de voz são protegidas usando-se o Gerenciamento de Direitos de Informação (IRM). É possível definir as configurações de proteção do correio de voz determinando o parâmetro a seguir em uma política da caixa de correio UM. Para obter mais detalhes, consulte os seguintes tópicos:

Parâmetros de correio de voz protegidos

Parameter Descrição

ProtectAuthenticatedVoicemail

O parâmetro ProtectAuthenticatedVoiceMail especifica se os servidores de Unificação de Mensagens que atende as chamadas de Acesso de Voz do Outlook para usuários habilitados para UM associados à diretiva de caixa de correio do UM criarem mensagens de email protegidas. Se o valor é definido como Private, apenas mensagens marcadas como privadas são protegidas. Se o valor é definido como All, todas as mensagem de correio de voz são protegidas.

Padrão   Nenhum (Nenhuma proteção é aplicada a mensagens de correio de voz)

ProtectUnauthenticatedVoiceMail

O parâmetro ProtectUnauthenticatedVoiceMail especifica se os servidores de Unificação de Mensagens que atende as chamadas para usuários habilitados para UM associados à diretiva de caixa de correio do UM criarem mensagens de voz protegidas. Isto também se aplica quando uma mensagem é enviada de um atendedor automático de UM para um usuário habilitado para UM associado à diretiva de caixa de correio do UM. Se o valor é definido como Private, apenas mensagens marcadas como privadas são protegidas. Se o valor é definido como All, todas as mensagem de correio de voz são protegidas.

Padrão   Nenhum (Nenhuma proteção é aplicada a mensagens de correio de voz)

RequireProtectedPlayOnPhone

O parâmetro RequireProtectedPlayOnPhone especifica se usuários associados à diretiva de caixa de correio do UM podem apenas usar o recurso Tocar no Telefone para mensagens de voz protegidas ou se os usuários podem usar software multimídia para tocar a mensagem protegida.

Padrão   $false. Os usuários podem usar ambos os métodos para ouvir as mensagens de voz protegidas.

Importante

Para servidores UM continuarem atendendo chamadas, é fundamental que eles tenham acesso ao Active Directory. Recomendamos que você monitore a disponibilidade do Active Directory

Apêndice 1: Documentação adicional relacionada à segurança

Esta seção contém links para outros documentos do Exchange relacionados à segurança.

Funcionalidade anti-spam e antivírus

Certificados

Autenticação de cliente e segurança

Outlook Web App

Outlook Anywhere

POP3 e IMAP

Permissions

Protegendo o fluxo de mensagens

Diretiva e conformidade de mensagens

Federação

 © 2010 Microsoft Corporation. Todos os direitos reservados.