Una canalización de despliegue es un proceso automatizado que toma código o artefactos precompilados y los despliega en un entorno de pruebas o de producción. Las pipelines de despliegue se suelen usar para desplegar aplicaciones, configuraciones o infraestructura en la nube (infraestructura como código) y pueden desempeñar un papel importante en la postura de seguridad general de un despliegue en la nube.
Esta guía está dirigida a ingenieros de DevOps y de seguridad, y describe las prácticas recomendadas para diseñar pipelines de implementación seguros en función de tus 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 muestra cómo puedes convertir tus artefactos en recursos.
Los flujos de procesamiento de despliegue suelen formar parte de un flujo de trabajo de integración continua y despliegue continuo (CI/CD) más amplio, y se suelen implementar con uno de los siguientes modelos:
Modelo push: en este modelo, implementas el flujo de procesamiento de despliegue mediante un sistema de CI/CD central, como Jenkins u GitLab. Este sistema de CI/CD puede ejecutarse en Google Cloud, on-premise o en un entorno de nube diferente. A menudo, se usa el mismo sistema de CI/CD para gestionar varias pipelines de implementación.
El modelo push da lugar a una arquitectura centralizada con unos pocos sistemas de CI/CD que se usan para gestionar un número potencialmente grande de recursos o aplicaciones. Por ejemplo, puede usar una sola instancia de Jenkins o GitLab para gestionar todo su entorno de producción, incluidos todos sus proyectos y aplicaciones.
Modelo de extracción: en este modelo, el proceso de despliegue se implementa mediante un agente que se despliega junto al recurso (por ejemplo, en el mismo clúster de Kubernetes). El agente extrae artefactos o código fuente de una ubicación centralizada y los despliega de forma local. Cada agente gestiona uno o dos recursos.
El modelo de extracción da lugar a una arquitectura más descentralizada con un número potencialmente grande de agentes de un solo propósito.
En comparación con las implementaciones manuales, usar de forma constante las canalizaciones de implementación puede ofrecer las siguientes ventajas:
- Mayor eficiencia, ya que no se requiere trabajo manual.
- Mayor fiabilidad, ya que el proceso está totalmente automatizado y se puede repetir.
- Mayor trazabilidad, ya que puedes rastrear todas las implementaciones hasta los cambios en el código o en los artefactos de entrada.
Para llevar a cabo una implementación, una canalización de implementación requiere acceso a los recursos que gestiona:
- Una canalización que despliega infraestructura mediante herramientas como Terraform puede necesitar crear, modificar o incluso eliminar recursos como instancias de VM, subredes o segmentos de Cloud Storage.
- Una canalización que despliega aplicaciones puede necesitar subir nuevas imágenes de contenedor a Artifact Registry y desplegar nuevas versiones de la aplicación en App Engine, Cloud Run o Google Kubernetes Engine (GKE).
- Un flujo de trabajo que gestione ajustes o implemente archivos de configuración puede necesitar modificar los metadatos de las instancias de VM, las configuraciones de Kubernetes o los datos de Cloud Storage.
Si tus pipelines de implementación no están protegidos correctamente, su acceso a los recursosGoogle Cloud puede convertirse en un punto débil de tu postura de seguridad. Una seguridad débil puede dar lugar a varios tipos de ataques, como los siguientes:
Ataques de envenenamiento de la canalización: en lugar de atacar un recurso directamente, un agente malicioso puede intentar poner en peligro la canalización de implementación, su configuración o su infraestructura subyacente. Aprovechando el acceso del flujo de trabajo a Google Cloud, el agente malintencionado podría hacer que el flujo de trabajo realizara acciones maliciosas en los recursos de Cloud, como se muestra en el siguiente diagrama:
Ataques a la cadena de suministro: en lugar de atacar la canalización de implementación, un agente malintencionado puede intentar poner en peligro o sustituir la entrada de la canalización, incluido el código fuente, las bibliotecas o las imágenes de contenedor, como se muestra en el siguiente diagrama:
Para determinar si tus pipelines de implementación están protegidos adecuadamente, no basta con fijarse únicamente en las políticas de permiso y de denegación de los recursos de Google Cloud de forma aislada. En su lugar, debes tener en cuenta todo el gráfico de sistemas que conceden acceso a un recurso de forma directa o indirecta. Este gráfico incluye la siguiente información:
- El flujo de procesamiento de despliegue, su sistema de CI/CD subyacente y su infraestructura subyacente
- El repositorio de código fuente, sus servidores subyacentes y su infraestructura subyacente
- Artefactos de entrada, sus ubicaciones de almacenamiento y su infraestructura subyacente
- Sistemas que producen los artefactos de entrada y su infraestructura subyacente
Los gráficos de entrada complejos dificultan la identificación del acceso de los usuarios a los recursos y las vulnerabilidades sistémicas.
En las siguientes secciones se describen las prácticas recomendadas para diseñar las canalizaciones de implementación de forma que le ayuden a gestionar el tamaño del gráfico y a reducir el riesgo de movimientos laterales y ataques a la cadena de suministro.
Evaluar los objetivos de seguridad
Es probable que tus recursos en Google Cloud varíen en cuanto a su sensibilidad. Algunos recursos pueden ser muy sensibles porque son cruciales para la empresa o confidenciales. Otros recursos pueden ser menos sensibles porque son efímeros o solo están pensados para hacer pruebas.
Para diseñar una canalización de implementación segura, primero debes saber a qué recursos necesita acceder la canalización y el nivel de confidencialidad de esos recursos. Cuanto más sensibles sean tus recursos, más deberías centrarte en proteger la canalización.
Los recursos a los que acceden las canalizaciones de implementación pueden incluir lo siguiente:
- Aplicaciones, como Cloud Run o App Engine
- Recursos de la nube, como instancias de VM o segmentos de Cloud Storage
- Datos, como objetos de Cloud Storage, registros de BigQuery o archivos
Algunos de estos recursos pueden tener dependencias de otros recursos. Por ejemplo:
- Las aplicaciones pueden acceder a datos, recursos en la nube y otras aplicaciones.
Los recursos en la nube, como las instancias de VM o los segmentos de Cloud Storage, pueden contener aplicaciones o datos.
Como se muestra en el diagrama anterior, las dependencias afectan a la sensibilidad de un recurso. Por ejemplo, si usas una aplicación que accede a datos altamente sensibles, normalmente deberías tratar esa aplicación como altamente sensible. Del mismo modo, si un recurso en la nube, como un segmento de Cloud Storage, contiene datos sensibles, normalmente deberías tratar el segmento como sensible.
Debido a estas dependencias, es mejor que primero evalúe la confidencialidad de sus datos. Una vez que hayas evaluado tus datos, podrás examinar la cadena de dependencias y evaluar la sensibilidad de tus recursos y aplicaciones de Cloud.
Categorizar la sensibilidad de los datos
Para entender la sensibilidad de los datos de tu flujo de implementación, ten en cuenta los tres objetivos siguientes:
- Confidencialidad: debe proteger los datos frente a accesos no autorizados.
- Integridad: debes proteger los datos frente a modificaciones o eliminaciones no autorizadas.
- Disponibilidad: debes asegurarte de que las personas y los sistemas autorizados puedan acceder a los datos de tu canal de implementación.
En relación con cada uno de estos objetivos, pregúntate qué ocurriría si se vulnerara tu canalización:
- Confidencialidad: ¿cuánto daño se causaría si los datos se revelaran a un agente malicioso o se filtraran públicamente?
- Integridad: ¿cuánto daño se produciría si un agente malintencionado modificara o eliminara los datos?
- Disponibilidad: ¿cuánto daño podría causar un agente pernicioso si interrumpiera el acceso a tus datos?
Para que los resultados sean comparables entre los recursos, es útil introducir categorías de seguridad. Estándares de categorización de seguridad (FIPS-199) sugiere usar las cuatro categorías siguientes:
- Alto: los daños serían graves o catastróficos
- Moderado: los daños serían graves
- Bajo: los daños serían limitados
- No aplicable: el estándar no se aplica
En función de tu entorno y contexto, puede que sea más adecuado usar otro conjunto de categorías.
La confidencialidad y la integridad de los datos de la canalización se encuentran en un espectro, en función de las categorías de seguridad que acabamos de analizar. En las siguientes subsecciones se incluyen ejemplos de recursos con diferentes medidas de confidencialidad e integridad:
Recursos con confidencialidad baja, pero integridad baja, media y alta
Todos los ejemplos de recursos siguientes tienen una confidencialidad baja:
- Integridad baja: datos de prueba
- Integridad moderada: contenido del servidor web público y restricciones de políticas de tu organización
- Integridad alta: imágenes de contenedor, imágenes de disco, configuraciones de aplicaciones, políticas de acceso (listas de permitidos y denegados), retenciones y datos de nivel de acceso
Recursos con confidencialidad media, pero con integridad baja, moderada y alta
Todos los ejemplos de recursos siguientes tienen una confidencialidad media:
- Integridad baja: contenido del servidor web interno
- Integridad moderada: registros de auditoría
- Alta integridad: archivos de configuración de aplicaciones
Recursos con alta confidencialidad, pero integridad baja, moderada y alta
Todos los ejemplos de recursos siguientes tienen una confidencialidad alta:
- Baja integridad: datos de uso e información personal identificable
- Integridad moderada: secretos
- Integridad alta: datos financieros, claves de KMS
Categorizar las aplicaciones en función de los datos a los que acceden
Cuando una aplicación accede a datos sensibles, tanto la aplicación como la canalización de implementación que la gestiona también pueden volverse sensibles. Para determinar la sensibilidad, fíjate en 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 accede una aplicación, puedes usar las siguientes categorías para clasificar la aplicación inicialmente antes de diseñar una canalización de implementación segura:
- Confidencialidad: la categoría más alta de todos los datos a los que se accede.
- Integridad: categoría más alta de los datos a los que se accede
- Disponibilidad: la categoría más alta de cualquier dato al que se acceda
Esta evaluación inicial proporciona orientación, pero puede haber otros factores que debas tener en cuenta, como los siguientes:
- Dos conjuntos de datos pueden tener una confidencialidad baja por separado. Pero, combinadas, podrían revelar nuevas estadísticas. Si una aplicación tiene acceso a ambos conjuntos de datos, es posible que tengas que clasificarla como de confidencialidad media o alta.
- Si una aplicación tiene acceso a datos de alta integridad, normalmente deberías clasificarla como de alta integridad. Sin embargo, si ese acceso es de solo lectura, una categorización de alta integridad podría ser demasiado estricta.
Para obtener información detallada sobre un enfoque formalizado para categorizar aplicaciones, consulta la guía para asignar tipos de información y sistemas de información a categorías de seguridad (NIST SP 800-60 Vol. 2 Rev1).
Categorizar los recursos de la nube en función de los datos y las aplicaciones que alojan
Cualquier dato o aplicación que implementes en Google Cloud se aloja en un recurso deGoogle Cloud :
- Una aplicación puede estar alojada en un servicio de App Engine, una instancia de VM o un clúster de GKE.
- Tus datos pueden estar alojados en un disco persistente, un segmento 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 lo gestiona también pueden volverse sensibles. Por ejemplo, debes considerar que un servicio de Cloud Run y su canalización de despliegue son tan sensibles como la aplicación que aloja.
Después de categorizar tus datos y tus aplicaciones, crea una categoría de seguridad inicial para la aplicación. Para ello, determina un nivel de las siguientes categorías:
- Confidencialidad: categoría más alta de cualquier dato o aplicación alojados
- Integridad: la categoría más alta de cualquier dato o aplicación alojados.
- Disponibilidad: categoría más alta de los datos o aplicaciones alojados
Cuando hagas la evaluación inicial, no seas demasiado estricto. Por ejemplo:
- Si encriptas datos altamente confidenciales, trata la clave de encriptado como altamente confidencial. Sin embargo, puedes usar una categoría de seguridad inferior para el recurso que contenga 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 del recurso sea inferior a la categoría de los datos o la aplicación que aloja.
Restringir el uso de los flujos de procesamiento de despliegue
Si tu canalización de implementación necesita acceder a recursos sensibles, Google Cloud debes tener en cuenta su postura de seguridad. Cuanto más sensibles sean los recursos, más te esforzarás por proteger la canalización. Sin embargo, puede que te encuentres con las siguientes limitaciones prácticas:
- Si usas una infraestructura o un sistema de CI/CD que ya tengas, es posible que esa infraestructura limite el nivel de seguridad que puedes alcanzar de forma realista. Por ejemplo, tu sistema de CI/CD solo podría admitir un conjunto limitado de controles de seguridad o podría ejecutarse en una infraestructura que consideres menos segura que algunos de tus entornos de producción.
- Al configurar una nueva infraestructura y sistemas para ejecutar tu canalización de implementación, proteger todos los componentes de forma que cumplan los requisitos de seguridad más estrictos puede no ser rentable.
Para hacer frente a estas limitaciones, puede ser útil definir restricciones sobre los casos en los que se deben usar las canalizaciones de implementación y un sistema de CI/CD concreto. Por ejemplo, las implementaciones más sensibles suelen gestionarse mejor fuera de una canalización de implementación. Estas implementaciones pueden ser manuales, mediante un sistema de gestión de sesiones con privilegios o un sistema de gestión de acceso con privilegios, o de otro tipo, como proxies de herramientas.
Para definir las restricciones, indica qué controles de acceso quieres aplicar en función de las categorías de recursos. Consulta las indicaciones que se ofrecen en la siguiente tabla:
| Categoría del recurso | Controles de acceso |
|---|---|
| Bajo | No se requiere aprobación |
| Moderada | El jefe de equipo debe aprobarlo |
| Alta | Varios responsables deben aprobar las acciones y estas deben registrarse |
Compara estos requisitos con las funciones de tus sistemas de gestión de código fuente (SCM) y CI/CD respondiendo a las siguientes preguntas, entre 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 frente a la subversión si los agentes perniciosos atacan la infraestructura subyacente?
- ¿La configuración que define los controles está protegida adecuadamente?
En función de las funciones y las limitaciones impuestas por tus sistemas de gestión de configuración de software o de integración continua y entrega continua, puedes definir las restricciones de datos y aplicaciones de tus pipelines de implementación. Consulta las directrices que se ofrecen en la siguiente tabla:
| Categoría del recurso | Restricciones |
|---|---|
| Bajo | 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 un jefe de equipo tiene que aprobar cada confirmación e implementación. |
| Alta | No uses flujos de procesamiento de despliegue. En su lugar, los administradores deben usar un sistema de gestión de acceso privilegiado y una grabación de sesiones. |
Mantener la disponibilidad de los recursos
Usar una canalización de implementación para gestionar recursos puede afectar a la disponibilidad de esos recursos y puede introducir nuevos riesgos:
- Provocar interrupciones: una canalización de implementación puede enviar código o archivos de configuración defectuosos, lo que provoca que un sistema que funcionaba correctamente deje de hacerlo o que los datos se vuelvan inutilizables.
- Prolongación de las interrupciones: para solucionar una interrupción, es posible que tengas que volver a ejecutar una canalización de implementación. Si la canalización de implementación no funciona o no está disponible por otros motivos, la interrupción podría prolongarse.
Una canalización que puede provocar o prolongar interrupciones supone un riesgo de denegación de servicio: un agente malintencionado podría usar la canalización de implementación para provocar una interrupción de forma intencionada.
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 ser crucial. En casos extremos, cuando una canalización de implementación es la única forma de gestionar una aplicación esencial para la empresa, también puede que tengas que considerar que la canalización de implementación es esencial para la empresa.
Como las pipelines de implementación suelen estar formadas por 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 creando 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 funciona.
Para crear un procedimiento de acceso de emergencia, normalmente se necesitan la mayoría de los siguientes procesos:
- Mantener una o varias cuentas de usuario con acceso privilegiado a losGoogle Cloud recursos pertinentes.
- Almacena las credenciales de las cuentas de usuario con acceso de emergencia en una ubicación segura o utiliza un sistema de gestión de acceso privilegiado para intermediar el acceso.
- 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 cumplen tus requisitos de disponibilidad
Normalmente, las pipelines de despliegue necesitan descargar el código fuente de un repositorio de código fuente central antes de poder realizar un despliegue. Si el repositorio de código fuente no está disponible, es probable que falle la ejecución de la canalización de despliegue.
Muchas pipelines de implementación también dependen de artefactos de terceros. Estos artefactos pueden incluir bibliotecas de fuentes como npm, Maven Central o la galería NuGet, así como imágenes base de contenedores y paquetes .deb y .rpm. Si una de las fuentes de terceros no está disponible, es posible que no se pueda ejecutar la canalización de implementación.
Para mantener un determinado nivel de disponibilidad, debe asegurarse de que los artefactos de entrada de su canalización de implementación cumplan los mismos requisitos de disponibilidad o unos superiores. La siguiente lista puede ayudarte a asegurar la disponibilidad de los artefactos de entrada:
- Limitar el número de fuentes de artefactos de entrada, especialmente las fuentes de terceros
- Mantener una caché de artefactos de entrada que las canalizaciones de implementación puedan 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 pipelines de implementación suelen servir de tejido conectivo entre los entornos de desarrollo, de staging y de producción. En función del entorno, pueden implementar varias fases:
- En la primera fase, la canalización de implementación actualiza un entorno de desarrollo.
- En la siguiente fase, la canalización de implementación actualiza un entorno de staging.
- En la fase final, la canalización de implementación actualiza el entorno de producción.
Cuando uses una canalización de despliegue en varios entornos, asegúrate de que la canalización cumpla los requisitos de disponibilidad de cada entorno. Como los entornos de producción suelen tener las mayores exigencias de disponibilidad, debes tratar la canalización de implementación y su infraestructura subyacente como un sistema de producción. Es decir, aplica los mismos estándares de control de acceso, seguridad y calidad a la infraestructura que ejecuta tus pipelines de implementación que a tus sistemas de producción.
Limitar el ámbito de los flujos de procesamiento de despliegue
Cuantos más recursos pueda acceder una canalización de implementación, más daños podrá causar si se ve comprometida. Una canalización de implementación vulnerada que tenga acceso a varios proyectos o incluso a toda tu organización podría, en el peor de los casos, causar daños permanentes en todos tus datos y aplicaciones enGoogle Cloud.
Para evitar esta situación, limita el alcance de tus pipelines de implementación. Define el ámbito de cada canalización de implementación para que solo necesite acceso a un número relativamente pequeño de recursos en Google Cloud:
- En lugar de conceder acceso a nivel de proyecto, concede acceso a las canalizaciones de implementación solo a recursos concretos.
- No concedas acceso a recursos de varios proyectos de Google Cloud .
- Divide las pipelines de implementación en varias fases si necesitan acceder a varios proyectos o entornos. A continuación, fija cada fase por separado.
Mantener la confidencialidad
Un flujo de implementación debe mantener la confidencialidad de los datos que gestiona. Uno de los principales riesgos relacionados con la confidencialidad es la filtración de datos.
Hay varias formas en las que un agente malicioso puede intentar usar una canalización de implementación para extraer datos de tus recursos de Google Cloud . Entre estas formas, se incluyen las siguientes:
- Directo: un agente malintencionado puede modificar la canalización de implementación o su configuración para extraer datos de tus recursos de Google Cloudy, a continuación, copiarlos en otro lugar.
- Indirecto: un agente malicioso 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 minimizando el acceso a los recursos confidenciales. Sin embargo, puede que no sea práctico eliminar todo el acceso a los recursos confidenciales. Por lo tanto, debe diseñar su canal de implementación para que cumpla los requisitos de confidencialidad de los recursos que gestiona. Para determinar estas demandas, puedes seguir estos pasos:
- Determina los datos, las aplicaciones y los recursos a los que debe acceder la canalización de implementación y clasifícalos.
- Busca el recurso con la categoría de confidencialidad más alta y úsalo como categoría inicial para la canalización de implementación.
Al igual que ocurre con el proceso de categorización de aplicaciones y 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 contengan información altamente confidencial. Si restringes la canalización de implementación para que pueda crear estos recursos, pero no leerlos, puede que sea suficiente con una categoría de confidencialidad inferior.
Para mantener la confidencialidad, el modelo de Bell-LaPadula sugiere que una canalización de implementación no debe hacer lo siguiente:
- Consumir artefactos de entrada de mayor confidencialidad
- Escribir datos en un recurso con un nivel de confidencialidad inferior
Según el modelo de Bell-LaPadula, el diagrama anterior 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 necesiten
Los flujos de implementación no suelen necesitar acceso a los datos, pero es posible que lo tengan. Este exceso de concesión de acceso puede deberse a lo siguiente:
- Conceder permisos de acceso incorrectos. Por ejemplo, se puede conceder acceso a Cloud Storage a una canalización de implementación a nivel de proyecto. Como resultado, la canalización de implementación puede acceder a todos los segmentos de Cloud Storage del proyecto, aunque podría ser suficiente con acceder a un solo segmento.
- Usar un rol demasiado permisivo. Por ejemplo, se puede conceder a una canalización de despliegue un rol que proporcione acceso completo a Cloud Storage. Sin embargo, sería suficiente con el permiso para crear nuevos contenedores.
Cuantos más datos pueda acceder una canalización, mayor será el riesgo de que alguien o algo robe tus datos. Para minimizar este riesgo, no concedas acceso a las canalizaciones de implementación a ningún dato que no necesiten. Muchos pipelines de implementación no necesitan acceso a los datos, ya que su único propósito es gestionar la configuración o las implementaciones de software.
No permitas que las canalizaciones de implementación escriban en ubicaciones que no necesiten
Para eliminar datos, un agente malintencionado necesita acceso y una forma de transferir los datos fuera de tu entorno. Cuantas más ubicaciones de almacenamiento y de red pueda enviar datos una canalización de implementación, más probable será que un agente malintencionado pueda usar una de esas ubicaciones para la exfiltración.
Puedes reducir el riesgo limitando el número de ubicaciones de red y almacenamiento a las que puede enviar datos una canalización:
- Revoca el acceso de escritura a los recursos que no necesite el flujo de procesamiento, aunque no contengan datos confidenciales.
- Bloquear el acceso a Internet o restringir las conexiones a un conjunto de ubicaciones de red incluidas en una lista de permitidas.
Restringir el acceso saliente es especialmente importante en las canalizaciones que has clasificado como moderadamente confidenciales o altamente confidenciales, ya que tienen acceso a datos confidenciales o a material de claves criptográficas.
Usar Controles de Servicio de VPC para evitar que las implementaciones vulneradas roben datos
En lugar de permitir que la canalización de implementación lleve a cabo la exfiltración de datos, un agente malintencionado podría intentar usarla para implementar código vulnerado. Ese código vulnerado puede robar datos de tu entorno de Google Cloud.
Puedes reducir el riesgo de que se produzcan estas amenazas de robo de datos mediante Controles de Servicio de VPC. Controles de Servicio de VPC te permite restringir el conjunto de recursos y APIs a los que se puede acceder desde determinadosGoogle Cloud proyectos.
Mantener la integridad
Para mantener la seguridad de tu Google Cloud entorno, debes proteger su integridad. Entre los datos que recoge se incluyen los siguientes:
- Impedir la modificación o eliminación no autorizadas de datos o configuraciones
- Impedir que se implemente código o configuración no fiables
- Asegurarse de que todos los cambios dejen un registro de auditoría claro
Los flujos 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)
- Implementa un proceso coherente para todos los cambios de configuración o de código
- Ejecuta pruebas automatizadas o comprobaciones rápidas antes de cada implementación
Para que sean eficaces, debes intentar asegurarte de que los infractores no puedan socavar o eludir estas medidas. Para evitar este tipo de actividad, debes proteger la integridad de lo siguiente:
- El flujo de procesamiento de despliegue 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 despliegue sea vulnerable, intenta asegurarte de que los estándares de integridad de la canalización de despliegue coincidan o superen las exigencias de integridad de los recursos que gestiona. Para determinar estas demandas, puedes seguir estos pasos:
- Determina los datos, las aplicaciones y los recursos a los que debe acceder la canalización de implementación y clasifícalos.
- Busca el recurso con la categoría de integridad más alta y úsalo como categoría de la canalización de implementación.
Para mantener la integridad de la canalización de implementación, el modelo de Biba sugiere lo siguiente:
- La canalización de implementación no debe consumir artefactos de entrada de menor integridad.
- El flujo de procesamiento de la 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 su integridad.
Verificar la autenticidad de los artefactos de entrada
Muchas pipelines de implementación consumen artefactos de fuentes de terceros. Entre los artefactos se incluyen los siguientes:
- Imágenes base de Docker
.rpmo.deb- Bibliotecas de Maven,
.npmo NuGet
Un agente malicioso podría intentar modificar tu canal de implementación para que use versiones vulneradas de artefactos de terceros de las siguientes formas:
- Poner en peligro el repositorio que almacena los artefactos
- Modificar la configuración de la canalización de implementación para usar otro repositorio de origen
- Subir paquetes maliciosos con nombres similares o con errores tipográficos
Muchos gestores de paquetes te permiten verificar la autenticidad de un paquete mediante la firma de código. Por ejemplo, puedes usar PGP para firmar paquetes RPM y Maven. Puedes usar Authenticode para firmar paquetes NuGet.
Puedes usar la firma de código para reducir el riesgo de ser víctima de paquetes de terceros vulnerados de las siguientes formas:
- Exigir que todos los artefactos de terceros estén firmados
- Mantener una lista seleccionada de certificados o claves públicas de editores de confianza
- Permitir que la canalización de implementación verifique la firma de los artefactos de terceros con la lista de editores de confianza
También puedes verificar los hashes de los artefactos. Puedes usar este método para los artefactos que no admiten la firma de código y que cambian con poca frecuencia.
Asegurarse de que la infraestructura subyacente cumple sus requisitos de integridad
En lugar de poner en peligro la propia canalización de implementación, los agentes maliciosos pueden intentar poner en peligro su infraestructura, lo que incluye:
- El software de CI/CD que ejecuta el flujo de procesamiento de despliegue
- Las herramientas que usa la canalización (por ejemplo, Terraform, kubectl o Docker)
- El sistema operativo y todos sus componentes
Como la infraestructura subyacente de las canalizaciones de implementación suele ser compleja y puede contener componentes de varios proveedores o fuentes, este tipo de brecha de seguridad puede ser difícil de detectar.
Puedes reducir el riesgo de que la infraestructura se vea comprometida de las siguientes formas:
- Mantener la infraestructura y todos sus componentes con los mismos estándares de integridad que la canalización de implementación y los Google Cloud recursos que gestiona
- Asegurarse de que las herramientas procedan de una fuente de confianza y verificar su autenticidad
- Reconstruir la infraestructura periódicamente desde cero
- Ejecutar la canalización de despliegue en VMs blindadas
Aplicar controles de integridad en la canalización
Aunque los agentes maliciosos son una amenaza, no son la única fuente posible de software o cambios de configuración que pueden dañar la integridad de tu entorno deGoogle Cloud . Estos cambios también pueden proceder de desarrolladores y ser simplemente accidentales, debido a que no se han dado cuenta o como resultado de errores tipográficos y de otro tipo.
Para reducir el riesgo de aplicar cambios peligrosos por error, puede configurar las canalizaciones de implementación para que apliquen controles de integridad adicionales. Entre estos controles se incluyen los siguientes:
- Realizar análisis estático de código y configuración
- Exigir que todos los cambios cumplan un conjunto de reglas (políticas como código)
- Limitar el número de cambios que se pueden hacer al mismo tiempo
Siguientes pasos
- Consulta nuestras prácticas recomendadas para usar cuentas de servicio en las canalizaciones de implementación.
- Consulta nuestras prácticas recomendadas para proteger cuentas de servicio.
- Consulta más información sobre cómo investigar y responder a amenazas.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.