Est-il possible d'utiliser la fonctionnalité Toujours chiffré avec la fonction de sécurité de niveau ligne dans SQL Server 2016? Et en quelque sorte crypter les lignes avec différents EncryptionKeys par rapport aux lignes qui doivent être visualisées par un utilisateur particulier?Chiffrement par ligne SQL Server 2016
Cela aide. Réponse courte, ne peut pas le faire facilement aujourd'hui avec AE & RLS.
AE est actuellement portée sur une colonne; vous cryptez une colonne entière avec une clé de chiffrement de colonne spécifique (CEK). Vous pouvez chiffrer plusieurs colonnes dans une table, chacune avec son propre CEK, mais la portée de la colonne est toujours valide. Vous ne pouvez pas grouper logiquement les lignes et les chiffrer avec leurs propres clés avec l'implémentation AE actuelle. Si cela est vraiment important pour vous, vous pouvez soumettre une suggestion à l'équipe via https://connect.microsoft.com/SQLServer/feedback/
Cela dit, en plus de répondre à certaines exigences de la réglementation ou de la politique d'entreprise, vous ne gagnez pas grand-chose de la conception que vous proposez actuellement. À moins d'avoir un très petit nombre d'utilisateurs (ou de groupes d'utilisateurs), donc un très petit nombre de groupes de lignes, vous allez rapidement rencontrer la prolifération de CEK. Ce n'est pas une chose difficile à gérer, mais encore fastidieuse et potentiellement beaucoup de travail. Par exemple, chaque utilisateur ou groupe d'utilisateurs a besoin de ses propres clés ou de son propre secret pour accéder à la clé transmise à son application ou à son poste de travail. La complexité et/ou beaucoup de pièces en mouvement signifie plus de risques d'échec. De plus, cela peut être très amusant pendant la saison d'audit (en fonction de votre auditeur bien sûr).
Si je reformuler vos objectifs, vous voulez vous assurer 1. Les données sont toujours à l'abri des regards indiscrets 2. Les utilisateurs autorisés sont permettent seulement de voir les données qu'ils sont autorisés à voir
correctement mis en œuvre, AE répond aux exigences # 1. Sans la clé, tout ce que vous voyez est un texte chiffré. Bien sûr, vous pouvez forcer la force ou trouver des failles dans l'algorithme de cryptage ou la mise en œuvre de SQL Server, mais il y a des moyens FAR, beaucoup plus faciles que ce que Hollywood veut nous faire croire. RLS adresse # 2 dans la plupart des cas. L'implémentation est au niveau du processeur de requêtes, donc contourner le RLS est extrêmement difficile; il doit y avoir un bug dans RLS pour que cela soit possible. Si votre filtre RLS est basé sur une colonne non cryptée (et ce devrait être le cas), il n'y a aucune chance que quelqu'un puisse même renifler vos secrets de la mémoire/du réseau à moins que votre client ne soit compromis.
Les deux exigences sont donc satisfaites même si vous n'avez que 1 CEK. Cela rend votre vie beaucoup plus facile à long terme avec une surface plus petite à gérer. Cela aboutit presque toujours à un environnement plus sécurisé. Avoir des clés séparées vous permet d'acquérir une couche supplémentaire qui est excellente sur papier pour la défense en profondeur, mais dans la pratique, vos efforts produiront beaucoup plus dans d'autres domaines (par exemple, alertes, formation des utilisateurs, etc ...).
Quels sont exactement vos objectifs? Toujours chiffré et Row Level Security sont des choses complètement différentes. RLS filtre le jeu de résultats en fonction de votre fonction de filtre afin que user_x ne voie que les données qu'il est autorisé à voir. RLS ne crypte pas les données utilisateur. AE va crypter les données de l'utilisateur. Indépendamment de ce que RLS renvoie à l'utilisateur, sans la clé, tout l'utilisateur voit est un texte chiffré. Lorsqu'ils sont utilisés ensemble, vous devez faire attention à la façon dont vous écrivez la fonction RLS. Si cela dépend d'une colonne AE cryptée, les performances de votre application en souffriront probablement. Si ce n'est pas le cas, cela fonctionnera avec la surcharge et les restrictions habituelles AE – SQLmojoe
@SQLmojoe: mon objectif est de ... si l'utilisateur A a des lignes et que l'utilisateur B a d'autres lignes ... avec RLS, nous pouvons nous assurer que A voit seulement ARows et B ne voit que BRows. Mais mon but serait que ARows soit chiffré avec une clé par A et que BRows soit chiffré par une clé différente par B dans la base de données. –