Après si les données sont si sensibles que cela rien n'empeche de les stockées de manière cryptées.

De plus , l herbergeur ne peux utiliser un compte sql d'un utilisateur , le mot de passe est stocké de manière crypté , par contre en étant root il peux acceder aux informations contenus dans les bases de données.

Cependant le niveau de sécurité dépendra réelement de la criticité des données , si c est pour stocké des recette de cuisine ... ca sert à rien d'avoir une salle blanche super équipée ...

Après ca dépends surtout du niveau de sécurité que tu cherches à avoir .

..Ce que j en dis ... :D

[quote="Tomm"][color=#000040][...] le branchement d'un clavier / écran
(possibilité prévue par certains hébergeurs qui fabriquent leur matériel).[/color][/quote]Pas besoin d'avoir un hébergeur qui monte lui même ses serveurs, tous les serveurs à ma connaissance ont un port écran/clavier même si il n'y a pas d'écran ni de clavier en permanence branché dessus.
L'utilisation de [url=http://fr.wikipedia.org/wiki/Commutateur_KVM]KVM[/url] voir même de KVM-IP (la même chose qu'un KVM mais qui peut être utiliser à distance) est assez courante.


[quote="Tomm"][color=#000040]En somme je n'ai toujours pas la solution pour qui veut mettre en hébergement des données confidentielles.
Je pense pourtant qu'il doit y avoir une autre solution que "tirer une ligne spécialisée" jusqu'à son bureau.[/color][/quote]La solution est de louer une demie-baie fermée à clé dans laquelle tu déposes [b]ton[/b] serveur.
Ainsi tu es sûr d'être le seul à avoir l'accès et le contrôle de ton serveur.
Au niveau de la connexion réseau, il faudra bien penser à l'encryptage (via SSL ou la mise en place d'un VPN par exemple) de sorte que personne ne puisse intercepter les données qui transitent entre toi et ton serveur.

[color=#000040]Exceptons l'enlèvement du disque pour le lire ailleurs, et le branchement d'un clavier / écran
(possibilité prévue par certains hébergeurs qui fabriquent leur matériel).

Alors en théorie, il est possible d'interdire à l'hébergeur l'accès de votre machine,
en enlevant son mot-de-passe d'utilisateur Linux et sa cléf d'accès SSH.

En théorie seulement. Car lors d'un problème de démarrage à distance de votre serveur,
les hébergeurs ont en principe une "console client" à laquelle vous vous connectez pour gérer votre compte,
et par exemple faire "rebooter" votre serveur sur un système annexe. (Un peu comme vous le feriez
avec une disquette ou un lecteur zip sur votre ordinateur de bureau qui ne démarre plus).
Dès lors : vos anciennes protections systèmes sont inopérantes et votre machine se comporte
comme une mémoire de masse livrant ses fichiers.
Bien entendu l'hébergeur est maître de cette console client.

Je n'ai pas posé la question, et je n'ai donc pas de réponse sur le fonctionnement de cette "console",
et sur la manière dont un hébergeur "voit" ou contrôle son parc de serveurs dédiés.
Pour les matériels "made-in-hébergeur" peut-être faut-il chercher un lien avec le "bios de la machine" ?..
Et pour votre propre machine que vous amenez chez l'hébergeur ("housing", colocation), peut-être que
votre domaine n'est qu'une petite partie d'un seul et même "hébergement" auquel l'hébergeur à toujours "accès" ?..
(Je précise que je ne suis absolument pas informaticien).

En somme je n'ai toujours pas la solution pour qui veut mettre en hébergement des données confidentielles.
Je pense pourtant qu'il doit y avoir une autre solution que "tirer une ligne spécialisée" jusqu'à son bureau.[/color]

Notes :
w.Linux Plus-Value Serveur SSH.htm
w.guides/ovh.

[quote="Tomm"][color=#000050]Des éléments de réponse un peu plus sérieux ont été fournis,
contre toute attente par des hébergeurs eux-mêmes.
Je réunirai à l'occasion les ressources pour ceux que ça intéressent.
[/color][/quote]
[color=darkblue]Cela m'intéresse, j'aime apprendre des choses.
Peux-tu les linker ici s'il s'agit de pages web ou nous coller le texte s'il s'agit d'email ?[/color]

[color=#000050]Des éléments de réponse un peu plus sérieux ont été fournis,
contre toute attente par des hébergeurs eux-mêmes.
Je réunirai à l'occasion les ressources pour ceux que ça intéressent.
Rien ne vous empêche de compléter ici si vous en avez.[/color]

[quote="Anonymous"]Bonjour @rthur.
Il ne s'agit pas d'un problème général de "sécurité". Les questions ont été posées.[/quote]Bonjour,

Je ne sais pas qui tu es [i]invité[/i], mais si "les questions ont été posées", ma réponse est en lien directe avec la question n°3 que je t'invite à relire ;)
[quote="Tomm"]3 - N'y a t-il vraiment plus aucun accès possible ?
(Après tout un mot-de-passe peut être perdu. Dans quelle mesure Linux pourrait être alors
"forcé" ou simplement "ré-installé" ?[/quote]

Il s'agit de problème de confidentialité, mais la confidentialité est un sous domaine de la sécurité, donc c'est nécessairement un problème de sécurité.

Bonjour @rthur.
Il ne s'agit pas d'un problème général de "sécurité". Les questions ont été posées.

J'ajouterai également que même sans avoir le mot de passe root, du moment qu'on a un accès physique au serveur (ce qui sera évidemment le cas de ton hébergeur) toutes les sécurités peuvent sauter sans trop de difficulté...

Un utilisateur root sous linux a accès à tout d'une manière ou d'une autre, c'est pas plus compliqué que cela, je ne vois pas pourquoi tu cherches des réponses précises sur des points aussi précis. Sur le principe, un compte d'un hébergement peut être totalement isolé des autres, un administrateur a accès à tout, et pour transgresser une sécurité bien faite, il faut récupérer le mot de passe du compte mutualisé auquel on veut accéder ou bien de l'administrateur, ce sont les 3 points à savoir.
Sachant que si tu administres toi même ton serveur, tu auras plus de chances d'avoir une sécurité mal faite et de perdre ou te faire voler ton pass root, parce que les hébergeurs ont des spécialistes en sécurité et des retours d'expérience de plusieures années.
Voilà, c'est un résumé de tout ce qu'on peut te dire là dessus, et amha, tu n'as pas besoin d'en savoir plus, et si tu veux en savoir plus, ça veut dire que tu veux faire de la sécurité ton métier, et là il faut se tapper des administrations de serveur, et pas mal de doc pour savoir comment tout cela fonctionne. De toute façon, tu ne comprendras jamais la sécurité des serveurs juste avec des explications vagues comme les notres, pour comprendre cela, il faut se frotter à la chose, et accessoirement déjà s'installer une machine sous Debian, Gentoo ou BSD entièrement configurée soi même.

[color=#000050]Le problème d'un choix de gestion, de ses dépendances sociales ou de la "confiance", est sans objet.
Il a été évoqué.

Par ailleurs gérer un serveur physiquement chez moi n'est pas la solution.
L'hébergeur doit faire son travail de mise à disposition et de maintenance du service,
des matériels et des logiciels.

La solution à trouver est intermédiaire, et appelle des questions.
Par quels biais techniques précisément un "root" Linux peut-il accéder
aux données d'une Base MySql, alors qu'un mot-de-passe MySql ne lui a pas été octroyé.

- En lisant un My.conf ?
- Mon passe d'accès Sql a t-il raison de se trouver dans quelconque routine php qu'il pourrait lire ?
- En lisant ou en rapatriant les fichiers de données Sgl pour les lire dans un autre serveur Sql ?
- En arrêtant le serveur Sql, pour repartir avec l'option skip_grant_tables et installer son passe root Sql ?[/color]

[quote="Tomm"]2 - Hors je ne possède pas vraiment les compétences pour gérer un Linux-Apache.
Est-il envisageable qu'un hébergeur fasse des interventions sur le système
avec mon mot-de-passe, après que j'ai retiré de ce système (c'est à dire rapatrié
sur mon ordinateur à la maison) les fichiers de données de la Base, le My.conf,
et quels autres fichiers ?[/quote]
[color=darkblue][b]Il y a forcément un moment, si tu n'as pas les compétences techniques[/b] pour mettre ton serveur dans ton salon, avec toi comme administrateur autant pour l'OS (Linux) que la Base de données (MySQL), [b]où tu devras faire confiance à quelqu'un d'autre[/b].
Si en + ces infos doivent être accessibles à distance (web ou réseau local) que sur la machine où elles sont, tu devras acquérir des compétences en réseau et sécurité de réseau (SSL, etc...)

Par ailleurs, j'ai compris que tes informations étaient importantes pour toi, mais as-tu pensé aux problèmes d'accès qui peuvent se poser si tu es indisponible ?
Est-ce que tu dois être le seul à pouvoir accéder à ces informations ?
Est-ce que tu dois pouvoir fournir des informations à des tiers ? Si oui, peux-tu leur garantir un accès 24/7 ? Et s'il t'arrive quelque chose, comment retrouveront-ils leurs infos ?[/color]

[color=#000050]Bonjour Xénon,

bonjour My-heberg.
Je n'ai pas bien compris ton intervention. Peut-être pourrais-tu être plus précis,
ou même en privé si tu le souhaite.

Je dois (hélas) persister dans l'apprentissage d'un serveur dédié :
si toutefois celui-ci permet effectivement de cloisonner complètement
l'accès à moi-seul, ou sinon jusqu'a quelle mesure.

Les explications que vous pourrez fournir n'ont d'autre but que de clarifier
les rapports entre les appareils, où sont les points d'accès,
et comment circule l'information sur un plan technique.

Sur un plan contentieux : lorsque les gens concluent un accord tout est rose.
Seulement voilà, les choses de la vie font que parfois, deux voisins peuvent
entrer en conflict, alors même qu'ancun des deux n'est particulièrement fautif.
Un employé-boulanger peut mettre trop de sel dans le pain
parce qu'il pense qu'il n'est pas assez payé.
Un stagiaire informaticien peut même tout simplement commettre une erreur
après avoir été trop curieux.
Ainsi chez les gens parfaitement clairs, les protocoles d'accord et l'information sont diffusés
pas du tout uniquement pour la seule tranquilité du client...

Merci de la remarque, il fallait que ce soit dit.[/color]

Moi je pourais lui présenté une personne qui pourais lui sécurisé et ect pour pas chere :)

[b]Sékiltoyai[/b] a parfaitement raison. Si tu n'as pas les connaissances pour l'administration d'un serveur, alors vaut mieux utiliser un hébergement mutualisé.

Si tes données sont si confidentielles que ça et que tu ne fais pas confiance aux hébergeurs mutualisés, alors vaut mieux embaucher un administrateur système qui fera la maintenance de ton serveur dédié. (si tu optes pour cette option) Mais on revient au point de départ: feras-tu confiance à cette personne?