Una canalización de implementación es un proceso automatizado que toma código o artefactos precompilados y los implementa en un entorno de prueba o en un entorno de producción. Las canalizaciones de implementación se suelen usar para implementar aplicaciones, configuración o infraestructura de nube (infraestructura como código), y pueden desempeñar una función importante en la postura de seguridad general de una implementación en la nube.
Esta guía está dirigida a ingenieros DevOps y de seguridad, y se describen las prácticas recomendadas para diseñar canalizaciones de implementación seguras según los requisitos de confidencialidad, integridad y disponibilidad.
Arquitectura
En el siguiente diagrama, se muestra el flujo de datos en una canalización de implementación. Se ilustra cómo puedes convertir los artefactos en recursos.
Las canalizaciones de implementación a menudo forman parte de un flujo de trabajo de integración continua/implementación continua (CI/CD) y, por lo general, se implementan mediante uno de los siguientes modelos:
Modelo de envío: en este modelo, implementas la canalización de implementación mediante un sistema de CI/CD central, como Jenkins o GitLab. Este sistema de CI/CD puede ejecutarse en Google Cloud, de manera local o en un entorno de nube diferente. A menudo, se usa el mismo sistema de CI/CD para administrar varias canalizaciones de implementación.
El modelo de envío lleva a una arquitectura centralizada con algunos sistemas de CI/CD que se usan para administrar una gran cantidad de recursos o aplicaciones. Por ejemplo, puedes usar una sola instancia de Jenkins o GitLab para administrar todo tu entorno de producción, incluidos todos sus proyectos y aplicaciones.
Modelo de extracción: en este modelo, un agente implementa el proceso de implementación que es implementado junto con el recurso, por ejemplo en el mismo Kubernetes clúster. El agente extrae artefactos o código fuente de una ubicación centralizada y, luego, los implementa de forma local. Cada agente administra uno o dos recursos.
El modelo de extracción lleva a una arquitectura más descentralizada con una cantidad potencialmente grande de agentes de un solo propósito.
En comparación con las implementaciones manuales, el uso coherente de canalizaciones de implementación puede tener los siguientes beneficios:
- Mayor eficiencia, ya que no se requiere trabajo manual.
- Mayor confiabilidad, ya que el proceso es completamente automatizado y repetible.
- Mayor trazabilidad, ya que puedes rastrear todas las implementaciones hasta cambios en el código o artefactos de entrada
Para realizar una canalización de implementación, se requiere acceso a los recursos que administra:
- una canalización que implementa infraestructura mediante herramientas como Terraform puede necesitar crear, modificar o incluso borrar recursos como instancias de VM, subredes o depósitos de Cloud Storage.
- Es posible que una canalización que implementa aplicaciones necesite subir imágenes de contenedor nuevas a Artifact Registry y que implemente versiones nuevas de la aplicación en App Engine. Cloud Run, o Google Kubernetes Engine (GKE).
- Una canalización que administra la configuración o implementa archivos de configuración puede necesitar modificar los metadatos de la instancia de VM, las configuraciones de Kubernetes o modificar los datos en Cloud Storage.
Si las canalizaciones de implementación no están protegidas de forma correcta, su acceso a los recursos de Google Cloud puede convertirse en un punto débil en tu posición de seguridad. Una seguridad debilitada puede generar varios tipos de ataques, incluidos los siguientes:
Ataques de envenenamiento de canalización: en lugar de atacar un recurso directamente, una persona/entidad que actúa de mala fe puede intentar comprometer la canalización de implementación, su configuración o su infraestructura subyacente. Aprovechar el acceso de la canalización a Google Cloud, la persona/entidad que actúa de mala fe puede hacer que la canalización realice acciones maliciosas en los recursos de Cloud, como se muestra en el siguiente diagrama:
Ataques de cadena de suministro: En lugar de atacar la canalización de implementación, una persona/entidad que actúa de mala fe puede intentar comprometer o reemplazar la entrada de la canalización, incluidas el código fuente, las bibliotecas o las imágenes de contenedor, como se muestra en el siguiente diagrama:
Para determinar si tus canalizaciones de implementación están protegidas de forma adecuada, no es suficiente ver solo las políticas de permisos y denegación de los recursos de Google Cloud de forma aislada. En cambio, debes considerar todo el gráfico de sistemas que otorgan acceso a un recurso de forma directa o indirecta. En este gráfico, se incluye la siguiente información:
- La canalización de implementación, su sistema de CI/CD subyacente y su infraestructura subyacente
- El repositorio de código fuente, sus servidores subyacentes y su infraestructura subyacente
- Los artefactos de entrada, sus ubicaciones de almacenamiento y su infraestructura subyacente
- Sistemas que producen los artefactos de entrada y su infraestructura subyacente
Los grafos de entrada complejos dificultan la identificación del acceso de los usuarios a los recursos y las debilidades sistémicas.
En las siguientes secciones, se describen las prácticas recomendadas para diseñar canalizaciones de implementación de una manera que te ayude a administrar el tamaño del grafo y reducir el riesgo de movimiento lateral y ataques de cadena de suministro.
Evalúa los objetivos de seguridad
Es probable que los recursos en Google Cloud varíen en cuanto a la sensibilidad. Algunos recursos pueden ser muy sensibles porque son fundamentales o confidenciales para la empresa. Otros recursos pueden ser menos sensibles porque son efímeros o solo están destinados a pruebas.
Para diseñar una canalización de implementación segura, primero debes comprender los recursos a los que debe acceder la canalización y su sensibilidad. Cuanto más sensibles sean tus recursos, más deberás enfocarte en proteger la canalización.
Los recursos a los que se accede mediante las canalizaciones de implementación pueden incluir los siguientes:
- Aplicaciones, como Cloud Run o App Engine
- Recursos de Cloud, como instancias de VM o buckets de Cloud Storage
- Datos, como objetos de Cloud Storage, registros de BigQuery o archivos
Algunos de estos recursos pueden tener dependencias en otros recursos, por ejemplo:
- Las aplicaciones pueden acceder a los datos, a los recursos en la nube y a otras aplicaciones.
Los recursos de la nube, como las instancias de VM o los Cloud Storage buckets, pueden contener aplicaciones o datos.
Como se muestra en el diagrama anterior, las dependencias afectan la sensibilidad de los recursos. Por ejemplo, si usas una aplicación que accede a datos altamente sensibles, por lo general, debes tratar esa aplicación como muy sensible. Del mismo modo, si un recurso de nube como un bucket de Cloud Storage contiene datos sensibles, por lo general, debes tratar el bucket como sensible.
Debido a estas dependencias, es mejor evaluar primero la sensibilidad de tus datos. Una vez que hayas evaluado tus datos, puedes examinar la cadena de dependencias y evaluar la sensibilidad de los recursos y las aplicaciones de Cloud.
Categoriza la sensibilidad de tus datos
Para comprender la sensibilidad de los datos en tu canalización de implementación, considera los siguientes tres objetivos:
- Confidencialidad: Debes proteger los datos del acceso no autorizado.
- Integridad: Debes proteger los datos contra modificaciones o eliminaciones no autorizadas.
- Disponibilidad: Debes asegurarte de que las personas y los sistemas autorizados puedan acceder a los datos en tu canalización de implementación.
Para cada uno de estos objetivos, pregúntate qué sucedería si se viola la seguridad de la canalización:
- Confidencialidad: ¿qué tan perjudicial sería si los datos se divulgaran a una persona/entidad que actúa de mala fe o se filtran al público?
- Integridad: ¿qué tan perjudicial sería si una persona/entidad que actúa de mala fe modificó o borró los datos?
- Disponibilidad: ¿qué tan perjudicial podría ser si una persona/entidad que actúa de mala fe interrumpe el acceso a los datos?
Para que los resultados sean comparables en todos los recursos, es útil ingresar categorías de seguridad. Estándares para la categorización de seguridad (FIPS-199) sugiere las siguientes cuatro categorías:
- Alta: los daños podrían ser graves o catastróficos.
- Moderado: los daños podrían ser graves
- Baja: se limitaría el daño.
- No aplicable: el estándar no aplica
Según tu entorno y contexto, un conjunto diferente de categorías podría ser más apropiado.
La confidencialidad y la integridad de los datos de la canalización existen en un espectro, basado en las categorías de seguridad que se acaban de analizar. Las siguientes subsecciones contienen ejemplos de recursos con diferentes medidas de confidencialidad e integridad:
Recursos con baja confidencialidad, pero con integridad baja, moderada y alta
Todos los ejemplos de recursos siguientes tienen baja confidencialidad:
- Integridad baja: datos de prueba
- Integridad moderada: contenido del servidor web público, restricciones de políticas para la organización
- Integridad alta: imágenes de contenedor, imágenes de disco, configuraciones de aplicación, políticas de acceso (listas de permiso y rechazo), retenciones, datos de nivel de acceso
Recursos con confidencialidad media, pero con integridad baja, moderada y alta
Todos los ejemplos de recursos siguientes tienen confidencialidad media:
- Integridad baja: contenido del servidor web interno
- Integridad moderada: registros de auditoría
- Integridad alta: archivos de configuración de la aplicación
Recursos con alta confidencialidad, pero baja, moderada y alta integridad
Los siguientes ejemplos de recursos tienen alta confidencialidad:
- Integridad baja: datos de uso e información de identificación personal
- Integridad moderada: secretos
- Integridad alta: datos financieros, claves de KMS
Clasificar las aplicaciones en función de los datos a los que acceden
Cuando una aplicación accede a datos sensibles, la aplicación y la canalización de implementación que administra la aplicación también pueden volverse sensibles. Para calificar esa sensibilidad, observa los datos a los que deben acceder la aplicación y la canalización.
Una vez que hayas identificado y categorizado todos los datos a los que accedió una aplicación, puedes usar las siguientes categorías para categorizar la aplicación inicialmente antes de diseñar una canalización de implementación segura:
- Confidencialidad: la categoría más alta de los datos a los que se accedió
- Integridad: la categoría más alta de los datos a los que se accedió
- Disponibilidad: la categoría más alta de los datos a los que se accedió
Esta evaluación inicial proporciona orientación, pero puede haber factores adicionales que tener en cuenta, por ejemplo:
- Dos conjuntos de datos pueden tener una confidencialidad baja de forma aislada. Pero cuando se combinan, pueden revelar estadísticas nuevas. Si una aplicación tiene acceso a ambos conjuntos de datos, es posible que debas clasificarla como de confidencialidad media o alta.
- Si una aplicación tiene acceso a datos de integridad alta, por lo general, debes categorizarla como de alta integridad. Sin embargo, si ese acceso es de solo lectura, una categorización de alta integridad puede ser demasiado estricta.
Si deseas obtener detalles sobre un enfoque formalizado para clasificar aplicaciones, consulta la Guía para asignar tipos de sistemas de información y información a categorías de seguridad (NIST SP 800-60 Vol. 2 Rev1).
Categoriza los recursos de la nube según los datos y las aplicaciones que alojan
Un recurso de Google Cloud aloja cualquier dato o aplicación que implementes en Google Cloud:
- Una aplicación puede estar alojada por un servicio de App Engine, una instancia de VM o un clúster de GKE.
- Es posible que tus datos estén alojados en un disco persistente, un bucket de Cloud Storage o un conjunto de datos de BigQuery.
Cuando un recurso en la nube aloja datos o aplicaciones sensibles, el recurso y la canalización de implementación que administra el recurso también pueden volverse sensibles. Por ejemplo, debes considerar que un servicio de Cloud Run y su canalización de implementación son tan sensibles como la aplicación que aloja.
Después de clasificar los datos y las aplicaciones, crea una categoría de seguridad inicial para la aplicación. Para hacerlo, determina un nivel de las siguientes categorías:
- Confidencialidad: la categoría más alta de los datos o aplicaciones alojadas.
- Integridad: es la categoría más alta de datos o aplicaciones alojadas.
- Disponibilidad: la categoría más alta de los datos o aplicaciones alojadas
Cuando realices tu evaluación inicial, no seas demasiado estricta, por ejemplo:
- si encriptas datos altamente confidenciales, trata la clave de encriptación como altamente confidencial. Sin embargo, puedes usar una categoría de seguridad más baja para el recurso que contiene los datos.
- Si almacenas copias redundantes de datos o ejecutas instancias redundantes de las mismas aplicaciones en varios recursos, puedes hacer que la categoría de recursos sea menor que la categoría de datos o aplicación que aloja.
Restringe el uso de canalizaciones de implementación
Si tu canalización de implementación necesita acceder a recursos sensibles de Google Cloud, debes considerar su postura de seguridad. Cuanto más sensibles sean los recursos, mejor deberás intentar proteger la canalización. Sin embargo, es posible que encuentres las siguientes limitaciones prácticas:
- Cuando se usa una infraestructura existente o un sistema de CI/CD existente, esa infraestructura puede limitar el nivel de seguridad que puedes lograr de forma realista. Por ejemplo, es posible que el sistema de CI/CD solo admita un conjunto limitado de controles de seguridad o que se ejecute en una infraestructura que consideres menos segura que en algunos de los entornos de producción.
- Cuando configuras una infraestructura y sistemas nuevos para ejecutar la canalización de implementación, puede que no sea rentable proteger todos los componentes de una manera que cumpla con los requisitos de seguridad más estrictos.
Para abordar estas limitaciones, puede ser útil establecer restricciones en qué situaciones deben y no deben usar las canalizaciones de implementación y un sistema de CI/CD en particular. Por ejemplo, las implementaciones más sensibles suelen manejarse mejor fuera de una canalización de implementación. Estas implementaciones pueden ser manuales mediante un sistema de administración de sesiones con privilegios, un sistema de administración de acceso con privilegios o algo más, como los proxies de herramientas.
Para establecer tus restricciones, define qué controles de acceso deseas aplicar en función de las categorías de recursos. Considera la orientación que se ofrece en la siguiente tabla:
| Categoría del recurso | Controles de acceso |
|---|---|
| Baja | No se requiere aprobación |
| Moderada | El líder del equipo debe aprobar la solicitud |
| Alta | Se deben aprobar varios clientes potenciales y se deben registrar las acciones |
Para contrastar estos requisitos con las capacidades de la administración de código fuente (SCM) y los sistemas de CI/CD, haz las siguientes preguntas y otras:
- ¿Tus sistemas de SCM o CI/CD admiten los controles de acceso y los mecanismos de aprobación necesarios?
- ¿Los controles están protegidos contra las anulaciones si las personas malintencionadas atacan la infraestructura subyacente?
- ¿La configuración que define los controles es adecuada?
Según las capacidades y limitaciones que imponen tus sistemas de SCM o CI/CD, puedes definir los límites de datos y aplicaciones para tus canalizaciones de implementación. Considera la orientación que se ofrece en la siguiente tabla:
| Categoría del recurso | Limitaciones |
|---|---|
| Baja | Se pueden usar las canalizaciones de implementación, y los desarrolladores pueden aprobar las implementaciones por su cuenta. |
| Moderada | Se pueden usar las canalizaciones de implementación, pero los líderes de equipo deben aprobar todas las implementaciones y confirmaciones. |
| Alta | No uses canalizaciones de implementación. En su lugar, los administradores deben usar un sistema de administración de acceso con privilegios y un registro de sesión. |
Mantén la disponibilidad de los recursos
El uso de una canalización de implementación para administrar recursos puede afectar la disponibilidad de esos recursos y puede introducir nuevos riesgos:
- Causa de interrupciones: Una canalización de implementación puede enviar un código o archivos de configuración defectuosos, lo que hace que un sistema que funcionaba antes se rompa o que los datos se vuelvan inutilizables.
- Prolongaciones de las interrupciones: para corregir una interrupción, es posible que debas volver a ejecutar una canalización de implementación. Si la canalización de implementación está dañada o no está disponible por otros motivos, esto podría extender la interrupción.
Una canalización que puede causar o prolongar interrupciones representa un riesgo de denegación del servicio: una persona/entidad que actúa de mala fe puede usar la canalización de implementación para causar una interrupción de forma intencional.
Crea procedimientos de acceso de emergencia
Cuando una canalización de implementación es la única forma de implementar o configurar una aplicación o un recurso, la disponibilidad de la canalización puede volverse fundamental. En casos extremos, en los que una canalización de implementación es la única forma de administrar una aplicación fundamental para la empresa, es posible que también debas considerar la canalización de implementación crítica para la empresa.
Debido a que las canalizaciones de implementación suelen provenir de varios sistemas y herramientas, mantener un alto nivel de disponibilidad puede ser difícil o poco rentable.
Puedes reducir la influencia de las canalizaciones de implementación en la disponibilidad mediante la creación de procedimientos de acceso de emergencia. Por ejemplo, crea una ruta de acceso alternativa que se pueda usar si la canalización de implementación no está operativa.
La creación de un procedimiento de acceso de emergencia suele requerir la mayoría de los procesos siguientes:
- Mantén una o más de las cuentas de usuario con acceso privilegiado a los recursos relevantes de Google Cloud.
- Almacena las credenciales de las cuentas de usuario de acceso de emergencia en una ubicación segura o usa un sistema de administración de acceso con privilegios para acceder a los agentes.
- Establece un procedimiento que los empleados autorizados puedan seguir para acceder a las credenciales.
- Audita y revisa el uso de las cuentas de usuario de acceso de emergencia.
Asegúrate de que los artefactos de entrada cumplan con tus demandas de disponibilidad
Por lo general, las canalizaciones de implementación necesitan descargar el código fuente de un repositorio de código fuente central para poder realizar una implementación. Si el repositorio de código fuente no está disponible, es probable que la ejecución de la canalización de implementación falle.
Muchas canalizaciones de implementación también dependen de artefactos de terceros. Estos artefactos
pueden incluir bibliotecas de fuentes como npm, Maven Central o NuGet Gallery, así como
imágenes base de contenedores y paquetes .deb y .rpm. Si
una de las fuentes de terceros no está disponible, la ejecución de la canalización de
implementación puede fallar.
Para mantener un cierto nivel de disponibilidad, debes asegurarte de que los artefactos de entrada de la canalización de implementación cumplan con los mismos requisitos de disponibilidad o con uno más alto. La siguiente lista puede ayudarte a garantizar la disponibilidad de los artefactos de entrada:
- Limita la cantidad de fuentes para los artefactos de entrada, en especial las fuentes de terceros
- Mantener una caché de artefactos de entrada que las canalizaciones de implementación pueden usar si los sistemas de origen no están disponibles
Trata las canalizaciones de implementación y su infraestructura como sistemas de producción
Las canalizaciones de implementación suelen funcionar como el tejido conector entre los entornos de desarrollo, etapa de pruebas y producción. Según el entorno, pueden implementar varias etapas:
- En la primera, la canalización de implementación actualiza un entorno de desarrollo.
- En la siguiente etapa, la canalización de implementación actualiza un entorno de etapa de pruebas.
- En la etapa final, la canalización de implementación actualiza el entorno de producción.
Cuando uses una canalización de implementación en varios entornos, asegúrate de que la canalización cumpla con las demandas de disponibilidad de cada entorno. Debido a que los entornos de producción suelen tener las demandas de mayor disponibilidad, debes tratar la canalización de implementación y su infraestructura subyacente como un sistema de producción. En otras palabras, aplica los mismos estándares de control de acceso, seguridad y calidad a la infraestructura que ejecuta las canalizaciones de implementación que lo haces para los sistemas de producción.
Limita el alcance de las canalizaciones de implementación
Cuantos más recursos pueda acceder una canalización de implementación, más daños puede causar si se vulnera. Una canalización de implementación vulnerada que tiene acceso a varios proyectos o incluso a toda tu organización podría, en el peor de los casos, causar daños duraderos en todos tus datos y aplicaciones en Google Cloud.
Para evitar esta peor situación, limita el alcance de las canalizaciones de implementación. Define el alcance de cada canalización de implementación para que solo necesite acceso a una cantidad relativamente pequeña de recursos en Google Cloud:
- En lugar de otorgar acceso a nivel de proyecto, solo otorga acceso a los recursos de implementación a las canalizaciones individuales.
- Evita otorgar acceso a los recursos en varios proyectos de Google Cloud.
- Divide las canalizaciones de implementación en varias etapas si necesitan acceso a varios proyectos o entornos. Luego, protege las etapas de forma individual.
Mantener la confidencialidad
Una canalización de implementación debe mantener la confidencialidad de los datos que administra. Uno de los riesgos principales relacionados con la confidencialidad es el robo de datos.
Existen varias formas en las que una persona/entidad que actúa de mala fe podría intentar usar una canalización de implementación para robar datos de los recursos de Google Cloud. Se incluyen las siguientes formas:
- Directo: una persona/entidad que actúa de mala fe puede modificar la canalización de implementación o su configuración para que extraiga datos de tus recursos de Google Cloud y luego, los copie en otro lugar.
- Indirecta: una persona/entidad que actúa de mala fe puede usar la canalización de implementación para implementar código vulnerado, que luego roba datos de tu entorno de Google Cloud.
Puedes reducir los riesgos de confidencialidad si minimizas el acceso a los recursos confidenciales. Sin embargo, quitar todo el acceso a los recursos confidenciales no es práctico. Por lo tanto, debes diseñar tu canalización de implementación para cumplir con las demandas de confidencialidad de los recursos que administra. Para determinar estas demandas, puedes usar el siguiente enfoque:
- Determina los datos, las aplicaciones y los recursos a los que la canalización de implementación necesita acceder y los clasifica.
- Busca el recurso con la categoría de confidencialidad más alta y úsalo como una categoría inicial para la canalización de implementación.
Al igual que el proceso de categorización para las aplicaciones y los recursos en la nube, esta evaluación inicial no siempre es adecuada. Por ejemplo, puedes usar una canalización de implementación para crear recursos que contendrán información altamente confidencial. Si restringes la canalización de implementación para que pueda crear estos recursos, pero no puedes leerlos, es posible que una categoría de confidencialidad más baja sea suficiente.
Para mantener la confidencialidad, el modelo Bell-LaPadula sugiere que una canalización de implementación no debe hacer lo siguiente:
- Consume artefactos de entrada de mayor confidencialidad
- Escribe datos en un recurso de menor confidencialidad
Según el modelo de Bell-LaPadula, en el diagrama anterior, se muestra cómo deben fluir los datos en la canalización para garantizar la confidencialidad de los datos.
No permitas que las canalizaciones de implementación lean datos que no necesitan
Las canalizaciones de implementación a menudo no necesitan acceso a los datos, pero pueden tenerla. El exceso de otorgamiento de acceso puede deberse a lo siguiente:
- Otorgar permisos de acceso incorrectos. Por ejemplo, a una canalización de implementación se le puede otorgar acceso a Cloud Storage a nivel de proyecto. Como resultado, la canalización de implementación puede acceder a todos los buckets de Cloud Storage en el proyecto, aunque el acceso a un solo bucket podría ser suficiente.
- Usar una función demasiado permisiva Por ejemplo, una canalización de implementación puede tener una función que proporcione acceso completo a Cloud Storage. Sin embargo, bastaría con el permiso para crear buckets nuevos.
A cuantos más datos acceda una canalización, mayor será el riesgo de que alguien o algo pueda robar tus datos. Para ayudar a minimizar este riesgo, evita otorgar a las canalizaciones de implementación acceso a cualquier dato que no necesiten. Muchas canalizaciones de implementación no necesitan acceso a los datos porque su único propósito es administrar las implementaciones de configuración o software.
No permitas que las canalizaciones de implementación escriban a ubicaciones que no necesitan
Para quitar datos, una persona/entidad que actúa de mala fe necesita acceso y una forma de transferir los datos fuera de tu entorno. A cuantas más ubicaciones de almacenamiento y red pueda enviar datos una canalización de implementación, más probable es que una persona/entidad que actúa de mala fe pueda usar una de esas ubicaciones para el robo de datos.
Para ayudar a reducir el riesgo, limita la cantidad de ubicaciones de red y almacenamiento a las que una canalización puede enviar datos:
- Revoca el acceso de escritura a los recursos que la canalización no necesita, incluso si los recursos no contienen datos confidenciales.
- Bloquea el acceso a Internet o restringe las conexiones a un conjunto de ubicaciones de red de la lista de entidades permitidas.
La restricción del acceso saliente es muy importante para las canalizaciones que clasificaste como moderadamente confidenciales o altamente confidenciales porque tienen acceso a datos confidenciales o material de la clave criptográfica.
Usa los Controles del servicio de VPC para evitar que las implementaciones vulneradas roben datos
En lugar de permitir que la canalización de implementación realice el robo de datos, una persona malintencionada podría intentar usar la canalización de implementación para implementar código vulnerado. Ese código vulnerado puede robar datos desde el entorno de Google Cloud.
Puedes ayudar a reducir el riesgo de esas amenazas de robo de datos mediante los Controles del servicio de VPC. Los Controles del servicio de VPC te permiten restringir el conjunto de recursos y API a los que se puede acceder desde ciertos proyectos de Google Cloud.
Mantener la integridad
Para mantener seguro tu entorno de Google Cloud, debes proteger su integridad. Esto incluye:
- Evita modificaciones o eliminaciones no autorizadas de los datos o la configuración
- Impide que se implemente un código o una configuración no confiables
- Asegúrate de que todos los cambios dejen un registro de auditoría claro
Las canalizaciones de implementación pueden ayudarte a mantener la integridad de tu entorno, ya que te permiten hacer lo siguiente:
- Implementar procesos de aprobación, por ejemplo, en forma de revisiones de código
- Aplicar un proceso coherente para todos los cambios de configuración o código
- Ejecutar pruebas automatizadas o verificaciones rápidas antes de cada implementación
Para que sean eficaces, debes intentar asegurarte de que las personas que actúan de mala fe no puedan socavar o evitar estas medidas. Para evitar esta actividad, debes proteger la integridad de lo siguiente:
- La canalización de implementación y su configuración
- La infraestructura subyacente
- Todas las entradas que consume la canalización de implementación
Para evitar que la canalización de implementación se vuelva vulnerable, intenta asegurarte de que los estándares de integridad de la canalización de implementación coincidan o excedan las demandas de integridad de los recursos que administra. Para determinar estas demandas, puedes usar el siguiente enfoque:
- Determina los datos, las aplicaciones y los recursos a los que la canalización de implementación necesita acceder y los clasifica.
- Busca el recurso con la categoría de integridad más alta y úsalo como la categoría para la canalización de implementación.
Para mantener la integridad de la canalización de implementación, el modelo Biba sugiere lo siguiente:
- La canalización de implementación no debe consumir artefactos de entrada de menor integridad.
- La canalización de implementación no debe escribir datos en un recurso de mayor integridad.
Según el modelo de Biba, el diagrama anterior muestra cómo deben fluir los datos en la canalización para garantizar la integridad de los datos.
Verifica la autenticidad de los artefactos de entrada
Muchas canalizaciones de implementación consumen artefactos de fuentes de terceros. Estos artefactos pueden incluir los siguientes:
- Imágenes base de Docker
- Paquetes
.rpmo.deb - Bibliotecas Maven,
.npmo NuGet
Una persona/entidad que actúa de mala fe podría intentar modificar tu canalización de implementación para que use versiones vulneradas de artefactos de terceros mediante las siguientes acciones:
- Comprometiendo el repositorio que almacena los artefactos
- Modificando la configuración de la canalización de implementación para usar un repositorio de código fuente diferente
- Subiendo paquetes maliciosos con nombres similares o nombres que contengan errores tipográficos
Muchos administradores de paquetes te permiten verificar la autenticidad de un paquete mediante la compatibilidad con la firma de código. Por ejemplo, puedes usar PGP para firmar paquetes de RPM y Maven. Puedes usar Authenticode para firmar paquetes de NuGet.
Puedes usar la firma de código para reducir el riesgo de ser víctima de paquetes de terceros vulnerados mediante las siguientes acciones:
- Requiriendo que todos los artefactos de terceros estén firmados
- Manteniendo una lista seleccionada de certificados de publicadores de confianza o claves públicas
- Permitiendo que la canalización de implementación verifique la firma de los artefactos de terceros en la lista de publicadores de confianza
Como alternativa, puedes verificar los hashes de los artefactos. Puedes usar este enfoque para los artefactos que no admiten la firma de código y el cambio con poca frecuencia.
Asegúrate de que la infraestructura subyacente satisfaga tus demandas de integridad
En lugar de comprometer la canalización de implementación, las personas/entidades que actúan de mala fe pueden intentar comprometer su infraestructura, incluidas las siguientes:
- El software de CI/CD que ejecuta la canalización de implementación
- Las herramientas que usa la canalización, por ejemplo, Terraform, kubectl o Docker
- El sistema operativo y todos sus componentes
Debido a que la infraestructura que sustenta las canalizaciones de implementación suele ser compleja y puede contener componentes de varios proveedores o fuentes, este tipo de incumplimiento de seguridad puede ser difícil de detectar.
Para ayudar a reducir el riesgo de una infraestructura comprometida, haz lo siguiente:
- Mantén la infraestructura y todos sus componentes en los mismos estándares de integridad que los de la canalización de implementación y los recursos de Google Cloud que administra
- Asegúrate de que las herramientas provengan de una fuente confiable y verifican su autenticidad
- Vuelve a compilar infraestructura desde cero con regularidad
- Ejecuta la canalización de implementación en VM protegidas
Aplica controles de integridad en la canalización
Si bien las personas malintencionadas son una amenaza, no son la única fuente posible de cambios de software o configuración que pueden afectar la integridad del entorno de Google Cloud. Estos cambios también pueden originarse de los desarrolladores y simplemente son accidentales, debido a la falta de conocimiento o al resultado de errores tipográficos y otros errores.
Puedes ayudar a reducir el riesgo de aplicar de forma involuntaria cambios riesgosos mediante la configuración de canalizaciones de implementación para aplicar controles de integridad adicionales. Estos controles pueden incluir lo siguiente:
- Realizar análisis estáticos del código y la configuración
- Requerir que todos los cambios pasen un conjunto de reglas (política como código)
- Limitar la cantidad de cambios que se pueden realizar al mismo tiempo
¿Qué sigue?
- Obtén información sobre nuestras prácticas recomendadas para usar cuentas de servicio en canalizaciones de implementación.
- Revisa nuestras prácticas recomendadas para proteger las cuentas de servicio.
- Obtén más información sobre cómo investigar y responder a las amenazas.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.