Ne dites plus Cameyo, mais Cameyo by Google.

En parallèle de ce changement de marque, la communication autour du produit évolue. Elle se porte plus sensiblement sur les intégrations avec l’écosystème Chrome.

En la matière, on ne partait pas de zéro. Mi-2024, lorsque Google avait annoncé acquérir Cameyo, des jonctions étaient déjà en place. Essentiellement vis-à-vis de ChromeOS (intégration avec le système de fichiers local, gestion du presse-papiers, livraison d’apps en tant que PWA…).

Est désormais mise en avant l’idée d’expérience unifiée au sein de Chrome Enterprise. Les applications client lourd virtualisées avec Cameyo bénéficieraient, d’un côté, du même contexte de sécurité que le SaaS (filtrage d’URL, DLP, protection contre les menaces…). Et de l’autre, de la même couche IA, à travers l’assistant Gemini for Chrome.

La virtualisation Linux, moins mise en avant sous l’ère Google

À l’exception de quelques renvois vers chez Google, le site Internet de Cameyo est demeuré tel qu’il était avant l’acquisition.

Parmi les promesses d’alors, il y avait celle de pouvoir virtualiser des applications Linux et des web apps internes sans avoir besoin d’une licence Windows Server.

Dans le giron de Google, cette possibilité n’est pas exclue, mais elle est nettement moins mise en avant, jusque dans l’assistance en ligne.

Le modèle de licence n’a pas non plus changé (abonnement par utilisateur), mais le nombre minimal d’utilisateurs a augmenté : 50 dorénavant, contre 25 auparavant (voire 15 sur la version autohébergée de Cameyo).

La version managée n’est plus déployable sur Azure : Google Cloud est maintenant l’hébergeur exclusif. Il est, dans ce cadre, responsable du déploiement des VM et de leur mise à l’échelle. Mais pas des logiciels – y compris l’OS – qui fonctionnent sur ces VM.

Des jonctions avec Drive et l’annuaire Google Workspace

Sur GCP, un serveur Cameyo peut exploiter 6 niveaux de capacité, variant en vCPU (1 à 16), en RAM (3,75 à 60 Go) et en réseau (pas d’accès Internet sur les deux premiers niveaux). Des clusters peuvent être mise en place pour l’autoscaling.
Pour l’autohébergement, il faut compter au moins 2 CPU et 8 Go de RAM, avec au minimum Windows Server 2019 (Windows Server 2025 n’est pas encore pris en charge).

D’autres jonctions avec l’écosystème Google ont été établies pour l’authentification des utilisateurs (SSO avec compte Google) et la configuration des permissions (annuaire Google Workspace). Drive a par ailleurs été intégré directement dans les sessions (explorateur et fenêtres de dialogue spécifiques).

Cameyo ne gère pas les applications qui ont besoin d’un accès direct à des périphériques locaux (webcams, imprimantes…). Ni celles qui dépendent de fonctions système (enregistrement d’écran, compression de fichiers…).

Illustrations © Google

The post Google relance un Cameyo plus intégré à l’écosystème Chrome appeared first on Silicon.fr.

Entre Ngrok et Pinggy, pas de jaloux : les attaquants qui s’en sont pris au centre hospitalier Stell de Rueil-Malmaison ont exploité l’un et l’autre de ces services de tunneling.

C’était en mars dernier. Au bout, le déploiement d’un ransomware qui avait chiffré des serveurs Windows. La gestion administrative des patients, entre autres, s’en était trouvée indisponible pendant un temps. Des données personnelles ont par ailleurs possiblement été exfiltrées.

Un compte de test admin de domaine

Le point d’entrée fut un ancien compte de test, réactivé le 4 mars 2025 pour un audit Wi-Fi. Ce compte au mot de passe faible avait des privilèges d’admin de domaine et disposait d’un accès VPN.

L’accès initial, via ce vecteur, a lieu le 17 mars (un lundi). Le 22, une latéralisation est mise en œuvre par connexion RDP sur le contrôleur de domaine. Un mécanisme de persistance est ensuite déployé, en ajoutant Pinggy pour établir une connexion SSH sur le port 443.

Vendredi 28 mars, un canal est mis en place entre le contrôleur de domaine et le serveur de l’attaquant grâce à Ngrok. Le même jour, le ransomware est déployé et exécuté. Le lendemain, les traces de l’attaque sur les systèmes sont supprimées.

Le CH de Rueil-Malmaison passe au tiering AD

Le chiffrement n’est constaté que lundi 31 mars. À partir de là, les flux VPN sont coupés ; les serveurs impactés, isolés. Le lendemain, les sauvegardes sont mises hors réseau en vérifiant leur intégrité. L’ANSSI et le CERT Santé se déplacent sur site.

Le 2 avril, l’analyse des serveurs compromis démarre. Et du matériel (postes, clés 4G…) est demandé à l’ARS.

La reconstruction AD débute le 7, parallèlement à la fin des analyses. Le 10, la bascule est achevée. Le service de sauvegarde est relancé, les services métiers impactés sont restaurés et une formation d’administration sécurisée est dispensée.

La période d’avril-mai est marquée par le rétablissement progressif des services RH et d’admission, ainsi que le déploiement de nouveaux postes. Entre juin et septembre, un modèle par niveaux de privilège est mis en place pour l’AD.

Illustration générée par IA

The post Comment un ransomware s’est infiltré au CH Rueil-Malmaison appeared first on Silicon.fr.