Re: Encryption et PG

Marc Cousin <cousinmarc(at)gmail(dot)com> writes:

> Ça résout la problématique du vol de serveur physique. Va bien falloir
> l'arrêter électriquement pour l'emmener (lui ou ses disques).
>
> Pour ce qui est du chiffrement des sauvegardes, c'est évidemment à faire aussi
> (beaucoup de logiciels, comme bacula par exemple, le permettent)...
>
> Et oui, évidemment, ce n'est qu'une des nombreuses briques dans l'arsenal
> défensif. Mais il permet de résoudre (ou au moins limiter) le problème de
> l'accès physique à la machine. Toutes les machines ne sont pas derrière une
> porte blindée dont vous êtes le seul à avoir le digicode. Pensez «grande
> distribution», par exemple… :)
>
> Sans le chiffrement des disques, il suffit qu'un malin prenne vos disques et les
> emmène avec lui...
>
> Ce n'est donc pas pour la confidentialité des données dans la base, bien sûr
>
> Après, je ne sais pas dans quel contexte Rodolphe veut s'en servir, mais je
> sais dans lesquels j'en ai eu besoin :)

Il reste un élément qui n'a pas été évoqué ici et qui je sais est
souvent clivant, mais j'ai la change d'intervenir dans un milieu
hétérogène ou se parlent des DBA et des devs :-)

Les contraintes de confidentialités ne sont toujours suivies (par
expérience) que sous la contrainte, et majoritairement la contrainte
client, donc si le cahier des charges indique qu'il faut se protéger
contre le vol de données effectivement dm-crypt répond au besoin, le
chiffrement SSL des flux étant de toutes façons déjà de base quand on se
pose la question du vol des disques. Après le codage au niveau colonne
implique de la refactorisation de code, qui est parfois possible
(temps, coût, compétences) parfois pas, toujours une question
d'équilibrage.

R.

--
Rodolphe Quiédeville - Expert Tsung
Consulting en performance des SI(G)
http://blog.rodolphe.quiedeville.org
Tel : 06 13 79 63 41

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)