Der er ingen hemmelighed, at information får verden til at gå rundt i øjeblikket. Hvis en virksomhed varetager sin intellektuelle ejendomsret, og hver enkelt medarbejder nemt kan få den nødvendige information, kan virksomheden håbe på væksten. Hvis der er kaos i data, vil virksomheden fejle trods teamånden.
I denne artikel skal vi udforske det grundlæggende i databasesikkerheden og eksempler på informationsbeskyttelse i Oracle. Faktisk vil de teoretiske grundprincipper til beskyttelse af information i databasen, som vi vil overveje i denne artikel, også være nyttige for folk, der arbejder med andre databaser.
Adgangstilladelser
I de fleste virksomheder, jeg arbejdede for, havde alle administratorer og udviklere fuld adgang til databaser, ligesom en medarbejder i IT-afdelingen var en gud og kunne gøre alt, hvad de ville. Hvorfor sker det? Der er to grunde til dette:
- Mens de arbejder i én afdeling, kan medarbejderne møde hinanden i 8 timer hver dag og blive venner. Hvordan kan de ikke give adgang? Venskab er én ting, men forretning er forretning.
- At give nogle adgangsrettigheder eller ændre nogle konfigurationer kan kræve nogle privilegier. Nogle gange tror administratorer, at programmører konfigurerer indstillinger bedre. Således giver de programmører unødvendige adgangsrettigheder. I stedet må programmører ikke være involveret i administrationen og må ikke have nogen rettigheder til dette.
Efter min erfaring er det andet problem meget almindeligt, så vi vil analysere det i detaljer.
Når de udvikler programmer til databaser, kender programmører en superbrugeradgangskode eller har simpelthen databaseadministratorrettigheder. Dette er unødvendigt og absolut usikkert. Kun databaseadministratoren skal have fulde rettigheder. Selv afdelingslederen, direktøren og bedste venner kan have færre privilegier.
For eksempel, når man udvikler programmer, er det nok at have skemaejerrettighederne i Oracle-databasen, der gemmer arbejdstabeller. Disse rettigheder er nok til at oprette nye tabeller, pakker, indekser og andre objekter, samt til at give adgangsrettigheder til skemaobjekter til andre brugere. Du behøver ikke systemrettighederne for fuldtidsarbejde.
Hvis der ikke er nogen databaseadministrator på fuld tid, er det meget dårligt. Det er bedre, når der er nogen, der er ansvarlig for databasens ydeevne, optimering og sikkerhed. I det mindste skal du udpege en programmør, som vil være ansvarlig for dette og vil have eksklusive rettigheder.
Ifølge statistikker forårsager medarbejdere i virksomheden oftest datatab. På trods af dette faktum fortsætter de fleste virksomheder med at ignorere denne tråd, og forskellige databaser, der er gemt på diske med fri adgang, sælges selv i metroen.
Brugere og roller
Der er to objekttyper til at give adgangsrettigheder i databaser:brugere og roller. Roller er nogle grupper, der kombinerer brugere, der skal have lignende rettigheder. For eksempel kan alle revisorer kræve adgang til økonomiske dokumenter. For at forhindre dig i at give rettigheder til hver enkelt revisor, kan vi kombinere dem i en rolle med den nødvendige adgang.
Som du kan se, ligner princippet om roller grupper i Windows-operativsystemet. Alligevel har det nogle forskelle. Ikke uden grund kan alle tre objekttyper såsom brugere, grupper og roller implementeres i databasen. Det er dog kun brugere og roller, der er implementeret i de fleste databaser. Det er nødvendigt at administrere og overvåge alle disse objekter, så hver bruger, der opnår de rettigheder, rollerne giver, kan få adgang til de data, der faktisk er nødvendige for at løse opgaver. Det er nødvendigt at bruge adgangsrettigheder som regler for en firewall. Ved at bruge disse rettigheder kan du løse det samme problem – at tillade en bruger kun at udføre bestemte opgaver og forhindre mulige tab eller korruption.
Ved hjælp af roller er det ret praktisk at kontrollere adgang, give tilladelser eller blokere hele gruppen af brugere. Den ene rolle kan inkluderes i den anden og dermed arve dens adgangsrettigheder. Derfor kan vi skabe en hierarkisk struktur af rettigheder.
Alle medarbejdere med adgangsrettigheder til en virksomhedsdatabase kan inkluderes i en enkelt rolle med minimumsrettigheder. Nu, hvis du har brug for yderligere privilegier, adgang til bestemte tabeller, skal du tilføje en bruger til andre roller (hvis en gruppe kræver den samme adgang) eller give en bestemt konto rettighederne.
I programmet er det for at kontrollere adgangen til tabellerne muligt at kontrollere resultatet for fejl efter hvert forsøg på at åbne datasættet. Hvis der opstår en adgangsfejl, spærres adgangen til den angivne tabel for en bruger. Der er således ikke behov for at implementere adgangsrettighederne til klientapplikationen. Men hvis du ønsker at implementere dette, vil der ikke ske nogen skade. Jeg kan i hvert fald ikke se noget kritisk i dette; det ser ud til at have den modsatte effekt.
Sikkerhedsrevision
Hvis hver bruger arbejder under deres egen konto i din database, kan du kalde brugervariablen for at bestemme den aktuelle bruger, for eksempel:
SELECT user from dual
Denne forespørgsel vil returnere et brugernavn, under hvilket forbindelsen til serveren åbnes. Hvis flere personer kan logge ind med ét navn, vil denne forespørgsel returnere det samme navn for begge, og det ville være ubrugeligt for revisionen. Især hvis lockout-kontrol forekommer på serverniveau.
Hvis flere brugere kan logge på med samme brugernavn, er det kompliceret, men stadig muligt, at identificere, hvem der er logget ind på kontoen. Følgende forespørgsel gør det muligt at få de detaljerede oplysninger om sessionen:
select s.user#, s.username, s.osuser, s.terminal, s.program from sys.v_$session s WHERE username=user
Som du kan se, returnerede forespørgslen brugernavnet, forbundet til databasen, et navn i operativsystemet, et terminalbrugernavn og et program.
Her kan du få adgang til v_$session-visningen fra sys-systemskemaet. Denne visning returnerer nogle oplysninger om forbindelserne til serveren. I WHERE-sætningen begrænser vi outputtet til kun den aktuelle bruger. Som et resultat returnerer forespørgslen bruger-id, navn, navn i operativsystemet, terminal og det program, hvorfra forbindelsen blev etableret.
Når du kender et brugernavn og et terminalnavn, kan du med sikkerhed identificere en bruger. For at vide, hvilke roller den aktuelle bruger blev tilføjet til, kan du køre følgende forespørgsel:
SELECT GRANTED_ROLE FROM dba_role_privs WHERE grantee=user
Kontosikkerhed
Vi vil ikke sige, at der ikke skal være standardadgangskoder. Nogle databaser, for eksempel MySQL, fejler, når de opretter en enkel og velkendt systemadgangskode efter installationen. Vi vil heller ikke sige, at adgangskoden skal være kompliceret. Denne regel gælder for alle it-områder og bør være kendt selv for en nybegynder. Vi skal tale om databaseproblemer.
Efter min erfaring, når udviklere udvikler virksomhedsprogrammer, bruger udviklere den samme konto til at få adgang til en database. Parametrene for denne konto registreres direkte i programmet, mens adgangen til bestemte moduler, herunder regnskab, lager, personaleafdeling osv. implementeres på en programmatisk måde. På den ene side er denne metode praktisk, fordi programmet kan oprette forbindelse til databasen med administratorrettigheder og ikke skal tage sig af rollerne og adgangsrettighederne til tabellerne. På den anden side er denne metode langt fra sikker. Niveauet af brugere vokser, og venner af din virksomheds medarbejdere kan blive uddannet inden for sikkerhed og hacking. Efter at have kendskab til navnet og adgangskoden, som programmet forbinder til databasen under, kan en almindelig bruger få flere muligheder, end du ønskede.
SQL-sproget er ikke et hemmeligt og kompliceret sprog. Der er mange programmer, som du nemt kan se alle data i databasen. Med brugernavnet og adgangskoden kan enhver stjæle alle dine data. Den vil således blive solgt i enhver bod, der sælger diske.
Et brugernavn og en adgangskode må aldrig gemmes i programmet. Adgangen til programmet skal også være begrænset til og umulig for tredjeparter. Det er ret logisk at kombinere begge logins til ét. Det er nødvendigt at oprette en separat konto på databaseserveren med de nødvendige minimumsrettigheder for hver bruger i organisationen. Disse navne og adgangskoder skal bruges, når du logger på programmet. Du kan bruge en fælles og meget effektiv logik – hvis du kan logge ind i databasen med de indtastede data, er adgangen tilladt; hvis ikke, skal du afbryde programmet. Denne proces er enkel og effektiv, fordi vi brugte databaseautorisation.
For at kontrollere, at brugere ikke arbejder samtidigt fra to forskellige computere under samme navn, kan du udføre følgende forespørgsel:
select s.username, s.terminal, count(*) from sys.v_$session s WHERE username=user HAVING count(*)>1 GROUP BY s.username, s.terminal
Faktisk må den ikke returnere nogen post.
Visninger
Visninger er en meget praktisk måde at slukke for datastrukturen og samtidig opbygge et ekstra beskyttelsesniveau. Det er rigtigt, at synspunkter har en negativ indvirkning på produktiviteten, men de har en positiv indvirkning på sikkerheden. Vi kan give deres egne adgangsrettigheder, mens tabellerne, hvorfra dataene hentes, kan forblive utilgængelige for denne konto.
Hvornår er det bedre at bruge visninger? Lad os først definere, hvad deres ulemper er. En visning er en SELECT-sætning til at hente data. Den kan få adgang til både et og flere borde. Hvis du blot vælger data fra visningen, vil der ikke være noget tab af ydeevne. Vi kan dog bruge visninger i andre forespørgsler til at vælge data og henvise til dem med hensyn til tabellerne. For eksempel:
SELECT list of fields FROM view, table_1, table_2 WHERE some parameters
I dette tilfælde henter forespørgslen data fra visningen og to tabeller. Derudover kan vi se en relation mellem alle objekterne, og der kan indstilles en yderligere betingelse.
Lad os nu se på forespørgslen, som databaseoptimeringsværktøjet ser det:
SELECT list of fields FROM (SELECT ...), table1, table2 WHERE some parameters
I dette tilfælde erstattede jeg visningen med en abstrakt SELECT-sætning i parentes, som visningen består af. Det viser sig, at serveren ser en forespørgsel med en underforespørgsel. Hvis underforespørgslen returnerer dynamiske data i stedet for en statisk værdi, vil dette datavalg arbejde langsommere, end hvis vi skrev den samme forespørgsel uden underforespørgslen.
Datasikkerhed
Du bør aldrig give fuld adgang til genstande uden et særligt behov. Jeg begynder altid kun at give rettigheder til at tillade datavalg med SELECT-sætningen. Hvis brugeren virkelig har brug for at indsætte nye poster, og de ikke kan udføre de opgaver, der er tildelt dem, skal du i dette tilfælde tilføje tilladelsen til INSERT-sætningen i den angivne tabel.
De farligste handlinger for dataene er ændring og sletning, nemlig henholdsvis OPDATERING og SLETT. Du skal give disse rettigheder omhyggeligt. Sørg for, at dataene kan ændres eller slettes. Kun i dette tilfælde skal du vælge de relevante rettigheder. Nogle tabeller er kun udvidet af natur.
Det er nødvendigt at være sikker på, at data ofte vil blive påvirket. For eksempel kan tabellen over medarbejdere udvides og ændres, men en enkelt post bør aldrig slettes. Fjernelsen kan påvirke baggrunden for medarbejdernes arbejde, rapportering og dataintegritet. Det tilfælde, hvor en personalemedarbejder ved et uheld tilføjer en ekstra post og ønsker at slette den, er stadig muligt. Sådanne tilfælde er dog sjældne, og fejlen kan rettes af databaseadministratoren. Vi forstår, at ingen ønsker at overanstrenge sig, og det er nemmere at give en tilladelse, men sikkerhed er mere værdifuldt.
Tildeling af rettigheder udføres ved hjælp af GRANT-operatøren. Generelt ser det sådan ud:
TILDEL hvad der skal give rettigheder til ON-objekter TIL brugere eller roller
For eksempel giver følgende forespørgsel ret til at indsætte og se TestTable-tabellen til Bruger1:
GRANT Select, Insert ON TestTable TO User1
Udenlandske nøgler
Mange brugere er bange for fremmednøgler, fordi de normalt ikke tillader sletning af data, når der er en ydre joinforbindelse. Problemet kan let løses, hvis der etableres en kaskadesletning. De fleste specialister kan dog ikke lide denne mulighed. En latterlig handling kan ødelægge meget vigtige data uden nogen anmodninger om bekræftelse. Tilknyttede data skal slettes eksplicit, og kun hvis brugeren bevidst har bekræftet, at dataene kan slettes.
Vær ikke bange for fremmednøgler. De giver os en bekvem måde at kontrollere dataintegriteten fra databaseserveren på, så dette er sikkerhed, der aldrig skader. At der kan være problemer med sletningen er kun en fordel. Det er bedre ikke at slette dataene i stedet for at miste dem for altid. Fremmednøglen sammen med indekset reducerer ikke ydeevnen. Dette er blot en lille kontrol, når du sletter data eller ændrer nøglefeltet, som dataene er forbundet til i forskellige tabeller.
Sikkerhedskopi
Sikkerhedskopiering er også en af de sikkerhedsfaktorer, vi ignorerer før det første tab af data. Men personligt ville jeg have inkluderet det i de vigtigste. Datatabet kan ikke kun skyldes hackere og uegnede brugere, men også på grund af udstyrsfejl. Fejl i udstyret kan føre til databasetab, hvis gendannelse kan tage timer eller endda dage.
Det er nødvendigt at udvikle den mest effektive backuppolitik på forhånd. Hvad menes derved? Nedetid forårsaget af tab af data og indtil tidspunktet for genoprettelse af arbejdskapaciteten bør være minimal. Datatabet bør også være minimalt, og sikkerhedskopieringen bør ikke påvirke brugerens arbejde. Hvis der er penge og muligheder, er det bedre at bruge sådanne systemer som RAID, cluster eller endda datareplikering.
Sikkerhedskopiering og gendannelse er et særskilt og interessant emne. Vi kunne ikke komme ind på det her, men vi vil ikke overveje det i detaljer.
Oversigt
Vi har overvejet grundlæggende sikkerhed, især for Oracle. Glem ikke, at beskyttelsen fra databasen kun er på ét niveau, mens beskyttelsen skal være på flere niveauer. For at sove lidt med et klart sind er det nødvendigt at implementere hele sikkerhedsfunktionerne på netværket, servere og alle computere, inklusive antivirus, anti-spyware, VPN, IDS osv. Jo flere niveauer af beskyttelse der er, jo mere svært vil det være at overvinde dem.
Der bør være en klar sikkerhedspolitik og kontrol. Hvis en medarbejder forlader, slettes vedkommendes konto. Hvis du har brugere, der arbejder med den samme adgangskode eller bruger en gruppeadgangskode til at udføre opgaver, skal alle disse adgangskoder ændres. For eksempel, hvis en administrator forlader, og du har alle administratorer, der bruger den samme konto, skal du ændre adgangskoden.
Sikkerheden er nødvendig. Du skal beskytte dig selv ikke kun mod hackere, men også mod "nybegyndere", som kan ødelægge data på grund af deres uerfarenhed. En god sikkerhedspolitik hjælper med at forhindre sådanne tilfælde, og denne mulighed kan ikke udelukkes. Det er bedre at give mulighed for at sikre data fra uerfarenhed på forhånd end at miste en masse tid til at gendanne data og få unødvendig nedetid.
Læs også:
Indstilling af databaseadgangstilladelser