Consideraciones y buenas prácticas en el diseño de Soluciones WSS v3 (II)

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.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

15 comentarios en “Consideraciones y buenas prácticas en el diseño de Soluciones WSS v3 (II)”

  1. Hasta aqui todo bien, pero si quiero que en un subsitio SOLO tengan acceso un grupo de usuarios?, es decir que los demas no puedan visualizar nada de nada de la web.

  2. Hola Juan Luis,
    Pues para hacer lo que necesitas a nivel de subsitio, no tienes más que crearlo sin que se hereden los permisos del sitio padre. Luego en el subsitio tendrás los correspondientes grupos de usuarios y en ellos irás añadiendo los usuarios que consideres oportunos.

    Esto es funcionalidad estándar de Sharepoint.

    Salu2

    JC

  3. hola, muy buenos los post.. puedo dar acceso anonimos a item particulares de una lista?? y a otros item de la misma lista no?..

    Estuve viendo, que se puede manejar a nivel de lista o biblioteca pero no se si se puede a nivel de item de lista o bibliotecas..

    muchas gracias.

  4. Hola Damian,
    Pues me temo que con funcionalidad por defecto no se puede. En este enlace tienes todas las posibildiades que WSS 3.0 & MOSS permiten para configurar el acceso anónimo a sites y listas / bibliotecas: http://office.microsoft.com/en-us/sharepointtechnology/HA101130181033.aspx

    Si lo que planteas es un requerimiento necesario, yo intentaría investigar que podemos hacer con el modelo de objetos en este sentido puesto que puedes fijar permisos a nivel de ítem individual de una lista o librería.

    Un saludo

    JC

  5. Muy bien explicado.

    Tengo una duda y quisiera ver si puedes ayudarme…

    Soy un principiante en Sharepoint nunca lo habia trabajado y ahora uso MOSS 2007, ya que me lo solicitaron donde hago mi servicio.

    La idea es crear una pagina en una escuela, para que cada carrera tenga su propia pagina y los maestros suban informacion, y los alumnos puedan verla.

    Lo que aun no entiendo es como se maneja los subsitios, se como se crean los sitios, todo lo he hecho desde la Administracion Central, y desde ahy se pueden checar todos los sitios creados y modificar.

    Lo que quisiera saber es como hacer que un sitio sea manejado por otro usuario, pero sin que desde ese sitio pueda ver la pagina de Administracion Central.

    Nose si eso esta en manejar usuarios o en manejar sitios.. ?

  6. Muy buenas Edgar,
    Vayamos por partes. Lo primero y más importante, tanto WSS 3.0 como MOSS tienen varios niveles de administración:
    – Desde la propia administración central de SharePoint desde dónde podremos crear web applications y luego site collections que son sites top. Entonces, en tu caso, podrías tener un sitio top para la web de la escuela. En este nivel de administració, sólo debería entrar los administradores de la granja de servidores, pero no usuarios normales.
    – Una vez creado un site collection, este tiene sus propias capacidades de administración a través del Site Settings. Aquí te digo lo mismo, en usuario que se loggea podrá hacer más o menos cosas dependiendo del nivel de permisos que le asignes. Así, si un profesor sólo puede subir documentos, lo lógico es que le asignes un nivel de permisos de tipo colaborador, pero no le des control total (sólo lo tendría el administrador).
    – Finalmente, dentro de un site collection puedes crear subsitios, que a su vez tienen sun administración independiente y en lo que aplica lo que he comentado antes.

    Entonces, evidentemente el quid de la cuestión está en manejar usuarios y tener clara la estructura de la web (entiendo Intranet) que quieres crear.

    Un saludo

    Jc’s

  7. te lo agradezco mucho, me sirvio bastante.

    bueno aprovechando el momento, no sabes como se habilita la opcion para que al iniciar sharepoint… me pida el usuario y contraseña??

    estoy manejando como windows authentication
    y al iniciar sharepoint desde las maquina donde esta instalado, no me pide el usuario reconoce de inicio el usuario con el que inice sesion en windows..

    antes me salia, pero ahora no.. al volver a configurar sharepoint.

    a y una ultima pregunta, como hago para que mi pagina pueda ser vista fuera del dominio.. desde internet??

  8. Buenas Edgar!
    El comportamiento que me comentas dentro de tu red es normal, no te pedirá las credenciales de usuario porque entiende que estás en zona segura de acceso…sin embargo, si probases a acceder desde fuera de tu red te las pedirá. Otra forma de comprobarlo es cambiar de usuario y verás como te vuelve a pedir las credenciales.

    Para hacer que tu página sea visible desde Internet, necesitas lo primero de todo tener una IP fija, lo segundo hacer que los DNS de tu dominio apunten a esa IP…y con esto ya podrías empezar a funcionar.

    Un saludo

    JC’s

  9. Muy bueno el post. Pero tengo el siguiente problema y deseo que me ayuden, como puedo darle permiso a un usuario anonimo para que participe en un sistema de raiting dentro de WSS 3.0.

  10. Quisiera saber como restinjo los permisos sobre una lista en un workflow, me explico, que el grupo que tenga la tarea en el momento tenga el control sobre el, pero los grupos que ya pasaron por el flujo solo la puedan ver.
    Gracias

  11. Hola:
    Bueno, para que me puedan entender, en mi empresa estamos desarrollando un portal para facilitar el flujo de informaciónn, pero tengo problemas con el acceso de los usuarios al sitio, solo les dice que con su usuario no pueden entrar. He hecho y deshecho con los grupos y sus permisos pero nada. Ahora lo último es que haciendo pruebas con las alertas que les llegan a traves del correo y el link que les aparece en el cuerpo del mismo entonces si pueden entrar por ahi pero al salir de ahi y entrar por el explorador entonces no les deja ni poner el pass simplemente les dice que por ese usser no pueden entrar.
    Les agradecería toda la ayuda que me puedan brindar.
    Slaudos

  12. Hola:
    Bueno, para que me puedan entender, en mi empresa estamos desarrollando un portal para facilitar el flujo de informaciónn, pero tengo problemas con el acceso de los usuarios al sitio, solo les dice que con su usuario no pueden entrar. He hecho y deshecho con los grupos y sus permisos pero nada. Ahora lo último es que haciendo pruebas con las alertas que les llegan a traves del correo y el link que les aparece en el cuerpo del mismo entonces si pueden entrar por ahi pero al salir de ahi y entrar por el explorador entonces no les deja ni poner el pass simplemente les dice que por ese usser no pueden entrar.
    Les agradecería toda la ayuda que me puedan brindar.
    Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *