Resumen
- Asten Cloud es una empresa francesa de nube y alojamiento en funcionamiento según los registros públicos: el servicio de búsqueda de empresas francés lista ASTEN CLOUD como una empresa activa en Gouesnou dedicada a la gestión de instalaciones informáticas, el propio sitio de Asten describe dos centros de datos en la región de Brest, y los registros de RIPE muestran que ASTEN CLOUD SAS posee recursos de sistema autónomo.
- La evidencia física más sólida es de primera mano pero concreta. Asten afirma que su nube privada se apoya en dos centros de datos franceses, 300 metros cuadrados de espacio de alojamiento en sala blanca, más de 1.000 servidores físicos y virtuales alojados, y una oferta de housing con 48 racks, alimentación y refrigeración redundantes, opción de operador de telecomunicaciones, acceso controlado y acceso al sitio 24/7.
- El panorama de enrutamiento es mixto más que débil. AS199727, en poder de ASTEN CLOUD SAS, es actualmente visible a través de RIPEstat con siete anuncios IPv4 /24 y un IPv6 /31, mientras que AS206308, el ASN denominado “asten-cloud-bretagne”, está registrado pero no anunciado. Por tanto, la señal de la red pública respalda la operación actual de Asten, pero no la simple afirmación de que el ASN con nombre de Bretaña transporta por sí mismo el tráfico de los clientes.
- Las copias de seguridad y la recuperación son más que una nota al pie de marketing aquí. Asten describe copias de seguridad basadas en Commvault en dos centros de datos franceses, retención prolongada, cinta opcional mediante un robot en uno de los centros de datos, pruebas de restauración periódicas, análisis de impacto empresarial y un servicio formal de plan de recuperación. Estas afirmaciones reducen parte del riesgo para el cliente, pero no publican RTO, RPO a nivel de carga de trabajo, resultados de pruebas de conmutación por error ni la capacidad restante tras la pérdida de un centro de datos.
- El grado de evidencia es medio. El registro legal, las páginas de certificación, el enrutamiento activo y las páginas de servicio detalladas hacen que la empresa sea materialmente verificable, pero el registro público aún no expone las direcciones exactas de las instalaciones, la ocupación real de los racks, la separación de rutas de los operadores, la autonomía de los generadores, la distribución de clientes, la profundidad del personal de soporte ni los resultados medidos de recuperación.
La empresa es visible, pero el activo sigue siendo local
La manera útil de entender a asten-cloud-bretagne ASTEN CLOUD SAS no es como una plataforma de hiperescala con regiones abstractas. Es un operador regional francés de alojamiento cuya propuesta de valor pública es precisamente que los sistemas de los clientes permanezcan cerca de Bretaña, de la legislación francesa y de los equipos de soporte de Asten. Elservicio francés de búsqueda de empresasidentifica a ASTEN CLOUD bajo el SIREN 323789990, con una oficina central activa en Gouesnou y un código de actividad de gestión de instalaciones informáticas. La señal del registro es importante porque una página de servicios en la nube sin un anclaje legal puede ser poco más que una fachada comercial. En este caso, la empresa tiene una presencia operativa registrada que coincide con la narrativa de la nube bretona.
La propiapágina de la nube de Astenes inusualmente física para una oferta de nube. Dice que Asten Cloud aloja los datos en su propia infraestructura en Francia, concretamente en Bretaña, y describe dos centros de datos soberanos en la región de Brest, 300 metros cuadrados de espacio de alojamiento en sala blanca y más de 1.000 servidores físicos y virtuales alojados. También presenta el servicio como una nube privada certificada en lugar de un envoltorio de reventa alrededor de una nube pública extranjera. Eso no es prueba de cada carga de trabajo de cliente, pero es una afirmación de activos concreta: salas, racks, servidores y personal operativo deben existir detrás del catálogo de servicios.
Lapágina de historia de la empresaayuda a explicar cómo se desarrolló esa presencia. Asten dice que el grupo se fundó en 1995, compró STTG en 2008, se convirtió en propietario de su primer centro de datos, creó el centro de datos refugio WhiteBox en 2013, compró un nuevo centro de datos en Brest en 2018 para colocation, obtuvo la certificación ISO 27001 en 2019, obtuvo la certificación HDS en 2020 y se convirtió en operador de telecomunicaciones el mismo año. También proporciona indicadores de escala: dos centros de datos en Bretaña, alrededor de 140 expertos, 350 clientes y 16,5 millones de euros de ingresos. Esas cifras son afirmaciones de la propia empresa, por lo que no deben tomarse como una utilización de capacidad auditada, pero hacen que la empresa sea mucho menos opaca que una empresa fantasma.
El área de servicio es nacional en el lenguaje comercial y regional en la lógica de infraestructura. Asten dice que su experiencia se despliega en toda Francia y más allá, pero su argumento de alojamiento se ancla en centros de datos franceses en Finisterre. Lapágina de alojamientodescribe dos centros de datos franceses ubicados en Finisterre y enmarca la oferta como alojamiento soberano para datos que deben permanecer bajo jurisdicción francesa y europea. Para un cliente en Bretaña, un operador cercano puede acortar la ruta de escalamiento y hacer más plausibles las visitas al sitio. Para un cliente fuera de la región, la localización sigue importando, pero la dependencia se desplaza hacia los enlaces de área amplia, el soporte remoto y la resiliencia de las rutas de tránsito y acceso del cliente de Asten.
Esa geografía es la primera limitación operativa. Asten puede vender capacidad de nube como servicio, pero su suministro está ligado a una base de activos regional finita. Dos centros de datos pueden constituir un diseño de resiliencia significativo si son lo suficientemente independientes en términos físicos, eléctricos y operativos. También pueden ser un clúster de destino compartido si ambos sitios dependen del mismo corredor de operadores, equipo de mantenimiento, suministro de combustible, calendario de cambios o inventario de proveedores.
Las páginas públicas demuestran que Asten comercializa dos sitios; no publican un árbol de fallos entre sitios.
Los racks convierten la afirmación de nube en una prueba de capacidad
La página de capacidad pública más específica es laoferta de housing de Asten. Dice que los clientes pueden colocar servidores físicos en centros de datos seguros, elegir entre tercios de rack y racks completos, usar racks de 800 por 1200 milímetros con 48U cada uno, y consumir energía incluida de 1 kVA o 3 kVA según la opción. También afirma que el centro de datos tiene 48 racks, suministro eléctrico asegurado y redundante de 175 kVA, refrigeración redundante, acceso biométrico, códigos digitales, cerraduras, detección y extinción de incendios, vigilancia 24/7 y acceso del cliente las 24 horas. Esos detalles son exactamente el tipo de hechos que convierten la “capacidad alojada” en algo comprobable.
También muestran por qué la capacidad instalada y la capacidad utilizable son diferentes. Cuarenta y ocho racks son una medida de superficie. Ciento setenta y cinco kVA son una medida de capacidad eléctrica. Trescientos metros cuadrados son una medida de sala. Más de 1.000 servidores alojados son una afirmación de inventario o escala de servicio.
Ninguna de esas cifras por sí sola dice a un cliente cuánta capacidad libre queda hoy, cuánta de la planta eléctrica está comprometida, cuánto margen de refrigeración está reservado o qué ocurre si un sitio deja de estar disponible y la capacidad superviviente debe absorber las cargas de trabajo protegidas. Un rack puede estar presente pero lleno. Un SAI puede estar instalado pero limitado por la autonomía de las baterías. Un segundo centro de datos puede existir pero carecer de suficiente capacidad informática de reserva fría para asumir todas las cargas de trabajo de los clientes a la vez.
La página de housing dice que el centro de datos está abierto a diferentes operadores de telecomunicaciones. Es un buen lenguaje para la elección del cliente, porque un único extremo de operador puede convertirse en el punto común oculto en un diseño de alojamiento por lo demás redundante. Sin embargo, “abierto a diferentes operadores” no es lo mismo que nombrar a los operadores activos, las entradas diversas, los conductos separados, las salas de interconexión independientes o la conmutación por error probada.
La dependencia física central de este caso está precisamente aquí: un cliente puede externalizar servidores a Asten y seguir expuesto a la disponibilidad de racks, el plazo de instalación de conexiones cruzadas, el mantenimiento del operador, el fallo del enrutador y la ventana práctica de reparación de un puerto averiado.
Lacartera de alojamiento de Astenabarca housing, alojamiento compartido, alojamiento HDS, alojamiento de aplicaciones y alojamiento de contenedores. Esa amplitud sugiere más de un patrón operativo. Un cliente de housing puede poseer los servidores y pedir a Asten que proporcione espacio, energía, refrigeración, seguridad y acceso a la red. Un cliente de alojamiento compartido puede consumir servidores virtuales en infraestructura propiedad de Asten. Un editor de software puede depender de Asten tanto para el alojamiento como para las operaciones gestionadas. Un cliente de contenedores puede preocuparse más por la orquestación de la plataforma y la disponibilidad del registro que por la disposición física de los racks. La misma interrupción del centro de datos o falla del operador afecta a cada cliente de manera diferente porque la responsabilidad se divide de forma distinta en cada capa.
La tensión económica central es que Asten vende el alivio de construir una sala de ordenadores privada, pero debe financiar la sala compartida que reemplaza muchas salas de clientes. Es un intercambio clásico de economía del alojamiento: los clientes evitan el gasto de capital, el trabajo de cumplimiento y las preocupaciones locales de energía y refrigeración, mientras que el proveedor concentra suficiente demanda para operar salas seguras, operaciones con personal y sistemas redundantes. El proveedor entonces debe evitar la sobreventa de recursos escasos.
La evidencia pública permite a un comprador hacer preguntas incisivas, pero no las responde completamente: la ocupación actual de racks, la energía comprometida frente a la de ráfaga, la redundancia de refrigeración en condiciones máximas de aire exterior, el inventario de servidores de repuesto, los plazos de entrega del hardware de reemplazo y el costo de mantener capacidad de recuperación vacía no están publicados.
La certificación acota la promesa, pero no elimina la maquinaria
Asten se apoya fuertemente en las certificaciones, y las páginas públicas aclaran el alcance más de lo que lo haría una simple insignia. Lapágina de certificacionesdice que Asten Cloud está certificada en ISO 27001 para alojamiento, servicios gestionados y soporte al usuario. También describe la certificación HDS tanto para el alojamiento de infraestructura física como para las actividades de alojamiento gestionado, incluyendo las seis áreas de actividad HDS que cubren sitios físicos, infraestructura hardware, infraestructura virtual, plataformas de aplicaciones, administración/explotación y copias de seguridad externalizadas. Lapágina de alojamiento HDSrepite el marco de los seis dominios y dice que el servicio está dirigido a clientes de salud y médico-sociales y a editores de software.
Esto es importante porque HDS no es solo un eslogan sobre seguridad. Vincula la oferta de alojamiento a cargas de trabajo sensibles donde importan la ubicación, el control de acceso, la trazabilidad, la administración y las copias de seguridad. La página HDS de Asten dice que su alojamiento de datos de salud evita las transferencias de datos personales de salud fuera del Espacio Económico Europeo.
En términos de cliente, se trata de una promesa de localización superpuesta a la operación de las instalaciones: los datos deben residir en centros de datos franceses, bajo protección legal europea, gestionados mediante procesos certificados y respaldados a través de servicios controlados. Si alguna de esas capas se desvía, el valor del servicio cambia.
Sin embargo, la certificación no hace que la capacidad sea infinita ni imposibles las interrupciones. ISO 27001 indica un sistema de gestión de seguridad de la información. HDS indica conformidad para actividades de alojamiento de datos de salud. Ninguna de las páginas publica el tiempo de recuperación por cliente, el número de ingenieros de guardia, el tiempo medio de sustitución de una bandeja de almacenamiento averiada, el calendario de mantenimiento de los conmutadores compartidos, o la distancia geográfica real y la separación de rutas de operador entre los dos centros de datos.
La certificación reduce el riesgo de improvisación; no elimina la dependencia física de la energía, la refrigeración, el hardware, las personas y los enlaces.
La oferta para el sector público añade otra señal de demanda. La página de Asten paracolectividades y establecimientos públicosdice que el grupo fue seleccionado para el lote regional de Bretaña del marco de nube y alojamiento CANUT. Presenta colocation, alojamiento compartido, alojamiento gestionado, copias de seguridad, conectividad y telefonía para entidades públicas. Esto es relevante porque los clientes del sector público a menudo conllevan contratación formal, requisitos de continuidad y preferencias de soberanía de datos. También aumenta el costo de un diseño de recuperación débil: una interrupción podría afectar a un municipio, una escuela, un organismo público o un proveedor de servicios local, no solo a un entorno de pruebas privado.
La conclusión correcta, por tanto, no es ni el cinismo ni la credulidad. Las certificaciones de Asten y su posicionamiento en el sector público son señales significativas, respaldadas por fuentes, de una postura operativa seria. Justifican un mayor nivel de confianza del que sería apropiado para un revendedor de una sola página. Pero no sustituyen la diligencia debida del cliente.
El comprador sigue necesitando la declaración de alcance, las fechas de validez del certificado, los servicios excluidos, la lista de subcontratistas, la ubicación de las copias de seguridad, el proceso de notificación de incidentes y la evidencia de que la carga de trabajo contratada se encuentra dentro del perímetro certificado.
La evidencia de enrutamiento separa la operación de Asten del ASN de Bretaña
El registro de red tiene una distinción extraña pero útil. El ASN que da nombre a este caso, AS206308, está registrado en RIPE comoasten-cloud-bretagne ASTEN CLOUD SAS. La información del titular lo vincula con ASTEN CLOUD SAS y direcciones en Gouesnou y la zona de Brest. Sin embargo, lavista general de RIPEstat para AS206308lo marca como no anunciado, y lapantalla de estado de enrutamientono muestra prefijos IPv4 o IPv6 visibles ni vecinos observados en la fecha de corte de la investigación. Eso no significa que Asten Cloud esté fuera de línea. Significa que el ASN con nombre de Bretaña no es el portador de ruta público en la evidencia de enrutamiento disponible.
La evidencia de enrutamiento activa apunta en cambio a AS199727. RDAP de RIPE listaAS199727como “asten-cloud-idf” bajo ASTEN CLOUD SAS, y lavista general AS de RIPEstatlo marca como anunciado. Suresultado de estado de enrutamientomuestra visibilidad IPv4 completa a través de los peers RIPE RIS y visibilidad IPv6 sustancial. Elresultado de prefijos anunciadosmuestra siete /24 IPv4 y un /31 IPv6 visibles en la ventana de observación actual, mientras que losdatos de vecinos ASNmuestran dos vecinos observados: AS174 y AS12645.
Estos dos hechos deben considerarse conjuntamente. Por un lado, Asten tiene infraestructura enrutada activa. Por otro, el ASN cuyo nombre contiene “bretagne” está silencioso. Un artículo simple podría eliminar esa distinción y decir “Asten Cloud tiene un ASN”. Una lectura de infraestructura más informada pregunta por qué el ASN regional con nombre está registrado pero no visible, si está reservado para un diseño que actualmente no se utiliza, si el tráfico de los clientes se encuentra detrás de AS199727 y si la disposición de dos ASN refleja elecciones de sitio, legado, producto o ingeniería de tráfico.
Los colectores de rutas públicos no responden a esa pregunta.
Los nombres de los prefijos también insinúan funciones de servicio sin probar la ubicación del cliente. RDAP de RIPE identifica185.189.172.0/24como “HEBERGEMENT”,185.189.173.0/24como “HEBERGEMENT_SEC2”,185.189.174.0/24como “HEBERGEMENT_SEC”,185.37.43.0/24como “HEBEGEMENT-SEC”,185.37.41.0/24como “K8S”, y185.37.42.0/24como “HORS-VDOM-INTERNET”. Estas etiquetas son pistas públicas útiles: alojamiento, alojamiento seguro y denominaciones tipo Kubernetes aparecen en el espacio de direcciones controlado por Asten. No revelan la sala de datos, el inquilino del cliente, la VLAN, la zona de cortafuegos ni el nivel de resiliencia detrás de ninguna IP en particular.
El riesgo de dependencia de rutas no es, por tanto, si Asten puede ser visto en Internet. Se puede ver. El riesgo es si los clientes conocen el arreglo real de tránsito, ruta y conmutación por error utilizado por su carga de trabajo. Dos vecinos de enrutamiento observados son mejores que uno, pero la diversidad de vecinos BGP no es lo mismo que la diversidad de rutas de fibra. Dos sesiones pueden aún compartir un conducto, una entrada de edificio, un enrutador, una ventana de mantenimiento o una dependencia comercial.
Un cliente de alta disponibilidad debería preguntar por los nombres de los operadores, las ubicaciones de transferencia, la diversidad de rutas, la política de conmutación por error, los plazos de notificación de mantenimiento, la gestión de DDoS, la postura RPKI/IRR y la evidencia de un ejercicio de conmutación por error reciente.
Las copias de seguridad reducen el riesgo de pérdida de datos, pero la recuperación sigue teniendo un reloj
Lapágina de copias de seguridad y recuperación de Astenes una de las más sólidas del conjunto de evidencia porque menciona tanto el mecanismo como el pensamiento ante fallos. Dice que Asten Backup utiliza Commvault, almacena las copias en dos centros de datos franceses, ofrece retención prolongada personalizable, puede añadir copias de seguridad en cinta mediante un robot en uno de los centros de datos, y emplea conceptos de copia de seguridad desconectada o aislada para resistir ciberataques. También dice que la oferta incluye pruebas de restauración periódicas en un entorno aislado, servicios de plan de recuperación, análisis de impacto empresarial y un plan de recuperación escrito dirigido por expertos en seguridad.
Es un buen punto de partida para la tarea de redundancia. La copia de seguridad no es meramente otro volumen de almacenamiento junto a producción; Asten describe múltiples medios, lógica fuera de sitio, pruebas de restauración y planificación de recuperación. La capa de cinta opcional es especialmente relevante para el ransomware, porque una réplica en línea puede replicar fielmente la corrupción, el cifrado o el borrado. La retención prolongada ayuda cuando un compromiso se descubre semanas o meses después de la primera intrusión.
Las pruebas de restauración importan porque una copia que no se puede restaurar no es una capacidad de recuperación.
La brecha restante es el reloj del servicio. La página no publica objetivos de RPO o RTO predeterminados para cada clase de carga de trabajo. No indica cuántas restauraciones simultáneas de clientes pueden ejecutarse durante un incidente regional, cómo se limita la tasa del tráfico de copias de seguridad, si los repositorios de copias comparten el mismo proveedor de almacenamiento que producción, o si el robot de cintas protege a todos los clientes o solo a aquellos que compran la opción. Tampoco explica cómo se prioriza una restauración si muchos clientes llaman durante la misma interrupción.
Un cliente puede creer que “copia de seguridad en dos centros de datos” significa continuidad rápida; el resultado real depende del alcance del contrato, la automatización, el rendimiento de la red, la capacidad de la sala blanca, la disponibilidad del personal y las dependencias de las aplicaciones.
La diferencia entre protección de datos y continuidad del servicio es fácil de pasar por alto. Si un servidor físico falla, una copia de seguridad puede restaurar los datos, pero no el entorno de cómputo exacto, el estado de las licencias, las reglas de cortafuegos, la configuración DNS o las dependencias de la aplicación. Si un centro de datos deja de estar disponible, una copia en un segundo sitio puede preservar los datos, pero aún se requiere cómputo, almacenamiento, alcanzabilidad IP y secuenciación de aplicaciones antes de que los usuarios regresen.
Si un ciberataque compromete los sistemas de identidad, los datos de respaldo pueden existir, pero el acceso privilegiado y las decisiones de confianza se convierten en el cuello de botella. Un plan de recuperación resiliente debe coreografiar personas y dependencias, no solo copiar bloques.
El catálogo de servicios de Asten reconoce parte de esto al combinar las copias de seguridad con servicios gestionados y planificación de recuperación. La tarea de verificación del comprador es convertir el catálogo en evidencia: fecha de la última prueba de restauración exitosa, lista de cargas de trabajo probadas, duración medida de la restauración, mapa de dependencias, recuperación de autenticación, pasos de conmutación de red, validación posterior a la restauración y un responsable designado para la declaración de emergencia. La página pública respalda la afirmación de que la recuperación forma parte de la oferta de Asten.
No permite a terceros calcular la rapidez con que regresa un cliente en particular.
La mano de obra de soporte es también un recurso de capacidad
Los fallos de la nube a menudo se describen como eventos técnicos, pero la reparación la realizan personas. Lapágina de servicios gestionados de Astendice que su oferta puede cubrir la infraestructura del cliente en sus instalaciones, en el centro de datos de Asten o en plataformas compartidas. Describe sistemas de supervisión, monitorización continua, alertas en tiempo real, corrección de alertas, actualizaciones de seguridad y parches de emergencia para vulnerabilidades críticas. También dice que el servicio puede combinar soporte in situ con recursos externalizados alojados en los servidores de Asten. Esta es la capa operativa que convierte una sala de servidores en un servicio gestionado.
Lapágina de contrato de soporteañade un detalle más mundano pero importante: las solicitudes fuera del ámbito de los servicios gestionados pueden gestionarse a través de un contrato de soporte basado en puntos, con técnicos de nivel 1 que escalan a ingenieros y expertos de nivel 2 y 3. Esto es relevante en una ruta de fallo porque no todas las interrupciones comienzan dentro del núcleo de Asten. Un cambio de aplicación de un cliente, la expiración de un certificado, una solicitud de cortafuegos, una tarea de configuración menor o una intervención hardware pueden situarse en el límite entre las operaciones incluidas y el soporte de pago. Si ese límite no está claro durante una interrupción, la reparación se ralentiza.
La mano de obra de soporte tiene el mismo problema de utilización que los racks. La página de historia de Asten dice que el grupo cuenta con alrededor de 140 expertos, pero el registro público no desglosa esa cifra por operaciones en la nube, seguridad, trabajo de campo, mesa de ayuda, especialistas en aplicaciones, gerentes o funciones administrativas. Un día normal puede contar con suficiente personal para alertas, cambios planificados y tickets de clientes. Un incidente simultáneo en alojamiento, copias de seguridad, red y sistemas de clientes puede consumir especialistas más rápido de lo que el centro de datos consume energía.
Por lo tanto, los clientes deben tratar el soporte como un recurso contratado. La cuestión no es solo “¿está disponible el soporte?”. Es si el contrato define los tiempos de respuesta, los activadores de escalamiento, los niveles de gravedad, la cobertura de guardia, las congelaciones de cambios, las ventanas de mantenimiento de emergencia, las responsabilidades del cliente y el derecho a solicitar evidencia tras un incidente. Las páginas públicas de Asten respaldan una expectativa de operaciones gestionadas y soporte multinivel. No publican la profundidad exacta de la cola ni el plan de personal que hay detrás de esa expectativa.
Esto es especialmente importante para los organismos públicos y las cargas de trabajo vinculadas a la salud. La página HDS de Asten describe vigilancia 24/7 e intervención rápida para entornos de datos de salud. Un municipio o un editor de software sanitario puede necesitar más que una respuesta a un ticket; puede necesitar un puente de incidentes documentado, un orden de restauración prioritario, soporte para notificaciones de privacidad y prueba de que los datos permanecen dentro del perímetro de alojamiento aprobado durante los trabajos de emergencia.
El lenguaje de marketing público apunta en esa dirección, pero solo el contrato y los manuales operativos mostrarían si es aplicable operativamente.
La soberanía es un límite operativo, no una etiqueta decorativa
La principal reivindicación de mercado de Asten es la localidad. La página principal de la nube dice que los datos se alojan en la infraestructura propia de Asten en Francia, en Bretaña, sin nube estadounidense y sin subcontratación en esa afirmación de nube. La página de alojamiento dice que la nube es soberana y está sujeta a la legislación francesa y europea. La página HDS dice que los datos de salud no se transfieren fuera del Espacio Económico Europeo. La página del sector público presenta la misma lógica a los establecimientos públicos bretones.
Estas afirmaciones hacen de la soberanía de los datos y la localidad uno de los temas controlados correctos para el artículo.
Pero soberanía no es lo mismo que simplicidad. Una nube local sigue teniendo proveedores de hardware, vendedores de software, operadores de telecomunicaciones, tecnologías de copia de seguridad, productos de seguridad y redes de acceso de clientes. La página de servicios gestionados de Asten dice que, para los requisitos de SecNumCloud, confía en OUTSCALE, una marca de Dassault Systèmes, en un enfoque soberano híbrido. Puede ser un diseño sensato para los clientes que requieren una opción de nube soberana cualificada.
También significa que un comprador debe preguntar qué cargas de trabajo se ejecutan en los centros de datos bretones propios de Asten, cuáles en un entorno OUTSCALE, qué datos se mueven entre ellos y qué controles contractuales se aplican en cada punto.
Esta distinción no es una crítica; es la definición práctica de la localidad. Si un cliente compra alojamiento ordinario, el activo esperado puede ser la infraestructura de Asten en la región de Brest. Si un cliente compra un servicio soberano híbrido, el límite del activo puede incluir las instalaciones del cliente gestionadas por Asten, los centros de datos de Asten y los recursos de OUTSCALE. Si un cliente compra copias de seguridad para datos de Microsoft 365, el servicio de producción puede permanecer en el entorno de Microsoft mientras las copias de seguridad residen en los centros de datos franceses de Asten.
La palabra “soberano” no puede evaluarse hasta que se dibuja la ruta real del servicio.
Lo mismo ocurre con la jurisdicción legal. Los datos almacenados en Francia bajo normativa francesa y europea constituyen una protección significativa, pero el acceso operativo sigue dependiendo de los administradores, los proveedores de soporte, los sistemas de monitorización, la gestión de claves de cifrado y los procedimientos de emergencia. Las páginas HDS e ISO de Asten respaldan la opinión de que estos procesos se gestionan bajo marcos formales de seguridad.
No muestran qué registros se conservan, dónde se guardan las claves, cómo se autentican los administradores de los clientes ni cómo se restringe el soporte transfronterizo de proveedores.
Por tanto, una buena revisión del cliente debería tratar la soberanía como un conjunto de puntos de prueba prácticos en lugar de un eslogan. ¿Dónde se almacenan los datos de producción? ¿Dónde se almacenan las copias de seguridad? ¿Dónde se almacenan los registros de monitorización? ¿Quién puede acceder a cada capa? ¿Están las claves de cifrado controladas por el cliente, por el proveedor o son compartidas? ¿Qué ocurre cuando el hardware se devuelve, repara o destruye? ¿Qué subcontratistas pueden tocar los datos o metadatos?
La evidencia pública convierte a Asten en un proveedor local creíble; el contrato debe demostrar aún que la carga de trabajo real del cliente sigue la ruta local.
Las rutas de fallo convergen en cinco cuellos de botella prácticos
La primera ruta de fallo es un problema de rack o de inventario de hardware. Los clientes de housing pueden poseer el equipo, pero Asten sigue proporcionando la sala, el rack, la energía, la refrigeración, el acceso y posiblemente la intervención manual. Un cliente de alojamiento compartido depende más directamente del inventario de servidores y del stock de reemplazo de Asten. La cifra de 48 racks de la página de housing ofrece un límite de capacidad visible.
Un fallo de hardware en el servidor de un cliente es limitado; un fallo en la refrigeración, la distribución eléctrica, la matriz de almacenamiento o un conmutador compartido puede amplificarse rápidamente. La recuperación depende de las piezas de repuesto, el soporte del proveedor, la disponibilidad de manos remotas y la capacidad del cliente para aprobar cambios.
La segunda ruta de fallo es la energía. La página de housing dice que el centro de datos tiene un suministro eléctrico asegurado, respaldado por SAI y redundante de 175 kVA, con generadores detrás de la transición. Ese lenguaje respalda una afirmación de resiliencia eléctrica a nivel de instalación. No publica la autonomía de las baterías, la autonomía de combustible del generador, el programa de mantenimiento, los resultados de las pruebas de carga, la topología de la cadena de energía ni cuánto margen queda cuando los racks están cargados.
Si Asten vende tanto alojamiento de producción como de recuperación en el mismo envolvente de energía, el margen disponible tras un fallo del sitio se convierte en una cuestión económica y técnica.
La tercera ruta de fallo es un fallo de tránsito o de ruta. RIPEstat ve AS199727 como activo y AS206308 como inactivo. Si el tráfico de los clientes depende de AS199727, importan su diversidad de tránsito y sus rutas físicas. Si algún producto utiliza una transferencia de operador que no es visible en el BGP público, la diligencia debida del cliente debe ir más allá de las páginas de ASN. Un prefijo visible puede desaparecer por un fallo del enrutador, un error de política de rutas, mantenimiento, un problema de mitigación de DDoS, una interrupción del operador o una disputa comercial.
Un cliente de nube siente todo eso como tiempo de inactividad de la aplicación incluso si todos los servidores permanecen en buen estado.
La cuarta ruta de fallo es el escalado del soporte. Asten describe supervisión, corrección de alertas, parches de seguridad y niveles de soporte. Durante un evento grave, el cuello de botella puede ser el número de especialistas que pueden tocar de forma segura cortafuegos, hipervisores, almacenamiento, copias de seguridad, DNS, identidad y aplicaciones del cliente. Si los clientes del sector público o de salud reciben prioridad, el orden de prioridad debe ser explícito.
Si un contrato de soporte basado en puntos cubre trabajos fuera de alcance, la política de emergencia debe decir si la contabilidad de puntos se pausa durante los incidentes o continúa como de costumbre.
La quinta ruta de fallo es la migración y la portabilidad. La propuesta de valor de Asten pide a los clientes que trasladen sus datos y sistemas a sus centros de datos o entornos gestionados. Salir más tarde puede requerir exportar máquinas virtuales, bases de datos, copias de seguridad, reglas de cortafuegos, zonas DNS, secretos de aplicación, historial de monitorización y documentación de acceso. Las páginas públicas de Asten enfatizan la protección, la continuidad y la ubicación francesa. No publican formatos de salida estándar, tarifas de exportación masiva, plazos de migración ni soporte para la repatriación de emergencia.
Un cliente debería resolver esas cuestiones antes de un fallo en el contrato con el proveedor, no durante el mismo.
Quién se ve afectado cuando este sistema falla
Las partes afectadas son más amplias de lo que implica la palabra “cliente”. Un cliente de housing puede ser una empresa local que colocó sus propios servidores en racks de Asten para evitar tener una sala privada. Un cliente de alojamiento compartido puede ser una pequeña o mediana empresa cuyos sistemas de contabilidad, pedidos, identidad o colaboración se ejecutan en servidores gestionados por Asten. Un editor de software puede utilizar el alojamiento de Asten para servir a sus propios clientes, convirtiendo un incidente de Asten en una interrupción de la aplicación en cascada.
Un organismo público que utiliza la oferta vinculada a CANUT puede depender de Asten para servicios de cara al ciudadano o administrativos. Un actor de salud o médico-social que utiliza alojamiento HDS puede tener obligaciones de disponibilidad y confidencialidad de los datos de los pacientes.
El impacto también difiere según el tipo de fallo. Una breve oscilación del operador puede cortar el acceso web sin dañar los datos. Un fallo de almacenamiento puede dejar las aplicaciones en línea pero inconsistentes. Un fallo en las copias de seguridad puede ser invisible hasta que se necesita una restauración. Un atasco en el soporte puede convertir un incidente manejable en una interrupción prolongada. Una ventana de mantenimiento de las instalaciones puede ser aceptable para sistemas por lotes, pero inaceptable para un portal de servicios públicos, un sistema de programación de clínicas o un minorista durante las horas punta.
La postura más sólida del cliente es mapear las dependencias antes de firmar o renovar. ¿Qué servicios son críticos para la producción? ¿Cuáles se ejecutan en los centros de datos de Asten, en las instalaciones del cliente o en un entorno híbrido? ¿Cuáles tienen copias de seguridad en el segundo centro de datos? ¿Cuáles tienen restauraciones probadas? ¿Cuáles requieren direcciones IP fijas, VPN, reglas de cortafuegos o cambios de DNS durante la recuperación? ¿Qué usuarios llamarán directamente a Asten y cuáles deben llamar a la mesa de servicio del cliente?
Estas preguntas suenan procedimentales, pero deciden si una promesa de recuperación se convierte en un plan utilizable.
La evidencia pública de Asten es lo suficientemente detallada como para que los clientes hagan esas preguntas con precisión. Un proveedor de nube vago puede desviarse con abstracciones. Asten ha publicado suficiente sobre racks, centros de datos, copias de seguridad, alcance HDS, soporte y enrutamiento para que los compradores pongan a prueba la afirmación. Las piezas que faltan no son señales de que el servicio no sea serio; son los detalles operativos privados que un comprador serio debería solicitar.
La prueba del comprador es un mapa de dependencias
El ejercicio más útil para el cliente es convertir las afirmaciones públicas de Asten en un mapa de dependencias para el sistema específico que se está trasladando o protegiendo. Empiece por el servicio de negocio, no por la máquina virtual. Un portal municipal puede depender de un front-end web, un almacén de contenidos, identidad, DNS, correo, un conector de pago y un contacto de mesa de ayuda.
Una aplicación de salud puede depender del alojamiento HDS, copias de seguridad cifradas, federación de identidades, registros de auditoría, acceso VPN y un proveedor que pueda dar soporte a la aplicación después de que Asten restaure la plataforma base. Un minorista puede depender de una base de datos de punto de venta, un sistema de stock, terminales de pago, acceso a Internet desde las tiendas e integraciones nocturnas. Cada servicio tiene un punto de ruptura diferente.
Para cada dependencia, el comprador debe preguntar si Asten es propietaria de la capa, la gestiona, simplemente la aloja o no tiene control sobre ella. Esta distinción es central en el título del artículo. La capacidad alojada puede fallar porque falle la propia infraestructura de Asten. También puede fallar porque el servidor de un cliente esté fuera de garantía, una aplicación de un tercero no se pueda reconstruir, un proveedor de fibra no cumpla el plazo de reparación, un registrador de dominios bloquee un cambio de DNS o un incidente de seguridad oblige a tomar una decisión de confianza manual.
Asten puede ser el socio adecuado en cada caso, pero el contrato debe hacer visible el límite antes del incidente.
El mapa también debe separar el soporte normal de la autoridad de emergencia. Durante la operación rutinaria, un cliente puede solicitar un cambio de cortafuegos, una ampliación de almacenamiento o una restauración a través de una vía de tickets. Durante un incidente grave, el mismo cliente puede necesitar una persona designada que pueda aprobar una declaración de recuperación, autorizar una conmutación de DNS, aceptar un rendimiento degradado, pausar los servicios no esenciales y comunicarse con los usuarios.
La página de soporte de Asten muestra una disposición de soporte estructurada, pero el comprador aún necesita nombres, roles, tiempos de escalado y definiciones de gravedad. Un plan de recuperación sin autoridad de decisión es solo un inventario.
La localidad de los datos debe aparecer en el mismo mapa. Si la producción se ejecuta en los centros de datos bretones de Asten, las copias de seguridad residen en dos centros de datos franceses y un servicio relacionado con SecNumCloud utiliza OUTSCALE bajo gestión de Asten, entonces hay tres afirmaciones de localidad diferentes. Cada una merece una línea separada: dónde reside la producción, dónde residen las copias de seguridad, dónde residen los registros, desde dónde se conectan los administradores, dónde se guardan las claves de cifrado y dónde pueden crearse copias de emergencia.
Cuanto más sólida se vuelve la narrativa de soberanía de Asten, más importante es demostrar que todos los componentes del servicio real siguen la misma política.
El mapa de dependencias debe incluir la capacidad después de un fallo, no solo la capacidad en un día normal. Un diseño de dos sitios puede ser excelente si cualquiera de los dos tiene suficiente capacidad informática, de almacenamiento, de licencias y de red de sobra para soportar los servicios protegidos. Puede ser más débil si el segundo sitio está diseñado principalmente para almacenamiento de copias de seguridad, cargas de trabajo críticas seleccionadas o una recuperación más lenta.
La página pública de copias de seguridad de Asten menciona pruebas de restauración periódicas y un segundo centro de datos; el contrato debe decir si se espera que el entorno del cliente se ejecute allí, cuánto tarda el traslado, cuánto rendimiento está reservado y qué otros clientes compiten por el mismo fondo de emergencia.
Por último, el comprador debe exigir una ruta de salida. No es una postura hostil; es parte de la resiliencia. Un cliente que no puede abandonar un proveedor durante una disputa comercial, un cambio estratégico o una interrupción persistente no ha reducido la dependencia, la ha concentrado. Para Asten, la prueba de salida debería cubrir la exportación de máquinas virtuales, la exportación de copias de seguridad, los volcados de bases de datos, las claves de cifrado, la configuración de cortafuegos y VPN, los cambios de IP pública, las zonas DNS, la documentación de soporte y la evidencia de eliminación tras la salida.
Un servicio que está genuinamente bien gestionado debería ser capaz de describir cómo un cliente entra, sobrevive a un incidente y sale sin perder el control de sus datos.
Qué mejoraría la evidencia
El registro público respalda hoy una evaluación de confianza media. Sería más sólido si Asten publicara o compartiera evidencia segura para el cliente del diseño de dos sitios: separación de sitios no sensible, diversidad de operadores, rutas de energía independientes, resultados probados de conmutación por error, métricas de restauración de copias de seguridad, bandas de RTO/RPO, procedimientos de escalado de emergencia y soporte de salida estándar. También ayudaría explicar el papel de AS206308 en relación con AS199727.
Si el ASN con nombre de Bretaña está reservado, es histórico o se usa solo en acuerdos privados, decirlo evitaría que los observadores externos malinterpreten su estado público inactivo.
Para un cliente, la solicitud de evidencia debe ser concreta. Pida el alcance más reciente de los certificados ISO y HDS, la matriz de servicios que muestra qué ofertas están incluidas, la declaración de ubicación de datos para producción y copias de seguridad, la lista de subcontratistas que pueden afectar al servicio y las responsabilidades del cliente durante una recuperación. Pregunte cuántas rutas de operador entran en cada sitio y si son físicamente diversas. Pregunte cómo se programan las pruebas de copias de seguridad, cómo se notifican los fallos y si el cliente puede presenciar o recibir el resultado.
Pregunte qué ocurre si se pierde un centro de datos durante una semana, no solo por una hora.
Lo mismo ocurre con el costo. La economía del alojamiento de Asten depende de la infraestructura compartida, por lo que puede resultar atractiva para los clientes que no quieren construir su propia sala segura. Pero la resiliencia consume capacidad reservada. Un servicio barato sin margen de recuperación reservado no equivale a un servicio más caro con conmutación por error probada y cómputo de reserva. Los compradores deberían separar el alojamiento base, las copias de seguridad, el PRA, las operaciones gestionadas, los puntos de soporte y la asistencia a la migración en lugar de asumir que están empaquetados.
El juicio final es que la capacidad de Asten Cloud es lo suficientemente real como para ser examinada. Sus materiales públicos no parecen los de un proveedor desaparecido o un mero intermediario. Muestran una empresa francesa legal, afirmaciones sobre centros de datos bretones, alcance de certificación, espacio de direcciones enrutado activo, productos de alojamiento, herramientas de copias de seguridad y orientación al sector público. La cautela del artículo es más concreta: la dependencia operativa del cliente no se resuelve con la palabra nube.
Se traslada a los racks de Asten, la planta eléctrica, las elecciones de rutas, los repositorios de copias de seguridad, la cola de soporte y los contratos de recuperación. Esa es una proposición de infraestructura respetable solo si esas dependencias físicas y contractuales se miden antes del fallo, no se descubren durante la ventana de reparación.