Lista de comprobación de aceptación de código de ejemplo para organizaciones de TI

Artículo
06/12/2012

Los sitios web basados en Microsoft Office SharePoint Server 2007 suelen incluir soluciones personalizadas. La posibilidad de personalizar los sitios mediante la adición de soluciones personalizadas aumenta la eficacia y la flexibilidad de Office SharePoint Server 2007. No obstante, un módulo ejecutable diseñado o implementado de forma incorrecta que se ejecute en una granja de servidores de SharePoint puede provocar daños más allá del ámbito de la aplicación web a la que se destina. Las soluciones personalizadas implementadas de forma incorrecta pueden representar riesgos de seguridad o rendimiento, aumentar el costo del soporte técnico, dificultar la implementación y reducir la productividad.

Debido a que los efectos de la instalación de soluciones personalizadas en una granja de servidores de SharePoint pueden ser positivos o negativos, se recomienda evaluar detenidamente todas las soluciones personalizadas antes de implementarlas en el entorno de producción. Las áreas que se deben evaluar son las siguientes:

¿Se ha desarrollado y probado la solución de forma coherente según los procedimientos recomendados descritos en Diseño y creación de sitios para Office SharePoint Server 2007 y en las notas del producto, como las dedicadas a la implementación de soluciones de Microsoft Office SharePoint Server 2007 y Windows SharePoint Services 3.0 (en inglés)?

Además del requisito de que la solución se desarrolle según los procedimientos recomendados generales, se recomienda que los programadores envíen una lista de comprobación para comprobar si las soluciones se han codificado y probado según los procedimientos recomendados.

Para garantizar que las soluciones implementadas ofrezcan las ventajas previstas sin exponer la empresa a un riesgo innecesario, puede usar la siguiente lista de comprobación de aceptación de código de ejemplo. Use esta lista como punto de partida en su propia lista de comprobación para comprobar la calidad de las soluciones enviadas para su implementación. Además de proporcionar una comprobación tras el desarrollo de una solución, la lista de comprobación de aceptación de código puede ser una herramienta de aprendizaje adecuada. Al proporcionar a los programadores esta lista antes de que implementen las personalizaciones, comunica sus expectativas de calidad para las soluciones que desarrollen y envíen.

Importante

Esta lista de comprobación de ejemplo es meramente informativa. No se pretende que cubra todos los problemas de aceptación de código ni evitar que se requieran medidas adicionales aplicables para la organización. Esta lista de comprobación no representa garantía alguna, ya sea expresa o implícita.

En este tema:

Recursos para los procedimientos recomendados de desarrollo de SharePoint
Listas de comprobación de aceptación de código
Versión imprimible de la lista de comprobación de aceptación de código (en inglés) (https://go.microsoft.com/fwlink/?linkid=125134&clcid=0xC0A) (en inglés)

Recursos para los procedimientos recomendados de desarrollo de SharePoint

En esta sección se incluye una lista de recursos que puede proporcionar a los programadores para facilitar el diseño y la implementación de soluciones que cumplan los requisitos de TI en relación con las posibilidades de uso, la compatibilidad, el rendimiento y la seguridad.

Lista de comprobación de aceptación de código

En esta sección, las listas de aceptación del código se clasifican en las siguientes categorías: seguridad, administración de sesiones, validación, información confidencial, control de excepciones, elementos web, documentación, procedimientos recomendados sobre el desarrollo general del software. Para obtener una versión que se pueda imprimir y modificar, vea la Versión imprimible de la lista de comprobación de aceptación de código (en inglés) (https://go.microsoft.com/fwlink/?linkid=125134&clcid=0xC0A) (en inglés).

Nota

Las listas de comprobación incluidas en este documento son un ejemplo que puede usar para desarrollar su propia lista de comprobación de aceptación de código según las necesidades de su empresa. Use esta lista como punto de partida para crear su propia lista de comprobación.

Seguridad

En esta sección de la lista de comprobación de aceptación de código se incluyen elementos recomendados para garantizar que las soluciones enviadas para su implementación en un entorno de SharePoint se han desarrollado mediante los procedimientos recomendados de seguridad.

[ ]	La aplicación usa una lista de inclusión (entrada conocida, válida y segura) en lugar de una lista de exclusión (rechazo de entradas malintencionadas o peligrosas conocidas).
[ ]	Todas las entradas de usuario se codifican con IOSec cuando se muestran a los clientes.
[ ]	La codificación de caracteres se establece mediante el servidor (se recomienda el uso de ISO-8859-1).
[ ]	Las contraseñas con texto sin formato no están presentes en Web.config, Machine.config o cualquier otro archivo que contenga valores de configuración. Para cifrar las credenciales, se usan utilidades como Aspnet_setreg.exe y el administrador de confianza o la configuración de identidad de AppPool de IIS 6.0 o IIS 7.0.
[ ]	Si las cookies contienen información confidencial, se marcan como seguras.
[ ]	Las superficies de entrada de los elementos web y otras personalizaciones incluyen comprobaciones de límites, comprobaciones de integridad de los datos de entrada y el control de excepciones correspondiente para ofrecer protección frente a ataques de scripts de sitios y ataques por inyección de código SQL.
[ ]	En el diseño se tratan posibles problemas de creación de nombres canónicos.
[ ]	Se debe evitar el uso de AllowUnsafeUpdates. Use ValidateFormDigest() y, si es necesario, use privilegios elevados para interactuar con los objetos de SharePoint. En los casos en que es necesario usar AllowUnsafeUpdates, asegúrese de que AllowUnsafeUpdates esté establecido en False en el bloque `try-catch-finally` o use un método Dispose() (según lo requiera la interfaz IDisposable) para evitar problemas de seguridad.

Administración de sesiones

En esta sección de la lista de comprobación de aceptación de código se incluyen elementos recomendados para garantizar que las soluciones enviadas para su implementación en el entorno de SharePoint se han desarrollado mediante los procedimientos recomendados para la administración de sesiones.

[ ]	El estado de sesión es seguro e impredecible, y está protegido frente al acceso no autorizado o los ataques de reproducción.
[ ]	La duración de la sesión se limita a 30 minutos de inactividad como máximo.
[ ]	Los identificadores de sesión no se pasan en la dirección URL y no se usa la sesión sin cookies, una característica de ASP.NET.
[ ]	El servicio de estado de sesión se deshabilita cuando no se usa.

Validación

[ ]	La validación de entrada se aplica en todos los puntos de entrada identificados (incluidos los campos de formulario, las cadenas de consulta, las cookies, los encabezados HTTP y los parámetros de servicio web).
[ ]	La opción validateRequest de ASP.NET se habilita si es posible.
[ ]	Los datos se validan para el tipo, la longitud, el formato y el intervalo.
[ ]	La seguridad no se basa en la validación del cliente, sino que se realiza en el servidor.
[ ]	La aplicación usa de forma coherente la validación de entrada estandarizada, como RegEx.

Información confidencial

[ ]	La aplicación no registra información confidencial en texto no cifrado.
[ ]	La información confidencial no se almacena en cookies.
[ ]	La información confidencial no se almacena en campos de formulario o cadenas de consulta ocultos y sin cifrar. Se mantiene mediante el uso de la administración de estados del servidor.
[ ]	Antes de la transmisión, se usa SSL, IPSEC con cifrado o el cifrado de nivel de aplicación para proteger la información confidencial durante la transmisión.
[ ]	La información confidencial no se almacena en la memoria caché. El almacenamiento en la memoria caché de resultados está desactivado de forma predeterminada.
[ ]	La información confidencial que se transfiere por correo electrónico usa el cifrado S/MIME o Information Rights Management (IRM) en función del destinatario previsto.

Control de excepciones

[ ]	La aplicación usa un enfoque estandarizado para el control estructurado de errores y excepciones.
[ ]	El código de control de errores se hereda de la clase SPException para mantener un aspecto coherente en SharePoint para los errores.
[ ]	La aplicación genera un error en caso de error y excepciones.
[ ]	Las condiciones de excepción no permiten al usuario omitir las comprobaciones de seguridad para ejecutar código con privilegios.
[ ]	La aplicación devuelve mensajes de error personalizados genéricos al cliente.
[ ]	El código usa el control de excepciones. El código detecta sólo las excepciones conocidas. Por ejemplo, no use `try{} catch(Exception ex){}` a menos que el error se vuelva a generar.
[ ]	Si el código usa filtros de excepciones, no es sensible a la secuencia de ejecución de filtro (el filtro se ejecuta antes del bloque `finally`).
[ ]	Los errores de aplicaciones no contienen información confidencial o información que se pueda usar para aprovechar la vulnerabilidad que representan estos errores.

Elementos web

[ ]	Los elementos web personalizados (incluidos los archivos de recursos) se incluyen en una característica de SharePoint y se empaquetan como una solución de SharePoint para su implementación.
[ ]	La configuración de los elementos web que se van a implementar proporciona al administrador la flexibilidad necesaria para la implementación en el nivel de la aplicación web o inferior.
[ ]	Use el conjunto de interfaces de conexión estandarizado de la infraestructura de elementos web de SharePoint para que los elementos web intercambien información entre sí en tiempo de ejecución.
[ ]	Siempre que sea posible, el código fuente de las soluciones de elementos web de terceros se proporcionará con la documentación correspondiente para garantizar un soporte técnico adecuado.
[ ]	Todos los elementos web personalizados usan la arquitectura de SharePoint para garantizar un comportamiento coherente en toda la aplicación para funcionalidades como el inicio de sesión único, la implementación de características, etc.

Documentación

Debe solicitar la documentación correspondiente para confirmar que las personalizaciones que debe implementar son compatibles y se pueden instalar y probar correctamente. Además, en la documentación se recomienda la descripción y el diagnóstico correctos de todos los errores generados por las personalizaciones. En esta sección de la lista de comprobación de aceptación de código se incluyen elementos recomendados para garantizar que las soluciones enviadas para su implementación en el entorno de SharePoint se han desarrollado mediante los procedimientos recomendados para la documentación.

[ ]	Las personalizaciones van acompañadas de una serie de instrucciones de instalación en que se detalla cómo instalar y desinstalar el paquete. Se incluyen diagramas de la arquitectura relacionados con la instalación de la solución. En caso de no poder revertir una solución, se debe explicar en las instrucciones de instalación para poder analizar los riesgos y preparar un plan para la recuperación del sistema.
[ ]	Las personalizaciones van acompañadas de los documentos y los resultados de las pruebas.
[ ]	Las personalizaciones van acompañadas de una lista de todas las dependencias. Esto puede incluir cuentas y contraseñas, servicios web, bases de datos, otras soluciones o características, revisiones, conjuntos de herramientas o bibliotecas y otras dependencias.
[ ]	Se proporciona una lista de todas las entradas de eventos generadas por las personalizaciones y de las acciones que se deben realizar. Esta información se puede incluir en una tabla de códigos de error, donde se indique la gravedad y la causa principal de cada código.
[ ]	De forma opcional, se proporciona el código fuente para agilizar la validación y las pruebas por parte de la organización de TI.
[ ]	Las personalizaciones que son una actualización de personalizaciones implementadas previamente van acompañadas de la documentación en que se describen los cambios, las consideraciones para actualizar las personalizaciones y las instrucciones

Procedimientos recomendados para el desarrollo de software general

[ ]	Los ensamblados tienen un nombre seguro. (Los ensamblados de página web ASP.NET generados dinámicamente no pueden tener un nombre seguro).
[ ]	Use la firma con retraso como medio de protección y restricción de la clave privada que se usa en el nombre seguro y en el proceso de firma.
[ ]	Los ensamblados incluyen atributos de seguridad declarativa (con SecurityAction.RequestMinimum) para especificar los requisitos de permisos mínimos.
[ ]	Los ensamblados con privilegios elevados se separan de los ensamblados con privilegios inferiores.
[ ]	Si se va a usar un ensamblado en un entorno de confianza parcial (por ejemplo, la llamada se realiza desde una aplicación web de confianza parcial), el código con privilegios se incluye en otro ensamblado.
[ ]	Se usa un archivo de configuración nativo para admitir la aplicación en lugar de cambiar la configuración en Web.config.
[ ]	Use .NET Framework 2.0, 3.0 o 3.5.
[ ]	Use una sola versión de .NET Framework. No mezcle varias versiones.
[ ]	El código es compatible con 64 bits.
[ ]	La aplicación no intenta obtener acceso directamente a ninguna de las bases de datos de SharePoint. Los almacenes de datos de las bases de datos de SharePoint sólo se actualizan con el modelo de objetos de SharePoint.
[ ]	Evite la codificación de forma rígida de las cadenas y etiquetas. Use archivos de recursos o idiomas en su lugar.
[ ]	Al hacer referencia a los objetos SPWeb o SPSite, use una instrucción `using` o, de forma alternativa, use una llamada explícita del método .Dispose para garantizar el uso y la eliminación correctos de los objetos de la memoria.
[ ]	Use el almacenamiento en caché según corresponda para reducir las idas y vueltas innecesarias. En el caso de los elementos web, exponga la expiración de la memoria caché (duración) como una propiedad del elemento web.
[ ]	Al empaquetar la solución, incluya una directiva de seguridad de acceso a código para la solución y, si es necesario, incluya el ensamblado en la lista de controles seguros para la solución.
[ ]	Al registrar el código, use la clase de registro del portal para registrar los registros del Servicio de creación de registros unificado (ULS) de SharePoint.
[ ]	Si necesita actualizar varios elementos de lista con código remoto, use el servicio web para actualizar los elementos de lista. Use sólo SPListItem.Update() si debe actualizar más de un elemento simultáneamente con código basado en el modelo de objetos local.
[ ]	Si usa la propiedad Count de SPListItemCollection, debe llamar a la propiedad sólo una vez y almacenarla en una variable a la que puede hacer referencia al crear un bucle. No llame a la propiedad desde el bucle.
[ ]	La solución usa el objeto AppSettings para implementar la asignación XML. (Se puede proporcionar mediante el uso del marco de persistencia de configuración de .NET 2.0, 3.0 o 3.5). La solución evita la creación de archivos XML personalizados y un objeto con establecimiento inflexible de tipos para la asignación XML.
[ ]	El registro de instalación e implementación se incluye en los registros de eventos para permitir una solución de problemas operativa adecuada durante la instalación y la desinstalación.

Descarga de este libro

En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:

Planeación de sitios y características (primera parte)

Vea la lista completa de libros disponibles en la página que muestra el contenido que se puede descargar para Office SharePoint Server 2007.