GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

MOSS, Seguridad y Permisos. Conceptos Básicos.


Este artículo explica como funciona la Seguridad y los Permisos en las Colecciones de Sitios de MOSS, incluyendo en sus SubSitios, Librerías de Documentos, Listas, Carpetas, SubCarpetas, Documentos, etc. Se explican las configuraciones de Directivas de Aplicación Web (Policy for Web Application), la configuración de Administradores de Colecciones de Sitios, como comprobar la Herencia de Permisos (así como la forma de romper la Herencia o restablecerla), cómo funcionan los Grupos de SharePoint, etc.

Seguridad y Permisos en Sitios y SubSitios de MOSS

La organización de permisos en MOSS, se realiza en base a los Niveles de Permisos (Site Permission Level). Los Niveles de Permisos (Site Permission Level) son un conjunto de permisos (denominados Site Permissions) que asociamos a un nombre, como si fuera un Role. Por ejemplo, podemos crear un Nivel de Permisos (Site Permission Level) denominado Permisos ejecutivos Business Intelligence, y sobre este Nivel de Permisos habilitar los permisos (mejor dicho, Site Permissions) deseados. Es importante, tener en cuenta que MOSS incluye de serie un conjunto predefinido de Niveles de Permisos (Site Permission Level), que podemos utilizar.

El siguiente paso, es hacer miembro de dichos Niveles de Permisos (Site Permission Level, o de dichos Roles si así lo vemos más claro), a los usuarios deseados. Esto lo podemos hacer, directamente sobre los Usuarios y/o Grupos de Directorio Activo (o de la máquina local, en una instalación MOSS en Stand-Alone), o sobre Grupos de SharePoint (esta última opción, la más recomendable).

Los Grupos de SharePoint, permite agrupar Usuarios y/o Grupos de Directorio Activo (o de la máquina local), de tal modo que podamos asignar los Niveles de Permisos (Site Permission Level) a Grupos de SharePoint, y así limitar la posterior administración de la seguridad, a la pertenencia a dichos Grupos de SharePoint. De hecho, sería posible hacer miembro de nuestros Grupos de SharePoint, a Grupos de Directorio Activo, delegando así esta administración a Directorio Activo (que administrará la pertenencia a los Grupos).

Así, la Recomendación General, sería utilizar Grupos de Directorio Activo donde gestionar la pertenencia de Usuarios en función de las funciones que deban poder realizar en MOSS, para seguidamente utilizar Grupos de SharePoint, asignando a cada Grupo de SharePoint los Niveles de Permisos (Site Permission Level) que se necesite, en función de los Permisos (Site Permissions) necesarios.

Este abanico o árbol de posibilidades, queda reflejado en la siguiente figura:

Hasta aquí, bien. Pero debemos tener en cuenta, que con todo lo anterior, tan sólo estamos estableciendo permisos a nivel de Sitio, viendo un Sitio de MOSS como un Contenedor (tomemos este término de Contenedor, como algo genérico).

El Modelo de Seguridad de MOSS se basa en Contenedores, Niveles de Permisos (Site Permission Levels) y Herencia.

Sabemos que una Colección de Sitios, está formada por un Sitio Principal o Sitio de Primer Nivel, sobre el cual podemos (entre otras cosas) crear SubSitios, así como Librerías de Documentos y Listas. Además, sobre las Librerías de Documentos es posible crear Carpetas y SubCarpetas (como se hace en cualquier sistema de ficheros). A su vez, cada SubSitio puede contener otros SubSitios, Librerías de Documentos y Listas (con sus Carpetas y Subcarpetas), y así sucesivamente, formando una Jerarquía de Contenedores (Sitios, Listas, Carpetas y Documentos).

Una vez que tenemos esto en mente esta Jerarquía, debemos tener en cuenta que sobre dicha Jerarquía de Contenedores, los Niveles de Permisos (Site Permission Level) pueden o no Heredarse de un Contenedor Primario a un Contenedor Secundario. Y dicha configuración de Herencia, puede cambiarse. Es decir, podemos crear un SubSitio sin Heredar los Permisos (Site Permission Level) de su Sitio Primario, y posteriormente si nos arrepentimos, podemos cambiar esta configuración para que se Herede (lo mismo ocurre con Listas, Carpetas, SubCarpetas y Documentos). Es algo similar a como ocurre con el sistema de ficheros NTFS, pero más sencillo: o se Herada todo o no se Hereda nada. No cabe la posibilidad de Heredar del Contenedor Primario y adicionalmente agregar permisos adicionales sobre el Contenedor Secundario: O se Hereda todo, o se rompe la Herencia y no se Hereda nada.

A continuación se muestra un diagrama que representa esta Jerarquía de Contenedores para una Colección de Sitios, de forma conceptual, e incluyendo sólo hasta el nivel de SubSubSitio (aunque podrían existir muchos más subniveles).

Por último, otro detalle muy importante, en lo relacionado con los permisos o niveles de permisos: En MOSS no se puede denegar Permisos ni Niveles de Permisos. Sólo existe una excepción, como veremos a continuación con las Policy for Web Application. Pero a nivel de un Sitio, Librería de Documentos, Lista, etc., no se puede Denegar. O concedemos permisos o NO concedemos permisos (ya sea heredándolos o concediéndolos explícitamente), pero no es posible denegar (o yo no sé como, vamos). De nuevo, una diferencia, frente a como ocurre en otros sistemas (ej: Sistema de Ficheros NTFS). Curioso, cuanto menos.

Conceder permisos a nivel de Aplicación Web: Policy for Web Application

Hasta aquí, bien. Pero además, sabemos que en MOSS existe el concepto de la Aplicación Web, que podemos verla como el Contenedor Principal, de tal modo, que sobre una Aplicación Web, podemos hospedar múltiples Colecciones de Sitios. Bien, pues a nivel de Aplicación Web de MOSS pueden definirse Políticas de acceso (Policy for Web Application), a través de las cuales puede concederse ciertos permisos a un Usuario o Grupo, de forma masiva sobre todas las Colecciones de Sitios y SubSitios existentes en la Aplicación Web. Eso sí, a este nivel, sólo pueden establecerse los siguientes permisos:

  • Full Control.
  • Full Read.
  • Deny Write.
  • Deny All.

Suele ser práctica habitual, conceder permisos de Full Control desde las Directivas de Aplicación Web (Policy for Web Application), a usuarios administradores de la Granja MOSS, cuentas de servicio para operaciones de Backup y Restore, etc.

Para conceder permisos a nivel de Aplicación Web, es necesario acceder a la Consola de Administración Central, y en la pestaña de Application Management, seleccionar la opción Policy for Web Application de la sección Application Security.

En la página Policy for Web Application, podremos agregar nuevos Usuarios (o Grupos) a los que conceder permisos, editar los permisos existentes, etc. Es importante, fijarse en el desplegable Web Application, para garantizar que estamos gestionando permisos sobre la Aplicación Web deseada.

Los Administradores de la Colección de Sitios

Otra forma de conceder permisos, es mediante el establecimiento de los Administradores de la Colección de Sitios, quienes tendrán permiso de control total sobre todos los Sitios de la Colección de Sitios.

Existen dos formas diferentes de establecer los Administradores de una Colección de Sitios.

  • Desde la Consola de Administración Central. Desde aquí, los Administradores de la Granja, podrán establecer el Administrador de la Colección de Sitios, y opcionalmente, también un Administrador Secundario de la Colección de Sitios.

    Para ello, accederemos a la Consola de Administración Central, seleccionaremos la pestaña Application Management, y seguidamente seleccionaremos la opción Site Collection Administrators de la sección SharePoint Site Management. En la página Site Collection Administrators, podremos establecer el Administrador de la Colección de Sitios, y opcionalmente un Administrador Secundario de la Colección de Sitios.

  • Desde la Página de Administración del Sitio Principal. También es posible agregar Administradores de la Colección de Sitios desde el propio Sitio Principal, con el detalle, de que en este caso podremos agregar a varios usuarios como Administradores de la Colección de Sitios (no está limitado a dos, como ocurre al hacerlo desde la Consola de Administración Central).

    Para ello, accederemos al Sitio Principal. Seguidamente, seleccionaremos la opción Site Actions -> Site Settings, y a continuación seleccionaremos la opción Site Collection administrators de la sección Users and Permissions.

Los Niveles de Permisos en Sitios de MOSS (Site Permission Level)

Los Niveles de Permiso (Site Permission Level), definen conjunto de permisos que podremos asignar a los Usuarios sobre Contenedores (Site, SubSite, Lista, etc.) específicos.

Para ver los Niveles de Permiso (Site Permission Level) definidos en un Sitio de MOSS, deberemos conectarnos con un navegador al Sitio, y realizar lo siguiente:

  • Seleccionar la opción Site Actions -> Site Settings.
  • En la página Site Settings (_layouts/settings.html) seleccionar la opción Advanced permissions de la sección User and Permissions.
  • En la página Permissions, seleccionar Settings -> Permission Level.

En la página Permission Levels podemos crear nuevos Niveles de Permisos (Permission Levels), así como modificar los existentes.

MOSS 2007 viene con dos Niveles de Permisos (Site Permission Level) predefinidos, que no se pueden eliminar ni modificar:

  • Full Control.
  • Limited Access.

Adicionalmente, viene con otros tres Niveles de Permisos (Site Permission Level) predefinidos, pero estos a diferencia de los anteriores, son susceptibles de ser modificados o eliminados (si así lo deseamos):

  • Design.
  • Contribute.
  • Read.

Además, en función de las Features (Características) que tengamos habilitados, y de la Plantilla de Sitio utilizada para la creación del Sitio MOSS, nos podemos encontrar con Niveles de Permisos (Site Permission Level) predefinidos adicionales, también susceptibles de ser modificados o eliminados (si así lo deseamos), como por ejemplo:

  • Manage Hierarchy.
  • Approve.
  • Restricted Access.
  • View Only.

En caso de crear nuevos Niveles de Permisos (Permission Levels), deberemos asignarles los Permisos (Site Permissions) que deseemos.

Los Permisos de los Sitios de MOSS (Site Permissions)

A continuación se incluyen los posibles Permisos (Site Permissions) que pueden concederse en MOSS, los cuales se encuentran clasificados en tres tipos (List Permissions, Site Permissions, Personal Permissions).

  • List Permissions
    • Manage Lists - Create and delete lists, add or remove columns in a list, and add or remove public views of a list.
    • Override Check Out - Discard or check in a document which is checked out to another user.
    • Add Items - Add items to lists, add documents to document libraries, and add Web discussion comments.
    • Edit Items - Edit items in lists, edit documents in document libraries, edit Web discussion comments in documents, and customize Web Part Pages in document libraries.
    • Delete Items - Delete items from a list, documents from a document library, and Web discussion comments in documents.
    • View Items - View items in lists, documents in document libraries, and view Web discussion comments.
    • Approve Items - Approve a minor version of a list item or document.
    • Open Items - View the source of documents with server-side file handlers.
    • View Versions - View past versions of a list item or document.
    • Delete Versions - Delete past versions of a list item or document.
    • Create Alerts - Create e-mail alerts.
  • Site Permissions
    • Manage Permissions - Create and change permission levels on the Web site and assign permissions to users and groups.
    • View Usage Data - View reports on Web site usage.
    • Create Subsites - Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites.
    • Manage Web Site - Grants the ability to perform all administration tasks for the Web site as well as manage content.
    • Add and Customize Pages - Add, change, or delete HTML pages or Web Part Pages, and edit the Web site using a Windows SharePoint Services-compatible editor.
    • Apply Themes and Borders - Apply a theme or borders to the entire Web site.
    • Apply Style Sheets - Apply a style sheet (.CSS file) to the Web site.
    • Create Groups - Create a group of users that can be used anywhere within the site collection.
    • Browse Directories - Enumerate files and folders in a Web site using SharePoint Designer and Web DAV interfaces.
    • Use Self-Service Site Creation - Create a Web site using Self-Service Site Creation.
    • View Pages - View pages in a Web site.
    • Enumerate Permissions - Enumerate permissions on the Web site, list, folder, document, or list item.
    • Browse User Information - View information about users of the Web site.
    • Manage Alerts - Manage alerts for all users of the Web site.
    • Use Remote Interfaces - Use SOAP, Web DAV, or SharePoint Designer interfaces to access the Web site.
    • Use Client Integration Features - Use features which launch client applications. Without this permission, users will have to work on documents locally and upload their changes.
    • Open - Allows users to open a Web site, list, or folder in order to access items inside that container.
    • Edit Personal User Information - Allows a user to change his or her own user information, such as adding a picture.
  • Personal Permissions
    • Manage Personal Views - Create, change, and delete personal views of lists.
    • Add/Remove Personal Web Parts - Add or remove personal Web Parts on a Web Part Page.
    • Update Personal Web Parts - Update Web Parts to display personalized information.

Usuarios y Grupos en MOSS

Para Administrar los Usuarios y Grupos de un Site, deberemos conectarnos con un navegador al Sitio, y realizar lo siguiente:

  • Seleccionar la opción Site Actions -> Site Settings.
  • En la página Site Settings (_layouts/settings.html) seleccionar la opción Advanced permissions o la opción People and Groups, de la sección User and Permissions.

A partir de aquí, podemos comprobar los Grupos existentes (tantos Grupos de SharePoint como Grupos de Directorio Activo o Locales de la máquina) desde la opción Groups y desde la opción Groups -> More del menú lateral. En el caso de Grupos de SharePoint, podremos modificar su pertenencia (qué Usuarios y/o Grupos de Directorio Activo o Locales de la máquina pertenecen a dicho Grupo de SharePoint).

Del mismo modo, a través de la opción All People podremos comprobar los Usuarios existentes en el Sitio. Un detalle muy importante: Pueden existir usuarios que aparezcan aquí, que no tengan permisos de acceso. Un error común, es pensar que todos los usuarios que aquí aparecen, tienen permisos sobre el Sitio de MOSS, lo cual no tiene porque ser así. Para ver los permisos de acceso al Sitio, debe utilizarse la opción Site Permissions. Del mismo modo, un Usuario puede tener permisos de acceso al Sitio, pero luego no tenerlos en Librerías de Documentos, Listas o SubSitios.

También podremos conceder acceso a nuevos Usuarios o Grupos (sean de Directorio Activo o Locales de la máquina) desde la opción New -> Add User (deberemos especificar el Usuario o Grupo de Directorio Activo o Local de la máquina, y los Niveles de Permisos - Site Permission Leves - deseados).

Por último, desde la opción Site Permissions del menú lateral, es posible ver y modificar todas las concesiones de Niveles de Permisos (Site Level Permissions) existentes a nivel de Sitio de MOSS.

Permisos en Listas, Librerías de Documentos, Carpetas y SubCarpetas, etc.

Hasta ahora, hemos estado centrados principalmente en las configuraciones de Seguridad y Permisos relativas al Sitio Principal y a SubSitios.

Sin embargo, igual de importante es la configuración de Seguridad y Permisos relativas a Listas, Librerías de Documentos, Carpetas y SubCarpetas, etc.

Por ejemplo, a nivel de Listas o Librerías de Documentos de MOSS, una vez que nos posicionamos en la Lista o Librería de Documentos deseada, podemos utilizar la opción Settings -> Document Library Settings (o Settings -> List Settings en caso de una Lista).

Seguidamente, click en Permissions for this document library (o en Permissions for this list en caso de una Lista). Con esto, accederemos a la configuración de Permisos de la Librería de Documentos o Lista correspondiente, como se muestra en la siguiente pantalla capturada.

Es importante fijarse en el mensaje que aparece en la parte superior, el cual nos indicará si se está Heredando o si no se está Heredando. En la pantalla anterior, como puede comprobarse, NO se está Heredando. Si se desea, se puede utilizar la opción Actions -> Inherit Permmissions para restablecer la Herencia, o en caso contrario, modificar la configuración de permisos.

En caso de que se estuviese Heredando la configuración de Permisos y Seguridad, sería posible utilizar la opción Actions -> Edit Permissions, de tal modo que se copie la configuración de permisos que actualmente se está Heredando, y a partir de aquí, podamos modificar dicha configuración de Seguridad y Permisos.

Con las Carpetas y SubCarpetas ocurre lo mismo. En este caso, deberemos desplegar el menú de la Carpeta o SubCarpeta deseada, y utilizar la opción Manage Permissions, como se muestra en la siguiente pantalla capturada.

Y vuelve a ser lo mismo. Ahora podremos comprobar si estamos Heredando o no estamos Heredando la configuración de Seguridad y Permisos, y en consecuencia, romper la Herencia o volver a restablecer la Herecia, así como modificar la configuración de Seguridad y Permisos de la Carpeta o SubCarpeta (en caso de que no estemos Heredando).

Lo que acabamos de ver con una Carpeta o SubCarpeta, ocurre también con los Documentos, es decir, es posible romper la Herencia de Seguridad y Permisos sobre un documento específico (y sobre el resto no), y configurar sobre el mismo los Permisos.

Con los SubSitios ocurre más de lo mismo.




Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Junio de 2017 (3)
Mayo de 2017 (1)
Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Copyright © 2007 GuilleSQL, todos los derechos reservados.