Planeación de la seguridad del sitio (Office SharePoint Server)

En este artículo:

• Elementos de seguridad del sitio

• Asignación de permisos

• Personalización avanzada de permisos y herencia de permisos

• Elección de los niveles de seguridad que se van a usar

• Planeación de la herencia de permisos

• Scripting de subsitios

• Hoja de trabajo

En este artículo se describe la planeación de la autorización y el control de acceso en la colección de sitios, el sitio y los niveles secundarios del sitio. No incluye información sobre la planeación de la seguridad de su servidor o de la granja de servidores. Para obtener más información acerca de la planeación de otros aspectos de seguridad, como los métodos de autenticación y cifrado, vea Planeación de la seguridad del sitio y el contenido (Office SharePoint Server).

La seguridad de los sitios se controla mediante la asignación de permisos a usuarios y grupos para un objeto protegible específico (como un sitio, una lista o un elemento). Al planear la seguridad del sitio, debe decidir:

• Hasta qué punto desea controlar los permisos de los objetos protegibles individuales. Por ejemplo, si desea controlar el acceso a todo el sitio o si desea usar una configuración de seguridad específica para una lista, una carpeta o un elemento en particular.

• Cómo desea categorizar y administrar los usuarios (mediante grupos de usuarios). Este artículo abarca los puntos esenciales de la seguridad para sitios y le ayuda a determinar los objetos protegibles a los que debe aplicar permisos específicos. Para obtener más información acerca de la categorización de usuarios en grupos, vea Elección de los grupos de seguridad que se usarán (Office SharePoint Server).

  Nota

  La forma en que interactúan los grupos y permisos ha cambiado significativamente desde la versión anterior, donde los grupos en el nivel de sitio se usaban para incluir tanto usuarios como permisos (es decir, cuando se agregaba un usuario a un grupo de sitio, se determinaban automáticamente los permisos que se le concedían al usuario para un sitio). En esta versión, se han separado los conceptos de grupos de usuarios y permisos: los grupos de SharePoint en el nivel de colección de sitios contienen usuarios, los niveles de permisos contienen permisos y los grupos no tienen permisos hasta que se les asigna un nivel de permisos para un objeto específico que se pueda proteger (como un sitio, una lista o biblioteca, una carpeta, un elemento o un documento).

Elementos de seguridad del sitio

Independientemente del tipo de sitio que cree, la seguridad del sitio incluye los cinco elementos siguientes:

• Permisos de usuarios individuales   Los permisos individuales ofrecen la posibilidad de realizar acciones específicas. Por ejemplo, el permiso Ver elementos ofrece al usuario la posibilidad de ver los elementos de una lista. Los administradores de la granja de servidores pueden controlar qué permisos están disponibles para la granja de servidores mediante la página Permisos de usuario para aplicación web de la Administración central (para abrir esta página, en la página Administración de aplicaciones, en Seguridad de aplicaciones, haga clic en Permisos de usuario para aplicación web). Para obtener información acerca de los permisos disponibles, vea User permissions and permission levels.

• Nivel de permisos   Conjunto predefinido de permisos que concede permiso para realizar acciones relacionadas. Los niveles de permisos predeterminados son: Acceso limitado, Lectura, Colaborar, Diseño y Control total. Por ejemplo, el nivel de permisos Lectura incluye los permisos Ver elementos, Abrir elementos, Ver páginas y Ver versiones (entre otros), todos los cuales son necesarios para leer documentos, elementos y páginas de un sitio de SharePoint. Los permisos se pueden incluir en varios niveles de permisos. Los niveles de permisos puede personalizarlos cualquier usuario asignado a un nivel de permisos que incluya el permiso Administrar permisos. Para obtener información acerca de los niveles de permisos predeterminados y qué permisos se incluyen en ellos, vea User permissions and permission levels.

• Usuario   Persona con una cuenta de usuario que se puede autenticar mediante el método de autenticación usado en el servidor. Puede agregar usuarios individuales y asignarles directamente un nivel de permiso a cada uno; no es necesario que los usuarios sean parte del grupo. Se recomienda asignar permisos a grupos, en lugar de a usuarios. Dado que no es eficaz mantener directamente las cuentas de usuario, sólo debe asignar permisos a usuarios individuales en casos excepcionales. Para obtener más información acerca de los tipos de cuentas de usuario, vea User permissions and permission levels.

• Grupo   Grupo de usuario. Puede ser un grupo de seguridad de Windows (por ejemplo, Departamento_A) que se agregue al sitio o un grupo de SharePoint (por ejemplo, Creadores del sitio, Miembros del sitio o Visitantes del sitio. A cada uno de los grupos de SharePoint se le asigna un nivel de permisos predeterminado, pero se puede cambiar el nivel de permisos de un grupo cuando sea necesario. Todos los usuarios que tengan asignado un nivel de permisos que incluya el permiso Crear grupos (incluido en el nivel de permisos Control total de forma predeterminada) pueden crear grupos personalizados de SharePoint.

• Objetivo protegible   A los usuarios o grupos se les asigna un nivel de permisos para un objeto protegible específico: sitio, lista, biblioteca, carpeta, documento o elemento. De forma predeterminada, los permisos para una lista, biblioteca, carpeta, documento o elemento se heredan del sitio, lista o biblioteca primarios. Sin embargo, cualquiera que tenga asignado un nivel de permisos para un objeto protegible determinado que incluya el permiso Administrar permisos puede cambiar los permisos para dicho objeto protegible. De forma predeterminada, los permisos se controlan inicialmente en el nivel de sitio y todas las listas y bibliotecas heredan los permisos del sitio. Use los permisos de nivel de lista, nivel de carpeta y nivel de elemento para controlar más detalladamente qué usuarios pueden ver o interactuar con el contenido del sitio. En cualquier momento, puede volver a heredar los permisos de una lista primaria, el sitio completo o un sitio primario.

Asignación de permisos

Puede asignar un nivel de permisos a un usuario o grupo para un objeto protegible específico (sitio, lista o elemento). Los usuarios individuales o grupos pueden tener diferentes niveles de permisos para diferentes objetos protegibles.

Nota

Puesto que mantener cuentas de usuario directamente resulta ineficaz, se recomienda usar en lo posible permisos de grupo. En concreto, si usa permisos específicos (vea la siguiente sección), debe usar grupos para evitar tener que realizar un seguimiento de las cuentas de usuario individuales. Los usuarios entran y salen de los equipos y cambian de responsabilidades con frecuencia, así que querrá evitar tener que realizar un seguimiento de todos esos cambios y actualizar continuamente los permisos para objetos protegibles de forma exclusiva.

En el siguiente diagrama se muestra cómo los usuarios y los grupos reciben niveles de permisos específicos para un objeto protegible en concreto.

Personalización avanzada de permisos y herencia de permisos

Puede usar permisos específicos (permisos en los niveles de lista o biblioteca, carpeta, elemento o documento) para controlar con mayor precisión las acciones que pueden realizar los usuarios en el sitio. Los siguientes objetos protegibles están disponibles para la asignación de permisos:

• Sitio   Controla el acceso a todo el sitio.

• Lista o biblioteca   Controla el acceso a una lista o biblioteca específicas.

• Carpeta   Controla el acceso a las propiedades de una carpeta (como el nombre de la carpeta).

• Elemento o documento   Controla el acceso a un elemento de lista o documento específicos.

Herencia de permisos y permisos con personalización avanzada

De forma predeterminada, los permisos de un sitio se heredan del sitio. Sin embargo, puede interrumpir esta herencia para cualquier objeto protegible en un nivel inferior de la jerarquía si modifica los permisos (mediante la asignación de un permiso exclusivo) de dicho objeto protegible. Por ejemplo, puede modificar los permisos de una biblioteca de documentos, lo que interrumpe la herencia del sitio. Sin embargo, la herencia sólo se interrumpe para ese objeto protegible específico para el que asignó permisos; el resto de permisos del sitio no experimentan cambios. Puede volver a heredar permisos de la lista o sitio primarios en cualquier momento.

Herencia de permisos y subsitios

Los propios sitios web son objetos protegibles a los que se pueden asignar permisos. Puede configurar subsitios para heredar permisos de un sitio primario o crear permisos exclusivos para un sitio determinado. La herencia de permisos es la forma más sencilla de administrar un grupo de sitios web. Sin embargo, si un subsitio hereda los permisos de su sitio primario, ese conjunto de permisos es compartido. Esto significa que los propietarios de los subsitios que heredan los permisos del sitio primario pueden modificar los permisos de dicho sitio primario. Si sólo desea cambiar los permisos del subsitio, debe interrumpir la herencia de permisos antes de realizar el cambio.

Los subsitios pueden heredar permisos de un sitio primario. Puede hacer que un subsitio deje de heredar permisos mediante la creación de permisos exclusivos. Esto copia los grupos, usuarios y niveles de permisos del sitio primario en el subsitio y, a continuación, interrumpe la herencia. Si cambia de permisos exclusivos a heredados, los usuarios, grupos y niveles de permisos empiezan a heredarse, y perderá todos los usuarios, grupos o niveles de permisos que haya definido de forma exclusiva en el subsitio. Los niveles de permisos también se pueden heredar (y, de forma predeterminada, se heredan), de modo que el nivel de permiso Lectura es igual, independientemente del objeto al que se aplique. Puede interrumpir dicha herencia si modifica el nivel de permiso. Por ejemplo, puede que no desee que el nivel de permiso Lectura de un subsitio determinado incluya el permiso Crear alertas.

Elección de los niveles de seguridad para el sitio

Cuando se crea la estructura de permisos, es importante encontrar el equilibrio entre la facilidad de administración, el rendimiento y la necesidad de controlar permisos específicos para elementos individuales. Si usa ampliamente permisos específicos:

• Empleará más tiempo en administrar los permisos.

• Es posible que Microsoft Office SharePoint Server deshabilite el almacenamiento en caché de los resultados si una colección de sitios contiene más de 10.000 listas únicas de control de acceso (ACL). También es posible que los usuarios experimenten un rendimiento más lento cuando intentan tener acceso al contenido de sitio. Para obtener más información acerca del almacenamiento en caché, vea Almacenamiento en caché en Office SharePoint Server 2007.

Del mismo modo que en cualquier servidor o sitio web, también es importante seguir el principio de privilegios mínimos a la hora de autorizar el acceso al sitio: los usuarios deben tener solo aquellos niveles de permiso que necesiten. Comience usando grupos estándar (por ejemplo, Miembros, Visitantes y Propietarios) y controlando los permisos en el nivel de sitio para que la administración sea lo más sencilla posible. Incluya a la mayoría de los usuarios en los grupos Visitantes o Miembros. Limite el número de personas del grupo Propietarios sólo a aquellos usuarios a los que permitirá cambiar la estructura, la configuración o la apariencia del sitio. De forma predeterminada, los usuarios del grupo Miembros pueden colaborar en el sitio, agregando o quitando elementos o documentos, pero no pueden cambiar la estructura, la configuración ni la apariencia del sitio. Puede crear grupos de SharePoint y niveles de permisos adicionales si necesita un mayor control sobre las acciones que pueden realizar los usuarios.

Si existen ciertas listas, bibliotecas, carpetas, elementos o documentos que contienen información confidencial y deben ser aún más seguros, puede conceder permisos a un grupo o usuario individual específicos. Sin embargo, tenga en cuenta que no es posible ver todos los permisos específicos de listas, bibliotecas, carpetas, elementos o documentos de un sitio. Esto significa que resulta difícil saber quién tiene permisos para qué objetos protegibles y dificulta restablecer cualquier permiso específico en bloque.

Planeación de la herencia de permisos

Resulta más sencillo administrar permisos cuando existe una jerarquía definida de permisos y permisos heredados. Se complica cuando algunas listas de un sitio tienen aplicados permisos específicos y cuando algunos sitios tienen subsitios con permisos exclusivos y subsitios con permisos heredados. En la medida de lo posible, organice los sitios y subsitios, y las listas y bibliotecas de modo que puedan compartir la mayoría de los permisos. Separe la información confidencial en sus propias listas, bibliotecas o subsitios.

Por ejemplo, resulta mucho más sencillo administrar un sitio con permisos heredados como en la siguiente tabla.

Objeto protegible	Descripción	Permisos exclusivos o heredados
SitioA	Página principal del grupo	Exclusivo
SitioA/SubsitioA	Grupo confidencial	Exclusivo
SitioA/SubsitioA/ListaA	Información confidencial	Exclusivo
SitioA/SubsitioA/BibliotecaA	Documentos confidenciales	Exclusivo
SitioA/SubsitioB	Información de proyecto compartida en grupo	Heredado
SitioA/SubsitioB/ListaB	Información no confidencial	Heredado
SitioA/SubsitioB/BibliotecaB	Documentos no confidenciales	Heredado

En comparación, no resulta tan sencillo administrar un sitio con permisos heredados como en la siguiente tabla.

Objeto protegible	Descripción	Permisos exclusivos o heredados
SitioA	Página principal del grupo	Exclusivo
SitioA/SubsitioA	Grupo confidencial	Exclusivo
SitioA/SubsitioA/ListaA	Información no confidencial	Exclusivo, pero con los mismos permisos que SitioA
SitioA/SubsitioA/BibliotecaA	Documentos no confidenciales, pero con uno o dos documentos confidenciales	Heredados, pero con permisos exclusivos en el nivel de documento
SitioA/SubsitioB	Información de proyecto compartida en grupo	Heredado
SitioA/SubsitioB/ListaB	Datos no confidenciales, pero con uno o dos elementos confidenciales	Heredados, pero con permisos exclusivos en el nivel de elemento
SitioA/SubsitioB/BibliotecaB	Documentos no confidenciales, pero con una carpeta especial que contiene documentos confidenciales	Heredados, pero con permisos exclusivos en el nivel de carpeta y documento

Scripting de subsitios

Si su entorno requiere el más alto nivel de aislamiento de contenido y de sitios, es posible que sea conveniente diseñar la estructura de sitios de Office SharePoint Server de forma que se minimicen los riesgos asociados con el uso de espacios de nombres URL contiguos. La configuración predeterminada del espacio de nombres URL de sitios de Office SharePoint Server podría dar lugar a un problema potencial de scripting de subsitios en el cual un usuario malintencionado podría realizar acciones en un sitio que excedan el nivel de permisos que ostente. Este problema se debe a que los sitios de Office SharePoint Server son límites de seguridad, y cualquier cantidad de dichos límites puede ser adyacente a otros sitios con el mismo nombre de host. Dado que los exploradores web solo consideran los nombres de host (y no los nombres de sitios) como límites de seguridad, en ciertas circunstancias, el contenido de scripts que residen en un sitio de Office SharePoint Server podría ejecutarse en otros sitios si los sitios comparten el nombre de host.

Office SharePoint Server autoriza el acceso al contenido en función de los derechos del usuario autenticado y de los grupos a los que pertenezca dicho usuario. Debido a esto, un script que se ejecuta en representación de un usuario puede realizar de forma eficaz cualquier acción autorizada para el usuario. El problema potencial se describe en el siguiente ejemplo:

• El usuario A y el usuario B tienen, respectivamente, sus propias colecciones de sitios de Office SharePoint Server: http://my/sites/UserA y http://my/sites/UserB.

• El usuario A tiene permisos de colaborador en su propio sitio, pero no tiene permisos en el sitio del usuario B. Cuando el usuario A se desplaza al sitio del usuario B, obtiene un error de acceso denegado.

• Sin embargo, el usuario A puede cargar en su sitio un documento que contenga un script malintencionado y conceder acceso de lectura al usuario B para dicho script. Si el usuario B ve el documento creado por el usuario A, el script malintencionado podría ejecutarse sin advertencia usando las credenciales del usuario B. En el contexto de muchos exploradores web disponibles, el script no sobrepasa un límite de seguridad y la ejecución del script no se considera un evento de acceso entre dominios.

Este problema se produce porque el sitio de Office SharePoint Server del usuario B y el sitio de Office SharePoint Server del usuario A comparten el nombre de host. En esta estructura de sitios, el usuario B y el usuario A deben poder confiar mutuamente en que no intentarán realizar un ataque de scripting. Si los grupos de colaboradores no tienen confianza mutua, se deben particionar sus sitios con nombres de host independientes. El problema de scripting es de gran importancia en la mayoría de escenarios de colaboración de Office SharePoint Server, más que en los escenarios de portales estructurados o de publicación en Internet, ya que el usuario malintencionado debe tener acceso de colaborador para realizar un ataque de scripting en un subsitio.

Dado que el uso de Office SharePoint Server crece, especialmente el uso de intranet en organizaciones grandes, y que varios usuarios de las organizaciones se convierten en colaboradores en alguna medida para una implementación basada en rutas de acceso (por ejemplo, http://my o http://corp), la capacidad de confiar en todos los colaboradores de ese host puede suponer un reto. Esto ocurre especialmente en escenarios en los que se utiliza creación de sitios sin intervención del administrador y en los que los subsitios adquieren un nivel profundo de anidamiento. Puede diseñar su implementación de Office SharePoint Server para minimizar estos problemas. Para obtener información acerca del diseño de una arquitectura de información, vea Determinación de la arquitectura de la información del sitio.

Para obtener información acerca del diseño de colecciones de sitios, sitios y subsitios de Office SharePoint Server, vea Determinación de los sitios y subsitios.

Para obtener instrucciones de seguridad adicionales, vea el tema sobre el centro de recursos de seguridad de Productos y Tecnologías de SharePoint (en inglés) (https://go.microsoft.com/fwlink/?linkid=148056&clcid=0xC0A) (en inglés).

Uso de colecciones de sitios con nombre de host

El uso de colecciones de sitios con nombre de host permite aumentar la seguridad del contenido y de los sitios al permitir la creación de varias colecciones de sitios de nivel raíz dentro de una aplicación web. Por ejemplo, los administradores de las organizaciones de host usan colecciones de sitios con nombre de host para crear varios sitios con nombre de dominio. Windows SharePoint Services 3.0 admite la creación de varios dominios en una única aplicación web. Esto permite colocar varios dominios, como http://UserA.collab.mycorp.com y http://UserB.collab.mycorp.com, en diferentes colecciones de sitios dentro de la misma aplicación web. Sin embargo, se deben tener en cuenta los siguientes aspectos cuando se usa este método para solucionar el problema de scripting en subsitios:

• El uso de nombres de host descriptivos, como http://UserB.collab.mycorp.com, puede ocasionar problemas de DNS, ya que es necesario dirigir todos los nombres de host descriptivos a la implementación correcta de Office SharePoint Server. Los nombres de dominio completos pueden mitigar este problema mediante el uso de entradas comodín de DNS, por ejemplo, *.collab.mycorp.com.

• Office SharePoint Server admite la creación y la administración sin intervención del administrador de colecciones de sitios basadas en rutas de acceso. La implementación de sitios con el nombre de encabezado de host puede generar una carga operativa para el aprovisionamiento del sitio. Para obtener información acerca de la creación de sitios sin intervención del administrador, vea Configuración de la creación de sitios sin intervención del administrador.

Para obtener más información acerca de colecciones de sitios con nombre de host, vea Planeación de colecciones de sitios con nombre de host (Office SharePoint Server).

Desplazamiento de contenido a un nombre de host diferente

Si tiene contenido que desea mover a un nombre de host diferente, tenga en cuenta las siguientes instrucciones:

• Puede mover cantidades pequeñas de contenido, incluidas listas y bibliotecas de documentos, mediante el uso de características de cliente, como Enviar a, Otra ubicación, Abrir con la vista del explorador (para documentos) o Exportar a hoja de cálculo (para listas).

• Para mover cantidades grandes de contenido, incluidos sitios y colecciones de sitios, considere crear una copia de seguridad del contenido y restaurar el contenido. Para obtener información acerca de copias de seguridad y restauración del contenido, vea Copia de seguridad y restauración de colecciones de sitios mediante herramientas integradas (Office SharePoint Server 2007).

• Para mover cantidades grandes de datos, considere crear una nueva colección de sitios con un nombre de host diferente.

• Considere crear una ruta de acceso administrada en el mismo nivel que el sitio de la ubicación original para hospedar la colección de sitios. Mediante la definición de una ruta de acceso administrada, puede especificar las rutas de acceso del espacio de nombres URL de una aplicación web que se usarán para las colecciones de sitios. Esto es importante, ya que, en muchos casos, el contenido de Office SharePoint Server usa rutas de acceso relativas al servidor. Durante la restauración de contenido en una ubicación nueva, Office SharePoint Server puede reparar el nombre de host de una dirección URL, pero una falta de coincidencia de nivel en este momento puede ocasionar un error en la operación de restauración. Para obtener más información acerca de rutas de acceso administradas, vea Definición de rutas de acceso administradas.

Hoja de trabajo

En la hoja de trabajo de seguridad de contenidos y sitios (en inglés) (https://go.microsoft.com/fwlink/?linkid=73135&clcid=0xC0A) (en inglés), especifique la jerarquía de sitios y, después, enumere los permisos necesarios en cada nivel de la jerarquía y cualquier herencia de permisos.

Descarga de este libro

Este tema se incluye en 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 descargable para Office SharePoint Server 2007.