Siguiendo con la serie de posts de buenas prácticas y aspectos a tener en cuenta a la hora de diseñar soluciones en WSSv3, en el segundo post de la serie vamos a tratar cuestiones relativas a la seguridad en sitios de WSSv3.
La meta de esta fase es establecer que mecanismos de seguridad se van a utilizar a la hora de acceder a sitios de WSSv3 y a sus contenidos. Para lograr esta meta, hay que cubrir algunos de los siguientes puntos:
- Los distintos niveles de permisos de acceso tanto a los sitios de WSSv3 como a los contenidos. Es importante recordar que en WSSv3 se ha añadido un nuevo modelo de seguridad y unas nuevas características de seguridad que hacen más fácil controlar quien tiene acceso a los distintos contenidos de un sitio (Recordemos que en WSSv3 hay seguridad a todos los niveles, llegando hasta nivel de elemento o documento).
- Los mecanismos de autenticación utilizados para acceder a los sitios: Windows, basada en formularios, mixta, customizado, etc.
Seguridad a Nivel de Sitio
La seguridad a nivel de sitio se controla asignando permisos a usuarios y grupos sobre elementos securizables de WSSv3: un sitio, una lista o un elemento de una lista. Cuando se hace el planning de la seguridad de un sitio, hay que decidir:
- Hasta qué nivel se quiere controlar los permisos de acceso a los distintos componentes de WSSv3: ¿Es suficiente con establecer permisos para controlar el acceso a nivel de sitio? ¿O se necesitan configuraciones específicas de seguridad para listas, carpetas o elementos?
- Como se van a categorizar y gestionar los usuarios y los grupos de usuarios definidos.
La seguridad a nivel de sitio debe considerar los siguientes elementos:
- Permisos individuales de usuario, garantizan la capacidad de que un usuario pueda realizar o no acciones específicas. Por ejemplo, el permiso View Items permite que el usuario pueda visualizar todos los elementos de una lista. Estos permisos se gestionan desde la Administración Central de Sharepoint, en la sección Application Security -> User Permissions For Web Application (a la que se accede desde la pestaña Application Management).
- Nivel de permiso, WSSv3 define un conjunto de niveles de permisos pre-definidos que permiten realizar ciertas acciones. Los niveles por defecto son: Limited Acces, Read, Contribute, Design, y Full Control. Cada uno de estos niveles a su vez incluye una serie de permisos individuales. Por ejemplo, el nivel Read incluye: View Items, Open Items, View Pages y View Versions, los cuales son necesarios para visualizar documentos, elementos y páginas de un sitio de WSSv3.
- Usuario, es una persona con una cuenta de usuario que puede ser autenticada por el método de autenticación usado en el servidor. Buena Práctica: Aunque se pueden añadir nuevos usuarios y permisos a nivel de usuario individual sin que pertenezcan a un grupo, es recomendable asignar permisos a nivel de grupo, e incluir los usuarios en los grupos que correspondan (Es ineficiente, salvo excepciones, mantener cuentas individuales de usuario). Por ejemplo, usar grupos de usuarios es más flexible para situaciones tan habituales como movimientos de personas de un equipo a otro porque se ha producido un cambio de rol o responsabilidad.
- Grupo, es un grupo de usuarios. Los grupos añadidos a un sitio de WSSv3 pueden ser directamente grupos de Windows (como un departamento) o directamente de Sharepoint (Site Owners, Site Members, Site Visitor o cualquier otro que definamos). Cada grupo de Sharepoint tiene asociado por defecto un nivel de permisos.
- Objetos securizables, en WSSv3 se pueden establecer niveles de permisos a nivel de sitio, lista, librería de documentos, carpeta, documento o elemento. Por defecto, los permisos para una lista, librería, carpeta, documento o elemento se heredan del sitio padre o de la lista o librería de documentos padre. Esta herencia se puede romper en cualquier momento, y a nivel de objeto individual (el resto de permisos del sitio permanece inalterado), editando los permisos de los objetos a los que se les quiera aplicar unos ciertos permisos.
Herencia de Permisos y Subsitios
Como hemos visto, en WSSv3 un sitio es en sí mismo un objeto securizable al que se le pueden asignar una serie de permisos. Cuando hablamos de subsitios dentro de un sitio de Sharepoint, podemos configurarlos para que hereden (opción por defecto al crear un subsitio) los permisos del sitio padre, o bien crear unos permisos únicos para el sitio. La herencia de permisos es el mecanismo más sencillo de gestionar un conjunto de sitios web. Sin embargo, hay un inconveniente: los permisos se comparten, de modo que los usuarios propietarios de un cierto subsitio con capacidad para editar sus permisos podrán editar también los permisos del sitio padre. Si se quiere cambiar los permisos sólo en el subsitio, será necesario romper la herencia, y a continuación realizar los cambios deseados.
¿Cómo se rompe la herencia de permisos? Como hemos comentado, la herencia se rompe en el momento en que especificamos que deseamos crear permisos únicos para un subsitio. En ese momento, se copian en el subsitio los grupos, usuarios y niveles de permisos del sitio padre, y se rompe la herencia. El proceso contrario también es posible, es decir, en cualquier momento puedo configurar un subistio para que herede del padre. Ahora bien, en este caso hay que tener en cuenta que se perderá todo grupo, usuario o nivel de permiso creado a nivel particular del subsitio (y que por tanto no exista en el sitio padre).
El proceso contrario también es posible, es decir, en cualquier momento puedo configurar un subistio para que herede del padre. Ahora bien, en este caso hay que tener en cuenta que se perderá todo grupo, usuario o nivel de permiso creado a nivel particular del subsitio (y que por tanto no exista en el sitio padre).
Nota: La misma filosofía de herencia y rotura de herencia que hemos descrito para permisos individuales puede ser rota en una capa de agregación de permisos superior (lo que en WSSv3 se llama Nivel de Permiso). Por ejemplo, podríamos romper la herencia del nivel Read porque no queramos que en un cierto subsitio incluir el permiso Create Alerts.
¿Qúe niveles de seguridad escogemos para un sitio?
Como suele suceder con este tipo de preguntas, la respuesta no es sencilla. Al crear la estructura de permisos hay que encontrar el balance adecuado entre factores como rendimiento, facilidad de administración o la necesidad de controlar permisos específicos para ítems individuales de WSSv3. Si decidimos utilizar una estructura de permisos con una granularidad muy fina, nos complicaremos la gestión de los permisos (necesitaremos más tiempo), y muy probablemente penalizaremos el rendimiento de acceso a los contenidos de nuestro sitio. La idea, por tanto, pasa por aplicar el principio de que los usuarios deberían tener solamente los niveles de permisos que realmente van a necesitar.
En general, al planear la estructura de permisos para sitios de WSSv3 se recomienda empezar utilizando los grupos estándar de WSSv3: Members, Visitors y Owners, y controlar los permisos a nivel de sitio para facilitar la labor administrativa.
Planeando la herencia de permisos
Cuanto más clara es la jerarquía de permisos y la herencia, más fácil va ser la gestión de los mismos. Para lograrlo, hay que estructurar y ordenar los sitios y subsitios, librerías y listas de manera que compartan el mayor número posible de permisos. También hay que separar los datos confidenciales de los confidenciales y agruparlos en sus propias listas, librerías o subsitos. Un ejemplo de buena estructuración de un sitio que facilita la definición de la jerarquía de sitios y la herencia es el siguiente:
|
Objeto a Securizar |
Descripción |
¿Permisos Únicos o Heredados? |
|
Sitio A |
Página Principal |
Únicos |
|
Sitio A / Subsitio A |
Información Confidencial |
Únicos |
|
Sitio A / Subsitio A / Lista A |
Datos Confidenciales |
Únicos |
|
Sitio A / Subsitio A / Librería B |
Documentos Confidenciales |
Únicos |
|
Sitio A / Subsitio B |
Información de Proyecto Compartida |
Heredados |
|
Sitio A / Subsitio B / Lista B |
Datos no Confidenciales |
Heredados |
|
Sitio A / Subsitio V / Librería B |
Documentos no Confidenciales |
Heredados |
Niveles de Permisos y Grupos a Utilizar
Una de las tareas más importantes cuando se está diseñando la seguridad de sitios y contenidos en WSSv3 es como categorizar los usuarios que van a acceder a los mismos y que niveles de permisos se van a utilizar. Como comentábamos anteriormente, tenemos unos Grupos por Defecto en WSSv3 y unos Niveles de Permisos por Defecto en WSSv3. Estos grupos y niveles de permisos que por defecto tenemos disponibles en WSSv3 están pensados para resolver las situaciones más típicas, pero podrían no ser suficientes por las características particulares de la organización en la que vamos a implantar nuestras soluciones de WSSv3.
· Grupos por defecto en WSSv3, los grupos en WSSv3 pueden estar formados por una serie de usuarios individuales de WSSv3, corresponderse con un grupo de Windows o ser una combinación de ambos. La idead de los grupos en WSSv3 no es conferir un cierto nivel de acceso a un sitio, sino actuar como unidad de agrupación y categorización de una serie de usuarios. Por defecto, WSSv3 incluye los siguientes grupos:
|
Nombre del Grupo |
Nivel de Permisos por Defecto |
|
Nombre del Sitio \ Visitors |
Read |
|
Nombre del Sitio \ Members |
Contribute |
|
Nombre del Sitio \ Owners |
Full Control |
Además de los grupos anteriores, existen usuarios y grupos especiales para realizar tareas a nivel de administración:
o Administradores de Site Collection, que tiene control completo sobre todos los sitios de un Site Collection, pueden auditar todos los contenidos y recibir alertas administrativas. La creación de estos usuarios se realiza en el momento de creación de un Site Collection, y se pueden cambiar desde la Administración Central del Sitio o a nivel de Sitio.
o Administradores de Granja, que controlan que usuarios pueden tocar la configuración del servidor y granja de servidores. Por defecto, los usuarios de este grupo no tienen acceso a los contenidos de los sitios, para ello deben configurarse como propietarios de los mismos (añadiéndoles al grupo Administradores de Site Collection). Este grupo sólo se usa desde la Administración Central de WSSv3.
o Administradores, que son miembros del grupo de Administradores del servidor local donde tenemos instalado WSSv3 y pueden realizar, además de todas las tareas de los administradores de granja, las siguientes acciones:
- Instalar nuevos productos y aplicaciones.
- Desplegar Web Parts y Features en la Global Assembly Cache.
- Crear nuevas Web Applications y nuevos sitios Web en el IIS.
- Iniciar / Reiniciar servicios.
· Niveles de permisos por defecto en WSSv3, la capacidad para visualizar, cambiar o gestionar un sitio particular de WSSv3 es determinada por el nivel de permisos que se asigne a un usuario individual o un grupo. Este nivel de permisos controla todos los permisos para el sitio y todos los subsitios, listas, librerías de documentos, carpetas, y elementos que hereden los permisos del padre. Los permisos por defecto que están disponibles son los siguientes:
|
Nivel de Permiso |
Descripción de las acciones que permite |
|
Limited Access |
Permisos para visualizar ciertas listas, librerías de documentos, elementos o documentos. |
|
Read |
Permisos para visualizar elementos en las páginas del sitio. |
|
Contribute |
Permisos para añadir o modificar elementos en páginas del sito o en listas y librerías de documentos. |
|
Design |
Permisos para cambiar el layout de las páginas del sitio. |
|
Full Control |
Todos los permisos. |
¿Cuándo necesitamos crear grupos customizados?
Básicamente, se necesitarán crear grupos customizados en las siguientes situaciones:
- Los roles de la organización no quedan cubiertos por los grupos que por defecto ofrece WSSv3. Así, por ejemplo puede ocurrir que además de tener un Grupo de usuarios con el nivel de permisos Designer, necesitemos definir un nuevo grupo que se encargue de publicar contenidos en el sitio (Publishers).
- Que en nuestra organización se utilicen ciertas nomenclaturas para ciertos Roles. Por ejemplo, supongamos que hemos concebido un sitio para vender los productos de nuestra organización, y queremos crear un grupo Customers para diferenciar a nuestros clientes de otros usuarios que pueden visualizar los productos.
- Cuando se quiere tener una correspondencia uno a uno entre los grupos de WSSv3 y os grupos de usuarios de Windows.
- Simplemente porque se prefieran otros grupos de usuarios.
¿Cuándo necesitamos niveles de permisos customizados?
En este caso, hay que considerar las siguientes situaciones:
- Uno de los niveles de permisos por defecto incluya todos los permisos necesarios, excepto uno o varios específicos al tipo de acciones o tareas que ciertos usuarios puedan realizar en el sitio, y que por lo tanto tienen que ser añadidos.
- Uno de los niveles de permisos por defecto incluye un permiso que no necesitamos.
- Se necesita excluir varios permisos de un cierto nivel de permisos, por lo que tiene más sentido definir un nuevo nivel.
- Se necesita definir un cierto conjunto de permisos únicos para un nuevo nivel de permisos.
Escoger Grupos Seguros
Como hemos comentado, en WSSv3 podemos tener dos tipos de grupos: los propios de Sharepoint (bien grupos por defecto o creados por nosotros mismos) y grupos de Windows, que por lo tanto se basarán en la estructura de grupos de Directorio Activo. Estos grupos se pueden añadir a WSSv3 siempre y cuando sean de tipo seguro (los grupos de Distribución no se pueden añadir directamente a Sharepoint), de manera que el AD se encargará de la sincronización correspondiente. En el caso de grupos de AD de tipo Distribución, no se pueden añadir al no ser seguros, aunque si se podrían añadir usuarios individuales (el problema de esta aproximación es que no hay sincronización, por lo que si se producen cambios en las características del usuario añadido a Sharepoint, el mantenimiento se tendrá que hacer de manera manual).
Buena Práctica: Es recomendable que los grupos de usuarios Windows a añadir permitan una gestión de permisos eficiente en WSS: (i) Sean los suficientes como para no tener que estar añadiendo grupos de manera continua. (ii) Estén lo suficientemente bien formados (en cuanto a características de los usuarios incluidos) para poder asignar adecuadamente los permisos apropiados.
Acceso Anónimo vs Acceso Autenticado
Dentro de este punto es igualmente importante determinar si queremos que todos los usuarios de nuestro dominio puedan visualizar contenidos del sitio, para lo que bastaría con garantizar acceso a todos los usuarios autenticados (y que pertenezcan al grupo de AD Domain Users Windows), de manera que no tendríamos que habilitar el acceso anónimo. También se puede dar la situación contraria, es decir, que permitamos acceso anónimo para visualizar contenidos, y que se pida autenticación para poder modificar contenidos de nuestro sitio.
El acceso anónimo debe configurarse a nivel de Web Application, de manera que los administradores del sitio podrán:
- Habilitar el acceso anónimo a todo el sitio.
- Habilitar el acceso anónimo solo a listas y librerías.
- Bloquear el acceso anónimo a todo el sitio.
El mecanismo de acceso se configura desde la administración central de WSSv3: Application Management -> Authentication Providers (mi compañero Pablo ya nos comentó como configurar Sharepoint con varios modelos de autenticación).
Además, se podrían añadir políticas de permisos dependiendo de la zona en la que se haya habilitado el acceso anónimo (Internet, Intranet, Extranet u Otra) y suponiendo que la misma Web Application es la que sirve las distintas zonas. Las políticas aplicables son: None (no se aplican restricciones adicionales) Read (sólo pueden leer contenidos), Deny Write (no pueden escribir contenidos aunque se fuerce), y Deny All (no tiene acceso, aunque se haya configurado el acceso anónimo).
Nota: El acceso anónimo en WSSv3 se construye sobre la cuenta de usuario anónimo del servidor web que es creada y mantenida por el IIS (cuenta por defecto IUSR_NombreMaquina). Por lo tanto, cuando se habilita el acceso anónimo a un sitio de WSS, lo que se está haciendo es habilitar el acceso de esta cuenta a Sharepoint. El nivel de permisos que se asigna a esta cuenta es View Items, con algunas restricciones añadidas:
- No se puede utilizar Sharepoint Designer para modificar sitios de Sharepoint (está bloqueado el RPC).
- No pueden añadir o modificar elementos del sitio (ítems, o documentos).
Y hasta aquí llega el segundo post de la serie sobre consideraciones a tener en cuenta a la hora de diseñar y planear soluciones de WSS 3.0.