Habilitar el aislamiento de subdominio

Acerca del aislamiento de subdominio

El aislamiento de subdominio mitiga las vulnerabilidades del estilo cross-site scripting y otras vulnerabilidades relacionadas. Para más información, vea "Scripting entre sitios" en Wikipedia. Se recomienda encarecidamente habilitar el aislamiento de subdominios en tu instancia de GitHub Enterprise Server.

Cuando el aislamiento de subdominio está habilitado, GitHub Enterprise Server reemplaza varias rutas con subdominios. Después de habilitar el aislamiento de subdominios, los intentos para acceder a las rutas anteriores para encontrar algo del contenido proporcionado por los usuarios, como http(s)://HOSTNAME/raw/, podría devolver errores de tipo 404.

Nota: Los subdominios http(s)://notebooks.HOSTNAME o http(s)://viewscreen.HOSTNAME son nuevos en GitHub Enterprise Server 3.7 y versiones posteriores, y reemplazan a http(s)://render.HOSTNAME. Después de actualizar a la versión 3.7 o posterior, el certificado TLS debe cubrir el subdominio de los servicios de reemplazo, http(s)://notebooks.HOSTNAME y http(s)://viewscreen.HOSTNAME.

Ruta sin aislamiento de subdominio	Ruta con aislamiento de subdominio
`http(s)://HOSTNAME/`	`http(s)://docker.HOSTNAME/`
`http(s)://HOSTNAME/_registry/npm/`	`https://npm.HOSTNAME/`
`http(s)://HOSTNAME/_registry/rubygems/`	`https://rubygems.HOSTNAME/`
`http(s)://HOSTNAME/_registry/maven/`	`https://maven.HOSTNAME/`
`http(s)://HOSTNAME/_registry/nuget/`	`https://nuget.HOSTNAME/`
`http(s)://HOSTNAME/assets/`	`http(s)://assets.HOSTNAME/`
`http(s)://HOSTNAME/avatars/`	`http(s)://avatars.HOSTNAME/`
`http(s)://HOSTNAME/codeload/`	`http(s)://codeload.HOSTNAME/`
`http(s)://HOSTNAME/gist/`	`http(s)://gist.HOSTNAME/`
`http(s)://HOSTNAME/media/`	`http(s)://media.HOSTNAME/`
`http(s)://HOSTNAME/notebooks/`	`http(s)://notebooks.HOSTNAME/`
`http(s)://HOSTNAME/pages/`	`http(s)://pages.HOSTNAME/`
`http(s)://HOSTNAME/raw/`	`http(s)://raw.HOSTNAME/`
`http(s)://HOSTNAME/reply/`	`http(s)://reply.HOSTNAME/`
`http(s)://HOSTNAME/uploads/`	`http(s)://uploads.HOSTNAME/`
`http(s)://HOSTNAME/viewscreen/`	`http(s)://viewscreen.HOSTNAME/`
No compatible	`https://containers.HOSTNAME/`

Requisitos previos

Advertencia: Si se deshabilita el aislamiento de subdominios, también se recomienda deshabilitar GitHub Pages en la empresa. No habrá forma de aislar el contenido de GitHub Pages que suministre un usuario del resto de los datos de tu empresa. Para obtener más información, vea «Configurar GitHub Pages para tu empresa».

Antes de que habilites el aislamiento de subdominio, debes configurar tus ajustes de red para el nuevo dominio.

Especifica un nombre de dominio válido como tu nombre del host, en lugar de una dirección IP. Para obtener más información, vea «Configuración del nombre de host para la instancia».

Advertencia: No cambie el nombre de host para GitHub Enterprise Server después de la configuración inicial. Cambiar el nombre del host ocasionará un comportamiento inesperado que puede incluir, llegar hasta la interrupción del servicio y a la invalidación de las claves de seguridad de los usuarios. Si ha cambiado el nombre de host de la instancia y tiene problemas, póngase en contacto con Soporte técnico para GitHub Enterprise o Soporte prémium de GitHub.

Configura un registro de Sistema de nombres de dominio (DNS) de carácter comodín o registros DNS individuales para los subdominios detallados más arriba. Se recomienda crear un registro A para *.HOSTNAMEque apunte a la dirección IP del servidor, para no tener que crear varios registros para cada subdominio.
Obtenga un certificado de seguridad de la capa de transporte (TLS) comodín para *.HOSTNAME con un nombre alternativo del firmante (SAN) para HOSTNAME y el dominio comodín *.HOSTNAME. Por ejemplo, si el nombre de host es github.octoinc.com, obtenga un certificado con el valor Nombre común establecido en *.github.octoinc.com y un valor SAN establecido en github.octoinc.com y *.github.octoinc.com.
Habilita TLS en tu aparato. Para obtener más información, vea «Configurar TLS».