Segurança do IIS
Este tópico descreve como o Microsoft SQL Server Compact 3.5 utiliza os seguintes recursos:
Autenticação do IIS
Autorização do IIS
Criptografia do IIS
Autenticação do IIS
Ao configurar o Agente de Servidor do SQL Server Compact 3.5, você especifica se os clientes devem executar a autenticação dos Serviços de Informações da Internet (IIS) da Microsoft ao se conectarem ao Agente de Servidor do SQL Server Compact 3.5. Há três formas de autenticação do IIS:
Acesso anônimo
Autenticação básica
Autenticação integrada do Windows
A expectativa é que a maioria dos aplicativos de Internet usarão a autenticação Básica e a criptografia SSL (protocolo SSL).
Acesso anônimo
Com o acesso Anônimo, o IIS não executa autenticação de cliente. Todo o trabalho do Agente de Servidor do SQL Server Compact 3.5 em benefício do cliente é executado com a identidade da Conta de convidado da Internet. Por padrão, essa conta é IUSR_nome_do_computador, mas é possível designar outra conta de usuário do Windows como a Conta de convidado da Internet.
Autenticação básica
Com a autenticação Básica, o cliente do SQL Server Compact 3.5 deve fornecer um nome de usuário e uma senha de conta do Windows. O IIS tenta fazer logon usando esses dados fornecidos pelo cliente. Se a tentativa de logon for bem-sucedida, todo o trabalho do Agente de Servidor do SQL Server Compact 3.5 será executado com a identidade da conta de usuário do Windows especificada. Se a tentativa de logon falhar, a solicitação do cliente será rejeitada. A autenticação básica pode ser usada para aplicativos de Internet e de intranet. Na autenticação Básica, cada cliente deve ter uma conta do Windows válida com nome de usuário e senha válidos.
Importante
Por padrão, a autenticação Básica passa o nome do usuário e a senha através da rede com codificação base64. Isso pode representar um risco à segurança, caso alguém espione a troca de senha, pois a codificação base64 pode ser facilmente decodificada. Para proteger a senha do usuário, a criptografia SSL (protocolo SSL) sempre deve ser utilizada quando a autenticação Básica for usada. Para obter mais informações, consulte Configurando a Criptografia SSL.
Autenticação integrada do Windows
A autenticação integrada do Windows funciona de forma muito semelhante à autenticação Básica. O cliente do SQL Server Compact 3.5 deve fornecer um nome de usuário e uma senha de conta do Windows válida. O IIS tenta fazer logon usando esses dados. Se a tentativa de logon for bem-sucedida, todo o trabalho do Agente de Servidor do SQL Server Compact 3.5 será executado com a identidade da conta de usuário do Windows. Se a tentativa de logon falhar, a solicitação de sincronização do cliente será rejeitada. Vantagem da Autenticação integrada do Windows em relação à autenticação Básica: ao contrário da autenticação Básica, a Autenticação integrada do Windows não transmite o nome de usuário e a senha do cliente através da rede na forma não-criptografada. Isso evita o risco de interceptação da senha. A autenticação integrada do Windows é mais adequada aos aplicativos de intranet. A Autenticação integrada do Windows é usada raramente para aplicativos de Internet, pois não pode operar através de um servidor proxy ou de um firewall.
Observação
Como o Microsoft Windows CE 4.2 não dá suporte para a Autenticação Digest, as soluções de conectividade do SQL Server Compact 3.5 não dão suporte para essa forma de autenticação.
Autorização do IIS
Após a autenticação do cliente do IIS, a autorização do IIS determina se o cliente pode invocar o Agente de Servidor do SQL Server Compact 3.5. Você controla quem pode executar a conectividade do SQL Server Compact 3.5 controlando os clientes que têm acesso ao Agente de Servidor do SQL Server Compact 3.5.
Mecanismos do IIS para controlar o acesso:
O IIS primeiro verifica o endereço do cliente quanto às restrições de endereço IP configuradas. Você pode configurar o servidor Web para evitar que computadores, grupos de computadores ou redes inteiras específicos acessem o Agente de Servidor do SQL Server Compact 3.5. Quando um cliente tenta inicialmente acessar o Agente de Servidor do SQL Server Compact 3.5, o IIS verifica o endereço IP do computador cliente quanto às configurações de restrição de endereço IP no servidor. Se for negado acesso ao endereço IP, a solicitação de sincronização do cliente será rejeitada com a mensagem: "403 Acesso Proibido".
Se o IIS estiver configurado para requerer autenticação, ele verificará se o cliente possui uma conta de usuário do Windows válida, conforme descrito na seção Autenticação do IIS deste documento. Se a conta do usuário não for válida, a solicitação de sincronização do cliente será rejeitada com a mensagem: "403 Acesso Proibido".
Em seguida, o IIS verifica as permissões da Web. Essa verificação de segurança do IIS não é relevante para as soluções de conectividade do SQL Server Compact 3.5.
O IIS então verifica as permissões NTFS do Agente de Servidor do SQL Server Compact 3.5, para garantir que o usuário que está se conectando tenha as permissões adequadas.
Observação
Embora o IIS também possa ser usado com um sistema de arquivos FAT (tabela de alocação de arquivos), é altamente recomendável usar NTFS. O NTFS permite usar ACLs (listas de controle de acesso) para conceder ou negar acesso ao Agente de Servidor do SQL Server Compact 3.5 e aos arquivos de mensagens de entrada e de saída no sistema IIS.
Criptografia do IIS
Ao configurar o Agente de Servidor do SQL Server Compact 3.5, você pode especificar a criptografia SSL. Quando essa criptografia é especificada, toda a comunicação entre o Agente de Cliente do SQL Server Compact 3.5 e o Agente de Servidor do SQL Server Compact 3.5 é criptografada. Para obter mais informações, consulte Configurando a criptografia SSL.
Você deve usar criptografia SSL nestas situações:
Se você configurar o IIS para usar autenticação Básica.
Isso é essencial para proteger a senha da Internet do usuário. Por padrão, a autenticação Básica transmite o nome do usuário e a senha através da rede com a codificação base64. Isso pode representar um risco à segurança, caso alguém espione a troca de senha, pois a codificação base64 pode ser facilmente decodificada. A criptografia SSL sempre deve ser usada quando a autenticação Básica é usada, para proteger a senha da Internet do usuário.
Somente para RDA: se o aplicativo especificar um parâmetro OLEDBConnectionString que contenha uma senha.
Os métodos RDA Pull, Push e SubmitSQL requerem um parâmetro OLEDBConnectionString. Essa cadeia de conexão é passada através da rede na forma de texto não criptografado. Isso pode representar um risco à segurança se alguém espionar a troca de senha.
Somente para replicação: se o Editor ou o Distribuidor do SQL Server usar Autenticação do SQL Server.
O Distribuidor estará usando Autenticação do SQL Server se a propriedade DistributorSecurityMode especificar DB_AUTHENTICATION. O Editor estará usando Autenticação do SQL Server se a propriedade PublisherSecurityMode especificar DB_AUTHENTICATION. Quando a Autenticação do SQL Server é usada, a DistributorPassword e a PublisherPassword são passadas através da rede na forma de texto não criptografado. Isso pode representar um risco à segurança se alguém espionar a troca de senha. A criptografia SSL sempre deve ser usada quando a Autenticação do SQL Server for usada para proteger a DistributorPassword e a PublisherPassword.