Modelo de arquitectura lógica: implementación corporativa
En este artículo:
Acerca del modelo
Objetivos generales de diseño
Granjas de servidores
Usuarios, zonas y autenticación
Proveedores de servicios compartidos
Sitios de administración
Grupos de aplicaciones
Aplicaciones web
Colecciones de sitios
Bases de datos de contenido
Zonas y direcciones URL
Directivas de zona
En este artículo se describe una implementación práctica de componentes de arquitectura lógica para lograr un diseño viable. Este artículo está pensado para usarse junto con el siguiente ejemplo de diseño de arquitectura lógica de implementación corporativa (en inglés) (https://go.microsoft.com/fwlink/?linkid=82151&clcid=0xC0A) (en inglés) de modelo.
El modelo muestra una implementación corporativa genérica de Microsoft Office SharePoint Server 2007. El modelo se aplica a casi todos los componentes de la arquitectura lógica e ilustra cómo éstos se incorporan en el diseño general. En este artículo se describen los objetivos de diseño para el modelo y se explica cómo se logran los objetivos mediante el uso de los componentes de la arquitectura lógica que se ilustran en el modelo.
Acerca del modelo
El modelo ilustra una implementación corporativa para una empresa ficticia denominada Fabrikam, Inc. La implementación abarca dos granjas de servidores. Una granja de servidores hospeda la intranet corporativa y el sitio web de asociados. La segunda granja hospeda el sitio web de la empresa (www.fabrikam.com).
Intranet
La intranet corporativa incluye las siguientes aplicaciones:
Contenido de la intranet publicado (por ejemplo, HRweb)
Sitios de grupos de colaboración
Mis sitios
Juntos, éstos son los sitios de contenido y colaboración que los empleados van a usar diariamente. De forma individual, cada una de estas aplicaciones representa un tipo distinto de contenido. Cada tipo de contenido:
Enfatiza distintas características de Office SharePoint Server 2007
Hospeda los datos con características de datos diferentes
Está sujeto a un perfil de uso diferente
Requiere una estrategia de administración de permisos diferente
Por consiguiente, las opciones de diseño para cada una de estas aplicaciones están pensadas para optimizar el rendimiento y la seguridad de cada aplicación.
El uso de un único Proveedor de servicios compartidos (SSP) une estas tres aplicaciones para ofrecer:
Navegación por las aplicaciones
Búsqueda en toda la empresa
Datos de perfil compartidos
La siguiente ilustración muestra las tres aplicaciones que componen la intranet corporativa.
.jpg "Arquitectura lógica para el modelo corporativo")
Sitio web de asociados
La aplicación web de asociados hospeda sitios disponibles de manera externa para ofrecer una colaboración segura con los empleados de las empresas asociadas. El objeto de esta aplicación es que los empleados puedan crear fácilmente sitios para una colaboración segura. Entre los factores clave en que se basan las opciones de diseño de esta aplicación se incluyen:
**Aislamiento del contenido **A los asociados no se les permite tener acceso a otros tipos de contenido hospedado en la granja de servidores. Además, con un SSP dedicado, para aislar el contenido puede:
Reducir la búsqueda sólo al nivel del sitio
Impedir la navegación a través de las colecciones de sitios
Impedir que los datos de perfil estén disponibles a través de las colecciones de sitios
**Autenticación independiente de las cuentas de asociado **Las cuentas de asociado se administran a través de la autenticación mediante formularios. Las cuentas de asociado no se agregan al directorio corporativo.
**Administración de permisos **Los propietarios de sitios individuales administran los permisos de sus sitios, invitándose a colaborar sólo a aquellos participantes necesarios.
En el modelo, la aplicación web de asociados se hospeda en la misma granja de servidores que el contenido de la intranet.
Sitio de Internet de la empresa
El sitio de Internet de la empresa representa la presencia de la empresa en Internet. El contenido estará disponible para los clientes mediante la configuración del acceso anónimo con permisos de solo lectura. Entre los factores clave en que se basan las opciones de diseño para esta aplicación se incluyen:
Aislamiento del contenido Los clientes no pueden tener acceso a ningún otro tipo de contenido hospedado en la granja de servidores.
Administración focalizada Se ofrece acceso autenticado a los empleados que administran el sitio web, incluidos los que realizan tareas administrativas y de creación.
Creación y publicación de contenido seguro Las colecciones de sitios independientes se hospedan en la Granja de servidores A de la aplicación web del asociado para la creación y el almacenamiento provisional. Esto permite la colaboración segura y el desarrollo de contenido con empleados internos y remotos así como con asociados editoriales especializados en el desarrollo de sitios web y en la creación de contenido. La publicación de contenido se configura para publicar automáticamente el contenido desde la colección de sitios de creación en la colección de sitios de almacenamiento provisional (en la Granja de servidores A) y desde la colección de sitios de almacenamiento provisional en la Granja de servidores A en la colección de sitios de producción de la Granja de servidores B. La siguiente ilustración muestra el proceso de publicación.
.jpg "Arquitectura de granja de servidores lógica: modelo de publicación")
Objetivos generales de diseño
El modelo muestra una implementación práctica de características de Office SharePoint Server 2007 dentro de varios tipos comunes de aplicaciones. En este artículo se abordan las implementaciones de diseño de cada una de las aplicaciones individuales. Entre los objetivos de diseño clave para el modelo se incluyen:
Usar el menor número de granjas de servidores para hospedar los tipos más comunes de sitios web normalmente requeridos por una empresa: sitios de intranet, extranet e Internet.
Crear un marco de trabajo para diseñar un entorno que puede aumentar de tamaño. Las decisiones de diseño para aplicaciones individuales no impiden la incorporación de otras aplicaciones. Por ejemplo, una implementación inicial puede incluir sólo los sitios de grupos de colaboración o sólo las tres aplicaciones que componen una intranet (sitios de grupo, Mis sitios y contenido de intranet publicado). El uso de un diseño de arquitectura lógica similar le permite agregar aplicaciones a la solución sin que ello afecte al diseño de las aplicaciones iniciales. En otras palabras, el diseño no incorpora opciones de diseño que limiten el uso del entorno.
Proporcionar acceso a varias clases de usuarios sin poner en peligro la seguridad del contenido dentro de las distintas aplicaciones. Los usuarios de zonas de red diferentes (internas y externas) con diferentes proveedores de autenticación pueden participar en la colaboración. Además, los usuarios sólo pueden tener acceso al contenido al que se supone que tienen acceso. El uso de un diseño de arquitectura lógica similar le permite disponer de la posibilidad de proporcionar acceso a los usuarios en varias ubicaciones y con diferentes objetivos. Por ejemplo, el diseño inicial puede diseñarse sólo para el acceso de empleados internos. Sin embargo, el uso de un diseño similar le permite disponer de la posibilidad de habilitar el acceso también para los empleados remotos, empleados de asociados y clientes.
Asegurarse de que el diseño pueda usarse en un entorno de extranet. Para garantizar que las granjas de servidores pueden implementarse de una manera segura en una red perimetral, se toman decisiones de diseño deliberadas.
En el resto de este artículo se aborda cada uno de los componentes lógicos que aparecen en el modelo (de arriba a abajo), así como las opciones de diseño que se aplican al modelo. El objetivo de este enfoque es demostrar las distintas formas en que se pueden configurar componentes de arquitectura lógica en función de la aplicación.
Granjas de servidores
El modelo incorpora el uso de dos granjas de servidores. En esta sección se describen los requisitos de licencias que afectan al número de granjas de servidores que se requieren en un entorno corporativo y las topologías de las granjas de servidores que se muestran en el modelo.
Requisitos de licencias
Nota
Los requisitos de licencias previos especificaban que se necesitaban al menos dos servidores para hospedar el contenido de la intranet y los sitios de Internet (un servidor para cada tipo de licencia). Esto ya no es necesario. Esta sección se ha actualizado para reflejar los nuevos requisitos de licencias que se implementaron en septiembre de 2008.
Hay dos licencias de servidor disponibles para Office SharePoint Server 2007. Se pueden combinar estas licencias en el mismo servidor o en la misma granja de servidores:
Microsoft Office SharePoint Server 2007, licencia de servidor Ésta es la licencia correcta para el contenido de intranet. Esta licencia requiere el uso de licencias de acceso de cliente (CAL). Si crea sitios para la colaboración de asociados, debe asegurarse de que compra el número de CAL necesarias para los empleados de éstos.
**Microsoft Office SharePoint Server 2007 para sitios de Internet **Esta licencia está destinada sólo a sitios web con acceso a Internet. Esta licencia no necesita CAL. Si crea sitios para la colaboración de asociados, no necesita adquirir CAL adicionales. Sin embargo, no puede crear sitios destinados exclusivamente al uso de los empleados de su organización.
Si piensa distribuir contenido interno de la organización y contenido para Internet para usuarios que no sean empleados pero forman parte de la misma granja de servidores, debe adquirir ambos tipos de licencia para esa granja. Como solución para posibles escenarios de implementación, los clientes que deseen consolidar los usos de Office SharePoint Server 2007 en una sola implementación pueden adquirir licencias para ambos productos, asignarlas al mismo servidor y utilizar la misma instancia en ejecución del software simultáneamente en ambas licencias. No obstante, los clientes deben adquirir las CAL requeridas según los derechos de uso de Office SharePoint Server 2007 para usuarios y dispositivos que tengan acceso a contenido de cualquier manera no permitida en los derechos de uso de Office SharePoint Server 2007 para sitios de Internet.
Para obtener más información acerca de cómo afectan los requisitos de licencias a la cantidad de granjas de servidores necesarias, vea Planeación de granjas de servidores.
Aunque solo se necesita una granja de servidores, el modelo ilustra el uso de dos granjas de servidores, una para contenido interno y otra para contenido orientado al cliente. Si decide implementar dos granjas de servidores independientes, la elección de diseño más importante consiste en decidir qué granja de servidores hospeda la aplicación web de asociados. En el modelo, la Granja de servidores A hospeda el contenido de la intranet y la Granja de servidores B hospeda el sitio de Internet de la empresa. De acuerdo con los términos de la licencia, cualquier granja puede hospedar sitios web de asociados.
Dada la elección de dos granjas de servidores, las pautas de diseño generales para determinar qué granja de servidores debe hospedar una aplicación web de asociados incluyen:
Tipo de colaboración Si el objetivo principal de un sitio de extranet de asociado es comunicar de forma segura información a muchos asociados, una granja de servidores de Internet es la opción más económica. Por otro lado, si el objetivo principal es trabajar en colaboración con un pequeño número de empleados de asociados, una granja de servidores de intranet puede ser la mejor elección. Elija la opción que le permita optimizar la granja para la función prevista (es decir, colaboración frente a contenido de solo lectura).
Número de empleados de asociados Si colabora con muchos empleados de asociados y la minimización de los costos es importante, puede hospedar de manera segura tanto contenido de colaboración como anónimo en una granja de servidores con acceso a Internet con la licencia para sitios de Internet.
En el modelo, el sitio web de asociados está diseñado para la colaboración intensiva con empresas asociadas, incluido el desarrollo y almacenamiento provisional del sitio de Internet de la empresa. La colocación del sitio web de asociados en la Granja de servidores A permite a la organización optimizar cada una de las dos granjas para su uso previsto (colaboración frente a contenido de solo lectura).
Para obtener más información acerca de la elección del número correcto de granjas de servidores para su organización, así como más información acerca de los requisitos de las licencias, vea Planeación de granjas de servidores.
Topología de las granjas de servidores
Cada granja de servidores del modelo está compuesta por cinco servidores con la siguiente topología:
Dos servidores cliente web
Un servidor de aplicaciones
Dos servidores de base de datos en clúster o reflejados.
El modelo ilustra la arquitectura lógica de Office SharePoint Server 2007 al mostrar que:
Todos los sitios se reflejan en servidores cliente web.
El sitio de Administración central se instala en un servidor de aplicaciones para protegerlo contra el acceso directo de los usuarios.
En realidad, el número de equipos servidor y la topología de la granja de servidores no son importantes para la arquitectura lógica, con la excepción de aumentar la capacidad y el rendimiento según sea necesario. La arquitectura lógica puede designarse de manera independiente de la topología de la granja de servidores. El proceso de planeación del rendimiento y de la capacidad le ayudará a ajustar el tamaño de la granja de servidores con el fin de cumplir los objetivos de rendimiento y capacidad. Para obtener más información, vea Planeación de rendimiento y capacidad (Office SharePoint Server).
Usuarios, zonas y autenticación
El modelo ilustra cinco clases diferentes de usuarios, cada una de ellas asignada a una zona diferente. En cada aplicación web, puede crear hasta cinco zonas con uno de los nombres de zona disponibles: Predeterminada, Intranet, Internet, Personalizada o Extranet. Una granja que hospede más de una aplicación web puede admitir solicitudes de usuario de más de cinco zonas de red (hasta cinco zonas por aplicación web). Sin embargo, el modelo muestra sólo cinco zonas.
Usuarios y autenticación
El modelo muestra usuarios de diferentes zonas de red o, en el caso de los administradores, usuarios que tienen requisitos de permisos muy diferentes. El modelo demuestra cómo se aplica la autenticación a los usuarios. La siguiente tabla muestra cómo se autentican los usuarios para cada zona.
| Zona | Usuarios | Autenticación |
|---|---|---|
Personalizada |
Administradores |
Kerberos (integrada de Windows) |
Intranet |
Empleados internos |
NTLM (integrada de Windows) |
Predeterminada |
Empleados remotos |
NTLM (integrada de Windows) o autenticación mediante formularios con el protocolo ligero de acceso a directorios (LDAP). |
Extranet |
Empleados de asociados |
Autenticación mediante formularios |
Internet |
Clientes |
Anónima |
En el modelo, no a todos los usuarios se les otorga acceso a ambas granjas de servidores. Por consiguiente, ninguna granja de servidores usa las cinco zonas.
Administradores
La zona personalizada se usa para proteger el acceso administrativo a los sitios. Este enfoque ofrece la oportunidad de:
Implementar un conjunto independiente de direcciones URL y directivas. Por ejemplo, los administradores pueden usar direcciones URL asociadas a la zona personalizada para llevar a cabo tareas administrativas de acuerdo con las directivas de la zona. Los administradores pueden usar las direcciones URL de la intranet para las demás tareas de acuerdo con las directivas que están configuradas para las aplicaciones que componen la intranet. Este enfoque separa los dos contextos y garantiza que los permisos de directiva no entran en conflicto.
Implementar un método de autenticación más seguro para los administradores. Esto proporciona mayor seguridad para la solución global.
Autenticarse en un proveedor diferente en escenarios donde es un proveedor externo el que ofrece soporte técnico para los sitios.
El modelo asume que los administradores son empleados de Fabrikam y tienen acceso interno a la red. El modelo incorpora el uso de la autenticación integrada de Windows para los administradores (es decir, la autenticación Kerberos o NTLM).
Empleados internos
La zona de la intranet se usa para el acceso de los empleados internos. Se usa la autenticación integrada de Windows.
Empleados remotos
La zona predeterminada se usa para el acceso de los empleados remotos. Los objetivos de diseño del modelo son los siguientes:
Realizar la autenticación en el entorno de servicio de directorio de Active Directory interno.
Simplificar la administración de permisos mediante el uso de la autenticación de Windows para empleados internos y empleados remotos. Este objetivo es importante porque, si los usuarios se conectan a sitios a través de dos proveedores de autenticación diferentes, Office SharePoint Server 2007 crea dos cuentas diferentes para cada usuario, y cada una de las dos cuentas debe tener permisos.
El modelo presenta dos opciones diferentes para autenticar a los empleados remotos. Con la primera opción (autenticación integrada de Windows con NTLM) se cumplen ambos objetivos de diseño. La segunda opción (autenticación mediante formularios) cumple el primer objetivo pero no el segundo. Por consiguiente, la primera opción es el método preferido.
En la siguiente tabla se resumen las diferencias entre estas dos opciones.
| Este método de autenticación | Autenticación integrada de Windows con NTLM | Autenticación mediante formularios con un proveedor LDAP |
|---|---|---|
Funcionamiento |
Este método se basa en el uso de Internet Security and Acceleration (ISA) Server 2006 o Intelligent Application Gateway (IAG 2007) para autenticar a los usuarios y, a continuación, enviar las credenciales de los usuarios a Office SharePoint Server 2007. Estos servidores usan la autenticación mediante formularios para autenticar a los usuarios en el entorno de Active Directory. A continuación, reenvían las credenciales a Office SharePoint Server 2007. Para obtener más información, vea los recursos siguientes:
Puesto que la zona es la Predeterminada, se usa la autenticación NTLM para cumplir un requisito del componente de índice. Para obtener más información, vea "Requisitos de configuración de la zona predeterminada" más adelante en este artículo. |
Office SharePoint Server 2007 usa la autenticación mediante formularios con un proveedor LDAP para autenticar a los empleados remotos en el entorno de Active Directory interno. Si se elige este método, compruebe que el componente de índice puede autenticarse a través de una zona alternativa. Para obtener más información, vea "Requisitos de configuración de la zona predeterminada" más adelante en este artículo. |
Ventajas |
Office SharePoint Server 2007 no crea dos cuentas distintas para los usuarios que trabajan de forma interna y de forma remota. Esto simplifica en gran medida la administración de permisos. |
No requiere un servidor proxy para autenticar los usuarios y reenviar credenciales. |
Desventajas |
Requiere configuración y coordinación adicional con ISA Server 2006 u otro producto de servidor proxy. |
Si los usuarios se conectan a Office SharePoint Server 2007 internamente y de manera remota, se crean dos cuentas de usuario diferentes en Office SharePoint Server 2007. Por lo tanto, ambas cuentas requieren permisos para sitios y documentos. Los empleados pueden potencialmente crear dos sitios personales Mis sitios. Los empleados necesitan administrar los permisos para sus propios sitios y documentos para ambas cuentas de usuario si van a trabajar desde la red interna y de forma remota. |
Empleados de asociados
Los empleados de asociados tienen acceso a la red a través la zona de extranet y se autentican a través de la autenticación mediante formularios. Esto requiere un directorio y proveedor independientes, por ejemplo, una base de datos de Microsoft SQL Server y un proveedor, para almacenar cuentas de asociado en la extranet. Las ventajas de este enfoque son que puede administrar cuentas de asociado por separado y no es necesario agregar cuentas de asociado al directorio de los empleados internos.
También puede usar el inicio de sesión web único para autenticarse directamente en el directorio de un asociado. Sin embargo, este enfoque requiere una zona independiente para cada directorio de asociado.
Dado que el modelo asume que Fabrikam está trabajando con los asociados de varias empresas diferentes dentro de la misma aplicación de asociado, se usa la autenticación mediante formularios. El directorio y el proveedor no se especifican.
Clientes
La zona Internet sirve para el acceso de los clientes. Esta zona está configurada para permitir el acceso anónimo con permisos de solo lectura.
Zonas
Al diseñar zonas, debe tomar varias decisiones que son esenciales para que la implementación sea satisfactoria. Se trata de decisiones relativas al diseño y la configuración de las zonas siguientes:
La zona predeterminada
Zonas para acceso externo
En las secciones siguientes se describen las decisiones que se incorporan en el modelo.
Requisitos de configuración de la zona predeterminada
La zona para la que hay que tener en cuenta más aspectos es la zona predeterminada. Office SharePoint Server 2007 impone los siguientes requisitos en el modo en que se configura la zona predeterminada:
Cuando una solicitud de usuario no se puede asociar a una zona, se aplican la autenticación y las directivas de la zona predeterminada. Consecuentemente, la zona predeterminada debe ser la zona más segura.
El componente de índice requiere acceso al contenido a través de, como mínimo, una zona para rastrear el contenido. De forma predeterminada, el componente de índice usa la autenticación NTLM. El administrador del SSP puede configurar reglas de rastreo que usen la autenticación básica o un certificado de cliente al rastrear un intervalo determinado de direcciones URL. En consecuencia, para rastrear contenido, como mínimo una de las zonas debe estar configurada para usar la autenticación NTLM, la autenticación básica o certificados. Además, el rastreador sondeará las zonas en el orden siguiente hasta que encuentre una zona a través de la cual se pueda autenticar: zona predeterminada, zona de intranet, zona de Internet, zona personalizada, zona de extranet. No obstante, si el rastreador se encuentra con una zona configurada para usar la autenticación Kerberos, no se autenticará y no intentará obtener acceso a la zona siguiente. Por tanto, asegúrese de que la configuración de las zonas que usen la autenticación Kerberos no impida al componente de índice rastrear contenido. Para obtener más información acerca de los requisitos de autenticación relacionados con el rastreo de contenido, vea Planeación de métodos de autenticación (Office SharePoint Server).
El correo electrónico administrativo se envía con vínculos desde la zona predeterminada. Éste incluye correo electrónico a propietarios de sitios que se aproximan a los límites de las cuotas. Por tanto, los usuarios que reciben estos tipos de mensajes de correo electrónico y alertas deben poder tener acceso a los vínculos a través de la zona predeterminada. Esto es especialmente importante para los propietarios de sitios.
Las colecciones de sitios con nombre de host sólo están disponibles por medio de la zona predeterminada. Todos los usuarios que vayan a tener acceso a colecciones de sitios con nombre de host deben hacerlo a través de la zona predeterminada.
En el modelo, la zona predeterminada se usa para el acceso de empleados remotos por los motivos siguientes:
Los empleados pueden tener acceso a vínculos de correo electrónico administrativo independientemente de dónde se encuentren.
Los nombres de los servidores internos y las direcciones URL están protegidos de ser expuestos cuando no se puede determinar la zona asociada a una solicitud de usuario. Debido a que la zona predeterminada ya está configurada para los empleados remotos, las direcciones URL no muestran datos confidenciales cuando se aplica esta zona.
Configuración de zonas para un entorno de extranet
En un entorno de extranet, es fundamental diseñar las zonas por estos dos motivos:
Las solicitudes de usuarios pueden iniciarse desde varias redes diferentes. En el modelo, los usuarios inician las solicitudes desde la red interna, Internet y las empresas asociadas.
Los usuarios usan contenido en varias aplicaciones web. En el modelo, la intranet se compone de tres aplicaciones web diferentes. Además, los empleados internos y remotos pueden potencialmente administrar y contribuir al contenido de todas las aplicaciones web: la intranet, el sitio web de asociados y el sitio corporativo en Internet.
En un entorno de extranet, asegúrese de que se observan los siguientes principios de diseño:
Configurar las zonas de varias aplicaciones web para que se reflejen mutuamente. La configuración de la autenticación y los usuarios a los que está dirigida deben coincidir. No obstante, las directivas asociadas con zonas pueden diferir entre distintas aplicaciones web. Por ejemplo, asegúrese que la zona de intranet se usa para los mismos empleados en todas las aplicaciones web. Es decir, no configure la zona de intranet para empleados internos en una aplicación web y para empleados remotos en otra.
Configurar las asignaciones alternativas de acceso precisa y correctamente para cada zona y cada recurso.
En el modelo, la zona predeterminada para cada una de las aplicaciones web está configurada de forma idéntica para el acceso de empleados remotos. Además, la zona de intranet está configurada de forma idéntica en todas las aplicaciones web para el acceso de los empleados internos. La zona de extranet y la zona de Internet se configuran sólo para una aplicación web.
Al crear la zona, se crean automáticamente asignaciones alternativas de acceso. Sin embargo, Office SharePoint Server 2007 se puede configurar para rastrear contenido en recursos externos, como un recurso compartido de archivos. Los vínculos a estos recursos externos deben crearse manualmente para cada zona mediante asignaciones alternativas de acceso. Por ejemplo, un recurso compartido de archivos se puede exponer a los usuarios internos con una dirección URL interna (file://). El mismo recurso compartido de archivos puede exponerse como un vínculo FTP a los usuarios externos (ftp://). Esto garantiza que estos recursos estén disponibles para los usuarios de acuerdo con el contexto de su zona. Cuando los usuarios reciben vínculos a estos recursos en los resultados de la búsqueda, los vínculos son accesibles.
Si las zonas entre las aplicaciones web no se reflejan entre sí y los vínculos a recursos externos no son los adecuados, éstos son algunos de los riesgos:
Los nombres de servidor, los nombres DNS (Sistema de nombres de dominio) y las direcciones IP se pueden exponer potencialmente fuera de la red interna.
Quizás los usuarios no puedan tener acceso a sitios web y otros recursos.
Proveedores de servicios compartidos
Un proveedor de servicios compartidos (SSP) proporciona un conjunto común de servicios y datos de servicios para una agrupación lógica de aplicaciones web y sitios asociados. Los servicios y datos de servicios incluyen:
Servicios de personalización
Audiencias
Catálogo de datos profesionales
Excel Services
Office SharePoint Server Search
Informes de uso del portal
El criterio más importante que determina si necesita más de un SSP en la arquitectura lógica es si necesita aislar el contenido. Por ejemplo, si la granja de servidores hospeda aplicaciones para más de una clase de usuarios, tener distintos SSP puede ayudar a aislar estas clases de usuarios.
El modelo incorpora un SSP independiente para cada una de las siguientes aplicaciones:
Intranet
Sitio web de asociados
Sitio web de Internet del cliente
.gif "Modelo de SSP para implementación corporativa")
Intranet
Las tres aplicaciones individuales que componen la intranet (contenido de intranet publicado, Mis sitios y sitios de grupo) las reúne un SSP. La aplicación de intranet que se ilustra en el modelo proporciona un ejemplo de cómo conseguir un equilibrio entre el aislamiento seguro y la necesidad empresarial de compartir la información y aprovechar los datos de perfil entre las aplicaciones.
Las aplicaciones individuales están aisladas por aplicaciones web y grupos de aplicaciones. Los grupos de aplicaciones independientes proporcionan el aislamiento de los procesos. Las aplicaciones web dedicadas ofrecen la oportunidad de implementar directivas de permisos diferentes para cada tipo de contenido.
La unificación de las tres aplicaciones en un mismo SSP permite la personalización y la búsqueda en toda la empresa en todas las aplicaciones.
.jpg "Arquitectura de proveedor de servicios compartidos")
Sitio web de asociados
El uso de un SSP independiente para la aplicación web de asociados garantiza que los asociados no pueden buscar ni tener acceso a la información confidencial en el entorno de la intranet de la organización. El SSP puede configurarse para aislar aún más el contenido entre las colecciones de sitios de las siguientes maneras:
Limitar los ámbitos de búsqueda a cada una de las colecciones de sitios
Usar destinatarios para dirigir el contenido a ciertos grupos de usuarios
Use la herramienta de línea de comandos Stsadm para configurar el Selector de personas para mostrar sólo los usuarios que sean miembros de la colección de sitios. En esta configuración, puede agregar cualquier usuario desde el directorio si conoce su nombre de usuario; sin embargo, sólo los usuarios que ya se hayan agregado a la colección de sitios se mostrarán en el Selector de personas. Esto impide a los usuarios asociados explorar el directorio de usuarios con el Selector de personas.
Use el siguiente comando para activar esta configuración:
Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv yes
Use el siguiente comando para desactivar esta configuración:
Stsadm.exe -o setproperty –url https://server –pn “peoplepicker-onlysearchwithinsitecollection” –pv no
Además de configurar los servicios en el SSP para lograr el aislamiento, contemple la posibilidad de configurar los permisos de las maneras siguientes:
Limite el acceso a los sitios a usuarios o grupos específicos
Use grupos de SharePoint para autorizar el acceso a contenido
Sitio de Internet de la empresa
En el modelo, el sitio de Internet de la empresa está disponible para los usuarios anónimos. Los sitios destinados a los usuarios anónimos siempre deben separarse de los sitios destinados a los usuarios autenticados. El modelo usa los siguientes métodos de aislamiento para el sitio de Internet de la empresa:
El grupo de aplicaciones independiente garantiza el aislamiento de los procesos
La aplicación web independiente proporciona la oportunidad de orientar directivas
Un SSP dedicado garantiza que los resultados de la búsqueda se limitan a la aplicación anónima
Sitios de administración
En el modelo, cada sitio de administración se hospeda dentro de un grupo de aplicaciones dedicado y una aplicación web. La siguiente lista describe cada uno de los sitios web de administración:
Sitios web de administración de servicios compartidos El modelo ilustra un sitio de administración dedicado para cada SSP. Los sitios de administración de servicios compartidos no pueden aislarse en un único servidor o granja de servidores. Estos sitios se reflejan automáticamente en todos los servidores cliente web.
Sitios web de Administración central En el modelo, el sitio de Administración central para cada granja de servidores está hospedado en un servidor de aplicaciones. De esta manera se protege el sitio contra el contacto directo de los usuarios. Si un peligro originado por un cuello de botella de rendimiento u otro problema de seguridad afecta a la disponibilidad de los servidores cliente web, el sitio de Administración central sigue estando disponible.
Las direcciones URL de los sitios de administración de carga equilibrada no se dan a conocer en el modelo ni en este artículo. Las recomendaciones son las siguientes:
Si se usan números de puerto en direcciones URL administrativas, use los puertos no estándar. Los números de puerto se incluyen en las direcciones URL de forma predeterminada. Si bien normalmente los números de puerto no se usan en direcciones URL expuestas a clientes, el uso de números de puerto para la administración de sitios puede aumentar la seguridad mediante la limitación del acceso a estos sitios a los puertos no estándar.
Permita el acceso a sitios de administración sólo desde un dominio administrativo.
Cree entradas DNS independientes para la administración de sitios.
Además de estas recomendaciones, también puede equilibrar la carga del sitio de Administración central entre varios servidores de aplicaciones para conseguir redundancia.
Grupos de aplicaciones
Los grupos de aplicaciones de Internet Information Services (IIS) independientes se implementan normalmente para lograr el aislamiento de procesos entre el contenido. Los grupos de aplicaciones permiten que varios sitios se ejecuten en el mismo servidor y que a la vez tengan sus propios procesos de trabajo e identidades. Esto mitiga una vulnerabilidad de seguridad en un sitio que ofrece a un atacante la oportunidad de insertar código en el servidor para atacar otros sitios.
En la práctica, considere la opción de usar un grupo de aplicaciones dedicado para cada una de estas situaciones:
Para separar el contenido autenticado del contenido anónimo.
Para aislar aplicaciones que almacenan contraseñas para aplicaciones empresariales externas e interactúan con ellas (por ejemplo, conexiones de Catálogo de datos profesionales).
Para aislar aplicaciones en las que los usuarios tienen libertad para crear y administrar sitios, y colaborar en el contenido.
El modelo usa grupos de aplicaciones de la siguiente manera:
Cada sitio de administración se hospeda en un grupo de aplicaciones dedicado. Esto es un requisito de Office SharePoint Server 2007.
El contenido de la intranet se divide en dos grupos de aplicaciones diferentes. El contenido de colaboración (Mis sitios y los sitios de grupo) está hospedado en un grupo de aplicaciones. El contenido publicado de la intranet se hospeda en un grupo de aplicaciones independiente. Esta configuración proporciona el aislamiento de los procesos para el contenido publicado de la intranet en aquellas conexiones de datos profesionales que suelen usarse con más probabilidad. Por ejemplo, muchos sitios de recursos humanos usan conexiones de datos profesionales para permitir a los empleados tener acceso a sus datos personales.
La aplicación web de asociados se hospeda en un grupo de aplicaciones dedicado.
El sitio en Internet de la empresa se hospeda en un grupo de aplicaciones dedicado de la Granja de servidores B. Si esta granja también fuese a hospedar contenido para la colaboración de asociados, estos dos tipos de contenido (de Internet y de asociado) se hospedarían en dos grupos de aplicaciones diferentes.
Aplicaciones web
Una aplicación web es un sitio web de IIS que crean y usan Productos y Tecnologías de SharePoint. Cada aplicación web está representada por un sitio web distinto en IIS. A cada aplicación web se el asigna un nombre de dominio único, que ayuda a evitar ataques XSS.
Por regla general, debe usar aplicaciones web dedicadas para:
Separar el contenido anónimo del contenido autenticado. En el modelo, el sitio de Internet de la empresa se hospeda en una aplicación web y un grupo de aplicaciones dedicados.
Aislar usuarios. En el modelo, el sitio web de asociados se hospeda en una aplicación web y un grupo de aplicaciones dedicados para garantizar que los asociados no tengan acceso al contenido de la intranet. .
Aplicar permisos. Una aplicación web dedicada ofrece la oportunidad de aplicar los permisos por directivas con la página Directiva de aplicación web en Administración central. Por ejemplo, puede crear una directiva en el sitio en Internet de la empresa para denegar de un modo explícito el acceso de escritura a uno o más grupos de usuarios. Las directivas de una aplicación web se aplican independientemente de los permisos configurados en sitios o documentos individuales de la aplicación web.
Optimizar el rendimiento. Las aplicaciones consiguen un mejor rendimiento si se colocan en aplicaciones web con otras aplicaciones de características similares. Por ejemplo, las características de datos de Mis sitios incluyen una gran cantidad de sitios cuyo tamaño es pequeño. Por el contrario, los sitios de grupo contienen normalmente una cantidad más pequeña de sitios de tamaño muy grande. Si estos dos tipos de sitios se colocan en aplicaciones web independientes, las bases de datos resultantes se componen de datos con características similares, lo cual optimiza su rendimiento. En el modelo, Mis sitios y los sitios de grupo no poseen requisitos de aislamiento de datos exclusivos sino que comparten el mismo grupo de aplicaciones. No obstante, Mis sitios y los sitios de grupo se colocan en aplicaciones web independientes para optimizar el rendimiento.
Optimizar la capacidad de administración. La creación de aplicaciones web independientes da como resultado sitios y bases de datos independientes, por lo que puede implementar distintos límites de sitios (para la Papelera de reciclaje, la expiración y el tamaño) y negociar distintos contratos de nivel de servicio. Por ejemplo, puede permitir más tiempo para restaurar el contenido de Mi sitio si éste es el tipo de contenido más crítico dentro de la organización. Esto le permite restaurar contenido más crítico antes de restaurar el contenido de Mi sitio. En el modelo, Mis sitios se coloca en una aplicación web independiente para permitir a los administradores controlar de un modo más agresivo el crecimiento frente a otras aplicaciones.
Colecciones de sitios
Las colecciones de sitios actúan de puente entre la arquitectura lógica y la arquitectura de la información. Los objetivos de diseño de las colecciones de sitios en el modelo son cumplir los requisitos para el diseño de dirección URL y crear divisiones lógicas de contenido.
Para satisfacer los requisitos del diseño de dirección URL, cada aplicación web incluye una colección de sitios única de nivel raíz. Las rutas de acceso administradas se usan para incorporar un segundo nivel de colecciones de sitios de nivel superior. Para obtener más información acerca de los requisitos de las direcciones URL y cómo usar rutas de acceso administradas, vea "Zonas y direcciones URL" más adelante en este artículo. Más allá del segundo nivel de colecciones de sitios, cada sitio es un subsitio.
La siguiente ilustración muestra la jerarquía de sitios de los sitios de grupo.
.jpg "Arquitectura lógica para sitios de colaboración")
Dado el requisito de una colección de sitios de nivel raíz, las decisiones de diseño giran en torno al segundo nivel de colecciones de sitios. El modelo incorpora opciones en función del tipo de la aplicación.
Contenido de intranet publicado
La suposición para la aplicación de contenido publicado de la intranet es que varias divisiones de la empresa hospedarán el contenido publicado. En el modelo, el contenido de cada división se hospeda en una colección de sitios independiente. Esto ofrece las siguientes ventajas:
Cada división puede administrar y conceder permisos a su contenido de forma independiente.
El contenido de cada división puede almacenarse en una base de datos dedicada.
Las desventajas de usar varias colecciones de sitios son las siguientes:
No es posible compartir entre varias colecciones de sitios páginas maestras, diseños de página, plantillas, elementos web y la navegación.
Se requiere más esfuerzo para coordinar las personalizaciones y la navegación a través de colecciones de sitios.
En función de la arquitectura de la información y del diseño de la aplicación de intranet, el contenido publicado puede presentarse al usuario como una aplicación integrada. Como alternativa, cada colección de sitios puede aparentar ser un sitio web independiente.
Mis sitios
Los sitios personales de Mis sitios tienen distintas características y las recomendaciones para implementar Mis sitios son sencillas. En el modelo, la aplicación de Mi sitio incorpora un sitio de nivel superior con la dirección URL http://my. La primera colección de sitios de nivel superior que se crea usa la plantilla Host de Mi sitio. Se incorpora una ruta de acceso administrada (mediante la inclusión de comodines), que permite un número indefinido de sitios creados por el usuario. Todos los sitios incluidos bajo la ruta de acceso administrada son colecciones de sitios independientes que heredan la plantilla Host de Mi sitio. El nombre de usuario se agrega a la dirección URL con el formato http://my personal/nombreDeUsuario. En la ilustración siguiente se muestra Mis sitios.
.jpg "Arquitectura de red lógica para Mis sitios")
Para obtener más información acerca del diseño de una aplicación de Mis sitios, vea Diseño de la arquitectura de Mis sitios.
Sitios de grupo
Puede elegir cualquiera de los dos enfoques siguientes para diseñar colecciones de sitios dentro de una aplicación de sitio de grupo:
Permitir que los equipos creen colecciones de sitios a través de la característica de creación de sitios sin intervención del administrador. La ventaja de este enfoque es que los equipos pueden crear fácilmente un sitio, según sea necesario, sin la ayuda de un administrador. Sin embargo, este enfoque tiene muchos inconvenientes, entre ellos:
Pierde la oportunidad de implementar una taxonomía bien meditada.
La aplicación podría llegar a ser difícil de administrar.
ES fácil que se descuiden los sitios.
Las plantillas y la exploración no se pueden compartir entre proyectos o equipos que, de otra forma, podrían compartir una colección de sitios.
Crear un número finito de colecciones de sitios para la organización en función de su forma de operar. Con este enfoque, un administrador de SharePoint crea colecciones de sitios. Una vez creada la colección de sitios, los equipos pueden crear sitios dentro de ella en función de sus necesidades. Este enfoque ofrece la oportunidad de implementar una taxonomía exhaustiva que estructura la forma en que se administran y crecen los sitios de grupos. También hay más oportunidades de compartir las plantillas y la navegación entre proyectos y equipos que comparten una colección de sitios.
El modelo incorpora el segundo método, lo que da como resultado una jerarquía de colección de sitios similar tanto para los sitios de grupo como para el contenido publicado de la intranet. El desafío para los arquitectos de la información es crear un segundo nivel de colecciones de sitios que tenga sentido para la organización. En la tabla siguiente se enumeran sugerencias para distintos tipos de organizaciones.
| Tipo de organización | Sugerencias de taxonomía de colección de sitios |
|---|---|
Desarrollo de productos |
|
Investigación |
|
Institución de enseñanza superior |
|
Departamento legislativo estatal |
|
Departamento legislativo corporativo |
|
Fabricación |
|
Sitio web de asociados
El sitio web de asociados está pensado para la colaboración con asociados externos en proyectos que tienen ámbitos finitos o duraciones finitas. Por su diseño, los sitios de la aplicación web de asociados no están diseñados para estar relacionados. Entre los requisitos del sitio web de asociados se incluye garantizar que:
Los propietarios de los proyectos pueden crear fácilmente sitios para la colaboración de asociados.
Los asociados y otros colaboradores tienen acceso sólo al proyecto en el que están trabajando.
Los propietarios de los sitios administran los permisos.
Los resultados de la búsqueda desde dentro de un proyecto no exponen el contenido de otros proyectos.
Los administradores pueden identificar fácilmente los sitios que ya no se usan y eliminar estos sitios.
Para satisfacer estos requisitos, el modelo incorpora una colección de sitios para cada proyecto. De este modo, se obtienen las siguientes ventajas:
Las colecciones de sitios individuales proporcionan el nivel adecuado de aislamiento entre proyectos.
Se puede implementar la creación de sitios sin intervención del administrador.
Debido a que la aplicación web de asociados también hospeda las colecciones de sitios para desarrollar contenido del sitio de Internet de la empresa, se crean colecciones de sitios independientes para la creación y el almacenamiento provisional.
Sitio de Internet de la empresa
El sitio de Internet de la empresa incorpora una sola colección de sitios de nivel raíz. Todos los sitios incluidos bajo esta colección de sitios son subsitios. Esta estructura simplifica las direcciones URL para las páginas incluidas dentro del sitio. La siguiente ilustración muestra la arquitectura del sitio de Internet de la empresa.
.jpg "Arquitectura de implementación lógica")
Bases de datos de contenido
Puede usar los dos enfoques siguientes para incorporar las bases de datos de contenido en el diseño (el modelo incorpora ambos enfoques):
Establecer objetivos de tamaño para las bases de datos de contenido con los umbrales de advertencia de tamaño apropiados y crear una base de datos nueva cuando se alcancen dichos umbrales. Con este enfoque, las colecciones de sitios se agregan automáticamente a la base de datos o bases de datos disponibles, únicamente en función de los objetivos de tamaño.
Asociar colecciones de sitios con bases de datos de contenido específicas. Este enfoque permite colocar una o más colecciones de sitios en una base de datos dedicada que se puede administrar de forma independiente con respecto al resto.
Si decide asociar colecciones de sitios con bases de datos de contenido específicas, dispone de los métodos siguientes:
Use la herramienta de línea de comandos Stsadm para crear una colección de sitios en una base de datos específica.
Dedique una base de datos a una sola colección de sitios mediante la aplicación de la siguiente configuración de capacidad de base de datos:
Número de sitios antes de que se genere un evento de advertencia = 1
Número máximo de sitios que se puede crear en esta base de datos = 1
Agregue un grupo de colecciones de sitios a una base de datos dedicada llevando a cabo los siguientes pasos:
Dentro de la aplicación web, cree la base de datos y establezca el estado de la base de datos en Listo.
Establezca el estado de todas las demás bases de datos en Sin conexión. Mientras las bases de datos de contenido están sin conexión, no se pueden crear nuevas colecciones de sitios. Sin embargo, las colecciones de sitios existentes de las bases de datos sin conexión siguen estando accesibles para operaciones de lectura y escritura.
Cree las colecciones de sitios. Se agregan a la base de datos automáticamente.
Vuelva a establecer el estado de todas las demás bases de datos en Listo.
Contenido de intranet publicado
Para el contenido publicado de la intranet, el modelo incorpora una base de datos dedicada para cada una de las colecciones de sitios del departamento.
Este enfoque permite a cada departamento administrar su contenido de forma independiente.
Mis sitios
Para Mis sitios, el modelo consigue la eficacia de escala mediante la administración de bases de datos hasta el objetivo de tamaño máximo. Para lograr este objetivo, se han de establecer las siguientes opciones de configuración:
Limitar el almacenamiento del sitio a un máximo de Esta opción de configuración, que se establece en la página Plantillas de cuota de Administración central, limita el tamaño de un sitio personal.
Papelera de reciclaje de la segunda etapa Esta opción de configuración, que se establece en la página Configuración general de la aplicación web, determina cuánto espacio adicional se asigna a la papelera de reciclaje de la segunda etapa.
Número máximo de sitios que se puede crear en esta base de datos Esta opción de configuración se establece al crear una base de datos. Calcule el número total de sitios permitido mediante el uso de las cifras especificadas para los dos valores anteriores. A continuación, en función del objetivo de tamaño de cada base de datos, determine cuántos sitios cabrán en la base de datos.
El modelo proporciona la siguiente configuración de tamaño basada en un objetivo de tamaño de base de datos de 100 gigabytes (GB) y un objetivo de tamaño para Mi sitio de 500 megabytes (MB):
Límite de tamaño por sitio = 500 MB
Objetivo de tamaño de la base de datos = 100 GB
Número máximo de sitios = 200
Advertencia de nivel de sitio = 150
Cuando se alcance la advertencia de nivel de sitio, cree una nueva base de datos. Después de crear la nueva base de datos, se agregan de manera alterna nuevos sitios personales de Mis sitios a la nueva base de datos y la base de datos existente hasta que se alcance el número máximo de sitios para una de las bases de datos.
Para obtener más información acerca del diseño de la configuración de base de datos para Mis sitios, vea Diseño de la arquitectura de Mis sitios.
Sitios de grupo
Para los sitios de grupo, el modelo incorpora una base de datos dedicada para cada una de las colecciones de sitios de grupo. Este enfoque permite administrar la base de datos de cada equipo de forma independiente para realizar copias de seguridad, restauraciones y migraciones. Asimismo, cuando se haya completado un proyecto, se puede archivar fácilmente la base de datos asociada al mismo.
Sitio web de asociados
De forma similar a Mis sitios, el sitio web de asociados logra la eficacia de escala mediante la administración de bases de datos hasta el objetivo de tamaño máximo. Sin embargo, en el modelo, el sitio web de asociados también hospeda las colecciones de sitios de creación y almacenamiento provisional para el sitio de Internet de la empresa. Como consecuencia, el diseño de la base de datos incorpora ambos enfoques:
Las colecciones de sitios de creación y almacenamiento provisional se hospedan en una base de datos dedicada.
La configuración de tamaño y base de datos se establece para administrar todos los demás sitios y bases de datos.
El sitio web de asociados se hospeda en una aplicación web dedicada, lo que le permite crear límites de tamaño que son más apropiados para los tipos de tamaños que se crean. El modelo ofrece las siguientes opciones de configuración de tamaño de ejemplo:
Objetivo de tamaño de la base de datos = 100 GB
Cuota de almacenamiento por sitio = 5 GB
Número máximo de sitios = 20
Colecciones de sitios de creación y almacenamiento provisional hospedados en bases de datos dedicadas
Sitio de Internet de la empresa
El uso de una sola colección de sitios en el diseño del sitio de Internet de la empresa permite usar una sola base de datos para esta aplicación web.
Zonas y direcciones URL
El modelo ilustra cómo coordinar las direcciones URL entre las distintas aplicaciones de una implementación corporativa.
Objetivos de diseño
Los siguientes objetivos influyen en las decisiones de diseño de las direcciones URL:
Las convenciones de las direcciones URL no limitan las zonas a través de las cuales es posible tener acceso al contenido.
Los puertos HTTP y HTTPS (80 y 443) estándar pueden usarse en todas las aplicaciones del modelo.
Los números de puerto no se incluyen en las direcciones URL. En la práctica, los números de puerto no suelen usarse en entornos de producción.
Principios de diseño
Para lograr estos objetivos de diseño, se aplican los siguientes principios de diseño:
No se usan colecciones de sitios con nombre de host. Tenga en cuenta que las colecciones de sitios con nombre de host no son lo mismo que los encabezados de host de IIS. Las colecciones de sitios con nombre de host no funcionan con la característica de asignaciones alternativas de acceso. La característica de asignaciones alternativas de acceso es necesaria para tener acceso al mismo contenido a través de varias direcciones URL de dominio. Por lo tanto, cuando se usan sitios con nombre de host, estos sitios están disponibles sólo a través de la zona predeterminada. La característica de asignaciones alternativas de acceso también ofrece compatibilidad con la finalización fuera de cuadro de SSL (Capa de sockets seguros), que permite que los escenarios de acceso de empleados remotos y de asociados usen SSL (https).
Cada aplicación incorpora una sola colección de sitios raíz. Esto es un requisito para usar asignaciones alternativas de acceso. Si se requieren varias colecciones de sitios raíz dentro de una aplicación web y prevé usar sólo la zona predeterminada para el acceso de usuarios, las colecciones de sitios con nombre de host son una buena opción.
Para la aplicación que incluye varias colecciones de sitios de alto nivel, donde cada colección de sitios representa un proyecto o equipo de nivel superior (por ejemplo, sitios de grupo), el modelo incorpora las rutas de acceso administradas. Las rutas de acceso administradas proporcionan un mayor control sobre las direcciones URL para estos tipos de sitios.
Inconvenientes del diseño
El cumplimiento de los objetivos del diseño tiene ventajas e inconvenientes, entre los que se pueden citar los siguientes:
Las direcciones URL son más largas.
No se usan colecciones de sitios con nombre de host.
Diseño de direcciones URL de carga equilibrada
Cuando se crea una aplicación web, se debe elegir una dirección URL de carga equilibrada para asignarla a la aplicación. Además, se debe crear una dirección URL de carga equilibrada para cada zona que se cree dentro de una aplicación web. La dirección URL de carga equilibrada incluye el protocolo, el esquema, el nombre de host y el puerto, si se usan. La dirección URL de carga equilibrada debe ser única en todas las aplicaciones y zonas web. Por tanto, cada aplicación y cada zona de cada aplicación requieren una dirección URL única en todo el modelo.
Intranet
Cada una de las tres aplicaciones que componen la intranet requiere una dirección URL única. En el modelo, la audiencia a la que va dirigido el contenido de la intranet es la de los empleados internos y los empleados remotos. En la siguiente tabla se enumeran las direcciones URL a través de las cuales los empleados internos y remotos tendrán acceso a cada aplicación.
| Aplicación | Dirección URL de empleado interno | Dirección URL de empleado remoto |
|---|---|---|
Contenido de intranet publicado |
http://fabrikam |
https://intranet.fabrikam.com |
Sitios de grupo |
http://teams |
https://teams.fabrikam.com |
Mis sitios |
http://my |
https://my.fabrikam.com |
Sitio web de asociados
En el modelo, los empleados internos, los empleados remotos y los empleados de asociados tienen acceso al sitio web de asociados. Si bien tanto los empleados remotos como los asociados tienen acceso al sitio web de asociados externamente mediante el uso de SSL (https), cada uno de ellos necesita una dirección URL diferente para aplicar las ventajas de usar zonas independientes, es decir, diferentes métodos de autenticación y diferentes directivas de zona. En la siguiente tabla se enumeran las direcciones URL que usan los empleados internos, los empleados remotos y los empleados asociados para tener acceso al sitio web de asociados.
| Zona | Dirección URL |
|---|---|
Dirección URL de empleado interno |
http://partnerweb |
Dirección URL de empleado remoto |
https://remotepartnerweb.fabrikam.com |
Dirección URL de asociados |
https://partnerweb.fabrikam.com |
Sitio de Internet de la empresa
El sitio de Internet de la empresa es un sitio público y a él puede tener acceso cualquier usuario a través de la dirección URL predeterminada: http://www.fabrikam.com. Se aplican las directivas de la zona de Internet (es decir, el acceso anónimo y la denegación de escritura).
Sin embargo, para admitir las tareas de administración y creación en el sitio público, el modelo incorpora las direcciones URL de los empleados internos y remotos. Las directivas para estas zonas limitan los permisos superiores al acceso de lectura a los grupos de seguridad de destino. En la siguiente tabla se enumeran las direcciones URL de cada zona.
| Zona | Dirección URL |
|---|---|
Dirección URL de empleado interno |
http://fabrikamsite |
Dirección URL de empleado remoto |
https://fabrikamsite.fabrikam.com |
Dirección URL de cliente |
http://www.fabrikam.com |
Uso de inclusiones explícitas y de caracteres comodín para rutas de acceso de direcciones URL
Al definir rutas de acceso administradas, puede especificar qué rutas del espacio de nombres de direcciones URL de una aplicación web se usan para colecciones de sitios. Puede especificar que existen una o varias colecciones de sitios en una ruta de acceso distinta situada por debajo del sitio raíz. Sin rutas de acceso administradas, todos los sitios creados por debajo de la colección de sitios raíz forman parte de la colección de sitios raíz.
Puede crear los dos tipos siguientes de rutas de acceso administradas:
Inclusión explícita Colección de sitios con la dirección URL explícita que asigne. Una inclusión explícita se aplica a una sola colección de sitios. Puede crear muchas inclusiones explícitas debajo de una colección de sitios raíz. Una dirección URL de ejemplo para una colección de sitios creada con este método es http://fabrikam/hr.
Inclusión de caracteres comodín Ruta de acceso que se agrega a la dirección URL. Esta ruta de acceso indica que todos los sitios que se especifican directamente después del nombre de la ruta de acceso son colecciones de sitios únicas. Esta opción suele usarse en el caso de aquellas aplicaciones que admiten la creación de sitios automáticos, como Mis sitios. Un ejemplo de una dirección URL de una colección de sitios creada mediante este método es http://my/personal/user1.
El modelo incorpora el uso de ambos tipos, como se describe en las secciones siguientes.
Inclusiones explícitas: sitios de grupo y contenido de intranet publicado
En el modelo, tanto la aplicación de sitios de grupo como las aplicaciones de contenido de intranet publicado incorporan el uso de inclusiones explícitas.
Sitios de grupo
Dentro de la aplicación de sitios de grupo se usa una inclusión explícita para cada colección de sitios de grupo. El límite de escala en colecciones de sitios creados con una inclusión explícita es de aproximadamente 100 sitios. Recomendamos mantener el número de sitios de grupo de nivel superior en un número que sea fácil de administrar. Asimismo, la taxonomía de los sitios de grupo debe ser lógica para el modo en que funcione el negocio. Muchas organizaciones se ajustan bien a la recomendación de 100 sitios. Si su organización requiere una escala mayor para sitios de grupo, use una inclusión de caracteres comodín.
En el modelo, el uso de inclusiones explícitas produce las direcciones URL de la siguiente tabla.
| Empleado interno (zona de Intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://team/Team1 |
https://team.fabrikam.com/Team1 |
http://team/Team2 |
https://team.fabrikam.com/Team2 |
http://team/Team3 |
https://team.fabrikam.com/Team3 |
En este ejemplo, la colección de sitios raíz, http://Team, no necesariamente hospeda contenido para los usuarios.
Contenido de intranet publicado
Dentro de la aplicación de contenido de intranet publicado, se usa una inclusión explícita para cada subsitio: recursos humanos (RH), instalaciones (Facilities) y compras (Purchasing). Esto permite que cada uno de estos sitios sea administrado de forma independiente. Cada una de estas colecciones de sitios puede asociarse a una base de datos de contenido diferente, si ello es necesario, para administrar el crecimiento y ofrecer la oportunidad de realizar copias de seguridad y restaurar estos sitios por separado.
En el modelo, el uso de inclusiones explícitas produce las direcciones URL de la siguiente tabla.
| Empleado interno (zona de Intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
En este ejemplo, la colección de sitios raíz, http://fabrikam, representa la página principal predeterminada para la intranet. Este sitio está diseñado para hospedar contenido para los usuarios.
Inclusiones de caracteres comodín: sitio web de asociados y Mis sitios
Tanto el sitio web de asociados como Mis sitios incorporan el uso de una inclusión de caracteres comodín. Las inclusiones de caracteres comodín son ideales para las aplicaciones que permiten a los usuarios crear sus propias colecciones de sitios. Una inclusión de caracteres comodín indica que el siguiente elemento tras el comodín es un sitio raíz de una colección de sitios.
Mis sitios
Mis sitios ofrece la funcionalidad de creación de sitios sin intervención del administrador. Cuando un usuario que explora la intranet en primer lugar hace clic en Mi sitio, se crea automáticamente un sitio personal Mi sitio para el usuario. En el modelo, Mis sitios incluye una inclusión de caracteres comodín denominada /personal (http://my/personal). La característica Mi sitio agrega automáticamente el nombre de usuario a la dirección URL.
Esto da como resultado direcciones URL con el formato que se muestra en la tabla siguiente.
| Empleado interno (zona de intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://my/sites/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/sites/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/sites/user3 |
https://my.fabrikam.com/personal/user3 |
Sitio web de asociados
El sitio web de asociados está diseñado para permitir a los empleados crear fácilmente sitios seguros para la colaboración con asociados externos. Para admitir este objetivo, se permite la creación de sitios sin intervención del administrador.
En el modelo, el sitio web de asociados incluye una inclusión de caracteres comodín denominada (http://partnerweb/sites). Esto da como resultado direcciones URL con el formato que se muestra en la siguiente tabla.
| Empleado interno (zona de Intranet) | Empleado remoto (zona predeterminada) |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
Los colaboradores asociados pueden tener acceso a sitios web de asociados a través de las direcciones URL que se enumeran en la tabla siguiente.
| Asociado (zona de extranet) |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
La excepción para el sitio web de asociados, como se ilustra en el modelo, son las dos colecciones de sitios que están dedicadas a la creación y almacenamiento provisional del contenido del sitio de Internet de la empresa. Para estas dos colecciones de sitios, se usa una inclusión explícita. Esto es un ejemplo de cómo usar inclusiones explícitas y de caracteres comodín en la misma aplicación web.
Direcciones URL de administración
En la siguiente tabla se enumeran las direcciones URL para la zona de administración de cada una de las aplicaciones hospedadas en la granja de servidores.
| Aplicación | Dirección URL |
|---|---|
Contenido de intranet publicado |
http://fabrikam.admin |
Sitios de grupo |
http://teams.admin |
Mis sitios |
http://my.admin |
Sitio web de asociados |
http://partnerweb.admin |
Sitio de Internet de la empresa |
http://fabrikamsite.admin |
El modelo supone que los administradores tienen acceso interno a la red corporativa.
Directivas de zona
Puede crear una directiva para una aplicación web con el fin de aplicar los permisos en el nivel de la aplicación web. Una directiva se puede definir para la aplicación web en general o sólo para una zona específica. Una directiva aplica permisos a todo el contenido incluido en la aplicación web o en la zona. Los permisos de directiva reemplazan todos los demás valores de configuración de seguridad que se hayan establecido para los sitios y el contenido. Puede configurar la directiva según usuarios o grupos de usuarios, pero no según grupos de SharePoint.
El modelo proporciona ejemplos de varias directivas para conseguir lo siguiente:
Conceder a los administradores acceso a todo el contenido.
Denegar el acceso de escritura para el contenido publicado.
Garantizar que los autores y los evaluadores tienen un acceso apropiado para el contenido publicado.
Descarga de este libro
En este tema se incluye el siguiente libro descargable para facilitar la lectura y la impresión:
Vea la lista completa de libros disponibles en la sección de libros descargables para Office SharePoint Server 2007.