Aller au contenu

Chiffrement (cryptage ou encryption ) de disk ou volume


Messages recommandés

Bonjour,

Après 5 ans de bons services, je pense à renouveler mon nas, et je constate avec déception que le chiffrement de volume (ou disque) n'a toujours pas été mis en place sur les nas Synology.

D'oû ma quetion : Pourquoi cette focntionnalité essentielle n'est-elle toujours pas proposée +5 ans après les premières demandes des clients ?

-est un probleme materiel ? (probablement pas quand on voit la conf du nouveau DS918+ qui est du même niveau que le qnap x53b qui lui le propose).

-est ce un probleme d'architecture logicielle du DSM ?

-est ce une volonté politique de synology de ne pas faciliter le chiffrement et la sécurité ?

Merci de vos eclairages.

PS : je connais les possibilités/limites des "encrypted shared folders" qui sont ici hors sujet.

 

Lien vers le commentaire
Partager sur d’autres sites

Merci de faire un tour dans la section présentation du forum, c'est toujours plus sympa (tu n'as pas trouvé le temps en 4ans ?)

il y a 13 minutes, poypoy a dit :

D'oû ma quetion : Pourquoi cette focntionnalité essentielle n'est-elle toujours pas proposée +5 ans après les premières demandes des clients ?

On a déjà répondu à cette question, c'est principalement une question d'approche et de bon sens.

Chiffrer un disque ou un volume ou un dossier c'est identique du point de vue sécurité et dans le cas d'un "serveur" l’approche "dossier" est plus souple (on n'est pas obligé de tout chiffrer et on peut changer d'avis sans devoir tout perdre, on peut chiffrer différents dossiers avec différentes clef, ...).

Pour ce qui est de Qnap, ils avaient commencé par chiffrer au niveau disque/volume avant d'ajouter la fonction au niveau "partage", preuve que le chiffrement disque/volume ne répondait pas au besoin.

nb : le chiffrement au niveau disque est toujours partiel (y compris sur ton mac/iphone/...) lorsque ce disque contient le boot

Lien vers le commentaire
Partager sur d’autres sites

houla, j'ai l'impression d'avoir posé la question qui fâche. donc en préambule, je précise que j'aime bien les produits synology, leur stabilité ainsi que l'ergonomie du dsm même si je ne suis pas un "fanboy". 

pourtant ma question est légitime car le "bon sens" est de laisser à l'utilisateur le choix entre chiffrage de volume ou dossier...la "preuve" est que tout le monde n'a pas le même besoin.

je ne comprends pas la comparaison avec le boot.

la question est toujours ouverte et je suis vraiment preneur d'informations sur les raisons de ce manque chez synology.

 

Lien vers le commentaire
Partager sur d’autres sites

Ce n'est pas une question qui fâche (en tout cas moi ça ne me fâche pas), je ne dis pas non plus que ta question est illégitime. Je n'ai pas non plus relevé ton dernier exemple qui était clairement une attaque. Remplace synology par apple, microsoft, qnap, ... ça marche aussi puisque aucun ne permet nativement d'avoir un vrai niveau de sécurité. Ils font tous des compromis entre coût de R&D, cible de marché et retour sur investissement.

J'ai expliqué que cela relevait du bon sens en indiquant que du point de vue sécurité c'était la même chose. Donc pourquoi perdre du temps en R&D pour implémenter une fonctions qui n'apporte rien ? Je peux me tromper, mais je ne vois aucun cas d'usage où le chiffrement au niveau disque apporterait quoi que ce soit par rapport au chiffrement niveau dossier pour un matériel de type "serveur". Par contre je vois de très nombreux cas où c'est l'inverse.

=> je suppose que la raison invoquée par Synology serait : ça n'apporterait rien aux clients.

On peut juste regretter que cette fonction ne soit disponible qu'aux admin (un utilisateur devrait pouvoir chiffrer un dossier).

Encore une fois, je parle ici d'un usage pour un appareil de type "serveur", qui doit pouvoir démarrer et fournir ses services sans interaction utilisateur. Sur un poste de travail (mono utilisateur, avec écran, périphérique de saisie, ...), c'est différent.

Le nota bene sur le boot c'était pour rappeler que tous les systèmes (d'Android à iOS en passant par linux ou encore mac ...) qui proposent un "soit disant" chiffrement intégral n'en font pas en réalité. Pour permettre de déchiffrer les données, il faut bien démarrer un "truc" qui va demander les clefs de déchiffrement. Ce truc ne peux donc pas être chiffré. En général c'est une petite partition contenant de quoi amorcer le système (apple_boot sous MacOS, /boot sous Linux), parfois c'est un composant dédié (intégré dans certains disques dur ou certains chipset). La sécurité du reste repose donc uniquement sur cet unique point.

J'espère avoir mieux répondu à ta question.

ps : si tu as des cas d'usage où le chiffrement du disque/volume permettrait de faire mieux que le chiffrement niveau dossier pour un serveur, je veux bien les connaitre

Modifié par Fenrir
Lien vers le commentaire
Partager sur d’autres sites

bon, ma réponse ne va pas être trop stucturée par manque de temps.
mais on est d'accord sur
- la partition du système de boot et le lancement d'une séquence de déverrouillage sont hors sujet.
- un nas contient de nombreuses données personnelles et sensibles (sensible pour moi même si je n'ai rien a cacher comme disent les détracteurs du chiffrement;-), le chiffrement est donc nécessaire.

Mon problème est que c'est un nas personnel donc même si il y a une fonction "serveur" (avec des ports ouverts et des services à l'écoute), il n'est pas dans une salle machine sécurisée mais dans ma maison et il est souvent tout seul. le risque est donc le vol au même titre qu'un ordi portable ou un smartphone (là le chiffrement total te semble dans ce cas justifié !).  
 
Alors pourquoi chiffrer tout un volume plutôt qu'un simple dossier partagé :

1/ c'est plus simple de tout chiffrer, ça permet de ne pas se poser de questions sur quelles sont les données et où sont elles localisées sur le système.
2/ je ne maitrise pas tous les internes de l’écosystème logiciel synology (linux + surcouche DSM + packages).  
3/ les quelques dossiers partagés chiffrables  dans le DSM ne sont que la partie visible mais :   
3/ comme dans tout système, il y a des fichiers de logs, des fichiers de configuration, des fichiers et répertoires temporaires qui contiennent forcement des données sensibles exploitables par un tiers.

alors pour les exemples concrets :  

4/ je configure des connexions FTP ou CIFS d'autres serveurs dans filestation, je ne sais ni où ni comment sont stockés ces informations (IP/login et mot de passe).
5/ bon, je lance un terminal sur le synology pour trouver un exemple concret (ce que je fais jamais)
   je vais dans le répertoire /volume1 qui contient entre autre les dossiers partagés et je vois plein de dossiers @xxx
   dans le premier @download, il un fichier transmission.log qui contient des listes de fichiers .torrent téléchargés il y a plusieurs années (attention aux perquisitions pour les vilains pirates !)
   dans @cloudstation, il y a une base sqllite qui doit contenir pas mal de métadonnées
   dans @database, il y a les bases mysql et postgre des applications web déployées !!!  et là il y a forcement des données sensibles non chiffrables!
6/etc...

pourquoi refuser le chiffrement de volume ? pour moi, il n'y a pas de bonnes raisons.

 

 

Lien vers le commentaire
Partager sur d’autres sites

Tu as raison pour les dossiers @xxx. Même si la plupart ne contiennent rien d'important, il peut y en avoir quelque uns à protéger, en particulier @cloudstation (qui contient aussi les versions des fichiers) et @database. Je n'y avais pas pensé car je n'utilise ni l'un ni l'autre (et les infos présentent dans la base postgresql, celle du Syno, sont neutres dans mon cas).

Ni Synology, ni Qnap (à moins que ça ait changé depuis 2015) ne chiffrent ces données car il s'agit de serveurs, ils ne pourraient donc pas démarrer les applications. C'est en ça que je parlais de bon sens, mais le bon sens me dit aussi qu'avec un meilleur design logiciel ils pourraient très bien le faire.

Le problème semble donc plus être un mauvais choix d'architecture pour les applications vis à vis du chiffrement. Dans ce cas précis, le chiffrement au niveau volume permettrait de masquer la misère.

Pour ma part, exception faite de audiostation/videostation, je me sers de mon NAS comme d'un NAS, c'est à dire un endroit où stocker des fichiers => mes données sensibles sont chiffrées avec des produits digne de confiance "en dehors" du nas.

=>fais un retour à Synology pour qu'ils implémentent correctement le chiffrement (une implémentation simple pourrait par exemple être le lancement d'un mini serveur Web au début de la phase de boot, attendant la saisie d'une clef pour démarrer le reste).

ps : mes réponses précédentes étaient sur le principe (le chiffrement du disque n'apporte rien par rapport au chiffrement des dossiers), pas sur l'implémentation (qui est mauvaise puisque que des données se retrouvent, au moins partiellement, dans des zones qui ne sont pas chiffrées) => elles ne répondaient donc pas à ta question ou ton besoin, dsl.

Lien vers le commentaire
Partager sur d’autres sites

la tendance de l'auto hebergement qui se developpe depuis quelques années (syno, qnap, cozycloud, ...) impose beaucoup de précautions de sécurité et avec ce constat du manque de chiffrement chez syno, on peut imaginer des scénarios terribles pour exploiter un nas volé :

imaginons le cas suivant (je ne sais pas si c'est possible en vrai car je ne connais pas le fonctionnment)

-un de mes repertoire est chiffré et  les données sont sauvegardées non chiffrées sur amazon Glacier (ce qui doit être fréquent vu l'implémentation du package)

- est ce que le fichier de configuration de la connexion vers Amazon Glacier (id+clef) est  recuperable et installable sur un autre nas synology ?

-si oui, cela permettrai de faire une recuperation des données sauvegardées sur un autre nas

ce scénario n'existe pas chez qnap avec un chiffrement de volume car rien n'est récupérable, et pour avoir egalement un qnap chez moi, le focntionnement du chiffrement de volume est très grosso modo le suivant :

lors de l'installation d'un package, on fait un choix de volume d'installation et si celui ci est chiffré, l'application ne sera pas disponible tant que le volume est vérouillé, dès qu'on dévérouille le volume, l'application (son service) se lance et devient dispo. il n'y a pas de données applicative en dehors du volume choisi.

Qnap a cet avantage mais malheureusement il n'a pas l'excellente ergonomie du DSM (et des packages standards). il y a plein de petits défaults qui pourissent l'experience de utilisateur final. ce n'est clairement pas aussi abouti. par contre il est probable (je ne sais pas vraiment) que les couches basses soient implementées de manières plus "propres" pour proposer ce chiffrement. et Qnap propose d'autres choses interessantes mais ce forum n'est pas le lieu pour promouvoir (non, je ne parles pas de la focntion karaoké) !

J'espere que synology va implementer cette fonctionnalité, la seule qui me manque (maintenant qu'il y a la virtualisation) et c'est vraiment bloquant.

à+

 

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.