Del código a la nube: cómo fomentar la resiliencia en todo el proceso de DevOps

DevOps gestiona el código, los flujos de trabajo, la automatización y los metadatos. Cuando estos recursos no están disponibles, los flujos de trabajo de entrega se paralizany las operaciones de la empresa se ven afectadas. 

Las eliminaciones accidentales, las acciones de personas con acceso privilegiado, los errores de configuración, los límites de las API, el ransomware y las interrupciones del servicio en la nube afectan incluso a las organizaciones más consolidadas. 

A menudo carecen de capacidades de retención a largo plazo, protección de metadatos, restauraciones multiplataforma y controles de seguridad de nivel empresarial. 

Al contribuir a proporcionar una protección unificada y nativa de la nube con Recovery granular, restauraciones entre nubes, RBAC, auditabilidad y almacenamiento escalable. 

Las interrupciones retrasan los lanzamientos, merman la productividad, aumentan el riesgo de incumplimiento normativo y dañan la reputación, lo que hace que la resiliencia de DevOps sea esencial. 

Consultaaquíel vídeo para ver la transcripción con marcas de tiempo

…

Hola a todos, bienvenidos a nuestra sesión «Del código a la nube: cómo fomentar la resiliencia en todo el
«proceso de DevOps».

Soy Aashray Agur, director sénior de producto en Commvault.

Este es mi tercer año en Commvault.

Trabajo desde Bangalore, en la India.

En cuanto a mi puesto, trabajo con el equipo de aplicaciones SaaS y soy responsable directo de las soluciones de Salesforce y
DevOps.

En pocas palabras, me encargo de comprender las necesidades del cliente y
diseñar soluciones de software relevantes en este ámbito.

Hoy contamos con Anilkumar, de Oikocredit, como ponente e invitado.

Antes de cederle la palabra, me gustaría hablar un poco sobre Oikocredit.

Oikocredit es una de las mayores cooperativas e inversores de impacto social del mundo.

Fomentan el desarrollo sostenible mediante inversiones en inclusión financiera,
agricultura y energías renovables.

Su sede se encuentra en los Países Bajos.

Y Anil es ingeniero de la nube en

Oikocredit.

Hola, Anil.

Sería estupendo que nos contaras un poco sobre tu puesto y dónde trabajas. Sí,
claro.

Sí, en primer lugar, eh… me llamo Anil.

Trabajo como ingeniero de la nube en Oikocredit, así que estoy destinado en los Países Bajos.

Así que me centro en implementar, colaborar en el diseño y mantener la infraestructura basada
en la nube.

Lo que más me gusta es el proceso de automatización, para que todo vaya más rápido.

En resumen, me encargo de que nuestro entorno en la nube funcione sin problemas, de forma segura y eficiente.

Este es el orden del día de la sesión.

Empezaremos hablando del riesgo creciente en el entorno DevOps; después, comentaremos un poco
por qué es importante la resiliencia y cuáles son las limitaciones de algunas de las soluciones existentes.

A continuación, pasaremos a la demostración.

En los últimos dos años, más o menos, hemos visto cómo algunas de las empresas más prestigiosas del sector
tecnológico

se han enfrentado a problemas inesperados en sus entornos de DevOps.

Por ejemplo, una plataforma de colaboración líder perdió más de 100 repositorios de GitHub.

Un proveedor global de servicios en la nube sufrió un error de configuración que provocó una interrupción en DevOps
en toda una región.

Del mismo modo, una empresa líder del sector de la automoción vio cómo se esfumaban sus principales proyectos en desarrollo.

No se trataba de casos aislados ni de fallos de seguridad.

Le suceden incluso a organizaciones con abundantes recursos y un alto grado de madurez.

La clave es que esta lista no es, en absoluto, exhaustiva.

Si analizamos estas situaciones, vemos que le podrían haber ocurrido a cualquier organización.

Así que lo que debemos reconocer es que los riesgos están aumentando en nuestras herramientas de DevOps.

¿Por qué no se lo preguntamos a alguien que trabaje en ese ámbito? Anil, llevas bastante tiempo gestionando entornos de DevOps
.

Cuando ves incidentes como estos en todo el sector, ¿cómo los interpretas?

¿Y ves que las organizaciones están cada vez más concienciadas sobre la protección de sus entornos de DevOps?
?

Sí, esa es una pregunta muy buena.

Hace unos años, DevOps se consideraba principalmente un flujo de trabajo para desarrolladores.

Pero hoy en día ha evolucionado hasta convertirse en algo mucho más amplio.

Se considera parte de la infraestructura crítica de la empresa.

Así que todo el mundo se centra sobre todo en que los sistemas de producción estén en funcionamiento, pero los sistemas que
Los que crean y distribuyen esas aplicaciones, es decir, el entorno de DevOps, también son fundamentales.

Por eso, cada vez hay una mayor concienciación en todo el mundo

sobre la necesidad de proteger esta capa, no solo frente a amenazas externas, sino también frente a cambios accidentales,
acciones internas o incluso interrupciones en el funcionamiento de la plataforma.

Es estupendo ver que la resiliencia está empezando a integrarse en DevOps desde el principio,
en lugar de ser algo que se añade más tarde.

Esa es una observación excelente.

Profundicemos un poco en

por qué es realmente importante la resiliencia.

Antes incluso de hablar de resiliencia, demos un paso atrás y aclaremos qué significa realmente DevOps
.

Como has dicho antes, en los inicios de DevOps, el desarrollo de software se dividía en dos equipos
: uno se encargaba de escribir el código y el segundo, el equipo de operaciones, tenía como tarea principal

garantizar el buen funcionamiento de los sistemas.

Ahora, DevOps ha

cambiado de verdad la forma en que se lleva a cabo el desarrollo de software.

Ya no hay dos equipos.

Hoy en día, todo transcurre en un ciclo continuo.

Por ejemplo, primero se empieza con un plan.

En la fase de planificación, se reflexiona sobre qué funcionalidades se van a crear y qué nuevas soluciones hay que
desarrollar, etcétera.

Para ello, puedes utilizar una herramienta como Jira, por ejemplo.

Después, una vez planificado, se escribe el código.

Este código se guarda en un repositorio y se almacena en un lugar como

GitHub o GitLab.

Una vez escrito el código, se empaqueta y se publica una versión, a modo de artefacto.

A continuación, compruebas si todo funciona correctamente, implementas tu solución y, después, la supervisas.

Una vez que realizas el seguimiento, surgen los requisitos.

Y, de nuevo, empiezas a planificar.

Verás, es como un bucle sin fin.

Habla con cualquier persona que haya trabajado en el ámbito del desarrollo de software.

Todo el mundo estaría de acuerdo en que esto seguiría así una y otra vez.

Entonces, Anil, ¿por qué crees que DevOps se ha convertido en un elemento tan fundamental para el funcionamiento
de las organizaciones modernas hoy en día, especialmente en lo que se refiere a la agilidad y la innovación?

Sí, creo que no se trata tanto de una organización concreta como de cómo ha
ha transformado la distribución de software en general.

Hoy en día, todo el mundo se centra en la rapidez y la colaboración.

DevOps realmente une las operaciones de desarrollo e incluso

la seguridad, de modo que las ideas puedan pasar del concepto a la producción de forma rápida y fiable.

Así que ya no se trata solo de eficiencia.

Eh… el entorno de DevOps alberga ahora los elementos más críticos, como el código fuente, el flujo de trabajo y
la lógica empresarial, que son, básicamente, la propiedad intelectual de la organización y su

.

Por eso, DevOps ha adquirido un carácter más estratégico.

Ahora las empresas deben innovar, mantener la resiliencia y conservar también una ventaja competitiva.

Exactamente.

La capacidad de actuar con rapidez, automatizar y colaborar entre equipos se ha convertido en una ventaja competitiva
, de eso no hay duda.

Pero también creo que, debido a esta interconexión —«a tanta interconexión»—, un
Tendrá un problema en algún punto

efectos en cadena en todo el proceso.

Por ejemplo, si pierdes tu código, todo lo que dependa de él se verá afectado.

Ya sabes, esos son los riesgos.

Ahora veamos qué riesgos existen hoy en día.

Ya hemos visto en nuestra primera diapositiva algunos ejemplos de lo que han vivido algunas de estas empresas
, ¿verdad?

Solo intento ponerles una etiqueta.

Así que, si se produce un ataque de ransomware, es probable que se cifren tus repositorios.

En el caso de empleados con malas intenciones, un delincuente podría llegar a borrar vuestras configuraciones.

En caso de un error humano, podría ser algo así como que, por ejemplo, vosotros y nuestros desarrolladores de software integraseis un
un montón de herramientas de terceros.

Si la integración falla, todo el sistema se ve afectado.

Así que los riesgos están ahí y están bajo nuestro control.

Anil, desde tu punto de vista, ¿qué pasaría si se interrumpieran estos procesos de DevOps, aunque
fuera brevemente?

Eh… Esa es una pregunta interesante.

Nuestro proceso de DevOps es, básicamente, el sistema que garantiza que las Features y las actualizaciones de
nuestras aplicaciones internas se implementen de forma fluida y segura, de acuerdo con nuestras

.

Así que no se trata solo de implementar código.

Es lo que hace que todo siga avanzando: probar, integrar y publicar los cambios
sin retrasos.

Así que, si el proceso se viera interrumpido, aunque fuera por algo insignificante, eso ralentizaría a varios de nuestros
equipos a la vez.

Eh… Y el impacto no es solo técnico.

Los miembros de nuestro equipo necesitan tener la seguridad de que, hasta ahora, todo funciona según lo previsto.

Eh… Se centra principalmente en resolver el problema y poner las cosas en marcha.

Así que el proyecto…

No pierdas el impulso.

Entendido.

Entendido.

He intentado identificar los riesgos inmediatos.

Por ejemplo, como has dicho, si se pierde algo, habrá retrasos en la implementación.

Si utilizas un ejemplo de prueba, la calidad del producto será deficiente.

Y hoy en día, el código alberga tu propiedad intelectual.

Hoy en día, el código es como el corazón de tus datos.

Si lo utilizas, corres el riesgo de perder tu propiedad intelectual.

Eh…

Más allá del aspecto técnico, ¿qué tipo de impacto empresarial crees que tendría si los datos
de DevOps dejaran de estar disponibles en el contexto, por ejemplo, de nuestros datos corporativos?

Sí, en ese caso, bueno, si los datos de DevOps dejaran de estar disponibles, aunque fuera solo durante unas horas o unos días, el
mayor, eh, impacto se produciría en el progreso.

Así que, cuando el sistema que sustenta la distribución de software se detiene, ralentiza las actualizaciones y
las mejoras de las que depende el equipo.

Por eso la resiliencia y Recovery no son opcionales.

Están integradas en el proceso desde el principio.

Se trata más bien de garantizar que la continuidad forme parte del diseño.

De este modo, aunque algo salga mal, podamos recuperarnos rápidamente y seguir avanzando.

Es decir, no lo habría podido expresar mejor; solo quería añadir algo a lo que has dicho.

Eh… No se trata solo de…

no solo la tasa de pérdida de datos, sino que también se produciría una pérdida de productividad.

Además, podría haber pérdidas de reputación.

Si trabajas en sectores regulados, te enfrentarías a numerosas deficiencias en el cumplimiento normativo.

Por eso, la resiliencia debe integrarse en DevOps desde el diseño, y estoy de acuerdo con la afirmación:
nunca es suficiente, eso es todo.

Bien, hemos establecido que necesitamos resiliencia en DevOps.

Ahora hablemos un poco sobre qué soluciones hay actualmente en el mercado y cuáles son algunas de ellas
de las limitaciones de dichas herramientas.

En cuanto a las soluciones que hay en el mercado, lo que he observado como gestor de productos
es que algunas se basan en herramientas nativas, la denominada «papelera de reciclaje».

Otras lo intentan con scripts, algunos scripts personalizados para, bueno, hacer las copias de seguridad, y luego están
las soluciones puntuales.

Pero,

estas tienen algunas limitaciones importantes.

Antes de hablar como gestor de producto, me gustaría preguntarte, como cliente, ¿por qué crees que
¿Hay algún equipo que siga confiando en estas funciones nativas o en los scripts?

¿Por qué no utilizamos esas soluciones?

Esa es una pregunta muy buena.

Sí, puedo hablar desde mi propia experiencia.

Empezamos utilizando lo que ya venía integrado en la plataforma y otras herramientas disponibles en
el mercado.

Y esas opciones no cubren, eh, la amplia gama de funciones que buscamos.

Cubren lo básico y requieren mucho mantenimiento.

Pero, si lo analizas con más detenimiento, suelen tener, eh, plazos de retención más cortos y no recogen
todo lo que importa, como los procesos, los paneles y los metadatos.

Entendido.

De hecho, esa ha sido mi experiencia al entrevistar a mucha gente.

Eh… los contenedores de reciclaje no lo cubren todo necesariamente.

Ni siquiera los scripts cubren por completo algo como los metadatos.

Una de las principales señales de alarma que se observan, digamos que si utilizas tus scripts, sería
la seguridad.

Además, tus copias de seguridad también se conservan en el mismo entorno.

Y eso es una señal de alarma muy grave.

Eh… Si el entorno de producción deja de funcionar, tu copia de seguridad también deja de funcionar.

Así que no puedes tener una copia de seguridad

el mismo entorno.

Y luego está el problema de la auditabilidad.

Cuando utilizas scripts, no ves qué se ha copiado ni qué se está copiando.

Por último, bueno, la escala empresarial.

Aunque hay scripts, aunque hay soluciones puntuales que ofrecen las tres cosas anteriores,
eh, pero tienen dificultades a gran escala.

Probablemente puedan gestionar cientos de repositorios, pero cuando pasas a miles de repositorios
hasta un terabyte de datos,

se atascan y se colapsan debido a las limitaciones de las API.

Y esa es la razón por la que ni los scripts ni las soluciones puntuales pueden
hacer frente a los requisitos a nivel empresarial.

Y esta es precisamente la brecha que Commvault se propone subsanar desde el primer momento.

Ahora bien, antes de explicar por qué mi propia solución es buena, quiero escuchar a Anil, como

Nuestro cliente, ¿cuál fue tu principal motivo para utilizar la solución de Commvault en primer lugar?
lugar?

Sí, diría que el motivo principal fue la sencillez y la coherencia.

Antes teníamos que hacer malabarismos con diferentes herramientas y políticas para cada entorno, lo que
hacía que la protección resultara compleja y más difícil de gestionar.

Con la copia de seguridad de Commvault para DevOps,

Ahora contamos con un enfoque unificado, un único lugar desde el que supervisar, proteger y recuperar datos en todo el entorno de DevOps.

Y sí, esa coherencia también ha reforzado nuestra seguridad.

Eh… sí, el control de acceso y las políticas de retención se aplican de la misma manera en todas partes, lo que
Además, reduce el riesgo y nos ayuda a cumplir con la normativa sin suponer ninguna carga adicional.

Genial, estoy de acuerdo.

De hecho, una de las primeras cosas que me comentan nuestros clientes es precisamente ese «panel único»
desde el que se pueden proteger todas las cargas de trabajo.

Además de lo que has destacado, me gustaría comentar brevemente dos
puntos muy importantes, ya que están relacionados con mi diapositiva anterior.

Hemos hablado de la escalabilidad, de cómo muchas soluciones del mercado no pueden gestionar configuraciones de gran tamaño.

Esto se debe a los límites de frecuencia de las API.

Cada una de estas plataformas —Azure DevOps, GitHub, GitHub—, ya sabes, estas plataformas limitan la
frecuencia de las copias de seguridad; y me refiero a la frecuencia o al número de llamadas a la API que puedes realizar.

Una vez que se alcanzan esos límites, los trabajos se ralentizan o fallan.

Y lo solucionamos mediante la rotación automática de tokens.

De este modo, las copias de seguridad se ejecutan en paralelo sin llegar nunca a los límites de frecuencia.

Podemos utilizar varios tokens y rotarlos sin problemas.

Además, distribuimos nuestras cargas de trabajo de forma inteligente para que los entornos a gran escala sigan funcionando
sin problemas y sin necesidad de intervención alguna.

Y el siguiente punto que me gustaría mencionar es la restauración multiplataforma.

Como hemos comentado antes, pueden producirse interrupciones en el servicio.

Los principales proveedores también pueden sufrir caídas.

Cuando eso ocurra, para salir del apuro, podrías trasladar tus informes de Azure
De DevOps a GitHub, de GitHub a GitLab, y en cualquier combinación de este tipo;

se consigue una verdadera resiliencia y el trabajo no se detiene.

Y, además de eso, contamos con todas estas funcionalidades estándar, como registros de auditoría detallados
, control de acceso basado en reglas, etcétera.

Y, llegados a este punto, me gustaría aprovechar esta oportunidad para anunciar también que pronto
comenzaremos a ofrecer compatibilidad con Jira.

Comenzaremos nuestro programa de acceso anticipado a partir de diciembre.

Con Jira, hemos entrado en nuestra siguiente fase de desarrollo dentro de DevOps, y estamos muy
ilusionados con nuestra compatibilidad con Jira.

Pasemos al siguiente apartado de nuestra presentación: la demostración del producto.

Esta es nuestra Commvault Cloud Console.

Se trata de un panel único desde el que se pueden proteger prácticamente todas las
cargas de trabajo.

Esta es la página de inicio de nuestra herramienta de DevOps.

Voy a estructurar mi exposición en dos partes.

En la primera parte, hablaré de la página de resumen y de cómo integrar vuestra aplicación.

En la segunda parte, me centraré en la restauración.

La página de resumen te ofrece una

una visión general de las aplicaciones que tienes y de su tamaño.

Por ejemplo, no hemos configurado Jira, por lo que no aparece aquí.

Sin embargo, independientemente de la configuración que se haya establecido, se muestra el tamaño de la copia de seguridad y el número de repositorios que se han protegido.

Esto te da una idea de cuántas copias de seguridad se han realizado y de cuántas instancias aún no se
han copiado.

Así que esto te ofrece una evaluación del estado del sistema.

Ahora veamos rápidamente cómo integrar una aplicación.

Estas son todas las aplicaciones que hemos configurado.

Eh… En resumen, todo esto es lo que has visto en esta… eh… página de resumen.

Ahora vamos a integrar una aplicación.

Haz clic en «Añadir aplicación DevOps».

Eh… Estas son las cuatro aplicaciones que admitimos.

El proceso de registro es bastante similar en todas estas plataformas.

Haz clic en «Siguiente».

El nombre de la aplicación puede ser, eh, lo que sea que

que te permita identificarla fácilmente; puede ser uno de tus nombres de Azure DevOps o cualquier otro que te resulte útil.

Hay dos formas de llevar a cabo la integración.

Si utilizas la configuración rápida, Commvault te proporciona la aplicación.

También puedes utilizar tu propia configuración personalizada.

Esto significa que puedes traer tu propia aplicación y utilizarla también con la configuración rápida.

Añadirla te llevará menos de un minuto.

Veamos cómo funciona.

¡Bingo!

Hemos establecido contacto con esta organización.

Ahora pasemos a Access Node.

Básicamente, tienes que elegir tu región de almacenamiento.

Estamos presentes prácticamente en todas partes.

Digamos que, si estás en EE. UU., verás la región de almacenamiento de EE. UU.; lo mismo ocurre en Europa y
en Asia.

Esto aparecerá automáticamente.

Configura la región.

Y, a continuación, elige un plan.

En la sección «Plan», básicamente puedes

Elige, eh, con qué frecuencia quieres hacer copias de seguridad.

Eh… Ya ofrecemos almacenamiento incluido, y además puedes elegir el periodo de retención.

Por eso ofrecemos almacenamiento ilimitado.

Puedes realizar copias de seguridad con una frecuencia mínima de una vez al día.

Y, por último, el contenido.

Estos son todos los servicios que protegemos.

Si no quieres que se proteja ningún servicio, puedes desmarcarlo.

En cuanto a los proyectos, cuando seleccionas «todos los proyectos», lo que ocurre es que cualquier nuevo
Cualquier proyecto o repositorio que se cree a diario, lo escaneamos y le hacemos una copia de seguridad.

Si, por ejemplo, solo quieres proteger o desmarcar determinadas cargas de trabajo, puedes seleccionar
esta opción.

Dado que el almacenamiento está incluido en la licencia, se recomienda seleccionar todos los proyectos.

Haz clic en «Enviar».

¡Ya está!

Tu instancia ya está creada.

Ahora, bueno… me gustaría volver sobre uno de los puntos en los que insistí mucho en mi presentación,
¿Cómo es la escalabilidad?

¿Por qué muchas soluciones del mercado no están preparadas para la escalabilidad?

Se trata de la compatibilidad con varios tokens.

Hoy en día, ya hemos añadido una aplicación,

que te proporciona un token.

Ahora vamos a añadir más.

Esta es una credencial que ya he creado.

Si quieres más, haz clic aquí.

Lo que esto hace es que, por ejemplo, si alcanzas los límites de tasa de la API con una, automáticamente pasamos
a la segunda y luego a la tercera.

De esta forma, puedes añadir tantas aplicaciones como quieras.

Así que, cada vez que alcances los límites de velocidad de la API, cambiamos y entonces tenemos esto.

Así es como gestionamos la escalabilidad.

Con esto, hemos terminado la parte de la demostración dedicada a la introducción.

Ahora veamos la parte de la restauración.

Volvamos al tema de la organización.

Estas son todas las copias de seguridad que se han realizado.

Verás esta marca de tiempo.

Puedes ir a cualquier fecha y hacer clic en «Restaurar».

Esta es la organización.

Puedes hacer clic en la organización.

Estos son todos los proyectos.

Así pues, la jerarquía es la siguiente: organización, proyectos y repositorios.

Como puedes ver, hay cientos de proyectos.

Puedes acceder a cualquiera de los proyectos y ver qué repositorios hay.

Estos son todos los repositorios que hay.

Ahora bien, si, por ejemplo, quieres restaurar algo.

Haz clic en el botón «Restaurar».

Exacto.

Ahora ofrecemos un nivel de detalle aún mayor.

Supongamos, por ejemplo, que solo quieres restaurar artefactos.

Solo tienes que desmarcarlos.

O quizá solo quieras restaurar los repositorios.

Puedes desmarcar otros servicios.

Así es como abordamos la granularidad.

Y, del mismo modo, la restauración in situ resulta evidente.

Sin embargo, ofrecemos la restauración fuera del sitio e incluso en disco.

Esto es para tu Readiness ante desastres.

Ahora, veamos la restauración fuera de la obra.

También mencioné un factor importante, ¿verdad?

Supongamos que vuestras plataformas también puedan sufrir interrupciones en el servicio.

Cuando eso ocurra, es posible que quieras trasladar tus informes a otras plataformas.

Por ejemplo, a Azure DevOps o GitHub.

Y eso es algo que reconocemos.

Por ejemplo, podrías elegir cualquiera de las aplicaciones configuradas en los ajustes.

Y este es el proceso.

Como ves, haz clic en «Enviar».

Eh… Estos informes se recuperarían sin problemas en tu aplicación.

GitHub y, dicho esto, con esto concluye el… oh.

Para zanjar todo el debate, ¿qué hemos visto?

Afrontemos la realidad: los incidentes cibernéticos no son algo teórico.

Hemos visto cómo las empresas se ven afectadas por ellos a todas horas, así que los riesgos que conllevan están muy claros: la
La brecha entre las herramientas nativas y los scripts «hazlo tú mismo» tiene sus limitaciones, y las soluciones puntuales

no pueden hacer frente a la escala.

Por lo tanto, confiar en ellas no garantizará vuestra ciberresiliencia.

Y también hemos hablado de los riesgos.

Se ha analizado la pérdida de productividad, el daño a la reputación, la pérdida de confianza de los clientes y
otros posibles riesgos.

La solución pasa por contar con una solución de nivel empresarial como Commvault para hacer frente a estos
riesgos y estar preparados.

Así que, para terminar, a aquellas organizaciones

que están empezando a plantearse cómo proteger sus entornos de DevOps: ¿qué consejo
¿Les darías?

Sí, yo empezaría por tratar los datos de DevOps como cualquier otro dato crítico para el negocio.

Otro error habitual es pensar que las herramientas nativas o los scripts rápidos son suficientes, pero
Es posible que solo cubran la Recovery básica.

No están diseñadas para garantizar la seguridad a largo plazo, la escalabilidad ni siquiera el cumplimiento normativo.

Así que lo segundo que quiero mencionar es: apostad por la simplicidad.

Cuanto más fragmentada esté la estrategia de protección, más difícil resulta mantener
la coherencia y la seguridad.

Por eso, deberíamos adoptar un enfoque unificado que incluya visibilidad, automatización e incluso controles de acceso rigurosos
.

Eso marca una gran diferencia en las operaciones diarias de TI.

Un consejo excelente.

Te agradezco mucho tus comentarios.

Antes de despedirnos, utiliza estos códigos QR para descargar nuestro resumen de la solución DevOps e inscribirte
en nuestro taller sobre ciberresiliencia, realizar la evaluación de Readiness cibernética y obtener más información

sobre nuestros programas de acceso anticipado.

Gracias.