Contener: MDM, SDK y actualización

Contener es reducir el daño que sigue ocurriendo, y cada hora de espera son más datos fuera. Por eso el orden lo marca el plazo: primero lo que se puede cambiar de inmediato sin esperar a nadie (reglas de la consola de MDM y el interruptor remoto), después la versión corregida, y por último exigirla como mínima para que quien no actualiza deje de poder usar la versión mala. Esperar a la versión nueva antes de cortar nada deja abierta la salida durante días, que es lo que cuesta compilar y publicar.

La contención no sustituye a la corrección: la versión sin el componente sigue siendo el cierre. Es la parte rápida del plan.

Una consola de MDM guarda sus reglas por aplicación y por ámbito, cada una con un valor actual. Para parar un envío sin esperar a una versión nueva hay que encontrar la regla que limita los destinos de red a los que puede llegar la app y comprobar si hoy hace algo. Ojo con las reglas parecidas: la versión mínima exige actualizar, y no corta nada mientras el dispositivo cumpla.

Lee las políticas vigentes y localiza la regla que, una vez rellenada, bloquearía el dominio del tercero en los dispositivos gestionados.

El hallazgo de la traza fue que el envío ocurría con la medición rechazada. Esa conducta tiene que venir de algún sitio de la compilación: en una librería de medición suele haber un conjunto de ajustes que decide si respeta o no la elección de la persona. La diferencia entre la compilación vieja y la nueva, línea a línea, enseña cuál era el ajuste que explicaba el defecto.

Lee los cambios de la compilación y anota el ajuste del componente que hacía enviar a quien había rechazado.

Ingeniería propone una corrección mínima: publicar una versión que solo ponga ese ajuste en falso y deje el componente dentro. Suena razonable y deja la puerta abierta: el componente sigue ahí, con su identificador publicitario y su destino, sin que nadie lo haya pedido ni la declaración lo cubra, y un cambio de configuración remota o de versión puede volver a activarlo. La corrección que cierra es retirar lo que no tiene dueño ni base declarada. Rotar o retirar la clave del proyecto corta la relación con la cuenta, pero no borra lo que el tercero ya recibió.

El criterio es el mismo de toda la ruta: lo que de verdad protege es que el dato no salga, no que un interruptor lo permita menos.

Un plan de contención solo es creíble si se ve de qué depende cada acción. Las que se hacen dentro de la empresa tienen plazos que controla el equipo; las que pasan por un tercero —la revisión del canal de publicación, el borrado del tercero— tienen plazos que no controla nadie de Rucamilla. Marcar esas dependencias es lo que permite avisar a la dirección de que la corrección tardará lo que tarde la revisión, y de que mientras tanto la contención inmediata sostiene el caso.

Revisa el plan y busca la acción que no puede avanzar hasta que alguien ajeno apruebe.