Beskyttelse av informasjon i underd. Sikre beskyttelse av personopplysninger i Oracle-databasen

Arbeidet undersøker noen av de viktigste lovkravene for beskyttelse av personopplysninger (PD). Generelle tilnærminger for å beskytte databaser administrert av en DBMS presenteres. Et eksempel på PD-beskyttelse som tar hensyn til lovkrav for Oracle-plattformen er vist - en av de mest brukte i mellomstore og store informasjonssystemer.

Lov om beskyttelse av personopplysninger er ikke implementert. Hvorfor?

Til å begynne med, la oss huske noen bestemmelser i føderal lov nr. 152 "Om personopplysninger".

I henhold til lovens artikkel 3 er "en operatør et statlig organ, kommunalt organ, juridisk enhet eller enkeltperson som organiserer og (eller) utfører behandling av personopplysninger, samt bestemmer formål og innhold for behandlingen av personopplysninger. data." Dermed kommer vi til konklusjonen som vi vil fortsette: nesten alle juridiske enheter i Den russiske føderasjonen er potensielle PD-operatører.

Loven sier også eksplisitt at behandling av personopplysninger betyr nesten alt som kan gjøres med dem, fra mottak av data til depersonalisering og destruksjon: «behandling av personopplysninger - handlinger (operasjoner) med personopplysninger, inkludert innsamling, systematisering, akkumulering , lagring, avklaring (oppdatering, endring), bruk, distribusjon (inkludert overføring), depersonalisering, blokkering, ødeleggelse av personlige data."

I tillegg inneholder kravene i loven "om beskyttelse av personopplysninger" nr. 152-FZ noen, for å si det mildt, uvanlige prosedyrer for russiske organisasjoner, for eksempel:

• innhente samtykke fra borgere til å behandle deres personopplysninger, inkludert (når nødvendig) overføring til tredjeparter;
• fastsettelse av sammensetningen av personopplysninger for hvert informasjonssystem som behandler personopplysninger (ISPD);
• klassifisering av ISPD etter datavolum og sikkerhetsegenskaper avhengig av vurderingen av mulig skade på registrerte;
• utarbeidelse og organisering av regelmessige meldinger om behandling av personopplysninger til det autoriserte organet.

La oss merke seg at det store flertallet av russiske organisasjoner ikke har praksisen med å oppfylle slike krav. Det er ingen etablerte gjensidige regler tillitsforhold For eksempel er det ytterst sjelden at det utarbeides en tilbudsavtale om samtykke til bruk av personopplysninger til borgere. Men denne tilnærmingen har vært vellykket praktisert i utviklede land i ganske lang tid. Og en ting til: selv om en slik avtale klart vil definere hvilke typer behandling av personopplysninger som er tillatt av en bestemt organisasjon, samt hvem som spesifikt vil bli holdt ansvarlig for brudd på de avtalte behandlingstypene og kompromittering av personopplysninger, få innbyggere ville bestemme seg for å inngå en slik avtale. Gitt vagheten i ordlyden i lovgivningen, er det åpenbart at selv om en borger ga sitt samtykke til behandlingen av hans personopplysninger, ville han uansett være helt avhengig av hvor klokt og samvittighetsfullt operatøren ville tolke bestemmelsene i lov.

Det er verdt å legge til at, ifølge noen data, er den nevnte klassifiseringen og kravene som tilsvarer hver klasse, i henhold til regjeringsdekret nr. 781, allerede utviklet av FSTEC, FSB og det russiske informasjons- og kommunikasjonsdepartementet og vil publiseres i nær fremtid. Dette etterlengtede dokumentet vil kaste lys over disse og andre aspekter ved den praktiske anvendelsen av føderal lov-152. Men hovedhåpene knyttet til det ligger i å motta praktiske instruksjoner om hvordan man implementerer lovens krav for statlige organisasjoner som behandler borgernes personopplysninger.

Stort sett har kommersielle strukturer lenge beskyttet virksomhetskritiske data (for eksempel aksjonærregisteret og annen kommersiell informasjon), inkludert personopplysninger. Det er imidlertid få organisasjoner som overholder kravene i føderal lov om forretningshemmeligheter, men dette er et bredt tema utenfor rammen av denne artikkelen.

I sin tur venter offentlige organisasjoner på spesifikke instruksjoner og metoder for å bygge beskyttelsessystemer, avhengig av klassen til informasjonssystemet og arten av dataene som behandles av dette systemet. Jeg vil gjerne håpe at i nær fremtid alt Påkrevde dokumenter vil bli ferdigstilt og publisert, og dette vil sette fart i starten på et reelt arbeid med beskyttelse av personopplysninger.

Loven er streng, men rettferdig

Ikke mindre interessant er det hvilke muligheter loven gir for innbyggerne selv - emnene for personopplysninger. I tillegg til det ovennevnte, la oss minne om andre bestemmelser i loven. I henhold til del 4 av artikkel 14 i den føderale loven nr. 152, har emnet for personopplysninger rett til å motta, når han søker eller mottar en forespørsel, informasjon om behandlingen av hans personopplysninger, inkludert inneholdende: bekreftelse av faktum behandling av personopplysninger av operatøren, samt formålet med slik behandling; PD-behandlingsmetoder som brukes av operatøren; informasjon om personer som har tilgang til personopplysninger; liste over personopplysninger som behandles og kilden til mottakelsen; vilkår for behandling av PD, inkludert vilkår for lagring av dem; informasjon om hvilke rettslige konsekvenser behandlingen av hans personopplysninger kan medføre for personopplysningsobjektet. Faktisk er dette også en vanskelig oppgave for operatøren, fordi ingen har opphevet artikkel 137 i den russiske føderasjonens straffelov "Krenkelse av personvernet" datert 13. juni 1996. Artikkelen sier spesielt at straffeansvar medføres ved: ulovlig innsamling eller spredning av informasjon om en persons privatliv, som utgjør hans personlige eller familiehemmelighet, uten hans samtykke, eller spredning av denne informasjonen i en offentlig tale, offentlig vist arbeid eller media, hvis disse handlingene ble begått av egoistiske eller andre personlige interesser og forårsaket skade på rettighetene og legitime interesser til borgere.

I henhold til artikkel 17 i føderal lov-152, hvis gjenstanden for personopplysninger mener at operatøren behandler personopplysningene hans i strid med kravene i denne Føderal lov eller på annen måte krenker hans rettigheter og friheter, har gjenstanden for personopplysninger rett til å klage på handlinger eller passivitet fra operatøren til det autoriserte organet for å beskytte rettighetene til subjekter av personopplysninger eller i retten. I dette tilfellet har personer som er skyldige i brudd på kravene administrativt, sivilt, strafferettslig og annet ansvar fastsatt ved lov.

Det virker svært viktig at utviklere er ansvarlige for å implementere sikkerhetskrav i informasjonssikkerhetssystemer.

Her er hovedkomponentene i systemet for statlig kontroll og tilsyn over å sikre sikkerheten til personopplysninger under behandlingen av dem i informasjonssystemet:

• Rossvyazohrankultura er det autoriserte organet for beskyttelse av rettighetene til subjekter av personopplysninger;
• FSB - Føderalt utøvende organ autorisert innen sikring av statens sikkerhet og bruk av krypteringsverktøy;
• FSTEC - den føderale tjenesten for teknisk og eksportkontroll og motvirkning mot utenlandsk etterretning - det autoriserte organet innen kontroll av de tekniske beskyttelsesmidlene som brukes;
• Departement informasjonsteknologier og kommunikasjon fra den russiske føderasjonen - prosedyren for klassifisering av informasjonssystemer som inneholder personopplysninger.

Dermed opprettes et gjennomtenkt system for statlig kontroll av operatører som behandler personopplysninger.

Hvordan beskytte databaser riktig?

Tiltak for å beskytte personopplysninger skiller seg lite fra den allment aksepterte tilnærmingen til informasjonsbeskyttelse, begrenset tilgang. Så en integrert tilnærming til databasebeskyttelse består av påfølgende stadier, inkludert:

• fastsettelse av en adekvat trusselmodell;
• risikovurdering;
• utvikling av et beskyttelsessystem basert på det ved bruk av metoder gitt for den tilsvarende klassen av informasjonssystemer (IS);
• kontrollere beredskapen til informasjonssikkerhetssystemer (IPS) med utarbeidelse av relevant dokumentasjon (systembeskrivelse, driftsregler, forskrifter, etc.), inkludert konklusjoner om muligheten for å betjene denne IPS;
• installasjon og igangkjøring av informasjonsbeskyttelsesutstyr;
• regnskap for informasjonssikkerhetssystemene som brukes, teknisk dokumentasjon til dem, så vel som PD-bærere;
• regnskap for personer som er autorisert til å jobbe med PD i IS;
• utvikling av en fullstendig beskrivelse av personopplysningssystemet;
• kontroll over bruken av informasjonssikkerhet.

I dette tilfellet brukes tradisjonelt to komponenter for å bygge et informasjonsbeskyttelsessystem: gjennomføre en oversikt over informasjonsressurser, identifisere eierne deres, kategorisere informasjon (inkludert begrenset tilgang, om nødvendig, innføre et forretningshemmelighetsregime), forberede og signere en ordre for å implementere det utviklede organisatoriske tiltak beskyttelse, begrunne og motta et budsjett, velge og forberede personell, trene dem, organisere omskolering, og... det er ikke alt.

Alle disse aktivitetene bør beskrives og godkjennes i forskriftsmessig og administrativ dokumentasjon. Samtidig er ledelsesstøtte svært viktig for en konsekvent implementering av den utviklede sikkerhetspolitikken. Det er åpenbart det beste praksis er at hver ansatt signerer en egen avtale for arbeid med begrenset informasjon. Som en siste utvei må ansatte instrueres, som igjen må bekreftes av signaturen "kjent" med den ansattes fulle navn og stilling i alle bestillinger og instrukser.

La oss gå videre til å vurdere de tekniske midlene for å beskytte en database som inneholder personopplysninger mer detaljert.

Hovedkomponenter i et databasesikkerhetssystem

Den klassiske databasebeskyttelsesordningen er delt inn i følgende obligatoriske prosedyrer:

• Adgangskontroll- hver bruker, inkludert administrator, har kun tilgang til den informasjonen han trenger i henhold til sin stilling.
• Tilgangsbeskyttelse - tilgang til data kan fås av en bruker som har bestått identifiserings- og autentiseringsprosedyren.
• Datakryptering- det er nødvendig å kryptere både data som overføres over nettverket for å beskytte mot avskjæring, og data skrevet til media for å beskytte mot tyveri av media og uautorisert visning/modifisering ved hjelp av databasestyringssystemet (DBMS).
• Revisjon av datatilgang- handlinger med kritiske data skal logges. Brukerne som den vedlikeholdes på, skal ikke ha tilgang til protokollen. Når det gjelder applikasjoner som bruker en flerlagsarkitektur, gjelder beskyttelsesfunksjonene ovenfor også, med unntak av databeskyttelse på media - denne funksjonen forblir i databasen.

DBMS- og Oracle-applikasjoner er i en eller annen grad utstyrt med alle de oppførte sikkerhetsfunksjonene, noe som skiller dem fra konkurrentenes produkter. La oss vurdere disse prosedyrene mer detaljert.

Adgangskontroll

For å forfølge målet om å beskytte databasen mot innsidetrusler, for å sikre tilgangskontroll i DBMS versjon 10g Release 3, har Oracle gitt ut et nytt produkt Database Vault, designet for å forhindre uautorisert tilgang til informasjon fra brukere, inkludert de med spesielle krefter, for eksempel , databaseadministratorer. Settet med regler i Database Vault som begrenser tilgangen er ganske bredt. For eksempel kan en organisasjons ledelse definere regler som krever at to ansatte er tilstede samtidig for å utføre oppgaver som krever tilgang til kritisk informasjon. Dermed løser Database Vault følgende problemer:

• begrense tilgang til data for databaseadministratoren og andre privilegerte brukere;
• forhindre manipulering av databasen og tilgang til andreoner;
• gir kontroll over hvem, når og hvor som kan få tilgang til applikasjonen.

Adgangsbeskyttelse

Autentisering i sammenheng med Oracle betyr å bekrefte identiteten til noen eller noe – en bruker, en applikasjon, en enhet – hvem eller hva som trenger tilgang til data, ressurser eller applikasjoner. Etter en vellykket autentiseringsprosedyre følger autorisasjonsprosessen, som innebærer å tildele visse rettigheter, roller og privilegier til autentiseringsemnet.

Oracle tilbyr en rekke autentiseringsmetoder og lar deg bruke en eller flere av dem samtidig. Felles for alle disse metodene er at brukernavnet brukes som autentiseringsemne. For å bekrefte ektheten, noen Tilleggsinformasjon, for eksempel passord. Autentisering av Oracle DBMS-administratorer krever en spesiell prosedyre, som bestemmes av det spesifikke jobbansvaret og graden av ansvar til denne ansatte. Oracle-programvaren krypterer også brukerpassord for sikker overføring over nettverket.

Så la oss se nærmere på autentiseringsmetoder i Oracle DBMS.

Autentisering ved hjelp av operativsystemet

En rekke operativsystemer lar Oracle DBMS bruke informasjon om brukere som administreres av selve operativsystemet. I dette tilfellet har datamaskinbrukeren tilgang til databaseressurser uten å spesifisere et navn og passord i tillegg - hans nettverkslegitimasjon brukes. Denne typen autentisering anses som usikker og brukes hovedsakelig til å autentisere DBMS-administratoren.

Autentisering ved hjelp av nettverkstjenester

Denne typen autentisering leveres av serveralternativet Oracle Advanced Security. Den tilbyr følgende tjenester:

1. SSL - autentisering bruker SSL-protokollen (Secure Socket Layer) - en applikasjonslagsprotokoll. Den kan brukes for autentisering i databasen og i det generelle tilfellet (hvis brukerautentisering da brukes ved bruk av DBMS) er ikke avhengig av det globale brukeradministrasjonssystemet levert av Oracle-katalogtjenesten - Oracle Internet Directory.

2. Autentisering av tredjepartstjenester.

Basert på Kerberos. Bruken av Kerberos som et autentiseringssystem med en betrodd tredjepart er basert på bruk av såkalte. delt hemmelighet. Dette sikrer sikkerheten og påliteligheten til den betrodde parten og gjør det mulig å bruke Single Sign-On, sentralisert passordlagring, transparent autentisering gjennom databasekoblinger og forbedret sikkerhet på arbeidsstasjoner.

Basert på PKI. Bruken av PKI for autentisering innebærer utstedelse av digitale sertifikater for brukere (applikasjoner), som brukes til direkte autentisering på databaseservere innenfor én organisasjon. Dette krever ikke bruk av en ekstra autentiseringsserver. Oracle definerer følgende komponenter for bruk av PKI:

• SSL-protokoll
• et sett med OCI (Oracle Call Interface - applikasjonsgrensesnitt for tilgang til databasen) og PL / SQL-funksjoner
• klarerte sertifikater, for å bekrefte ektheten til sertifikater presentert av brukere (applikasjoner)
• Oracle-lommebøker er nøkkelbeholdere som inneholder brukerens private nøkkel, hans sertifikat og klarerte sertifikatkjeder
• Oracle AS Certificate Authority - komponent av Oracle Application Server, designet for å utstede sertifikater og videre administrere dem
• - Oracle Wallet Manager (OWM) - en DBMS-komponent for administrasjon av lommebøker

Basert på RADIUS. Oracle DBMS støtter RADIUS-protokollen (Remote Authentication Dial - In User Service) - en standardprotokoll for autentisering av eksterne brukere. I dette tilfellet blir tredjeparts autentiseringstjenester og enheter tilgjengelige som RADIUS-serveren kan samhandle med (for eksempel enheter for generering av engangspassord, biometriske enheter osv.).

Basert på LDAP-katalogtjeneste. Bruk av en LDAP-katalogtjeneste gjør autentiseringsadministrasjon og brukerkontoadministrasjon (applikasjon) veldig effektiv. I Oracle DBMS-infrastrukturen er katalogtjenesten representert av følgende komponenter:

• Oracle Internet Directory (OID) lar deg sentralt lagre og administrere informasjon om brukere (såkalte bedriftsbrukere). Lar deg ha en enkelt brukerkonto for mange databaser. Mulig integrasjon med tredjeparts katalogtjenester, slik som MS Active Directory eller iPlanet. OID lar deg fleksibelt administrere sikkerhetsattributtene og privilegiene til hver bruker, inkludert de som er autentisert med digitale sertifikater. For å øke sikkerheten under autentiseringsprosessen er det mulig å bruke SSL-protokollen.
• Oracle Enterprise Security Manager er et verktøy for å administrere brukere, grupper, roller og privilegier.

3. Autentisering i flerlagsapplikasjoner

De ovennevnte autentiseringsmetodene kan også brukes i flerlagsapplikasjoner. Som regel, for å få tilgang til applikasjoner fra Internett, brukes autentisering ved hjelp av et navn og passord (inkludert ved å bruke RADIUS-protokollen) eller ved å bruke SSL-protokollen. Andre metoder brukes for brukere å jobbe på et lokalt nettverk.

Datakryptering

For å beskytte data som overføres over nettverket i Oracle DBMS, starter med versjon 8i, alternativene brukes Oracle Advanced Security, som gir funksjonen Nettverkskryptering, som lar deg kryptere hele datastrømmen. Informasjonssikkerheten er sikret av hemmeligholdet til nøkkelen som dataene er kryptert med.

Nettverkskryptering lar deg oppnå et høyt sikkerhetsnivå. Følgende algoritmer støttes AES-kryptering(kun 10g/11g). DES, 3 DES, RC 4 (kun 10g/11g).

Beskyttelse av data som overføres over nettverket i Oracle-applikasjoner er sikret SSL-protokoll i henhold til algoritmene som støttes av applikasjonsserveren, er dette som regel en Oracle WEB-server.

Databeskyttelse på media leveres av to komponenter i Oracle DBMS - pakker som implementerer krypteringsalgoritmer og et alternativ Transparent datakryptering (T DE). Fra og med versjon 8i gir Oracle DBMS applikasjonsutviklere pakker med lagrede prosedyrer som implementerer følgende algoritmer: DES med en nøkkellengde på 56 biter, Trippel DES med nøkkellengde 112 og 168 bits ,AES med nøkkellengder på 128, 192 og 256 biter RC 4(kun 10g/11g).

Alternativ T DE dukket opp i Oracle DBMS versjon 10g Release 2 som komponent Avansert sikkerhet. Den lar deg selektivt kryptere tabellkolonner ved hjelp av Triple DES (med en nøkkellengde på 168 bits), AES (med en nøkkellengde på 128, 192 eller 256 biter) algoritmer. Håndtering av krypteringsnøkler overtas av databasekjernen, og bruken av slik kryptering krever ikke omarbeiding av klient- og serverprogramvaren. I DBMS versjon 11g og høyere ble det mulig å kryptere hele tabellplassen.

Revisjon av datatilgang

DBMS Oracle har kraftige verktøy for revisjon av brukerhandlinger, inkludert både datatilgang og registrering/utloggingshendelser og endringer i databasestrukturen. Fra og med versjon 9i er DBMS utstyrt med et detaljert revisjonsalternativ (Fine Grained Audit Control), som lar deg revidere tilgang under forhold bestemt av ganske fleksible tilpassbare regler. Disse revisjonsverktøyene lar deg imidlertid ikke overvåke handlingene utført av databaseadministratoren, og hindrer heller ikke ham i å endre revisjonsloggen, slette eventuelle linjer og ikke etterlate spor av slike handlinger. Det nye behovet for å revidere aktiviteter og beskytte revisjonsdata fra privilegerte brukere, inkludert databaseadministratorer, ble spurt Oracle utvikle et nytt revisjonskonsept. Den er basert på ideen som funksjonaliteten er basert på Databasehvelv: Databaseadministratoren er isolert fra revisjonsadministrasjonen, noe som av åpenbare grunner gir et høyere nivå av databasesikkerhet. Som i saken Databasehvelv regler for tildeling av revisjoner til Revisjonshvelv veldig fleksibel.

Er de innebygde beskyttelsene tilstrekkelige?

Gitt av oss kort anmeldelse Informasjonssikkerhetsverktøyene som Oracle Corporation har innebygd i sine produkter og teknologier, viser et solid grunnlag for å bygge IS med ulike sikkerhetsnivåer som oppfyller de nyeste sikkerhetskravene. Imidlertid vil selv et overfladisk blikk på sikkerhetssystemene til ulike programvarer som bruker en DBMS- eller Oracle-applikasjonsserver vise at innebygde sikkerhetsverktøy, med sjeldne unntak, enten ikke brukes i det hele tatt, eller de erstattes av lignende funksjonalitet. egen utvikling enten ferdige utviklinger som tilbys på markedet, eller innebygde verktøy er supplert med tredjeparts programvare.

I hovedsak har vi å gjøre med tre tilnærminger fra innenlandske selskaper til spørsmålet om informasjonssikkerhet generelt og til å beskytte databaser mot stadig voksende trusler spesielt.

Dessverre er det verdt å erkjenne at den første tilnærmingen er den vanligste og innebærer bruk av enkel passordautentisering, autorisasjon og datakryptering.

Følgende argumenter kan oftest høres fra tilhengere av denne tilnærmingen i utvikling og drift av informasjonssystemer:

• den enkleste og derfor mer pålitelig når det gjelder drift;
• lave eierkostnader;
• et høyere beskyttelsesnivå er ikke nødvendig.

Passordbeskyttelse krever selvfølgelig ikke ekstra kostnader verken på utviklingsstadiet eller på driftsstadiet av IS - alle "bekymringer" for å betjene brukere og passordene deres overtas av DBMS eller applikasjonsserver. Det er heller ingen kostnader for ekstra maskinvare (autentiseringsservere, katalogtjenester, lagringsenheter for nøkkelinformasjon osv.) og programvare (lisenser, tredjepartsprogramvare osv.). Det er også viktig at kravene til kvalifikasjoner til databaseadministratorer og sikkerhetsadministratorer inn i dette tilfellet betydelig lavere, og dette er også et spørsmål om innsparinger. Det tredje argumentet ser ut til å ha historisk vært bevart fra de tidene da sikkerhetsspørsmål ikke ble tatt opp på alvor.

Beskyttelsessystemer bygget i henhold til den andre tilnærmingen er litt mindre vanlige. Delvis blir systemer fra det første alternativet overført til dem, når for eksempel kunder av et slikt system, lei av de "lave" eierkostnadene for passordbeskyttelse, bestiller utviklere eller kjøper et ferdig passordbehandlingssystem. Det hender at periodiske skandaler med datatyveri tvinger oss til å lage programvare-"patcher" på et ferdig system for å implementere kryptering, ofte ved å bruke våre egne "supersterke" algoritmer.

Argumentene for denne tilnærmingen er omtrent følgende: innebygde sikkerhetstiltak er tydeligvis utilstrekkelige og er fulle av sårbarheter;

• Det er bedre å forholde seg til et "lokalt" utviklingsteam enn å stole på leverandørstøtte;
• systemet fungerer normalt med passordbeskyttelse, og det er bedre å ikke berøre det; det er nok å implementere ekstra programvare for passordadministrasjon.

De to alternativene for bruk av sikkerhetstiltak omtalt ovenfor er typiske for informasjonssystemer utviklet og implementert hovedsakelig på slutten av 90-tallet av forrige århundre. Et typisk eksempel er faktureringssystemer, som er uavhengig utviklet av dusinvis av selskaper. Ikke mindre slående eksempler er databaser over helsevesen og rettshåndhevelsesbyråer. Men de inneholder imponerende mengder konfidensiell informasjon og spesielt personopplysninger, som russisk lovgivning forplikter til å beskytte pålitelig. Er en slik uaktsom holdning til beskyttelse av databaser med personopplysninger om innbyggere årsaken til den konstante opptredenen av databasesamlinger på fysiske og personlige data blant piratkopier av filmer? juridiske enheter? Svaret på dette spørsmålet bør først og fremst søkes basert på manglene ved de beskrevne tilnærmingene. La oss gjøre et forsøk på å analysere tilhengerne av disse tilnærmingene.

Er passordautentisering tilstrekkelig?

Faktisk er brukervennligheten av passordbeskyttelse hevet over tvil. Men enkelhet og pålitelighet av beskyttelse i dette tilfellet er uforenlige. Når det gjelder sikkerhet og brukervennlighet, er denne teknologien i ferd med å bli foreldet. Styrken til et passord, og derfor sikkerheten ved bruken av det, avhenger direkte av kvaliteten (tegnene som brukes, tilfellet deres, forskjellen fra meningsfulle ord). Og brukervennligheten avtar raskt selv med en liten økning i "sikkerheten" til passordet, fordi det er ganske vanskelig å huske en uleselig kombinasjon av tegn. La oss se på tallene og fakta. Brukerpassord lagres i Oracle DBMS som hash-verdier og kan leses av privilegerte brukere. Algoritmen for å beregne en passordhash har lenge vært kjent. Den mest omfattende studien av passordstyrke i Oracle ble utført av Red - Database - Security GmbH - verdens ledende ekspert innen sikkerhet for Oracle-produkter. Her er noen data om passordstyrke for DBMS-versjoner 7-10g:

På en datamaskin med en Pentium 4 3 GHz er den nødvendige tiden (brute force attack):

• 10 sekunder alle 5 tegnkombinasjoner
• 5 minutter alle 6 tegnkombinasjoner
• 2 timer alle 7-tegns kombinasjoner
• 2,1 dager alle 8 tegnkombinasjoner
• 57 dager alle 9 tegnkombinasjoner
• 4 år alle 10-tegns kombinasjoner

Og dette er når du bruker langt fra den kraftigste datamaskinen. Etter hvert som ytelsen øker, utføres et ordbokangrep enda raskere. Dette er ikke å si at Oracle ikke reagerer på denne tilstanden - i versjon DBMS 11g har situasjonen forbedret seg betydelig. Algoritmen for hashgenerering og kvaliteten på passordgenerering er styrket. Som et resultat økte tallene ovenfor med 2,5-3 ganger. Men til tross for slike forbedringer, anbefaler Oracle bruk av forbedrede autentiseringsverktøy, som også er forbedret til det bedre, for eksempel er det blitt mulig å bruke HSM (Hardware Security Module) for autentisering og lagring av krypteringsnøkler.

Dermed konkluderer vi: påliteligheten og sikkerheten ved å bruke passord for å beskytte IP oppfyller for øyeblikket ikke lenger kravene til selskaper som på den ene siden bryr seg om sitt omdømme, og på den andre er pålagt å overholde kravene i gjeldende lovgivning .

Lave eierkostnader - en myte?

Utbredt misforståelse. Statistikk bekrefter fakta om betydelige kostnader for å betjene for eksempel glemte passord. Bedrifter lider enda større tap på grunn av lav pålitelighet og sikkerhet for passordbeskyttelse.

Er det innebygde sikkerhetssårbarheter?

Og i denne saken står vi igjen overfor den vanlige oppfatningen at standard sikkerhetstiltak er utilstrekkelig. Hvordan kan vi forklare fremveksten av en slik mening, spesielt med tanke på det faktum at innebygde sikkerhetstiltak oftest ikke brukes på 100%. T

Når det gjelder sårbarhetene til innebygde sikkerhetstiltak i Oracle, er situasjonen her nøyaktig den samme som i andre komplekse systemer. Oracle Corporation har tradisjonelt tatt en ansvarlig tilnærming til å identifisere og eliminere sårbarheter som er funnet. CPU-oppdateringer (Critical Patch Update) utgis regelmessig (4 ganger i året), og eliminerer feil oppdaget både av Oracle selv og av dusinvis av andre selskaper, hvorav den mest kjente er den allerede nevnte Red - Database - Security GmbH. For eksempel, i CPU i oktober 2007, ble 27 sårbarheter eliminert i DBMS, 11 i applikasjonsserveren, 13 i forskjellige applikasjoner. Med tanke på antall Oracle-produkter, deres versjoner og programvare- og maskinvareplattformer for dem, er dette ikke så mye.

Egen utvikling vs leverandørstøtte

Det er mange meninger om denne saken. Noen organisasjoner foretrekker å ha egne utviklingsavdelinger, noen gjør det ikke. Det kanskje mest overbevisende argumentet for leverandørstøtte er at ikke alle bedrifter har råd til å ha spesialister på informasjonssikkerhet i utviklingsavdelingen.

Men selv om slike ressurser finnes, er det verdt å huske på at et "hjemmeskrevet" system i stor grad avhenger av teamet av utviklere som deltok i utformingen og opprettelsen. Dette betyr at deres profesjonalitetsnivå, deres kvalifikasjoner er avgjørende med tanke på kvaliteten på utviklingen, fraværet av bokmerker innebygd i programvaren, og sårbarheter som kan utnyttes av eksterne angripere. I tillegg er «hjemmeskrevne» løsninger beheftet med det faktum at avgang av en eller flere sentrale «forfattere» av disse løsningene kan innebære risiko forbundet med riktig støtte og utvikling av den tidligere opprettede infrastrukturen av nye spesialister.

Så, la oss oppsummere mellomresultatene. Hovedargumentene fremsatt av apologetene for tilnærmingene vi har listet opp - innebygde sikkerhetstiltak brukes ikke og "hjemmelagde" midler er mer pålitelige enn standard - har faktisk ikke noe seriøst grunnlag. Og selskaper som forfølger disse alternativene for å beskytte databasene sine, utsetter faktisk den konfidensielle informasjonen i databasen for risikoen for tyveri og lekkasje.

Muligheter for å forbedre sikkerhetsfunksjoner: når er det nødvendig?

Eksemplet vi ga ovenfor om å beskytte databasene til ulike sosiale institusjoner er faktisk veldig veiledende. Tross alt snakker vi om et statlig foretak, som er direkte knyttet til overholdelse, på den ene siden, med statens interesser, og på den andre, med borgernes interesser. Følgelig blir spørsmålet om å beskytte lagrede og behandlede data som sirkulerer i informasjonsinfrastrukturen til denne institusjonen prioritet nummer én. Og i dette tilfellet kan maksimal bruk av egenskapene til standard beskyttelsesverktøy i løsninger fra pålitelige leverandører fortsatt være utilstrekkelig. Kravet om å styrke beskyttelsen for statseide virksomheter er på den ene siden forbundet med innføringen av teknologier med høyere sikkerhetsnivå, og på den andre siden med oppfyllelsen av juridiske krav, spesielt om bruk av utelukkende sertifiserte beskyttelsesmidler.

Det er derfor i I det siste Den tredje "blandede" tilnærmingen til å beskytte informasjonssystemer begynte å få fart. Hvis vi analyserer de typiske kravene til IP-beskyttelse og egenskapene som kan implementeres ved hjelp av innebygde Oracle-verktøy, kan vi umiddelbart identifisere hva som må suppleres:

Russiske kryptografialgoritmer (PKI, digital signatur, kryptering på nettverket og på media)

Implementering av kryptering ved skriving til media uten bruk av TDE

Oppbevaring av nøkkelmateriale.

Av åpenbare grunner ga ikke Oracle-utviklerne en universell implementering av disse to punktene, selv om de ga noen generelle tilnærminger.

Anvendelse av innenlandske kryptografiske algoritmer

Kryptografiske algoritmer kan brukes i prosessen med autentisering, generering av digital signatur (GOST R 34.10-2001), for å beskytte kommunikasjonskanalen (GOST 28147-89, GOST R 34.11-94) og datakryptering (GOST 28147-89). Oracles innebygde verktøy implementerer ikke disse algoritmene verken i DBMS, eller i applikasjonsserveren, eller i applikasjoner. Implementeringen av kryptografi i form av biblioteker, standard kryptografileverandører (CSP), utviklingssett (SDK) tilbys av flere russiske produsenter - CryptoPro, Signal-Com, Infotex, Lissy, CryptoCom, CryptoEx, etc. Men å få Oracle-produkter å jobbe med de foreslåtte bibliotekene er ganske problematisk. Poenget er ikke at disse verktøyene ikke er kompatible på programvare- og maskinvarenivå - innbygging av kryptografi i Oracle-produkter bør ikke være i strid med lisensavtale leverandør angående programvareintegritet. Hvis det som regel ikke oppstår problemer med innbygging med IS bygget på grunnlag av Oracle-applikasjonsserveren eller hele settet med Oracle-applikasjoner, er situasjonen mer komplisert med en DBMS. På grunn av det faktum at DBMS-kjernen ikke har programvaregrensesnitt for kryptooperasjoner (autentisering, kryptering), må løsninger brukes. Bruk for eksempel Kerberos-autentiseringsprotokollen eller engangspassordgeneratorer med RADIUS-protokollen, og beskytt kommunikasjonskanalen ved hjelp av sertifisert programvare.

Krypter data uten å bruke TDE

Til tross for den ekstreme enkelheten til Oracle TDE-alternativet, er det ofte nødvendig å forlate bruken. Det er to hovedårsaker:

Noen datatyper støttes ikke

Det er ingen mulighet for rutinemessig å bruke russiske kryptoalgoritmer

Nei reell beskyttelse fra privilegerte brukere.

Det første problemet kan i prinsippet løses ved å bruke tredjepartsprodukter - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R.D.), The Encryption Wizard for Oracle (Relational Database Consultants, Inc.). Det andre problemet er fundamentalt løst på samme måte, men her er det færre alternativer - eToken SafeData eller Krypteringsveiviseren for Oracle. Dessuten, for det første produktet kreves det en ekstra versjonsmontering (avhengig av den sertifiserte kryptografiprodusenten som brukes), men for det andre produktet var det rett og slett ikke mulig å finne nødvendig informasjon. Det tredje problemet kunne i prinsippet løses ved deling alternativer TDE Og Oracle Database Hvelv, men i dette tilfellet flyter myndighetene til DBMS-administratoren jevnt til Database Va u lt-administratoren, dvs. problemet med beskyttelse mot privilegerte brukere gjenstår.

Oppbevaring av nøkkelmateriale

Nøkkelmateriale (sertifikater, private nøkler, krypteringsnøkler) som brukes av Oracles innebygde sikkerhetsverktøy for å autentisere eller kryptere data, lagres i nøkkelbeholdere (kalt lommebøker) som vanlige filer. Et passord kreves for å få tilgang til informasjon i lommeboken. Ofte oppfyller ikke denne lagringsmetoden sikkerhetskrav, spesielt på kundearbeidsstasjoner. Oracle DBMS, som starter med versjon 10g, lar deg lagre private nøkler på maskinvareenheter som støtter PKCS#11-standarden. Samtidig garanterer ikke Oracle på noen måte driften av andre maskinvareenheter enn produksjonsenheter nCipher (nCipher Corporation Ltd.). Dette er ikke alltid akseptabelt, for eksempel hvis bare sertifisert maskinvare er ment å brukes. Og i dette tilfellet kan problemet med å lagre nøkler og sertifikater løses ved hjelp av tredjepartsløsninger. På det russiske markedet er kanskje det eneste produktet i sin klasse eToken SecurLogon for Oracle (Aladdin Software Security R.D.).

Konklusjon

Til tross for den bevisste forståelsen av problemet reist av både lovgivere og offentlige og kommersielle organisasjoner, er personopplysninger fortsatt utsatt for informasjonslekkasjer, hvor skaden noen ganger anslås til svært imponerende tall. Mangelen på høyprofilerte presedenser kan forklares med forsinkelsen av forbrytelser på dette området. Lekkasjer oppstår imidlertid konstant og før eller siden vil en fullskala kamp mot databasetyveri bli lansert på statlig nivå. Selvfølgelig kan du bruke usertifiserte løsninger, du kan bruke ulisensiert programvare og finne opp hjulet på nytt selv, og ignorere velprøvde industrielle løsninger... Men bare i dette tilfellet bør organisasjoner være klar over det faktum at alle tilleggsrisikoer - fra økonomisk til omdømme - knyttet til bruken av slike produkter tar de også fullt ansvar. Det er trusler og det er konsekvenser. Ved å ta i bruk en eller annen tilnærming for å sikre sikkerheten til informasjonsressurser, tar organisasjoner enten risiko eller skaper de sikreste forholdene for seg selv.

For tiden er sikkerhetskravene fra forbrukerne ganske høye, og optimal løsning består i å gjøre full bruk av innebygde sikkerhetsverktøy og klokt supplere dem med produkter og løsninger fra tredjepartsutviklere. Imidlertid kommer ofte ønsket om å bygge pålitelig IP-beskyttelse opp mot en banal mangel på kvalifisert personell - utviklere, analytikere, tekniske støtteingeniører, konsulenter. Konsekvensen av dette er dårlig kunnskap om mulighetene til innebygde sikkerhetsfunksjoner i Oracle og andre systemer og deres korrekte bruk. En annen konsekvens er den samme situasjonen, men i forhold til produktene til andre produsenter av programvare og maskinvare for informasjonssikkerhet og deres bruk i forbindelse med Oracle-teknologier og -produkter. Som et resultat fortsetter eksisterende systemer å bruke utdaterte passordbeskyttelsessystemer, og får unødvendige modifikasjoner og haugevis av tilleggsreguleringer, og enda verre, nye informasjonssystemer med gammel beskyttelsesteknologi utvikles. Veien ut av denne situasjonen er for det første i opplæring av personell som har ekspertkunnskap i selve informasjonssikkerheten, i Oracle-produktlinjen og som er i stand til å integrere utviklingen til russiske selskaper med innebygde sikkerhetstiltak. Slik opplæring bør begynne ved spesialiserte universiteter, og spesialister på dette feltet bør ha mulighet til å bygge opp erfaring og kompetanse i opplæringssentre. Jeg vil gjerne se støtte i denne saken både fra Oracle og fra andre produsenter som opererer i det russiske informasjonssikkerhetsmarkedet.

I denne forbindelse er en veldig oppmuntrende trend, etter vår mening, fremveksten reelle løsninger, metoder og tilnærminger for å organisere informasjonssikkerhetssystemer, utviklet av innenlandske selskaper sammen med russiske representasjonskontorer for vestlige selskaper. Slikt samarbeid gjør det mulig å sikre ikke bare den stabile ytelsen til beskyttelsesmekanismene som en del av informasjonssystemet, men også at disse løsningene samsvarer med kravene i russisk lovgivning.

Men mens våre lovgivere krangler om lovforslag om forretningshemmeligheter og e-handel, på offentlige steder - i T-banepassasjer og til og med på parkeringsplasser, for ikke å nevne Internett, fortsetter det å selges CDer med forskjellige databaser (DB). Utvalget er uvanlig bredt: for $40-60 vil du bli tilbudt MGTS-databasen (oppdatert i januar 2003), United statlig registrering bedrifter ( full informasjon om foretak registrert i Russland i 2003), informasjon om registrering i Moskva og Moskva-regionen, og til en dyrere pris, for $110, kan du kjøpe en utenlandsk økonomisk aktivitetsdatabase, etc. Litt "foreldede varer", for eksempel litt, utdaterte data om MTS-abonnenter (fra november 2002), koster bare 40 "cu".

Det er usannsynlig at noen ærlige borgere vil være glade for å finne hans personlige data på en CD kjøpt på denne måten. Tross alt kan en slik plate enkelt kjøpes ikke bare av en "nysgjerrig kamerat", men også av såkalte kriminelle strukturer. Det verste er imidlertid at det til nå praktisk talt ikke har vært noen reelle mekanismer for å forhindre tyveri av informasjon og bevise en forbrytelse for å straffe angripere. I følge forfatterne, i skrivende stund, har løsningen som implementerer databeskyttelse under kontroll av Oracle 9i DBMS ved bruk av elektroniske eToken-nøkler ingen analoger i det globale informasjonssikkerhetsmarkedet.

Essensen av metoden er å bruke standard mekanismer for offentlig nøkkelinfrastruktur og organisere brukertilgang til informasjon ved presentasjon av X.509 digitale sertifikater støttet av Oracle Advanced Security-verktøy på to nivåer: for autentisering i bedriftsnettverket (for eksempel under administrert av Microsoft Windows Server 2000/2003) og for tilgang til konfidensielle data som behandles og lagres på Oracle-servere. Begge sertifikatene lagres i en personlig identifikator i form av en USB-nøkkel eller eToken-smartkort.

Denne metoden lar deg redusere risikoen for tap knyttet til den menneskelige faktoren betydelig og personlig tilpasse handlingene til informasjonssystembrukere som arbeider med Oracle 9i DBMS.

Hovedspørsmål

Hvorfor skjer informasjonstyverier i en rekke organisasjoner, selv i rettshåndhevelsesbyråer? Hva er forutsetningene for en datalekkasje, og trenger en angriper å ha omfattende kunnskap og ferdigheter for å overvinne eksisterende beskyttelse? Finnes det måter å bygge informasjonssikkerhetssystemer (ISPS) på som minimerer risikoen for tap av data? Er det mulig å beskytte bedriftsdata fra din egen systemadministrator?

Alle disse spørsmålene knyttet til beskyttelse av konfidensielle data på DBMS-nivå bør vurderes fra forskjellige posisjoner, og tar ikke bare hensyn til databasearkitekturen og innebygde sikkerhetsfunksjoner, men også konfigurasjonen av bedriftsnettverket, dets sikkerhetssystem, som samt driftsfunksjonene til klientstasjonene.

Nivåer for beskyttelse av datatilgang

En typisk modell for å beskytte brukertilgang til bedriftsdata og -applikasjoner inkluderer fire elementer:

• organisatoriske tiltak for å begrense tilgangen til en datamaskin koblet til bedriftsnettverket;
• restriksjoner på tilgang til bedriftsnettverket;
• beskyttelse av tilgang til DBMS;
• restriksjoner på bruken av applikasjonsprogramvare av en bestemt bruker.

Siden organisatoriske tiltak og mekanismer for å begrense tilgangen til et bedriftsnettverk er beskrevet i detalj både med tanke på metodikk og praktisk implementering, er det verdt å dvele mer detaljert ved oppgavene med å beskytte tilgangen til DBMS og restriksjoner på bruken av applikasjonsprogramvare. Men først, la oss snakke om hvilke forhold som er "gunstige" for informasjonstyveri.

Hvorfor stjeler folk informasjon?

La oss prøve å analysere mulige årsaker til vellykkede forsøk på å stjele informasjon som er lagret i bedriftens databaser.

Den første og viktigste årsaken er mangelen systematisk tilnærming til trusselvurdering. Dessverre er det for tiden bare en liten del av virksomhetene som implementerer internasjonal erfaring og den generelle tilnærmingen til trusselvurdering beskrevet i detalj i arbeidet til Statens tekniske kommisjon, samt anbefalinger for bruk av tilstrekkelig informasjonssikkerhetstiltak.

Generelt, for bedriftsdatabaser som et objekt for beskyttelse mot uautorisert tilgang, blir trusler vanligvis klassifisert etter kilde, og deler dem inn i interne og eksterne. Kilden til en intern trussel kan være juridiske databasebrukere eller interne hackere, og kilden til en ekstern trussel kan være lovlige brukere av et bedriftsnettverk eller eksterne hackere.

Tyveri av informasjon fra databasen er vanligvis forbundet med ulovlige handlinger bedriftsnettverksbrukere, dvs. med implementering av interne trusler. I følge data fra forskjellige kilder, er opptil 85 % av tyverier og kompromitteringer av informasjon begått av lovlige brukere av et bedriftsinformasjonssystem og, det som er spesielt ubehagelig, administratorer av DBMS eller applikasjonssystemet. I følge ulike estimater utgjør andelen interne (dvs. registrert i bedriftsnettverket) hackere som prøver å få uautorisert tilgang til informasjon for opptil 15 % av truslene.

Eksterne trusler om uautorisert tilgang til bedriftsdata er også delt inn i to underklasser, hvorav eksterne hackere står for opptil 20 %, og lovlige brukere av bedriftsnettverket står for opptil 100 %.

Den andre grunnen er feilen i passordbeskyttelsen. Til tross for det store antallet publikasjoner om at passord ikke gir tilstrekkelig beskyttelse for data og applikasjoner, er denne metoden fortsatt den mest brukte, først og fremst på grunn av dens nullkostnad. Spørsmålet om svikt i passordbeskyttelsen diskuteres i tilstrekkelig detalj, for eksempel i verkene.

Det mest ubehagelige er at denne tilnærmingen ofte brukes i langt fra små organisasjoner. Og tilgang til systemressurser av flere forskjellige brukere under samme konto er en veldig vanlig og godt forankret praksis. For eksempel, hvis en organisasjon har fem systemadministratorer, kan alle ha tilgang med samme passord. Fordervelsen av en slik organisering av tilgang er godt illustrert av analogien med å kjøre gjennom gatene i en stor by i biler uten bilskilt. Ingen trafikkpolitibetjent vil klart kunne identifisere en bil som overskrider fartsgrensen i en strøm av "anonyme" kjøretøy hvis alle kjører uten skilt.

Den tredje grunnen er at informasjonsbeskyttelsen og overvåkingsverktøyene for brukerhandlinger som er innebygd i DBMS ikke brukes fullt ut, så vel som uberettigede forhåpninger om kvalifikasjonene til når det gjelder å organisere et. Hvem er egentlig ansvarlig for bruk/ikke-bruk av informasjonssikkerhetsverktøy innebygd i DBMS? Mest sannsynlig på som implementerer systemene sine med kunder. Men paradokset er at det overveldende flertallet av utviklerne ikke har en i staben og ikke vet om standardfunksjonene for å organisere DBMS-beskyttelse. I følge de mest konservative estimatene er det flere tusen applikasjonssystemer og programvareprodukter basert på bruk av industrielle DBMS-er på det russiske markedet. Dessuten, i det overveldende flertallet av tilfellene, antas det at alle problemer knyttet til datasikkerhet håndteres av DBMS selv, og tilgang til informasjonssystemet skjer ved hjelp av et passord.

På grunn av utilstrekkelig oppmerksomhet til sikkerhetsproblemer fra, blir inimplementert i selve DBMS ekstremt viktige. Dessuten, som nevnt ovenfor, kan flere personer ha tilgang til systemet med maksimale (administrator) rettigheter. Det er ikke mulig å spore handlingene til en spesifikk person (med andre ord å personifisere disse handlingene) under slike forhold. Selv om det er mulig å lokalisere lekkasjekanalen, er brukeren ikke underlagt noen, i det minste administrative, straffer. Overtreders standardargument er en henvisning til det faktum at passordet hans ble stjålet og at noen under hans navn begikk ulovlige handlinger.

Til slutt, den siste men vesentlige grunnen er den vedvarende følelsen av straffrihet for angriperen. Praksisen med å innføre strenge regler og administrative tiltak uten den strengeste dokumenterte kontrollen fører dessverre ikke til en merkbar reduksjon i antall overtredelser. Nesten alle skruppelløse ansatte som ble tatt på fersk gjerning, innrømmet at de ikke ville ha begått slike handlinger hvis de visste at disse handlingene ville bli sporet og, viktigst av alt, personliggjort. Derfor støttes kun en kombinasjon av administrative og tekniske tiltak programvare kontroll og overvåking, lar deg oppnå riktig nivå for beskyttelse av konfidensielle data.

Innebygd sikkerhet

Hvis vi vurderer sikkerhetsverktøy når det gjelder databasetilgang, informasjonslagring og nettverksoverføring, er Oracle DBMS i dag den klare markedslederen innen databasestyringssystemer. Det gir programvareutviklere og aet komplett utvalg av verktøy og verktøy som trengs for å bygge sikre systemer. Blant dem er det verdt å fremheve følgende:

Virtual Private Database (VPD)- midler for å begrense tilgangen til data på radnivå (i versjon 10g - og på kolonnenivå) og muligheten til å organisere brukerens arbeid bare med den virtuelle regulerte delen av dataene, og ikke med den virkelige databasen;

Oracle Advanced Security- et sett med autentiserings- og nettverkssikkerhetsverktøy, inkludert støtte for sikre dataoverføringsprotokoller, inkludert SSL;

Oracle Label Security (OLS)- verktøy som ligner på VPD, men med muligheten til å sjekke brukerens tilgangsnivå;

Finkornet revisjonskontroll (FGAC)- detaljert revisjonsverktøy.

Standard Oracle-verktøy + eToken

Beskyttelsen av Oracle 9i DBMS-klientprogramvare ved hjelp av elektroniske eToken-nøkler kan radikalt øke sikkerheten til databaseapplikasjoner. Beskyttelsen ble betydelig forbedret ved bruk av flere teknologiske løsninger.

Først av alt er metoden for brukerautentisering med navn og passord erstattet av en mer pålitelig en - tofaktors autentisering ved bruk av digitale sertifikater av X.509-standarden. Og selv om de innebygde Oracle Advanced Security-verktøyene støtter autentisering ved bruk av digitale sertifikater, forblir spørsmålet om lagring av sertifikater og private nøkler åpent. Metodene som tilbys av Oracle for lagring av sertifikater i form av PKCS#12-beholderfiler eller Windows OS-registeret har en rekke betydelige ulemper. Essensen av egenskapene innebygd i Advanced Security er illustrert av sertifikatlagringsdiagrammet (fig. 1).

Ris. 1. Opplegg for lagring av Oracles digitale sertifikater i Oracle Advanced Security-arkitekturen ved bruk av eToken.

En containerfil kan for eksempel bli stjålet av en angriper som har leserettigheter til den tilsvarende registernøkkelen eller containerfilen. Samtidig er det bare tillatt å jobbe med DBMS for brukeren som den tilsvarende beholderen er opprettet for, og dessuten er han "bundet" til en spesifikk arbeidsstasjon (hvor beholderfilen er plassert). For å unngå disse "problemene" må du lagre digitale sertifikater direkte i minnet elektronisk nøkkel eToken, og for å utføre kryptografiske operasjoner med en privat nøkkel, bruk den innebygde kryptoprosessoren med ekstra PIN-autorisasjon fra brukeren.

Det er åpenbart at, i tillegg til å øke påliteligheten, gir autentisering ved hjelp av eToken en rekke fordeler sammenlignet med den tradisjonelle (pålogging/passord) metoden. Først av alt lar en elektronisk nøkkel brukeren av ulike applikasjoner ikke lagre den "bare hvor som helst" og ikke huske de nødvendige navnene og passordene. Når du kjenner én PIN-kode og velger et sertifikat fra den foreslåtte listen, kan du, med de riktige rettighetene og privilegiene, få tilgang til en bestemt database og fra hvilken som helst arbeidsstasjon.

Sikkerhetsadministratoren får ekstra bekvemmelighet i form av sentralisert tilgangskontroll og kontroll over arbeidet til systemadministratorer. Alle disse administrasjonsmulighetene leveres av ett enkelt verktøy - Oracle Internet Directory-tjenesten. Eksisterende applikasjoner de mottar ett enkelt inngangspunkt gjennom katalogtjenesten - en slags klient-server-arkitekturportal. I de fleste tilfeller er det ikke nødvendig med endringer i applikasjonsprogramvaren.

Arkitektoniske trekk

Den foreslåtte løsningen er basert på bruk av digitale sertifikater av X.509-standarden og Secure Sockets Layer (SSL)-protokollen, som støtter streng tofaktorautentisering av Oracle DBMS-brukere, samt kryptering av informasjon som overføres over nettverket mellom kl. databaseserveren og klientarbeidsstasjonen (fig. 2). I dette tilfellet brukes kun standardinnstillingene til DBMS og Oracle-klienten, beskrevet i dokumentasjonen for Oracle Advanced Security. Installasjon av eToken-tjenester på en arbeidsstasjon gjør det mulig å bruke sertifikatene på nøkkelen for autentisering i Oracle DBMS (se sidefeltet "Autentiseringsprosedyre i Oracle DBMS ved bruk av eToken").

Ris. 2. Tilgangsordningsarkitektur.

Autentiseringsprosedyre i Oracle DBMS ved hjelp av eToken

Trinn 1. Etablere en klient-server-tilkobling Klienten sender en forespørsel om å etablere en SSL-tilkobling. Serveren svarer på forespørselen ved å sende sitt sertifikat og sender en forespørsel om klientens sertifikat. Klienten bekrefter integriteten, datoen og utløpsdatoen til sertifikatet, og at sertifikatet ble signert av en klarert utsteder. Hvis serverens sertifikat er bekreftet, sender klienten det sitt eget sertifikat, som brukeren kan velge fra listen. Serveren verifiserer integriteten, datoen og gyldighetsperioden til sertifikatet, samt det faktum at klientsertifikatet er signert av en pålitelig utsteder, og ved bekreftelse av autentisitet "samtykker" til utveksling av data (ellers nektes tilgang ). Klienten og serveren utveksler nøkkelinformasjon ved hjelp av kryptografiske algoritmer med offentlig nøkkel. På dette stadiet blir brukerautorisasjon i eToken forespurt (oppgi en PIN-kode). Basert på nøkkelinformasjonen genereres en øktnøkkel for å kryptere trafikk under økten ved å bruke den beste symmetriske algoritmen som er tilgjengelig for både klienten og serveren. Klientforbindelsen til serveren er etablert.

Trinn 2. Autorisasjon av brukeren av Oracle-nettverkstjenester i databasen LDAP-katalogen (Oracle Internet Directory) søkes etter brukerens navn som samsvarer med emnefeltet i klientsertifikatet. Hvis et samsvar blir funnet, bestemmes den nødvendige databasen av tilkoblingsstrengen, og brukerens tilgangsskjema til den spesifiserte databasen bestemmes av emnefeltet i klientsertifikatet. Bedriftsroller bestemmes og deres samsvar med roller i det valgte brukerskjemaet. En tilkobling til databasen opprettes.

Sertifikater og tilhørende private nøkler lagres i eTokens sikre minne (bare tilgjengelig av kryptoprosessoren som er innebygd i den). For å utføre kryptografiske operasjoner med en privat nøkkel, må brukeren angi en PIN-kode. Denne tilnærmingen gjør det mulig i praksis å implementere en modell for organisering av sikker brukertilgang til data (DBMS) ved hjelp av X.509 digitale sertifikater installert i eToken på to nivåer. Legitime brukere av et bedriftsnettverk (for eksempel under kontroll av en Windows 2000/2003-domenekontroller) kan kun logge på nettverket (fig. 3) etter å ha fullført, som inkluderer fremvisning av riktig sertifikat ( første nivå). På det andre beskyttelsesnivået er tilgang for autoriserte brukere av bedriftsnettverket til beskyttede DBMS-data kun mulig ved fremvisning av det aktuelle Oracle-sertifikatet.

Ris. 3. To-nivå modell for tilgang til beskyttede data ved hjelp av X.509 digitale sertifikater.

La oss oppsummere. Den foreslåtte databeskyttelsesmetoden begrenser muligheten for informasjonstyveri betydelig. Og i tilfelle en forbrytelse gir det rimelige bevis for anvendelse av straff, siden eieren av den elektroniske nøkkelen og sertifikatene som er lagret i den, alltid er kjent.

1 - Vanligvis er industrielle DB2- og Oracle-klasse DBMS-er sertifisert til minst sikkerhetsklasse C2.

2 - Ifølge en rekke kilder, inkludert IDC. - Ca. utg.

Følgende hovedområder for å bekjempe potensielle trusler mot konfidensialitet og dataintegritet kan nevnes:

Brukeridentifikasjon og autentisering;

Datatilgangskontroll (eieren av et objekt overfører tilgangsrettigheter til det etter eget skjønn);

En ansvarlighetsmekanisme for alle handlinger som påvirker sikkerheten;

Beskyttelse av registreringsinformasjon mot forvrengning og analyse av den;

Rengjøring av gjenstander før gjenbruk;

Beskyttelse av informasjon som overføres over kommunikasjonslinjer.

Alle disse universelle anbefalingene gjelder også for DBMS-er. I tillegg gjør spesifikasjonene til DBMS nye trusler potensielt mulige og krever derfor spesielle beskyttelsestiltak (for eksempel bruk innleveringer- tilgangskontrollverktøy i DBMS, som lar deg gjøre visse kolonner med basistabeller synlige for fag eller velge bestemte rader).

DBMS-er har strenge intern struktur, og operasjoner på deres elementer er definert ganske klart. Som regel inkluderer disse operasjonene fire hovedhandlinger - søk, innsetting, sletting og erstatning av et element, og resten er hjelpetiltak og brukes ganske sjelden. Å ha en streng struktur og klart definerte operasjoner forenkler oppgaven med å beskytte DBMS. I de fleste tilfeller gir angripere ikke DBMS oppmerksomheten, og foretrekker å hacke nettverkssikkerheten på OS-nivå og få tilgang til DBMS-filene ved hjelp av OS. Men i tilfeller der en DBMS med utilstrekkelig pålitelige sikkerhetsmekanismer brukes, eller en dårlig testet versjon av DBMS, eller DBMS-administratoren gjorde feil ved å definere sikkerhetspolicyen, kan en angriper enkelt overvinne beskyttelsen implementert på DBMS-nivå.

Det er to spesifikke scenarier for å angripe en DBMS:

1) i det første tilfellet rundes resultatene av aritmetiske operasjoner på DBMS numeriske felt ned, og forskjellen summeres opp i en annen DBMS-post (som regel er denne posten en sum penger som er lagret i hackerens personlige bankkonto, og de numeriske feltene som rundes av er til kontoene til andre bankkunder);

2) i det andre tilfellet får angriperen tilgang til feltene til DBMS-poster som kun inneholder akkumulert statistisk informasjon. Angriperens oppgave er å formulere forespørselen på en slik måte at det settet med poster som det samles inn statistikk for kun består av én post.

Hovedkilden til DBMS-spesifikke trusler ligger i selve naturen til databasene som lagrer informasjon. Hovedmiddelet for interaksjon med DBMS er SQL-språket - et kraftig ikke-prosedyreverktøy for å definere og manipulere data. Lagrede prosedyrer legger til kontrollkonstruksjoner til den. Regelmekanismen gjør det mulig å bygge komplekse handlingskjeder som er vanskelig å analysere, samtidig som man implisitt kan overføre retten til å utføre prosedyrer, selv uten strengt tatt myndighet til å gjøre det. Som et resultat får en potensiell angriper hendene på et kraftig og praktisk verktøysett, og all utvikling av DBMS er rettet mot å gjøre dette verktøysettet enda mer kraftfullt og praktisk.

Innhenting av informasjon gjennom logiske konklusjoner. Ofte, gjennom logisk slutning, er det mulig å trekke ut informasjon fra en database som brukeren ikke har nok privilegier til å oppnå ved bruk av standardmidler.

Hvis visninger brukes til å implementere tilgangskontroll, og disse visningene tillater modifikasjon, kan du ved å bruke modifikasjons-/innsettingsoperasjoner få informasjon om innholdet i basistabellene uten å ha direkte tilgang til dem.

Hovedmiddelet for å bekjempe slike trusler, i tillegg til nøye utforming av datamodellen, er strengmultiplikasjonsmekanismen. Dens essens ligger i det faktum at primærnøkkelen eksplisitt eller implisitt inkluderer en sikkerhetsetikett ( sikkerhetsetikett- dette er nivået av datasikkerhet som bestemmer hvilke brukere eller prosesser som får tilgang til data), på grunn av dette blir det mulig å lagre flere forekomster av rader i tabellen med de samme verdiene av "meningsfulle" nøkkelfelt. Radmultiplikasjon er mest naturlig implementert i DBMS-er som støtter etiketter, men en tilfredsstillende løsning kan også oppnås ved bruk av standard SQL-verktøy.

Dataaggregering. Aggregasjon er en metode for å oppnå ny informasjon ved å kombinere data innhentet lovlig fra ulike tabeller. Samlet informasjon kan være mer sensitiv enn hver av komponentene som utgjør den. Informasjon om enkeltdeler er ikke hemmelig i seg selv (hva er vitsen med å skjule materialet, dimensjonene og antall muttere?). Samtidig gjør analyse av hele databasen det mulig å finne ut hvordan man lager en rakett, som kan betraktes som en statshemmelighet.

Å øke nivået av datahemmelighold under aggregering er ganske naturlig - dette er en konsekvens av loven om overgang fra kvantitet til kvalitet. Aggregasjon kan bekjempes ved å nøye utforme datamodellen og maksimal grense brukertilgang til informasjon.

Angrep på høy beredskap (tilgjengelighet). Hvis en bruker har tilgang til alle egenskapene til SQL, kan han ganske enkelt hindre andre brukeres arbeid ved for eksempel å sette i gang en langvarig transaksjon som involverer et stort antall tabeller. Moderne flertrådede DBMS-servere avviser bare de mest enkle angrepene, som for eksempel består av å starte en bulkdatalastingsoperasjon i rushtiden. Derfor anbefales det ikke å gi brukere direkte SQL-tilgang til databasen ved å bruke applikasjonsservere som filtre. Valget av en slik arkitektur er rimelig av mange andre grunner.

Som en trussel spesifikk for relasjonell DBMS, la oss nevne referansebegrensninger. Strengt tatt forhindrer å pålegge en slik begrensning rader fra å bli slettet fra en tabell som inneholder primærnøkler, selv om det er i moderne versjoner SQL kan be om en såkalt kaskadesletting.

Mange produkter utvikles for å støtte databasesikkerhet. Blant dem er produkter fra DBSecure og BrainTree Security Software. SQL Auditor DBSecure evaluerer risikoer i databasen Microsoft SQL Server, oppdager svake passord, driftsbrudd, oppstartsangrep og andre former for uautorisert tilgang. BrainTree sin SQL Secure-pakke sentraliserer sikkerhetsadministrasjon til én enkelt konsoll. Passordbehandlingskomponenten analyserer passord for svakheter, administrerer prosessen med å tildele passord og deres utløpsdato. Policy Manager hjelper brukere med å evaluere databasene sine mot sikkerhetsstandarder.

Databasen er en verdifull bedriftsressurs. Muligheten til å få tilgang til dataene som er lagret i den er en nødvendig betingelseå gjennomføre forretningsprosesser på nesten alle aktivitetsområder. Permanent tap av data setter bedrifter i alvorlig risiko. Tapte dataressurser kan gjenopprettes, men i mangel av tiltak for å beskytte og gjenopprette tapte data, er det umulig å gjenopprette dem. Noen databaseteknologiforskere anslår at blant selskaper som er rammet av katastrofer og opplever et stort permanent tap av bedriftsdata, var omtrent halvparten ute av stand til å fortsette driften.

Ødeleggelse og tap av data i databasen kan være forårsaket av en rekke årsaker:

· utstyrsfeil;

· fysisk innvirkning på databasemaskinvare;

· naturkatastrofer;

· feil fra autoriserte brukere;

· forsettlige ondsinnede handlinger fra uautoriserte brukere eller programmer;

· programvarefeil i DBMS eller operativsystem;

· feil i applikasjonsprogrammer;

· felles implementering av motstridende brukerforespørsler mv.

Følgende nivå av tiltak finnes for å sikre databasesikkerhet:

• lovgivende (lover, forskrifter, standarder, etc.);
• administrative og organisatoriske (handlinger generell tatt av ledelsen i organisasjonen, og spesifikke sikkerhetstiltak rettet mot å jobbe med mennesker);
• programvare og maskinvare (spesifikke tekniske tiltak).

Lovgivende tiltak er svært viktige for databasesikkerhet. Dette nivået omfatter hele spekteret av tiltak rettet mot å skape og opprettholde en negativ (inkludert straffende) holdning til sikkerhetsbrudd og krenkere i samfunnet.

De fleste begår ikke ulovlige handlinger fordi det er fordømt og/eller straffet av samfunnet, og fordi det ikke er akseptert å gjøre det.

Siden informasjonssikkerhet generelt og databasesikkerhet spesielt er nytt område aktivitet, er det viktig her ikke bare å forby og straffe, men også å undervise, forklare og hjelpe. Samfunnet må innse viktigheten av denne problemstillingen og forstå de viktigste måtene å løse relevante problemer på. Dette kan staten gjøre på best mulig måte. Det er ikke behov for store materialkostnader, men intellektuelle investeringer kreves.

Databaser, så vel som dataprogrammer, er likestilt med litterære verk og kan på en rekke betingelser være gjenstander for opphavsrett, som fastsatt i artikkel 7 i "Republikken Hviterusslands lov om opphavsrett". Hvis en database er anerkjent som et gjenstand for opphavsrett, betyr dette at den er beskyttet av sivil, administrativ og strafferettslig lovgivning, som alle andre gjenstander for opphavsrett. Opphavsrett i databasen er ikke knyttet til opphavsrett i dataprogrammet som brukes til å få tilgang til og behandle dataene.

Tiltak på administrativt og organisatorisk nivå. Administrasjonen av organisasjonen må være klar over behovet for å opprettholde et sikkerhetsregime og tildele passende ressurser til dette formålet. Grunnlaget for beskyttelsestiltak på administrativt og organisatorisk nivå er sikkerhetspolitikken og et sett med organisatoriske tiltak.

Settet med organisatoriske tiltak inkluderer sikkerhetstiltak implementert av mennesker. Følgende grupper av organisatoriske tiltak kan skilles ut:

· personalledelse;

· fysisk beskyttelse;

· opprettholde ytelsen;

· reagere på sikkerhetsbrudd;

· planlegging av restaureringsarbeid.

Tiltak på administrativt og organisatorisk nivå inkluderer instruksjoner og regler som må tas i betraktning ved utforming og drift av databasen. Slike midler inkluderer for eksempel prosedyren for å registrere en person som databasebruker, regler for start og stopp av DBMS, instruksjoner for bruk av hvert DBMS-verktøy eller applikasjon, etc. For å lykkes med å bruke DBMS, må alle brukere ha dokumentasjon som regulerer deres handlinger når de arbeider med databasen.

Programvare- og maskinvarenivå gir V Moderne DBMS-er har spesialverktøy for å beskytte databaser, for eksempel passordbeskyttelse, datakryptering og differensiering av tilgangsrettigheter. I mange tilfeller er disse midlene ikke nok, og da brukes en rekke sikkerhetsmetoder, alt fra å designe et DBMS med innebygde sikkerhetsmekanismer til å integrere DBMS med spesielle programvareprodukter for informasjonssikkerhet.

I praksis må du alltid være sikker på at det er en bruker ved datamaskinen hvis autentisitet er garantert.

Det er tre sekvensielle prosesser for å bekrefte brukerens autentisitet:

· Identifikasjon er prosessen med å gjenkjenne en bruker ved hans identifikator (pålogging og passord).

· Autentisering er prosessen med å bekrefte gyldigheten til en bruker-ID . Prosessen kan for eksempel implementeres ved et hemmelig uttrykk.

· A autorisasjon- gi brukeren kun de dataene han har rett til, dvs. differensiering av tilgangsrettigheter.

Den største fordelen med beskyttelse ved hjelp av Logg Inn Og passord– enkelhet og fortrolighet. Påliteligheten til passordbeskyttelse er basert på å holde dem hemmelige. Når du bruker et passord, er det tilrådelig å overholde følgende krav:

· passordet må bestå av en kombinasjon av bokstaver og tall eller spesialtegn;

· Passordet må være minst seks tegn langt og må ikke inneholde mellomrom.

· Passord bør endres ofte.

Når de brukes riktig, kan passord gi et akseptabelt sikkerhetsnivå for mange organisasjoner. På grunn av sårbarheten ved å holde passord hemmelig, er imidlertid ikke slik beskyttelse i noen tilfeller nok.

Differensiering av tilgangsrettigheter er en nødvendig funksjon i enhver flerbruker DBMS. Dette er et ganske fleksibelt og utviklet system som lar databaseadministratoren konfigurere brukertilgangsrettigheter i samsvar med jobbansvaret. Fastsettelse av brukerrettigheter ved tilgang til databasen bør være basert på prinsippet om minimumsmaktene som er nødvendige for å utføre direkte jobbansvar. Nesten alle moderne DBMS-er gir et sett med grunnleggende verktøy for å administrere tilgangsrettigheter. Vanligvis støttes konsepter som brukere og grupper, samt muligheten til å gi disse brukerne og gruppene tilgangsrettigheter til bestemte databaseobjekter. Samtidig har mange DBMS-er muligheten til ikke bare å gi tilgang til en bestemt bruker, men også å indikere den tillatte typen tilgang: hva nøyaktig en spesifikk bruker kan gjøre med spesifikke data - fra skrivebeskyttet til omorganisering av hele databasen . De viktigste sikkerhetsobjektene i en relasjonell DBMS er tabeller, visninger og lagrede prosedyrer. Avhengig av typen objekt kan du administrere rettigheter til bestemte handlinger med det. For eksempel, når det gjelder tabeller, kan du uavhengig kontrollere rettighetene til å lese, legge til, slette og endre poster. Noen DBMS-er lar deg kontrollere tilgang på nivået til en enkelt kolonne i en visning eller tabell.

Databasen kan krypteres og lagres på disk i kryptert form.

Kryptering– dette er transformasjonen av kildedata ved hjelp av spesielle algoritmer til en ny representasjon som skjuler innholdet i den opprinnelige informasjonen.

Dekryptering er den omvendte prosessen med kryptering. Når du krypterer en database, er databasefilen kryptert og kan ikke vises av verktøy.

Det er to mulige arbeidsmåter med krypterte databaser. Den enkleste modusen er hvor informasjon dekrypteres på eksterne medier, de nødvendige handlingene utføres med den, hvoretter informasjonen krypteres igjen for opptak på eksterne medier. Fordelen med denne modusen er uavhengigheten av funksjonen til krypteringsverktøy og DBMS, som fungerer sekvensielt etter hverandre. Samtidig kan en feil eller feil i systemet føre til at deler av databasen forblir registrert i ukryptert form på eksterne medier.

Den andre modusen antar evnen til DBMS til å utføre brukerforespørsler uten å dekryptere informasjon på eksterne medier. Dekryptering gjøres i tilfeldig tilgang minne umiddelbart før du utfører spesifikke handlinger med dataene. Denne modusen er mulig hvis krypteringsprosedyrer er innebygd i DBMS. I dette tilfellet oppnås et høyt beskyttelsesnivå mot uautorisert tilgang, men implementeringen av modusen er forbundet med komplikasjonen av DBMS. Enhver kryptering reduserer ytelsesnivået til DBMS.

Under moderne forhold innebærer enhver aktivitet å håndtere store mengder informasjon, som produseres av et bredt spekter av mennesker. Beskyttelse av data mot uautorisert tilgang er en av prioriteringene når man designer ethvert informasjonssystem. Den siste tidens økte betydning av informasjon har resultert i høye krav til datakonfidensialitet. Databasestyringssystemer, spesielt relasjonelle DBMS-er, har blitt det dominerende verktøyet på dette området. Å sikre informasjonssikkerheten til et DBMS blir avgjørende når man velger et spesifikt middel for å sikre det nødvendige sikkerhetsnivået for organisasjonen som helhet.

Tre hovedaspekter ved informasjonssikkerhet er viktige for et DBMS - konfidensialitet, integritet og tilgjengelighet. Emnet for denne artikkelen er den første av dem - midler til beskyttelse mot uautorisert tilgang til informasjon. Den generelle ideen med å beskytte en database er å følge anbefalingene formulert for sikkerhetsklasse C2 i evalueringskriteriene for pålitelige datasystemer.

Sikkerhetspolicyen bestemmes av dataadministratoren. Databeskyttelsesløsninger bør imidlertid ikke bare begrenses til DBMS. Absolutt databeskyttelse er praktisk talt umulig å implementere, så de nøyer seg som regel med relativ beskyttelse av informasjon – de er garantert å beskytte den i tidsperioden inntil uautorisert tilgang til den får konsekvenser. Datatilgangsavgrensning er også beskrevet i databasen gjennom begrensninger, og informasjon om dette lagres i denne systemkatalogen. Noen ganger kan tilleggsinformasjon bli bedt om fra operativsystemene der databaseserveren og klienten som har tilgang til databaseserveren opererer.

Noen vilkår

sensitiv informasjon – informasjon som krever beskyttelse.

Tilgang til informasjon - kjennskap til informasjon, dens behandling (spesielt kopiering), modifikasjon, ødeleggelse.

Tilgangssubjekt er en person eller prosess hvis handlinger er regulert av adgangskontrollregler.

Tilgangsobjekt er en informasjonsenhet for et automatisert system, som er regulert av tilgangskontrollregler. Tilgang (kontroll) objekter i en DBMS er nesten alt som inneholder endelig informasjon: tabeller (grunnleggende eller virtuelle), visninger, samt mindre dataelementer: kolonner og rader med tabeller og til og med radfelt (verdier). Databasetabeller og visninger har en eier eller skaper. De er også forent ved at de alle presenteres for sluttbrukeren som tabeller, det vil si som noe navngitt som inneholder informasjon i form av mange rader (poster) av samme struktur. Tabellrader er delt inn i felt etter navngitte kolonner.

Adgangskontrollregler (sikkerhetspolicy) er et sett med regler som regulerer rettighetene til subjekter med tilgang til tilgangsobjekter.

Autorisert tilgang til informasjon - tilgang til informasjon som ikke bryter reglene for tilgangskontroll.

Uautorisert tilgang til informasjon - tilgang til informasjon som bryter reglene for tilgangskontroll ved bruk av standardmidler levert av datateknologi eller automatiserte systemer.

Tilgangsidentifikator er et unikt attributt til et objekt eller emne for tilgang.

Identifikasjon - tilordne en identifikator til objekter og tilgangsobjekter og (eller) sammenligne den presenterte identifikatoren med listen over tildelte identifikatorer.

Passord er identifikatoren til emnet, som er dets hemmelighet.

Autentisering - sjekke at tilgangssubjektet eier identifikatoren presentert av ham, bekrefter ektheten.

I DBMS, på stadiet for tilkobling til databasen, blir brukere identifisert og autentisert. Brukeren eller prosessen får deretter tilgang til dataene i henhold til sitt sett med tillatelser. Hvis en brukers tilkobling til databasen går tapt, rulles den gjeldende transaksjonen tilbake og brukeren må identifiseres på nytt og legitimeres når tilkoblingen gjenopprettes.

Autoritetsnivået til tilgangssubjektet (subjektprivilegium) er et sett med tilgangsrettigheter for tilgangssubjektet (for korthets skyld vil vi i fremtiden bruke begrepet "privilegium").

En brudd på sikkerhetspolitikken er et tilgangssubjekt som gir uautorisert tilgang til informasjon.

Sikkerhetspolicybruddmodell - en abstrakt (formalisert eller uformell) beskrivelse av en brudd på adgangskontrollregler.

Informasjonsintegritet er evnen til datateknologi (i dette tilfellet informasjonssystemet som helhet) til å sikre uforanderlighet av informasjon under forhold med utilsiktet og (eller) tilsiktet forvrengning (ødeleggelse).

Sensitivitetsetikett er et informasjonselement som karakteriserer konfidensialiteten til et objekt.

Multilevel secure - beskyttelse som sikrer differensiering av tilgang til subjekter med ulike tilgangsrettigheter til objekter med ulike konfidensialitetsnivåer.

DBMS-brukere

DBMS-brukere kan deles inn i tre grupper:

1. Applikasjonsprogrammerere er ansvarlige for å lage programmer som bruker en database.

   Når det gjelder databeskyttelse, kan en programmerer enten være en bruker med rettigheter til å lage og manipulere dataobjekter, eller en bruker med kun datamanipuleringsprivilegier.

2. Database sluttbrukere - arbeid med databasen direkte gjennom en terminal eller arbeidsstasjon. Vanligvis har sluttbrukere et strengt begrenset sett med datamanipuleringsprivilegier. Dette settet kan defineres når du konfigurerer sluttbrukergrensesnittet og kan ikke endres. Sikkerhetspolicyen i dette tilfellet bestemmes av sikkerhetsadministratoren eller databaseadministratoren (hvis dette er samme offisielle).
3. Databaseadministratorer utgjør en spesiell kategori av DBMS-brukere. De oppretter databasene selv, utfører teknisk kontroll av funksjonen til DBMS, og sikrer den nødvendige ytelsen til systemet. I administratoransvar I tillegg inkluderer det å gi brukere tilgang til dataene de trenger, samt skrive (eller hjelpe med å definere) de eksterne representasjonene av data som brukeren trenger. Administratoren definerer reglene for datasikkerhet og integritet.

Skjønnsmessig beskyttelse

Moderne DBMS-er har tilstrekkelig utviklet metoder for skjønnsmessig beskyttelse.

Skjønnsmessig tilgangskontroll - differensiering av tilgang mellom navngitte subjekter og navngitte objekter. En enhet med en viss tilgangsrett kan overføre denne retten til en hvilken som helst annen enhet.

Skjønnsmessig beskyttelse er en logisk beskyttelse på flere nivåer.

Logisk beskyttelse i et DBMS er et sett med privilegier eller roller i forhold til det beskyttede objektet. Logisk beskyttelse inkluderer også eierskap til en tabell (visning). Eieren av bordet kan endre (utvide, ta bort, begrense tilgang) settet med privilegier (logisk beskyttelse). Logiske beskyttelsesdata er plassert i databasesystemtabellene og er atskilt fra de beskyttede objektene (tabeller eller visninger).

Informasjon om registrerte databasebrukere lagres i systemkatalogen. Moderne DBMS Har ikke generell syntaks SQL-databaseforbindelsessetninger fordi deres opprinnelige syntaks er før ISO-standarden. Imidlertid er nøkkelsetningen ofte CONNECT. Nedenfor er syntaksen til denne erklæringen for henholdsvis Oracle og IBM DB2:

KOBLE TIL [ ] bruker/passord[@database] KOBLE TIL database BRUKER bruker BRUKER passord

Disse setningene gjenspeiler det nødvendige settet med attributter og viser også forskjellen i syntaks. Formatet til database_attribute bestemmes vanligvis av DBMS-leverandøren, og det samme gjelder navnet på brukeren som har systemprivilegier som standard (SYSDBA/SYSOPER i tilfellet med Oracle).

Tilkobling til systemet av uidentifiserte brukere og brukere hvis autentisitet av identifikasjon ikke har blitt bekreftet under autentisering er ekskludert. Under en brukerøkt (fra vellykket identifikasjon og autentisering til frakobling fra systemet) er alle handlingene hans direkte relatert til resultatet av identifikasjon. Å koble fra en bruker kan enten være normalt (KOBLE-operasjon) eller tvunget (kommer fra en administratorbruker, for eksempel i tilfelle sletting av en bruker eller i tilfelle et nødavbrudd i klient-server-kommunikasjonskanalen). I det andre tilfellet vil brukeren bli informert om dette, og alle handlingene hans vil bli kansellert til den siste commit av endringene han gjorde i databasetabellene. Uansett, i løpet av arbeidsøkten, vil den identifiserte brukeren være gjenstand for tilgang til midlene for å beskytte informasjon mot uautorisert tilgang (heretter referert til som IPS NSD) til DBMS.

Etter åpen systemteknologi kan tilgangssubjektet få tilgang til databasen gjennom DBMS bare fra programmer levert i distribusjonssettet eller utarbeidet av ham, og kun ved å bruke standard systemverktøy.

Alle systemkontrollemner er lagret i systemautorisasjonstabellen og er delt inn i en rekke kategorier for systemet, som CONNECT, RESOURCE og DBA. Settet med slike kategorier bestemmes av DBMS-produsenten. Det er ingen tilfeldighet at vi foreslår den spesifiserte vurderingsrekkefølgen - slik skjer veksten av evner (myndigheter) for hver enkelt type forbindelse:

• CONNECT - sluttbrukere. Som standard har de bare lov til å koble til databasen og utføre spørringer på data, alle handlingene deres er regulert av privilegiene som er gitt dem;
• RESURSE - privilegerte brukere som har rett til å lage sine egne objekter i databasen (tabeller, visninger, synonymer, lagrede prosedyrer). Brukeren - eieren av objektet har et komplett sett med privilegier til å administrere dette objektet;
• DBA er en kategori av databaseadministratorer. Inkluderer mulighetene til begge tidligere kategorier, samt muligheten til å legge inn (fjerne) sikkerhetsemner i (fra systemet) eller endre deres kategori.

Det bør spesielt bemerkes at i noen implementeringer er administrative handlinger også adskilt, noe som fører til tilstedeværelsen av flere kategorier. I Oracle er altså en bruker som heter DBA administrator for en databaseserver, ikke en enkelt database. I RELEX Linter DBMS er det ikke noe konsept for en databaseserveradministrator, men bare konseptet med en spesifikk databaseadministrator. Det finnes en rekke kategorier av administratorer i IBM DB2: SYSADM (det høyeste nivået; en systemadministrator med fulle rettigheter); DBADM (Database Administrator, som har alle rettighetene innenfor en bestemt database). Databaseer tilgjengelige for brukere kalt SYSCTRL (det høyeste autoritetsnivået systemadministrasjon, som bare gjelder operasjoner som påvirker systemressurser; direkte tilgang til data er forbudt, operasjoner med å opprette, endre, slette en database, overføre en database eller forekomst til en passiv tilstand (stille), opprette og slette tabellplasser er tillatt), SYSMAINT (det andre nivået av systemadministrasjonsautoritet, inkludert all støtteoperasjonsytelse for forekomsten; direkte tilgang til data for denne brukeren er forbudt, operasjoner med å endre databasekonfigurasjonsfiler, sikkerhetskopiering av databasen og tabellplasser, databasespeiling er tillatt). For hver administrativ operasjon i IBM DB2 er det definert et nødvendig sett med administrative kategorier som brukeren som utfører en bestemt administrativ forespørsel må tilhøre. Dermed kan SYSADM eller DBADM utføre operasjoner for å tildele privilegier til brukere, og for å opprette et dataobjekt må brukeren ha CREATETAB-privilegiet.

Administratoren for hver database er ansvarlig for å opprette en krets av mulige brukere av databasen han oppretter og avgrense kreftene til disse brukerne. Data om avgrensning finnes i databasesystemkatalogen. Selvfølgelig kan denne informasjonen brukes til uautorisert tilgang og må derfor beskyttes. Beskyttelsen av disse dataene utføres ved hjelp av selve DBMS.

DBMS lar deg registrere en bruker og lagre informasjon om hans unike identifikator. Oracles sikkerhetsmotor lar deg for eksempel opprette databasebrukere gjennom setningen:

LAG BRUKERIDENTIFISERT bruker VED passord

IBM DB2-sikkerhetsundersystemet kan bruke brukeridentifikatorer for operativsystemet; henne SQL-syntaks inneholder ikke en klausul som ligner på CREATE USER-klausulen. Microsoft SQL Server kan bruke både database- og operativsystemautentisering. Men vi vil ikke diskutere fordelene og ulempene ved autentiseringsmetoder valgt av produsenter her - alle lar oss bygge riktige ordninger for å bestemme autentisiteten til brukere. Bruk av ekstra autentiseringsmidler i informasjonssystemet er ikke forbudt.

Et sett med privilegier kan defineres for en spesifikk registrert bruker eller for en gruppe brukere (dette kan være brukergrupper selv, roller osv.). Det beskyttede objektet kan være en tabell, visning, lagret prosedyre

etc. ( detaljert liste beskyttelsesobjekter er tilgjengelige i dokumentasjonen for DBMS som brukes). Sikkerhetsemnet kan være en bruker, en brukergruppe eller en rolle, eller en lagret prosedyre, hvis dette er gitt av implementeringen som brukes. Hvis det følger av implementeringen som brukes at den lagrede prosedyren har en "dobbel status" (den er både et beskyttelsesobjekt og et beskyttelsesobjekt), må du nøye vurdere mulige modeller for brudd på tilgangsrettigheter og forhindre disse bruddene ved å bygge, hvis mulig, et passende beskyttelsessystem.

Når du bruker lagrede prosedyrer, bør du være spesielt oppmerksom på hvilken bruker som kjører denne lagrede prosedyren i hver konkret tilfelle. Inntil nylig ble lagrede prosedyrer utført i Oracle på vegne av eieren av den lagrede prosedyren, og ikke på vegne av brukeren som ringte. Gjeldende versjon Oracle gir muligheten til å spesifisere under hvis navn en kalt lagret prosedyre skal utføres, men brukeren må bare ha EXECUTE-rettigheten for denne prosedyren. I Linter, for eksempel, blir lagrede prosedyrer alltid utført på vegne av brukeren som ringte prosedyren.

Rettigheter for en spesifikk bruker kan tildeles av en administrator enten eksplisitt eller implisitt, for eksempel gjennom en rolle. En rolle er en annen mulig navngitt bærer av privilegier. En liste over tillatte brukere er ikke knyttet til en rolle - i stedet er roller beskyttet med passord, med mindre selvfølgelig en slik funksjon støttes av DBMS-produsenten. Roller er praktiske å bruke når et bestemt sett med privilegier må gis (eller tas bort) til en gruppe brukere. På den ene siden gjør dette det lettere for administratoren å administrere rettigheter, på den andre siden innfører det en viss rekkefølge dersom det er nødvendig å endre rettighetssettet for en gruppe brukere på en gang. Det bør spesielt bemerkes at når du utfører lagrede prosedyrer og interaktive spørringer, kan settet med brukerprivilegier avhenge av hvordan de ble oppnådd: eksplisitt eller gjennom en rolle. Det finnes også implementeringer, for eksempel i Oracle, hvor lagrede prosedyrer bruker privilegier som er eksplisitt gitt til brukeren. Hvis implementeringen du bruker har denne egenskapen, bør endring av privilegiene til en brukergruppe implementeres som et sett med kommandoer eller som en administrativ prosedyre (avhengig av administratorens preferanser).

Forslag til rettighetsadministrasjon:

• privilegieoppgave: GI privilegium TIL fag
• oppheve privilegium: REVOKE privilege FRA emne

Hvis subjekt=bruker, blir privilegiet tildelt ham eksplisitt. Hvis emne = rolle, brukes følgende for å administrere privilegier:

GI ROLLE rollenavn TIL emne OPPHAV ROLE rollenavn FRA emne

Rettigheter tildeles alle brukere av systemet som følger:

GI OFFENTLIGHET privilegium

I dette tilfellet vil hver nyopprettede bruker automatisk motta dette privilegiet. Privileget kan kanselleres som følger:

OPPHAV privilegiet FRA OFFENTLIGHET

Vær oppmerksom på at enkelte implementeringer, for eksempel IBM DB2, bruker brukergrupper definert i operativsystemet. Derfor bør du være oppmerksom på implementeringsfunksjonene til rolleanaloger i DBMS. Vi må finne ut om implementeringen inneholder SQL-setninger som:

LAG ROLLE rollenavn SLIP ROLLE rollenavn

Når du kontrollerer tilgang til tabeller og visninger, bestemmes settet med privilegier i DBMS-implementeringen av produsenten.

Datasampling og modifikasjonsprivilegier:

SELECT - rettighet til å velge data;

INSERT - rett til å legge til data;

SLETT - rett til å slette data;

OPPDATERING - rettighet til å oppdatere data (du kan spesifisere spesifikke kolonner som er tillatt for oppdatering).

Rettigheter for å endre tabellstruktur:

ALTER - endre den fysiske/logiske strukturen til basistabellen (endre størrelsen og antall tabellfiler, introdusere en ekstra kolonne, etc.);

INDEX - opprette/slette indekser på kolonner i basistabellen;

ALT - alt mulige handlinger over bordet.

Implementeringer kan inneholde andre typer privilegier, for eksempel: CONTROL (IBM DB2) - kompleks rettighet til å administrere tabellstruktur, REFERANSER - rettighet til å lage fremmednøkler, RUNSTAT - innsamling av statistisk informasjon om en tabell og andre.

Imidlertid er skjønnsmessig beskyttelse ganske svak, siden tilgangen er begrenset kun til navngitte objekter, og ikke til de faktiske dataene som er lagret. Ved implementering av et informasjonssystem ved bruk av et relasjons-DBMS, vil objektet for eksempel være en navngitt relasjon (det vil si en tabell), og subjektet vil være en registrert bruker. I dette tilfellet er det umulig å fullstendig begrense tilgangen til bare deler av informasjonen som er lagret i tabellen. En del av problemet med å begrense tilgangen til informasjon løses ved visninger og bruk av lagrede prosedyrer som implementerer et bestemt sett med forretningshandlinger.

En visning er et generert utvalg av tupler lagret i en(e) tabell(er). Visninger kan nås på samme måte som tabeller, bortsett fra datamodifikasjonsoperasjoner, siden noen visningstyper ikke kan endres. Ofte i implementeringer lagres visningen som tekst som beskriver hentingsforespørselen, i stedet for selve datahentingen; utvalget opprettes dynamisk på tidspunktet for utførelse av SQL-setningen ved hjelp av view. Men det er ikke lenger mulig å begrense tilgangen til for eksempel to dokumenter som tilfredsstiller samme utvalgsbetingelse. Dette skyldes det faktum at selv om du introduserer et eget attributt som vil lagre informasjon om sensitivitetsetiketten til et dokument, vil det ved bruk av SQL være mulig å få et utvalg av data uten å ta hensyn til attributtet til denne etiketten. Dette betyr faktisk at enten må databaseserveren selv gi et høyere nivå av informasjonssikkerhet, eller så må den implementeres dette nivået beskytte informasjon ved å strengt begrense operasjonene som en bruker kan utføre ved bruk av SQL. På et eller annet nivå kan en slik distinksjon implementeres ved å bruke lagrede prosedyrer, men ikke fullstendig - i den forstand at selve DBMS-kjernen lar deg bryte forbindelsen "beskyttet objekt - følsomhetsetikett".

Obligatorisk beskyttelse

Obligatoriske beskyttelsesmidler leveres av spesielle (klarerte) versjoner av DBMS.

Obligatorisk tilgangskontroll er avgrensningen av tilgang for subjekter til dataobjekter, basert på informasjonen i objektene, preget av en konfidensialitetsetikett, og på offisiell tillatelse (opptak) fra subjekter til å få tilgang til informasjon på dette nivået av konfidensialitet.

Hvorfor er mandatbeskyttelse nødvendig? Tilfeldige tilgangskontroller er spesifikke for nivå C-sikkerhet og er generelt tilstrekkelig for de aller fleste kommersielle applikasjoner. Imidlertid løser de ikke ett veldig viktig problem - oppgaven med å overvåke informasjonsoverføringen. Tilfeldige tilgangskontroller kan ikke hindre en autorisert bruker i å lovlig innhente sensitiv informasjon og deretter gjøre den tilgjengelig for andre, uautoriserte brukere. Det er ikke vanskelig å se hvorfor det er slik. Med vilkårlig tilgangskontroll eksisterer privilegier separat fra dataene (i tilfelle av relasjonelle DBMS-er, separat fra radene med relasjonstabeller), som et resultat av at dataene viser seg å være "upersonlige" og ingenting hindrer dem i å bli overført til hvem som helst, til og med ved å bruke selve DBMS; alt du trenger å gjøre er å få tilgang til tabellen eller visningen.

Den fysiske beskyttelsen av et DBMS karakteriserer hovedsakelig dataene (deres eierskap, betydning, representativitet, etc.). Dette er i utgangspunktet sikkerhetsetiketter som beskriver medlemsgruppen og nivåer av sensitivitet og verdi for et objekts (tabell, kolonne, rad eller felt) data. Sikkerhetsetiketter (fysisk beskyttelse) er uendret gjennom hele eksistensen av det beskyttede objektet (de ødelegges bare sammen med det) og er lokalisert geografisk (på disken) sammen med de beskyttede dataene, og ikke i systemkatalogen, som skjer med logisk beskyttelse.

DBMS tillater ikke at personvernetiketter ignoreres når du får tilgang til informasjon. Slike DBMS-implementeringer representerer som regel et sett med verktøy både på servermaskinen og på klientmaskinen, og det er mulig å bruke en spesiell beskyttet versjon av operativsystemet. I tillegg til å begrense tilgangen til informasjon gjennom konfidensialitetsetiketter, gir sikre DBMS-er midler til å overvåke subjekters tilgang til beskyttede objekter (revisjon).

Bruken av et DBMS med obligatoriske beskyttelsesfunksjoner lar deg skille tilgang til de faktiske dataene som er lagret i informasjonssystemet fra tilgang til navngitte dataobjekter. Beskyttelsesenheten i dette tilfellet vil spesielt være en post om kontrakt N, og ikke en tabell eller visning som inneholder informasjon om denne kontrakten. En bruker som prøver å få tilgang til avtalen vil ikke lenger kunne omgå personvernmerket. Det finnes implementeringer som lar deg begrense tilgangen til en bestemt verdi av et spesifikt attributt i en bestemt rad i en bestemt tabell. Det er ikke begrenset til bare én sensitivitetsetikettverdi - vanligvis er selve etiketten et sett med verdier som reflekterer for eksempel sikkerhetsnivået til enheten som bordet er lagret på, sikkerhetsnivået til selve bordet, sikkerheten nivået til et attributt, og sikkerhetsnivået til en bestemt tuppel.

Med unntak av egenskapsattributtet (logisk beskyttelse), som deler data (tabeller) i egne (tilhører et gitt emne) og utenlandske, deler fysisk beskyttelse data finere. Men er det mulig å klare seg uten fysisk beskyttelse, eller i det minste prøve, ved å implementere for eksempel et komplekst sett med lagrede prosedyrer. Generelt sett implementeres et visst utseende av slik beskyttelse i tilfelle når etiketter legges til tabellen som et ekstra attributt, tilgang til tabellene er forbudt i det hele tatt, og ingen applikasjoner kan utføre en interaktiv SQL-spørring, men bare en lagret prosedyre, etc. En rekke implementeringer av dette beskyttelsesnivået bruker et kall til et sett med lagrede prosedyrer med svært abstrakte (som er veldig ønskelig) navn. Systemet for å implementere informasjonssikkerhet i dette tilfellet er ganske komplekst og krever et visst nivå av tillit til sikkerhetsadministratoren, siden han har rett til å endre strukturen til databasen, og derfor lagrede prosedyrer og visninger. I dette tilfellet er ikke sikkerhetsadministratoren fysisk isolert fra å administrere hemmelige data.

I tillegg gjør sikre DBMS-er det mulig å begrense tilgangen til et informasjonssystem fra enkelte arbeidsstasjoner for enkelte registrerte brukere, definere driftsmoduser og pålegge tidsbegrensninger for arbeidet til enkelte brukere fra enkelte arbeidsstasjoner. Hvis disse alternativene er implementert på applikasjonsnivå oppgaven kommer som regel ned til å lage en applikasjonsserver som sporer "hvem som kom fra hvor." Et eget sett med serverapplikasjoner (vanligvis lagrede prosedyrer, hvis DBMS ikke har obligatorisk beskyttelse) gir revisjon.

La oss se på mandatbeskyttelsen mer detaljert. La oss som et eksempel ta den obligatoriske beskyttelsen til Linter DBMS, som har fått anerkjennelse i en helt spesifikk sektor – rettshåndhevelsesbyråer, som eneste DBMS sertifisert for den andre klassen av beskyttelse mot uautorisert tilgang, som tilsvarer klasse B3 iht. den amerikanske nasjonale standarden.

Først er alle listede objekter (uavhengig av deres hierarki i databasen) her delt inn i medlemsgrupper. Et objekt kan kun tilhøre én av gruppene (dette kan for eksempel deles inn i avdelinger i organisasjonen). Medlemsgrupper er direkte relatert til faggrupper (se nedenfor). En subjekt har rett til å se kun data fra sin egen gruppe, dersom det ikke er etablert tillitsforhold mellom grupper av subjekter.

For det andre er alle objekter ordnet i et hierarki i henhold til nivåer av konfidensialitet og i henhold til nivåer av verdi eller viktighet. Personvernnivået bryter ned objekter etter lese (og til og med visning) tilgjengelighet. En bruker med et lavere tilgangsnivå vil ikke engang vite om eksistensen av objekter med et høyere nivå høy level personvern. Verdinivået, tvert imot, bryter ned data (objekter) etter viktighet, noe som begrenser muligheten for sletting og modifisering av dem.

De allerede nevnte "Kriterier for vurdering av pålitelige datasystemer" i forhold til sikkerhetsnivå B-systemer beskriver sikkerhetsmerkemekanismen implementert i DBMS omtalt i denne artikkelen.

Objektetiketten inkluderer følgende:

1. Gruppe av personen som bidro med dette objektet.
2. Lesetilgangsnivå - RAL (Lesetilgangsnivå).
3. Skrivetilgangsnivå - WAL (skrivetilgangsnivå).

Emneetiketten ser lik ut:

1. Gruppen som faget tilhører.
2. Subject RAL-nivå, som representerer det maksimale RAL-nivået av informasjon som er tilgjengelig for faget.
3. WAL-nivået til emnet, det vil si minimums RAL-nivået til objektet som kan opprettes av dette emnet.

Alle databasebrukere anses å være delt inn i ikke-overlappende grupper. Gruppen beskriver området tilgjengelig for brukeren data. For hver gruppe er det en gruppeadministrator (DBA-nivå for gruppen) opprettet av systemadministratoren. I dette tilfellet ser ikke brukere av en gruppe data som tilhører brukere av en annen gruppe. I denne forbindelse har Linter DBMS en spesiell funksjon: systemet implementerer et konsept som "tillitsnivået mellom grupper." Tillitsnivåer kan imidlertid ikke nestes. En gruppe representerer en numerisk verdi i området. Gruppe 0 er systemadministratorgruppen. Bare systemadministratoren kan opprette en bruker i en annen gruppe enn sin egen. All data opprettet på vegne av brukeren er merket med gruppen hans.

Tilgangsnivåer er introdusert for å bekrefte rettigheter til å lese og skrive informasjon. Følgende tilgangsnivåer er introdusert:

1. For brukeren (emnet):

• RAL - tilgangsnivå; brukeren kan motta (lese) informasjon hvis RAL-nivå ikke er høyere enn hans eget tilgangsnivå;
• WAL - nivå av tillit for å redusere nivået av konfidensialitet; brukeren kan ikke legge inn informasjon med et tilgangsnivå (RAL-nivå) lavere enn det gitte WAL-brukernivået. Med andre ord kan brukeren ikke gjøre informasjonen tilgjengelig for ham mindre konfidensiell enn spesifisert i denne parameteren.

1. Til informasjon:

• RAL - lesenivå; brukeren kan motta (lese) informasjon hvis RAL-nivå ikke er høyere enn hans eget RAL-nivå (kan lese mindre konfidensielle data);
• WAL - verdinivå eller skrivetilgangsnivå (endring, sletting); brukeren kan endre (slette) informasjon hvis WAL-nivå ikke er høyere enn RAL-nivået.

Bare systemadministratoren kan opprette en bruker med vilkårlige nivåer. Andre administratorer (DBAer) kan opprette brukere (eller endre brukernivåer) bare innenfor nivåene som er tildelt dem. Brukeren kan tvinge frem merking av inngangsdata ved å spesifisere tilgangsnivåene for de tilsvarende postene og feltene i attributtlisten (når du utfører INSERT- eller UPDATE-setninger). Som standard arver de angitte dataene nivåene til brukeren som legger inn/endrer dataene. Beskyttede objekter: brukere, tabeller, kolonner, poster (oppgitt når du utfører INSERT), felt med poster (endret når du utfører OPPDATERING). Nivåer, som grupper, kan ikke brukes med mindre de er opprettet av spesielle spørringer.

En konfigurasjon som minst én programmerer har tilgang til kan ikke anses som sikker. Derfor er det å sikre informasjonssikkerhet for databaser en svært kompleks sak, og i stor grad på grunn av selve naturen til relasjonelle DBMS-er.

I tillegg til systematisk bruk av verktøyene beskrevet ovenfor, er det nødvendig å bruke administrative og prosedyremessige tiltak, spesielt regelmessig endring av brukerpassord, og hindre tilgang til fysiske medier informasjon osv.

ComputerPress 3"2002