Comment protéger les fichiers journaux et données standard sensibles de HIPAA (HIPAA)

Je traite des informations de santé électroniques protégées (ePHI ou PHI) et les réglementations HIPAA exigent que seuls les utilisateurs autorisés puissent accéder à ePHI. Le chiffrement au niveau de la colonne peut être utile pour certaines données, mais j'ai besoin de pouvoir effectuer des recherches sur certains des champs PHI tels que le nom.

Le chiffrement transparent des données (TDE) est une fonctionnalité de SQL Server 2008 pour chiffrer la base de données et les fichiers journaux. Si je comprends bien, cela empêche quelqu'un qui accède aux fichiers MDF, LDF ou de sauvegarde de pouvoir faire quoi que ce soit avec les fichiers car ils sont cryptés. TDE est uniquement sur les versions entreprise et développeur de SQL Server et l'entreprise est prohibitif pour mon scénario particulier. Comment obtenir une protection similaire sur SQL Server Standard? Existe-t-il un moyen de crypter la base de données et les fichiers de sauvegarde (existe-t-il un outil tiers)? Ou tout aussi bien, existe-t-il un moyen d'empêcher les fichiers d'être utilisés si le disque a été attaché à une autre machine (Linux ou Windows)?

L'accès administrateur aux fichiers à partir de la même machine est correct, mais je veux juste éviter tout problème si le disque a été retiré et connecté à une autre machine. Quelles sont les solutions pour cela qui existent?

— Quesi
source

Les listes de contrôle d'accès BitLocker et Least Privilidge sont suffisantes pour HIPPA (au moment de la rédaction de ce document). Vous souhaitez probablement des contrôles plus avancés, mais le chiffrement au niveau de la cellule n'est pas requis si les contrôles d'accès sont correctement configurés. (Des conseils génériques donnés sans connaissance approfondie de votre environnement et n'impliquent aucune indemnisation). Sur une note plus sérieuse; si vous ne connaissez pas la sécurité SQL, veuillez ne pas être la seule personne à configurer la sécurité ePHI, faites entrer quelqu'un qui connaît vraiment son domaine.

— Chris S

@Chris s, Merci beaucoup. J'avais entendu parler de BitLocker, mais je ne savais pas ce que c'était. Je le fais maintenant et c'est ce que je cherchais.

— Quesi

Réponses:

La suggestion générale pour HIPAA est de suivre la norme de sécurité des données PCI (PCI-DSS), sauf partout où ils disent «Informations sur le titulaire de la carte» ou «Informations sur le compte», vous dites «PHI». Mon entreprise (secteur de la santé, traitant des PHI) utilise le PCI-DSS comme point de départ principal, ainsi qu'une bonne dose de bon sens (par exemple, en s'assurant que les données restent cryptées (ou confinées à des réseaux sécurisés) à tout moment).

Le chiffrement au niveau des colonnes d'une certaine sorte est presque toujours une bonne idée lorsqu'il s'agit de données sensibles, et étant donné le coût potentiel d'une poursuite, il est très élevé avec des éléments à prendre en compte.

— voretaq7
source

Bien que je préfère que le commentaire sur ma question utilise BitLocker comme réponse, il ne l'a pas posté comme réponse, donc je marque la vôtre parce que vous m'avez pointé vers un excellent document avec plus d'informations sur le sujet. Bien que le chiffrement au niveau des colonnes soit une bonne idée, il n'est tout simplement pas pratique dans tous les cas, par exemple lorsque vous devez le rechercher.

— Quesi

Vous devez protéger le PHI, ce qui nécessiterait que vous chiffriez les données dans la table de base de données. Crypter les données au niveau de la colonne si votre meilleur pari. La recherche sur ces champs va coûter cher, mais c'est le coût d'une haute sécurité.

Je parle d'une variété d'options de chiffrement des données dans le chapitre 2 de mon livre " Sécurisation de SQL Server "

— mrdenny
source

Est-il même possible de rechercher sur des champs cryptés en utilisant une requête "like"?

— Quesi

Bien sûr, vous devez décrypter toute la colonne, la rechercher puis renvoyer les lignes nécessaires.

— mrdenny

décrypter toute la colonne. beurk! C'est ce que vous vouliez dire par «cher».

— Quesi

Oui, la sécurité n'est pas faite pour vous faciliter la vie. La sécurité des données est la première considération, l'accès facile aux données est la deuxième. Si possible lors de la recherche de données, vous pouvez hacher les données et les stocker car les hachages sont beaucoup plus faciles à rechercher que les données chiffrées. Bien que ni l'un ni l'autre ne fonctionnera bien pour utiliser LIKE. Si vous ne cryptez pas le PHI et que vous êtes audité, vous échouerez à l'audit.

— mrdenny