Je mettrai bien mon grain de sel sur la partie sécurité/souverraineté/simplicité.
Déjà via le Cloud Act qui est un très bon (gros) point d'entrée dans le sujet : l'expression "les données gérées par un datacenter" me semble trop approximative, il faudrait plutôt parler des "données gérées par un opérateur" car la question est de savoir 1/ à qui appartiennent les équipements qui manipulent lesdites données et 2/ qui les contrôle.
Cas hostile : tu met des données dans des équipements situés en France mais appartenant à un cloud américain et géré par lui; le Cloud Act leur permet de siphonner ce qu'ils veulent quand ils veulent. De toute façon tu consommes du "cloud (IaaS)" et il n'y a aucun espoir que tu crées le moindre rideau de confidentialité, puisque le cloud gère toutes les clés de chiffrage pour toi. Si tu les gères manuellement ça ne change rien, à un moment il faut qu'une clé de chiffrage existe en clair (même brièvement, même en RAM) sur le(s) serveur(s) concernés. J'appellerai ça le modèle "à poil sur Internet".
Cas intermédiaire : tu met des données dans des équipements situés en France appartenant à un opérateur français. Cet opérateur peut techniquement aspirer tes données (cf. paragraphe précédent), mais légalement non. On en revient donc à une relation de confiance traditionnelle (avec l'opérateur, avec la loi de son pays, avec la façon dont son application est contrôlée, etc). Et bien sûr on est toujours sujet à l'écoute légale, qui est un mécanisme considéré acceptable quand il est bien contenu (limité à la justice, doit passer par un juge pour approbation, etc). En France actuellement on peut tout à fait être insatisfait de ce niveau de confidentialité : par ex. si on héberge un blog écolo on peut tout à fait se faire "écouter" par la cellule anti-terroriste.
Cas prudent : tu mets des données dans des équipements situés en France, qui t'appartiennent et que tu gères. En théorie tu n'est donc sujet qu'à l'interception légale, soit au niveau de ton peering, soit éventuellement directement sur tes équipements mais dans ce cas tu recevras une demande de la PJ ou de la DGSE (tu seras donc bien informé, et tu ne pourras pas refuser). Et il reste aussi l'accès physique : même si tu loues une "suite privée" dans un datacenter, tous les techniciens du datacenter peuvent y accéder. Tu ne peux pas formellement assurer que tu es le seul à pouvoir accéder physiquement à tes équipements, c'est pas interdit d'être parano en monitorant ce qui se plugge sur les switches, bloquer tous les ports serveurs eth/usb non utilisés, etc.
Evidemment tout ceci est à analyser au prisme d'un modèle de menace : si tu héberges une boutique qui vend des pots de miel, tout ce qui a été cité t'importe très peu. Au pire tu crains une attaque de concurrents, qui n'useront probablement pas d'attaque physique (le remote via les failles des apps web + ingénierie sociale restant hélas très efficaces).
Quant à l'avantage de la virtualisation, OK pour ceux cités, mais ...
En premier lieu quand tu passes à la virtu toi-même (par ex. tu installes Proxmox), tu dois acquérir une compétence en plus. Et elle n'est souvent pas mince, les outils de virtu (avec tout ce qu'ils tirent : Xen/KVM, H-A, Ceph/NFS/etc) peuvent venir à un gros update de bagage technique. Evidemment ça peut rapporter gros sur la partie opérationnelle si les besoins de nouveaux "serveurs" sont fréquents : si ces derniers sont virtuels, on élimine une grosse friction. Mais j'ai vu des cas où ces besoins étaient quasi nuls, et il était tout à fait raisonnable de ne pas envisager de passer aux VMs.
En second lieu quand tu délègues la virtu, tu :
* change de business model : au lieu d'acheter du matériel et l'amortir, tu passes sur du récurrent; l'impact peut être important car un bon matériel peut s'amortir sans problème sur 5 à 10 ans (autant dire qu'à +2 ans ton "compute" est quasi-gratuit vu du modèle du cloud)
* renonce à plein de garanties de sécurité et de confidentialité (cf. le barratin plus haut)
* dépend du support du cloud : ce que tu savais réparer en 30min va peut être se transformer en ticket fleuve d'1 semaine (dans mon expérience hélas récurrente, retirez le "peut être")
* en général la dispo des VMs du cloud est meilleure que ce tu faisais par toi-même (si ce n'était pas ton métier), mais le cloud ça plante quand même; du coup les problèmes de H-A se posent toujours et ne sont pas magiquement résolus (sauf réplication en continu de VM à la VMware, jamais testé, mais à chaque fois qu'on m'a proposé ça coûtait 3 bras et 5 fesses)
* c'est peut être un avis plus perso, mais les "clouds" ont parfois une complexité et charge cognitive bien supérieur à ton petit cluster Xen/KVM; si tu es un profil technique ça peut devenir contre-productif et démotivant de te battre contre des usines à gaz relativement abstraites
# Bon brossage de tableau !
Posté par zerodeux (site web personnel) . En réponse à la dépêche La virtualisation pour les nuls et autres enjeux autour des datacenters. Évalué à 9.
Je mettrai bien mon grain de sel sur la partie sécurité/souverraineté/simplicité.
Déjà via le Cloud Act qui est un très bon (gros) point d'entrée dans le sujet : l'expression "les données gérées par un datacenter" me semble trop approximative, il faudrait plutôt parler des "données gérées par un opérateur" car la question est de savoir 1/ à qui appartiennent les équipements qui manipulent lesdites données et 2/ qui les contrôle.
Cas hostile : tu met des données dans des équipements situés en France mais appartenant à un cloud américain et géré par lui; le Cloud Act leur permet de siphonner ce qu'ils veulent quand ils veulent. De toute façon tu consommes du "cloud (IaaS)" et il n'y a aucun espoir que tu crées le moindre rideau de confidentialité, puisque le cloud gère toutes les clés de chiffrage pour toi. Si tu les gères manuellement ça ne change rien, à un moment il faut qu'une clé de chiffrage existe en clair (même brièvement, même en RAM) sur le(s) serveur(s) concernés. J'appellerai ça le modèle "à poil sur Internet".
Cas intermédiaire : tu met des données dans des équipements situés en France appartenant à un opérateur français. Cet opérateur peut techniquement aspirer tes données (cf. paragraphe précédent), mais légalement non. On en revient donc à une relation de confiance traditionnelle (avec l'opérateur, avec la loi de son pays, avec la façon dont son application est contrôlée, etc). Et bien sûr on est toujours sujet à l'écoute légale, qui est un mécanisme considéré acceptable quand il est bien contenu (limité à la justice, doit passer par un juge pour approbation, etc). En France actuellement on peut tout à fait être insatisfait de ce niveau de confidentialité : par ex. si on héberge un blog écolo on peut tout à fait se faire "écouter" par la cellule anti-terroriste.
Cas prudent : tu mets des données dans des équipements situés en France, qui t'appartiennent et que tu gères. En théorie tu n'est donc sujet qu'à l'interception légale, soit au niveau de ton peering, soit éventuellement directement sur tes équipements mais dans ce cas tu recevras une demande de la PJ ou de la DGSE (tu seras donc bien informé, et tu ne pourras pas refuser). Et il reste aussi l'accès physique : même si tu loues une "suite privée" dans un datacenter, tous les techniciens du datacenter peuvent y accéder. Tu ne peux pas formellement assurer que tu es le seul à pouvoir accéder physiquement à tes équipements, c'est pas interdit d'être parano en monitorant ce qui se plugge sur les switches, bloquer tous les ports serveurs eth/usb non utilisés, etc.
Evidemment tout ceci est à analyser au prisme d'un modèle de menace : si tu héberges une boutique qui vend des pots de miel, tout ce qui a été cité t'importe très peu. Au pire tu crains une attaque de concurrents, qui n'useront probablement pas d'attaque physique (le remote via les failles des apps web + ingénierie sociale restant hélas très efficaces).
Quant à l'avantage de la virtualisation, OK pour ceux cités, mais ...
En premier lieu quand tu passes à la virtu toi-même (par ex. tu installes Proxmox), tu dois acquérir une compétence en plus. Et elle n'est souvent pas mince, les outils de virtu (avec tout ce qu'ils tirent : Xen/KVM, H-A, Ceph/NFS/etc) peuvent venir à un gros update de bagage technique. Evidemment ça peut rapporter gros sur la partie opérationnelle si les besoins de nouveaux "serveurs" sont fréquents : si ces derniers sont virtuels, on élimine une grosse friction. Mais j'ai vu des cas où ces besoins étaient quasi nuls, et il était tout à fait raisonnable de ne pas envisager de passer aux VMs.
En second lieu quand tu délègues la virtu, tu :
* change de business model : au lieu d'acheter du matériel et l'amortir, tu passes sur du récurrent; l'impact peut être important car un bon matériel peut s'amortir sans problème sur 5 à 10 ans (autant dire qu'à +2 ans ton "compute" est quasi-gratuit vu du modèle du cloud)
* renonce à plein de garanties de sécurité et de confidentialité (cf. le barratin plus haut)
* dépend du support du cloud : ce que tu savais réparer en 30min va peut être se transformer en ticket fleuve d'1 semaine (dans mon expérience hélas récurrente, retirez le "peut être")
* en général la dispo des VMs du cloud est meilleure que ce tu faisais par toi-même (si ce n'était pas ton métier), mais le cloud ça plante quand même; du coup les problèmes de H-A se posent toujours et ne sont pas magiquement résolus (sauf réplication en continu de VM à la VMware, jamais testé, mais à chaque fois qu'on m'a proposé ça coûtait 3 bras et 5 fesses)
* c'est peut être un avis plus perso, mais les "clouds" ont parfois une complexité et charge cognitive bien supérieur à ton petit cluster Xen/KVM; si tu es un profil technique ça peut devenir contre-productif et démotivant de te battre contre des usines à gaz relativement abstraites