--- title: "Lista de verificación de refuerzo de la seguridad de GCP | Snow Tree" url: "https://www.snow-tree.com/es/gcp-security-hardening/" --- Infraestructura GCP segura # Lista de verificación de refuerzo de la seguridad de GCP para equipos pequeños y medianos Una línea de base práctica para equipos que ejecutan cargas de trabajo de producción en Google Cloud sin un departamento de seguridad propio. Empieza por donde las vías más probables hacia un incidente grave son más fáciles de reducir. ## En esta página 1. [Vías de amenaza habituales en GCP](https://www.snow-tree.com/es/#threat-paths) 2. [Identidad y acceso](https://www.snow-tree.com/es/#identity) 3. [Red y perímetro](https://www.snow-tree.com/es/#network) 4. [Datos y secretos](https://www.snow-tree.com/es/#data) 5. [Refuerzo de la seguridad de GKE](https://www.snow-tree.com/es/#gke) 6. [Detección y recuperación](https://www.snow-tree.com/es/#detection) 7. [Una lista de verificación priorizada a 30, 60 y 90 días](https://www.snow-tree.com/es/#checklist) 8. [Referencias oficiales](https://www.snow-tree.com/es/#references) ## Vías de amenaza habituales en GCP La mayoría de los incidentes en la nube empiezan por una pequeña laguna de responsabilidad o de configuración. Busca estas vías antes de que lo haga un atacante. - Un usuario, una cuenta de servicio o una identidad de carga de trabajo con permisos excesivos puede convertir una sola credencial robada en un acceso amplio a varios proyectos. - Un endpoint de administración expuesto, un puerto de depuración o una regla de firewall permisiva pueden eludir todos los controles diseñados para el tráfico normal de la aplicación. - Un bucket de almacenamiento público o una URL firmada demasiado amplia pueden revelar datos de clientes sin que haya un compromiso visible de la aplicación. - Las cargas de trabajo obsoletas generan un riesgo duradero cuando las imágenes antiguas, los espacios de nombres olvidados, las cuentas de servicio sin uso y los recursos sin responsable siguen pudiendo desplegarse. - Si las evidencias de auditoría faltan o se conservan poco tiempo, es difícil saber quién cambió una política, cuándo empezó el acceso y a qué datos se llegó. - Una copia de seguridad sin probar es solo una esperanza. Las restauraciones fallidas, la retención incompleta y las claves de encriptación inaccesibles pueden convertir un evento de seguridad en una pérdida permanente. ## Identidad y acceso Trata la identidad como el plano de control principal. Cada persona, proceso de automatización y carga de trabajo debe tener una identidad propia con un propósito acotado. ### Haz explícitos los límites de los recursos Usa la organización y las carpetas para establecer barreras de protección, y separa desarrollo, preproducción y producción en proyectos distintos o tras límites de confianza más estrictos. Aplica las políticas de la organización en el nivel más alto que resulte práctico, restringe el uso de servicios y evita compartir proyectos de producción entre productos no relacionados. ### Concede el rol mínimo en el ámbito más reducido Prefiere roles predefinidos o personalizados a los roles primitivos amplios, otórgalos a grupos y a identidades de carga de trabajo, y usa condiciones de IAM cuando un nombre de recurso o una etiqueta permitan acotar el acceso. Revisa los permisos sin usar y elimina el acceso permanente a producción que solo debería existir mediante un procedimiento de acceso de emergencia (break-glass). ### Elimina las credenciales de larga duración Usa Workload Identity Federation for GKE para que los pods reciban credenciales de corta duración sin claves de cuenta de servicio exportadas. Bloquea la creación y la subida de claves con políticas de la organización siempre que sea posible, inventaría las claves que queden y configura alertas para los cambios de IAM de alto riesgo en Cloud Audit Logs. ## Red y perímetro Da por hecho que algún defecto de la aplicación acabará siendo accesible desde la red. Limita a qué puede acceder ese defecto. ### Empieza denegándolo todo y añade rutas con nombre Usa reglas de firewall de VPC de privilegio mínimo y NetworkPolicies de Kubernetes para el tráfico de los pods. Separa los entornos en redes distintas, documenta cada ruta de entrada y elimina las reglas de depuración amplias que permiten puertos de administración o todos los protocolos desde rangos de direcciones grandes. ### Mantén privados los nodos y los planos de control Inhabilita las direcciones IP externas en los nodos de GKE. Prefiere el endpoint privado del plano de control basado en DNS y, cuando un endpoint IP sea inevitable, restríngelo con redes autorizadas. Da a las cargas de trabajo una ruta de salida deliberada en lugar de un acceso amplio a internet. ### Publica solo los servicios públicos que decidas exponer Expón las aplicaciones mediante una puerta de enlace o un balanceador de carga revisados, no a través de direcciones de pods o nodos expuestas por accidente. Realiza la terminación TLS con certificados administrados, restringe los hosts y las rutas de entrada, aplica límites de solicitudes y de frecuencia, y protege las interfaces de administración con acceso basado en la identidad. ## Datos y secretos Protege los datos en reposo, en tránsito y en uso, y luego demuestra que puedes recuperarlos. El descubrimiento de datos forma parte del control. ### Evita el acceso público accidental Aplica la prevención del acceso público y el acceso uniforme a nivel de bucket en Cloud Storage. Clasifica los buckets según su sensibilidad, restringe el acceso a objetos y claves, habilita el registro para los datos de alto valor y usa claves de encriptación administradas por el cliente cuando tu modelo de riesgo o de cumplimiento lo exija. ### Mantén los secretos fuera de las imágenes y del código fuente Guarda las credenciales en Secret Manager y concede acceso a una identidad de carga de trabajo y una versión del secreto concretas. Rota los secretos de forma deliberada, evita copiarlos en Git o en imágenes de contenedor, y no consideres los Kubernetes Secrets ordinarios como un límite de protección completo. ### Prueba la recuperación, no solo la creación de copias de seguridad Define objetivos de punto de recuperación (RPO) y de tiempo de recuperación (RTO), conserva copias fuera del dominio de fallo de producción y protege el acceso a las copias de seguridad y a las claves de encriptación frente a la identidad de la carga de trabajo. Restaura periódicamente en un entorno aislado, verifica los datos y registra el tiempo transcurrido y cualquier paso manual. ## Refuerzo de la seguridad de GKE GKE protege el plano de control administrado, pero la configuración del clúster, los espacios de nombres, las políticas de admisión y las cargas de trabajo siguen siendo responsabilidad tuya. ### Convierte los espacios de nombres en el contrato de aislamiento Separa los equipos y los entornos en espacios de nombres o clústeres, vincula allí roles de Kubernetes RBAC acotados y aplica cuotas de recursos y NetworkPolicies. Evita el acceso de escritura a todo el clúster para la entrega de aplicaciones y da a cada carga de trabajo su propia cuenta de servicio cuando necesite una identidad diferenciada. ### Admite solo imágenes y configuraciones de confianza Aplica el estándar restringido de Pod Security o reglas equivalentes de Policy Controller. Despliega las imágenes por digest inmutable, analízalas en busca de vulnerabilidades, usa Binary Authorization cuando importe la procedencia, y rechaza el acceso inesperado al host, la escalada de privilegios y las vinculaciones de cluster-admin. ### Elimina los privilegios innecesarios de los contenedores Ejecuta los contenedores como usuario no root, descarta las capacidades de Linux, usa un sistema de archivos raíz de solo lectura cuando sea posible y aplica el perfil seccomp RuntimeDefault. No montes el token de la cuenta de servicio si no es necesario, evita los contenedores privilegiados y los espacios de nombres del host, reduce al mínimo los permisos de la cuenta de servicio de los nodos y usa Shielded Nodes junto con Container-Optimized OS. ## Detección y recuperación Los controles fallan. Apóyate en evidencias y en acciones ensayadas, no en la confianza de que nadie ha cometido un error. ### Reúne las evidencias que vas a necesitar Conserva Cloud Audit Logs y los registros del sistema y de las cargas de trabajo de GKE en un destino central, con una retención acorde a tus necesidades de investigación. Habilita selectivamente los registros de auditoría de acceso a los datos para los datos sensibles, restringe el acceso a los registros y deja constancia de los cambios administrativos en IAM, el firewall, el almacenamiento y la configuración del clúster. ### Configura alertas para los cambios relevantes para la seguridad Configura alertas para la exposición pública del almacenamiento, los cambios amplios en el firewall o en IAM, las claves de cuenta de servicio inesperadas, los rechazos de admisión, la exposición del plano de control, los fallos de autenticación repetidos, el registro deshabilitado, las copias de seguridad fallidas y los certificados a punto de caducar. Dirige cada alerta a un responsable, junto con los pasos para confirmarla o descartarla. ### Ensaya la respuesta Escribe runbooks breves para credenciales filtradas, datos expuestos públicamente, cargas de trabajo comprometidas y pérdida de regiones o proyectos. Incluye quién puede autorizar la contención, cómo revocar el acceso, cómo conservar las evidencias y cómo restablecer el servicio. Prueba los runbooks con las personas que los van a usar. ## Una lista de verificación priorizada a 30, 60 y 90 días Si partes de una línea de base incompleta, ordena el trabajo para reducir primero la exposición y conseguir que las revisiones posteriores sean repetibles. ### Días 1 a 30: cierra las vías evidentes Haz inventario de proyectos y responsables, elimina las credenciales sin uso y de larga duración, confirma el registro de auditoría, bloquea los buckets públicos, revisa las reglas de firewall y las concesiones de IAM más amplias, identifica las carencias en las copias de seguridad de producción y corrige cualquier endpoint público sin responsable. Asigna un responsable y una fecha límite a cada hallazgo. ### Días 31 a 60: haz que la línea de base sea repetible Lleva la configuración de red, identidad y cargas de trabajo a infraestructura como código revisada y a una entrega GitOps. Adopta Workload Identity, nodos privados, Pod Security restringido, comprobaciones de imágenes de confianza, registros centralizados y alertas para los cambios más importantes. ### Días 61 a 90: demuéstralo y mantenlo Realiza pruebas de restauración y un ejercicio de simulación de incidentes (tabletop), revisa el acceso privilegiado y la caducidad de las excepciones, vuelve a analizar imágenes y dependencias, verifica que los responsables reciben las alertas y mide las carencias que quedan. Incluye las comprobaciones en un ciclo de revisión periódico antes de que las evidencias queden obsoletas. Usa esta lista de verificación como punto de partida. Snow Tree puede aplicar la línea de base mediante la operación de su plataforma gestionada o un proyecto de consultoría específico. [Plataforma gestionada](https://www.snow-tree.com/es/managed-platform/) [Consultoría](https://www.snow-tree.com/es/consulting/) ## Referencias oficiales Toma las indicaciones actuales de Google como fuente técnica de referencia cuando cambien los valores predeterminados de la plataforma o las funciones de los productos. - [Google Cloud: prácticas recomendadas para reforzar la seguridad de tu clúster de GKE](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster) - [Google Cloud: prácticas recomendadas de seguridad para GKE](https://docs.cloud.google.com/docs/security/gke-security-bps) Plataforma gestionada ## Deja que Snow Tree desarrolle, aloje y opere tu software. [Iniciar un proyecto](mailto:support+snow-tree-platform-1-issue-@gitlab.snow-tree.com?subject=Snow%20Tree%20project)