Databasesikkerhet - Database security

Databasesikkerhet angår bruk av et bredt spekter av informasjonssikkerhetskontroller for å beskytte databaser (potensielt inkludert dataene, databaseapplikasjonene eller lagrede funksjoner, databasesystemene, databaseserverne og de tilknyttede nettverkskoblinger) mot kompromisser av konfidensialitet, integritet og tilgjengelighet. Det involverer forskjellige typer eller kategorier av kontroller, for eksempel teknisk, prosessuell/administrativ og fysisk.

Sikkerhetsrisiko for databasesystemer inkluderer for eksempel:

  • Uautorisert eller utilsiktet aktivitet eller misbruk av autoriserte databasebrukere, databaseadministratorer eller nettverks-/systemadministratorer, eller av uautoriserte brukere eller hackere (f.eks. Upassende tilgang til sensitive data, metadata eller funksjoner i databaser, eller upassende endringer i databaseprogrammene, strukturene eller sikkerhetskonfigurasjoner);
  • Malware -infeksjoner som forårsaker hendelser som uautorisert tilgang, lekkasje eller avsløring av personlige eller proprietære data, sletting av eller skade på dataene eller programmene, avbrudd eller nektelse av autorisert tilgang til databasen, angrep på andre systemer og uventet svikt i databasetjenester;
  • Overbelastning, ytelsesbegrensninger og kapasitetsproblemer som resulterer i at autoriserte brukere ikke kan bruke databaser etter hensikten;
  • Fysisk skade på databaseservere forårsaket av branner eller flom i datarom, overoppheting, lyn, utilsiktet væskesøl, statisk utladning, elektroniske havarier/utstyrsfeil og foreldelse;
  • Design feil og programmeringsfeil i databaser og de tilhørende programmene og systemene, og skap forskjellige sikkerhetsproblemer (f.eks. Uautorisert eskalering av privilegier ), tap av data/korrupsjon, forringelse av ytelse osv.;
  • Datakorrupsjon og/eller tap forårsaket av registrering av ugyldige data eller kommandoer, feil i databaser eller systemadministrasjonsprosesser, sabotasje/kriminell skade etc.

Ross J. Anderson har ofte sagt at store databaser av sin natur aldri vil være fri for misbruk ved brudd på sikkerheten; hvis et stort system er designet for enkel tilgang blir det usikkert; Hvis den er vanntett, blir den umulig å bruke. Dette er noen ganger kjent som Andersons regel.

Mange lag og typer informasjonssikkerhetskontroll er passende for databaser, inkludert:

Databaser har i stor grad blitt sikret mot hackere gjennom nettverkssikkerhetstiltak som brannmurer og nettverksbaserte system for inntrengingsdeteksjon . Selv om nettverkssikkerhetskontroller fortsatt er verdifulle i denne forbindelse, har sikring av databasesystemene selv, og programmene/funksjonene og dataene i dem, uten tvil blitt mer kritiske ettersom nettverk i økende grad åpnes for bredere tilgang, spesielt tilgang fra Internett. Videre har system-, program-, funksjon- og datatilgangskontroller, sammen med tilhørende brukeridentifikasjon, autentisering og rettighetsstyringsfunksjoner, alltid vært viktig for å begrense og i noen tilfeller logge aktivitetene til autoriserte brukere og administratorer. Med andre ord, dette er komplementære tilnærminger til databasesikkerhet, som fungerer både fra utsiden og inn og ut.

Mange organisasjoner utvikler sine egne "baseline" sikkerhetsstandarder og design som beskriver grunnleggende sikkerhetskontrolltiltak for sine databasesystemer. Disse kan gjenspeile generelle krav til informasjonssikkerhet eller forpliktelser som er pålagt av retningslinjer for informasjonssikkerhet og gjeldende lover og forskrifter (f.eks. Angående personvern, økonomistyring og rapporteringssystemer), sammen med allment akseptert god databasesikkerhetspraksis (for eksempel hensiktsmessig herding av de underliggende systemene) og kanskje sikkerhetsanbefalinger fra det relevante databasesystemet og programvareleverandører. Sikkerhetsdesignene for spesifikke databasesystemer spesifiserer vanligvis ytterligere sikkerhetsadministrasjons- og administrasjonsfunksjoner (for eksempel administrasjon og rapportering av brukertilgangsrettigheter, logghåndtering og analyse, databasereplikering/-synkronisering og sikkerhetskopier) sammen med ulike forretningsdrevne informasjonssikkerhetskontroller i databasen programmer og funksjoner (f.eks. validering av dataoppføring og revisjonsspor ). Videre er forskjellige sikkerhetsrelaterte aktiviteter (manuelle kontroller) normalt innlemmet i prosedyrer, retningslinjer etc. knyttet til design, utvikling, konfigurasjon, bruk, administrasjon og vedlikehold av databaser.

Privilegier

To typer privilegier er viktige knyttet til databasesikkerhet i databasemiljøet: systemprivilegier og objektprivilegier.

Systemrettigheter

Systemrettigheter lar en bruker utføre administrative handlinger i en database.

Objektprivilegier

Objektrettigheter tillater bruk av visse operasjoner på databaseobjekter som er godkjent av en annen bruker. Eksempler inkluderer: bruk, velg, sett inn, oppdater og referanser.

Rektor for minst privilegium og arbeidsdeling:

Databaser som faller under internkontroll (det vil si data som brukes til offentlig rapportering, årsrapporter, etc.) er underlagt arbeidsplikt, noe som betyr at det må være adskillelse av oppgaver mellom utvikling og produksjon. Hver oppgave må valideres (via kodegjennomgang/friske øyne) av en tredje person som ikke skriver den faktiske koden. Databaseutvikleren bør ikke kunne utføre noe i produksjonen uten en uavhengig gjennomgang av dokumentasjonen/koden for arbeidet som utføres. Vanligvis er utviklerens rolle å overføre kode til en DBA; Men på grunn av nedskjæringene som har blitt forårsaket av den økonomiske nedgangen, er det ikke sikkert at en DBA er lett tilgjengelig. Hvis en DBA ikke er involvert, er det i det minste viktig for en kollega å gjennomføre en kodevurdering. Dette sikrer at utviklerens rolle er klart atskilt.

Et annet punkt med intern kontroll er overholdelse av prinsippet om å gi minst mulig privilegier , spesielt i produksjonen. For å gi utviklere mer tilgang til arbeidet sitt, er det mye tryggere å bruke etterligning for unntak som krever forhøyede privilegier (f.eks. EXECUTE AS eller sudo for å gjøre det midlertidig). Ofte kan utviklere avvise dette som "overhead" mens de er på vei til kodende ære. Vær imidlertid oppmerksom på at DBA -er må gjøre alt som anses som ansvarlig fordi de er de facto dataforvaltere for organisasjonen og må overholde forskrifter og lov.

Sårbarhetsvurderinger for å håndtere risiko og etterlevelse

Ytterligere informasjon: applikasjonssikkerhet

En teknikk for å evaluere databasesikkerhet innebærer å utføre sårbarhetsvurderinger eller penetrasjonstester mot databasen. Testere prøver å finne sikkerhetsproblemer som kan brukes til å beseire eller omgå sikkerhetskontroller, bryte seg inn i databasen, kompromittere systemet etc. Databaseadministratorer eller informasjonssikkerhetsadministratorer kan for eksempel bruke automatiske sårbarhetsskanninger for å finne feilkonfigurasjon av kontroller (ofte referert til som 'drift') innenfor lagene nevnt ovenfor sammen med kjente sårbarheter i databaseprogramvaren. Resultatene av slike skanninger brukes til å herde databasen (forbedre sikkerheten) og stenge de spesifikke sårbarhetene som er identifisert, men andre sårbarheter forblir ofte ukjente og uadresserte.

I databasemiljøer der sikkerhet er kritisk, forbedrer kontinuerlig overvåking for overholdelse av standarder sikkerheten. Sikkerhetsoverensstemmelse krever blant annet prosedyrer, patchbehandling og gjennomgang og håndtering av tillatelser (spesielt offentlige) som er gitt til objekter i databasen. Databaseobjekter kan inneholde tabell eller andre objekter som er oppført i tabellkoblingen. Tillatelsene som gis for SQL -språkkommandoer på objekter, vurderes i denne prosessen. Samsvarsovervåking ligner sårbarhetsvurdering, bortsett fra at resultatene av sårbarhetsvurderinger generelt driver sikkerhetsstandardene som fører til det kontinuerlige overvåkingsprogrammet. I hovedsak er sårbarhetsvurdering en foreløpig prosedyre for å bestemme risiko der et samsvarsprogram er prosessen med løpende risikovurdering.

Samsvarsprogrammet bør ta hensyn til eventuelle avhengigheter på programvarenivå , siden endringer på databasenivå kan ha effekter på applikasjonsprogramvaren eller applikasjonsserveren .

Abstraksjon

Applikasjonsnivå autentisering og autoriseringsmekanismer kan være effektive midler for å tilveiebringe abstraksjon fra databasen laget. Den primære fordelen med abstraksjon er den med en enkelt påloggingskapasitet på tvers av flere databaser og plattformer. Et enkelt påloggingssystem lagrer databasebrukerens legitimasjon og autentiserer til databasen på vegne av brukeren. Abstraksjon er ideen om å gjøre komplekse ideer lettere å forstå.

Overvåkning av databaseaktivitet (DAM)

Et annet sikkerhetslag av mer sofistikert art inkluderer sanntids databaseaktivitetsovervåking , enten ved å analysere protokolltrafikk (SQL) over nettverket, eller ved å observere lokal databaseaktivitet på hver server ved hjelp av programvareagenter, eller begge deler. Bruk av agenter eller innfødt logging er nødvendig for å fange opp aktiviteter som utføres på databaseserveren, som vanligvis inkluderer aktivitetene til databaseadministratoren. Agenter tillater at denne informasjonen fanges opp på en måte som ikke kan deaktiveres av databaseadministratoren, som har muligheten til å deaktivere eller endre opprinnelige revisjonslogger.

Analyse kan utføres for å identifisere kjente utnyttelser eller brudd på retningslinjer, eller grunnlinjer kan fanges opp over tid for å bygge et normalt mønster som brukes for påvisning av unormal aktivitet som kan være tegn på inntrengning. Disse systemene kan gi et omfattende databasekontrollspor i tillegg til mekanismer for påvisning av inntrengning, og noen systemer kan også gi beskyttelse ved å avslutte brukersesjoner og/eller sette karantene i bruk som viser mistenkelig oppførsel. Noen systemer er designet for å støtte arbeidsoppdeling (SOD), som er et typisk krav for revisorer. SOD krever at databaseadministratorene som vanligvis overvåkes som en del av DAM, ikke kan deaktivere eller endre DAM -funksjonaliteten. Dette krever at DAM -revisjonssporet lagres sikkert i et eget system som ikke administreres av databaseadministrasjonsgruppen.

Innfødt tilsyn

I tillegg til å bruke eksterne verktøy for overvåking eller revisjon, er native database revisjonsfunksjoner også tilgjengelige for mange databaseplattformer. De opprinnelige revisjonssporene trekkes ut regelmessig og overføres til et utpekt sikkerhetssystem der databaseadministratorene ikke har/bør ha tilgang. Dette sikrer et visst nivå av adskillelse av oppgaver som kan gi bevis på at de opprinnelige revisjonssporene ikke ble endret av godkjente administratorer, og bør utføres av en sikkerhetsorientert senior DBA-gruppe med leserettigheter til produksjon. Å slå på native påvirker ytelsen til serveren. Vanligvis gir de opprinnelige revisjonssporene til databaser ikke tilstrekkelige kontroller for å håndheve arbeidsoppdeling; Derfor gir nettverks- og/eller kjernemodulnivå vertsbaserte overvåkingskapasiteter en høyere grad av tillit til rettsmedisin og bevaring av bevis.

Prosess og prosedyrer

Et godt databasesikkerhetsprogram inkluderer regelmessig gjennomgang av privilegier gitt til brukerkontoer og kontoer som brukes av umiddelbare prosesser. For individuelle kontoer forbedrer et tofaktorautentiseringssystem sikkerhet, men legger til kompleksitet og kostnader. Kontoer som brukes i automatiserte prosesser krever passende kontroller rundt passordlagring, for eksempel tilstrekkelig kryptering og tilgangskontroller for å redusere risikoen for kompromisser.

I forbindelse med et godt databasesikkerhetsprogram, kan et passende program for katastrofegjenoppretting sikre at tjenesten ikke blir avbrutt under en sikkerhetshendelse, eller en hendelse som resulterer i en avbrudd i det primære databasemiljøet. Et eksempel er replikering for de primære databasene til nettsteder som ligger i forskjellige geografiske regioner.

Etter at en hendelse har oppstått, kan databaseforensikk brukes for å bestemme omfanget av bruddet og for å identifisere passende endringer i systemer og prosesser.

Se også

Referanser

Eksterne linker