recomendaciones para usar la personalización avanzada de...
TRANSCRIPT
Recomendaciones para usar la Personalización avanzada de permisos
Este documento se proporciona “tal cual”. Es posible que la información y los puntos de vista reflejados en
este documento, incluidas la dirección URL y otras referencias a sitios web de Internet, cambien sin previo
aviso. El usuario asume el riesgo de su uso.
Algunos ejemplos descritos en este documento se proporcionan únicamente con fines ilustrativos y son
ficticios. No se pretende indicar ni debe deducirse ninguna asociación ni conexión real.
Este documento no proporciona ningún derecho legal sobre la propiedad intelectual e industrial de ningún
producto de Microsoft. Este documento puede copiarse y usarse para fines internos y de referencia.
© 2010 Microsoft Corporation. Reservados todos los derechos.
Página 2
Recomendaciones para usar la Personalización avanzada de permisos
Autor: Sean Livingston, director de productos del grupo de productos de SharePoint Publicación: septiembre de 2010
Resumen: en estas notas del producto se describen los procedimientos recomendados para la Personalización avanzada de permisos y cómo usarla dentro de la organización al usar Productos y Tecnologías de SharePoint® o los productos de Microsoft® SharePoint® 2010.
Página 3
Contenido
Contenido .............................................................................................................................................................. 3
Introducción a la Personalización avanzada de permisos .................................................................................... 4
Introducción al sistema de permisos de SharePoint ............................................................................................ 5
Niveles de permisos........................................................................................................................................ 5
Grupos de SharePoint ..................................................................................................................................... 5
Ámbito ............................................................................................................................................................ 5
Objeto protegible ........................................................................................................................................... 6
Herencia ......................................................................................................................................................... 6
Acceso limitado .............................................................................................................................................. 7
ACL binaria ...................................................................................................................................................... 8
Recomendaciones para evitar problemas habituales de límites en la Personalización avanzada de permisos ........................................................................................................................................... 9
Demasiados ámbitos en una lista ................................................................................................................... 9
Demasiados miembros dentro de un ámbito............................................................................................... 10
Jerarquía del ámbito demasiado profunda .................................................................................................. 10
Recomendaciones para los problemas de rendimiento habituales en la Personalización avanzada de permisos .............................................................................................................. 11
Solución 1: quitar la Personalización avanzada de permisos y usar la exigencia de seguridad solo en el nivel web ..................................................................................................................... 11
Limpieza de la seguridad del entorno .................................................................................................... 11
Nuevo diseño de la arquitectura de seguridad del entorno .................................................................. 12
Solución 2: uso de la Personalización avanzada de permisos por cambios en la estructura jerárquica...... 13
Nuevo diseño de la jerarquía del entorno ............................................................................................. 13
Solución 3: uso de la Personalización avanzada de permisos por cambios en la estructura del ámbito (solo 2010).................................................................................................................................. 14
Nuevo diseño del código dinámico de cambio de seguridad ................................................................ 14
Ejemplo de arquitectura del entorno ................................................................................................................. 15
Descripción general del entorno .................................................................................................................. 15
Diseño del flujo de trabajo ........................................................................................................................... 17
Problemas de la Personalización avanzada de permisos ............................................................................. 17
Solución de problemas de la Personalización avanzada de permisos ......................................................... 18
Resumen ............................................................................................................................................................. 21
Página 4
Introducción a la personalización avanzada de permisos
En este artículo se describe el uso de la Personalización avanzada de permisos para los productos de
SharePoint® 2010 (Microsoft® SharePoint® Server 2010 y Microsoft® SharePoint® Foundation 2010) y para
Productos y Tecnologías de SharePoint® (Office SharePoint® Server 2007 y Windows SharePoint® Services
versión 3.0), los problemas de rendimiento relacionados con la Personalización avanzada de permisos y los
procedimientos recomendados para la configuración de soluciones que incluyen la Personalización avanzada
de permisos.
Nota: se recomienda usar la Personalización avanzada de permisos solo para las oportunidades de negocio
para las que sea necesaria. La Personalización avanzada de permisos puede ser costosa en términos de
rendimiento y supervisión operativa.
Para evitar el uso de la Personalización avanzada de permisos, puede hacer lo siguiente:
Interrumpir la herencia de permisos tan ocasionalmente como sea posible.
Usar grupos basados en la pertenencia de directorio para asignar permisos.
Nota: no se recomienda usar grupos de SharePoint para asignar permisos a sitios ya que, al hacerlo,
se producirá en un rastreo completo del índice. En su lugar, se recomienda usar grupos de dominio.
Asignar permisos en el nivel más alto posible. Como parte de esta estrategia, tenga en cuenta las
siguientes técnicas:
o Separe los documentos que requieren la Personalización avanzada de permisos en las
bibliotecas de documentos definidas para admitir cada grupo de permisos y mantenga las
bibliotecas de documentos en un sitio o colección de sitios separados. Para obtener
información adicional acerca de los cambios jerárquicos, vea Solución 2: uso de la
Personalización avanzada de permisos por cambios en la estructura jerárquica.
Nota: en este documento, los términos web y sitio son equivalentes al objeto SPWeb y el
término colecciones de sitios es equivalente al objeto SPSite.
o Use diferentes niveles de publicación de documentos para controlar el acceso. Antes de
publicar un documento, se puede establecer la configuración de permisos avanzados y el
control de versiones para los usuarios que solo pueden aprobar los elementos de la
biblioteca de documentos.
o En las bibliotecas que no son de documentos (listas), se deben usar los niveles de permisos
ReadSecurity y WriteSecurity. Cuando se crea una lista, los propietarios pueden establecer
los permisos de nivel de elemento para el acceso de lectura o de creación y edición.
Si debe usar la Personalización avanzada de permisos, tenga en cuenta las siguientes recomendaciones:
Asegúrese de no tener demasiados elementos en el mismo nivel de jerarquía en las bibliotecas de
documentos, ya que aumentará el tiempo necesario para procesar los elementos en las vistas.
Use controladores de eventos para controlar el permiso de edición. Puede tener un controlador de
eventos que registre un evento mediante los métodos SPEventReceiverType.ItemUpdating y
SPEventReceiverType.ItemUpdated y, a continuación, usar el código para controlar si se debe
permitir la actualización. Esto es extremadamente eficaz, ya que permite tomar decisiones de
seguridad basadas en los metadatos de una lista o elemento sin afectar al rendimiento de la
Página 5
representación de vista. Para obtener información adicional acerca de los controladores de eventos,
vea Solución de problemas de la Personalización avanzada de permisos.
Use el método AddToCurrentScopeOnly para asignar la pertenencia de acceso limitado en un grupo
de SharePoint. El elemento clave de este principio es volver a diseñar la arquitectura para que la
pertenencia del ámbito no ocasione un nuevo cálculo de la lista de control de acceso (ACL) en la
biblioteca de documentos y el sitio web primarios. Para obtener información adicional acerca de los
cambios en el ámbito, vea Solución 3: uso de la Personalización avanzada de permisos por cambios
en la estructura del ámbito (solo 2010).
Introducción al sistema de permisos de sharepoint
En esta sección se describe el sistema de ámbitos de permisos de SharePoint. Para obtener más información
acerca de la planeación de la seguridad del sitio, vea:
Planeación de los permisos del sitio (SharePoint Server 2010) (http://technet.microsoft.com/es-
es/library/cc262778.aspx)
Planeación de los permisos del sitio (SharePoint Foundation 2010) (http://technet.microsoft.com/es-
es/library/cc287752.aspx)
Planeación de la seguridad del sitio (Office SharePoint Server) (http://technet.microsoft.com/es-
es/library/cc262778(office.12).aspx)
Planeación de la seguridad de sitios (Windows SharePoint Services) http://technet.microsoft.com/es-
es/library/cc287752(office.12).aspx (http://technet.microsoft.com/es-
es/library/cc287752(office.12).aspx)
Niveles de permisos
Un nivel de permisos contiene un conjunto de permisos individuales, como Ver elementos o Crear alertas.
Los niveles de permisos pueden estar predefinidos o los puede crear el usuario. El conjunto de permisos se
puede modificar incluso dentro de los niveles de permisos predefinidos.
Grupos de SharePoint
Un grupo de SharePoint es un objeto de toda la colección de sitios que puede contener otras entidades de
seguridad, incluidos grupos de Active Directory, cuentas de usuarios de Windows y usuarios que no son de
Windows (por ejemplo, cuentas basadas en formularios).
Ámbito
Un ámbito es el límite de seguridad de un objeto protegible y todos sus elementos secundarios que no
tengan definido un límite de seguridad independiente. El ámbito contiene una ACL pero, a diferencia de las
ACL de NTFS, un ámbito puede incluir entidades de seguridad específicas de SharePoint. Los miembros de
una ACL para un ámbito pueden incluir usuarios de Windows, usuarios que no son de Windows (como
Página 6
cuentas basadas en formularios de Productos y Tecnologías de SharePoint o cuentas basadas en
notificaciones de los productos de SharePoint 2010), grupos de Active Directory o grupos de SharePoint.
No existe un número máximo de ámbitos que pueden crearse dentro de un ámbito primario. Sin embargo, en
Productos y Tecnologías de SharePoint, una vez creados 1.000 ámbitos, se usa una ruta de acceso al código
que requiere idas y vueltas de Microsoft® SQL Server adicionales para analizar los ámbitos antes de
representar una vista. Cuando hay 1.000 ámbitos o menos, solo se requiere una ida y vuelta. En los productos
de SharePoint 2010, el número límite de ámbitos devueltos antes de cambiar a un algoritmo diferente se
basa en una limitación de consultas, con un valor predeterminado de 5.000. Sin embargo, incluso este valor
predeterminado puede ser lo suficientemente grande como para reducir el rendimiento significativamente.
En los productos de SharePoint 2010, hay un nuevo método denominado
SPRoleAssignmentCollection.AddToCurrentScopeOnly mediante el cual puede llevarse a cabo la asignación
de roles. Para obtener información adicional acerca de las asignaciones de roles, vea el tema sobre
SPRoleAssignmentCollection.AddToCurrentScopeOnly (http://msdn.microsoft.com/es-
es/library/microsoft.sharepoint.sproleassignmentcollection.addtocurrentscopeonly.aspx).
Objeto protegible
Un objeto protegible es un objeto que puede tener asignada una ACL. En Productos y Tecnologías de
SharePoint, se puede usar la interfaz ISecurableObject y en los productos de SharePoint 2010, se debe usar
la clase SPSecurableObject. Para obtener información adicional acerca de los objetos protegibles, vea el
tema sobre la interfaz ISecurableObject (http://msdn.microsoft.com/es-
es/library/microsoft.sharepoint.isecurableobject.aspx o sobre la clase SPSecurableObject
(http://msdn.microsoft.com/es-es/library/microsoft.sharepoint.spsecurableobject.aspx).
Herencia
Si un objeto protegible no tiene un ámbito único, el objeto heredará el ámbito de su elemento primario.
Cuando un objeto hereda de su elemento primario, no se crea ningún ámbito para dicho objeto. En su lugar,
al realizar una comprobación de seguridad, solo comprobará en el objeto primario. En el entorno más simple,
este ámbito se encuentra en el sitio web raíz de la colección de sitios que contiene el elemento. Cuando se
modifica un elemento o contenedor para que su pertenencia sea única, se interrumpe su herencia, lo que
significa que se crea un nuevo ámbito para ese elemento y, de forma predeterminada, para todos sus
elementos secundarios que heredan sus ámbitos de permisos.
En el siguiente diagrama se muestra una jerarquía de objetos de una biblioteca de documentos, en la que todos los objetos menos uno heredan su ámbito de sus elementos primarios. Cada hexágono dorado numerado representa un ámbito de permisos. Todos los objetos secundarios de un contenedor heredan de ese ámbito primario, a menos que tengan su propio ámbito de permisos exclusivos.
Página 7
Acceso limitado
Cuando se agrega una entidad de seguridad al ámbito de un elemento con permisos exclusivos, se agrega
inmediatamente con nivel de permisos de acceso limitado a cada ámbito de permisos exclusivos de la
jerarquía por encima del elemento, hasta que se encuentra el sitio web primario con permisos exclusivos.
La razón por la cual se agrega el usuario a los ámbitos con acceso limitado es para permitir un acceso
suficiente al objeto que se encuentra jerárquicamente por encima del elemento con permisos exclusivos, con
el fin de que puedan representarse el modelo de objetos, las páginas principales y la navegación cuando el
usuario intenta navegar al elemento. Sin los permisos de acceso limitado en los ámbitos primarios, el usuario
no podría navegar ni abrir correctamente el elemento con permisos exclusivos.
En el diagrama siguiente se muestra cómo la profundidad jerárquica de los ámbitos puede afectar a la
cantidad de trabajo necesario para agregar usuarios con acceso limitado a ámbitos primarios. Cuanto mayor
sea el número de ámbitos únicos por encima del elemento, hasta el sitio web con permisos exclusivos
inclusive, mayor será el número de adiciones que se deben llevar a cabo. En el diagrama se muestra una
representación simplificada de una estructura física que tiene ámbitos únicos definidos en todos los niveles,
desde el sitio web hasta los elementos individuales. Al igual que en el diagrama anterior, cada hexágono
dorado numerado de forma diferente representa un ámbito de permisos exclusivos y todos los objetos
secundarios que se encuentran dentro de ese contenedor heredan de dicho ámbito a menos que tengan su
propio ámbito de permisos exclusivos. La cadena de promoción de acceso limitado se muestra mediante las
flechas rojas.
Página 8
En el diagrama también se incluye el conjunto de ámbitos únicos junto con las adiciones de pertenencia de
acceso limitado que deben llevarse a cabo en cada ámbito primario, representados por cuadros
independientes dentro del ámbito. No se requiere programación adicional para agregar ámbitos únicos cada
vez que se agrega una entidad de seguridad a un ámbito de objetos con permisos exclusivos que se
encuentre por debajo de un sitio web con permisos exclusivos.
Cuando se agrega una entidad de seguridad con el nivel de permisos de acceso limitado a un ámbito
primario, no se realiza ninguna comprobación para ver si la entidad de seguridad ya se encuentra en el
ámbito primario. Una entidad de seguridad que ya tiene acceso al ámbito primario se vuelve a agregar con
permisos de acceso limitado, independientemente de sus permisos existentes en el ámbito primario.
Cuando se quita una entidad de seguridad del nivel de permisos de acceso limitado en un ámbito primario,
cada instancia de dicha entidad de seguridad de cada ámbito secundario se quita del nivel de permisos de
acceso limitado, independientemente de si la entidad de seguridad tiene acceso limitado o un conjunto más
amplio de permisos en los ámbitos secundarios.
ACL binaria
Una ACL binaria realiza comparaciones rápidas de un token de usuario para determinar si el usuario debe
tener acceso al objeto cubierto por el ámbito. Cada vez que cambia la pertenencia de un ámbito, se calcula
una ACL binaria, incluso cuando se agrega un nuevo miembro de acceso limitado. La ACL binaria tarda más
Página 9
tiempo en calcularse a medida que la pertenencia crece y el acceso a los objetos se bloqueará hasta que se
pueda volver a calcular la ACL.
Aunque no hay ninguna limitación de tamaño explícita en una ACL binaria aparte del tamaño máximo de una
columna de imagen de SQL Server, algunos servicios no pueden aceptar una ACL de más de 64 KB. En este
caso, el número de entidades de seguridad de la ACL binaria puede llegar a ser muy alto, pero debe limitarse
debido a consideraciones de interoperabilidad y rendimiento. Para obtener información sobre las
limitaciones en el tamaño de columnas de imagen de SQL Server, vea el tema sobre ntext, text, e image
(Transact-SQL) (http://msdn.microsoft.com/es-es/library/ms187993.aspx).
Recomendaciones para evitar problemas habituales de límites en la personalización avanzada de permisos
Cuando se trabaja con la Personalización avanzada de permisos, es fácil encontrarse accidentalmente con
límites que impiden que los permisos se resuelvan.
Demasiados ámbitos en una lista
Existe un límite integrado de 50.000 ámbitos por lista o biblioteca de documentos. Una vez alcanzados los
50.000 ámbitos, se prohíbe la adición de nuevos ámbitos dentro de una lista o biblioteca de documentos
determinadas.
En los productos de SharePoint 2010, el límite de ámbito integrado puede modificarse mediante un script de
Windows PowerShell.
Para modificar el límite de ámbito integrado a un número menor que 50.000
1. Compruebe que cumple con los siguientes requisitos mínimos: vea Add-SPShellAdmin
(http://technet.microsoft.com/es-es/library/ff607596.aspx).
2. En el menú Inicio, haga clic en Todos los programas.
3. Haga clic en Productos de Microsoft SharePoint 2010.
4. Haga clic en Consola de administración de SharePoint 2010.
5. En el símbolo del sistema de Windows PowerShell, escriba la siguiente sintaxis:
$webapp = Get-SPWebApplication http://nombreDelServidor
$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Número de límite de ámbito>
Sin embargo, en ocasiones el límite efectivo es mucho menor que 50.000 si existen muchos ámbitos en el mismo nivel jerárquico. Esto se debe a que las comprobaciones de visualización de los elementos que se encuentran por debajo de dicho nivel jerárquico deben realizarse en todos los ámbitos que se encuentran
Página 10
por encima. Esta limitación puede ocasionar la reducción del número efectivo de ámbitos permitidos en una
consulta determinada de 1.000 a 2.000.
Procedimientos recomendados:
Solo establezca ámbitos únicos en objetos primarios como las carpetas.
No cree un sistema con muchos objetos con permisos exclusivos por debajo de un objeto que tenga
muchos ámbitos.
Si su empresa requiere más de 50.000 elementos con permisos exclusivos en una lista o biblioteca de
documentos, deberá mover algunos elementos a una lista o biblioteca de documentos diferente.
Demasiados miembros dentro de un ámbito
Como se describió anteriormente, una ACL binaria se calcula cada vez que cambia la pertenencia de ese
ámbito, incluso al agregar un nuevo miembro de acceso limitado. A medida que aumenta el número de
pertenencias del ámbito, aumentará la cantidad de tiempo que se tarda en volver a calcular la ACL binaria.
Sin embargo, el problema puede empeorar, ya que las adiciones de usuarios en un ámbito único de objetos
secundarios ocasionarán que sus ámbitos primarios se actualicen con los nuevos miembros de acceso
limitado, aunque en última instancia esto no implique ningún cambio en la pertenencia del ámbito primario.
Cuando esto ocurre, la ACL binaria de los ámbitos primarios también se debe volver a calcular, a costa de una
mayor cantidad de tiempo de procesamiento aunque el resultado final sea la misma ACL.
Procedimiento recomendado:
Básese en la pertenencia a grupos en lugar de la pertenencia de usuarios individuales en los ámbitos. Por
ejemplo, si puede usarse un único grupo en lugar de 1.000 usuarios, el ámbito tendrá 999 entradas de
pertenencia menos para el ámbito y cualquiera de los ámbitos primarios, que se actualizarán con derechos
de acceso limitado para ese único grupo, en lugar de para 1.000 usuarios individuales con derechos de acceso
limitado. Además, esto ayuda a aumentar la velocidad de la inserción de derechos de acceso limitado y del
nuevo cálculo de ACL en los objetos del ámbito primario.
Importante: el uso de un grupo de SharePoint ocasionará un rastreo completo del índice. Si es posible, use
un grupo de dominio.
Jerarquía del ámbito demasiado profunda
Como se indicó anteriormente, la profundidad jerárquica de los ámbitos puede afectar a la cantidad de
trabajo necesario para agregar usuarios de acceso limitado a los ámbitos primarios. Cuanto mayor sea el
número de ámbitos únicos por encima de un elemento, hasta el sitio web con permisos exclusivos inclusive,
mayor será el número de adiciones que se deben llevar a cabo. Si la jerarquía de un ámbito es muy profunda,
un cambio en la pertenencia del ámbito puede tardar mucho tiempo en llevarse a cabo, ya que cada cambio
de pertenencia en el elemento del ámbito más profundo deberá actualizar de forma iterativa los ámbitos
primarios con una adición de pertenencia para el usuario o grupo agregado explícitamente con derechos de
acceso limitado. Además, esto aumentará el número de ACL binarias que se deberán volver a calcular, con el
impacto de rendimiento correspondiente.
Procedimiento recomendado:
Página 11
Reduzca el número de objetos primarios con permisos exclusivos, lo que reducirá el número de ámbitos que deben actualizarse con miembros de acceso limitado cada vez que cambie un ámbito de objetos secundarios.
Recomendaciones para los problemas de rendimiento habituales en la personalización avanzada de permisos
Las siguientes soluciones pueden ayudar a mitigar los problemas de rendimiento relacionados específicamente con el uso exhaustivo de la Personalización avanzada de permisos. Cada una de las siguientes soluciones trata las modificaciones en la seguridad del entorno, la jerarquía de objetos o el código personalizado que contribuyen al problema de rendimiento relacionado con la Personalización avanzada de permisos. Cada solución comienza con el entorno de ejemplo siguiente, donde un solo sitio web contiene varias bibliotecas de documentos, cada una con un gran número de objetos secundarios con permisos exclusivos.
Solución 1: quitar la Personalización avanzada de permisos y usar la exigencia de seguridad solo en el nivel web
Para cambiar la arquitectura del entorno de modo que ya no requiera la Personalización avanzada de permisos, se puede implementar un proceso de limpieza del entorno y, a continuación, se puede ajustar el número de elementos con ámbito para mejorar la escalabilidad del entorno a largo plazo. Las recomendaciones siguientes describen los cambios de seguridad de la arquitectura y limpieza del entorno necesarios para llevar a cabo esta solución.
Limpieza de la seguridad del entorno
Cuando se quita un usuario del ámbito del nivel web, el modelo de objetos interno debe quitar dicho usuario de todos los ámbitos que se encuentren por debajo del nivel web. Sin embargo, la eliminación de usuarios individuales a fin de limpiar los permisos existentes es un proceso lento. En su lugar, primero quite cada uno de los ámbitos únicos del nivel de elemento individual para que el elemento se establezca para heredar los permisos de su objeto primario. Esto tomará relativamente menos tiempo que si intentara quitar los usuarios en primer lugar, ya que actúa en un solo ámbito del elemento.
Página 12
Importante: si el sitio web actual no se encuentra en la raíz de la colección de sitios y si se establece para
heredar sus permisos del sitio web primario, se quitarán todos los ámbitos únicos que se encuentren por
debajo, y todas las pertenencias de acceso limitado se sobrescribirán a la vez mediante una única ida y vuelta
de SQL Server.
Una vez quitados todos los ámbitos del nivel de elemento, pueden reemplazarse las pertenencias del ámbito
individual en el ámbito del nivel de web por una o varias pertenencias a grupos para permitir el acceso.
Nuevo diseño de la arquitectura de seguridad
del entorno
Una vez quitados los ámbitos y la Personalización avanzada de permisos existentes, el plan de arquitectura a largo plazo debe consistir en mantener un ámbito único solo en el nivel de web. En el diagrama siguiente se muestra cómo se puede estructurar para que quede solo el ámbito de nivel web. El requisito principal en la arquitectura es no tener demasiados elementos en el mismo nivel de la jerarquía en las bibliotecas de documentos, ya que se incrementa el tiempo necesario para procesar elementos en las vistas. Como procedimiento recomendado, el número máximo de elementos o carpetas en cualquier nivel de la jerarquía debe ser de aproximadamente 2.000 elementos.
Página 13
Si son necesarios cambios adicionales en la arquitectura, considere la posibilidad de mover las bibliotecas de
documentos a sitios web o colecciones de sitios diferentes. También se puede cambiar el número de
bibliotecas de documentos para cumplir en mayor medida con las necesidades de negocio y las
recomendaciones de escalado que se basan en la taxonomía o la audiencia del contenido almacenado.
Solución 2: uso de la Personalización avanzada
de permisos por cambios en la estructura
jerárquica
Para cambiar la arquitectura del entorno de modo que siga usando la Personalización avanzada de permisos,
pero sin ocasionar actualizaciones excesivas de un ámbito web único ni cambiar su tamaño, considere la
posibilidad de mover las bibliotecas de documentos protegidas de modo diferente a sitios web diferentes.
Nuevo diseño de la jerarquía del entorno
En el siguiente diagrama, la arquitectura física se ha modificado para que cada biblioteca de documentos se encuentre en un sitio web con permisos exclusivos. Además, cuando debe conservarse la Personalización avanzada de permisos del nivel de elemento, como procedimiento recomendado, el número acumulado de las entidades de seguridad a las que se concederá acceso debe limitarse a aproximadamente 2.000, aunque este no es un límite fijo. Así pues, la pertenencia efectiva de cada sitio web, incluidos todos los usuarios de los miembros de acceso limitado, no debe ser mayor que 2.000 usuarios aproximadamente a fin de evitar que cada ámbito de nivel web llegue a ser demasiado grande.
Página 14
El número de elementos secundarios con ámbito único no es un problema importante y puede escalar hasta
grandes cantidades, pero sí será un factor limitante el número de entidades de seguridad que se agregarán
como acceso limitado hacia arriba en la cadena de ámbitos hasta el primer sitio web con permisos exclusivos.
Por último, aunque no se trata concretamente de un problema de la Personalización avanzada de permisos,
la estructura de carpetas debe garantizar que ningún nivel jerárquico de la biblioteca de documentos
superará jamás los 2.000 elementos aproximadamente. Este límite puede ayudar a garantizar un buen
rendimiento de las vistas solicitadas por los usuarios.
Solución 3: uso de la Personalización avanzada de permisos por cambios en la estructura del ámbito (solo 2010)
Para cambiar la arquitectura del entorno de modo que siga usando la Personalización avanzada de permisos,
pero sin ocasionar actualizaciones excesivas de un ámbito de nivel web único ni cambiar su tamaño,
considere la posibilidad de usar un proceso diferente de protección de elementos. Esto se aplica
principalmente si la causa del número excesivo de ámbitos únicos tuviera lugar en un proceso automatizado
como un controlador de eventos o flujo de trabajo que modifica los permisos de objeto de forma dinámica.
En este caso, la recomendación es realizar un cambio de código al proceso que crea los ámbitos de seguridad
únicos.
Nuevo diseño del código dinámico de cambio de seguridad
En el diagrama siguiente, se ha modificado la arquitectura del ámbito para que la pertenencia del ámbito no
ocasione un nuevo cálculo de ACL en el sitio web y la biblioteca de documentos primarios. Como se
mencionó anteriormente, la pertenencia efectiva del sitio web, incluidos todos los miembros de acceso
limitado, no debe ser mayor que 2.000 aproximadamente a fin de evitar que el ámbito de nivel web llegue a
ser demasiado grande. En este caso, sin embargo, mediante la implementación de un nuevo grupo de
SharePoint que contiene todos los miembros que deben tener derechos de acceso limitado, el ámbito no
llegará a ser demasiado grande. Al agregar usuarios a ámbitos individuales debajo del nivel web, con el nuevo
método SPRoleAssignmentCollection.AddToCurrentScopeOnly de los productos de SharePoint 2010,
Página 15
también podrán agregarse con código adicional al nuevo grupo que ya se ha establecido para contar con
derechos de acceso limitado en el nivel web y el nivel de la biblioteca de documentos.
Como se mencionó anteriormente, cuando debe conservarse la Personalización avanzada de permisos del
nivel de elemento, como procedimiento recomendado, el número acumulado de las entidades de seguridad
a las que se concederá acceso debe limitarse a aproximadamente 2.000, aunque este no es un límite fijo. Por
lo tanto, si aumenta este número, aumentará la cantidad de tiempo que se tarda en volver a calcular la ACL
binaria. Si se cambia la pertenencia de un ámbito, se debe volver a calcular la ACL binaria. Sin embargo, las
adiciones de usuarios en un ámbito único de elemento secundario harán que los ámbitos primarios se
actualicen con los nuevos miembros de acceso limitado, aunque en última instancia esto no implique ningún
cambio en la pertenencia del ámbito primario. Cuando esto ocurre, la ACL binaria de los ámbitos primarios
también se debe volver a calcular.
Al igual que en la solución anterior, el número de elementos secundarios con ámbito único no es un
problema importante y puede escalar hasta grandes cantidades, pero el número de entidades de seguridad
que se agregarán como acceso limitado hacia arriba en la cadena de ámbitos hasta el primer sitio web con
permisos exclusivos será un factor limitante.
Ejemplo de arquitectura del entorno
En esta sección se describe un entorno de ejemplo que experimentaba problemas importantes relacionados
con una confluencia de problemas relacionados con la Personalización avanzada de permisos, y se aborda la
combinación de soluciones usadas para solucionar el problema.
Descripción general del entorno
Un sistema de administración de conocimientos basado en SharePoint Server 2007 contenía dos colecciones
de sitios, cada una con un solo sitio web, Contoso-Draft y Contoso-Production. En Contoso-Draft se
Página 16
publicaban los borradores iniciales y los flujos de trabajo interactuaban con los documentos. Contoso-
Production era el destino final de cada documento aprobado y el repositorio de todo el contenido aprobado.
Los documentos podían asignarse a uno de varios tipos de contenido que transmiten la finalidad prevista del
documento (como planes de proyecto o guías de solución de problemas). Además, los documentos se
clasificaban dentro de dominios tecnológicos (de los cuales cien o más eran de una especificidad cada vez
mayor) y en diversas disciplinas (como administración de proyectos u operaciones). La colección de sitios de
publicación de borradores incluía una biblioteca de documentos por disciplina, cada una con una jerarquía de
carpetas cada vez más específicas para cada dominio tecnológico, y se esperaba que los usuarios primero
seleccionaran una biblioteca de disciplina y una carpeta de dominio tecnológico específica al crear un nuevo
documento.
En el siguiente diagrama se muestra una representación simplificada de la estructura física original del sitio
web, donde cada hexágono dorado numerado representa un ámbito de permisos exclusivos y todos los
objetos secundarios dentro de ese contenedor heredan de ese mismo ámbito a menos que tengan su propio
ámbito de permisos exclusivos.
Cada combinación de tipo de contenido, dominio tecnológico y disciplina podía tener asignado un revisor no
superpuesto que fuera experto en el dominio tecnológico o en la disciplina. La biblioteca de documentos
debía contener una gran cantidad de elementos mientras estos experimentaban operaciones de flujo de
trabajo que cambiaban dinámicamente el revisor asignado y la seguridad del elemento. Una vez revisado el
documento por última vez, se copiaba a una ubicación de Contoso-Production coincidente donde
permanecía sin modificaciones como una versión publicada y disponible para todos los empleados de la
compañía.
Para obtener información sobre la planeación de tipos de contenido y flujos de trabajo, vea:
Planeación de tipos de contenido y flujos de trabajo (SharePoint Server 2010)
(http://technet.microsoft.com/es-es/library/cc262735.aspx)
Planeación de tipos de contenido (SharePoint Foundation 2010) (http://technet.microsoft.com/es-
es/library/ff607870.aspx)
Página 17
Planeación del tipo de contenido (Office SharePoint Server) (http://technet.microsoft.com/es-
es/library/cc262735(office.12).aspx)
Planeación de los tipos de contenido (Windows SharePoint Services)
(http://technet.microsoft.com/es-es/library/cc287765(office.12).aspx)
Diseño del flujo de trabajo
Una vez iniciado el proceso de flujo de trabajo, se bloqueaba el acceso del autor de un documento al
documento para que otros usuarios pudieran revisarlo sin que el autor efectuara cambios al mismo tiempo.
Para cada paso subsiguiente del flujo de trabajo, se denegaba el acceso a los usuarios que antes tenían
acceso al documento y se otorgaba acceso a los revisores de la siguiente fase del flujo de trabajo.
El proceso de flujo de trabajo usaba un flujo de trabajo codificado y un controlador de eventos personalizado
que trabajaban juntos. Al cambiar un elemento de una biblioteca de documentos, inicialmente actuaba sobre
él el controlador de eventos personalizado mediante el cambio de los permisos y el inicio de una nueva
instancia de flujo de trabajo. Tanto el flujo de trabajo como el controlador de eventos cambiaban los
permisos del archivo específico que se estaba actualizando, a fin de que a cada elemento se le proporcionara
un ámbito de permisos exclusivos. Este cambio de permisos significaba que solo un usuario o un subconjunto
pequeño de usuarios (es decir, los revisores en ese paso) tenían acceso al elemento de manera simultánea. El
último paso del flujo de trabajo, una vez aprobado completamente el documento, era copiarlo a la ubicación
de Contoso-Production equivalente como una nueva versión publicada del documento, con los permisos
heredados del sitio web primario.
Problemas de la Personalización avanzada de permisos
El diseño del flujo de trabajo y del entorno se probó correctamente durante el desarrollo, pero ahora
experimenta problemas importantes en el rendimiento, lo que ocasiona que los usuarios sufran retrasos
entre uno y varias decenas de minutos en la finalización de las tareas. Las pruebas solo usaron cientos de
cuentas de prueba, pero una vez que el diseño se puso a disposición de toda la compañía y se anunció como
una herramienta de captura de conocimientos obligatoria, el uso aumentó rápidamente a más de 15.000
usuarios que trabajan de forma acumulativa en más de 30.000 documentos. Los problemas de rendimiento
informados impedían que una gran parte de la compañía usara el nuevo sistema de administración de
conocimientos, que se esperaba que admitiera más de 60.000 usuarios.
Cuando se produjeron cambios de permisos en el flujo de trabajo, se creó un ámbito de permiso para cada
elemento individual. Conforme a los requisitos del nivel de permisos de acceso limitado descritos
anteriormente, cada entidad de seguridad única se agregó con acceso limitado a los distintos ámbitos de
permisos exclusivos de la jerarquía por encima del elemento hasta encontrar un sitio web con permisos
exclusivos. Por lo tanto, cuanto mayor era la cantidad de ámbitos únicos que se encontraban por encima del
elemento con permisos exclusivos pero por debajo del sitio web con permisos exclusivos, mayor era la
cantidad de ámbitos en los que se agregaba la entidad de seguridad con acceso limitado.
Página 18
Un aspecto clave a tener en cuenta es que el problema no se debe al gran número de ámbitos únicos creados
dentro del sitio web raíz de las colecciones de sitios, sino que el número efectivo de entidades de seguridad
únicas dentro de ese ámbito de nivel web ha crecido a más de 15.000 usuarios únicos. Cada usuario agregado
a cualquier ámbito de permisos exclusivos por debajo del sitio web también se agregó al ámbito propio del
sitio web, lo que provocó un nuevo cálculo de ACL binaria en cada adición.
Debido al gran tamaño del ámbito de nivel web, si se combina con la frecuencia del nuevo cálculo de ACL
binaria, podría ocasionarse un bloqueo en varios procedimientos almacenados de SQL Server. Cada vez que
se cambia el ámbito de pertenencia de un elemento con la herencia interrumpida, se agrega cada miembro
del ámbito como una pertenencia de usuario de acceso limitado en el ámbito de nivel web. Además, cada vez
que se actualizó la pertenencia del ámbito de nivel web con miembros nuevos o existentes, incluidos los de
acceso limitado, se provocó un nuevo cálculo de ACL binaria en el ámbito de nivel web. Debido a que el
ámbito de nivel web contenía más de 15.000 entidades de seguridad, el nuevo cálculo llevó mucho tiempo.
Mientras se realizaba el nuevo cálculo, el acceso al objeto no se encontraba disponible y los usuarios finales
experimentaron dificultades intermitentes de inicio de sesión.
Solución de problemas de la Personalización avanzada de permisos
Las soluciones mencionadas anteriormente se consideraron como parte del proceso de mitigación de los
problemas de rendimiento experimentados relacionados con la Personalización avanzada de permisos, con
un plan aprobado a corto y largo plazo. La decisión a corto plazo fue refactorizar el flujo de trabajo para que
la Personalización avanzada de permisos ya no esté establecida por elemento, y la estructura del entorno se
dejó igual jerárquicamente. Se quitaron los ámbitos individuales de Personalización avanzada de permisos.
Inicialmente se intentó quitar cada usuario del ámbito de nivel web o los ámbitos del nivel de elemento, pero
como el rendimiento no era satisfactorio, se aprobó un proceso de eliminación para cada ámbito del
elemento mediante el cual el elemento hereda los permisos de su elemento primario. Además, se reequilibró
cierto contenido para impedir que se muestren demasiados elementos en un determinado nivel o jerarquía.
El controlador de eventos se modificó para exigir un formulario o el acceso de lectura para los usuarios que
no estén asignados como revisores actualmente y, de este modo, evitar modificaciones en flujos de trabajo o
documentos. Este enfoque no limitó quién podía ver los elementos, porque no existe otro modo aparte de
los ámbitos para restringir de forma segura la visualización, pero pudo usarse para evitar modificaciones en
documentos o flujos de trabajo, como por ejemplo, permitir por error al autor que modifique el documento
Página 19
mientras se encontraba en un ciclo de revisión. Una vez que se quitaron los ámbitos de seguridad del
elemento individual y se instalaron el flujo de trabajo y el controlador de eventos actualizados, los usuarios
pudieron usar el entorno sin exigencia de seguridad del nivel de elemento individual, sin ningún problema de
rendimiento.
En el siguiente diagrama se muestra una representación simplificada de la estructura física del sitio web una
vez quitado el ámbito de seguridad, donde cada hexágono dorado numerado representa un ámbito de
permisos exclusivos y todos los objetos secundarios dentro de ese contenedor heredan de ese mismo ámbito
a menos que tengan su propio ámbito de permisos exclusivos.
Una solución planeada a largo plazo de Productos y Tecnologías de SharePoint sería dividir el contenido en
sitios web diferentes para poder seguir usando la Personalización avanzada de permisos, pero con el impacto
general limitado a un conjunto mucho más pequeño de cambios.
En el siguiente diagrama se muestra una representación simplificada de la estructura física del contenido una
vez dividido en sitios web diferentes, donde cada hexágono dorado numerado representa un ámbito de
permisos exclusivos y todos los objetos secundarios dentro de ese contenedor heredan de ese mismo ámbito
a menos que tengan su propio ámbito de permisos exclusivos.
Página 20
En el siguiente diagrama se muestra el diseño de ámbito lógico y se resaltan los límites de cuántas entidades
de seguridad únicas se podrían agregar al ámbito de cada sitio web si la Personalización avanzada de
permisos se volviera a habilitar después de mover a sitios web diferentes. Tenga en cuenta que aunque
todavía queda una gran cantidad de elementos con permisos exclusivos, se ha solucionado el problema
principal de grandes cantidades de entidades de seguridad en un ámbito.
Por último, se analizó el momento en que un cambio eventual a los productos de SharePoint 2010 aportaría
nuevas funcionalidades al diseño del flujo de trabajo, en concreto la capacidad de asignar dinámicamente la
Personalización avanzada de permisos mediante el método SPRoleAssignmentCollection.AddToCurrent
ScopeOnly para asignar pertenencias solo al ámbito individual de cada elemento y, a continuación, conceder
acceso limitado en el sitio web primario a un grupo de SharePoint que contiene la pertenencia. Este proceso
permitiría la implementación de la Personalización avanzada de permisos mediante el flujo de trabajo o el
controlador de eventos sin afectar al rendimiento.
Página 21
Resumen
En este documento se describen los procedimientos recomendados sobre el modo en que su organización
puede usar la Personalización avanzada de permisos y los problemas de rendimiento que pueden producirse.
Además, se tratan las estrategias y procesos para mitigar problemas si un entorno actualmente los
experimenta debido al uso o escala incorrectos de la Personalización avanzada de permisos. Por último, se
describe un entorno de ejemplo que experimentaba problemas debido al uso incorrecto de la
Personalización avanzada de permisos, y el proceso usado para solucionar los problemas encontrados.