Este contenido se actualizó por última vez en diciembre de 2023 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google de ahora en adelante, ya que mejoramos la protección de nuestros clientes de forma continua.
En este documento, se describen las prácticas recomendadas que te permiten implementar un conjunto de recursos fundamentales en Google Cloud. Una base de la nube es el modelo de referencia de los recursos, las configuraciones y las capacidades que permiten a las empresas adoptarGoogle Cloud para sus necesidades comerciales. Una base bien diseñada permite una administración coherente, controles de seguridad, escalamiento, visibilidad y acceso a servicios compartidos en todas las cargas de trabajo en tu entorno de Google Cloud . Después de implementar los controles y la administración que se describen en este documento, puedes implementar cargas de trabajo en Google Cloud.
El plano de bases empresariales (antes conocido como plano de bases de seguridad) está dirigido a arquitectos, profesionales de seguridad y equipos de ingeniería de plataforma que son responsables de diseñar un entorno empresarial listo para Google Cloud. Este plano consta de lo siguiente:
- Un repositorio de GitHub de terraform-example-foundation que contiene los elementos que se pueden implementar de Terraform.
- Una guía que describe la arquitectura, el diseño y los controles que implementas con el plano (este documento).
Puedes usar esta guía de dos maneras:
- Para crear una base completa basada en las prácticas recomendadas de Google. Puedes implementar todas las recomendaciones de esta guía como un punto de partida y, luego, personalizar el entorno para abordar los requisitos específicos de tu empresa.
- Para revisar un entorno existente en Google Cloud. Puedes comparar componentes específicos de tu diseño con las prácticas recomendadas de Google.
Casos prácticos compatibles
El plano de base empresarial proporciona una capa de modelo de referencia de recursos y configuraciones que ayudan a habilitar todos los tipos de cargas de trabajo en Google Cloud. Ya sea que migres cargas de trabajo de procesamiento existentes a Google Cloud, compiles aplicaciones web alojadas en contenedores o crees cargas de trabajo de macrodatos y aprendizaje automático, el plano de base empresarial te ayuda a compilar tu entorno para admitir cargas de trabajo empresariales a gran escala.
Después de implementar el plano de base empresarial, puedes implementar cargas de trabajo directamente o implementar planos adicionales para admitir cargas de trabajo complejas que requieran capacidades adicionales.
Un modelo de seguridad de defensa en profundidad
Los servicios deGoogle Cloud se benefician del diseño de seguridad de la infraestructura de Google subyacente. Es tu responsabilidad diseñar la seguridad en los sistemas que compilas sobre Google Cloud. El plano de base empresarial te ayuda a implementar un modelo de seguridad de defensa en profundidad para tus Google Cloud servicios y cargas de trabajo.
En el siguiente diagrama, se muestra un modelo de seguridad en profundidad para tu organización deGoogle Cloud que combina controles de arquitectura, controles de políticas y controles de detección.
En el diagrama, se describen los siguientes controles:
- Los controles de políticas son restricciones programáticas que aplican opciones de configuración de recursos aceptables y evitan las configuraciones riesgosas. El plano usa una combinación de controles de políticas, incluida la validación de infraestructura como código (IaC) en las restricciones de la política de la canalización y de la organización.
- Los controles de arquitectura son la configuración de los recursos de Google Cloud, como las redes y la jerarquía de recursos. La arquitectura del plano se basa en las prácticas recomendadas de seguridad.
- Los controles de detección te permiten detectar comportamientos anómalos o maliciosos dentro de la organización. El plano usa funciones de la plataforma como Security Command Center, se integra en los controles de detección y flujos de trabajo existentes, como un centro de operaciones de seguridad (SOC) y proporciona capacidades para aplicar controles de detección personalizados.
Decisiones clave
En esta sección, se resumen las decisiones arquitectónicas de alto nivel del plano.
En el diagrama, se describe cómo los servicios de Google Cloud contribuyen a decisiones clave de arquitectura:
- Cloud Build: Los recursos de infraestructura se administran mediante un modelo de GitOps. La IaC declarativa se escribe en Terraform y se administra en un sistema de control de versión para su revisión y aprobación, y los recursos se implementan mediante Cloud Build como la herramienta de automatización de integración continua y de implementación continua (CI/CD). La canalización también aplica verificaciones de políticas como código para validar que los recursos cumplan con los parámetros de configuración esperados antes de la implementación.
- Cloud Identity: Los usuarios y la membresía del grupo se sincronizan desde tu proveedor de identidad existente. Los controles para el inicio de sesión único (SSO) y la administración del ciclo de vida de las cuentas de usuario dependen de los controles y procesos existentes del proveedor de identidad.
- Identity and Access Management (IAM): Las políticas de permisos (antes conocidas como políticas de IAM) permiten el acceso a los recursos y se aplican a los grupos según la función de trabajo. Se agregan usuarios a los grupos adecuados para recibir acceso de solo lectura a los recursos básicos. Todos los cambios en los recursos de la base se implementan a través de la canalización de CI/CD que usa las identidades de cuentas de servicio con privilegios.
- Resource Manager: Todos los recursos se administran en una sola organización, con una jerarquía de recursos de carpetas que organizan los proyectos por entornos. Los proyectos se etiquetan con metadatos para la administración, incluida la atribución de costos.
- Herramientas de redes: Las topologías de red usan VPC compartidas para proporcionar recursos de red a las cargas de trabajo en múltiples regiones y zonas, separadas por entorno y administradas de manera centralizada. Todas las rutas de red entre hosts locales, Google Cloud recursos en las redes de VPC Google Cloud y servicios son privadas. De forma predeterminada, no se permite el tráfico saliente ni el tráfico entrante desde la Internet pública.
- Cloud Logging: Los receptores de registro agregados están configurados para recopilar registros relevantes para la seguridad y auditoría en un proyecto centralizado para la retención, el análisis y la exportación a largo plazo a sistemas externos.
- Servicio de políticas de la organización: Las restricciones de las políticas de la organización se establecen para evitar varias configuraciones de alto riesgo.
- Secret Manager: Los proyectos centralizados se crean para un equipo responsable de administrar y auditar el uso de secretos de aplicación sensibles a fin de ayudar a cumplir con los requisitos de cumplimiento.
- Cloud Key Management Service (Cloud KMS): los proyectos centralizados se crean para un equipo responsable de administrar y auditar las claves de encriptación a fin de ayudar a cumplir con los requisitos de cumplimiento.
- Security Command Center: Las funciones de detección y supervisión de amenazas se proporcionan mediante una combinación de controles de seguridad integrados de Security Command Center y soluciones personalizadas que te permiten detectar y responder a eventos de seguridad.
Para obtener alternativas a estas decisiones clave, consulta alternativas.
¿Qué sigue?
- Lee sobre la autenticación y la autorización (siguiente documento de esta serie).
Autenticación y autorización
En esta sección, se presenta cómo usar Cloud Identity para administrar las identidades que usan tus empleados para acceder a los servicios de Google Cloud.
Proveedor de identidad externo como fuente de información
Recomendamos federar tu cuenta de Cloud Identity con tu proveedor de identidad existente. La federación te ayuda a garantizar que los procesos de administración de cuentas existentes se apliquen a Google Cloud y a otros servicios de Google.
Si no tienes un proveedor de identidad existente, puedes crear cuentas de usuario directamente en Cloud Identity.
En el siguiente diagrama, se muestra una vista de alto nivel de la federación de identidades y el inicio de sesión único (SSO). Usa Microsoft Active Directory, ubicado en el entorno local, como el proveedor de identidad de ejemplo.
En este diagrama, se describen las prácticas recomendadas siguientes:
- Las identidades de usuario se administran en un dominio de Active Directory ubicado en el entorno local y se federan en Cloud Identity. Active Directory usa Google Cloud Directory Sync para aprovisionar identidades a Cloud Identity.
- A los usuarios que intentan acceder a los servicios de Google se los redirecciona al proveedor de identidad externo para el inicio de sesión único con SAML, con sus credenciales existentes a fin de autenticarse. No hay contraseñas sincronizadas con Cloud Identity.
En la siguiente tabla, se proporcionan vínculos a la guía de configuración para los proveedores de identidad.
Proveedor de identidad | Orientación |
---|---|
Active Directory | |
Microsoft Entra ID (anteriormente Azure AD) | |
Otros proveedores de identidad externos (por ejemplo, Okta o Ping) |
Te recomendamos que apliques la autenticación de varios factores en tu proveedor de identidad con un mecanismo resistente al phishing como una llave de seguridad Titan.
La configuración recomendada para Cloud Identity no está automatizada a través del código de Terraform en este plano. Consulta Controles administrativos de Cloud Identity para obtener la configuración de seguridad recomendada que debes configurar, además de implementar el código de Terraform.
Grupos para el control de acceso
Una principal es una identidad a la que se le puede otorgar acceso a un recurso. Las principales incluyen Cuentas de Google para usuarios, Grupos de Google, cuentas de Google Workspace, dominios de Cloud Identity y cuentas de servicio. Algunos servicios también te permiten otorgar acceso a todos los usuarios que se autentican con una Cuenta de Google o a todos los usuarios de Internet. Para que una principal interactúe con los servicios de Google Cloud , debes otorgarles roles en la administración de identidades y accesos (IAM).
Para administrar los roles de IAM a gran escala, te recomendamos que asignes usuarios a grupos en función de sus funciones y requisitos de acceso y, luego, les otorgues roles de IAM a esos grupos. Debes agregar usuarios a grupos mediante los procesos en tu proveedor de identidad existente para la creación y membresía de grupos.
No recomendamos otorgar roles de IAM a usuarios individuales, ya que las asignaciones individuales pueden aumentar la complejidad de la administración y la auditoría de los roles.
El plano configura los grupos y los roles para el acceso de solo lectura a los recursos base. Recomendamos que implementes todos los recursos del plano a través de la canalización de base y que no otorgues roles a los usuarios a grupos para modificar los recursos de base fuera de la canalización.
En la siguiente tabla, se muestran los grupos que configura el plano para ver los recursos de la base.
Nombre | Descripción | Roles | Alcance |
---|---|---|---|
grp-gcp-org-admin@example.com |
Administradores con muchos privilegios que pueden otorgar roles de IAM a nivel de la organización. Pueden acceder a cualquier otro rol. No se recomienda este privilegio para el uso diario. | Administrador de la organización | organización |
grp-gcp-billing-admin@example.com |
Administradores con muchos privilegios que pueden modificar la cuenta de Facturación de Cloud. No se recomienda este privilegio para el uso diario. | Administrador de cuenta de facturación | organización |
grp-gcp-billing-viewer@example.com |
El equipo responsable de ver y analizar los gastos en todos los proyectos. | Visualizador de cuentas de facturación | organización |
Usuario de BigQuery | proyecto de facturación | ||
grp-gcp-audit-viewer@example.com |
El equipo responsable de auditar los registros relacionados con la seguridad. | proyecto de registro | |
grp-gcp-security-reviewer@example.com |
El equipo responsable de revisar la seguridad en la nube. | Revisor de seguridad | organización |
grp-gcp-network-viewer@example.com |
El equipo responsable de ver y mantener la configuración de red. | Visualizador de la red de Compute | organización |
grp-gcp-scc-admin@example.com |
El equipo responsable de configurar Security Command Center. | Editor administrador del centro de seguridad | organización |
grp-gcp-secrets-admin@example.com |
El equipo responsable de administrar, almacenar y auditar las credenciales y otros secretos que usan las aplicaciones. | Administrador de Secret Manager | proyectos de Secrets |
grp-gcp-kms-admin@example.com |
El equipo responsable de aplicar la administración de claves de encriptación para cumplir con los requisitos de cumplimiento. | Visualizador de Cloud KMS | proyectos de KMS |
A medida que compilas tus propias cargas de trabajo sobre la base, creas grupos adicionales y otorgas roles de IAM basados en los requisitos de acceso para cada carga de trabajo.
Te recomendamos que evites los roles básicos (como propietario, editor o visualizador) y uses roles predefinidos. Los roles básicos son demasiado permisivos e implican un posible riesgo de seguridad. Los roles Propietario y Editor pueden generar una elevación de privilegios y un movimiento lateral, y el rol Visualizador incluye acceso para leer todos los datos. Para obtener prácticas recomendadas sobre los roles de IAM, consulta Usa IAM de forma segura.
Cuentas de administrador avanzado
Los usuarios de Cloud Identity con la cuenta de administrador avanzado omiten la configuración de SSO de la organización y se autentican directamente en Cloud Identity. Esta excepción es por diseño, de modo que el administrador avanzado aún puede acceder a la consola de Cloud Identity en caso de una configuración incorrecta o interrupción del SSO. Sin embargo, significa que debes considerar una protección adicional para las cuentas de administrador avanzado.
Para proteger tus cuentas de administrador avanzado, recomendamos que siempre apliques la verificación en 2 pasos con llaves de seguridad en Cloud Identity. Si deseas obtener más información, consulta Prácticas recomendadas de seguridad para las cuentas de administrador.
Problemas con cuentas de usuario personales
Si no usaste Cloud Identity ni Google Workspace antes de integrarte a Google Cloud, es posible que los empleados de tu organización ya estén usando cuentas personales asociadas con sus identidades de correo electrónico corporativo para acceder a otros servicios de Google, como Google Marketing Platform o YouTube. Las cuentas personales son cuentas que pertenecen completamente a las personas que las crearon y son administradas por ellas. Debido a que esas cuentas no están bajo el control de tu organización y pueden incluir datos personales y corporativos, debes decidir cómo consolidar estas cuentas con otras cuentas corporativas.
Te recomendamos que consolides las cuentas de usuario personales existentes como parte de la integración en Google Cloud. Si aún no usas Google Workspace para todas tus cuentas de usuario, te recomendamos bloquear la creación de cuentas personales nuevas.
Controles administrativos de Cloud Identity
Cloud Identity tiene varios controles administrativos que no están automatizados por el código de Terraform en el plano. Te recomendamos que apliques cada uno de estos controles de seguridad de las prácticas recomendadas al comienzo de la creación de tu base.
Control | Descripción |
---|---|
Implementa la verificación en 2 pasos | Las cuentas de usuario pueden verse comprometidas mediante phishing, la ingeniería social, el robo de contraseñas o varias otras amenazas. La verificación en 2 pasos ayuda a mitigar estas amenazas. Te recomendamos que apliques la verificación en 2 pasos a todas las cuentas de usuario de tu organización con un mecanismo resistente al phishing como las llaves de seguridad Titan u otras llaves que se basen en estándares FIDO U2F (CTAP1) resistentes al phishing. |
Establece la duración de la sesión para losGoogle Cloud servicios | Los tokens de OAuth persistentes en estaciones de trabajo para desarrolladores pueden ser un riesgo de seguridad si se exponen. Te recomendamos que establezcas una política de reautenticación para requerir la autenticación cada 16 horas mediante una llave de seguridad. |
Establece la duración de la sesión para los servicios de Google | (Solo para clientes de Google Workspace)
Las sesiones web persistentes en otros servicios de Google pueden ser un riesgo de seguridad si se exponen. Recomendamos que apliques una duración máxima de sesión web y la alinees con los controles de duración de sesión en tu proveedor de SSO. |
Comparte datos de Cloud Identity con los Google Cloud servicios | Por lo general, los registros de auditoría de actividad del administrador de Google Workspace o Cloud Identity se administran y ven en la Consola del administrador, por separado de los registros en tu entorno de Google Cloud . Estos registros contienen información relevante para tu entorno de Google Cloud , como los eventos de acceso del usuario. Te recomendamos que compartas los registros de auditoría de Cloud Identity con tu entorno deGoogle Cloud para administrar de forma centralizada los registros de todas las fuentes. |
Cómo configurar la verificación posterior al SSO | En el plano, se supone que configuraste el SSO con el proveedor de identidad externo. Te recomendamos que habilites una capa de control adicional según el análisis de riesgos de acceso de Google. Después de aplicar esta configuración, es posible que los usuarios vean desafíos de acceso adicionales basados en el riesgo durante el acceso si Google considera que el acceso de los usuarios es sospechoso. |
Soluciona problemas con las cuentas de usuario personales | Los usuarios con una dirección de correo electrónico válida en tu dominio, pero sin una Cuenta de Google, pueden registrarse para obtener cuentas personales no administradas. Estas cuentas pueden contener datos corporativos, pero no los controlan tus procesos de administración del ciclo de vida de las cuentas. Te recomendamos que tomes medidas para garantizar que todas las cuentas de usuario sean cuentas administradas. |
Inhabilita la recuperación de cuentas para administradores avanzados | La recuperación automática de la cuenta de administrador avanzado está desactivada de forma predeterminada para todos los clientes nuevos (es posible que los clientes existentes tengan esta configuración activada). Desactivar esta configuración ayuda a mitigar el riesgo de que un teléfono vulnerado, un correo electrónico vulnerado o un ataque de ingeniería social puedan permitir que un atacante obtenga privilegios de administrador avanzado en tu entorno. Planificar un proceso interno para que un administrador avanzado se comunique con otro administrador avanzado de tu organización si perdió el acceso a su cuenta y asegurarte de que todos los administradores avanzados estén familiarizados con el proceso para la recuperación con ayuda del equipo de asistencia. |
Aplica y supervisa los requisitos de contraseña para los usuarios | En la mayoría de los casos, las contraseñas de los usuarios se administran a través de tu proveedor de identidad externo, pero las cuentas de administrador avanzado omiten el SSO y deben usar una contraseña para acceder a Cloud Identity. Inhabilita la reutilización de contraseñas y supervisa la seguridad de las contraseñas de cualquier usuario que use una contraseña para acceder a Cloud Identity, en especial, las cuentas de administrador avanzado. |
Establece políticas para toda la organización a fin de usar grupos | De forma predeterminada, las cuentas de usuario externas se pueden agregar a los grupos en Cloud Identity. Te recomendamos establecer una configuración de uso compartido para que los propietarios de grupos no puedan agregar miembros externos. Ten en cuenta que esta restricción no se aplica a la cuenta de administrador avanzado ni a otros administradores delegados con permisos de administrador de Grupos. Debido a que la federación de tu proveedor de identidad se ejecuta con privilegios de administrador, la configuración de uso compartido de grupos no se aplica a esta sincronización de grupo. Te recomendamos que revises los controles en el proveedor de identidad y el mecanismo de sincronización para asegurarte de que los miembros que no son de dominio se agreguen a grupos o que apliques restricciones de grupo. |
¿Qué sigue?
- Lee sobre la estructura de la organización (siguiente documento de esta serie).
Estructura de la organización
El nodo raíz para administrar recursos en Google Cloud es la organización. La organización de Google Cloud proporciona una jerarquía de recursos que proporciona una estructura de propiedad para los recursos y puntos de conexión para las políticas de la organización y los controles de acceso. La jerarquía de recursos consta de carpetas, proyectos y recursos, y define la estructura y el uso de los servicios de Google Cloud dentro de una organización.
Los recursos que se encuentran más abajo en la jerarquía heredan las políticas, como las políticas de permiso de IAM y las políticas de la organización. Todos los permisos de acceso se rechazan de forma predeterminada, hasta que apliques políticas de permisos directamente a un recurso o este herede las políticas de permisos de un nivel superior en la jerarquía de recursos.
En el siguiente diagrama, se muestran las carpetas y los proyectos que implementa el plano.
En las siguientes secciones, se describen las carpetas y los proyectos del diagrama.
Carpetas
El plano usa carpetas para agrupar proyectos según su entorno. Esta agrupación lógica se usa para aplicar parámetros de configuración como políticas de permiso y políticas de la organización a nivel de carpeta y, luego, todos los recursos dentro de la carpeta heredan las políticas. En la siguiente tabla, se describen las carpetas que forman parte del plano.
Carpeta | Descripción |
---|---|
bootstrap |
Contiene los proyectos que se usan para implementar componentes básicos. |
common |
Contiene proyectos con recursos que se comparten en todos los entornos. |
production |
Contiene proyectos con recursos de producción. |
nonproduction |
Contiene una copia del entorno de producción para que puedas probar las cargas de trabajo antes de ascenderlas a producción. |
development |
Contiene los recursos de la nube que se usan para el desarrollo. |
networking |
Contiene los recursos de red que comparten todos los entornos. |
Proyectos
El plano usa proyectos para agrupar recursos individuales según su funcionalidad y los límites previstos para el control de acceso. En la siguiente tabla, se describen los proyectos que se incluyen en el plano.
Carpeta | Proyecto | Descripción |
---|---|---|
bootstrap |
prj-b-cicd |
Contiene la canalización de implementación que se usa para compilar los componentes básicos de la organización. Para obtener más información, consulta la metodología de implementación. |
prj-b-seed |
Contiene el estado de Terraform de tu infraestructura y la cuenta de servicio de Terraform necesaria para ejecutar la canalización. Para obtener más información, consulta la metodología de implementación. | |
common |
prj-c-secrets |
Contiene secretos a nivel de organización. Para obtener más información, consulta Almacena credenciales de aplicaciones con Secret Manager. |
prj-c-logging |
Contiene las fuentes de registro agregadas para los registros de auditoría. Si deseas obtener más información, consulta Registro centralizado para seguridad y auditoría. | |
prj-c-scc |
Contiene recursos para ayudar a configurar las alertas de Security Command Center y otra supervisión de seguridad personalizada. Para obtener más información, consulta supervisión de amenazas con Security Command Center. | |
prj-c-billing-export |
Contiene un conjunto de datos de BigQuery con las exportaciones de facturación de la organización. Para obtener más información, consulta Asigna costos entre los centros de costos internos. | |
prj-c-infra-pipeline |
Contiene una canalización de infraestructura para implementar recursos como VMs y bases de datos que usarán las cargas de trabajo. Para obtener más información, consulta capas de canalización. | |
prj-c-kms |
Contiene claves de encriptación a nivel de la organización. Para obtener más información, consulta Administra claves de encriptación. | |
networking |
prj-net-{env}-shared-base |
Contiene el proyecto host para una red de VPC compartida en las cargas de trabajo que no requieren Controles del servicio de VPC. Para obtener más información, consulta la topología de red. |
prj-net-{env}-shared-restricted |
Contiene el proyecto host para una red de VPC compartida en las cargas de trabajo que requieren Controles del servicio de VPC. Para obtener más información, consulta la topología de red. | |
prj-net-interconnect |
Contiene las conexiones de Cloud Interconnect que proporcionan conectividad entre tu entorno local yGoogle Cloud. Para obtener más información, consulta Conectividad híbrida. | |
prj-net-dns-hub |
Contiene recursos para un punto central de comunicación entre el sistema DNS local y Cloud DNS. Para obtener más información, consulta Configuración de DNS centralizada. | |
prj-{env}-secrets |
Contiene secretos a nivel de carpeta. Para obtener más información, consulta Almacena y audita las credenciales de la aplicación con Secret Manager. | |
prj-{env}-kms |
Contiene claves de encriptación a nivel de carpeta. Para obtener más información, consulta Administra claves de encriptación. | |
proyectos de aplicación | Contiene varios proyectos en los que creas recursos para aplicaciones. Para obtener más información, consulta los patrones de implementación de proyectos y las capas de canalización. |
Administración de la propiedad de los recursos
Te recomendamos que apliques etiquetas a tus proyectos de forma coherente para facilitar la administración de costos y la administración de costos. En la siguiente tabla, se describen las etiquetas del proyecto que se agregan a cada proyecto para la administración en el plano.
Etiqueta | Descripción |
---|---|
application |
El nombre legible por humanos de la aplicación o la carga de trabajo asociada con el proyecto. |
businesscode |
Un código corto que describe qué unidad de negocios es propietaria del proyecto. El código shared se usa para los proyectos comunes que no están vinculados de forma explícita a una unidad de negocios. |
billingcode |
Un código que se usa para proporcionar información de devolución de cargos. |
primarycontact |
El nombre de usuario del contacto principal que es responsable del proyecto. Debido a que las etiquetas de proyecto no pueden incluir caracteres especiales como el signo et (@), se establece en el nombre de usuario sin el sufijo @example.com. |
secondarycontact |
El nombre de usuario del contacto secundario que es responsable del proyecto. Debido a que las etiquetas de proyecto no pueden incluir caracteres especiales como @, configura solo el nombre de usuario sin el sufijo @example.com. |
environment |
Un valor que identifica el tipo de entorno, como bootstrap , common , production , non-production,development o network. |
envcode |
Un valor que identifica el tipo de entorno, abreviado como b , c , p , n , d o net . |
vpc |
Es el ID de la red de VPC que se espera que use este proyecto. |
En ocasiones, es posible que Google envíe notificaciones importantes, como suspensiones de cuentas o actualizaciones de las condiciones de los productos. El modelo usa Contactos esenciales para enviar esas notificaciones a los grupos que configuras durante la implementación. Los contactos esenciales se configuran en el nodo de la organización y son heredados por todos los proyectos de la organización. Te recomendamos revisar estos grupos y asegurarte de que los correos electrónicos se supervisen de manera confiable.
Los contactos esenciales se usan para un propósito diferente a los campos primarycontact
y secondarycontact
que se configuran en las etiquetas del proyecto. Los contactos en las etiquetas de proyecto están destinados a la administración interna. Por ejemplo, si identificas recursos que no cumplen con las políticas en un proyecto de carga de trabajo y necesitas comunicarte con los propietarios, puedes usar el campo primarycontact
para encontrar a la persona o el equipo responsable de esa carga de trabajo.
¿Qué sigue?
- Lee sobre las herramientas de redes (siguiente documento de esta serie).
Redes
Las herramientas de redes son necesarias para que los recursos se comuniquen dentro de tu organización de Google Cloud y entre tu entorno de nube y el entorno local. En esta sección, se describe la estructura en el plano de las redes de VPC, el espacio de direcciones IP, el DNS, las políticas de firewall y la conectividad al entorno local.
Topología de la red
El repositorio de planos proporciona las siguientes opciones para la topología de red:
- Usa redes de VPC compartidas independientes para cada entorno, sin tráfico de red permitido directamente entre los entornos.
- Usa un modelo de concentrador y radio que agregue una red de concentrador para conectar cada entorno en Google Cloud, con el tráfico de red entre entornos controlado por un dispositivo virtual de red (NVA).
Elige la topología de red de VPC compartida doble cuando no quieras conectividad de red directa entre entornos. Elige la topología de red de concentrador y radio cuando desees permitir la conectividad de red entre entornos que se filtran por un NVA, como cuando usas las herramientas existentes que requieren una ruta de red directa a cada servidor de tu entorno.
Ambas topologías usan una VPC compartida como una construcción de red principal porque la VPC compartida permite una separación clara de las responsabilidades. Los administradores de red administran los recursos de red en un proyecto host centralizado y los equipos de carga de trabajo implementan sus propios recursos de aplicación y consumen los recursos de red en proyectos de servicio vinculados al proyecto host.
Ambas topologías incluyen una versión base y una restringida de cada red de VPC. La red de VPC base se usa para recursos que contienen datos no sensibles y la red de VPC restringida se usa para recursos con datos sensibles que requieren Controles del servicio de VPC. Para obtener más información sobre la implementación de los controles del servicio de VPC, consulta Protege tus recursos con los controles del servicio de VPC.
Topología de red de VPC compartida doble
Si necesitas aislamiento de red entre tus redes de desarrollo, no producción y producción en Google Cloud, te recomendamos la topología de red de VPC compartida doble. En esta topología, se usan redes de VPC compartidas independientes para cada entorno, cada uno con una división adicional entre una red de VPC compartida base y una red de VPC compartida restringida.
En el siguiente diagrama, se muestra la topología de red de VPC compartida doble.
En el diagrama, se describen estos conceptos clave de la topología de VPC compartida doble:
- Cada entorno (producción, no producción y desarrollo) tiene una red de VPC compartida para la red base y una red de VPC compartida para la red restringida. En este diagrama, solo se muestra el entorno de producción, pero el mismo patrón se repite para cada entorno.
- Cada red de VPC compartida tiene dos subredes, cada una de las cuales se encuentra en una región diferente.
- La conectividad con recursos locales se habilita a través de cuatro adjuntos de VLAN a la instancia de interconexión dedicada para cada red de VPC compartida, mediante cuatro servicios de Cloud Router (dos en cada región para redundancia). Para obtener más información, consulta Conectividad híbrida entre el entorno local y Google Cloud.
De forma predeterminada, esta topología no permite que el tráfico de red fluya directamente entre entornos. Si necesitas que el tráfico de red fluya directamente entre los entornos, debes tomar medidas adicionales para permitir esta ruta de red. Por ejemplo, puedes configurar extremos de Private Service Connect para exponer un servicio de una red de VPC a otra. Como alternativa, puedes configurar tu red local para permitir que el tráfico fluya de un entorno deGoogle Cloud al entorno local y, luego, a otro entorno de Google Cloud .
Topología de red de concentrador y radio
Si implementas recursos en Google Cloud que requieren una ruta de red directa a los recursos en varios entornos, te recomendamos la topología de red de concentrador y radio.
La topología de concentrador y radio usa varios de los conceptos que forman parte de la topología de VPC compartida doble, pero modifica la topología para agregar una red de concentrador. El siguiente diagrama muestra la topología de concentrador y radio.
El diagrama describe estos conceptos clave de la topología de red de concentrador y radio:
- Este modelo agrega una red central y cada una de las redes de desarrollo, no producción y producción (radios) se conecta a la red central mediante el intercambio de tráfico entre redes de VPC. Como alternativa, si anticipas que excederás el límite de la cuota, puedes usar una puerta de enlace de VPN con alta disponibilidad en su lugar.
- La conectividad a las redes locales solo se permite a través de la red central. Todas las redes de radio pueden comunicarse con recursos compartidos en la red de concentrador y usar esta ruta de acceso para conectarse a redes locales.
- Las redes de concentrador incluyen un NVA para cada región, que se implementa de forma redundante detrás de las instancias del balanceador de cargas de red interno. Este NVA actúa como la puerta de enlace para permitir o denegar la comunicación del tráfico entre redes de radio.
- La red central también aloja herramientas que requieren conectividad a todas las demás redes. Por ejemplo, puedes implementar herramientas en las instancias de VM para la administración de configuración en el entorno común.
- El modelo de concentrador y radio se duplica para una versión base y una versión restringida de cada red.
Para habilitar el tráfico de radio a radio, el plano implementa NVA en la red de VPC compartida de concentrador que actúan como puertas de enlace entre redes. Estas rutas se intercambian desde las redes de VPC del concentrador al radio a través del intercambio de rutas personalizadas. En esta situación, la conectividad entre los radios se debe enrutar a través del NVA porque el intercambio de tráfico entre redes de VPC no es transitivo y, por lo tanto, las redes de VPC de radio no pueden intercambiar datos de forma directa. Debes configurar los dispositivos virtuales para permitir el tráfico de forma selectiva entre los radios.
Patrones de implementación de proyectos
Cuando creas proyectos nuevos para las cargas de trabajo, debes decidir cómo se conectan los recursos de este proyecto a tu red existente. En la siguiente tabla, se describen los patrones para implementar proyectos que se usan en el plano.
Patrón | Descripción | Ejemplo de uso |
---|---|---|
Proyectos base compartidos | Estos proyectos se configuran como proyectos de servicio para un proyecto host de VPC compartida de base. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
|
example_base_shared_vpc_project.tf |
Proyectos restringidos compartidos | Estos proyectos se configuran como proyectos de servicio para un proyecto host de VPC compartida restringido. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
|
example_restricted_shared_vpc_project.tf |
Proyectos flotantes | Los proyectos flotantes no están conectados a otras redes de VPC en tu topología. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
Es posible que tengas una situación en la que desees mantener la red de VPC de un proyecto flotante separada de la topología de red principal de VPC, pero también quieras exponer una cantidad limitada de extremos entre redes. En este caso, publica servicios mediante Private Service Connect para compartir el acceso a la red a un extremo individual entre redes de VPC sin exponer toda la red. |
example_floating_project.tf |
Proyectos de intercambio de tráfico | Los proyectos de intercambio de tráfico crean sus propias redes de VPC e intercambian tráfico con otras redes de VPC en tu topología. Usa este patrón cuando los recursos de tu proyecto tengan los siguientes criterios:
Si creas proyectos de intercambio de tráfico, es tu responsabilidad asignar rangos de direcciones IP sin conflictos y planificar la cuota del grupo de intercambio de tráfico. |
example_peering_project.tf |
Asignación de direcciones IP
En esta sección, se presenta cómo la arquitectura del plano asigna rangos de direcciones IP. Es posible que debas cambiar los rangos específicos de direcciones IP que se usan en función de la disponibilidad de la dirección IP en tu entorno híbrido existente.
En la siguiente tabla, se proporciona un desglose del espacio de direcciones IP que se asignó para el plano. El entorno de concentrador solo se aplica en la topología de concentrador y radio.
Objetivo | Tipo de VPC | Región | Entorno de concentrador | Entorno de desarrollo | Entorno que no es de producción | Entorno de producción |
---|---|---|---|---|---|---|
Rangos de subredes principales | Capas | Región 1 | 10.0.0.0/18 | 10.0.64.0/18 | 10.0.128.0/18 | 10.0.192.0/18 |
Región 2 | 10.1.0.0/18 | 10.1.64.0/18 | 10.1.128.0/18 | 10.1.192.0/18 | ||
No asignado | 10.{2-7}.0.0/18 | 10.{2-7}.64.0/18 | 10.{2-7}.128.0/18 | 10.{2-7}.192.0/18 | ||
Restringido | Región 1 | 10.8.0.0/18 | 10.8.64.0/18 | 10.8.128.0/18 | 10.8.192.0/18 | |
Región 2 | 10.9.0.0/18 | 10.9.64.0/18 | 10.9.128.0/18 | 10.9.192.0/18 | ||
No asignado | 10.{10-15}.0.0/18 | 10.{10-15}.64.0/18 | 10.{10-15}.128.0/18 | 10.{10-15}.192.0/18 | ||
Acceso privado a servicios | Capas | Global | 10.16.0.0/21 | 10.16.8.0/21 | 10.16.16.0/21 | 10.16.24.0/21 |
Restringido | Global | 10.16.32.0/21 | 10.16.40.0/21 | 10.16.48.0/21 | 10.16.56.0/21 | |
Extremos de Private Service Connect | Capas | Global | 10.17.0.1/32 | 10.17.0.2/32 | 10.17.0.3/32 | 10.17.0.4/32 |
Restringido | Global | 10.17.0.5/32 | 10.17.0.6/32 | 10.17.0.7/32 | 10.17.0.8/32 | |
Subredes de solo proxy | Capas | Región 1 | 10.18.0.0/23 | 10.18.2.0/23 | 10.18.4.0/23 | 10.18.6.0/23 |
Región 2 | 10.19.0.0/23 | 10.19.2.0/23 | 10.19.4.0/23 | 10.19.6.0/23 | ||
No asignado | 10.{20-25}.0.0/23 | 10.{20-25}.2.0/23 | 10.{20-25}.4.0/23 | 10.{20-25}.6.0/23 | ||
Restringido | Región 1 | 10.26.0.0/23 | 10.26.2.0/23 | 10.26.4.0/23 | 10.26.6.0/23 | |
Región 2 | 10.27.0.0/23 | 10.27.2.0/23 | 10.27.4.0/23 | 10.27.6.0/23 | ||
No asignado | 10.{28-33}.0.0/23 | 10.{28-33}.2.0/23 | 10.{28-33}.4.0/23 | 10.{28-33}.6.0/23 | ||
Rangos de subred secundarios | Capas | Región 1 | 100.64.0.0/18 | 100.64.64.0/18 | 100.64.128.0/18 | 100.64.192.0/18 |
Región 2 | 100.65.0.0/18 | 100.65.64.0/18 | 100.65.128.0/18 | 100.65.192.0/18 | ||
No asignado | 100.{66-71}.0.0/18 | 100.{66-71}.64.0/18 | 100.{66-71}.128.0/18 | 100.{66-71}.192.0/18 | ||
Restringido | Región 1 | 100.72.0.0/18 | 100.72.64.0/18 | 100.72.128.0/18 | 100.72.192.0/18 | |
Región 2 | 100.73.0.0/18 | 100.73.64.0/18 | 100.73.128.0/18 | 100.73.192.0/18 | ||
No asignado | 100.{74-79}.0.0/18 | 100.{74-79}.64.0/18 | 100.{74-79}.128.0/18 | 100.{74-79}.192.0/18 |
En la tabla anterior, se muestran estos conceptos para asignar rangos de direcciones IP:
- La asignación de una dirección IP se subdivide en rangos para cada combinación de VPC compartida base, VPC compartida restringida, región y entorno.
- Algunos recursos son globales y no requieren subdivisiones para cada región.
- De forma predeterminada, para los recursos regionales, el plano se implementa en dos regiones. Además, hay rangos de direcciones IP sin usar para que puedas expandir las seis regiones adicionales.
- La red de concentrador solo se usa en la topología de red de concentrador y radio, mientras que los entornos de desarrollo, de no producción y de producción se usan en ambas topologías de red.
En la siguiente tabla, se presenta cómo se usa cada tipo de rango de direcciones IP.
Objetivo | Descripción |
---|---|
Rangos de subredes principales | Los recursos que implementas en tu red de VPC, como las instancias de máquina virtual, usan direcciones IP internas de estos rangos. |
Acceso privado a servicios | Algunos Google Cloud servicios, como Cloud SQL, requieren que asignes previamente un rango de subred para el acceso privado a servicios. El plano reserva un rango /21 a nivel global para cada una de las redes de VPC compartidas para asignar direcciones IP a los servicios que requieren acceso privado a servicios. Cuando crees un servicio que dependa del acceso privado a servicios, deberás asignar una subred /24 regional desde el rango reservado /21. |
Private Service Connect | El plano aprovisiona cada red de VPC con un extremo de Private Service Connect para comunicarse con las APIs de Google Cloud. Este extremo permite que tus recursos en la red de VPC lleguen a las APIs de Google Cloud sin depender del tráfico saliente a Internet o a los rangos de Internet anunciados de forma pública. |
Balanceadores de cargas basados en proxy | Algunos tipos de balanceadores de cargas de aplicaciones requieren que asignes previamente subredes de solo proxy. Aunque el plano no implementa balanceadores de cargas de aplicaciones que requieren este rango, la asignación de rangos por adelantado ayuda a reducir la fricción para las cargas de trabajo cuando deben solicitar un rango de subred nuevo para habilitar ciertos recursos del balanceador de cargas. |
Rangos de subred secundarios | Algunos casos de uso, como las cargas de trabajo basadas en contenedores, requieren rangos secundarios. El plano asigna rangos del espacio de direcciones IP RFC 6598 para rangos secundarios. |
Configuración de DNS centralizada
Para la resolución de DNS entre Google Cloud y entornos locales, te recomendamos que uses un enfoque híbrido con dos sistemas DNS confiables. En este enfoque, Cloud DNS controla la resolución de DNS autorizada para tu entorno deGoogle Cloud y tus servidores DNS locales existentes manejan la resolución de DNS autorizada para los recursos locales. Tu entorno local y el entorno de Google Cloud realizan búsquedas de DNS entre entornos a través de solicitudes de reenvío.
En el siguiente diagrama, se muestra la topología de DNS en las múltiples redes de VPC que se usan en el plano.
En el diagrama, se describen los siguientes componentes del diseño de DNS que implementa el plano:
- El proyecto del concentrador de DNS en la carpeta común es el punto central del intercambio de DNS entre el entorno local y el entorno de Google Cloud. El reenvío de DNS usa las mismas instancias de interconexión dedicada y Cloud Routers que ya están configurados en tu topología de red.
- En la topología de VPC compartida doble, el concentrador de DNS usa la red de VPC compartida de producción base.
- En la topología de concentrador y radio, el concentrador de DNS usa la red de VPC compartida del concentrador base.
- Los servidores de cada red de VPC compartida pueden resolver los registros DNS de otras redes de VPC compartida a través del reenvío de DNS, que se configura entre Cloud DNS en cada proyecto host de VPC compartida y el concentrador de DNS.
- Los servidores locales pueden resolver los registros DNS en los entornos de Google Cloud mediante las políticas de servidor DNS que permiten consultas desde servidores locales. El plano configura una política de servidor entrante en el concentrador de DNS para asignar direcciones IP, y los servidores DNS locales reenvían solicitudes a estas direcciones. Todas las solicitudes de DNS a Google Cloud llegan primero al concentrador de DNS, que luego resuelve los registros de los pares DNS.
- Los servidores de Google Cloud pueden resolver los registros DNS en el entorno local mediante las zonas de reenvío que consultan los servidores locales. Todas las solicitudes de DNS al entorno local se originan en el concentrador de DNS. La fuente de la solicitud de DNS es 35.199.192.0/19.
Políticas de firewall
Google Cloud tiene varios tipos de políticas de firewall. Las políticas de firewall jerárquicas se aplican a nivel de organización o carpeta a fin de heredar las reglas de políticas de firewall de manera coherente en todos los recursos de la jerarquía. Además, puedes configurar políticas de firewall de red para cada red de VPC. El plano combina estas políticas de firewall para aplicar opciones de configuración comunes en todos los entornos mediante políticas de firewall jerárquicas y aplicar opciones de configuración más específicas en cada red de VPC individual mediante políticas de firewall de red.
El plano no usa reglas de firewall de VPC heredadas. Recomendamos usar solo políticas de firewall y evitar el uso mixto de reglas de firewall de VPC heredadas.
Políticas jerárquicas de firewall
El plano define una sola política de firewall jerárquica y adjunta la política a cada una de las carpetas de producción, no producción, desarrollo, arranque y común. Esta política de firewall jerárquica contiene las reglas que se deben aplicar de manera amplia en todos los entornos y delega la evaluación de reglas más detalladas a la política de firewall de red para cada entorno individual.
En la siguiente tabla, se describen las reglas de políticas de firewall jerárquicas que implementa el plano.
Descripción de la regla | Dirección del tráfico | Filtro (rango IPv4) | Protocolos y puertos | Acción |
---|---|---|---|---|
Delega la evaluación del tráfico entrante de RFC 1918 a niveles inferiores en la jerarquía. | Ingress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
Delega la evaluación del tráfico saliente a RFC 1918 a niveles inferiores en la jerarquía. | Egress |
192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12 |
all |
Go to next |
IAP para la redirección de TCP | Ingress |
35.235.240.0/20 |
tcp:22,3389 |
Allow |
Activación de Windows Server | Egress |
35.190.247.13/32 |
tcp:1688 |
Allow |
Verificaciones de estado para Cloud Load Balancing | Ingress |
130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22 |
tcp:80,443 |
Allow |
Políticas de firewall de red
El modelo configura una política de firewall de red para cada red. Cada política de firewall de red comienza con un conjunto mínimo de reglas que permiten el acceso a los servicios de Google Cloud y rechazan la salida a todas las demás direcciones IP.
En el modelo de concentrador y radio, las políticas de firewall de red contienen reglas adicionales para permitir la comunicación entre los radios. La política de firewall de red permite el tráfico saliente de un radio a un concentrador o a otro radio, y permite el tráfico entrante desde el NVA en la red del concentrador.
En la siguiente tabla, se describen las reglas en la política de firewall de red global implementada para cada red de VPC en el plano.
Descripción de la regla | Dirección del tráfico | Filtro | Protocolos y puertos |
---|---|---|---|
Permitir el tráfico de salida a las APIs de Google Cloud. | Egress |
El extremo de Private Service Connect que se configura para cada red individual. Consulta Acceso privado a las APIs de Google. | tcp:443 |
Deniega el tráfico saliente que no coincida con otras reglas. | Egress |
todos | all |
Permite el tráfico saliente de un radio a otro (solo para modelo de concentrador y radio). |
Egress |
La suma de todas las direcciones IP que se usaron en la topología de concentrador y radio. El tráfico que sale de una VPC de radio se enruta primero al NVA en la red central. | all |
Permitir el tráfico entrante a un radio desde el NVA en la red central (solo para el modelo de concentrador y radio). |
Ingress |
El tráfico que se origina en los NVA de la red central. | all |
Cuando implementas el plano por primera vez, una instancia de VM en una red de VPC puede comunicarse con los servicios de Google Cloud , pero no con otros recursos de la infraestructura en la misma red de VPC. Para permitir que las instancias de VM se comuniquen, debes agregar reglas adicionales a tu política de firewall de red y etiquetas que permitan que las instancias de VM se comuniquen de forma explícita. Las etiquetas se agregan a las instancias de VM y el tráfico se evalúa en función de esas etiquetas. Además, las etiquetas tienen controles de IAM para que puedas definirlas de forma centralizada y delegar su uso a otros equipos.
En el siguiente diagrama, se muestra un ejemplo de cómo agregar etiquetas personalizadas y reglas de políticas de firewall de red para permitir que las cargas de trabajo se comuniquen dentro de una red de VPC.
En el diagrama, se muestran los siguientes conceptos de este ejemplo:
- La política de firewall de red contiene la regla 1 que rechaza el tráfico saliente de todas las fuentes en la prioridad 65530.
- La política de firewall de red contiene la regla 2 que permite el tráfico entrante de las instancias con la etiqueta
service=frontend
a las instancias con la etiquetaservice=backend
en la prioridad 999. - La VM instance-2 puede recibir tráfico de instance-1 porque el tráfico coincide con las etiquetas permitidas por la regla 2. La regla 2 coincide antes de que se evalúe la regla 1, según el valor de prioridad.
- La VM instance-3 no recibe tráfico. La única regla de política de firewall que coincide con este tráfico es la regla 1, por lo que se rechaza el tráfico saliente de instance-1.
Acceso privado a las APIs de Google Cloud
Para permitir que los recursos de tus redes de VPC o entornos locales lleguen a los servicios deGoogle Cloud , recomendamos la conectividad privada en lugar del tráfico de Internet saliente a extremos de APIs públicas. El modelo configura el Acceso privado a Google en cada subred y crea extremos internos con Private Service Connect para comunicarse con los servicios de Google Cloud . En conjunto, estos controles permiten una ruta privada a los servicios de Google Cloud , sin depender del tráfico de salida de Internet ni de los rangos de Internet anunciados de forma pública.
El modelo configura extremos de Private Service Connect con paquetes de API para diferenciar a qué servicios se puede acceder en qué red. La red base usa el paquete all-apis
y puede acceder a cualquier servicio de Google, y la red restringida usa el paquete vpcsc
, que permite el acceso a un conjunto limitado de servicios que admiten Controles del servicio de VPC.
Para el acceso desde hosts que se encuentran en un entorno local, te recomendamos que uses una convención de FQDN personalizado para cada extremo, como se describe en la siguiente tabla. El plano usa un extremo único de Private Service Connect para cada red de VPC, configurado a fin de acceder a un conjunto diferente de paquetes de API. Por lo tanto, debes considerar cómo enrutar el tráfico de servicio desde el entorno local a la red de VPC con el extremo de API correcto y, si usas Controles del servicio de VPC, asegúrate de que el tráfico a los servicios de Google Cloud llegue al extremo dentro del perímetro previsto. Configura los controles locales para DNS, firewalls y routers a fin de permitir el acceso a estos extremos, y configura hosts locales para usar el extremo adecuado. Para obtener más información, consulta Accede a las APIs de Google a través de extremos.
En la siguiente tabla, se describen los extremos de Private Service Connect que se crearon para cada red.
VPC | Entorno | Paquete de API | Dirección IP del extremo de Private Service Connect | FQDN personalizado | ||||
---|---|---|---|---|---|---|---|---|
Capas | Common | all-apis |
10.17.0.1/32 | c.private.googleapis.com |
||||
Desarrollo | all-apis |
10.17.0.2/32 | d.private.googleapis.com |
|||||
No producción | all-apis |
10.17.0.3/32 | n.private.googleapis.com |
|||||
Producción | all-apis |
10.17.0.4/32 | p.private.googleapis.com |
|||||
Restringido | Common | vpcsc |
10.17.0.5/32 | c.restricted.googleapis.com |
||||
Desarrollo | vpcsc |
10.17.0.6/32 | d.restricted.googleapis.com |
|||||
No producción | vpcsc |
10.17.0.7/32 | n.restricted.googleapis.com |
|||||
Producción | vpcsc |
10.17.0.8/32 | p.restricted.googleapis.com |
Para garantizar que el tráfico de los servicios de Google Cloud tenga una búsqueda de DNS en el extremo correcto, el modelo configura zonas de DNS privadas para cada red de VPC. En la siguiente tabla, se describen estas zonas de DNS privadas.
Nombre de zona privada | Nombre de DNS | Tipo de registro | Datos |
---|---|---|---|
googleapis.com. |
*.googleapis.com. |
CNAME |
private.googleapis.com. (para redes base) o restricted.googleapis.com. (para redes restringidas) |
private.googleapis.com (para redes base) o restricted.googleapis.com (para redes restringidas) |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. | |
gcr.io. |
*.gcr.io |
CNAME |
gcr.io. |
gcr.io |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. | |
pkg.dev. |
*.pkg.dev. |
CNAME |
pkg.dev. |
pkg.dev. |
A |
La dirección IP del extremo de Private Service Connect para esa red de VPC. |
El plano tiene configuraciones adicionales para garantizar que estos extremos de Private Service Connect se usen de manera coherente. Cada red de VPC compartida también aplica lo siguiente:
- Una regla de política de firewall de red que permite el tráfico saliente de todas las fuentes a la dirección IP del extremo de Private Service Connect en TCP:443.
- Una regla de política de firewall de red que rechaza el tráfico saliente a 0.0.0.0/0, que incluye los dominios predeterminados que se usan para acceder a los servicios de Google Cloud .
Conectividad a Internet
El plano no permite el tráfico de entrada ni de salida entre sus redes de VPC e Internet. Para las cargas de trabajo que requieren conectividad a Internet, debes tomar medidas adicionales para diseñar las rutas de acceso necesarias.
Para las cargas de trabajo que requieren tráfico de salida a Internet, te recomendamos que administres el tráfico de salida a través de Cloud NAT para permitir el tráfico de salida sin conexiones entrantes no solicitadas, o a través de Secure Web Proxy para obtener un control más detallado y permitir el tráfico de salida solo a servicios web de confianza.
Para las cargas de trabajo que requieren tráfico entrante de Internet, te recomendamos que diseñes tu carga de trabajo con Cloud Load Balancing y Google Cloud Armor para aprovechar las protecciones contra DDoS y WAF.
No recomendamos que diseñes cargas de trabajo que permitan la conectividad directa entre Internet y una VM mediante una dirección IP externa en la VM.
Conectividad híbrida entre un entorno local y Google Cloud
Para establecer la conectividad entre el entorno local yGoogle Cloud, te recomendamos que uses la interconexión dedicada para maximizar la seguridad y la confiabilidad. Una conexión de interconexión dedicada es un vínculo directo entre tu red local yGoogle Cloud.
En el siguiente diagrama, se presenta la conectividad híbrida entre el entorno local y una red de nube privada virtual de Google.
En el diagrama, se describen los siguientes componentes del patrón para la disponibilidad del 99.99% para la interconexión dedicada:
- Cuatro conexiones de interconexión dedicada, con dos conexiones en una área metropolitana (metro) y dos conexiones en otra área. Dentro de cada área metropolitana, hay dos zonas distintas dentro de la instalación de colocación.
- Las conexiones se dividen en dos pares, y cada par se conecta a un centro de datos local independiente.
- Los adjuntos de VLAN se usan para conectar cada instancia de interconexión dedicada a los Cloud Routers que están conectados a la topología de VPC compartida.
- Cada red de VPC compartida tiene cuatro Cloud Routers, dos en cada región, con el modo de enrutamiento dinámico configurado en
global
para que cada Cloud Router pueda anunciar todas las subredes, independientemente de la región.
Con el enrutamiento dinámico global, Cloud Router anuncia rutas a todas las subredes que se encuentran en la red de VPC. Cloud Router anuncia rutas a subredes remotas (ubicadas fuera de la región de Cloud Router) con una propiedad más baja en comparación con las subredes locales (ubicadas en la región de Cloud Router). De manera opcional, puedes cambiar las prioridades y los prefijos anunciados cuando configuras la sesión de BGP para un Cloud Router.
El tráfico de Google Cloud a un entorno local usa el Cloud Router más cercano a los recursos en la nube. Dentro de una sola región, varias rutas a redes locales tienen el mismo valor de discriminante de varias salidas (MED) y Google Cloud usan el enrutamiento de ruta de acceso múltiple de igual costo (ECMP) para distribuir el tráfico saliente entre todas las rutas posibles.
Cambios en la configuración local
Para configurar la conectividad entre el entorno local yGoogle Cloud, debes configurar cambios adicionales en tu entorno local. El código de Terraform en el plano configura automáticamente los recursos deGoogle Cloud , pero no modifica ninguno de tus recursos de red locales.
El modelo habilita automáticamente algunos de los componentes de la conectividad híbrida de tu entorno local aGoogle Cloud , incluidos los siguientes:
- En Cloud DNS, se configura el reenvío de DNS entre todas las redes de VPC compartidas a un solo concentrador, como se describe en Configuración de DNS. Una política del servidor de Cloud DNS se configura con direcciones IP de reenvío entrantes.
- Cloud Router se configura a fin de exportar rutas para todas las subredes y rutas personalizadas para las direcciones IP que usan los extremos de Private Service Connect.
Para habilitar la conectividad híbrida, debes seguir estos pasos adicionales:
- Solicita una conexión de interconexión dedicada.
- Configura routers y firewalls locales para permitir el tráfico de ida al espacio de direcciones IP internas definido en Asignación de espacio de direcciones IP.
- Configura tus servidores DNS locales para reenviar las búsquedas de DNS vinculadas aGoogle Cloud a las direcciones IP de reenvío entrantes que ya está configurada por el modelo.
- Configura los servidores DNS, los firewalls y los routers locales para aceptar consultas de DNS desde la zona de reenvío de Cloud DNS (35.199.192.0/19).
- Configura los servidores DNS locales para que respondan a las consultas de hosts locales a los servicios de Google Cloud con las direcciones IP definidas en el acceso privado a las APIs de Cloud.
- Para la encriptación en tránsito a través de la conexión de interconexión dedicada, configura MACsec para Cloud Interconnect o configura VPN con alta disponibilidad mediante Cloud Interconnect para la encriptación de IPsec.
Si deseas obtener más información, consulta Acceso privado a Google para hosts locales.
¿Qué sigue?
- Lee sobre los controles de detección (siguiente documento de esta serie).
Controles de detección
Las funciones de detección y supervisión de amenazas se proporcionan mediante una combinación de controles de seguridad integrados de Security Command Center y soluciones personalizadas que te permiten detectar eventos de seguridad y responder a ellos.
Un registro centralizado para la seguridad y la auditoría
El plano configura las capacidades de registro para realizar un seguimiento y analizar los cambios en tus recursos de Google Cloud con registros que se agregan a un solo proyecto.
En el siguiente diagrama, se muestra cómo el plano agrega registros de varias fuentes en varios proyectos a un receptor de registros centralizado.
En el diagrama, se describe lo siguiente:
- Los receptores de registros se configuran en el nodo de la organización para agregar registros de todos los proyectos en la jerarquía de recursos.
- Varios receptores de registros están configurados para enviar registros que coincidan con un filtro a diferentes destinos para el almacenamiento y las estadísticas.
- El proyecto
prj-c-logging
contiene todos los recursos para el almacenamiento y las estadísticas de registros. - De manera opcional, puedes configurar herramientas adicionales para exportar registros a una SIEM.
El plano usa diferentes fuentes de registro e incluye estos registros en el filtro del receptor de registros para que los registros se puedan exportar a un destino centralizado. En la siguiente tabla, se describen las fuentes del archivo de registro.
Fuente del archivo de registro |
Descripción |
---|---|
No puedes configurar, inhabilitar o excluir registros de auditoría de actividad del administrador. |
|
No puedes configurar, inhabilitar o excluir registros de auditoría de eventos del sistema. |
|
No puedes configurar o inhabilitar los registros de auditoría de política denegada, pero puedes excluirlos de forma opcional con filtros de exclusión. |
|
De forma predeterminada, el plano no habilita los registros de acceso a los datos, ya que el volumen y el costo de estos registros puede ser alto. Para determinar si debes habilitar los registros de acceso a los datos, evalúa dónde tus cargas de trabajo controlan los datos sensibles y considera si tienes que habilitar los registros de acceso a los datos para cada servicio y entorno que trabaja con datos sensibles. |
|
El plano habilita los registros de flujo de VPC para cada subred. El plano configura el muestreo de registros para muestrear el 50% de los registros a fin de reducir el costo. Si creas subredes adicionales, debes asegurarte de que los registros de flujo de VPC estén habilitados para cada subred. |
|
El plano habilita el registro de las reglas de firewall para cada regla de política de firewall. Si creas reglas de políticas de firewall adicionales para las cargas de trabajo, debes asegurarte de que el registro de reglas de firewall esté habilitado para cada regla nueva. |
|
El plano habilita los registros de Cloud DNS para las zonas administradas. Si creas zonas administradas adicionales, debes habilitar esos registros de DNS. |
|
Requiere un paso de habilitación único que no esté automatizado por el plano. Para obtener más información, consulta Cómo compartir datos con los servicios deGoogle Cloud . |
|
Requiere un paso de habilitación único que no esté automatizado por el plano. Para obtener más información, consulta Habilita la Transparencia de acceso. |
En la siguiente tabla, se describen los receptores de registros y cómo se usan con destinos compatibles en el plano.
Receptor |
Destino |
Objetivo |
---|---|---|
|
Registros enrutados a buckets de Cloud Logging con Log Analytics y un conjunto de datos de BigQuery vinculado habilitados |
Analiza los registros de forma activa. Ejecuta investigaciones ad hoc con el Explorador de registros en la consola o escribe consultas, informes y vistas de SQL con el conjunto de datos de BigQuery vinculado. |
|
Almacena registros a largo plazo para fines de cumplimiento, auditoría y seguimiento de incidentes. De forma opcional, si tienes requisitos de cumplimiento para la retención de datos obligatoria, te recomendamos que configures el bloqueo del bucket. |
|
|
Exporta registros a una plataforma externa, como tu SIEM existente. Esto requiere trabajo adicional para la integración en tu SIEM, como los siguientes mecanismos:
|
Para obtener orientación sobre cómo habilitar tipos de registro adicionales y escribir filtros del receptor de registros, consulta la herramienta de alcance de registros.
Supervisión de amenazas con Security Command Center
Te recomendamos que actives Security Command Center Premium para que tu organización detecte automáticamente amenazas, vulnerabilidades y configuraciones incorrectas en tus Google Cloud recursos. Security Command Center crea resultados de seguridad a partir de varias fuentes, incluidas las siguientes:
- Security Health Analytics: Detecta vulnerabilidades comunes y parámetros de configuración incorrectos en los recursos de Google Cloud.
- Exposición de la ruta de ataque: muestra una ruta simulada de cómo un atacante podría aprovechar tus recursos de alto valor, según las vulnerabilidades y configuraciones incorrectas que se detectan mediante Otras fuentes de Security Command Center.
- Event Threat Detection: Aplica la lógica de detección y la inteligencia de amenazas propia en tus registros para identificar amenazas casi en tiempo real.
- Container Threat Detection: detecta ataques comunes del entorno de ejecución del contenedor.
- Virtual Machine Threat Detection: detecta aplicaciones potencialmente maliciosas que se ejecutan en máquinas virtuales.
- Web Security Scanner: Analiza las vulnerabilidades de OWASP Top Ten en tus aplicaciones web en Compute Engine, App Engine o Google Kubernetes Engine.
Para obtener más información sobre las vulnerabilidades y amenazas que aborda Security Command Center, consulta Fuentes de Security Command Center.
Debes activar Security Command Center después de implementar el plano. Si deseas obtener instrucciones, consulta Activa Security Command Center para una organización.
Después de activar Security Command Center, te recomendamos exportar los resultados que produce Security Command Center a tus herramientas o procesos existentes para clasificar y responder a las amenazas. El plano crea el proyecto prj-c-scc
con un tema de Pub/Sub que se usará para esta integración. Según tus herramientas existentes, usa uno de los siguientes métodos para exportar los resultados:
- Si usas la consola para administrar los resultados de seguridad directamente en Security Command Center, configura roles a nivel de carpeta y a nivel de proyecto para Security Command Center para permitir que los equipos vean y administren los resultados de seguridad solo para los proyectos de los que son responsables.
Si usas Google SecOps como tu SIEM, ingresa Google Cloud datos a Google SecOps.
Si usas una herramienta SIEM o SOAR con integraciones en Security Command Center, comparte datos con Cortex XSOAR, Elastic Stack, ServiceNow, Splunk o QRadar.
Si usas una herramienta externa que puede transferir resultados de Pub/Sub, configura exportaciones continuas a Pub/Sub y configura tus herramientas existentes para transferir resultados desde el tema de Pub/Sub.
Solución personalizada para el análisis de registros automatizado
Es posible que tengas requisitos para crear alertas de eventos de seguridad basados en consultas personalizadas en los registros. Las consultas personalizadas pueden ayudar a complementar las capacidades de tu SIEM mediante el análisis de registros en Google Cloud y la exportación solo de los eventos que requieren investigación, en especial si no tienes la capacidad para exportar todos los registros en la nube a tu SIEM.
El plano ayuda a habilitar este análisis de registros mediante la configuración de una fuente centralizada de registros que puedes consultar mediante un conjunto de datos de BigQuery vinculado. Para automatizar esta capacidad, debes implementar la muestra de código en bq-log-alerting
y extender las capacidades básicas. El código de muestra te permite consultar con regularidad una fuente de registro y enviar un resultado personalizado a Security Command Center.
En el siguiente diagrama, se presenta el flujo de alto nivel del análisis de registros automatizado.
En el diagrama, se muestran los siguientes conceptos del análisis de registros automatizado:
- Los registros de varias fuentes se agregan a un bucket de registros centralizado con estadísticas de registros y un conjunto de datos de BigQuery vinculado.
- Las vistas de BigQuery están configuradas para consultar registros del evento de seguridad que deseas supervisar.
- Cloud Scheduler envía un evento a un tema de Pub/Sub cada 15 minutos y activa funciones de Cloud Run.
- Las funciones de Cloud Run consultan las vistas para los eventos nuevos. Si encuentra eventos, los envía a Security Command Center como resultados personalizados.
- Security Command Center publica notificaciones sobre los resultados nuevos en otro tema de Pub/Sub.
- Una herramienta externa como una SIEM se suscribe al tema de Pub/Sub para transferir resultados nuevos.
La muestra tiene varios casos de uso para consultar comportamientos potencialmente sospechosos. Los ejemplos incluyen el acceso de una lista de administradores avanzados o de otras cuentas con muchos privilegios que especifiques, cambios en la configuración de registro o cambios en las rutas de red. Puedes extender los casos de uso si escribes vistas de consulta nuevas para tus requisitos. Escribe tus propias consultas o consulta estadísticas de registros de seguridad para obtener una biblioteca de consultas en SQL que te ayude a analizar los registros de Google Cloud .
Solución personalizada para responder a los cambios de recursos
Para responder a eventos en tiempo real, te recomendamos usar Cloud Asset Inventory para supervisar los cambios de los elementos. En esta solución personalizada, se configura un feed de recursos para activar notificaciones en Pub/Sub sobre cambios en los recursos en tiempo real y, luego, las funciones de Cloud Run ejecutan código personalizado para aplicar tu propia lógica empresarial según se debe permitir el cambio.
El plano tiene un ejemplo de esta solución de administración personalizada que supervisa los cambios de IAM que agregan roles altamente sensibles, como administrador de la organización, propietario y editor. En el siguiente diagrama, se describe esta solución.
En el diagrama anterior, se muestran estos conceptos:
- Se realizan cambios en una política de permisos.
- El feed de Cloud Asset Inventory envía una notificación en tiempo real sobre el cambio de política de permisos a Pub/Sub.
- Pub/Sub activa una función.
- Las funciones de Cloud Run ejecutan código personalizado para aplicar tu política. La función de ejemplo tiene lógica para evaluar si el cambio agregó los roles de administrador, propietario o editor de la organización a una política de permisos. Si es así, la función crea un resultado de seguridad personalizado y lo envía a Security Command Center.
- De manera opcional, puedes usar este modelo para automatizar los esfuerzos de solución. Escribe una lógica empresarial adicional en las funciones de Cloud Run para realizar acciones de forma automática sobre el resultado, como revertir la política de permisos a su estado anterior.
Además, puedes ampliar la infraestructura y la lógica que usa esta solución de muestra a fin de agregar respuestas personalizadas a otros eventos que sean importantes para tu empresa.
¿Qué sigue?
- Lee sobre los controles preventivos (siguiente documento de esta serie).
Controles preventivos para configuraciones de recursos aceptables
Te recomendamos que definas las restricciones de políticas que aplican opciones de configuración de recursos aceptables y evitan las configuraciones riesgosas. El modelo usa una combinación de restricciones de políticas de la organización y validación de infraestructura como código (IaC) en tu canalización. Estos controles evitan la creación de recursos que no cumplan con los lineamientos de tus políticas. Aplicar estos controles al comienzo del diseño y la compilación de tus cargas de trabajo te ayuda a evitar el trabajo de corrección más adelante.
Restricciones de las políticas de la organización
El servicio de políticas de la organización aplica restricciones para garantizar que ciertas opciones de configuración de recursos no se puedan crear en tu organización de Google Cloud , incluso por alguien que tenga un rol de IAM con privilegios suficientes.
El modelo aplica políticas en el nodo de organización para que todas las carpetas y proyectos de la organización hereden estos controles. Este conjunto de políticas está diseñado para evitar ciertas configuraciones de alto riesgo, como exponer una VM a la Internet pública u otorgar acceso público a los buckets de almacenamiento, a menos que permitas una excepción a la política de forma deliberada.
En la siguiente tabla, se presentan las restricciones de las políticas de la organización que se implementan en el modelo:
Restricción de las políticas de la organización | Descripción |
---|---|
| La virtualización anidada en las VMs de Compute Engine puede evadir la supervisión y otras herramientas de seguridad para las VMs si están mal configuradas. Esta restricción evita la creación de virtualización anidada. |
| Los roles de IAM como |
| Las subredes IPv6 externas pueden estar expuestas a un acceso no autorizado a Internet si están mal configuradas. Esta restricción evita la creación de subredes IPv6 externas. |
| El comportamiento predeterminado de la configuración de claves SSH en metadatos puede permitir el acceso remoto no autorizado a las VMs, si se exponen claves. Esta restricción aplica el uso del Acceso al SO en lugar de las claves SSH basadas en metadatos. |
|
El reenvío de protocolos de VM para direcciones IP externas puede generar una salida no autorizada a Internet si el reenvío está mal configurado. Esta restricción permite el reenvío de protocolos de VM solo para direcciones internas. |
|
Si borras un proyecto host de VPC compartida, es posible que se produzcan interrupciones en todos los proyectos de servicio que usan recursos de red. Esta restricción evita la eliminación accidental o maliciosa de los proyectos host de VPC compartida, ya que impide la eliminación de la retención del proyecto en estos proyectos. |
|
No se recomienda usar una configuración heredada para el DNS interno global (para todo el proyecto), ya que reduce la disponibilidad del servicio. Esta restricción evita el uso del parámetro de configuración heredado. |
| En cada proyecto nuevo que habilite la API de Compute Engine, se crean una red de VPC predeterminada y reglas de firewall de VPC predeterminadas demasiado permisivas. Esta restricción omite la creación de la red predeterminada y las reglas de firewall de VPC predeterminadas. |
| De forma predeterminada, se crea una VM con una dirección IPv4 externa que puede generar acceso no autorizado a Internet. Esta restricción configura una lista de entidades permitidas vacía de direcciones IP externas que la VM puede usar y rechaza todas las demás. |
|
De forma predeterminada, los Contactos esenciales se pueden configurar para enviar notificaciones sobre tu dominio a cualquier otro dominio. Esta restricción aplica que solo se pueden configurar como destinatarios de Contactos esenciales las direcciones de correo electrónico de los dominios aprobados. |
| De forma predeterminada, se pueden otorgar políticas de permiso a cualquier Cuenta de Google, incluidas las cuentas no administradas y las que pertenecen a organizaciones externas. Esta restricción garantiza que las políticas de autorización de tu organización solo se puedan otorgar a las cuentas administradas de tu propio dominio. De forma opcional, puedes permitir dominios adicionales. |
|
De forma predeterminada, a las cuentas de servicio predeterminadas se les otorgan roles demasiado permisivos de forma automática. Esta restricción evita que los roles de IAM automáticos se otorguen a las cuentas de servicio predeterminadas. |
|
Las claves de cuenta de servicio son una credencial persistente de alto riesgo y, en la mayoría de los casos, se puede usar una alternativa más segura que las claves de cuenta de servicio. Esta restricción impide la creación de claves de cuenta de servicio. |
|
Subir material de claves de cuenta de servicio puede aumentar el riesgo si se expone. Esta restricción evita la carga de claves de cuenta de servicio. |
|
Las instancias de Cloud SQL pueden exponerse al acceso a Internet no autenticado si las instancias están configuradas para usar redes autorizadas sin un proxy de autenticación de Cloud SQL. Esta política evita la configuración de redes autorizadas para el acceso a la base de datos y fuerza el uso del proxy de autenticación de Cloud SQL. |
| Las instancias de Cloud SQL pueden exponerse al acceso a Internet no autenticado si las instancias se crean con direcciones IP públicas. Esta restricción evita las direcciones IP públicas en las instancias de Cloud SQL. |
| De forma predeterminada, se puede acceder a los objetos en Cloud Storage a través de las Listas de control de acceso (LCA) heredadas, en lugar de IAM, lo que puede provocar controles de acceso incoherentes y una exposición accidental si se configura de forma incorrecta. El acceso a la LCA heredada no se ve afectado por la restricción |
|
Los buckets de Cloud Storage pueden estar expuestos al acceso a Internet no autenticado si están mal configurados. Esta restricción evita las LCA y los permisos de IAM que otorgan acceso a |
Estas políticas son un punto de partida que recomendamos para la mayoría de los clientes y
la mayoría de las situaciones, pero es posible que debas modificar las restricciones de las políticas de la organización para
adaptarlas a ciertos tipos de cargas de trabajo. Por ejemplo, storage.publicAccessPrevention
bloquea una carga de trabajo que usa un bucket de Cloud Storage como backend para Cloud CDN a fin de alojar recursos públicos, o iam.allowedPolicyMemberDomains
bloquea una app de Cloud Run pública que no requiere autenticación. En estos casos, modifica la
política de la organización a nivel de la carpeta o el proyecto para permitir una excepción limitada.
También puedes agregar restricciones de forma condicional a la política de la organización si defines una etiqueta que otorgue una excepción o aplicación para la política y, luego, aplicas la etiqueta a proyectos y carpetas.
Para conocer otras restricciones, consulta las restricciones disponibles y las restricciones personalizadas.
Validación previa a la implementación de la infraestructura como código
El plano usa un enfoque de GitOps para administrar la infraestructura, lo que significa que todos los cambios en la infraestructura se implementan a través de la infraestructura como código (IaC) con control de versión, y se pueden validar antes de la implementación.
Las políticas aplicadas en el modelo definen las configuraciones de recursos aceptables que puede implementar tu canalización. Si el código que se envía a tu repositorio de GitHub no supera las verificaciones de políticas, no se implementarán recursos.
Si deseas obtener información sobre cómo se usan las canalizaciones y cómo se aplican los controles a través de la automatización de CI/CD, consulta la metodología de implementación.
¿Qué sigue?
- Lee sobre la metodología de implementación (siguiente documento de esta serie)
Metodología de implementación
Te recomendamos que uses una infraestructura declarativa para implementar la base de manera coherente y controlable. Este enfoque ayuda a habilitar la administración coherente mediante la aplicación de controles de política sobre las configuraciones aceptables de recursos en las canalizaciones. El plano se implementa mediante un flujo de GitOps, con Terraform que se usa para definir la infraestructura como código (IaC), un repositorio de Git para el control de versiones y la aprobación de código, y Cloud Build para la automatización de CI/CD en la canalización de implementación. Para obtener una introducción a este concepto, consulta Administra la infraestructura como código con Terraform, Cloud Build y GitOps.
En las siguientes secciones, se describe cómo se usa la canalización de implementación para administrar recursos en tu organización.
Capas de la canalización
Para separar los equipos y la pila tecnológica responsables de administrar diferentes capas de tu entorno, recomendamos un modelo que use diferentes canalizaciones y arquetipos diferentes que sean responsables de cada capa de la pila.
En el siguiente diagrama, se presenta nuestro modelo recomendado para separar una canalización de base, una canalización de infraestructura y una canalización de aplicación.
En el diagrama, se presentan las capas de canalización en este modelo:
- La canalización base implementa los recursos base que se usan en toda la plataforma. Recomendamos que un solo equipo central sea responsable de administrar los recursos básicos que consumen varias unidades de negocios y cargas de trabajo.
- La canalización de infraestructura implementa proyectos y una infraestructura que usan las cargas de trabajo, como las instancias de VM o bases de datos. El plano configura una canalización de infraestructura independiente para cada unidad de negocios, o es posible que prefieras una sola canalización de infraestructura que usen varios equipos.
- La canalización de aplicación implementa los artefactos para cada carga de trabajo, como imágenes o contenedores. Es posible que tengas muchos equipos de aplicaciones diferentes con canalizaciones de aplicaciones individuales.
Las siguientes secciones presentan el uso de cada capa de la canalización.
La canalización base
La canalización de base implementa los recursos de base. También configura la canalización de infraestructura que se usa para implementar la infraestructura que usan las cargas de trabajo.
Para crear la canalización de base, primero debes clonar o bifurcar la base de datos de Terraform a tu propio repositorio de Git. Sigue los pasos del archivo README de 0-bootstrap
para configurar tu carpeta de arranque y tus recursos.
Etapa | Descripción |
---|---|
Inicia una organización de Google Cloud . En este paso, también se configura una canalización de CI/CD para el código del plano en etapas posteriores.
|
Después de crear la canalización de base en la etapa 0-bootstrap
, las siguientes etapas implementan recursos en la canalización de base. Revisa las instrucciones de README para cada etapa y, luego, implementa cada etapa de forma secuencial.
Etapa | Descripción |
---|---|
Configura carpetas compartidas de nivel superior, proyectos para servicios compartidos, registros a nivel de la organización y configuración de seguridad de referencia a través de políticas de la organización. |
|
Configura entornos de desarrollo, de no producción y de producción dentro de la organización de Google Cloud que creaste. |
|
o |
Configura las VPC compartidas en la topología elegida y en los recursos de red asociados. |
Canalización de infraestructura
La canalización de infraestructura implementa los proyectos y la infraestructura (por ejemplo, las instancias y bases de datos de VMs) que usan las cargas de trabajo. La canalización base implementa varias canalizaciones de infraestructura. Esta separación entre la canalización de base y la canalización de infraestructura permite una separación entre los recursos de toda la plataforma y los recursos específicos de la carga de trabajo.
En el siguiente diagrama, se describe cómo el plano configura varias canalizaciones de infraestructura destinadas a usarse por equipos separados.
En el diagrama, se describen los siguientes conceptos clave:
- Cada canalización de infraestructura se usa para administrar los recursos de infraestructura sin importar los recursos base.
- Cada unidad de negocios tiene su propia canalización de infraestructura, administrada en un proyecto dedicado en la carpeta
common
. - Cada una de las canalizaciones de infraestructura tiene una cuenta de servicio con permiso para implementar recursos solo en los proyectos asociados con esa unidad de negocios. Esta estrategia crea una separación de obligaciones entre las cuentas de servicio con privilegios usadas para la canalización de base y las que usa cada canalización de infraestructura.
Este enfoque con varias canalizaciones de infraestructura se recomienda cuando tienes varias entidades dentro de la organización que tienen las habilidades y el acierto para administrar su infraestructura por separado, en especial si tienen requisitos diferentes, como los tipos de políticas de validación de canalizaciones que quieren aplicar. Como alternativa, puedes tener una sola canalización de infraestructura administrada por un solo equipo con políticas de validación coherentes.
En terraform-example-foundation, la etapa 4 configura una canalización de infraestructura y la etapa 5 muestra un ejemplo del uso de esa canalización para implementar recursos de infraestructura.
Etapa | Descripción |
---|---|
Configura una estructura de carpetas, proyectos y una canalización de infraestructura. |
|
|
Implementa proyectos de carga de trabajo con una instancia de Compute Engine mediante la canalización de infraestructura como ejemplo. |
Canalización de aplicación
La canalización de aplicación es responsable de implementar artefactos de aplicación para cada carga de trabajo individual, como imágenes o contenedores de Kubernetes que ejecutan la lógica empresarial de la aplicación. Estos artefactos se implementan en los recursos de infraestructura que implementa tu canalización de infraestructura.
El plano de base empresarial configura la canalización de base y la canalización de infraestructura, pero no implementa una canalización de aplicación. Para ver un ejemplo de canalización de aplicación, consulta el plano de aplicación empresarial.
Automatiza tu canalización con Cloud Build
El plano usa Cloud Build para automatizar los procesos de CI/CD. En la siguiente tabla, se describen los controles que se compilan en la canalización de base y en la canalización de infraestructura que implementa el repositorio terraform-example-foundation. Si desarrollas tus propias canalizaciones con otras herramientas de automatización de CI/CD, te recomendamos que apliques controles similares.
Control | Descripción |
---|---|
Separa las configuraciones de compilación para validar el código antes de implementar |
El plano usa dos archivos de configuración de compilación de Cloud Build para toda la canalización, y cada repositorio asociado con una etapa tiene dos activadores de Cloud Build que son asociados con esos archivos de configuración de compilación. Cuando el código se envía a una rama de repositorio, los archivos de configuración de compilación se activan para ejecutar |
Verificaciones de políticas de Terraform | El plano incluye un conjunto de restricciones del Agente de políticas abiertas que aplica la validación de políticas en Google Cloud CLI. Estas restricciones definen las configuraciones de recursos aceptables que puede implementar tu canalización. Si una compilación no cumple con la política en la primera configuración de compilación, la segunda configuración no implementa ningún recurso. Las políticas aplicadas en el plano se bifurcan desde |
Principio de privilegio mínimo | La canalización base tiene una cuenta de servicio diferente para cada etapa con una política de permisos que otorga solo los roles de IAM mínimos para esa etapa. Cada activador de Cloud Build se ejecuta como la cuenta de servicio específica para esa etapa. El uso de cuentas diferentes ayuda a mitigar el riesgo de que modificar un repositorio pueda afectar los recursos que administra otro repositorio. Para comprender los roles específicos de IAM que se aplican a cada cuenta de servicio, consulta el código de Terraform |
Grupos privados de Cloud Build | El plano usa grupos privados de Cloud Build. Los grupos privados te permiten aplicar controles adicionales de forma opcional, como restringir el acceso a repositorios públicos o ejecutar Cloud Build dentro de un perímetro de Controles del servicio de VPC. |
Compiladores personalizados de Cloud Build | El plano crea su propio compilador personalizado para ejecutar Terraform. Para obtener más información, consulta |
Aprobación de la implementación | De manera opcional, puedes agregar una etapa de aprobación manual a Cloud Build. Esta aprobación agrega un punto de control adicional después de que se activa la compilación, pero antes de que se ejecute para que un usuario con privilegios pueda aprobar la compilación de forma manual. |
Estrategia de ramificación
Recomendamos una estrategia de rama persistente para enviar el código a tu sistema de Git y, luego, implementar recursos a través de la canalización de base. En el siguiente diagrama, se describe la estrategia de la rama persistente.
En el diagrama, se describen tres ramas persistentes en Git (desarrollo, no producción y producción) que reflejan los entornos deGoogle Cloud correspondientes. También hay varias ramas de características efímeras que no corresponden a los recursos implementados en los entornos deGoogle Cloud .
Recomendamos que apliques un proceso de solicitud de extracción (PR) a tu sistema de Git para que cualquier código que se combine con una rama persistente tenga una PR aprobada.
Para desarrollar código con esta estrategia de rama persistente, sigue estos pasos de alto nivel:
- Cuando desarrolles funciones nuevas o trabajes en una corrección de errores, crea una rama nueva basada en la rama de desarrollo. Usa una convención de nombres para tu rama que incluya el tipo de cambio, un número de ticket o algún otro identificador, y una descripción legible por humanos, como
feature/123456-org-policies
. - Cuando completes el trabajo en la rama de funciones, abre una PR que se oriente a la rama de desarrollo.
- Cuando envías la PR, esta activa la canalización de base para realizar
terraform plan
yterraform validate
para almacenar en etapa intermedia y verificar los cambios. - Después de validar los cambios en el código, combina la función o la corrección de errores en la rama de desarrollo.
- El proceso de combinación activa la canalización de base para ejecutar
terraform apply
para implementar los últimos cambios en la rama de desarrollo en el entorno de desarrollo. - Revisa los cambios en el entorno de desarrollo mediante revisiones manuales, pruebas funcionales o pruebas de extremo a extremo que sean relevantes para tu caso de uso. Luego, promueve los cambios en el entorno que no sea de producción. Para ello, abre una PR que se oriente a la rama de no producción y combina tus cambios.
- Para implementar recursos en el entorno de producción, repite el mismo proceso que en el paso 6: revisa y valida los recursos implementados, abre una PR para la rama de producción y combina.
¿Qué sigue?
- Lee sobre las prácticas recomendadas de operaciones (siguiente documento de esta serie).
Prácticas recomendadas para las operaciones
En esta sección, se presentan las operaciones que debes tener en cuenta a la hora de implementar y operar cargas de trabajo adicionales en tu entorno de Google Cloud . El objetivo de esta sección no es abarcar todas las operaciones de tu entorno de nube, sino presentar decisiones relacionadas con las recomendaciones arquitectónicas y los recursos que implementa el modelo.
Actualiza los recursos de la base
Aunque el modelo de diseño proporciona un punto de partida definido para tu ambiente de base, es posible que tus requisitos de base aumenten con el tiempo. Después de la implementación inicial, puedes ajustar la configuración o compilar nuevos servicios compartidos para que los consuman todas las cargas de trabajo.
Para modificar los recursos de la fundación, te recomendamos que realices todos los cambios a través de la canalización de la fundación. Revisa la estrategia de ramificación para obtener una introducción al flujo de escritura del código, su combinación y la activación de las canalizaciones de implementación.
Decide los atributos para los proyectos de cargas de trabajo nuevas
Cuando creas proyectos nuevos a través del módulo de fábrica de proyectos de la canalización de automatización, debes configurar varios atributos. Tu proceso para diseñar y crear proyectos para cargas de trabajo nuevas debe incluir decisiones sobre lo siguiente:
- Qué APIs de Google Cloud habilitar
- Qué VPC compartida usar o si crear una red de VPC nueva
- Qué roles de IAM crear para la
project-service-account
inicial que crea la canalización - Qué etiquetas de proyecto aplicar
- La carpeta en la que se implementa el proyecto
- Qué cuenta de facturación usar
- Si se debe agregar el proyecto a un perímetro de Controles de servicio de VPC
- Si deseas configurar un presupuesto y un límite de alerta de facturación para el proyecto
Para obtener una referencia completa de los atributos configurables de cada proyecto, consulta las variables de entrada de la fábrica de proyectos en la canalización de automatización.
Administra permisos a gran escala
Cuando implementes proyectos de cargas de trabajo sobre tu base, debes considerar cómo otorgarás acceso a los desarrolladores y consumidores previstos de esos proyectos. Recomendamos que agregues usuarios a un grupo administrado por tu proveedor de identidad existente, que sincronices los grupos con Cloud Identity y, luego, que apliques roles de IAM a los grupos. Ten siempre presente el principio de privilegio mínimo.
También te recomendamos que uses el recomendador de IAM para identificar las políticas de permisos que otorgan roles con privilegios excesivos. Diseña un proceso para revisar las recomendaciones de forma periódica o aplicarlas de forma automática en las canalizaciones de implementación.
Coordina los cambios entre el equipo de redes y el equipo de aplicaciones
En las topologías de red que implementa el modelo, se supone que tienes un equipo responsable de administrar los recursos de red y equipos independientes responsables de implementar los recursos de infraestructura de la carga de trabajo. A medida que los equipos de cargas de trabajo implementan la infraestructura, deben crear reglas de firewall para permitir las rutas de acceso previstas entre los componentes de su carga de trabajo, pero no tienen permiso para modificar las políticas de firewall de la red.
Planifica cómo los equipos trabajarán en conjunto para coordinar los cambios en los recursos de red centralizados que se necesitan para implementar aplicaciones. Por ejemplo, puedes diseñar un proceso en el que un equipo de cargas de trabajo solicite etiquetas para sus aplicaciones. Luego, el equipo de redes crea las etiquetas y agrega reglas a la política de firewall de red que permite que el tráfico fluya entre los recursos con las etiquetas y delega los roles de IAM para usar las etiquetas a Workload Team.
Optimiza tu entorno con la cartera de Active Assist
Además del recomendador de IAM, Google Cloud proporciona la cartera de servicios de Active Assist para hacer recomendaciones sobre cómo optimizar tu entorno. Por ejemplo, las estadísticas de firewall o el recomendador de proyectos sin actividad proporcionan recomendaciones prácticas que pueden ayudarte a reforzar tu postura de seguridad.
Diseña un proceso para revisar las recomendaciones de forma periódica o aplicarlas de forma automática en las canalizaciones de implementación. Decide qué recomendaciones debe administrar un equipo central y cuáles deben ser responsabilidades de los propietarios de las cargas de trabajo y aplica los roles de IAM para acceder a las recomendaciones según corresponda.
Otorga excepciones a las políticas de la organización
El modelo aplica un conjunto de restricciones de políticas de la organización que se recomiendan a la mayoría de los clientes en la mayoría de los casos, pero es posible que tengas casos de uso legítimos que requieran excepciones limitadas a las políticas de la organización que aplicas de forma general.
Por ejemplo, el modelo aplica la restricción iam.disableServiceAccountKeyCreation. Esta restricción es un control de seguridad importante porque una clave de cuenta de servicio filtrada puede tener un impacto negativo significativo y la mayoría de las situaciones deben usar alternativas más seguras para las claves de cuenta de servicio para autenticarse. Sin embargo, puede haber casos de uso que solo puedan autenticarse con una clave de cuenta de servicio, como un servidor local que requiere acceso a los servicios deGoogle Cloud y no puede usar la federación de Workload Identity. En esta situación, puedes permitir una excepción a la política, siempre que se apliquen controles de compensación adicionales, como las prácticas recomendadas para administrar claves de cuentas de servicio.
Por lo tanto, debes diseñar un proceso para que las cargas de trabajo soliciten una excepción a las políticas y debes asegurarte de que los encargados de tomar decisiones que son responsables de otorgar excepciones tengan el conocimiento técnico para validar el caso de uso y consultar sobre si se deben implementar controles adicionales para compensar. Cuando otorgues una excepción a una carga de trabajo, modifica la restricción de la política de la organización lo más específica posible. También puedes agregar restricciones de forma condicional a una política de la organización si defines una etiqueta que otorgue una excepción o aplicación para la política y, luego, aplicas la etiqueta a proyectos y carpetas.
Protege tus recursos con los Controles del servicio de VPC
El modelo ayuda a preparar tu entorno para los Controles del servicio de VPC, ya que separa las redes base y restringidas. Sin embargo, de forma predeterminada, el código de Terraform no habilita los Controles del servicio de VPC, ya que esta habilitación puede ser un proceso disruptivo.
Un perímetro niega el acceso a los servicios Google Cloud restringidos desde el tráfico que se origina fuera del perímetro, lo que incluye la consola, las estaciones de trabajo del desarrollador y la canalización de la base que se usa para implementar recursos. Si usas los Controles del servicio de VPC, debes diseñar excepciones al perímetro que permitan las rutas de acceso que deseas.
Un perímetro de Controles del servicio de VPC está diseñado para los controles de robo de datos entre tu Google Cloud organización y fuentes externas. El perímetro no está diseñado para reemplazar o duplicar las políticas de permiso para el control de acceso detallado a proyectos o recursos individuales. Cuando diseñas y creas un perímetro, te recomendamos usar un perímetro unificado común para reducir la sobrecarga de administración.
Si debes diseñar varios perímetros para controlar de forma detallada el tráfico de servicios dentro de tu Google Cloud organización, te recomendamos que definas con claridad las amenazas que aborda una estructura de perímetro más compleja y las rutas de acceso entre los perímetros que se necesitan para las operaciones previstas.
Para adoptar los Controles del servicio de VPC, evalúa lo siguiente:
- Cuáles de tus casos de uso requieren Controles del servicio de VPC.
Si los servicios Google Cloud requeridos admiten los Controles del servicio de VPC
Cómo configurar el acceso de emergencia para modificar el perímetro en caso de que interrumpa tus canalizaciones de automatización.
Cómo usar las prácticas recomendadas para habilitar los Controles del servicio de VPC para diseñar e implementar tu perímetro.
Una vez habilitado el perímetro, te recomendamos que diseñes un proceso para agregar de manera coherente proyectos nuevos al perímetro correcto y un proceso para diseñar excepciones cuando los desarrolladores tengan un caso de uso nuevo que tu configuración de perímetro actual rechace.
Cómo probar cambios en toda la organización en una organización independiente
Te recomendamos que nunca implementes cambios en producción sin realizar pruebas. En el caso de los recursos de la carga de trabajo, este enfoque se facilita con entornos separados para el desarrollo, la no producción y la producción. Sin embargo, algunos recursos de la organización no tienen entornos separados para facilitar las pruebas.
Para cambios a nivel de la organización o de otro tipo que puedan afectar los entornos de producción, como la configuración entre el proveedor de identidad y Cloud Identity, considera crear una organización distinta para fines de prueba.
Controla el acceso remoto a las máquinas virtuales
Debido a que recomendamos que implementes una infraestructura inmutable a través de la canalización de base, la canalización de infraestructura y la canalización de aplicación, también recomendamos que solo otorgues acceso directo a una máquina virtual a los desarrolladores a través de SSH o RDP para casos de uso limitados o excepcionales.
En situaciones que requieran acceso remoto, te recomendamos que administres el acceso de los usuarios con el Acceso al SO siempre que sea posible. En este enfoque, se usan servicios Google Cloud administrados para aplicar el control de acceso, la administración del ciclo de vida de las cuentas, la verificación en dos pasos y el registro de auditoría. Como alternativa, si debes permitir el acceso a través de claves SSH en metadatos o credenciales de RDP, es tu responsabilidad administrar el ciclo de vida de las credenciales y almacenar las credenciales de forma segura fuera de Google Cloud.
En cualquier caso, un usuario con acceso SSH o RDP a una VM puede ser un riesgo de escalamiento de privilegios, por lo que debes diseñar tu modelo de acceso teniendo esto en cuenta. El usuario puede ejecutar código en esa VM con los privilegios de la cuenta de servicio asociada o consultar el servidor de metadatos para ver el token de acceso que se usa para autenticar las solicitudes a la API. Este acceso puede ser una elevación de privilegios si no tenías la intención deliberada de que el usuario opere con los privilegios de la cuenta de servicio.
Planifica alertas de presupuesto para mitigar el exceso de gastos
El esquema implementa las prácticas recomendadas que se presentan en el Google Cloud framework de arquitectura: Optimización de costos para administrar los costos, incluidas las siguientes:
Usa una sola cuenta de facturación en todos los proyectos de la base empresarial.
Asigna a cada proyecto una etiqueta de metadatos
billingcode
que se use para asignar el costo entre los centros de costos.Configura presupuestos y límites de alertas.
Es tu responsabilidad planificar los presupuestos y configurar las alertas de facturación. El esquema crea alertas de presupuesto para los proyectos de carga de trabajo cuando el gasto previsto está en camino de alcanzar el 120% del presupuesto. Este enfoque permite que un equipo central identifique y mitigue incidentes de sobregasto significativo. Los aumentos significativos no esperados en el gasto sin una causa clara pueden ser un indicador de un incidente de seguridad y deben investigarse desde las perspectivas del control de costos y la seguridad.
Según tu caso de uso, puedes establecer un presupuesto basado en el costo de una carpeta de entorno completa o de todos los proyectos relacionados con un centro de costos determinado, en lugar de establecer presupuestos detallados para cada proyecto. También te recomendamos que delegues la configuración del presupuesto y las alertas a los propietarios de cargas de trabajo que podrían establecer un umbral de alerta más detallado para su supervisión diaria.
Si deseas obtener orientación para desarrollar capacidades de FinOps, incluida la previsión de presupuestos para cargas de trabajo, consulta Primeros pasos con FinOps en Google Cloud.
Asigna costos entre centros de costos internos
La consola te permite ver tus informes de facturación para ver y
prever los costos en varias dimensiones. Además de los informes precompilados, te recomendamos que exportes los datos de facturación a un conjunto de datos de BigQuery en el proyecto prj-c-billing-export
. Los registros de facturación exportados te permiten asignar el costo en dimensiones personalizadas, como tus centros de costos internos, en función de los metadatos de la etiqueta del proyecto, como billingcode
.
La siguiente consulta en SQL es una consulta de muestra para comprender los costos de todos los proyectos agrupados por la etiqueta billingcode
del proyecto.
#standardSQL
SELECT
(SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
service.description AS description,
SUM(cost) AS charges,
SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC
Para configurar esta exportación, consulta Cómo exportar datos de la Facturación de Cloud a BigQuery.
Si necesitas contabilidad interna o una devolución de cargos entre centros de costos, es tu responsabilidad incorporar los datos que se obtienen de esta consulta en tus procesos internos.
Transferir los resultados de los controles de detección a tu SIEM existente
Aunque los recursos de la base te ayudan a configurar destinos agregados para los registros de auditoría y los resultados de seguridad, es tu responsabilidad decidir cómo consumir y usar estos indicadores.
Si tienes un requisito para agregar registros en todos los entornos locales y en la nube a una SIEM existente, decide cómo transferir registros desde el proyecto prj-c-logging
y resultados de Security Command Center en tus herramientas y procesos existentes. Puedes crear una sola exportación para todos los registros y hallazgos si un solo equipo es responsable de supervisar la seguridad en todo tu entorno, o bien puedes crear varias exportaciones filtradas para el conjunto de registros y hallazgos necesarios para varios equipos con diferentes responsabilidades.
Como alternativa, si el volumen y el costo de los registros son prohibitivos, puedes evitar la duplicación reteniendo los registros y los hallazgos de Google Cloud solo enGoogle Cloud. En esta situación, asegúrate de que tus equipos existentes tengan el acceso y la capacitación adecuados para trabajar con registros y hallazgos directamente enGoogle Cloud.
- En el caso de los registros de auditoría, diseña vistas de registro para otorgar acceso a un subconjunto de registros en tu bucket de registros centralizado a equipos individuales, en lugar de duplicar los registros a varios buckets que aumentan costo de almacenamiento de los registros.
- En el caso de los resultados de seguridad, otorga roles a nivel de carpeta y de proyecto para Security Command Center para permitir que los equipos vean y administren los resultados de seguridad solo para los proyectos de los que son responsables, directamente en la consola.
Desarrollar continuamente tu biblioteca de controles
El plan comienza con un modelo de referencia de controles para detectar y evitar amenazas. Te recomendamos que revises estos controles y agregues controles adicionales según tus requisitos. En la siguiente tabla, se resumen los mecanismos para aplicar las políticas de administración y cómo extenderlas para tus requisitos adicionales:
Controles de políticas que aplica el modelo | Orientación para extender estos controles |
---|---|
Security Command Center detecta vulnerabilidades y amenazas de varias fuentes de seguridad. |
Define módulos personalizados para las estadísticas del estado de la seguridad y módulos personalizados para Event Threat Detection. |
El servicio de políticas de la organización aplica un conjunto recomendado de restricciones de políticas de la organización en los servicios deGoogle Cloud . |
Aplica restricciones adicionales de la lista prediseñada de restricciones disponibles o crea restricciones personalizadas. |
La política de Open Policy Agent (OPA) valida el código en la canalización de la base para configuraciones aceptables antes de la implementación. |
Desarrolla restricciones adicionales según los lineamientos de GoogleCloudPlatform/policy-library. |
Alertas sobre métricas basadas en registros y métricas de rendimiento configura métricas basadas en registros para alertar sobre cambios en las políticas de IAM y la configuración de algunos recursos sensibles. |
Diseña métricas basadas en registros y políticas de alertas adicionales para los eventos de registro que esperas que no ocurran en tu entorno. |
Una solución personalizada para el análisis automático de registros consulta con regularidad los registros de actividad sospechosa y crea hallazgos de Security Command Center. |
Escribe consultas adicionales para crear los resultados para los eventos de seguridad que deseas supervisar mediante las estadísticas del registro de seguridad como referencia. |
Una solución personalizada para responder a los cambios de los elementos crea hallazgos de Security Command Center y puede automatizar las acciones de solución. |
Crea feeds de Cloud Asset Inventory adicionales para supervisar los cambios en tipos de recursos específicos y escribir funciones de Cloud Run adicionales con lógica personalizada para responder a los incumplimientos de políticas. |
Estos controles pueden evolucionar a medida que cambian tus requisitos y madurez enGoogle Cloud .
Administra claves de encriptación con Cloud Key Management Service
Google Cloud proporciona encriptación en reposo predeterminada para todo el contenido del cliente, pero también proporciona Cloud Key Management Service (Cloud KMS) para proporcionarte control sobre las claves de encriptación para datos en reposo. Te recomendamos que evalúes si la encriptación predeterminada es suficiente o si tienes un requisito de cumplimiento que debes usar Cloud KMS para administrar las claves por tu cuenta. Para obtener más información, consulta Decide cómo cumplir con los requisitos de cumplimiento para la encriptación en reposo.
El modelo proporciona un proyecto prj-c-kms
en la carpeta común y un proyecto prj-{env}-kms
en cada carpeta de entorno para administrar las claves de encriptación de forma centralizada. Este enfoque permite que un equipo central audite y administre las claves de encriptación que usan los recursos en los proyectos de carga de trabajo para cumplir con los requisitos regulatorios y de cumplimiento.
Según tu modelo operativo, es posible que prefieras una sola instancia de proyecto centralizada de Cloud KMS bajo el control de un solo equipo, o bien que administres las claves de encriptación por separado en cada entorno o que prefieras varias instancias distribuidas para que la responsabilidad de las claves de encriptación se pueda delegar a los equipos adecuados. Modifica la muestra de código de Terraform según sea necesario para que se ajuste a tu modelo operativo.
De manera opcional, puedes aplicar políticas de organización de claves de encriptación administradas por el cliente (CMEK) para aplicar que ciertos tipos de recursos siempre requieran una clave CMEK y que solo las claves CMEK de una lista de proyectos de confianza estén permitidos.
Almacena y audita las credenciales de la aplicación con Secret Manager
Te recomendamos que nunca confirmes secretos sensibles (como claves de API, contraseñas y certificados privados) en repositorios de código fuente. En su lugar, confirma el secreto en Secret Manager y otorga el rol de IAM de Administrador y descriptor de acceso a secretos al usuario o la cuenta de servicio que necesita acceder al secreto. Te recomendamos que otorgues el rol de IAM a un secreto individual, no a todos los secretos del proyecto.
Cuando sea posible, debes generar secretos de producción automáticamente dentro de las canalizaciones de CI/CD y mantenerlos inaccesibles para los usuarios humanos, excepto en situaciones de emergencia. En esta situación, asegúrate de no otorgar roles de IAM para ver estos secretos a ningún usuario o grupo.
El modelo proporciona un solo proyecto prj-c-secrets
en la carpeta común y un proyecto prj-{env}-secrets
en cada carpeta de entorno para administrar los secretos de forma centralizada. Este enfoque permite que un equipo central audite y administre los secretos que usan las aplicaciones para cumplir con los requisitos regulatorios y de cumplimiento.
Según tu modelo operativo, es posible que prefieras una sola instancia centralizada de Secret Manager bajo el control de un solo equipo, o que prefieras administrar los secretos por separado en cada entorno, o que prefieras varias instancias distribuidas de Secret Manager para que cada equipo de carga de trabajo pueda administrar sus propios secretos. Modifica el código de Terraform según sea necesario para que se adapte a tu modelo operativo.
Planifica el acceso de emergencia a cuentas con muchos privilegios
Aunque recomendamos que los cambios en los recursos de la base se administren a través de la IaC controlada por versión que implementa la canalización de base, es posible que tengas situaciones excepcionales o de emergencia que requieran acceso con privilegios para modificar tu entorno directamente. Te recomendamos que planifiques cuentas de emergencia (a veces llamadas cuentas de llamada de emergencia o de emergencia) que tengan acceso de alto privilegio a tu entorno en caso de emergencia o cuando fallen los procesos de automatización.
En la siguiente tabla, se describen algunos ejemplos de los fines de las cuentas de emergencia.
Propósito de la anulación de emergencia | Descripción |
---|---|
Administrador avanzado | Acceso de emergencia al rol de administrador avanzado que se usa con Cloud Identity para, por ejemplo, solucionar problemas relacionados con la federación de identidades o la autenticación de varios factores (MFA). |
Administrador de la organización |
Acceso de emergencia al rol de administrador de la organización, que luego puede otorgar acceso a cualquier otro rol de IAM en la organización. |
Administrador de canalización de base | Acceso de emergencia para modificar los recursos de tu proyecto de CI/CD en Google Cloud y el repositorio de Git externo en caso de que falle la automatización de la canalización de la fundación. |
Operaciones o SRE |
Un equipo de operaciones o SRE necesita acceso con privilegios para responder a interrupciones o incidentes. Esto puede incluir tareas como reiniciar VMs o restablecer datos. |
Tu mecanismo para permitir el acceso con el sistema de cristal de seguridad depende de las herramientas y los procedimientos existentes que tengas implementados, pero algunos ejemplos de mecanismos incluyen los siguientes:
- Usa las herramientas existentes para la administración de accesos con privilegios para agregar de forma temporal a un usuario a un grupo predefinido con roles de IAM con muchos privilegios o usa las credenciales de una cuenta con muchos privilegios.
- Cuentas de aprovisionamiento previo destinadas solo para el uso del administrador. Por ejemplo, la desarrolladora Dana podría tener la identidad dana@example.com para el uso diario y admin-dana@example.com para el acceso de emergencia.
- Usa una aplicación como el acceso privilegiado justo a tiempo que permite a un desarrollador derivar a roles con más privilegios.
Independientemente del mecanismo que uses, considera cómo abordas de manera operativa las siguientes preguntas:
- ¿Cómo diseñas el alcance y el nivel de detalle del acceso de emergencia? Por ejemplo, puedes diseñar un mecanismo de emergencia diferente para diferentes unidades de negocios para asegurarte de que no puedan interrumpirse entre sí.
- ¿Cómo evita el abuso tu mecanismo? ¿Necesitas aprobaciones? Por ejemplo, es posible que tengas operaciones divididas en las que una persona tenga las credenciales y otra tenga el token de MFA.
- ¿Cómo se audita y alerta sobre el acceso de emergencia? Por ejemplo, puedes configurar un módulo personalizado de Detección de amenazas de eventos para crear un hallazgo de seguridad cuando se usa una cuenta de emergencia predefinida.
- ¿Cómo se quita el acceso al cristal de seguridad y se reanudan las operaciones normales después de que termina el incidente?
Para las tareas comunes de elevación de privilegios y reversión de cambios, recomendamos diseñar flujos de trabajo automatizados en los que un usuario pueda realizar la operación sin requerir elevación de privilegios para su identidad de usuario. Este enfoque puede ayudar a reducir los errores humanos y mejorar la seguridad.
Para los sistemas que requieren intervención periódica, automatizar la corrección podría ser la mejor solución. Google recomienda a los clientes que adopten un enfoque automático para realizar todos los cambios de producción con automatización, proxies seguros o flujos de trabajo de emergencia auditados. Google proporciona los libros de SRE para los clientes que desean adoptar el enfoque de SRE de Google.
¿Qué sigue?
- Lee Implementa el plano (siguiente documento de esta serie).
Implementa el plano
En esta sección, se describe el proceso que puedes usar para implementar el plano, sus convenciones de nombres y las alternativas a las recomendaciones del plano.
Revisión general
Para implementar tu propia base empresarial según las prácticas recomendadas y las recomendaciones de este plano, sigue las tareas de alto nivel que se resumen en esta sección. La implementación requiere una combinación de pasos de configuración que son requisitos previos, la implementación automatizada a través de terraform-example-foundation en GitHub y pasos adicionales que deben configurarse de forma manual después de que se complete la implementación inicial de la base.
Proceso | Pasos |
---|---|
Requisitos previos antes de implementar los recursos de la canalización de base |
Completa los siguientes pasos antes de implementar la canalización de base:
Para conectarte a un entorno local existente, prepara lo siguiente:
|
Pasos para implementar terraform-example-foundation desde GitHub |
Sigue las instrucciones de README para cada etapa para implementar terraform-example-foundation desde GitHub:
|
Pasos adicionales después de la implementación de IaC |
Después de implementar el código de Terraform, completa lo siguiente:
|
Controles administrativos adicionales para los clientes con cargas de trabajo sensibles
Google Cloud proporciona controles administrativos adicionales que pueden ayudarte con los requisitos de seguridad y cumplimiento. Sin embargo, algunos controles implican compensaciones adicionales de costo u operativas que podrían no ser adecuadas para cada cliente. Estos controles también requieren entradas personalizadas para tus requisitos específicos que no se pueden automatizar por completo en el plano con un valor predeterminado para todos los clientes.
En esta sección, se presentan los controles de seguridad que aplicas de forma centralizada a tu base. Esta sección no está diseñada para ser exhaustiva en todos los controles de seguridad que puedes aplicar a cargas de trabajo específicas. Para obtener más información sobre los productos y las soluciones de seguridad de Google, consulta el Centro de prácticas recomendadas de seguridad.Google Cloud
Evalúa si los siguientes controles son adecuados para tu base en función de los requisitos de cumplimiento, el apetito de riesgo y la sensibilidad de los datos.
Control | Descripción |
---|---|
Controles del servicio de VPC te permiten definir políticas de seguridad que evitan el acceso a los servicios administrados por Google fuera de un perímetro de confianza, bloquean el acceso a los datos desde ubicaciones no confiables y mitigan los riesgos de robo de datos. Sin embargo, los Controles del servicio de VPC pueden hacer que los servicios existentes se rompan hasta que definas excepciones para permitir patrones de acceso deseados. Evalúa si el valor de mitigar los riesgos de robo de datos justifica la mayor complejidad y la sobrecarga operativa de adoptar los Controles del servicio de VPC. El plano prepara redes restringidas y variables opcionales para configurar los Controles del servicio de VPC, pero el perímetro no está habilitado hasta que realices pasos adicionales para diseñarlo y habilitarlo. |
|
Es posible que tengas requisitos regulatorios que indiquen que los recursos en la nube solo se deben implementar en ubicaciones geográficas aprobadas. Esta restricción de política de la organización aplica que los recursos solo se pueden implementar en la lista de ubicaciones que definas. |
|
Assured Workloads proporciona controles de cumplimiento adicionales que te ayudan a cumplir con regímenes regulatorios específicos. El plano proporciona variables opcionales en la canalización de implementación para la habilitación. |
|
Es posible que debas registrar todo el acceso a ciertos datos o recursos sensibles. Evalúa dónde tus cargas de trabajo manejan datos sensibles que requieren registros de acceso a los datos y habilita los registros para cada servicio y entorno que trabaja con datos sensibles. |
|
La aprobación de acceso garantiza que la ingeniería y el servicio de atención al cliente de Cloud requieran tu aprobación explícita cada vez que necesiten acceder al contenido de clientes. Evalúa el proceso operativo necesario para revisar las solicitudes de aprobación de acceso para mitigar posibles demoras en la resolución de incidentes de asistencia. |
|
Key Access Justifications te permite controlar de manera programática si Google puede acceder a tus claves de encriptación, incluidas las operaciones automatizadas y la Atención al cliente para acceder al contenido de clientes. Evalúa el costo y la sobrecarga operativa asociada con Key Access Justifications, así como su dependencia en Cloud External Key Manager (Cloud EKM). |
|
Cloud Shell es un entorno de desarrollo en línea. Este shell está alojado en un servidor administrado por Google fuera de tu entorno y, por lo tanto, no está sujeto a los controles que puedes haber implementado en tus propias estaciones de trabajo para desarrolladores. Si deseas controlar estrictamente las estaciones de trabajo que un desarrollador puede usar para acceder a los recursos de la nube, inhabilita Cloud Shell. También puedes evaluar Cloud Workstations para obtener una opción de estación de trabajo configurable en tu propio entorno. |
|
Google Cloud te permite restringir el acceso a la consola de Google Cloud según los atributos de nivel de acceso, como la membresía del grupo, los rangos de direcciones IP de confianza y la verificación del dispositivo. Algunos atributos requieren una suscripción adicional a Chrome Enterprise Premium. Evalúa los patrones de acceso en los que confías para el acceso de los usuarios a aplicaciones basadas en la Web, como la consola, como parte de una implementación de confianza cero más grande. |
Convenciones de nombres
Te recomendamos que tengas una convención de nombres estandarizada para tus recursos deGoogle Cloud . En la siguiente tabla, se describen las convenciones recomendadas para los nombres de recursos en el plano.
Recurso | Convención de nombres |
---|---|
Carpeta |
Por ejemplo: |
ID del proyecto |
Por ejemplo: |
Red de VPC |
Por ejemplo: |
Subred |
Por ejemplo: |
Políticas de firewall |
Por ejemplo:
|
Cloud Router |
Por ejemplo: |
Conexión de Cloud Interconnect |
Por ejemplo: |
Adjunto de VLAN de Cloud Interconnect |
Por ejemplo: |
Grupo |
En el ejemplo anterior, Por ejemplo: |
Rol personalizado |
En el ejemplo anterior, Por ejemplo: |
Cuenta de servicio |
Aquí:
Por ejemplo: |
Bucket de almacenamiento |
Aquí:
Por ejemplo: |
Alternativas a las recomendaciones predeterminadas
Es posible que las prácticas recomendadas del plano no funcionen para todos los clientes. Puedes personalizar cualquiera de las recomendaciones para cumplir con tus requisitos específicos. En la siguiente tabla, se presentan algunas de las variaciones comunes que puedes necesitar según tu pila tecnológica existente y las formas de trabajar.
Área de decisión | Alternativas posibles |
---|---|
Organización: El plano usa una sola organización como nodo raíz para todos los recursos. |
Decide una jerarquía de recursos para tu Google Cloud zona de destino presenta situaciones en las que es posible que prefieras varias organizaciones, como las siguientes:
|
Estructura de carpetas: El plano tiene una estructura de carpetas simple, con cargas de trabajo divididas en carpetas |
Decide una jerarquía de recursos para tu Google Cloud zona de destino presenta otros enfoques para estructurar carpetas según la forma en la que desees administrar los recursos y heredar políticas, como las que se describen a continuación:
|
Políticas de la organización: El plano aplica todas las restricciones de la política de la organización en el nodo de la organización. |
Es posible que tengas diferentes políticas de seguridad o formas de trabajar para diferentes partes del negocio. En esta situación, aplica las restricciones de la política de la organización en un nodo inferior de la jerarquía de recursos. Revisa la lista completa de restricciones de las políticas de la organización que te ayudan a cumplir con tus requisitos. |
Herramientas de canalización de implementación: el plano usa Cloud Build para ejecutar la canalización de automatización. |
Es posible que prefieras otros productos para tu canalización de implementación, como Terraform Enterprise, GitLab Runners, GitHub Actions o Jenkins. El plano incluye instrucciones alternativas para cada producto. |
Repositorio de código para la implementación: el plano usa Cloud Source Repositories como el repositorio privado de Git administrado. |
Usa el sistema de control de versión que prefieras para administrar repositorios de código, como GitLab, GitHub o Bitbucket. Si usas un repositorio privado alojado en tu entorno local, configura una ruta de red privada desde tu repositorio hasta tu entorno de Google Cloud. |
Proveedor de identidad: el plano supone un Active Directory local y envía las identidades a Cloud Identity mediante Google Cloud Directory Sync. |
Si ya usas Google Workspace, puedes usar las identidades de Google que ya están administradas en Google Workspace. Si no tienes un proveedor de identidad existente, puedes crear y administrar las identidades de los usuarios directamente en Cloud Identity. Si tienes un proveedor de identidad existente, como Okta, Ping o Azure Entra ID, debes hacer lo siguiente podría administrar las cuentas de usuario en tu proveedor de identidad existente y sincronizarse con Cloud Identity. Si tienes requisitos de soberanía de los datos o cumplimiento que te impiden usar Cloud Identity y no necesitas identidades de usuario de Google administradas para otros servicios de Google, como Google Ads o Google Marketing Platform, entonces es posible que prefieras la federación de identidades de personal. En esta situación, ten en cuenta las limitaciones de los servicios compatibles. |
Varias regiones: El modelo de diseño implementa recursos regionales en dos regiones Google Cloud diferentes para ayudar a habilitar el diseño de cargas de trabajo con requisitos de alta disponibilidad y recuperación ante desastres. |
Si tienes usuarios finales en más ubicaciones geográficas, puedes configurar más regiones de Google Cloud para crear recursos más cercanos al usuario final con menos latencia. Si tienes restricciones de soberanía de los datos o tus necesidades de disponibilidad se pueden satisfacer en una sola región, puedes configurar solo una región deGoogle Cloud . |
Asignación de direcciones IP: El plano proporciona un conjunto de rangos de direcciones IP. |
Es posible que debas cambiar los rangos específicos de direcciones IP que se usan en función de la disponibilidad de la dirección IP en tu entorno híbrido existente. Si modificas los rangos de direcciones IP, usa el plano como guía para la cantidad y el tamaño de los rangos requeridos y revisa los rangos de direcciones IP válidos para Google Cloud. |
Herramientas de redes híbridas: El modelo usa la interconexión dedicada en varios sitios físicos y regiones deGoogle Cloud para obtener un ancho de banda y una disponibilidad máximos. |
En función de los requisitos de costo, ancho de banda y confiabilidad, puedes configurar Interconexión de socio o Cloud VPN en su lugar. Si necesitas comenzar a implementar recursos con conectividad privada antes de que se pueda completar una interconexión dedicada, puedes comenzar con Cloud VPN y cambiar a la interconexión dedicada más adelante. Si no tienes un entorno local existente, es posible que no necesites ninguna red híbrida. |
Perímetro de los Controles del servicio de VPC: El plano recomienda un solo perímetro que incluye todos los proyectos de servicio asociados con una red de VPC restringida. Los proyectos asociados con una red de VPC base no se incluyen en el perímetro. |
Es posible que tengas un caso de uso que requiera varios perímetros para una organización o que decidas no usar los Controles del servicio de VPC. Para obtener información, consulta cómo decidir cómo mitigar el robo de datos a través de las APIs de Google. |
Secret Manager: El plano implementa un proyecto para usar Secret Manager en la carpeta |
Si tienes un solo equipo responsable de administrar y auditar los secretos sensibles de toda la organización, es posible que prefieras usar solo un proyecto para administrar el acceso a los secretos. Si permites que los equipos de carga de trabajo administren sus propios secretos, es posible que no uses un proyecto centralizado para administrar el acceso a los secretos y, en su lugar, permitas que los equipos usen sus propias instancias de Secret Manager en los proyectos de carga de trabajo. |
Cloud KMS: El plano implementa un proyecto para usar Cloud KMS en la carpeta |
Si tienes un solo equipo responsable de administrar y auditar las claves de encriptación en toda la organización, es posible que prefieras usar un solo proyecto para administrar el acceso a las claves. Un enfoque centralizado puede ayudar a cumplir con los requisitos de cumplimiento, como los custodias de la clave PCI. Si permites que los equipos de carga de trabajo administren sus propias claves, no puedes usar un proyecto centralizado para administrar el acceso a las claves y, en su lugar, permitir que los equipos usen sus propias instancias de Cloud KMS en proyectos de carga de trabajo. |
Receptores de registros agregados: El plano configura un conjunto de receptores de registros en el nodo de la organización para que un equipo de seguridad central pueda revisar los registros de auditoría en toda la organización. |
Es posible que tengas diferentes equipos responsables de auditar diferentes partes del negocio, y estos equipos puedan requerir registros diferentes para realizar sus trabajos. En esta situación, debes diseñar varios receptores agregados en las carpetas y los proyectos adecuados, y crear filtros para que cada equipo reciba solo los registros necesarios o diseñar vistas de registro para el control de acceso detallado a un bucket de registros común. |
Nivel de detalle de las canalizaciones de infraestructura: El plano usa un modelo en el que cada unidad de negocios tiene una canalización de infraestructura independiente para administrar sus proyectos de carga de trabajo. |
Es posible que prefieras una sola canalización de infraestructura administrada por un equipo central si tienes un equipo central que es responsable de implementar todos los proyectos y la infraestructura. Este equipo central puede aceptar solicitudes de extracción de los equipos de cargas de trabajo para que las revisen y aprueben antes de la creación del proyecto, o pueden crear la solicitud de extracción en respuesta a un sistema con tickets. Es posible que prefieras canalizaciones más detalladas si los equipos de cargas de trabajo individuales tienen la capacidad de personalizar sus propias canalizaciones y deseas diseñar cuentas de servicio con privilegios más detalladas para las canalizaciones. |
Exportaciones de SIEM: El plano administra todos los resultados de seguridad en Security Command Center. |
Decide si exportarás los resultados de seguridad de Security Command Center a herramientas como Google Security Operations o tu SIEM existente, o si los equipos usarán la consola para ver y administrar los resultados de seguridad. Puedes configurar varias exportaciones con filtros únicos para diferentes equipos con diferentes permisos y responsabilidades. |
Búsquedas de DNS para Google Cloud servicios desde entornos locales: El plano configura un extremo único de Private Service Connect para cada VPC compartida, que puede ayudar a habilitar diseños con varios perímetros de Controles del servicio de VPC. |
Es posible que no necesites enrutar desde un entorno local a extremos de Private Service Connect en este nivel de detalle si no necesitas varios perímetros de Control del servicio de VPC. En lugar de asignar hosts locales a los extremos de Private Service Connect por entorno, puedes simplificar este diseño para usar un único extremo de Private Service Connect con el paquete de API adecuado o usar los extremos genéricos para |
¿Qué sigue?
- Implementa el plano mediante la base de ejemplo de Terraform en GitHub.
- Obtén más información sobre los principios de diseño de prácticas recomendadas con el framework de arquitectura deGoogle Cloud .
Revisa la biblioteca de planos para ayudarte a acelerar el diseño y la compilación de cargas de trabajo empresariales comunes, incluidos los siguientes:
Consulta las soluciones relacionadas para implementar sobre tu entorno base.
Para acceder a un entorno de demostración, comunícate con nosotros al correo electrónico security-foundations-blueprint-support@google.com.