Sådan sikrer du referentiel integritet for at beskytte dine SQL-data - dummier

Du kan måske tro, at hvis du kan styre hvem der ser, opretter, ændrer og sletter data i et SQL-bord, godt beskyttet. Mod mest trusler er du. En kyndig hacker kan dog stadig ransackere huset ved hjælp af en indirekte metode.

En korrekt designet relational database har referential integritet, , hvilket betyder at dataene i en tabel i databasen er i overensstemmelse med dataene i alle de andre tabeller. For at sikre referentiel integritet anvender databasedesignere begrænsninger til tabeller, der begrænser de data, brugerne kan indtaste i tabellerne.

Men her er ulempen ved denne beskyttelse: Hvis du har en database med referentielle integritetsmæssige begrænsninger, kan en bruger muligvis oprette et nyt bord, der bruger en kolonne i et fortroligt bord som fremmednøgle. Denne kolonne tjener derefter som et link, hvorigennem nogen muligvis kan stjæle fortrolige oplysninger. Ups.

Sig for eksempel at du er en berømt Wall Street-lageranalytiker. Mange mennesker tror på rigtigheden af ​​dine lageroptioner, så når du anbefaler et lager til dine abonnenter, køber mange mennesker det lager, og dets værdi stiger.

Du gemmer din analyse i en database, som indeholder en tabel med navnet FOUR_STAR. Dine øverste anbefalinger til dit næste nyhedsbrev er i den tabel. Du begrænser naturligvis adgangen til FOUR_STAR, så ordet lækker ikke ud til investorer, før dine betalende abonnenter modtager nyhedsbrevet.

Du er dog stadig sårbar, hvis nogen andre kan oprette et nyt bord, der bruger feltnavnets felt på FOUR_STAR som fremmednøgle, som vist i følgende kommandoeksempel:

CREATE TABLE HOT_STOCKS (Aktiekarakter (30) REFERENCER FOUR_STAR);

Hackeren kan nu forsøge at indsætte navnet på hver bestand på New York Stock Exchange, American Stock Exchange og NASDAQ i tabellen. De indsætninger, der lykkes, fortæller hackeren, hvilke lagre svarer til de bestande, som du nævner i dit fortrolige bord. Det tager ikke lang tid for hackeren at udtrække hele din liste over aktier.

Du kan beskytte dig selv mod hack som den i det foregående eksempel ved at være meget forsigtig med at indtaste udsagn svarende til følgende:

GRANT REFERENCES (Stock) PÅ FOUR_STAR TO SECRET_HACKER;

Det er klart, at dette er en overdrivelse. Du ville aldrig give nogen form for adgang til et kritisk bord til en usikker person, ville du? Ikke hvis du indså, hvad du gjorde.Imidlertid er hackere i dag ikke bare kloge teknisk. De er også mestre af vildledende mennesker til at gøre, hvad de normalt ikke ville gøre. Ramp op til fuld advarsel, når en glat talker nævner alt relateret til dine fortrolige oplysninger.

Undgå at give privilegier til personer, der misbruger dem. Sandt nok kommer folk ikke med garantier trykt på deres pande. Men hvis du ikke ville låne din nye bil til en person for en lang tur, skal du nok ikke give ham REFERENCES-privilegiet på et vigtigt bord heller.

Det foregående eksempel giver en god grund til at opretholde nøje kontrol med REFERENCES-privilegiet. Her er to andre grunde til, at du bør holde nøje kontrol med REFERENCER:

• Hvis den anden person angiver en begrænsning i HOT STOCKS ved at bruge en RESTRICT-indstilling, og du forsøger at slette en række fra dit bord, fortæller DBMS dig, at du kan 't, fordi det ville krænke en referential integritet begrænsning.

• Hvis du vil bruge DROP-kommandoen til at ødelægge din tabel, finder du, at du skal få den anden person til at DROP hans begrænsning (eller hans bord) først.

Den nederste linje: At aktivere en anden person til at angive integritetsmæssige begrænsninger på bordet introducerer ikke kun et potentielt sikkerhedsbrud, men betyder også, at den anden bruger nogle gange kommer i vejen.