Criando Componentes de Serviço Seguros

Nesta página

	Neste módulo
	Objetivos
	Aplicação
	Como usar este módulo
	Visão geral
	Ameaças e contramedidas
	Considerações sobre o projeto
	Autenticação
	Autorização
	Gerenciamento de configuração
	Dados confidenciais
	Auditoria e log
	Criar um componente de serviço seguro
	Considerações sobre a segurança de acesso ao código
	Considerações sobre a implantação
	Resumo
	Recursos adicionais

Neste módulo

Os componentes de serviço são serviços de infra–estrutura COM+, também conhecidos como Serviços Corporativos. Eles podem ser acessados a partir do código gerenciado e são compostos de uma ou mais classes gerenciadas, derivadas de System.EnterpriseServices.ServicedComponent.

Este módulo explica como a segurança dos Serviços Corporativos (COM+) depende da segurança do Windows para autenticar e autorizar os chamadores, e também como técnicas de codificação sólidas e configuração de catálogo adequada podem garantir a implantação segura dos componentes de serviço.

Este módulo foi criado para o desenvolvedor e também contém exemplos sobre como criar componentes de serviço seguros.

Início da página

Objetivos

Use este módulo para:

Início da página

Aplicação

Este módulo aplica–se aos produtos e tecnologias a seguir:

Início da página

Como usar este módulo

Para aproveitar ao máximo este módulo:

Início da página

Visão geral

Os serviços de infra–estrutura COM+, também conhecidos como Serviços Corporativos, podem ser acessados a partir do código gerenciado. Os aplicativos dos Serviços Corporativos são compostos de um ou mais componentes de serviço, os quais são classes gerenciadas, derivadas de System.EnterpriseServices.ServicedComponent.

Os componentes de serviço, normalmente usados para encapsular a lógica de negócios e de acesso a dados por parte de um aplicativo, são utilizados quando os serviços de infra–estrutura, como transações distribuídas, agrupamento de objetos, componentes enfileirados, entre outros, são solicitados na camada intermediária de um aplicativo. Os aplicativos dos Serviços Corporativos geralmente residem nos servidores de aplicativos da camada intermediária como mostra a Figura 11.1.

Figura 11.1
Componentes de serviço em um aplicativo dos Serviços Corporativos da camada intermediária

Início da página

Ameaças e contramedidas

As principais ameaças que deverão ser solucionadas ao serem criados os componentes de serviço são:

A Figura 11.2 realça essas principais ameaças juntamente com as vulnerabilidades comuns dos componentes de serviço.

Figura 11.2
Ameaças aos Serviços Corporativos

Espionagem na rede

Os aplicativos dos Serviços Corporativos geralmente são executados em servidores de aplicativos da camada intermediária, que são remotos em relação ao servidor Web. Conseqüentemente, os dados de aplicativo confidenciais devem ser protegidos contra espionagens na rede. Você pode usar um canal IPSec (Internet Protocol Security) criptografado entre o servidor Web e o de aplicativos. Essa solução costuma ser usada em centros de dados da Internet. Os componentes de serviço podem também oferecer suporte à autenticação no nível do pacote RPC (Chamada de Procedimento Remoto), que conta com criptografia baseada em pacote. Isso é geralmente usado para proteger a comunicação de envio e recepção de clientes desktop.

Acesso não autorizado

Ao ativar uma autorização baseada em função COM+ (ela é desativada por padrão no Microsoft Windows 2000), é possível evitar o acesso anônimo e oferecer autorização baseada em função para controlar o acesso às operações restritas, expostas pelos componentes de serviço.

Delegação irrestrita

Se for ativada uma delegação no Windows 2000 para permitir que um servidor remoto acesse os recursos da rede usando o identificador que representa o cliente, a delegação será irrestrita. Isso significa que não existem limites para o número de saltos de rede que podem ser efetuados. O Microsoft Windows Server 2003 introduz delegação restrita.

Divulgação de dados de configuração

Muitos aplicativos armazenam dados confidenciais como strings de conexão de banco de dados no catálogo COM+, usando strings de construtor de objetos. Essas strings são recuperadas e passadas para um objeto pelo COM+ quando o objeto é criado. Os dados com configuração confidencial devem ser criptografados antes da armazenagem no catálogo.

Repúdio

A ameaça de repúdio surge quando um usuário se nega a efetuar uma operação ou uma transação e não há como obrigá–lo a fazê–lo por falta de provas. A auditoria deve ser efetuada por todas as camadas do aplicativo. Os componentes de serviço devem fazer log de atividade do usuário na camada intermediária. Os componentes de serviço geralmente têm acesso à identidade original do chamador, pois os aplicativos da Web front–end costumam ativar a representação em ambientes dos Serviços Corporativos.

Início da página

Considerações sobre o projeto

Antes de iniciar a gravação do código, existem várias questões importantes que devem ser consideradas no momento em que for feito o projeto. As principais considerações são:

Autorização baseada em função

Para obter uma autorização eficaz baseada em função usando funções COM+, certifique–se de que o contexto de segurança do chamador original seja usado para a chamada do componente de serviço. Isso permite efetuar a autorização de função granular baseada na participação do grupo do chamador. Se um aplicativo da Web ASP.NET chamar seus componentes de serviço, isso significa que o aplicativo da Web precisa representar os seus próprios chamadores antes de chamar seu componente.

Proteção de dados confidenciais

Se seus componentes de serviço lidarem com dados confidenciais, como detalhes sobre funcionários, transações financeiras e históricos médicos, pense em como proteger os dados enquanto eles percorrem a rede. Se o aplicativo não estiver sendo executado em um IDC (Internet Data Center) protegido, onde o IPSec fornece criptografia no nível do transporte, uma opção alternativa é usar criptografia RPC. Para isso, é preciso usar a autenticação da Privacidade do pacote. Para obter mais informações, consulte a seção "Dados confidenciais" mais adiante neste módulo.

Requisitos da auditoria

Para solucionar a ameaça de repúdio, as transações confidenciais efetuadas pelos componentes de Serviços Corporativos devem ser registradas. Durante o projeto, considere o tipo das operações que devem ser auditadas e os detalhes que devem ser registrados. No mínimo, isso deve incluir a identidade que iniciou a transação e a identidade usada para efetuar a transação, que pode ou não ser a mesma.

Tipo de ativação de aplicativo

Durante o projeto, decida como seu componente de serviço será ativado. Você pode ativá–lo usando uma instância do processo Dllhost.exe ou executá–lo no processo de cliente. Os aplicativos do servidor são executados fora do processo numa instância Dllhost.exe. Os aplicativos de biblioteca são executados no espaço de endereço do processo de cliente. Os aplicativos de biblioteca são mais eficientes devido à falta de comunicação entre processos. Porém, eles são menos configuráveis e não são protegidos com o isolamento no nível do processo. Muitas configurações de segurança, como as de autenticação e de representação, são herdadas do processo de cliente.

Transações

Se você pretende usar transações distribuídas, pense em onde se inicia a transação e nas implicações envolvidas na execução de transações entre componentes e gerenciadores de recursos separados por firewalls. Nesse caso, o firewall deve ser configurado para oferecer suporte ao tráfego Microsoft DTC (Coordenador de Transações Distribuídas).

Caso sua arquitetura de implantação física inclua um servidor de aplicativo da camada intermediária, é melhor iniciar as transações a partir do aplicativo dos Serviços Corporativos no servidor de aplicativos e não do aplicativo da Web front–end.

Segurança de acesso ao código

Normalmente, os aplicativos que usam componentes de serviço são totalmente confiáveis e, por isso, a segurança de acesso ao código tem uso limitado para autorizar o código de chamada. No entanto, os Serviços Corporativos requerem que o código de chamada tenha a permissão necessária para chamar o código não gerenciado. A principal implicação disso é que você não poderá chamar diretamente um aplicativo dos Serviços Corporativos a partir de um aplicativo da Web parcialmente confiável. Os níveis de confiança parciais do ASP.NET (Alto, Médio, Baixo e Mínimo) não concedem a permissão de código não gerenciado. Se você precisar chamar um componente de serviço a partir de um aplicativo parcialmente confiável, o código privilegiado que chama seu componente deve estar no modo seguro. Para obter mais informações, consulte "Considerações sobre a segurança de acesso ao código" mais adiante neste módulo.

Início da página

Autenticação

Os aplicativos dos Serviços Corporativos usam a autenticação do Windows. Ela pode ser a autenticação NTLM ou Kerberos, dependendo do sistema operacional do cliente e do servidor. Em ambientes Windows 2000 ou Windows Server 2003, é usada a autenticação Kerberos.

A principal questão que deve ser considerada ao criar componentes de serviço é certificar–se de que as chamadas sejam autenticadas para evitar que usuários anônimos acessem a funcionalidade de seu componente.

Use (pelo menos) autenticação no nível de chamada

Para rejeitar chamadores anônimos, use pelo menos autenticação no nível de chamada. Configure essa definição adicionando o seguinte atributo ao conjunto do componente de serviço:

[assembly: ApplicationAccessControl( 
                Authentication = AuthenticationOption Call)] 

Observação: isso equivale a configurar o Nível de autenticação para chamadas como Chamada na guia Segurança da caixa de diálogo Propriedades do aplicativo em Serviços de componentes.

Início da página

Autorização

Os Serviços Corporativos usam funções COM+ para autorização. É possível controlar a granularidade da autorização em aplicativos, componentes, interfaces e métodos. Para evitar que os usuários efetuem operações restritas, expostas pelos componentes de serviço de seu aplicativo, será preciso:

Ativar a segurança baseada em função

No Windows 2000, a segurança baseada em função é desativada por padrão. Ocorre o inverso no Windows Server 2003. Para certificar–se de que a segurança baseada em função seja automaticamente desativada quando o seu componente for registrado, adicione o seguinte atributo ao conjunto de seu componente de serviço.

[assembly: ApplicationAccessControl(true)] 

Observação: usar este atributo equivale a selecionar Aplicar verificações de acesso para este aplicativo na guia Segurança da caixa de diálogo Propriedades do aplicativo em Serviços de componentes.

Ativar verificações de acesso no nível do componente

As verificações de acesso no nível do componente devem ser ativadas para oferecer suporte a verificações de função no componente, na interface ou no método. Para certificar–se de que as verificações de acesso no nível do componente são automaticamente ativadas quando o seu componente é registrado, adicione os seguintes atributos ao conjunto do componente de serviço.

[assembly: ApplicationAccessControl(AccessChecksLevel=  
               AccessChecksLevelOption.ApplicationComponent)] 

Observação: usar este atributo equivale a selecionar Efetuar verificações de acesso nos níveis de processo e de componente na guia Segurança da caixa de diálogo Propriedades do aplicativo em Serviços de componentes.

Ativar verificações de acesso no nível do componente

Para permitir que os componentes individuais efetuem verificações de acesso, é preciso ativar as verificações de acesso no nível do componente. Essa configuração só será eficaz se o nível de segurança de todo o aplicativo for definido para o processo e o componente conforme descrito acima. Para certificar–se de que as verificações de acesso no nível do componente sejam automaticamente ativadas quando o componente for registrado, adicione os seguintes atributos às classes do componente de serviço.

[ComponentAccessControl(true)] 
public class YourServicedComponent : ServicedComponent 
{ 
} 

Observação: usar este atributo equivale a selecionar Aplicar verificações de acesso no nível do componente na guia Segurança da caixa de diálogo Propriedades do componente em Serviços de componentes.

Início da página

Gerenciamento de configuração

Além das definições configuráveis oferecidas pelo COM+ aos administradores por meio da ferramenta Serviços de componentes, os desenvolvedores geralmente executam funções relacionadas a configuração no código. Por exemplo, as funções podem recuperar strings de construção de objeto armazenadas no catálogo COM+. Ao usar o gerenciamento de configuração com os Serviços Corporativos, considere as principais questões a seguir:

Usar contas de execução com menos privilégios

Durante o desenvolvimento, execute e teste seus componentes de serviço, usando uma conta com menos privilégios em vez da conta de usuário interativo. Configure a conta de modo que ela tenha o maior número de detalhes possível e possa corresponder à conta de execução que provavelmente será usada pelo administrador no ambiente de produção.

Evitar o armazenamento de segredos em strings de construtor de objetos

Se você armazenar segredos, como strings de conexão de banco de dados ou senhas em strings de construtor de objetos no catálogo COM+, qualquer membro do grupo de administradores local poderá exibir esses dados em texto sem formatação. Tente evitar o armazenamento de segredos. Se for preciso armazenar um segredo, criptografe os dados. A DPAPI é uma boa opção de implementação, pois permite evitar problemas associados ao gerenciamento de chaves.

Durante a execução, recupere a string de construção de objeto e use a DPAPI para descriptografar os dados. Para obter mais informações sobre o uso da DPAPI a partir do código gerenciado, consulte "How to create a DPAPI library" no artigo do MSDN, "Building Secure ASP.NET Applications," em http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp (em inglês).

[ConstructionEnabled(Default="")] 
public class YourServicedComponent : ServicedComponent, ISomeInterface 
{ 
  // The object constructor is called first. 
  public YourServicedComponent() {} 
  // Then the object construction string is passed to Construct method. 
  protected override void Construct(string constructString) 
  { 
    // Use DPAPI to decrypt the configuration data. 
  } 
}

Evitar delegação irrestrita

Os clientes de componentes de serviço são autenticados com autenticação NTLM ou Kerberos, dependendo do ambiente. A autenticação Kerberos no Windows 2000 oferece suporte a delegação irrestrita; isso significa que o número de saltos de rede que podem ser efetuados com as credenciais do cliente é ilimitado.

Se o ASP.NET for o cliente, será preciso configurar o atributo comImpersonation no elemento <processModel> no Machin.config para.configurar o nível de representação:

comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]" 

O nível de representação definido para um aplicativo do servidor dos Serviços Corporativos determina a capacidade de representação de qualquer servidor remoto com o qual os componentes de serviço se comunicam. Nesse caso, os componentes de serviço são os clientes. Você pode especificar o nível de representação de um componente de serviço, o qual é aplicado quando o componente de serviço é o cliente, usando o atributo a seguir:

[assembly: ApplicationAccessControl( 
                ImpersonationLevel=ImpersonationLevelOption.Identify)] 

Observação: usar este atributo equivale a configurar o valor Nível de representação na página Segurança da caixa de diálogo Propriedades do aplicativo em Serviços de componentes.

A tabela a seguir descreve o efeito de cada um desses níveis de representação:

Tabela 11.1: Níveis de representação

Para obter mais informações consulte "Representação", "Protegendo seu Servidor de Aplicativo" e "How to Enable Kerberos Delegation in Windows 2000" na seção References do artigo do MSDN, "Building Secure ASP.NET Applications," em http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp (em inglês).

Início da página

Dados confidenciais

Se seu aplicativo transmitir dados confidenciais para um componente de serviço ou a partir dele por meio de uma rede a fim de solucionar a ameaça de espionagem na rede, os dados devem ser criptografados para garantir que eles continuem inalterados e em sigilo. É preciso usar proteção no transporte com o IPSec ou usar proteção no aplicativo configurando seu aplicativo dos Serviços Corporativos para utilizar o nível de autenticação da privacidade do pacote RPC. Ele criptografa cada pacote de dados enviados para o componente de serviço ou a partir dele a fim de proporcionar privacidade e integridade.

Você pode configurar a autenticação da privacidade do pacote usando a ferramenta Serviços de componentes ou adicionando o seguinte atributo para o conjunto do componente de serviço:

[assembly: ApplicationAccessControl( 
                   Authentication = AuthenticationOption Privacy)] 

Para obter mais informações sobre o uso do IPSec para criptografar todos os dados transmitidos entre dois computadores, consulte "How To: Use IPSec to Provide Secure Communication Between Two Servers" na seção "How To" de "Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication" em http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT00.asp (em inglês).

Início da página

Auditoria e log

A auditoria e o log devem ser executados por meio das camadas de seu aplicativo para evitar ameaças de repúdio potenciais nas quais os usuários negam efetuar certas transações ou operações essenciais.

Auditar transações de usuário

Se seu aplicativo da Web ou Web Service estiver configurado para a representação, a identidade do chamador original será transmitida automaticamente para um aplicativo dos Serviços Corporativos e ficará disponível usando o SecurityCallContext.OriginalCaller. Isso é útil para auditoria na camada intermediária. O código a seguir mostra como acessar essa informação:

[ComponentAccessControl] 
public class YourServicedComponent : ServicedComponent 
{ 
  public void ShowCallers() 
  { 
    SecurityCallers callers = SecurityCallContext.CurrentCall.Callers; 
    foreach(SecurityIdentity id in callers) 
    { 
      LogEvent(id.AccountName); 
    } 
  } 
  private void LogEvent(string message) 
  { 
    try 
    { 
      if (!EventLog.SourceExists(appName)) 
      { 
        EventLog.CreateEventSource(appName, eventLog); 
      } 
      EventLog.WriteEntry(appName, message, EventLogEntryType.Information ); 
    } 
    catch (SecurityException secex) 
    { 
      throw new SecurityException( 
            "Event source does not exist and cannot be created.", secex); 
    } 
  } 
} 

Para gravar com êxito no log de eventos, é preciso haver uma fonte de evento que associa o aplicativo dos Serviços Corporativos a um log de eventos específico. O código acima cria a fonte de evento durante a execução, o que significa que a conta de processo do componente de serviço deve receber as permissões relevantes no registro.

HKLM\SYSTEM\CurrentControlSet\Services\Eventlog 

Uma estratégia alternativa é usar uma classe Instalador e criar a fonte de evento para o aplicativo durante a instalação, quando os privilégios de administrador estão disponíveis. Para obter mais informações sobre essa abordagem, consulte "Auditoria e log" , "Criando Páginas e Controles ASP.NET Seguros."

Início da página

Criar um componente de serviço seguro

Após abordarmos as ameaças e contramedidas que podem ser aplicadas nos aplicativos dos componentes de serviço e dos Serviços Corporativos, passaremos para a implementação. Os fragmentos de código a seguir ilustram as principais características de um componente de serviço protegido para uma implementação de classe Cliente simples. Os detalhes sobre a implementação do método foram omitidos para facilitar a compreensão.

Implementação do conjunto

O seguinte fragmento de código retirado de assemblyinfo.cs mostra os metadados no nível do conjunto usados para configurar o catálogo COM+ quando o conjunto do componente de serviço é registrado nos Serviços Corporativos usando o regsvcs.exe.

// (1) Assembly has a strong name. 
[assembly: AssemblyKeyFile(@"..\..\Customer.snk")] 
// Enterprise Services configuration 
[assembly: ApplicationName("CustomerService")] 
[assembly: Description("Customer Services Application")] 
// (2) Server application - runs in dllhost.exe process instance. 
[assembly: ApplicationActivation(ActivationOption.Server)] 
// (3) Enable component level access checks. 
// (4) Specify call level authentication. 
// (5) Specify Identify impersonation level for downstream calls. 
[assembly: ApplicationAccessControl( 
              AccessChecksLevel=AccessChecksLevelOption.ApplicationComponent, 
              Authentication=AuthenticationOption.Call, 
              ImpersonationLevel=ImpersonationLevelOption.Identify)] 

O código mostrado acima exibe as seguintes características de segurança (identificadas por números na linha de comentário).

Implementação da classe do componente de serviço

O fragmento de código a seguir realça a configuração de segurança de uma classe Cliente parcialmente implementada.

namespace busCustomer 
{ 
  // (1) Explicit interface definition to support method level authorization 
  public interface ICustomerAdmin 
  { 
    void CreditAccountBalance(string customerID, double amount); 
  } 
  // (2) Enforce component level access checks. 
  [ComponentAccessControl] 
  public sealed class Customer : ServicedComponent, ICustomerAdmin 
  { 
    private string appName = "Customer"; 
    private string eventLog = "Application"; 
    // ICustomer implementation 
    // (3) Access to CreditAccountBalance is limited to members of the 
    //     Manager and Senior Manager role. 
    [SecurityRole("Manager")] 
    [SecurityRole("Senior Manager")] 
    public void CreditAccountBalance(string customerID, double amount) 
    { 
      // (4) Structured exception handling to protect implementation. 
      try 
      { 
        // (5) Check that security is enabled. 
        if (ContextUtil.IsSecurityEnabled) 
        { 
          // Only managers can credit accounts with sums of money 
          // in excess of $1,000. 
          if (amount > 1000) { 
            // (6) Programmatic role check to authorize credit operation 
            if (ContextUtil.IsCallerInRole("Senior Manager")) { 
              // Call data access component to update database. 
              . . . 
              // (7) Audit the transaction. 
              AuditTransaction(customerID, amount); 
            } 
            else { 
              throw new SecurityException("Caller not authorized"); 
            } 
          } 
        }  
        else { 
          throw new SecurityException("Security is not enabled"); 
        } 
      } 
      catch( Exception ex) 
      { 
        // Log exception details. 
        throw new Exception("Failed to credit account balance for customer: " + 
                             customerID, ex); 
      } 
    } 
    private void AuditTransaction(string customerID, double amount) 
    { 
      // (8) Original caller identity is obtained from call context for  
      //     logging purposes. 
      SecurityIdentity caller = SecurityCallContext.CurrentCall.OriginalCaller; 
      try 
      { 
        if (!EventLog.SourceExists(appName)) 
        { 
          EventLog.CreateEventSource(appName,eventLog); 
        } 
        StringBuilder logmessage = new StringBuilder(); 
        logmessage.AppendFormat("{0}User {1} performed the following transaction". 
                               + "{2} Account balance for customer {3} " 
                               + "credited by {4}", 
                                Environment.NewLine, caller.AccountName,  
                                Environment.NewLine, customerID, amount); 
        EventLog.WriteEntry(appName, logmessage.ToString(),  
                            EventLogEntryType.Information); 
      } 
      catch(SecurityException secex) 
      { 
        throw new SecurityException( 
                   "Event source does not exist and cannot be created", secex); 
      } 
    } 
  } 
} 

O código mostrado acima exibe as seguintes características de segurança (identificadas por números na linha de comentário):

Início da página

Considerações sobre a segurança de acesso ao código

Os aplicativos que usam componentes de serviço costumam ser totalmente confiáveis, e por isso, a segurança de acesso ao código tem uso limitado para autorizar o código de chamada. O código de chamada deve considerar os seguintes pontos:

<trust level="Full" /> 

Início da página

Considerações sobre a implantação

Os aplicativos dos Serviços Corporativos são normalmente instalados no servidor Web ou em um servidor remoto do aplicativo. A Figura 11.3 mostra os dois casos habituais para a implantação dos Serviços Corporativos sob uma perspectiva de segurança, a notável diferença em relação ao caso da implantação remota é que os dados de envio e recepção que circulam pelo componente de serviço passam pela rede, geralmente por meio de um firewall interno usado para separar as redes internas e de perímetro.

Figura 11.3
Configurações de implantação típicas dos Serviços Corporativos

Os desenvolvedores e administradores devem estar atentos às seguintes questões relacionadas à implantação:

Para obter mais informações sobre a aplicação de configuração segura durante a implantação, consulte, "Protegendo seu Servidor de Aplicativo".

Restrições de Firewall

Se o cliente e o aplicativo dos Serviços Corporativos são separados por um firewall interno, as portas relevantes que oferecem suporte ao DCOM e provavelmente ao DTC (caso seu aplicativo use transações distribuídas) devem estar abertas.

O DCOM usa alocação de porta dinâmica RPC que, por padrão, seleciona aleatoriamente os números de porta acima de 1024. Além disso, a porta 135 é usada pelo mapeador de ponto de extremidade RPC. É possível restringir as portas requisitadas para oferecer suporte ao DCOM no firewall interno de duas maneiras:

Para obter mais informações sobre a definição de intervalos de portas e mapeamento de ponto de extremidade estático, consulte "Considerações sobre firewall", "Protegendo seu Servidor de Aplicativo".

Usando os Web Services

Se abrir portas no firewall interno não for uma opção, você pode introduzir uma camada da fachada dos Web Services na frente dos componentes de serviço no servidor de aplicativos. Isso significa que só será preciso abrir a porta 80 para o tráfego HTTP e especificamente para que as mensagens SOAP (Simple Object Access Protocol) percorram ambas as direções conforme mostrado na Figura 11.4.

Figura 11.4
Usando uma camada da fachada dos Web Services para a comunicação com os Serviços Corporativos utilizando o HTTP

Com essa abordagem, não é possível percorrer o contexto de transação do cliente para o servidor, embora em muitos casos em que sua arquitetura de implantação inclui um servidor de aplicativos da camada intermediária, é aconselhável iniciar as transações no componente de serviço remoto no servidor de aplicativos.

Para obter informações sobre os requisitos de implantação física para agentes de serviço e interfaces de serviço, como a camada da fachada dos Web Services, consulte "Physical Deployment and Operational Requirements" na seção Reference do artigo do MSDN, "Application Architecture for .NET: Designing Applications and Services".

Requisitos do DTC

Se o seu aplicativo usa transações distribuídas COM+ e elas são usadas em servidores remotos separados por um firewall interno, então o firewall deve abrir as portas necessárias para oferecer suporte ao tráfego DTC.

Se sua arquitetura de implantação inclui uma camada de aplicativo remoto, as transações são geralmente iniciadas no aplicativo dos Serviços Corporativos e propagadas ao servidor de banco de dados. Na ausência de um servidor de aplicativos, o aplicativo dos Serviços Corporativos do servidor Web inicia a transação e a propaga ao gerenciador de recursos do SQL Server.

Para obter informações sobre a configuração de firewalls de modo que eles ofereçam suporte ao tráfego DTC, consulte, "Protegendo seu Servidor de Banco de Dados".

Início da página

Resumo

A segurança dos Serviços Corporativos (COM+) depende da segurança do Windows para autenticar e autorizar os chamadores. A autorização é configurada e controlada com funções COM+ que contêm contas de grupo ou de usuário do Windows. A maioria das ameaças relacionadas aos aplicativos dos Serviços Corporativos e componentes de serviço podem ser solucionadas com técnicas de codificação sólidas e configuração de catálogo adequada.

O desenvolvedor deve usar atributos declarativos para definir a configuração de segurança do componente de serviço. Esses atributos determinam como se configura o aplicativo quando ele é registrado inicialmente nos Serviços Corporativos (normalmente usando o Regsvcs.exe).

Nem toda configuração de segurança pode ser definida com atributos. Um administrador deve especificar a identidade de execução para um servidor de aplicativos. Durante a implantação, o administrador deve também preencher funções nas contas de grupo ou de usuário do Windows.

Ao desenvolver componentes de serviço ou avaliar a segurança da sua solução de Serviços Corporativos, use a "Lista de verificação: protegendo os Serviços Corporativos" na seção "Listas de verificação" deste guia.

Início da página

Recursos adicionais

Para obter mais informações, consulte os seguintes recursos:

Início da página