Segurança do LightSwitch

Protegendo o acesso a aplicativos do LightSwitch

Valerie Andersen

Matt Evans
Sheel Shah
Michael Simons

Vamos encarar os fatos: a implementação da segurança para aplicativos pode ser desanimadora. Felizmente, o Visual Studio LightSwitch facilita o gerenciamento do controle de acesso baseado em permissões nos aplicativos LOB (linha de negócios), permitindo que você crie aplicativos com lógica de controle de acesso para atender às necessidades específicas da sua empresa.

Um aplicativo do LightSwitch consiste logicamente em três camadas: apresentação, lógica e armazenamento de dados. Você precisará considerar o acesso a ativos em cada camada para garantir que o nível certo de acesso seja atingido. Com o LightSwitch, é possível criar a lógica de controle de acesso em aplicativos no nível certo. Além disso, o LightSwitch aproveita os princípios básicos do controle de acesso das tecnologias subjacentes e permite a configuração comum do controle de acesso pelo IIS e ASP.NET.

Este artigo examina como o controle de acesso funciona nos aplicativos do LightSwitch. Em primeiro lugar, descreveremos os recursos que o LightSwitch fornece para controle de acesso em uma arquitetura de três camadas. Em seguida, analisaremos rapidamente a implantação relacionada ao controle de acesso e mostraremos algumas maneiras de controlar ainda mais o acesso usando as tecnologias que oferecem suporte ao LightSwitch. Por fim, discutiremos a implantação do controle de acesso em um ambiente do Windows Azure.

Noções básicas do controle de acesso

Existem dois aspectos para o controle de acesso nos aplicativos do LightSwitch. O primeiro é a autenticação, ou como um aplicativo verifica se um usuário é quem diz ser. O segundo é a autorização, que define o quê o usuário tem permissão para fazer ou visualizar no aplicativo.

Autenticação

O processo de autenticação determina se um usuário é quem ele afirma ser. A primeira camada do controle de acesso no LightSwitch exige que os usuários se identifiquem para o aplicativo. Os modos de autenticação com suporte são autenticação do Windows e autenticação de Formulários. Essas opções podem ser configuradas na guia Controle de Acesso das propriedades do seu aplicativo, como pode ser visto na Figura 1.

Figura 1 Definindo permissões no Designer de Aplicativos

A autenticação do Windows é recomendada quando todos os usuários estão em um domínio do Windows e você tem a certeza de que a pessoa que fez logon em um computador é o mesmo usuário que está usando o aplicativo. A autenticação do Windows não exige uma solicitação de logon adicional e o aplicativo não precisa armazenar nem gerenciar senhas fora do Windows. A autenticação do Windows é a opção mais segura, mas geralmente será prática somente se o aplicativo estiver em execução em um ambiente de intranet corporativo com um domínio.

Com a segunda opção, a autenticação de Formulários, é solicitado ao usuário um nome de usuário e uma senha quando o aplicativo é aberto. No LightSwitch, esses valores são verificados, por padrão, em um banco de dados. A autenticação de Formulários funciona perfeitamente para clientes em execução na Internet ou para aqueles que não estejam em um domínio do Windows.

A autenticação de Formulários exige que qualquer usuário que precise de acesso ao aplicativo, primeiramente, seja adicionado ao sistema. A autenticação do Windows também pode funcionar desse modo, mas há uma opção que pode ser definida no tempo de design para permitir que todos os usuários do Windows que podem fazer logon no domínio tenham acesso ao aplicativo, por padrão. Qualquer parte do aplicativo que exija permissões específicas não poderá ser acessada por um usuário do Windows que não tenha sido explicitamente adicionado.

A autenticação permite identificar quem pode ou não usar o aplicativo, e pode ser que todos precisem atender às necessidades de controle de acesso para alguns tipos de aplicativo. Assim que os usuários forem autenticados, você poderá optar por confiar totalmente neles com acesso aos dados. Nesse caso, a implementação do controle de acesso é concluído e não é necessário nenhum código ou permissão adicional. É necessário apenas considerar as opções de IIS discutidas na seção Considerações de implantação para controle de acesso, de modo a proteger seu aplicativo no servidor host.

No entanto, muitos aplicativos exigem controle mais granular do comportamento dos usuários depois que eles tiverem sido autenticados. Nesses casos, você precisará de autorização.

Autorização

O LightSwitch apresenta um sistema de autorização baseado em permissões para desenvolvimento de regras de negócios, conforme mostrado na Figura 2.  

Figura 2 Implementando a autorização no LightSwitch

Você define permissões no designer de aplicativos (veja a Figura 1). Em seguida, escreve o código para verificar se o usuário atual tem as permissões necessárias. Os métodos de controle de acesso podem ser implementados em entidades, consultas e telas, de modo que é possível escrever a lógica com facilidade para determinar se o usuário atual pode exibir ou manipular dados específicos ou abrir uma determinada tela.

O LightSwitch tem uma permissão interna chamada Administração de Segurança e qualquer usuário que receber essa permissão se tornará um administrador de segurança. A permissão Administração de Segurança permite que o usuário conectado acesse as telas de Administração de Segurança no aplicativo cliente LightSwitch em execução, que serão mostradas automaticamente para os usuários que tiverem recebido esse privilégio. O administrador de segurança cria as funções necessárias para o aplicativo e atribui as permissões desejadas a cada função, conforme mostrado na Figura 3. Em seguida, os usuários são criados e atribuídos à função apropriada, conforme mostrado na Figura 4.

Figura 3 Criando funções em tempo de execução

Figura 4 Atribuindo usuários a funções em tempo de execução

Quando um aplicativo é implantado pela primeira vez, um administrador de segurança deve ser adicionado à função Administração de Segurança para habilitar o acesso inicial ao aplicativo. O processo de implantação auxilia na configuração desse usuário padrão adequadamente. Quando um aplicativo implantado estiver em execução, o sistema não permitirá a remoção do último usuário com a permissão de administrador de segurança, de modo a garantir que um administrador de segurança exista o tempo todo.

No entanto, não será preciso implantar o aplicativo para verificar o comportamento adequado da permissão. Ao executar um aplicativo do LightSwitch no modo de depuração, o sistema de função e a autenticação serão executados em um modo especial, no qual o ambiente de desenvolvimento tenta autenticar um usuário de teste especial automaticamente. É possível conceder ou negar as permissões do usuário de teste no designer do LightSwitch usando a coluna “Granted for debug”. Em seguida, o aplicativo será executado no modo de depuração com as permissões selecionadas; assim, será possível testar a lógica de permissão escrita. Isso significa que você pode validar rapidamente se as verificações de permissão são precisas sem precisar configurar vários usuários de teste e funções.

Onde é importante controlar o acesso aos ativos de aplicativo

Agora, vamos considerar o quê proteger e onde protegê-lo. Muitos aplicativos contêm dados confidenciais que precisam ser protegidos contra a exibição, outros dados que precisam apenas ser protegidos contra manipulação e, possivelmente, alguns dados que não precisam de acesso protegido. O primeiro lugar em que se deve pensar quando se trata de proteger os dados deve ser a camada de lógica. Quando os desenvolvedores controlam os dados adequadamente na camada de lógica, a camada de apresentação frequentemente reagirá de modo correto e automático. Por exemplo, se um usuário não tiver recebido a permissão de exclusão para dados do Funcionário, uma grade mostrando os dados do Funcionário terá o botão de exclusão desabilitado. Esses são o poder e a facilidade proporcionados pelo LightSwitch na criação de aplicativos.

A implementação do controle de acesso no nível de dados torna o aplicativo mais seguro e permite que os desenvolvedores aproveitem a inteligência interna. A proteção dos dados somente na camada de apresentação deixa-os expostos na camada de lógica. Um usuário mal-intencionado, autenticado poderia desviar da camada de apresentação e acessar o serviço diretamente para ler ou manipular os dados. Isso está relacionado à arquitetura de três camadas dos aplicativos do LightSwitch e, na verdade, é comum entre os aplicativos de três camadas. A camada de apresentação é responsável por exibir os dados adequadamente; no entanto, esse não é o único meio de um usuário autenticado acessar os dados se os controles de acesso adequados não estiverem implementados na camada de lógica.

Protegendo os dados na camada de lógica

A camada de lógica inclui dois grupos principais de componentes quando você aplica a verificação de permissões: entidades e consultas.

Entidades As entidades são o mecanismo geral para acessar e trabalhar com os dados de aplicativo. Existem quatro ações principais que podem ser executadas com as entidades: ler, inserir, atualizar e excluir. O LightSwitch permite que os desenvolvedores verifiquem as permissões de um usuário conforme execução de cada ação, além de fornecer uma API simples para verificar se o usuário atual tem uma permissão específica definida no aplicativo. O código a seguir mostra um exemplo da verificação de permissões e os vários métodos gate que a API fornece para permitir que um desenvolvedor verifique permissões:

partial void Employee_CanUpdate(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.EmployeeUpdate);
}
 
partial void Employee_CanInsert...
 
partial void Employee_CanRead...
 
partial void Employee_CanDelete...
 
partial void SaveChanges_CanExecute...

Aqui, dois pontos devem ser observados. Em primeiro lugar, esses métodos, com exceção de SaveChanges_CanExecute, são implementados no conjunto de entidades como um todo, e não em instâncias específicas de entidade. Portanto, qualquer verificação executada não pode estar relacionada aos valores de dados em uma instância específica de entidade. O método SaveChanges_CanExecute controla o acesso às alterações em toda a fonte de dados e, desse modo, não pode conter lógica específica da entidade ou do conjunto de entidades. Em segundo lugar, se o método Employee_CanRead retornar false, os métodos Employee_CanUpdate e Employee_CanDelete não serão chamados, uma vez que eles também seriam implicitamente falsos. Um usuário não terá permissão para atualizar nem excluir uma entidade se esta não puder ser lida.

Os métodos “Can” são a maneira básica de definir uma segurança de alta granularidade. Eles oferecem suporte às políticas de controle de acesso aos dados básicos. No entanto, eles apresentam algumas limitações. Quando for necessário controle mais refinado para ler os dados, você poderá implementar a lógica de controle de acesso nas consultas. Para controlar a gravação de dados em um nível mais granular, você deverá usar o Pipeline de Salvamento.

Consultas As consultas também são protegidas na camada de lógica. Cada consulta tem um método que permite controlar o acesso. O LightSwitch gera automaticamente três consultas para cada entidade existente: uma consulta All para retornar todas as instâncias da entidade; e as consultas Single e SingleOrDefault para retornar uma instância de entidade por chave. Cada uma dessas consultas internas tem um método CanExecute que pode ser usado para implementar o controle de acesso:

partial void Employees_All_CanExecute(ref bool result)
{
  result = Application.Current.User.HasPermission(Permissions.QueryEmployees);
}
 
partial void Employees_Single_CanExecute...
partial void Employees_SingleOrDefault_CanExecute...

É importante observar que as consultas do LightSwitch podem ser compostas, o que significa que novas consultas podem ser baseadas em uma consulta existente. Ao aplicar a lógica de controle de acesso em consultas, os requisitos de permissão na consulta inicial servirão como entrada para consultas compostas com base nessa consulta. As consultas Single e SingleOrDefault são compostas com base na consulta All, de modo que proteger a consulta All também protegerá essas consultas se nenhuma permissão for especificada para a consulta derivada. No entanto, se desejar, você poderá especificar permissões na consulta derivada que sejam menos restritivas do que aquelas da consulta de composição. Além disso, o método CanRead no conjunto de entidades será aplicado antes de CanExecute em qualquer consulta desse tipo.

A Figura 5 mostra um exemplo de composição de consulta — se a consulta NorthAmericaEmployees for criada na entidade Employee, essa consulta terá como base a consulta Employee_All interna. Portanto, qualquer lógica de controle de acesso aplicada via Employee_All_CanExecute também será aplicada à consulta NorthAmericaEmployees, pois a consulta NorthAmericaEmployees é baseada na consulta Employee_All, supondo que nenhum código específico seja escrito para a consulta derivada. Se desejar permitir que somente determinados usuários acessem os dados na entidade NorthAmericanEmployees, você poderá fazer uma restrição de maneira específica ou abrir as permissões para essa consulta usando o método NorthAmericaEmployees_CanExecute.

Figura 5 Composição de consulta na entidade Employee

Controlando o acesso entre relacionamentos

Ao trabalhar com consultas entre relacionamentos, é importante entender que as permissões são verificadas nas entidades como relacionamentos, que são percorridos entre entidades relacionadas. Esse é outro motivo da importância das permissões adequadamente definidas nas entidades. Se você precisar proteger os dados contra acesso de leitura por meio de relacionamento, o método CanRead na entidade precisará exigir o nível de permissão correto. Por exemplo, vamos considerar nossa tabela Employee novamente e os dados de compensação relacionados, conforme mostrado no modelo da Figura 6.

Figura 6 Modelo de aplicativo de RH

Ao percorrer o relacionamento entre as tabelas Employee e Compensation através de uma consulta, as permissões nas ações de leitura da entidade serão avaliadas conforme o relacionamento é percorrido, e não as permissões no método Compensation_All_CanExecute. As permissões devem ser definidas corretamente no método CanRead da entidade Compensation, de modo que o nível de permissão correto seja atingido conforme as entidades são percorridas. É preciso estar ciente de que as consultas podem ser usadas para inferir dados quando as entidades não estiverem protegidas. Por exemplo, se você tiver uma consulta que retorne os funcionários mais bem pagos, conforme mostrado na Figura 7, a entidade Compensation que é acessada para retornar dados de Employee precisará estar adequadamente protegida, de modo que somente usuários que tiverem recebido acesso possam obter esses dados por meio da consulta.

Figura 7 Definindo uma consulta para retornar os funcionários mais bem pagos

Fornecendo uma experiência de apresentação personalizada

Depois que os dados estiverem protegidos na camada de lógica, é hora de criar a experiência de usuário na camada de apresentação. Se desejar que um usuário não tenha acesso de jeito nenhum a uma determinada tela, você pode desativar a tela usando o método <ScreenName>_CanRun para o aplicativo. Quando um usuário não tem acesso a uma determinada tela, esta não será mostrada no menu de navegação. Também é possível restringir comandos em uma tela usando o método <CommandName>_CanExecute.

Há vários outros métodos disponíveis nas telas e entidades que podem ser usados para ocultar, mostrar e controlar o estado editável de controles específicos em uma tela, como <EntityProperty>_IsReadOnly, <ScreenControl>.IsEnabled, <ScreenControl>.IsReadOnly e <ScreenControl>.IsVisible. Embora a principal finalidade desses métodos não seja o controle de acesso, eles são bastante úteis no fornecimento da experiência de usuário desejada. Em alguns casos, pode ser melhor ocultar os dados que os usuários não podem manipular; outras vezes, é conveniente mostrar controles somente leitura; e, às vezes, pode ser conveniente orientar os usuários a inserir dados corretamente e mostrar erros significativos casos eles se percam. A camada de apresentação do LightSwitch proporciona toda essa flexibilidade.

É importante ressaltar que fornecer lógica na tela para ocultar, mostrar ou controlar o estado editável de dados não os protege do acesso do usuário; apenas controla como os dados são exibidos. Um usuário mal-intencionado, autenticado poderia acessar o serviço da camada de lógica diretamente para exibir ou manipular os dados, se eles não estiverem protegidos adequadamente. Por isso é essencial implementar o controle de acesso em cada camada de aplicativo adequadamente.

Protegendo os dados na camada de armazenamento

A camada de armazenamento é o local em que seus dados são armazenados em um banco de dados. É possível controlar o acesso aos dados na camada de armazenamento fornecendo um logon de banco de dados com os mínimos privilégios necessários no banco de dados. O aplicativo usa esse logon para conectar-se ao banco de dados e realizar as operações necessárias. Toda a conectividade com os dados é feita por meio da camada intermediária e os usuários finais nunca têm acesso direto aos dados ou à cadeia de conexão em uma implantação de três camadas. Quando você estiver implantando um aplicativo do LightSwitch, será preciso especificar uma cadeia de conexão que o aplicativo usará para acessar os dados, conforme mostrado na Figura 8. Se não houver um logon de banco de dados exclusivo para o aplicativo, o LightSwitch orientará o administrador do aplicativo a criar um. É altamente recomendável que o usuário do banco de dados identificado seja específico ao aplicativo e receba acesso somente para os dados pertinentes usados pelo aplicativo.

Figura 8 Especificando as credenciais de conexão de banco de dados para o aplicativo em execução durante a implantação

Vale a pena mencionar que é possível implantar um aplicativo do LightSwitch seguro com uma implantação de duas camadas. Em uma implantação de duas camadas, a camada de apresentação e a camada de lógica são executadas na área de trabalho do usuário. Essa configuração fornece ao usuário do cliente acesso ao arquivo web.config, onde a cadeia de conexão para o banco de dados é armazenada, portanto, ela não oferece a separação das camadas de apresentação e lógica exigidas para atingir uma configuração de aplicativo seguro. Com a cadeia de conexão, o usuário pode obter acesso direto ao banco de dados e desviar de qualquer lógica de controle de acesso na camada intermediária. Nesse caso, é melhor usar a autenticação do Windows entre a camada intermediária e o banco de dados. Caso contrário, será necessária uma implantação de três camadas para proteger o aplicativo adequadamente.

Considerações de implantação para controle de acesso

Ao implantar um aplicativo do LightSwitch pela primeira vez, é preciso criar um usuário administrativo do LightSwitch. Inicialmente, esse será o único usuário que terá permissões de administrador. Esse usuário será usado para configurar funções e usuários no aplicativo cliente, conforme mencionado anteriormente. Observe que esse usuário será um administrador do seu aplicativo do LightSwitch, mas não precisará ser um administrador do Windows. Um utilitário de linha de comando também está disponível para criar um novo usuário administrativo fora do processo de implantação. Você encontra esse utilitário, Microsoft.LightSwitch.SecurityAdmin.exe, no diretório de instalação do LightSwitch.

Utilizando recursos do controle de acesso no IIS

Agora que falamos sobre a funcionalidade de controle de acesso específica do LightSwitch, vamos analisar rapidamente como um administrador de aplicativo pode proteger manualmente aplicativos do LightSwitch usando as tecnologias de suporte.

LightSwitch e SSL Assim como os navegadores da Web e servidores Web, os clientes e servidores LightSwitch se comunicam usando o protocolo HTTP. O HTTP especifica que os dados sejam enviados em texto não criptografado, o que significa que um interceptador de rede pode monitorar os dados trocados entre clientes e servidores. Para proteger as comunicações contra esses interceptadores de rede, você deve usar o protocolo HTTPS, que oculta os dados normais HTTP em um túnel criptografado.

Os aplicativos do LightSwitch podem ser implantados de modo que esses clientes se comuniquem com o servidor via HTTPS. Isso protege não apenas os dados corporativos confidenciais trocados entre o cliente e o servidor, como também os nomes de usuário e as senhas quando se usa a autenticação de Formulários. Uma prática recomendada é implantar em um site HTTPS ao usar a autenticação de Formulários juntamente com o IIS ou Windows Azure. Caso contrário, é possível que um invasor roube o token de autenticação e represente o usuário conectado. Quando se usa a autenticação do Windows, um invasor não pode recuperar senhas do usuário nem representá-lo, mesmo que se use HTTP em vez de HTTPS. No entanto, independentemente do modo de autenticação, os dados corporativos transferidos entre cliente e servidor continuam sujeitos à interceptação, a menos que seja utilizado o HTTPS.

SSL e certificados Os servidores Web que se comunicam via HTTPS dependem da instalação de um certificado de servidor. O certificado tem duas finalidades. Primeira, o certificado verifica se o servidor ao qual o cliente está se conectando é realmente o servidor correto e não foi substituído ou violado. Segunda, o certificado de servidor contém as informações de chave secreta usadas para criptografar todos os dados enviados ao cliente.

Para que um navegador da Web possa confiar na identidade de um servidor que ele não tenha contatado anteriormente, o certificado do servidor deve ter sido assinado criptograficamente por uma autoridade de certificação confiável. Você pode comprar um certificado de vários provedores, como verisign.com, entrust.net, instantssl.com ou geocerts.com. Como a maioria dos provedores cobra para gerar ou assinar certificados de servidor, é comum nos ambientes de desenvolvimento usar um certificado autogerado e não assinado (e, portanto, não confiável).

Se você se conectar a um aplicativo Web do LightSwitch via HTTPS e o servidor estiver usando um certificado não confiável, o comportamento dependerá do seu navegador da Web. Sem muitos detalhes, o navegador informará sobre o problema do certificado e exibirá uma mensagem perguntando se você deseja continuar. Em aplicativos Web do LightSwitch, isso deve funcionar corretamente.

No entanto, se você estiver usando um aplicativo da área de trabalho do LightSwitch que seja hospedado pelo IIS e estiver acessando-o via HTTPS, o servidor do IIS deverá usar um certificado confiável. O Silverlight não permitirá aplicativos da área de trabalho que venham de certificados de servidor não confiáveis. Um certificado não confiável mostrará que um aplicativo foi aparentemente instalado com êxito, mas que falhará imediatamente ao ser iniciado. Para corrigir esse problema, force seu navegador da Web a confiar no certificado do servidor pré-instalando-o no repositório de certificados do cliente ou substituindo o certificado do servidor por um que tenha sido assinado por uma autoridade de certificação confiável. Observe que é importante executar uma dessas etapas corretivas antes de acessar o aplicativo pela primeira vez em um determinado cliente; caso contrário, para esse cliente, o certificado aparecerá como tendo sido alterado ou violado.

IIS Não é necessária nenhuma configuração específica do LightSwitch no servidor do IIS para hospedar aplicativos do LightSwitch com o SSL. Os administradores de servidor devem configurar o servidor Web para permitir o HTTPS e selecionar um certificado normalmente.

De fato é possível hospedar o mesmo aplicativo do LightSwitch usando ambos os protocolos, HTTP e HTTPS; e, em alguns casos, talvez seja conveniente fazer isso. Porém, observe que, como já mencionei, os clientes que se conectam via HTTP não estão protegendo as informações de senha do usuário nem dados corporativos confidenciais.

Por padrão, em versões recentes do IIS, o Site Padrão escuta ambas as conexões, HTTP e HTTPS. O administrador do servidor pode forçar um aplicativo do LightSwitch implantado em tal servidor a exigir HTTPS e redirecionar todas as conexões de entrada HTTP para o ponto de extremidade HTTPS. Essa configuração está no web.config do aplicativo do LightSwitch.

Configuração do pool de aplicativos Ao publicar no IIS, pense na possibilidade de executar o aplicativo em seu próprio pool de aplicativos. Os pools de aplicativos fornecem isolamento entre processos de trabalho (assim, se um aplicativo Web falhar, ele não afetará outros aplicativos no servidor), mas eles também permitem que o aplicativo seja executado sob diferentes identidades. Dessa forma, é possível criar um pool de aplicativos que hospede um aplicativo Web ou um conjunto de serviços que seja executado sob uma identidade específica do Windows e permitir acesso somente aos recursos necessários para que a identidade execute o aplicativo. No caso de um aplicativo do LightSwitch, esse recurso adicional será o banco de dados. Por padrão, o assistente de implantação publica o aplicativo sob o pool de aplicativos ASP.NET 4, que é executado sob uma identidade de conta da máquina. No entanto, essa identidade não tem acesso ao banco de dados de aplicativos, de modo que a execução do aplicativo resulta em uma mensagem de erro do tipo “Falha de logon para o usuário ‘IIS APPPOOL\ASP.NET v4.0’”.

Aqui, temos duas opções. Se estiver usando um nome de usuário/uma senha do SQL Server na cadeia de conexão, é bem provável que o aplicativo esteja pronto para ser usado (desde que o usuário tenha acesso apropriado ao banco de dados). Entretanto, quando é escolhida a autenticação do Windows para se conectar ao banco de dados, é necessário um pool de aplicativos separado, de modo que ele possa ser configurado para ser executado em uma conta de usuário do Windows com privilégios mínimos. Essa conta também deve ter recebido acesso apropriado para o banco de dados de aplicativo.

Se você estiver usando a autenticação do Windows no IIS 7, há uma configuração adicional da qual você deve estar ciente. Ao usar uma identidade de usuário personalizada como a identidade do pool de aplicativos, você precisa usar o provedor (não Kerberos) Windows NTLM (NT LAN Manager) ou habilitar o suporte para autenticação Kerberos. Outra opção é usar a identidade do Serviço de Rede como a identidade do pool de aplicativos e adicionar esse acesso de conta ao banco de dados.

Protegendo aplicativos Azure do LightSwitch

Todos os aplicativos do LightSwitch que são hospedados no Windows Azure podem ser acessados publicamente. Portanto, esses aplicativos têm um conjunto exclusivo de requisitos de controle de acesso.

Criptografia SSL O LightSwitch será padronizado para usar um ponto de extremidade HTTPS ao publicar um aplicativo no Windows Azure. Isso serve para garantir que qualquer informação corporativa confidencial seja criptografada quando comunicada pela Internet. O LightSwitch fornece uma opção para criar um certificado SSL autoassinado para o aplicativo durante a publicação. Embora essa seja uma excelente maneira de testar o aplicativo no Windows Azure, é altamente recomendável que seja usado um certificado de licença de um fornecedor externo, como já foi mencionado mais acima. Como os aplicativos da área de trabalho não funcionarão por SSL com um certificado não confiável, é possível desativar a criptografia SSL para fins de depuração atualizando o valor de configuração da implantação de Microsoft.LightSwitch.RequireEncryption para false, usando o portal do Windows Azure para isso depois que o aplicativo tiver sido implantado com êxito.

Depois que o aplicativo for testado usando um certificado SSL autoassinado, será possível atualizar o certificado SSL sem republicar o aplicativo pelo portal do Windows Azure. Um novo certificado SSL poderá ser carregado para o aplicativo hospedado alterando o valor de SSLCertificate para a impressão digital do mais novo certificado e reativando a criptografia.

Autenticação do aplicativo É recomendável a autenticação de Formulários para impedir acesso não autorizado aos aplicativos do LightSwitch hospedados pelo Windows Azure. Isso não exigirá nenhuma configuração adicional de servidor depois que um aplicativo tiver sido publicado. Apesar disso, se o aplicativo exigir autenticação do Windows, o aplicativo do LightSwitch publicado precisará estar associado ao domínio. Isso exige o uso do Windows Azure Connect. Você encontrará instruções sobre como habilitar o Windows Azure Connect em bit.ly/qx0Z6n.

Segurança do banco de dados do SQL Azure Normalmente, os aplicativos do LightSwitch dependerão de um banco de dados SQL Azure para os respectivos bancos de dados internos. Esse banco de dados será necessário se você tiver criado tabelas no LightSwitch ou estiver usando autenticação. O SQL Azure usa a combinação de firewall e credenciais de usuário para proteção contra acesso não autorizado.

Para permitir que os aplicativos do LightSwitch hospedados pelo Windows Azure se conectem ao banco de dados, a regra de firewall “Allow other Windows Azure services to access this server" deve ser definida como true. O LightSwitch também exige que uma regra de firewall seja adicionada para o endereço IP do computador que está publicando o aplicativo. É recomendável que essa regra de firewall seja removida assim que o aplicativo for publicado. Isso impedirá que qualquer computador externo acesse o banco de dados.

Conclusão

O LightSwitch ajuda os desenvolvedores a criar aplicativos corporativos de maneira simples e produtiva, e isso também se confirma na implementação de recursos de controle de acesso. Os desenvolvedores podem restringir o acesso de modo rápido e fácil aos respectivos aplicativos usando a autenticação. Quando for necessário um controle mais granular, os recursos de autorização fornecem um meio eficaz de definir permissões e proteger ativos nas camadas de lógica e dados do aplicativo, de modo a controlar eficientemente o acesso do usuário. Os recursos normalmente usados no IIS e Windows Azure podem ser aproveitados para uma solução completa de controle de acesso. No entanto, a parte da inovação é com você! Saiba mais com a equipe do LightSwitch em blogs.msdn.com/b/lightswitch.

 

Valerie Andersen é a gerente de programas da Microsoft que está trabalhando no Visual Studio LightSwitch. Sua meta é promover recursos no LightSwitch que permitirão ao desenvolvedores da vida real criar rapidamente aplicativos seguros e de qualidade para atender às necessidades dos clientes do mundo todo.

Matt Evans é o testador de software que está trabalhando no LightSwitch. Ele quer ter a certeza de que seus aplicativos do LightSwitch são tão seguros quanto você precisa que sejam.

Sheel Shah é o gerente de programas da Microsoft que está trabalhando no LightSwitch. Seu foco na equipe inclui desenvolver recursos de suporte do Windows Azure, implantação e do cliente LightSwitch.

Michael Simons é o desenvolvedor sênior da Microsoft que está trabalhando no LightSwitch. Seu foco na equipe é desenvolver recursos de segurança e dados.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Dan Leeaphon, John Rivard, Dan Seefeldt e Matt Thalman