Exemplo de lista de verificação de aceitação de código para organizações de TI

Artigo
06/12/2012

Atualizado em: 2009-02-26

Sites que se baseiam no Microsoft Office SharePoint Server 2007 em geral incluem soluções personalizadas. O recurso de personalização de sites com a adição dessas soluções proporciona capacidade e flexibilidade ao Office SharePoint Server 2007. Entretanto, um módulo executável mal projetado ou implementado que é executado em um farm do SharePoint pode causar prejuízos que vão além do escopo do aplicativo Web para o qual foi destinado. Soluções personalizadas mal implementadas podem introduzir riscos à segurança e ao desempenho, aumentar o custo do suporte, complicar a implantação e reduzir a produtividade.

Como o impacto da instalação de soluções personalizadas em um farm de servidores do SharePoint pode ser positivo ou negativo, recomendamos avaliar todas cuidadosamente antes de implantá-las em seu ambiente de produção. Entre as áreas que devem ser avaliadas estão:

A solução passou pelas fases de desenvolvimento, teste e piloto de maneira coerente com as práticas recomendadas descritas em Projetar e criar sites para o Office SharePoint Server 2007 e em white papers como o que trata da implementação de soluções do Microsoft Office SharePoint Server 2007 e do Windows SharePoint Services 3.0 (em inglês)?

Além de exigir que a solução seja desenvolvida de acordo com práticas recomendadas gerais, recomendamos providenciar para que os desenvolvedores enviem uma lista de verificação para conferir se suas soluções foram codificadas e testadas de acordo com essas práticas recomendadas.

Para ajudar a garantir que as soluções que você implanta ofereçam os benefícios pretendidos sem expor a empresa a riscos desnecessários, é possível usar a seguinte amostra de lista de verificação de aceitação de código. Use-a como ponto de partida de sua própria lista para verificar a qualidade das soluções enviadas para implantação. Além de permitir uma verificação depois da implantação de uma solução, a lista de verificação de aceitação de código pode se tornar uma ótima ferramenta de treinamento. Fornecendo-a aos desenvolvedores antes de implementarem as personalizações, você comunica as suas expectativas quanto à qualidade das soluções que eles desenvolverão e enviarão.

Importante

Essa lista de verificação de amostra serve para fins meramente informativos. Não se pode pressupor que todos os problemas de aceitação de código sejam tratados nessa lista de verificação, nem que a aplicação de medidas adicionais seja desnecessária para sua organização. Nenhuma garantia, seja explícita ou implícita, é criada por essa lista de verificação.

Neste tópico:

Recursos para as práticas recomendadas de desenvolvimento do SharePoint
Listas de verificação de aceitação de código
Versão imprimível da lista de verificação de aceitação de código (em inglês) (https://go.microsoft.com/fwlink/?linkid=125134\&clcid=0x416) (em inglês)

Recursos para as práticas recomendadas de desenvolvimento do SharePoint

Esta seção contém uma lista de recursos que você pode fornecer aos desenvolvedores para ajudá-los a projetar e implementar soluções que atendam aos requisitos de TI em termos de usabilidade, suporte, desempenho e segurança.

Lista de verificação de aceitação de código

Esta seção organiza as listas de verificação de aceitação de código nas categorias a seguir: segurança, gerenciamento de sessões, validação, dados confidenciais, manipulação de exceções, Web Parts, documentação, práticas recomendadas de desenvolvimento de software geral. Para obter uma versão imprimível e modificável de toda a lista de verificação, consulte Versão imprimível da lista de verificação de aceitação de código (em inglês) (https://go.microsoft.com/fwlink/?linkid=125134\&clcid=0x416) (em inglês).

Dica

As listas de verificação deste documento são fornecidas como uma amostra que pode ser usada para desenvolver sua própria lista de verificação de aceitação de código com base nas necessidades de sua empresa. Use-as como ponto de partida para desenvolver sua própria lista de verificação.

Segurança

Esta seção da lista de verificação de aceitação de código contém os itens sugeridos para ajudar a garantir que as soluções enviadas para implantação em um ambiente do SharePoint tenham sido desenvolvidas usando práticas recomendadas de segurança.

[ ]	O aplicativo usa uma lista de inclusão (entrada conhecida, válida e segura), em vez de uma lista de exclusão (rejeitando entrada maliciosa ou perigosa conhecida).
[ ]	Toda entrada do usuário é codificada com IOSec quando exibida para clientes.
[ ]	A codificação de caracteres é definida pelo servidor (ISO-8859-1 é recomendado).
[ ]	Senhas de texto sem formatação não estão presentes nos arquivos Web.config, Machine.config ou em quaisquer outros que contenham definições de configuração. Utilitários como Aspnet_setreg.exe e Trustee ou a configuração de identidade do AppPool no IIS 6.0 ou IIS 7.0 são usados para criptografar credenciais.
[ ]	Se os cookies contiverem dados confidenciais, eles serão marcados como seguros.
[ ]	Superfícies de entrada nas Web Parts e em outras personalizações incluem verificações de limite, verificações de integridade dos dados de entrada e manipulação de exceções apropriada para proteger contra scripts entre sites e injeção SQL.
[ ]	O design aborda possíveis problemas de canonização.
[ ]	Evite usar AllowUnsafeUpdates. Use ValidateFormDigest() e, se necessário, use privilégios elevados para interagir com os objetos do SharePoint. Nos casos em que for necessário usar AllowUnsafeUpdates, verifique se AllowUnsafeUpdates está definido como False em seu bloco `try-catch-finally` ou use um método Dispose() (conforme exigido pela interface IDisposable) para evitar problemas de segurança.

Gerenciamento de sessões

Esta seção da lista de verificação de aceitação de código contém os itens sugeridos para ajudar a garantir que as soluções enviadas para implantação em seu ambiente do SharePoint tenham sido desenvolvidas usando práticas recomendadas de gerenciamento de sessões.

[ ]	O estado da sessão é forte, imprevisível e protegido contra acesso não autorizado ou ataques de repetição.
[ ]	A duração da sessão está limitada a um máximo de inatividade de 30 minutos.
[ ]	Os identificadores de sessão não são passados na URL, e não é usado o recurso do ASP.NET, ou seja, a sessão sem cookies.
[ ]	O serviço de estado de sessão é desabilitado se não estiver sendo usado.

Validação

[ ]	A validação de entrada é aplicada em todos os pontos de entrada identificados (incluindo campos de formulário, cadeias de caracteres de consulta, cookies, cabeçalhos HTTP e parâmetros de serviços da Web).
[ ]	A opção validateRequest do ASP.NET é habilitada, se possível.
[ ]	Os dados são validados para tipo, comprimento, formato e intervalo.
[ ]	A segurança não depende da validação do lado do cliente. Em vez disso, a validação é executada no lado do servidor.
[ ]	O aplicativo usa de maneira uniforme validação de entrada padronizada, por exemplo, RegEx.

Dados confidenciais

[ ]	O aplicativo não registra dados confidenciais em texto não criptografado.
[ ]	Os dados confidenciais não são armazenados em cookies.
[ ]	Os dados confidenciais não são armazenados em campos de formulário ou cadeias de caracteres de consulta descriptografados e ocultos. Eles são mantidos usando o gerenciamento de estados do lado do servidor.
[ ]	O SSL, o IPSEC com criptografia ou a criptografia de camada de aplicativo antes da transmissão é usado(a) para proteger os dados confidenciais durante a transmissão.
[ ]	Os dados confidenciais não são armazenados em cache. O cache de saída é desativado por padrão.
[ ]	Os dados confidenciais transferidos por email usam criptografia S/MIME ou IRM (Gerenciamento de Direitos de Informação), dependendo do destinatário pretendido.

Manipulação de exceções

[ ]	O aplicativo emprega uma abordagem padronizada à taxa de transferência de manipulação estruturada de exceções e erros.
[ ]	O código de manipulação de erros herda da classe SPException para manter uma aparência consistente dos erros do SharePoint.
[ ]	O aplicativo falha de maneira segura em caso de erros e exceções.
[ ]	As condições de exceção não permitem que um usuário ignore as verificações de segurança para executar código privilegiado.
[ ]	O aplicativo retorna mensagens de erro personalizadas genéricas ao cliente.
[ ]	O código usa manipulação de exceções. O código captura somente as exceções de que você está ciente. Por exemplo, não use `try{} catch(Exception ex){}` a menos que você emita o erro novamente.
[ ]	Se o código usar filtros de exceção, ele não será sensível para filtrar a sequência de execução (o filtro será executado antes do bloco `finally`).
[ ]	Os erros de aplicativo não contêm informações confidenciais ou que possam ser usadas para explorar a falha.

Web Parts

[ ]	Web Parts personalizadas (incluindo arquivos de recursos) estão contidas em um Recurso do SharePoint e são empacotadas como uma solução do SharePoint para ser implantadas.
[ ]	A configuração de Web Parts que estão sendo implantadas oferece ao administrador a flexibilidade de implantar no nível do aplicativo Web ou em um nível inferior.
[ ]	Use o conjunto padronizado de interfaces de conexão referentes a Web Parts da infraestrutura de Web Parts do SharePoint para trocar informações mútuas em tempo de execução.
[ ]	O código-fonte para soluções de Web Parts de terceiros, sempre que possível, é fornecido com a devida documentação para garantir um ótimo suporte técnico.
[ ]	Todas as Web Parts personalizadas utilizam a arquitetura do SharePoint para garantir o comportamento consistente da funcionalidade do aplicativo, como logon único, implantação de recursos e assim por diante.

Documentação

Você deve exigir a devida documentação para garantir que as personalizações solicitadas possibilitem a instalação, o suporte e testes bem-sucedidos. Além disso, a documentação indica que todos os erros gerados pelas personalizações sejam adequadamente descritos e diagnosticados. Esta seção da lista de verificação de aceitação de código contém os itens sugeridos para ajudar a garantir que as soluções enviadas para implantação em seu ambiente do SharePoint tenham sido desenvolvidas usando práticas recomendadas de documentação.

[ ]	As personalizações são acompanhadas por instruções de instalação que detalham o modo de instalação e desinstalação do pacote. Estão inclusos diagramas de arquitetura relacionados à instalação da solução. Se não for possível reverter uma solução, isso deverá ser explicado nas instruções de instalação para que você possa discutir os riscos e preparar um plano de recuperação do sistema.
[ ]	As personalizações são acompanhadas por documentos e resultados de teste.
[ ]	As personalizações são acompanhadas por uma lista de todas as dependências. Isso pode incluir conta/senhas, serviços da Web, bancos de dados, outras soluções ou Recursos, patches, conjuntos de ferramentas ou bibliotecas e outras dependências.
[ ]	É fornecida uma lista com todas as entradas de evento geradas pelas personalizações e as ações que devem ser tomadas. Ela pode assumir a forma de uma tabela de códigos de erros, em que a gravidade e a causa principal de cada código são fornecidas.
[ ]	Como outra opção, o código-fonte é fornecido para agilizar a validação e os testes feitos pela organização de TI.
[ ]	As personalizações que consistem em uma atualização das personalizações implantadas anteriormente são acompanhadas pela documentação que descreve as alterações, as considerações ao atualizar as personalizações e as instruções de reversão.

Práticas recomendadas gerais no desenvolvimento de software

[ ]	Os assemblies têm um nome forte. (Assemblies de páginas da Web do ASP.NET gerados dinamicamente no momento não podem ter um nome forte.)
[ ]	Use assinatura atrasada como uma maneira de proteger e restringir a chave privada usada no nome forte no processo de assinatura.
[ ]	Os assemblies incluem atributos de segurança declarativos (com SecurityAction.RequestMinimum) para especificar os requisitos mínimos de permissão.
[ ]	Os assemblies altamente privilegiados são separados dos assemblies menos privilegiados.
[ ]	Se um assembly for usado em um ambiente de confiança parcial (por exemplo, se for chamado a partir de um aplicativo Web de confiança parcial), o código privilegiado estará em um assembly separado.
[ ]	Você depende de um arquivo de configuração nativa para oferecer suporte ao aplicativo, em vez de alterar a configuração no Web.config.
[ ]	Use o .NET Framework 2.0, 3.0 ou 3.5.
[ ]	Use uma única versão do .NET Framework. Não misture várias versões.
[ ]	O código é compatível com 64 bits.
[ ]	O aplicativo não tenta acessar diretamente nenhum banco de dados do SharePoint. Os armazenamentos de dados nos bancos de dados do SharePoint são atualizados somente usando o modelo de objeto do SharePoint.
[ ]	Evite cadeias e rótulos codificados. Em vez disso, use arquivos de recursos ou de idiomas.
[ ]	Ao referenciar os objetos do SPWeb ou SPSite, empregue uma instrução `using` ou, como alternativa, use uma chamada explícita do método .Dispose para garantir o uso e descarte adequados dos objetos de memória.
[ ]	Use o cache conforme apropriado para reduzir viagens de ida e volta desnecessárias. Para as Web Parts, exponha a validade (duração) do cache como uma propriedade da Web Part.
[ ]	Ao empacotar a solução, inclua uma diretiva de Segurança de Acesso a Código para a solução e, se necessário, inclua seu assembly na lista de Controles Seguros por meio da solução.
[ ]	Ao registrar o código, use a classe Log de Portal para registrar os logs de ULS (Serviço de Log Unificado) do SharePoint.
[ ]	Se precisar atualizar vários itens de lista usando código remoto, use o serviço da Web para atualizar itens de lista. Use SPListItem.Update() somente se precisar atualizar mais de um item por vez usando código baseado em OM local.
[ ]	Ao usar a propriedade Count de um SPListItemCollection, você só pode chamá-la uma vez e armazená-la em uma variável que pode ser mencionada durante o loop. Não a chame dentro de um loop.
[ ]	A solução usa o objeto AppSettings para implementar mapeamento XML. (Isso pode ser fornecido usando a estrutura de persistência de configurações do .NET 2.0, 3.0 ou 3.5.) A solução evita a criação de arquivos XML personalizados e um objeto digitado com segurança para mapeamento XML.
[ ]	Logs de instalação e implantação são fornecidos nos logs de eventos para habilitar a resolução de problemas operacionais adequada durante a instalação e desinstalação.

Baixar este manual

Este tópico está incluído no seguinte manual baixável para facilitar a leitura e a impressão:

Planejamento e arquitetura para o Office SharePoint Server 2007, parte 1

Consulte a lista completa de manuais disponíveis no Conteúdo baixável do Office SharePoint Server 2007.