Dois-je explicitement refuser la mise à jour des colonnes qui ne doivent pas être mises à jour?

Question

J'ai l'habitude de travailler dans des environnements très sécurisés et je conçois donc mes autorisations avec une très grande granularité. Une chose que je fais normalement est de explicitement DENY utilisateurs la possibilité de UPDATE colonnes qui ne devraient jamais être mises à jour.

Par exemple:

create table dbo.something (
    created_by varchar(50) not null,
    created_on datetimeoffset not null
);

Ces deux colonnes ne doivent jamais être modifiées une fois la valeur définie. Par conséquent, je voudrais explicitement DENY l'autorisation UPDATE sur eux.

Récemment, lors d'une réunion d'équipe, un développeur a souligné que la logique pour garantir que les champs ne soient jamais mis à jour devrait être contenue dans la couche application et non dans la couche base de données dans le cas où "ils doivent mettre à jour les valeurs pour une raison quelconque". Pour moi, cela ressemble à une mentalité de développement typique (je sais, j'en étais un!)

Je suis l'architecte senior de mon entreprise et j'ai toujours travaillé sur le principe du minimum de privilèges requis pour faire fonctionner l'application. Toutes les autorisations sont auditées régulièrement.

Quelle est la meilleure pratique dans ce scénario?

Answer 1

L'argument n'a pas de sens. Je veux toujours que les contrôles et les contraintes soient aussi proches que possible des données. Le mettre dans la couche application signifie qu'il n'affecte que les personnes en utilisant la couche application, et suppose également que le code sera exempt de bogues et que la sécurité autour de ces chemins de code sera être à l'épreuve des balles. Ce sont de grandes hypothèses.

S'ils doivent absolument être mis à jour, cela peut être fait par une personne non affectée par le DENY explicite, ou la personne peut être temporairement déplacée dans un rôle qui n'est pas affecté, ou le DENY peut être temporairement supprimé. Ce sont des choses qui sont faciles pour vous, en tant que DBA, à configurer l'audit. Dans l'application? Pas tellement.

Answer 2

Je suis entièrement d'accord avec @Aaron sur l'aspect technique de cela.

Au-delà de cela, je dirais, concernant les meilleures pratiques:

1. Étant donné que c'est le travail/la responsabilité du DBA de protéger les données, l'approche par défaut devrait être de faire exactement cela, comme le DBA le juge approprié, et nécessiter une analyse de rentabilisation solide pour apporter un changement. Un potentiel futur hypothétique-quelque-peu-possible-donné-certaines-conditions-qui-seront-brainstormées-plus tard-et-confirmées-bien-après-mais-peut-être-changées-plus tard-ou-pourraient-ne jamais -la raison qui se produit réellement (c'est-à-dire "pour une raison quelconque") semble un peu fragile d'une justification, en particulier lorsque le sujet change une norme/pratique d'entreprise.

2. Ne faites jamais confiance à quelqu'un qui souhaite apporter des modifications à quelque chose qui ne devrait jamais changer ;-), (encore plus s'il ne sait même pas pourquoi il le souhaite).

3. Dites au développeur qu'il est bienvenu d'ajouter une telle logique au code de l'application pour empêcher ces mises à jour. Mais aussi que vous n'allez pas supprimer le DENY. Si/quand le jour vient un jour (et pourrait ne pas probablement pas) que quelqu'un obtient une erreur en essayant de mettre à jour une de ces colonnes, alors vous pouvez avoir une discussion pour savoir si vous supprimerez ou non le DENY, ce qui nécessitera , une justification solide pour expliquer pourquoi quelqu'un mettrait à jour cette valeur en premier lieu.

   Le fait est qu'il devrait y avoir une véritable analyse de rentabilisation motivant ce sur quoi les gens passent leur temps. Le temps est en forte demande mais en pénurie, donc vous (et tout le monde) avez des choses plus importantes à faire que de changer le système en fonction de l'opinion de quelqu'un. Il y aura toujours une variété d'opinions (espaces vs tabulations, n'importe qui?) Et vous pourriez passer des années à changer cela d'avant en arrière si ce développeur quitte et est remplacé par quelqu'un qui s'oppose fortement à ce que ces champs puissent être mis à jour. Si aucun client ne le demande (ou quelque chose qui l'exige), et qu'il n'y a aucun avantage tangible (même un avantage retardé tel que le nettoyage de la dette technique, qui est difficile à afficher le retour sur investissement, mais qui en vaut la peine étant donné que le les chances que ce temps passé n'entraîne pas d'économies de coûts réelles à long terme soient minimes, voire nulles), puis fermez la demande ou placez-la dans l'arriéré avec une faible priorité, même dans les cas où l'idéalisme dit qu'elle devrait être modifiée ( ce n'est pas un de ces cas, mais mentionné pour ceux qui pensent que c'est le cas). L'idéalisme est idéal pour les conversations, mais les entreprises ne peuvent pas payer le loyer, les services publics, les employés, les taxes, etc. avec des idéaux.

4. @ jpmc26 est correct quant au besoin de communication, mais pas exactement quant à ce qui doit être communiqué. Oui, vous devez écouter ce que les autres demandent et chercher à comprendre leur raisonnement, ce qui inclut de poser des questions si vous n'êtes pas clair sur quoi que ce soit.

   TOUTEFOIS, la base de données n'est pas subordonnée à l'application, et les professionnels de la base de données (administrateurs, ingénieurs, quel que soit le nom utilisé par votre entreprise) ne sont pas subordonnés aux développeurs (comme cela semble être impliqué dans cette réponse). Vous ne travaillez pas pour les développeurs, vous travaillez pour l'entreprise, tout comme eux. Il s'agit d'un effort d'équipe et vous ne devriez pas demander pardon pour avoir fait votre travail. Cela dit, nous, les types de calcul, ne sommes pas (généralement) connus pour nos compétences en communication interhumaine, donc, vous devez vraiment vous assurer que les autres comprennent vous, quel est votre raisonnement, quelles sont vos responsabilités ET comment ces choses fonctionnent réellement.

   J'ai mis cette dernière partie parce qu'il y a un haut degré de malentendu, de désinformation et de manque de connaissances là-bas (même certains ici sur cette même page). Par exemple, il semble y avoir cette notion que toutes les règles sont des règles commerciales. Nous devons expliquer qu'il y a une distinction entre les règles de données et les règles métier (@Aaron a appelé cela "contrainte de workflow vs contrainte de données" dans un commentaire sur la question), et cela alors que la plupart des données naturellement appartient à l'application, certaines données appartiennent en fait au modèle de données. Un DBA doit-il dicter aux développeurs comment les données d'application seront limitées? Bien sûr que non. C'est notre travail de proposer comment les données d'application peuvent être contraintes. Si une violation d'une règle métier liée aux données d'application peut causer des dommages et que l'application n'est pas le 100% uniquement pour manipuler les données, alors peut-être qu'une contrainte de vérification pourrait vraiment aider (et elles ne sont pas pas difficile à changer ou à supprimer).

   MAIS, venant de l'autre sens, les développeurs ne devraient pas dicter la façon dont les données du modèle de données (c'est-à-dire les métadonnées) sont traitées. Cela inclut les champs d'audit (tels que le created_on/created_by colonnes) et les colonnes PK/FK (ces valeurs ne sont censées être connues qu'en interne et non communiquées aux clients). Ces données ne sont pas ce que l'application stocke sur les clients (même si l'application peut voir les valeurs et même les utiliser, comme avec les ID), c'est ce que le modèle de données stocke sur les données de l'application.

   Il est donc logique d'utiliser des règles de données pour protéger les données du modèle de données. Et cela n'implique pas que vous êtes sur le point de commencer à ajouter des contraintes ou des restrictions sur les données d'application. MAIS, il sera difficile de faire avancer la conversation d'une manière vraiment productive si cette distinction n'est pas comprise.

Donc:

1. Oui, j'aime l'idée d'expliciter DENY sur les colonnes d'audit, et j'ai proposé la même chose dans des endroits où j'ai déjà travaillé.

2. Pour l'anecdote, j'ai eu une conversation très similaire avec un développeur principal (un très bon), peut-être en 2000, lorsque j'ai commencé à ajouter des clés étrangères. Il a soutenu (assez sérieusement) qu'il s'agissait d'une ingénierie/idéalisme inutile (quelque chose comme ça, cela fait 17 ans depuis cette conversation) et ne valait pas le coup de la performance. Il était tout à fait clair que le nettoyage des données connexes devrait être géré dans la couche d'application. (oui, j'ai ajouté les FK parce qu'il n'allait pas être le seul à nettoyer les données orphelines que son code créerait inévitablement)

   Des années plus tard, il s'est excusé d'avoir avancé cet argument ;-)

Answer 3

Il s'agit probablement d'un problème XY. Le développeur n'est probablement pas particulièrement concerné par le blocage des mises à jour d'un champ vraiment constant comme created_on. Cet exemple particulier est une contrainte extrêmement modeste.

Le développeur est probablement préoccupé par le fait que l'équipe DBA (qui vous inclut) a l'intention d'ajouter tant de restrictions complexes que cela commence à entraver leur capacité à fonctionner efficacement, ou que lorsque quelque chose hors de l'ordinaire se produit ou que quelque chose change, l'équipe DBA va résister aux changements et entraver la capacité de l'équipe de développeurs à progresser. Il s'agit d'une préoccupation relativement raisonnable. Les bureaucraties et la perte de la capacité d'effectuer les changements nécessaires sont des événements réels, et l'encodage de contraintes trop nombreuses ou complexes peut avoir des effets négatifs sur les performances et sur la capacité de répondre aux changements des exigences.

Le développeur peut même ne pas réaliser que c'est la nature de leurs préoccupations. Ils sont probablement habitués à avoir le règne libre de la base de données, et abandonner ce niveau de liberté est difficile, surtout si vous savez que vous n'en avez jamais abusé. Ainsi, leur sentiment d'inquiétude de perdre la capacité de faire ce dont ils ont besoin pourrait être vague et mal défini.

Il y a donc quelques choses que vous devez faire pour apaiser ces peurs:

1. Communiquez fortement avec les développeurs. Assurez-vous de comprendre les besoins des fonctionnalités qu'ils essaient de créer et assurez-vous que vous êtes réactif lorsque des changements surviennent. Écoutez ce qu'ils ont à dire et travaillez dur pour trouver une solution qui équilibre leurs préoccupations avec les vôtres. Soyez prêt à vous plier lorsqu'ils ont des besoins légitimes. Assurez-vous qu'ils savent que vous êtes allié dans la construction du logiciel.
2. Soyez prudent lorsque vous introduisez des restrictions. Les restrictions, même celles destinées à assurer l'intégrité et la sécurité, peuvent rendre plus difficile l'adaptation au changement ou la gestion de circonstances imprévues. Comprenez donc que chaque restriction que vous ajoutez est tout aussi susceptible d'avoir un coût associé qu'elle est susceptible de réduire les coûts (à l'exception possible des clés primaires et étrangères, qui n'ont pratiquement aucun inconvénient). Soyez sûr que les restrictions que vous imposez sont vraiment nécessaires ou bénéfiques.
3. Je ne vois aucun signe que vous faites cela, mais je tiens à le mentionner pour les autres lecteurs: ne visualisez pas les données ou la base de données comme votre ou la responsabilité de votre équipe. Les données sont un atout pour toute l'entreprise. Sans système pour le stocker (la base de données) et scripts, outils ou applications pour le créer, le mettre à jour et le récupérer, les données ne valent rien. Parce que tout le monde doit utiliser cet actif, les données sont la responsabilité de tous. La base de données elle-même n'est qu'une partie de la valorisation des données.

Answer 4

Vous avez des déclarations contradictoires

• Colonnes qui ne doivent jamais être mises à jour
• Ils ont besoin de mettre à jour les valeurs pour une raison quelconque

Est-ce vraiment à vous de dicter le premier?

Vous jetez le moindre privilège pour que l'application fonctionne sans preuve, l'application n'aura jamais besoin de mettre à jour la valeur.

Qui est responsable de l'intégrité des données?

Avec les contraintes SQL, pouvez-vous garantir l'intégrité des données? Non, vous ne pouvez pas, car il existe souvent des règles métier qui vont au-delà de ce que peut faire une base de données.

VendorID should ne change jamais, mais que se passe-t-il si deux fournisseurs fusionnent. Ne jamais dire jamais.

Si l'équipe de l'application contamine les données et qu'elle a dit qu'elle avait besoin de cette autorité, c'est à elle. Si les équipes d'application travaillent pour vous, vous pouvez dicter.

La question appropriée est de savoir si l'application doit mettre à jour les données.