Partilhar via

Melhores práticas de segurança para Information Protection

  • Artigo

Importante

As versões do Microsoft Rights Management Service SDK lançadas antes de março de 2020 são depreciadas; as aplicações que utilizam versões anteriores devem ser atualizadas para utilizar a versão de março de 2020. Para mais detalhes, consulte o aviso de depreciação.

Não estão previstas mais melhorias para o Microsoft Rights Management Service SDK. Recomendamos vivamente a adoção do Proteção de Informações da Microsoft SDK para serviços de classificação, rotulagem e proteção.

Information Protection Kits de Desenvolvimento de Software (SDKs) fornecem um sistema robusto para publicar e consumir informações protegidas de todos os tipos. Para ajudar um sistema a ser o mais forte possível, as aplicações ativadas pela proteção da informação devem ser construídas com base nas melhores práticas. As aplicações partilham a responsabilidade de ajudar a manter a segurança deste ecossistema. Identificar os riscos de segurança e proporcionar soluções de mitigação para esses riscos introduzidos durante o desenvolvimento da aplicação ajuda a minimizar a probabilidade de uma implementação de software menos segura.

Esta informação complementa o acordo legal que deve ser assinado, para obter certificados digitais para pedidos que utilizem os SDKs.

Assuntos não abrangidos

Embora os seguintes assuntos sejam considerações importantes para a criação de um ambiente de desenvolvimento e aplicações seguras, estão fora de alcance para este artigo:

  • Gestão de processos de desenvolvimento de software — Gestão de configuração, garantia de código fonte, minimização do acesso ao código depurado e atribuição de prioridade aos bugs. Para alguns clientes, ter um processo de desenvolvimento de software mais seguro é da maior importância para eles. Alguns clientes prescrevem mesmo um processo de desenvolvimento.
  • Erros comuns de codificação — Informações para evitar ultrapassagens de tampão. Recomendamos a versão mais recente de “Writing Secure Code”, de Michael Howard e David LeBlanc (Microsoft Press, 2002), para rever estas ameaças e mitigações genéricas.
  • Engenharia social — Inclui informações sobre salvaguardas processuais e estruturais, para ajudar a proteger o código contra a exploração por parte de desenvolvedores ou outros dentro da organização do fabricante.
  • Segurança física – inclui informações sobre o bloqueio do acesso ao seu código base e a assinatura de certificados.
  • Implementação ou distribuição de software de pré-lançamento – inclui informações sobre a distribuição de software beta.
  • Gestão de rede – inclui informações sobre sistemas de deteção de intrusões nas suas redes físicas.

Modelos de ameaças e mitigações

Os proprietários de informação digital precisam da capacidade de avaliar os ambientes em que os seus ativos serão desencriptados. Uma declaração de normas mínimas de segurança fornece aos proprietários de informações um quadro para compreender e avaliar o nível de segurança dos pedidos.

Alguns setores, como a administração pública e a saúde, têm processos e normas de certificação e acreditação que se podem aplicar ao seu produto. O cumprimento destas recomendações de segurança mínima não substitui as necessidades únicas de acreditação dos seus clientes. No entanto, o objetivo dos padrões de segurança consiste em ajudá-lo a preparar-se para os requisitos atuais e futuros dos clientes e qualquer investimento que faça no início do ciclo de desenvolvimento será vantajoso para a sua aplicação. Estas diretrizes são recomendações, não um programa formal de certificação da Microsoft.

Existem várias categorias principais de vulnerabilidades num sistema de serviços de gestão de direitos, incluindo as seguintes:

  • Fuga – as informações aparecem em localizações não autorizadas.
  • Danos – o software ou os dados são modificados de forma não autorizada.
  • Negação — Um recurso de computação não está disponível para uso.

Estes tópicos concentram-se principalmente nos problemas relacionados com as fugas. A integridade de um sistema API depende da sua capacidade, ao longo do tempo, de proteger a informação, permitindo o acesso apenas a entidades designadas. Estes tópicos abordam também os problemas relacionados com os danos. As questões de negação não estão abrangidas.

A Microsoft não testa ou analisa os resultados dos testes relacionados com o cumprimento do padrão mínimo. O parceiro é responsável por garantir que as normas mínimas são cumpridas. A Microsoft disponibiliza dois níveis adicionais de recomendações para ajudar a mitigar ameaças comuns. Em geral, estas sugestões são aditivas. Por exemplo, o cumprimento das recomendações preferenciais pressupõe que cumpriu as normas mínimas, se aplicável, salvo especificação em contrário.

Nível do padrão Description
Padrão mínimo Uma aplicação que trate informações protegidas deve cumprir a norma mínima, antes de poder ser assinada com o certificado de produção recebido da Microsoft. Os parceiros geralmente usam o certificado de hierarquia de produção, no momento da libertação final do software. Os próprios testes internos de um parceiro são utilizados para verificar se o pedido cumpre esta norma mínima. Cumprir o padrão mínimo não é, e não deve ser interpretado como uma garantia de segurança pela Microsoft. A Microsoft não testa ou analisa os resultados dos testes relacionados com o cumprimento do padrão mínimo. O parceiro é responsável por garantir que o mínimo é cumprido.
Padrão recomendado As diretrizes recomendadas traçam um caminho para melhorar a segurança da aplicação e fornecem uma indicação de como o SDK pode evoluir à medida que mais critérios de segurança são implementados. Os fornecedores podem diferenciar as suas aplicações construindo este nível mais elevado de diretrizes de segurança.
Padrão preferencial Esta norma é a categoria de segurança mais elevada atualmente definida. Os fornecedores que desenvolvem aplicações comercializadas como altamente seguras devem ter em vista este padrão. As aplicações que satisfazem este padrão são, provavelmente, as menos vulneráveis a ataques.

Software malicioso

A Microsoft definiu padrões obrigatórios mínimos que a sua aplicação tem de satisfazer para proteger os conteúdos contra software malicioso.

Importar software malicioso utilizando tabelas de endereços

A proteção da informação SDK não suporta a modificação do código no tempo de execução ou modificação do quadro de endereços de importação (IAT). É criada uma tabela de endereços de importação para cada DLL carregado no seu espaço de processo. Essa tabela especifica os endereços de todas as funções que a sua aplicação importa. Um ataque comum consiste em modificar as entradas de IAT numa aplicação para, por exemplo, apontarem para software malicioso. O SDK para a aplicação quando deteta este tipo de ataque.

Padrão mínimo

  • Não é possível modificar a tabela de endereços de importação no processo de candidatura durante a execução. A sua aplicação especifica muitas das funções chamadas no tempo de execução, utilizando tabelas de endereços. Estas mesas não podem ser alteradas durante ou após o tempo de funcionação. Entre outras coisas, esta restrição significa que não pode efetuar perfis de código numa aplicação assinada através do certificado de produção.
  • Não é possível ligar para a função DebugBreak dentro de qualquer DLL especificado no manifesto.
  • Não pode ligar para o LoadLibrary com o conjunto de bandeiras DONT_RESOLVE_DLL_REFERENCES . Este sinalizador indica ao carregador para ignorar o enlace aos módulos importados, que modifica a tabela de endereços de importação.
  • Não é possível alterar o atraso no carregamento fazendo alterações no tempo de funcionamento ou alterações subsequentes no interruptor do linker /DELAYLOAD.
  • Não é possível alterar o carregamento atrasado fornecendo a sua própria versão da função de ajudante Delayimp.lib.
  • Não é possível descarregar módulos carregados por módulos autenticados, enquanto o ambiente SDK de proteção de informação existe.
  • Não é possível utilizar o /DELAY:UNLOAD interruptor linker para permitir a descarga de módulos atrasados.

Interpretação incorreta dos direitos de licença

Se a sua aplicação não interpretar e aplicar corretamente os direitos expressos na licença de emissão SDK, poderá disponibilizar informações de forma a que o proprietário da informação não pretenda. Por exemplo, quando uma aplicação permite que um utilizador guarde informações não encriptadas para novos meios de comunicação, quando a licença de emissão apenas confere o direito de visualizar a informação.

Azure Information Protection (AIP)

O sistema de proteção da informação organiza direitos a alguns agrupamentos. Para mais informações, consulte os direitos de utilização da Azure Information Protection.

A AIP permite que um utilizador desencriptar informações ou não. A informação não tem nenhuma proteção inerente. Se um utilizador tiver o direito de desencriptar, a API permite-o. A aplicação é responsável pela gestão ou proteção dessa informação depois de estar clara. Uma aplicação é responsável pela gestão do seu ambiente e interface para impedir o uso não autorizado de informação. Por exemplo, desativar os botões Imprimir e Copiar se uma licença apenas conceder o direito VIEW. O seu conjunto de aplicações de teste deve confirmar se a aplicação atua corretamente em todos os direitos de licença que reconhece.

Padrão mínimo

  • A implementação do cliente dos direitos XrML v.1.2 deve ser consistente com as definições destes direitos, conforme descrito nas especificações XrML, que estão disponíveis no web site da XrML (http://www.xrml.org). Quaisquer direitos que sejam específicos da sua aplicação têm de ser definidos para todas as entidades que têm um interesse na mesma.
  • O seu conjunto de testes e o seu processo de teste devem verificar se a sua aplicação executa corretamente contra os direitos que a aplicação suporta. Também deve verificar se não atua em direitos não apoiados.
  • Se estiver a construir um pedido de publicação, deve disponibilizar informações que expliquem os direitos intrínsecos utilizados. Isto inclui aqueles que são, e não são, apoiados pela aplicação editorial, e como esses direitos devem ser interpretados. Além disso, a interface de utilizador deve explicar claramente ao utilizador final quais são as implicações de cada direito concedido ou negado a uma determinada informação.
  • Quaisquer direitos que sejam resumidos, através da inclusão em novos direitos implementados por uma aplicação, devem ser mapeados para a nova terminologia. Por exemplo, um novo direito denominado GESTOR pode incluir como direitos abstraídos os direitos IMPRIMIR, COPIAR e EDITAR.

Nenhum neste momento.

Padrão preferencial

Nenhum neste momento.

Passos seguintes

As melhores práticas para a implementação de aplicações utilizando o AIP SDK incluem os seguintes artigos: