SEGURANÇA
Existem duas grandes alterações na segurança do .net framework versão 4: As politicas de segurança Machine-wide foram eliminadas, embora o sistema de permissões permaneça no lugar; e o Security Transparency tenha se tornado o mecanismo de reforço.
WEB
O ASP.NET versão 4 introduziu novos componentes nas seguintes áreas:
- Serviços Core, incluindo uma nova API que permite a você extender o caching, suporte a compressão de dados no session-state, e um novo gerenciador de preload de aplicação (componente autostart).
- Web Forms, incluindo suporte mais integrado para rotinas ASP.NET, melhoramentos para padrões web, atualização de suporte a browser, novos componentes para controles de dados, e novos componentes para o gerenciamento do View State;
- Contoles Web Forms, incluindo um novo controle de Chart;
- MVC incluindo novos métodos de ajuda para visualizações, suporte para aplicações MVC particionadas, e controladores assincronos;
- Dados Dinâmicos, incluindo suporte para aplicações web existentes, suporte para relacionamentos muitos para muitos e herança, novos Field Templates e atributos, e filtragem de dados melhorada;
- Microsoft AJAX, incluindo suporte adicional para aplicações AJAX client-based na biblioteca ajax;
- Visual Web Developer, incluindo Intellisense melhorado para JScript, novos Snipets auto-complete para html e markups asp.net, e compatibilidade de css melhorada;
- Deployment, incluindo novas ferramentas para automatizar tarefas de deployment típicas;
- Multi-Targeting, incluindo filtrs para componentes que não estão disponíveis em verões destino do Asp.Net Framework;
terça-feira, 27 de abril de 2010
SEGURANÇA - TRANSPARENT CODE
A segurança no .net framework 4 envolve três partes que interagem: sandboxing, permissions, e enforcement. O Sandboxing refere-se a prática de criar dominios isolados onde alguns códigos são tratados como totalmente confiáveis e outros códigos são restritos as permissões do conjuneto garantido para o sandbox. O código da aplicação executada dentro da garantia de configuração do sandbox é considerada transparente; isto é, ele não pode executar nenhuma operação que pode afetar a segurança. O conjunto garantido para o sandbox é determinado pela evidence. Evidence identifica quais permissões específicas são requeridas pelo sandbox, e quais tipos de sandbox podem ser criados. Enforcement refere-se a permitir código transparente a ser executado apenas dentro de seu conjuento de garantias.
Importante: Políticas de segurança foram um componente chave nas versões anteriores do .net framework. Mas a partir da versão 4 do framework foi tornada obsoleta. A eliminação das políticas de segurança é separada da security transparency.
Proposta do Transparency Model
Tranparency é um mecanismo de reforço que separa o código que executa como parte da aplicação do código que executa como parte da infraestrutura. A Transparency desenha uma barreira entre o código que faz coisas com privilégios (código crítico), como chamar código nativo, e código que não pode (transparent code). Código transparente pode executar comandos dentro dos limites do conjunto de permissões que está operando, mas não podem executar código crítico.
O primeiro objetivo da transparency enforcement é fornecer um mecanismo simples, mas efetiva para isolar diferentes grupos de código com base em privilégios. Dentro do contexto do moddelo sandboxing, estes grupos de privilégios são fully trusted (sem restrições) ou partial trusted (restrito as permissões do sandbox).
Importante: O modelo transparency transcende segurança de acesso do código. A Transparency é reforçada pelo compilador just-in-time e permanece ativo idependente do conjunto de garantias para um assemble, incluindo full trust.
Transparency foi introduzido no framework 2.0 para simplificar o modelo de segurança, e para tornar mais fácil escrever e distribuir bibliotecas seguras e aplicações. O código Transparency também é usado no Silverlight, para simplificar o desenvolvimento de aplicações partially trusted.
Especificando o Transparency Level
O Atributo SecurityRulesAttribute em nivel de assemble, determina as regras do SecurityRuleSet que o assemble irá seguir. As regras são organizadas sob um nível numérico do sistema, onde níveis mais elevados significam super reforço das regras de segurança.
Os níveis são:
Level 2 - regras de transparencia do framework 4;
Level 1 - regras de transparência do framework 2.0;
A primeira diferença entre os dois níveis é que o nível 1 não reforça as regras de transparência para chamadas de fora do assemble e é usada apenas para compatibilidade.
Importante: você precisa especificar o nível 1 apenas para compatibilidade; isto é, especifique o nível 1 apenas para código que foi desenvolvido no framework 3.5 ou anteriores que utilizam o atributo AllowPartiallyTrustedCallersAttribute, ou não usa modelo de transparency. Por exemplo, utilize o level 1 de transparencia para assembles .net framework 2.0 que chamam de chamadores partially trusted (APTCA). Para código que foi desenvolvido no .net framework 4 sempre utilize o level 2.
Level 2 Transparency
O level 2 transparency foi introduzido no .net framework 4. Os três princípios deste modelo são código transparente, código security-safe-critical, e código security-critical.
Importante: Políticas de segurança foram um componente chave nas versões anteriores do .net framework. Mas a partir da versão 4 do framework foi tornada obsoleta. A eliminação das políticas de segurança é separada da security transparency.
Proposta do Transparency Model
Tranparency é um mecanismo de reforço que separa o código que executa como parte da aplicação do código que executa como parte da infraestrutura. A Transparency desenha uma barreira entre o código que faz coisas com privilégios (código crítico), como chamar código nativo, e código que não pode (transparent code). Código transparente pode executar comandos dentro dos limites do conjunto de permissões que está operando, mas não podem executar código crítico.
O primeiro objetivo da transparency enforcement é fornecer um mecanismo simples, mas efetiva para isolar diferentes grupos de código com base em privilégios. Dentro do contexto do moddelo sandboxing, estes grupos de privilégios são fully trusted (sem restrições) ou partial trusted (restrito as permissões do sandbox).
Importante: O modelo transparency transcende segurança de acesso do código. A Transparency é reforçada pelo compilador just-in-time e permanece ativo idependente do conjunto de garantias para um assemble, incluindo full trust.
Transparency foi introduzido no framework 2.0 para simplificar o modelo de segurança, e para tornar mais fácil escrever e distribuir bibliotecas seguras e aplicações. O código Transparency também é usado no Silverlight, para simplificar o desenvolvimento de aplicações partially trusted.
Especificando o Transparency Level
O Atributo SecurityRulesAttribute em nivel de assemble, determina as regras do SecurityRuleSet que o assemble irá seguir. As regras são organizadas sob um nível numérico do sistema, onde níveis mais elevados significam super reforço das regras de segurança.
Os níveis são:
Level 2 - regras de transparencia do framework 4;
Level 1 - regras de transparência do framework 2.0;
A primeira diferença entre os dois níveis é que o nível 1 não reforça as regras de transparência para chamadas de fora do assemble e é usada apenas para compatibilidade.
Importante: você precisa especificar o nível 1 apenas para compatibilidade; isto é, especifique o nível 1 apenas para código que foi desenvolvido no framework 3.5 ou anteriores que utilizam o atributo AllowPartiallyTrustedCallersAttribute, ou não usa modelo de transparency. Por exemplo, utilize o level 1 de transparencia para assembles .net framework 2.0 que chamam de chamadores partially trusted (APTCA). Para código que foi desenvolvido no .net framework 4 sempre utilize o level 2.
Level 2 Transparency
O level 2 transparency foi introduzido no .net framework 4. Os três princípios deste modelo são código transparente, código security-safe-critical, e código security-critical.
Assinar:
Postagens (Atom)