Share via


Criar uma permissão

Uma permissão representa a capacidade de acesso um recurso protegido ou efetuar uma operação protegida.Durante a implementação de sua própria classe de permissão, você deve tomar várias decisões de design de alto nível.Uma das primeiras etapas é determinar exatamente o que recurso sua permissão personalizada é projetada para proteger.

Em seguida você deseja decidir se há dúvidas Sobre sobreposição de permissões.Embora você deseja evitar ter duas permissões que proteger o mesmo recurso, em algumas situações você não pode razoavelmente evitá-lo.Por exemplo, a permissão para acessar código não gerenciado pode abranger também Outros permissões, porque o código que recebeu permissão para acessar código não gerenciado pode fazer quase tudo por meio de uma API não gerenciada.No entanto, quando permissão para acesso código não gerenciado não é concedido, você ainda precisará conceder permissões a acesso outros recursos específicos.Portanto, faz sentido permissão acessar código não gerenciado a ser separada Outros permissões.

Como saber se uma sobreposição na cobertura de permissão é gerenciável?Não há nenhuma resposta absoluta, mas algo pensar é se uma das permissões representa acesso mais refinado que o Outros permissão para que ele normalmente seja concedido mais rapidamente que o Outros permissão.Quando este for o caso, direitos de acesso é fácil de fazer em muitos casos, que facilita a tarefa do administrador.

Depois de decidir quais recursos sua permissão protegerá e resolveu problemas sobre a sobreposição de permissões, você deve decidir como um melhor controle de acesso granular deve ser.A resposta a essa pergunta afeta a forma como você Design as variáveis que representam o estado da permissão e determina se os administradores podem configurar o acesso ao recurso protegido.Ele também pode afetar o desempenho, facilidade de uso e outros fatores.

Para ilustrar alguns desses problemas de design, considere alguns dos designs que poderiam foram selecionados para o Classe FileIOPermission que o .NET estrutura fornece.Cada opção de design afeta as variáveis que representam o estado da permissão.

  • Um único bit significa "usar todos os arquivos" ou "não usar nenhum arquivo", dependendo do seu valor.

  • Dois bits significando "ler todos os arquivos" e "gravar todos os arquivos", ou não, dependendo de seus valores.

  • 26 bits que significa "usar todos os arquivos na unidade especificada".

  • Uma matriz de seqüências de caracteres listando todos os arquivos aos quais o acesso é concedido.

Obviamente, há várias vantagens e desvantagens a serem considerados.Por exemplo, a permissão de bit único é muito simples, rápida e fácil de entender, mas ele apresenta uma opção Tudo ou nada para administradores, que podem não ser desejáveis.Outras opções que especificam uma representação mais complexa do estado de permissão podem prejudicar o desempenho em algum grau.Você deve avaliar essas compensações e considere a possibilidade de que você não deve criar mais de uma permissão para proteger o mesmo recurso.Em geral, você deve projetar sua classe de permissão de forma que o estado da permissão é tão complexo sistema autônomo necessário, sem afetar significativamente o desempenho.

Embora outros designs sejam possíveis, a maioria das permissões execute um dos seguintes padrões de design padrão ou uma combinação disso:

  • Booleanas permissões.Esse tipo de objeto de permissão mais simples contém um ou mais bits, cada um dos quais corresponde a "permissão para fazer X".Você tem a permissão ou não fizer isso.Um exemplo desse tipo de permissão é o Classe SecurityPermission, cujo estado contém variáveis booliano, que representa o direito de fazer coisas diferentes, sistema autônomo permissão para chamar código não gerenciado, ou cada um deles é permitida ou não.

  • Níveis de permissões.Essa forma mais detalhada de permissão tem variáveis que representam cada tipo de acesso sistema autônomo um número de zero (o que significa que nenhum acesso em todos sistema autônomo) para algum número mais alto (significado totalmente irrestrito de acesso), com alguns níveis entre sistema autônomo dois.Por exemplo, você pode usar o Classe UIPermission para expressar a níveis variados de permissão para usar janelas, sem permissão de interface do usuário para permissões irrestritas de interface do usuário, com alguns gradações entre os dois.

  • Objeto as permissões de lista.Esse tipo de permissão fornece uma especificação muito detalhada para o que é e não é permitido.The Classe FileIOPermission é um mercadoria exemplo desse tipo de permissão porque seu estado é representado por listas de arquivos em que determinados tipos de acesso são permitidos.Permissões com listas são mais úteis para a proteção de recursos que contêm um grande número de objetos nomeados.

Em geral, é uma mercadoria idéia minimizar dependências externas na sua classe de permissão personalizada como sua permissão cada assembly depende terão que ser carregado quando o sistema de segurança necessita de sua classe de permissão.Outro motivo para minimizar as dependências é que cada assembly usado por sua classe de permissão personalizada (exceto Mscorlib) deve ser adicionado à lista confiança total.(Para obter mais informações, consulte Atualização de diretiva de segurança.) Se possível, você deve colocar a permissão personalizada e as classes de atributo associadas a ele em um assembly separado, para reduzir a probabilidade de que outros assemblies sejam carregados desnecessariamente.

Observação:

sistema autônomo permissões personalizadas ou deverá ser marcadas sistema autônomo sealed (NotInheritable no Visual Basic) ou tem uma demanda de herança colocada em-los.Caso contrário, chamadores mal-intencionados serão capazes de derivar de sua permissão, acarretando possíveis vulnerabilidades de segurança.

Consulte também

Conceitos

Criando suas próprias permissões de acesso ao código

Outros recursos

Segurança de Acesso de código