Seguridad de SharePoint: Aspectos básicos de la protección de las implementaciones de SharePoint

Brien Posey

Incluso un administración sin experiencia puede implementar Microsoft Office SharePoint Server 2007 en el transcurso de algunas horas. Sin embargo, y a pesar de que la implementación básica sería sin lugar a dudas funcional, es probable que no esté configurada para lograr una seguridad óptima. SharePoint Server 2007 es una de las aplicaciones fáciles de instalar, pero difíciles de hacerlo adecuadamente.

Lo que hace que la seguridad sea tan desafiante es que SharePoint 2007 es un producto monolítico que intenta serlo todo para todas las personas. SharePoint 2007 es una aplicación web, pero también puede considerarla como una herramienta de colaboración, un servidor de documentos o incluso un marco de desarrollo. La naturaleza abstracta y altamente personalizable de SharePoint es la razón por la cual es difícil de proteger.

Tal como probablemente haya deducido, no hay una solución mágica para proteger SharePoint. Cada implementación de SharePoint es única, por lo que una solución que sirva para todo simplemente no es práctica. Sin embargo, hay un enfoque básico que funcionará para todas las implementaciones.

Si alguna vez ha creado un sitio de SharePoint, sabe que SharePoint fue diseñado para ser modular, con bloques de creación que puede usar para crear sitios de SharePoint, colecciones de sitios, listas, bibliotecas, etc. Y en lo que respecta a la seguridad, puede usar esta naturaleza modular para su beneficio.

La idea es centrarse en proteger los componentes individuales de la implementación de SharePoint. La naturaleza modular de SharePoint significa que la implementación normalmente requiere varios servidores SharePoint independientes. Así, si desea que su implementación sea segura, debe configurar estos servidores independientes para que sean seguros.

SQL Server

Todos los datos contenidos en las listas y bibliotecas de SharePoint se almacenan en una base de datos de SQL Server subyacente, que además almacena la mayor parte de los ajustes de configuración de SharePoint. Claramente, proteger correctamente el SQL Server es esencial.

Las organizaciones más pequeñas a menudo instalan SQL Server y SharePoint en el mismo servidor para reducir los costos de hardware de servidor. Pero implementar SQL Server y SharePoint en una máquina común es una mala idea tanto de un punto de vista de la seguridad como del rendimiento.

Uno de los conceptos más fundamentales en la seguridad de TI es minimizar la superficie de ataque de un servidor. Si SQL y SharePoint residen en el mismo servidor, ese servidor tendrá una gran superficie de ataque. Por lo tanto, mi primera recomendación es ejecutar SQL Server en una máquina dedicada. Si un SQL Server dedicado está detrás del presupuesto de su organización, considere usar la virtualización de servidor para aislar SQL y SharePoint.

También es buena idea deshabilitar cualquier servicio y componente que no se esté utilizando. Una implementación básica de SharePoint usa el motor de base de datos de SQL Server, el Agente SQL Server y los componentes SQL Server Browser. Instalaciones más avanzadas pueden requerir servicios de indización de texto completo, análisis o generación de informes.

¿Cómo decide lo que va a deshabilitar? Microsoft brinda una herramienta llamada Herramienta de configuración de superficie de SQL Server (que aparece en la figura 1) que puede ayudar en el proceso. Esta herramienta está diseñada para analizar la implementación de SQL Server y deshabilitar todo lo que se está usando. Debe ejecutar esta utilidad después de implementar y ejecutar SharePoint.

Para obtener acceso a la herramienta, elija la opción Configuración de superficie de SQL Server desde el menú Inicio | Todos los programas | Microsoft SQL Server 2005 | Herramientas de configuración del servidor.

Figura 1 La herramienta de configuración de superficie de SQL Server puede ayudar a saber cuáles son los componentes y servicios que puede deshabilitar.

También debe considerar cuidadosamente el método de autenticación que selecciona para la seguridad de SQL Server. Aunque puede elegir un modo mixto o el modo de autenticación de Windows, debe configurar el SQL Server para usar la autenticación de Windows cada vez que sea posible. El modo de Windows es más seguro que el modo mixto, porque usa el protocolo de seguridad kerberos durante el proceso de autenticación. Además, la autenticación de Windows usa cuentas de usuario de dominio, por lo que cualquier directiva de contraseña que haya establecido dentro de Active Directory sigue siendo efectiva.

Cuentas de servicio

Uno de los principales errores de seguridad en los que incurren los administradores al momento de implementar SharePoint 2007 es que no configuran correctamente las cuentas de servicio. Si alguna vez instaló SharePoint 2007, sabe que hay varios puntos durante los procesos de implementación y configuración en los que se le pide brindar una cuenta de servicio.

Muy a menudo, los administradores crean una sola cuenta de servicio y la usan durante todo el proceso de instalación de SharePoint. A pesar de que el servidor SharePoint resultante es funcional, este enfoque es riesgoso desde un punto de vista de la seguridad.

El problema es que cada vez que brinda SharePoint con una cuenta de servicio, se le otorgan derechos a la cuenta designada para realizar la tarea en mano. SharePoint brinda la cuenta sólo con los permisos suficientes para hacer su trabajo, nada más. Pero si usa la misma cuenta de servicio varias veces a lo largo del proceso de implementación, usted termina con una cuenta con permisos excesivos debido a que recibe derechos adicionales cada vez que la usa. Es posible que alguna persona entonces ejecute código en un servidor de SharePoint que use estos derechos excesivos y obtenga control sobre el servidor.

Existe mucha información contradictoria acerca de cómo estructurar las cuentas que usa SharePoint. Se ha visto dificultada incluso la confirmación de los procedimientos recomendados. Aún así, si realiza una implementación básica de SharePoint, se recomienda el uso de un mínimo de cinco cuentas independientes.

También se recomienda crear una cuenta de usuario especial únicamente para el propósito de instalar SharePoint y SQL Server. Es una práctica común que los administradores inicien sesión usando su propia cuenta personal o la cuenta de administrador de dominio al implementar SharePoint. Usar una cuenta existente puede ser un error desde una perspectiva de seguridad, porque esa cuenta tendrá derechos adicionales para completar el proceso de configuración.

Si decide usar una cuenta dedicada para la instalación, debe hacer que la cuenta sea un miembro del grupo del administrador local en cada uno de los servidores de SharePoint. También debe hacer que la cuenta sea un miembro del grupo de inicios de sesión de SQL Server, lo que permite que la cuenta inicie sesión en la instancia de SQL Server.

Finalmente, deberá asignar la cuenta a los roles de Creador de base de datos de SQL Server y de Administrador de seguridad de SQL Server en SQL Server. Estos roles dan a las cuentas permiso para crear y modificar bases de datos y administrar la seguridad de SQL Server. Estos permisos especiales son la base de la recomendación para usar una cuenta de usuario dedicada.

Además de crear una cuenta específicamente para el proceso de instalación de SharePoint, deberá crear algunas otras cuentas de servicio:

Cuenta de acceso a base de datos. Esta es la cuenta que usará SharePoint para comunicarse con la base de datos de SQL Server.

Cuenta de servicio de SharePoint Search. El servicio SharePoint Search usará esta cuenta para escribir archivos de índice de contenido en el servidor de índice, y para replicar la información de índice en cualquier servidor de consulta que exista en la granja.

Cuenta de acceso a contenido. Esta cuenta se usa para rastrear contenido dentro de un proveedor de servicios compartidos. En algunos casos, es posible que necesite crear varias cuentas de acceso a contenido para que varias fuentes de contenido se puedan rastrear de manera individual.

Cuenta de servicio de grupo de aplicaciones. Los procesos de trabajo dentro de IIS usan esta cuenta. Las aplicaciones web dentro del grupo deben tener una manera de obtener acceso a bases de datos de contenido de SharePoint, y la cuenta de identidad de grupo de aplicaciones facilita este proceso.

Cuenta de servicio de SQL Server. SQL Server también requiere una cuenta de servicio, y debe usar una cuenta dedicada para este propósito.

Las implementaciones de SharePoint más avanzadas pueden requerir el uso de cuentas de servicio adicionales. La sección Contenido relacionado que aparece al final de este artículo incluye un vínculo a un artículo de TechNet que ofrece información detallada sobre algunas de las otras cuentas de servicio que pudiera necesitar.

Convenciones de nomenclatura

En este punto, ya puede ver que tendrá que crear varias cuentas antes de siquiera comenzar con la implementación de SharePoint. Un truco para garantizar la implementación sin problemas es decidir una convención de nomenclatura para las cuentas de servicio antes de crearlas.

Existen distintos enfoques que puede usar para establecer una convención de nomenclatura de cuentas de servicio, pero debe seguir algunas reglas básicas. Es recomendable que los nombres sean lo más descriptivos posible, y que se tome el tiempo de documentar los nombres elegidos y los propósitos que tienen. Por ejemplo, es posible que la cuenta de SharePoint Search reciba un nombre similar a SPT_Search.

La razón por la que no se escribe completamente SharePoint tiene que ver con algunas limitaciones heredadas. Windows permite nombres de usuario de hasta 100 caracteres, pero en algún momento los nombres de usuario estaban limitados a 16 caracteres. A veces, es posible encontrarse con problemas inesperados en lo que respecta a nombres de usuario más largos, debido a hardware o software heredado. A pesar de que es raro, sí ocurre, por lo que es mejor ceñirse a nombres más cortos.

Tenga en cuenta que, aunque he recomendado usar nombres de cuenta de servicio descriptivos, lo que ciertamente facilita la vida de los administradores, el hacerlo no siempre brinda una seguridad óptima. Las cuentas de servicio son un buen objetivo para los hackers, porque tienen más permisos que las cuentas de usuarios normales. Además tienen contraseñas estáticas y que no cambian. Siendo este el caso, es posible que desee considerar camuflar sus cuentas de servicio. Si lo hace, asegúrese de documentar las funciones y los nombres de las cuentas de servicio.

Cifrado de tráfico

Cuando se refiere a la planificación de una implementación de SharePoint, los administradores pasan gran cantidad de tiempo diseñando la arquitectura del servicio. Un elemento que a veces se pasa por alto es la infraestructura de clave pública (PKI). Es necesario tener una PKI antes de implementar SharePoint, para así poder cifrar adecuadamente el tráfico de SharePoint. El tráfico HTTP entre servidores de SharePoint y los usuarios finales debe estar cifrado mediante SSL (usando HTTPS).

Por lo tanto, el tráfico entre servidores de SharePoint debe cifrarse mediante el uso de IPSec. Ambos tipos de cifrado dependen de los certificados y de una infraestructura de PKI subyacente.

Estos procedimientos recomendados de seguridad no son, de ningún modo, integrales. Sin embargo, son un buen punto de partida que puede usar para garantizar que la instalación de SharePoint sea lo más segura posible.

Brien Posey*, MVP, es autor técnico independiente con miles de artículos y docenas de libros a su haber. Puede visitar su sitio web en** brienposey.com*.

Contenido relacionado

·       Plan para cuentas administrativas y de servicio (Office SharePoint Server)

·       Comprensión de la configuración de superficie

·       Guía paso a paso de servicios de certificado de Active Directory