Comment assurer l'intégrité référentielle pour protéger vos données sql

Vous pouvez penser que si vous pouvez contrôler qui voit, crée, modifie et supprime les données dans une table SQL, vous êtes bien protégé. Contre les plus menaces, vous sont. Un pirate bien informé, cependant, peut encore saccager la maison en utilisant une méthode indirecte.

Une base de données relationnelle correctement conçu a l'intégrité référentielle, ce qui signifie que les données dans une table de la base est en accord avec les données de toutes les autres tables. Pour assurer l'intégrité référentielle, les concepteurs de bases de données d'appliquer des contraintes aux tables qui restreignent les utilisateurs de données peuvent entrer dans les tableaux.

Mais voici l'inconvénient de cette protection: Si vous avez une base de données avec les contraintes d'intégrité référentielle, un utilisateur peut éventuellement créer une nouvelle table qui utilise une colonne dans une table confidentielles comme clé étrangère. Cette colonne sert alors de lien par lequel quelqu'un pourrait voler des informations confidentielles. Oops.

Disons, par exemple, que vous êtes un célèbre Wall Street analyste boursier. Beaucoup de gens croient en l'exactitude de vos choix d'actions, de sorte que chaque fois que vous recommandez un stock à vos abonnés, beaucoup de gens achètent ce stock, et sa valeur augmente.

Vous gardez votre analyse dans une base de données, qui contient une table nommée FOUR_STAR. Vos principales recommandations pour votre prochain bulletin sont dans ce tableau. Naturellement, vous limitez l'accès à FOUR_STAR si ce mot ne fuit pas au public avant d'investir vos abonnés payants reçoivent le bulletin.

Vous êtes toujours vulnérable, cependant, si quelqu'un d'autre peut créer une nouvelle table qui utilise le champ de nom du stock FOUR_STAR comme une clé étrangère, comme le montre l'exemple de la commande suivante:

CREATE TABLE HOT_STOCKS (Stock CARACTERE (30) RÉFÉRENCES FOUR_STAR) -

Le pirate peut maintenant essayer d'insérer le nom de toutes les actions sur le New York Stock Exchange, l'American Stock Exchange et le NASDAQ dans la table. Ces inserts qui réussissent disent le pirate stocks qui correspondent aux actions que vous nommez dans votre table confidentielle. Il ne faut pas longtemps pour le pirate d'extraire votre liste entière des stocks.

Vous pouvez vous protéger contre les hacks tels que celui de l'exemple précédent en étant très prudent sur la saisie des déclarations similaires à ce qui suit:

RÉFÉRENCES DE SUBVENTION (stock) SUR FOUR_STARTO SECRET_HACKER-

Il est clair que cela est exagéré. Vous auriez jamais accorder tout type d'accès à une table critique à une personne digne de confiance, diriez-vous? Non, si vous avez réalisé ce que vous faisiez. Cependant, les pirates aujourd'hui ne sont pas seulement habile techniquement. Ils sont aussi maîtres de tromper les gens en faisant ce qu'ils auraient normalement pas faire. Rampe jusqu'à la pleine alerte chaque fois qu'un bonimenteur mentionne quoi que ce soit lié à vos informations confidentielles.

Éviter d'accorder des privilèges aux personnes qui pourraient en abuser. Certes, les gens ne viennent pas avec des garanties imprimés sur leurs fronts. Mais si vous ne prêtez pas votre nouvelle voiture à une personne pour un long voyage, vous ne devriez pas lui accorder la RÉFÉRENCES privilège sur une table importante, soit.

L'exemple précédent offre une bonne raison de maintenir un contrôle attentif de la RÉFÉRENCES privilège. Voici deux autres raisons pour lesquelles vous devriez maintenir le contrôle attentif de RÉFÉRENCES:

• Si l'autre personne indique une contrainte dans HOT STOCKS en utilisant un LIMITER option et vous essayez de supprimer une ligne de votre table, le SGBD vous dit que vous ne pouvez pas, parce que cela serait violer une contrainte d'intégrité référentielle.

• Si vous voulez utiliser le DROP commande de détruire votre table, vous trouvez que vous devez obtenir l'autre personne DROP sa contrainte (ou sa table) en premier.

La ligne de fond: Permettre une autre personne de préciser les contraintes d'intégrité sur votre table non seulement introduit une faille de sécurité potentielle, mais signifie également que l'autre utilisateur obtient parfois sur votre chemin.