Dentro de SharePoint Proteger las comunicaciones externas de SharePoint

Pav Cherny

Contents

Consideraciones de diseño de topología
Autenticación
La configuración a soporte técnico del sitio TLS
Configuración de IIS para certificados SSL
Configuración del servidor ISA
Facilitar las molestias

Cifrar el tráfico de SharePoint en escenarios de acceso a Internet mediante seguridad de nivel de transporte (TLS) Secure Sockets Layer (SSL) es un enfoque familiarizado para proteger la comunicación. Dado que cuando Netscape introdujo SSL como medio para proteger los datos a través de criptografía de 1995 se implementa en la parte superior del protocolo HTTP, comunicación cliente/servidor basada en Web ha mucho se basaban en los certificados SSL. Las tecnologías de SharePoint aprovechan TLS mediante IIS con. NET, que proporcionan la plataforma de servidor Web compatible con TLS subyacente. Sin embargo, habilitar TLS para los sitios de SharePoint es sólo un aspecto de proteger la comunicación externa. También debe considerar otros aspectos como basado en host y red de servidores de seguridad, topología de diseño, Active Directory subyacente y dependencias de la red física.

En la columna de 2009 de julio, tratan opciones para proteger la comunicación de servidor en el entorno interno por exigir directivas de mantenimiento protección de acceso a través de redes (NAP) con IPSec y por siguientes generales SharePoint recomendaciones de seguridad. Uno de las claves instalaciones de proteger la comunicación interna es conocer la identidad de los usuarios internos y los equipos y, basándose en esto, crear directivas para conceder y restringir el acceso. Esta premisa es eficaz en un entorno autenticado como uno que utiliza Active Directory y Kerberos o NT LAN Manager (NTLM), pero es incompleta en entornos donde al menos algunos de los usuarios son anónimas o donde una clase de usuarios, como proveedores o socios, necesita distintas directivas aplicadas. Seguridad en el contexto de sitios de Internet requiere un enfoque similar del uso de varios niveles.

Uno de los principios subyacentes de proteger la comunicación externa está bloqueando el acceso no deseado tan pronto como sea posible, al tener la capacidad para realizar auditorías de seguridad y registro para los usuarios no autenticados y autenticados. El enfoque típico para satisfacer esta necesidad es utilizar, como mínimo, un servidor de seguridad en el borde de la red para la inspección con estado de autenticación y de usuario del tráfico HTTP. Sin embargo, TLS supone un desafío para la inspección de paquetes con estado, ya que el servidor de seguridad debe poder descifrar los paquetes, inspeccionarlos, volver a cifrarlos y pasarlos a un servidor de solicitudes de cliente para su procesamiento. Además, el servidor de seguridad (y cualquier solución de equilibrio de carga) deben conservar sesiones HTTPS. Internet Security and Acceleration (ISA) Server 2006 y Server Intelligent Application Gateway (IAG) 2007 proporcionan una solución firewall que funciona junto con IIS y SharePoint para ofrecer un medio compatible con TLS para proteger la comunicación.

Descripción de la comunicación TLS en SharePoint requiere un conocimiento de cómo la arquitectura de alojamiento y topología afectan al modo de IIS y los servidores de seguridad controlan certificados SSL. Por consiguiente, hay una serie de consideraciones para diseñar e implementar soluciones de SharePoint que son accesibles desde Internet. La arquitectura de SharePoint incluye algunos aspectos de configuración desafiante en además a consideraciones de IIS, SSL y servidor de seguridad, como asignaciones alternativas de acceso (AAM), autenticación y las zonas de SharePoint.

Consideraciones de diseño de topología

Desarrollo de varios niveles de seguridad de sitios de SharePoint comienza con definir la topología de red física. Si puede reducir o eliminar el tráfico no deseado antes de aciertos de servidores de aplicaciones para usuario y de servicios de fondo, no sólo reducir la carga del servidor sino también podrían mitigar los riesgos de virus, correo no deseado y software malintencionado que vienen con tráfico malintencionado.

En el escenario de uso necesario para su organización depende de la topología de red que admite TLS para SharePoint. Figure 1 shows a decision tree with some considerations and relevant topology decisions.

Puede simplificar las decisiones más separando las distintas opciones topología en tres áreas:

• Tráfico antes de el servidor de seguridad de aciertos.
• Tráfico entre el servidor de seguridad y la red interna.
• Tráfico dentro de la red interna.

Figura 1 Consideraciones de decisión para topologías accesible en Internet.

En términos de la configuración de TLS, que hace esta distinción es vital porque se debe configurar reglas de enrutamiento y el servidor de seguridad para enlazar conexiones HTTPS entre las solicitudes de Internet y los servidores de aplicaciones para usuario de IIS, configure IIS para servir aplicaciones SharePoint y garantizar que los recursos internos están protegidos. Dependiendo de la topología del tráfico TLS deberá ser capaz de recorrer los tres de estas áreas a través de varios enrutadores y servidores de seguridad. Vamos a echar un vistazo a tres opciones de topología de sitios Internet accesibles y considere la repercusión de las topologías del tráfico TLS. Figure 2 shows a basic "edge" topology with one firewall securing internal servers.

Figura 2 Topología de borde básico con un único servidor de seguridad.

En la topología de borde, un firewall de red único significa entre los usuarios externos y sitios de SharePoint internos. Tiene la ventaja de utilizar un único entorno de Active Directory para los usuarios internos y externos, que simplifica la administración y mantenimiento. Para proteger el tráfico a través de TLS, configure el servidor de seguridad también actúan como un proxy inverso. El concepto de un proxy inverso integrado como ISA Server es fundamental para proteger los sitios orientados a Internet, ya que el proxy inverso intercepta las solicitudes entrantes, puede autenticar los usuarios externos, descifra el tráfico TLS, inspecciona con las reglas de firewall y reenvía las solicitudes a servidores. Direcciones URL públicas pueden diferir las URL internas, por lo que el proxy inverso debe tener un medio para traducir vínculos para convertir direcciones URL externas en las direcciones URL internas. IAG Server proporciona funciones de seguridad adicionales, como extremo de la autorización basada en estado a través de una directiva de acceso basada en estado de equipo cliente y la identidad de usuario y la capacidad de traducir vínculos internos direcciones URL de SharePoint cuando se utiliza Outlook Web Access.

Para agregar una capa adicional a la topología y ejercer un control más granular sobre la comunicación entre servidores, puede crear una red perimetral que aloja servidores de SharePoint. En una red perimetral, los servidores de SharePoint están aislados de Internet mediante un servidor de seguridad y de la red interna por un servidor de seguridad. Esto es una topología de tipo opuesto con opuesto, como se muestra en figura 3.

Figura 3 una topología “ opuesto con opuesto ” con dos servidores de seguridad.

Por supuesto, no están limitados a sólo dos servidores de seguridad en una topología de tipo opuesto con opuesto o sándwich. Puede implementar capas adicionales separadas por servidores de seguridad o los enrutadores más separan las funciones de SharePoint. Por ejemplo, puede utilizar un enfoque de tres niveles, colocando cada capa en una DMZ, donde servidores están en primer lugar, seguido por aplicación, base de datos y índice de búsqueda y el servidor y terminar por servidores DNS de Active Directory. También puede personalizar una topología para incluir un entorno de ensayo interno en una batería independiente y publicarlo en el conjunto en la red perimetral opuesto con opuesto. Otra opción es dividir la granja de SharePoint entre la red perimetral y la red interna para crear una topología de tipo opuesto con opuesto o sándwich de división, como se muestra en la figura 4. En consonancia con el enfoque del uso de las capas de seguridad en la topología, los servidores de aplicaciones para usuario residen en la red perimetral y los servidores back-end que ejecuta SQL Server residen en la red interna. Las funciones restantes, como índice, búsqueda y administración central, pueden estar en cualquier red.

Figura 4 en una topología de tipo opuesto con opuesto o sándwich “ dividir ”, funciones de servidor pueden configurarse en la DMZ o en la red interna.

Coloque el servidor de búsqueda en la red interna para búsqueda óptima y rendimiento de rastreo. Puede dedicar el servidor de búsqueda a rastrear. Tenga en cuenta que la topología de tipo opuesto con opuesto o sándwich división requiere una confianza unidireccional entre el perímetro y interno y entornos de Active Directory para admitir la comunicación.

Resources

Sitio Web de Productos y tecnologías de SharePoint

Windows SharePoint Services TechCenter

Centro de desarrolladores de Windows SharePoint Services

Blog del equipo de Productos y Tecnologías de Microsoft SharePoint

Autenticación

Determinar la configuración de autenticación adecuado para proteger la comunicación externa puede convertirse rápidamente en abrumadora, debido a las opciones disponibles y los niveles de topología en la autenticación y autorización tiene lugar.

Por ejemplo, su entorno puede admitir RSA SecurID, incorporar Server directivas de redes (NPS) o utilice un directorio personalizado de basado en protocolo LIGHTWEIGHT Directory Access. Al final, los aspectos relevantes de la autenticación de proteger la comunicación externa de SharePoint incluyen la autenticación de usuarios internos y externos y autenticación de IIS para sitios de SharePoint.

Vamos a simplificar estos aspectos más trazando la ruta de comunicación de solicitudes de los usuarios externos a los sitios de SharePoint para ver cómo ocurrir la autenticación y autorización.

1. Un usuario externo realiza una solicitud que se enruta al servidor de seguridad. Si el servidor de seguridad es un servidor ISA configurado para utilizar autenticación basada en formularios (FBA), el usuario se presenta con un formulario de inicio de sesión y autenticado. A continuación, se envía la solicitud a un servidor de aplicaciones para usuario.
2. IIS en el servidor de aplicaciones para usuario acepta la solicitud;Determina el sitio asociado con la dirección URL;comprueba la configuración de autenticación para el sitio;autentica el tráfico;y lo pasa a SharePoint para la autorización.
3. SharePoint realiza la autorización. Permisos de sitio de SharePoint y la autorización son fuera del ámbito de este artículo, porque TLS está configurado para cada sitio en el nivel IIS. Para obtener más información acerca de autenticación y autorización de SharePoint, consulte plan autenticación métodos (Office SharePoint Server).

La configuración a soporte técnico del sitio TLS

SharePoint depende en gran medida IIS y el subyacente de la topología y configuración de autenticación para proporcionar la funcionalidad necesaria para admitir TLS. Cuando el tráfico se enruta a SharePoint, ya tiene pasa a través del servidor de seguridad y se ha controlado por IIS. Configurar sitios de SharePoint para admitir TLS es más una tarea informándole de SharePoint del entorno subyacente para cada sitio que directamente de especificar los certificados SSL, crear cuenta de servicio y así sucesivamente. Sin embargo, es importante tener en cuenta dos detalles de específicos de SharePoint al implementar TLS: las zonas y asignación de acceso alternativa (AAM). Ambos están configurados en el sitio Administración Central en Administración de aplicaciones.

Al crear o extender una aplicación Web, puede especificar las zonas y especificar detalles sobre el entorno de SharePoint utiliza para crear un conjunto inicial de AAMs (consulte la figura 5). Las consideraciones clave desde una perspectiva de seguridad son el proveedor de autenticación y si el servidor ISA utiliza TLS para comunicarse con el servidor de solicitudes de cliente, o termina las solicitudes HTTPS desde los usuarios externos en el servidor de seguridad y se comunica a través de HTTP.

Figura 5 SSL y otras opciones de guration de confi para un sitio de SharePoint.

Aunque el uso de TLS para la comunicación del servidor ISA a servidores crea adicional procesamiento sobrecarga, se proporciona una solución cifrada de extremo a extremo y mi método preferido. Finalizando TLS en el servidor ISA también puede romper algunos escenarios de uso, como cuando mediante elementos Web personalizados que almacenan direcciones URL en una base de datos de SQL Server. El proceso es similar para enabeing un sitio existente para TLS. Debe comprobar el botón de opción de utilizar Secure Sockets Layer (SSL), configurar las opciones y, a continuación, vaya a la configuración de AAM y compruebe que están configurados correctamente.

Configuración de zona y AAM es interrelacionada. SharePoint utiliza la idea de las zonas para permitir lógicas distinciones entre partes de la topología, como Internet, extranet, intranet y las direcciones URL disponibles para las partes. Las definiciones de AAM especifican el encabezado de dirección URL debe aspecto para los usuarios de distintas zonas cuando la dirección URL es diferente de la dirección URL interna. Si la dirección URL interna es igual a una dirección URL pública que utiliza un nombre de dominio completo (FQDN), no es necesario configurar AAM;SharePoint realiza automáticamente. Para otros escenarios, configurar AAMs para los sitios de SharePoint. Troy Starr registra una descripción completa de AAMs para SharePoint en el blog de SharePoint Team, que encontrará en qué necesita saber acerca de asignaciones de acceso alternativas (parte 1 de 3) cada administrador de SharePoint. Merece la pena un aspecto;Configuración incorrecta de AAM es una de las causas más predominantes de problemas de escenario de extranet.

Configuración de IIS para certificados SSL

Como se mencionó, habilitar SSL para un sitio de SharePoint se realiza en el nivel IIS. En IIS7, se configuran los certificados SSL a través de certificados de servidor. Se encuentran en la página Propiedades del servidor IIS. Microsoft ha publicado ya instrucciones, consideraciones y escenarios de uso para tener en cuenta al habilitar sitios de IIS para utilizar SSL;Recuerde que entidad emisora de certificados e IP dirección y puerto enlace son especialmente relevantes para proteger sitios accesibles de Internet. Hay varias opciones para generar un certificado SSL. Puede utilizar selfssl.exe, implementar una PKI con una entidad emisora de certificados de Windows confianza (CA) o utilizar un proveedor comercial. Para propósitos de desarrollo y entornos de laboratorio, un certificado autofirmado funciona bien, pero que pueden surgir problemas de usuario para entornos de producción. A menos que los usuarios aceptan el certificado en sus exploradores, se pedirá al tener acceso a un sitio SSL habilitado que el certificado procede de un origen que no sea de confianza. Esto puede producir para admitir llamadas y confusión, lo que facilita implementar un certificado de producción de una entidad emisora de CERTIFICADOS raíz.

Es posible utilizar la misma dirección IP o el mismo puerto para varios sitios SSL habilitado. La sencilla consiste en utilizar una dirección IP fija y el mismo puerto para cada sitio, por lo que IIS puede enlazar el sitio a la dirección IP y puerto. Como alternativa, si utiliza la configuración de un dominio de raíz y varios subsitios, puede utilizar un comodín certificado o con varios nombres alternativos de sitio (SAN). El proceso es principalmente el mismo que para un certificado normal, pero no puede configurar en la pantalla IIS 7e en enlaces de sitios. En su lugar, utilice appcmd y ejecute el comando siguiente para enlazar SSL al sitio y establecer el encabezado de host: Sitio /site C:\Windows\System32\inetsrv\appcmd Set. nombre: < CustomSiteName >/ + enlaces. [protocolo = 'https', bindingInformation = ' *: 443: < FQDN >]. Si se realizan correctamente, verá un enlace de SSL con el encabezado de host especificado en los enlaces de sitios.

Configuración del servidor ISA

Independientemente de si desea proteger un sitio de SharePoint nuevo o existente con TLS, debe asegurarse de que el tráfico puede atravesar el servidor de seguridad. ISA Server proporciona varios mecanismos que funcionan con SharePoint y permiten la exploración transversal: FBA, HTTPS, puentes, traducción de vínculos a través de proxy inverso y SharePoint reglas de publicación.

ISA Server utiliza a un Asistente para ayudarle a publicar sitios de SharePoint. Este asistente crea un agente de escucha y un "Permitir"regla para permitir el tráfico de SharePoint. Antes de ejecutar al asistente, exportar el certificado SSL instalado a través de IIS en el servidor front-end aloja el sitio e importarla a ISA Server mediante el complemento MMC certificados. Importar el certificado en el almacén personal de cuentas de equipo local. Esto permite que el agente de escucha se crea en el servidor ISA para descifrar el tráfico entrante, inspeccionarla y cifrarlos. Para obtener más información acerca de cómo configurar ISA Server para SharePoint, vea autenticación en ISA Server 2006 y configurar ISA 2006 para SharePoint 2007.

En el momento en que configura ISA Server para publicar los sitios de SharePoint con SSL habilitado, internos y direcciones URL externas son resolverse mediante DNS;las cuentas de usuario y permisos se han configurado;Se configuran las zonas de SharePoint y AAMs;y tener instalado el certificado SSL para el sitio a través de IIS. En este momento, especifique los detalles relevantes en el servidor ISA. Cuando configura el agente de escucha y la regla de publicación, tenga en cuenta lo siguiente:

• AAM: Para que la asignación de acceso alternativo funcione correctamente, debe configurar la regla de publicación para reenviar el encabezado de host original. También, asegúrese de que especificar las direcciones FQDN adecuadas para las URL internas y externas.
• FBA: Asegúrese de que seleccionar autenticación de formularios HTML y de Windows (Active Directory) en la ficha autenticación, a menos que esté usando Kerberos o una solución de autenticación personalizada.
• Denegar el acceso a los usuarios no autenticados. Para mejorar la seguridad, asegúrese de que agregar todos los usuarios autenticados. Alternativelyr Seleccionar usuarios específicos en conjuntos de usuarios y asegúrese de quitar todos los usuarios.

Facilitar las molestias

Proteger los sitios de SharePoint mediante TLS puede ser completa de los problemas. El servidor de seguridad correctamente puede dirigir el tráfico como un proxy inverso o puede realizar un trabajo deficiente de traducción de vínculos. La configuración de enrutamiento no esté configurada correctamente en las topologías más complejas. O las configuraciones de AAM y zona no pueden coincidir con la configuración de DNS o servidor de seguridad. La buena noticia es que si el enfoque seguridad externa con un enfoque de varias capas, puede aislar los problemas y resolverlos. Puede facilitar su vida incluso si utiliza ISA Server con autenticación de FBA y Windows. Elija la topología adecuada, configurar el sitio de SharePoint, habilitarla para SSL en IIS, póngalo todo juntos con ISA Server y ha protegido la comunicación externa a través de TLS.

Pav Cherny es experto en TI y autor especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus publicaciones incluyen notas y manuales de productos, y libros centrados en operaciones de TI y administración de sistemas. Pav Cherny es presidente de Biblioso Corporation, una empresa especializada en servicios administrados de documentación y localización.