Obligatorisk oppgave 1 i Databaseadministrasjon.

Transkript

1 Obligatorisk oppgave 1 i Databaseadministrasjon. Gruppenummer 7 Av Kai Hagali Ole J. Schøn Thor Jarle Kinstad Cato Goffeng Høgskolen i Østfold 18 September

2 Gruppen startet med å sette opp de tre forskjellige databasesystemene i henhold til beskrivelsen. Screenshot av dette er ikke lagt ved siden resten av oppgavene er avhengig av dette og derav fremkommer av besvarelsen. Databasen ble en enkel database med gruppens medlemmer, samt noe informasjon om den enkelte. 2

3 Innhold Innhold... 3 Design og oppsett av database:... 5 Sette opp brukere og rettigheter... 6 Views... 6 Test av grants... 8 Test av grants med command line Oppsett av MSSQL server Backup: Logging: Loggfiler MsSQL Mysql logg Forskjellene mellom SQL systemene SQLServer/GUI-verktøy: Sikkerhet: Nivå 1: Nivå 2: Nivå 3: Monitorering: Replikering: Nivå 1: Nivå 2: Oppsett master MySQL server versjon 5.5: Oppsett slave MySQL server versjon 5.1:

4 Nivå 3: Replikasjon mellom 2 SQL Servere Replikasjon mellom MsSQL og MySQL Daffodil DbConvert DBA: Nivå 1: Nivå 2: Gjeste Forelesning Gjeste Forelesning Sammenligning: Nivå 3: Erfaringer/konklusjon Referanser

5 Design og oppsett av database: Laget en meget enkel database med tabell som beskriver gruppens deltakere CREATE DATABASE das CHARACTER SET 'utf8'; CREATE TABLE Deltaker( Deltakerid INT NOT NULL AUTO_INCREMENT PRIMARY KEY, Fornavn Varchar(50) NOT NULL, Etternavn Varchar(50) NOT NULL, Telefonnr Varchar(20) NOT NULL, Epost Varchar(30) NOT NULL, Merknader Varchar(100) ); INSERT INTO Deltaker(Fornavn,Etternavn,Telefonnr,Epost,Merknader) values fyr med peiling og mange meninger'); INSERT INTO Deltaker(Fornavn,Etternavn,Telefonnr,Epost,Merknader) values på å få peiling'); INSERT INTO Deltaker(Fornavn,Etternavn,Telefonnr,Epost,Merknader) values også om DBA'); INSERT INTO Deltaker(Fornavn,Etternavn,Telefonnr,Epost,Merknader) values ('Thor også med saken ); Dette gir oss tabellen : Bilde 1- Screenshot av select * på testdatabasen das. 5

6 Sette opp brukere og rettigheter Opprettet brukerkontoer for hvert av gruppens medlemmer for å unngå bruk av root konto. Brukerne ble opprettet med dene syntaksen: CREATE USER % IDENTIFIED BY <lurtpassord> ; I første omgang ble Grant satt til ALL fordi alle i utgangspunktet agerer DBA og for å kunne utføre de fleste operasjoner hver for oss.. I neste omgang vil vi teste begrensede Grants for å se hva som skjer og eventuele feilmeldinger. GRANT ALL ON *.* TO 'catoag'@' %'; /* 0 rows affected, 0 rows found. Duration for 1 query: 0,000 sec. */ GRANT ALL ON *.* TO 'tj'@' %'; /* 0 rows affected, 0 rows found. Duration for 1 query: 0,000 sec. */ GRANT ALL ON *.* TO 'cappa'@' %'; /* 0 rows affected, 0 rows found. Duration for 1 query: 0,000 sec. */ GRANT ALL ON *.* TO ole'@' %'; /* 0 rows affected, 0 rows found. Duration for 1 query: 0,000 sec. */ Syntaksen for grant er bygget opp på denne måten at det settes hvilke operasjoner brukeren kan utføre, på hvilke databaser og tabeller, og hvor bruker kan koble opp mot databasen fra. Views Dette er lagrede spørringer mot en database som kreerer virtuell(e) tabell(er) som selve resultatet av spørringen. Funksjonen av dette er å kunne vise data i en gitt sammenheng uten å kunne sende med parametere. Dette er da den biten som skiller view ifra lagrede prosedyrer som er en alternativ metode for å gjøre en lignende jobb. View er derfor en bedre løsning for blant annet selgere som skal ha data om noen spesifikke deler av salgssystemet. Men selve spørringen skal ikke lagre resultatet på noen som helst måte. Dette vil også si at view er en sikrere metode for å vise data til brukere som skal gjøre oppslag kontra en prosedyre der de vil kunne ha muligheten for å endre. Dog vet view kunne være oppdaterbart hvis det som hovedregel har et en-til-en forhold i viewet og de tabeller de gjenspeiler. De finnes såpass mange begrensende variabler slik at det er enklere å si at for de aller 6

7 fleste view er det hverken mulig å oppdatere eller sette inn data. Den aller mest benyttede bruken av view er ved joins, istedet for å måtte reskrive join setningen hver gang ligger det allerede ferdigdefinert en tabell i databasen som fungerer som dette. Med andre ord et view kan spare serveren for repeterende joins siden det allerede ligger klart et resultat av en slik spørring. Dette kan benyttes som underlag for videre spørringer. Eksempel på et view mot vår database vil da være et select statement som gir en fullverdig tabell. Brukeren ser ingen forskjell fra den originale tabellen. Men forskjellen er at brukeren da ikke skal kunne se merknadene som ligger i tabellen. Selve sql setningen for å lage et view: Bilde 2- Screenshot av create view Selve tabellen Deltakere er ikke noen ekte tabell men er laget av et view. Resultatet av select * på denne tabellen blir da slik : Bilde 3- Screenshot av test av view 7

8 For å teste et view kjøres en drop table mot denne tabellen deltakere. Bilde 4- Screenshot av test på spørring uten rettigheter Resultatet av dette blir : Bilde 5- Screenshot av resultat fra test spørring Deltakere er jo ikke en tabell siden den er resultat av et view. Derfor vil denne feilmeldingen være korrekt. Et view vil da gi en tabell som brukere ikke kan slette ved feiltagelse eller direkte handling. Gitt rett miljø kan view gi en økt sikkerhet for selve databasens innhold. Test av grants Opprettet en temporær bruker med kun rettigheter til å se views. Bilde 6- Screenshot av skjema privilegier 8

9 Denne brukeren skal da prøve å kjøre en select setning som den ifølge oppsettet ikke skal kunne gjøre. For enkelthetsskyld blir denne testen gjort i kommandovinduet slik at en kan ha to forskjellige connections til databasen samtidig. Før lagring av rettigheter gir kommandoen show databases kun denne informasjonen: Bilde 7- Screenshot av show databases Etter lagring av rettigheter er ihvertfall databasen synlig: Bilde 8- Screenshot av show databases med rettigheter Vi tester da med en drop database for å se hva som skjer: Bilde 9- Screenshot av feilmelding grunnet manglende rettigheter Dette fikk vi ikke tilgang til da det ikke finnes rettigheter på denne brukeren. Da gikk vi videre med å bruke databasen das. Vi velger da å se hvilke tabeller vi kan se: Bilde 10- Screenshot av show tables 9

10 Både den egentlige tabellen og den virtuelle tabellen er synlig. Vi tar da en enkelt select * fra begge to for å se om det er en forskjell. Bilde 11- Screenshot av feilmelding ved select Bilde 12- Screenshot av feilmelding ved select Vi får da ikke se noe som helst fra disse siden vi ikke har rettigheter for dette. Selv det å få vår testbruker til å se det den skal ifølge oppsettet av kontoen viste seg å være vanskelig. Vi satte begrensningen at den ikke skulle kunne gjøre annet en å benytte seg av show view. Tester ga resultatet : Bilde 13- Screenshot av feilmelding ved select etter rekonfigurasjon Begge tabellene var da ikke tilgjengelige for denne brukeren. Selv om select kommandoen ble gitt som ekstra parameter for kontoen var resultatet det samme. Bilde 14- Screenshot av oppsett av rettigheter justert 10

11 Det er mulig at det er mysql workbench som er problemet her. Det har heller ikke blitt flushet rettigheter. Men uansett så vil logoff/loginn gi samme effekt. Basert på det som er sjekket opp av dokumentasjon så skal notasjonen <database>/<tabell> kunne sette rettigheter på en spesifikk tabell. Test av grants med command line Vi gjorde deretter de samme operasjonene med command line for å kjenne på forskjellen. Logger inn med root og setter view på databasen das. Her ligger en tabell med flere kolonner som vi har kalt Deltaker. Vi bestemmer at kun 3 kolonner skal være synlige: Fornavn, Etternavn og Telefonnr og at nytt view skal hete Deltakerliste: Bilde 15- Lage view i command vindu Vi sjekker view og tester å slette det med drop table. Deretter oppretter vi brukeren test som vi kun kun gir select grants på tabellen Deltakerliste i basen das. Bilde 16- Tester view og oppretter bruker med grants på view. 11

12 Vi logger på MySQL med klienten og tester om denne får det resultatet vi har bestemt. Bilde 17- Hva brukeren vi kaller test ser når den logger inn i viewet som er opprettet. Å sjekke grants på en bruker kan gjøres på denne måten: Bilde 18- Sjekke grants på bruker 12

13 Så vil vi sjekke hva som skjer når vi kjører revoke på brukeren. I denne prosessen fant vi ut at man må bruke nøyaktig de grants brukeren er tildelt ved fjerning. Det ble for eksempel forsøkt REVOKE SELECT ON das.* for brukeren som resulterte i feilmelding. Bilde 19- Revoke av grants på bruker test Under kan man se hva bruker test har tilgang til etter de grants han var tildelt er fjernet. Bilde 20- Hva brukeren har tilgang til uten grants 13

14 Oppsett av MSSQL server. Vi startet installasjonen av MS-SQL server 2008 R2 fra Donau. Ledig plass på testserveren er noe begrenset så vi droppet å kopiere mappen på i overkant av 5 GB. Vi startet setup.exe og valgte «New installation». Første stopp er en advarsel som forteller at det er en aktiv brannvegg (firewall) og at vi må sørge for at riktig port åpnes om vi skal få tilgang utenfra. Dette er noe vi kan se på når installasjonen er ferdig så vi fortsetter. Bilde 21- Screenshot av melding ved installasjon Neste er å avgjøre hva som skal være med i oppsettet. En god regel er å ikke legge til mer enn man skal bruke, på den måten sparer vi ressurser og begrenser tilgang. Siden det lar seg gjøre å legge til flere «features» etter hvert, bestemte vi oss for å starte med de mest nødvendige for å komme i gang. I dette tilfellet er det Data Engine Services og Management Tools. 14

15 Bilde 22- Screenshot av Feature selection ved installering av MsSql Vår testmaskin er ikke satt opp i domene og vi har kun lokal Administrator konto satt opp. For å sikre systemet lager vi lokale brukere som ikke har administrator rettigheter i Windows for hver av de to tjenestene vi skal sette opp først. Bilde 23- Screenshot av server konfigurasjon MsSql 15

16 Backup: Denne deloppgaven ble mer utfordrende en først antatt. Vi viste at vi skulle bruke mysqldump ut i fra beskrivelsen for å få en kopi av en hel database. Som bildet under viser dumper vi innholdet i databasen til filen dass.sql som bruker root og med passord. Det vi ikke skjønte før etter en lengre periode er at dette programmet kjøres externt utenfor mysql innlogging. Her fikk vi nemlig bare sql feil. Men ved å kjøre det eksternt i eget kommandopromt fungerte dette utmerket. Dette må nok kalles en nybegynnerfeil. Bilde 24- Screenshot av login i command prompt Etter å ha justert my.ini filen fikk vi også lagt backupen i egen mappe og ikke på default lokasjon som er i c:\user\administrator. Bildet under viser backup i begge mapper. Bilde 25- Screenshot av søk etter backupfilene 16

17 Den inkrementelle backup er i realiteten en binær logg. Denne settes på i my.ini. Ved å gå inn i den mappen den legges ser vi at vi har en indexfil og de logfilene som tilhører med de forskjellige endringer underveis. Bilde 26- Screenshot av binær loggenes eksistens Etter en backup er det da greit å teste at det virker. som vi ser under er databasen eksisterende. Bilde 27- Screenshot av show databases 17

18 Vi velger så å droppe databasen. Bilde 28- Screenshot av kommandoen drop databases Dette medfører at databasen nå er borte vekk fra mysql. det krever da en restore for å få denne opp igjen. I starten fikk vi flere problemer her. Etter å ha sjekket opp sql filen fant vi fort at det ikke var tilstede en create database sql statement. Ved å sette opp en tom database og deretter velge denne var det da bare å kjøre en restore via mysql > dass.sql. Dette trigget da sql statementet med create table og insert av de forskjellige data. Bilde 29- Screenshot av dumping/backup av databasen 18

19 Logging: Bilde 30- Screenshot av oppsett logging MySql Logging er ikke på som default i MySQL. Med kommandolinjen show variables like '%log%' \G ; kan vi se hvilke logger som er aktive. Alle er som tidligere nevnt ikke aktivert så vi skriver inn kommandolinjene: SET GLOBAL log = ON; SET GLOBAL general_log = ON; SET GLOBAL slow_query_log = ON; 19

20 Nå er loggene aktivert men vi har ikke satt noen path til loggene. Vi editerte my.ini i MySQL og la til disse linjene under seksjonen [mysqld]: Bilde 31 - Konfigurering av logger i my.ini På første forsøk hadde vi ingen path satt til loggene i det vi tenkte at de ville havne i for eksempel programdata folderen. Vi definerte kun inn filnavnene slow,general og error med filendelse log. Etter restart av MySQL kjørte vi noen kommandoer og forsøkte deretter å finne loggfilene på serveren. Vi kunne ikke finne noen logfiler som tilsvarte de som er satt i my.ini og bestemte oss for å lage en egen logg mappe under C:\ logger. etter å ha satt path til de tre loggene i my.ini restartet vi MySQL igjen og skrev kommandoer for at loggene skulle registrere i de forskjellige kategoriene. Ingen loggfiler ble opprettet denne gang heller. For å finne ut hva som var feil sjekket vi skrivetilgang på folderen logger og oppdaget at den kun var readonly. Ingen logger ble opprettet så vi fant at vi måtte opprette filene fysisk: slow.log, general.log og error.log ble opprettet i denne 20

21 mappen og deretter restartet vi MySQL igjen. Etter restarten ble det skrevet til de aktuelle loggene.. 21

22 Loggfiler Begge databasesystemene har muligheter for log filer. Disse lagres forskjellig i de to systemene. Mye av loggene i MsSQL er basert på bruk av SSMS (Management verktøyet), noe som ikke er situasjonen for MySQL. Når så er sagt vil vi først gå inn på de vesentlige loggene i begge systemer for så å dra en sammenligning. MsSQL Her ligger logfilene default i programfolderen. Her finner vi både en hendelseslogg og en profilerlogg. Den siste kan startes opp i et tilhørende program Her kan en gjenskape heler eller deler av de hendelsene som har vært i en periode. Bilde 32 - Logfilene i MsSQL Her ses errorloggene og de såkalte profiler loggene. Selve errorloggen ligger som klartekst og derav er de lette å lese med hvilken som helst tekst editor. Profilerloggene derimot er ikke presentert i klartekst. Ved å dobbeltklikke på en trc fil startes automatisk opp programmet SQL Server Profiler. 22

23 Bilde 33 - Profilerloggfil i MsSQL hentet opp i SQL Server profiler Her kan en reskape en eller flere hendelser i databasen. Dette verktøyet gir da databaseadministratoren en god mulighet for å offline kjøre en problemhendelse for å se hvor eller hvordan problemene oppstår. En bedre forklaring av denne loggen er at det er en debugger. Sammenlignet med MySQL gir denne presentasjonen en tilsynelatende god oversikt. Men det er en mengde kolonner som gitt den informasjon vi har om programmet idag ikke gir en god nok forklaring på eksakt hva disse kolonnene egentlig presenterer. Vi føler det slik at det presenteres så mye informasjon som mulig om hver enkelt hendelse. Loggfil fra MsSQL I tillegg kan vi finne hendelses loggfiler i MsSQL. Disse har vi tilgang til via SSMS management verktøyet. 23

24 Bilde 34 - Hendelses Logfiler i MsSQL Som vi ser er det en overflod av informasjon i disse logg filene. I tillegg til den loggen som tilsvarer general.log i MySQL har vi her også muligheten til å hente opp service logger og system logger. Selve hendelsene kommer ikke klart frem. For eksempel er det ikke like lett å finne en rekke spørringer i dette verktøyet. Men disse han jo dog hentes frem i profiler loggen. Som vi ser under er starten rimelig lik den vi finner i MySQL. 24

25 Bilde 35 - Innholdet i en loggfil fra MsSQL Som nevnt er følelsen av logg filer i MsSQL at de inneholder for mye informasjon i forhold til det å kunne si at en har oversikt over hva som skjer. Når det er sagt inneholder MsSQL profiler logger et viktig verktøy for det å gjenskape hendelser. Dette kan gjøre det lettere å identifisere problemer i database eller tilhørende applikasjoner. Mysql logg General. log logger alle som logger på og av samt alle SQL spørringer som blir gjort mot databasen. Denne loggen er nyttig å feilsøke i når det oppstår feil for klienter og du da kan se hva de har sendt av spørringer. 25

26 Bilde 36 - Utdrag fra MySqL general.log Error loggen registrerer når MySQL serveren blir startet eller stoppet. I tillegg skrives feilmeldinger som oppstår mens serveren går. Bilde 37 - Utdrag fra MySQL error.log 26

27 Slow.log registrer alle SQL spørringer som tar mer en x antall sekunder å gjennomføre. I vårt oppsett logges alle spørringer som tar over et sekund. Bilde 38 - Utdrag fra MySQL slow.log Den siste loggen er binærloggen som registrerer alle forandringer i databasen, som opprettinger av nye baser og tabeller med innhold. Denne loggen sier vi fungerer som en inkrementell backup fordi serveren kan gjenopprettes ut i fra et gitt tidspunkt i loggen. Det engelske utrykket for dette er point-in-time recovery. 27

28 Forskjellene mellom SQL systemene Det vi umiddelbart merker oss er at loggingen i MsSQL er på fra starten, mens det i MySQL må settes opp i konfigureringsfilen før dette fungerer. Lett sagt er det mulig å si at loggene i MySQL er funksjonelle logger som tillater å lese de i klartekst og de kan raskt benyttes for å få databasen tilbake igjen hvis noe skulle skje. Derav ligger det også at for eksempel binærloggen i MySQL kan eksporteres til en annen server og settes opp der uten store problemer. Vi kan ikke se at dette er en mulighet som er lett tilgjengelig i MsSQL. Det kan dog ikke utelukkes at dette er tilfelle, men så langt vi har hatt mulighet til å utforske programmet finner vi ikke noe tilsvarende.vi ser at det er mye lettere å bruke loggene i MySQL på en fornuftig måte. Forskjellene betyr at MySQL kan lettere brukes uten store kunnskaper om programmet mens MsSQL på sin side fordrer ekstrem kompetanse. Vi så etter at vi hadde sett på loggfilene og foretatt en analyse at vi ikke er helt ute av fokus. Sanders "Kaufman, Jr." skrev en artikkel på webstedet Techrepublic som beskriver samme oppfattning. MySQL keeps a binary log of all SQL statements that change data. Because it s binary, this log can be used to replicate data from the master to the storage on one or more slaves very quickly. Even if the server goes down, the binary record is still intact, and replication can take place. For query-heavy databases systems, MySQL scales easily into large data farms. In SQL Server, you can also record every SQL statement, but doing so can be costly. I know of one development shop that had to do this because of other architectural issues, and the sheer volume of data that they were storing on tape was quite remarkable. Instead, SQL Server relies on elaborate mechanisms of record and transaction locking, cursor manipulation, and dynamic replication of data to keep database servers synchronized. If you're skilled at juggling these mechanisms, replication is pretty easy. 28

29 SQLServer/GUI-verktøy: Vi lager en database ved å høyreklikke og velge «New database». Vi velger navnet «cia» og trykker OK. Bilde 39- Screenshot av ny database MsSql 29

30 Bilde 40- Screenshot av oppsett tabell MsSql Deretter lager vi en tabell (på samme måte som over) og legger inn feltene i denne før vi trykker save Dersom vi høyreklikker på den nylige opprettede tabellen og velger «Script table as» à «Insert to» à «New query editor window» kan vi legge inn alle verdiene i databasen. Etter dette er gjort klikker vi «Execute Bilde 41- Screenshot av query window MsSql 30

31 Når vi da høyreklikker på tabellen og velger «Script table as» à «Select to» à«new query editor window» for deretter å trykke på «Execute» ser vi at databasen er opprettet og innehar de verdiene vi la inn i forrige steg. Bilde 42- Screenshot av resultat av select i MsSql Når vi gjorde dette så syntes vi dette var en smidigere og mer oversiktlig prosess enn i et tekstlig grensesnitt. Selv om vi ikke har noen erfaring med programvaren fra før av og måtte knote rundt litt i starten opplevde vi at det lett lot seg lære og utføre oppgaven vi hadde foran oss. Det var fint å kunne få ferdig generert kode i «query» vinduene og vi antar at dette sparte oss for en del tid i form av feilsøking av egen kode. Erfaringsmessig går det mye mer tid for å få noe til å fungere enn det gjorde her. Vi tror nok at en bedret kunnskap om sql ville gjort dette enklere. Samtidig vil det for en administrator antakelig være en greiere arbeidsmetodikk å benytte det tekstbaserte grensesnittet. Her vil erfaring fra systemet og kunnskap om hvordan en skal gjøre det spille mye inn på hvordan effektivisere oppgavene. På den annen side gir det grafiske grensesnittet oss rask tilgang til funksjoner som historikk og logger. Delvinduer gir oss i tillegg enkel tilgang til de forskjelligedelene av arbeidet vi holder på med. Ved å kunne knote oss rundt i programmet lærer vi oss hvordan finne de 31

32 forskjellige elementene vi trenger på en bedre måte. Kall det læring via feiling. En slik læringsform er med på å gi oss som brukere av programmet en bedret hukommelse av hvor de forskjellige elementene/del elementer ligger. 32

33 Sikkerhet: Nivå 1: Trusselbildet mot den eksisterende databasen kan deles opp i to deler. De interne truslene og de eksterne truslene. Med interne defineres de truslene som kommer fra egen organisasjon. Oppgaven beskriver fokus på vår database og ikke de generelle problemene en kan komme over. For vår database vil det være uheldig om en av oss skulle komme til å slette enten med vilje eller utilsiktet hele databasen. For å sikre seg mot dette må en ha tiltak som backup og lagring av denne på utsiden av den installerte serveren. Dernest handler det om selve serveren som enhet. Denne er satt opp virtuelt. Her vil en eventuell disk kræsj få fatale konsekvenser. Hvis vi senere i semesteret ikke har tilgang til de verktøy vi trenger vil vi ikke få gjort de oppgavene vi trenger å utføre. Siden vi ikke har kontroll på installasjonen og eventuell backup av denne er vi avhengig av å ha en ekstern backup av databasen som minimum. Samt sette opp rutiner som gjør dette automatisk. Ved å ha en kopi eksternt vil vi raskt kunne sette opp en alternativ database server som gjør at oppgavene kan utføres i henhold til plan. Aksess til server fra andre enn oss i gruppen er avhengig av å få aksess via hacking. Vår mulighet til å forhindre dette ligger i å ha sterke passord. Med sterke passord menes passord som består IT-Avdelingen ved Høgskolen i Østfold sin passordtester. Passordtesteren har flere ledd som må tilfredsstilles: Bilde 43- Screenshot av passord testeren ved Høgskolen i Østfold 33

34 Dernest handler det om å oppdatere databaseinstallasjonene med eventuelle patcher det samme gjelder operativsystemet og eventuelle oppdtateringer. Siden det er en server er ikke Java noe som skal være tilstede. Men siste dagers sikkerhetsdebatt viser klart behovet for å følge med på og implementere oppdateringer. Mysql er som oppgaven beskriver satt slik at den skal aksesseres utenifra. Dette medfører at det er en port minimum som står åpen. Vi kunne valgt en annen port en standardporten 3306 for Mysql noe som ble gjort annerledes for den versjonen av Mysql som skulle være for replikering.. Men viktigere er å slå av ICMP response på windows 2008 r2 serveren. Da vil ihvertfall ikke en ping avsløre at serveren lever. Er dette klart vil neste trekk for en som ønsker å komme inn å se om det er åpne porter. Vårt viktigste trekk for å se slike eventuelle angrep er å følge med på loggene til både server og database. For å se om det er aktivitet som ikke skulle vært der. Det andre tiltaket vi kan ha ellers er som tidligere nevnt backup av databasene. Dette handler først og fremst om å ikke gi brukere mere rettigheter en de trenger for å utføre en oppgave. Hvis en person for eksempel kun skal kunne oppdatere kontaktinformasjon til studenter så trenger han kun tilgang til den tabellen. Men har personen adgang til hele databasen vil han for eksempel kunne forandre karakterer eller annen informasjon. Den mest vanlige trusselen ellers er uhederlige brukere. Siden denne gruppen består av dedikerte studenter anses risikoen for at en av deltakerene saboterer for minimal. Det eneste som kan redusere denne faktoren er ekstern backup. Den er ikke noe hinder i å legge den på det felles området på Google Docs som benyttes for sammarbeidet av rapportene. Nivå 2: Oppgaven beskriver en analyse av forskjellige bøkers fremstilling av sikkerhetsproblematikken i en database administrators verden. Bøkene som er valgt er Fundamentals of database systems av Ramez Elmasri, Shamkant B. Samt Database systems : a practical approach to design, implementation, and management av Thomas M. Connolly og Carolyn E. Begg. 34

35 Fundamentals of database systems identifiserer følgende sikkerhetsproblemer. Legal and ethical, policy issues, system-related issues og security levels. Alle disse 4 kategoriene påvirker følgende parametere loss of integrity, loss of avaiability og loss of confidentiality. For å møte dette benyttes det access control, interference controll, flow control og encryption. Dette medfører en tabellisert presentasjon av risiko og hvilke parameter som påvirkes : Loss Integrity Loss avaiability Loss confidentiality Legal/ethical Policy System Security Tabell 1- Tabellisert oppsett av trusler For eksempel vil da et policy problem påvirke tilgjengeligheten til databasen eller vil det påvirke integriteten eller selve informasjonen i database. Som et eksempel en person logger seg på med en annen persons brukerid. Med dette følger da den andre personens rettigheter. Hvilken betydning vil dette ha for selve databasen. Forfatterene mener at dette påvirker integriteten. Men det vil være naturlig å hevde at med feil brukerid kan en påvirke alle 3 forskjellige parametere. Selv om tilgangen med feil brukerid skjer ved et uhell så kan en være uheldig å slette feil for eksempel, eller få tilgang til informasjon om for eksempel kunder en ikke skulle hatt. Forfatterene skiller dog av ved bevist bruk av annens id, men tar ikke høyde for feilbruk ved tilfeldigheten at noen ikke hadde logget seg ut av en arbeidsstasjon. For å motvirke disse trusslene defineres det 4 forskjellige ledd. Disse er definert slik: Legal and ethical : Retten til å aksessere informasjon. Policy issues: Hva skal ikke være tilgjengelig - medisinske journaler eller kredittrating. System related issues: sikkerhetsfunksjoner og i hvilket ledd skal de benyttes hardware, os eller dbms. 35

36 Sikkerhetsnivåer: Klassifisere data i klasser som hemmelig topp hemmelig med mer. Oppbyggingen som presenteres i denne boken kan ses på som et godt grunnlag for en sikkerhets analyse i alle ledd i et foretak. Sikkerhet handler ikke bare om tilgangskontroll, men også om bevisthet om hva en skal kunne gjøre i et databasesystem. Database systems : a practical approach to design, implementation, and management benytter seg av et oppsett med 5 definerte situasjoner: Theft and fraud Loss of confidenciality Loss of privacy Loss of integrity Loss of availability Deretter settes disse 5 kategoriene opp mot forskjellige threats og identifiserer hvem av de som de kommer inn under. Med threats menes det de forskjellige hendelser som kan forekomme. Dette betyr at en må først identifisere trusslene mot systemet for deretter å bestemme hva dette kan påvirke. F.eks bruke en annens aksess til db kommer inn under theft and fraud, loss of confidentiality og loss of privacy. Merkelig nok ses ikke dette på som et integritetsproblem. Basert på hva det kan medføre og alvorlighetsgraden bestemmer en så tiltak. Begge bøkene benytter tilsynelatende like begreper. Oppbyggingen er noe annerledes. Men de kommer frem til omtrent samme konklusjoner. Det viktigste er at en uansett ikke kan se på sikkerhet i sammenheng med databaser som kun systemteknisk. Det er på det rene at selve sikkerhetssørsmålet handler om forankring i egen organisasjon. Er det bare databaseadministratoren som snakker om sikkerhet vil ikke totalintegriteten i systemet være tilstede. Det ser vi klart av forskjellige lekasjer av kjendisers journaler i helsevesenet. Selv om selve databasesystemet er sikkert er det ikke sikkert at de personer som enten har godkjent aksess eller ved misbruk av andres aksess har samme oppfattning av sikkerhet. 36

37 Etter å ha lest bøkene og vurdert disse kom vi over en webside som listet opp de 10 viktigste security threats. Dette handlet om forskjellige systemtekniske tiltak. Men siden konkluderte med en setning som virker som en fin konklusjon på mye av det sikkerhet handler om: As it turns out, some of the biggest threats to your enterprise database are not zero-days, but the vulnerabilities you already know. (eweek.com). Fortolkningen av dette blir da at med sunn fornuft og skepsis til brukere samt tekniske løsninger vil en komme langt i arbeidet med å identifisere trusslene. Utfra å identifisere trusslene kan en i en organisasjon sette opp de nødvendige tiltakene. Avveininger må klart foretas i forhold til konsekvens, risiko og kostnad. Noe av dette er lovregulert, mens andre deler handler om bedriftens kritiske forretningsdata. Nivå 3: Alle forsøk på å få kontakt med bekjente innen denne delen av oppgaven strandet. Den må desverre utgå. 37

38 Monitorering: Definisjonen av monitorering vil være å overvåke databasesystemet med verktøy for å se hvordan helsesituasjonen til databasesystemet er. Det finnes mange verktøy for denne oppgaven. Både kommersielle og fritt tilgjengelige. For MySQL sin del er det tilgjengelig en mulighet for monitorering via MySQL Workbench. Dette er et grafisk verktøy som kan benyttes for alle forskjellige oppgavene tilhørende databaser fra modellering til drift. Som bildet under viser kan det også grafisk med informasjon gi en pekepinn på den aktuelle serverens status. Bilde 44 - Screenshot av monitor i MySQL Workbench Vi har her tilgang på parametere som cpu load, minnebruk, antall tilkoblinger, trafikk, query cache, og effektivitetsmåling. Hver connection til databasen vises med informasjon om hva de gjør. Det er gitt mulighet for å terminere hver enkelt forbindelse om det skulle være behov for dette. Selv om det finnes bedre løsninger en må betale for er det også alternative gratisverktøy tilgjengelig som gir en god oversikt over hva som skjer i databasen. Et av disse verktøyene er JetProfiler. Her har vi en grafisk fremstilling av flere 38

39 parametere som gir oss informasjon om hvordan det står til med databasen der og da. Bilde 45- Screenshot fra JetProfiler Med dette verktøyet går en mer ned på de viktige delene av en database kontra den innebyggede i MySQL som mer er sentrert mot hvordan tilstanden til hardware er der og da. En kan også gå inn på de forskjellige requests som har skjedd for å analysere disse nærmere. Programmet kommer opp med anbefalinger om den eksakte spørringen. Noen ganger kan det da hende det er en spørring en vil gjøre noe med, eller at en velger å overse dette. 39

40 Bilde 46- Screenshot fra JetProfiler 40

41 Replikering: Nivå 1: Replikasjon handler om å ha en eller flere kopier av en database som kan aksesseres. Vi kan gjerne kalle dette for et speilbilde av databasen. Det som skrives til en server kan da bli automatisk skrevet til de andre serverene. Grunnene for å benytte replikasjon er flere. Det kan være en webserver hvor lastbalansering er vesentlig, skulle en av serverene midlertidig bli overbelastet kan den andre ta over noe av de forespørselene som kom til hovedserver. Det kan også være slik at webserverene for tjenesten er plassert på forskjellige steder i verden for å redusere eventuelle trafikkbelastninger i utgangspunket. Serverene speiles hele tiden mot hverandre slik at innholdet er identisk. Brukeren skal ikke merke noe uansett hvilken server som benyttes. Det siste er for brukeren skjult siden fordelingen av hvor ting hentes fra skjer i bakgrunnen. Sikkerhet kan være en annen grunn til å ha replikerte databaser. Med sikkerhet menes både datasikkerhet og tilgjengelighet. For systemer hvor det er systemkritisk med aksess uansett tidspunkt kan dette være en viktig brikke for å øke sannsynligheten for å kunne bruke databasen. I sikkerhetsdelen kan grunnene ligge i at om en database utsettes for et angrep så er den speilede fremdeles online og kan servere brukerene de data de trenger. Replikasjon er dog ingen erstatning for en backup, men det nuller ut den tiden som det tar å få en backup tilbake på systemet og bli tilgjengelig for brukerene. Selv om da hovedserveren med databasen går ned er fremdeles en eller plere speilede versjoner av databasen oppe og fungerer. Selve mekanismene for replikering kan være både hardware styrte og software styrte. Hovedutfordringen med replikering handler om såkalt lag. Det vil si den tiden det tar fra data er skrevet til en database før det er presentert i alle databasene. For enkelte databaser kan det da være snakk om at data ikke er skrevet før alle de replikerte databasene har fått oppdatert seg, eller en kan ha et system hvor tidspunktet for dataskriving ikke er kritisk. Gode forskjeller på dette finner vi for eksempel innen bankvesen der alle data uansett hvilket speil en aksesserer skal ha 100% identiske data, her vil det da være mekanismer som sikrer dette. Facebook er på den annen side fremdeles kjørende 41

42 og fungerende selv om du ikke får de siste oppdateringene fra dine venner før etter for eksempel 5 minutter etter at de ble skrevet til en av de speilede databasene. Det kritiske her er at du får oppdateringene, men det er da ikke viktig eller kritisk når du får de.. Nivå 2: Denne testen vil være en enkel replikering mellom to MySQL databaseoppsett der den ene er master og den andre er slave. Alt vi replikere fra master vil kopieres til slaven. Fordi denne testen gjøres på samme server må det brukes to forskjellige versjoner av MySQL og den nyeste versjonen MÅ være master. I tilegg må portene være forskjellige så masteren har default 3306 mens slaven har port 3336 for at replikeringen skal fungere på samme server. Med forskjellige ipadresser kunne begge hatt samme versjon og samme port Oppsett master MySQL server versjon 5.5: På master må binærlogging samt en unik server id være aktivert. Dette oppsettet skrives inn i my.ini filen som er vår konfigurasjonsfil på windows serveren. Under [mysqld] seksjonen i my.ini sjekker vi at vi har skrevet inn: Bilde 47- Screenshot av oppsett my.ini for Master Oppsett slave MySQL server versjon 5.1: I my.ini skriver vi også inn server id under seksjonen [mysqld]: Bilde 48- Screenshot av oppsett my.ini for slave 42

43 Deretter restartes master og slave. Bilde 49- Screenshot av restart av tjenestene Neste steg er å opprette en bruker som styrer replikeringen. I dokumentasjonen til MySQL står det at man ikke er nødt å gjøre dette men at slaven vil opprette en en master.info fil der brukernavn og passord vil stå i klartekst. Derfor oppretter vi en bruker på masteren som kun har rettigheter til å replikkere. Bilde 50 - Screenshot av laging av nødvendige brukere for replikasjon Før vi kan starte replikkering må slaven vite fra hvor i binærloggen den skal starte å lese på master serveren. For å lage et nøyaktig punkt må de aktuelle tabellene som skal replikeres til slaven låses, på den måten vil ikke binærloggen forandres. I vårt tilfelle valgte vi å sette på en global tabell lås. Bilde 51 - Screenshot av setting av global tabell lås 43

44 Deretter sjekkes hvilken binærlogg som er i bruk: Bilde 52- Screenshot av hvilken binær logg brukes nå Vi lar tabellene være låst mens vi kjører en MySQLdump på de databasene vi vil overføre. I dette tilfelle er det basen vi har kalt das Bilde 53 - Screenshot av dumping av master databasen Vi logger inn i slaven: Bilde 54- Screenshot av innlogging slave Vi oppretter databasen das på slaven og importerer mysqldumpen vi tok på master 44

45 Bilde 55 - Screenshot av oppsett av databasen med import på slaven.deretter importerer vi das.sql til slaven. Merk at tabellene fortsatt er låst på master. Bilde 56- Screenshot av import av mysqldump på slaven For at slaven skal kunne kommunisere med master trenger den å vite hvor den skal koble seg opp, innloggingsinfo og detaljene om binærloggen som er frosset. Bilde 57- Screenshot av oppsett av kommunikasjon for slaven 45

46 Da skal et bare være å låse opp tabellene på master. Slaven er nå klar til å få oppdateringer fra master. Bilde 58- Screenshot av opplåsing av tabeller på Master Nå skulle i prinsippet alt være i orden trodde vi, men ingen replikering fant sted. Med kommandoen SHOW SLAVE STATUS \G fikk vi dette svaret: Bilde 59- Screenshot av show slave status Når vi så prøver å logge på master med brukeren vi lagde ser vi at den kommer opp som localhost og ikke med ip vi satte. Bilde 60- Screenshot av access denied for bruker slave Siden all replikering i denne testen skal skje lokalt på serveren velger vi å forandre på host til replikeringskontoen. UPDATE replik set host='localhost' where host=' %'; Vi kunne sikkert satt % istedet for localhost siden det kun skal fungere lokalt.. Deretter setter vi GRANT REPLICATION SLAVE ON *.* TO 'replik'@'localhost'; brukeren replik får nå logget inn på master og vi tar hele prosedyren om igjen fra toppen. Binærloggen har forandret seg siden sist: Bilde 61- Screenshot av forandret binærlogg 46

47 Så må vi legge inn oppdatert info om master. Denne gangen får vi en feilmelding siden SLAVE funksjonen er aktivert fra tidligere. Vi stopper SLAVE og legger inn masterinfo på nytt. Bilde 62- Screenshot av restart av slave Vi tester med kommandoen SHOW SLAVE STATUS \G igjen. Denne gangen får vi ingen feilmeldinger. Kontoen replik har koblet opp mot master og vi kjører UNLOCK TABLES; på master. Deretter prøver vi oss på en oppdatering. Denne gangen fungerer det. Vi legger til en Insert setning i tabellen deltaker i databasen das på master serveren: INSERT INTO Deltaker(Fornavn,Etternavn,Telefonnr,Epost,Merknader) values ('Per','Persen',' ','per.persen@persen.no','Testdummy'); Når vi deretter prøver select * from deltaker; på slaven får vi opp linjen vi la til. Siden vi på tidligere forsøk kjørte delete på radene for få tilbake den opprinnelige tabellen, så vi nå at de slettede Deltakerid ene ikke lenger var tilgjengelige og at siste oppdatering hadde lagt inn Deltakerid 8 etter rad nummer fire. Et bedre alternativ hadde vært å ha en backup vi kunne gjennoprettet enn å editere tabellen 47

48 slik vi gjorde. En nyttig erfaring å ta med seg. Bilde 63- Screenshot av select på slaven Nå fungerer replikeringen mellom de to mysqldatabasene. Vi sjekket også C:\Programdata\MySQL\MySQL Server 5.1\data og der fant vi som beskrevet i MyQL dokumentasjonen både login og passord på replikkeringskontoen vi bruker mot master. Bilde 64- Screenshot av oppsett replikasjonskonto 48

49 Nivå 3: Vi valgte under denne delen av oppgaven å løse det på to forskjellige måter. Variant 1 gikk på å i tillegg til den allerede beskrevete metoden for å replikere mellom to versjoner av MySQL å ta to forskjellige MsSQL systemer hvor en database skulle replikeres. Variant 2 ble å se om det gikk an å replikere mellom MsSQL og MySQL. Replikasjon mellom 2 SQL Servere Ved direkte replikkering mellom to SQL servere sjekker vi først om vi har satt opp unntak i brannmuren for dette. Vi legger til disse unntakene i på bege serverne så vi kan jobbe begge veier. Bilde 65 - SQL Server Management Studio lagt til i unntak i brannmur 49

50 Bilde 66 - Legger til port 1433 i untak på brannmur Vi innstallerte kun det vi måtte ha første gang på serveren og mangler feature for å kunne replikere. Gangen i intstallasjonen er svært lik første gang Bilde 67 - Starter installasjon for å kunne replikere Den skiller seg ut når vi kommer til dette bildet der vi velger add features 50

51 Bilde 68 - Legger til feature for replikering Bilde 69 - Velger SQL Serve Replication under Database Engine Services 51

52 Bilde 70 - Setter opp distribusjonsfolder på SQL server Bilde 71 - Konfigurasjons wizard for distribusjon 52

53 Bilde 72 - Det bestemmes hvilken server som er distributør Bilde 73 - Setter SQL Server Agent til å starte automatisk 53

54 Bilde 74 - Beholder default Replikeringsdata mappe Bilde 75- Beholder default mappe navn i dette forsøket 54

55 Det kommer en feil på slutten av wizarden og vi fant ut at det er en bug. For å unngå dette setter man SQL Server Agent til å starte Automatisk Bilde 76 - Konfigurering av autostart på SQL agent feilet Vi trenger å få SQL Agent Server i gang : Start > Administrative Tools > Services 55

56 Bilde 77 - Setter SQL Server Agent til å starte automatisk i services. Deretter starter vi servicen. Bilde 79 - SQL Server Agent er startet på serven som er publisher Vi kjører gjennom samme oppsettet på SQLserver2 som skal være subscriber altså ta imot basen som skal replikeres. På begge sql serverne setter vi opp admin på den andre serveren som sysadmin. 56

57 Bilde 80 - Begge admin er satt opp som sysadmin på den andres server. Deretter lager vi et snapshot av det vi ønsker å replikkere fra serveren som er publisher.høyreklikker Local Åublications og lager en Snapshot publication. Bilde 81 - Snapshot publication på publisher server 57

58 Man kan sortere ut hvilke kollonner man ønsker fra hvilke tabeller og skreddersy snapshot. Vi velger å ta heledatabasen som den er. Bilde 82 - Det er mulig å velge hva som skal være med i snapshot Vi velger å kjøre publish immediatly og kaller publicasjonen for ciaworld. 58

59 Bilde 83 - Snapshot ferdigstilles for distribusjon. Neste steg er å legge til den serverer som skal ha publikasjonen altså databasen som replikeres. Vi må legge til en subscription. 59

60 Bilde 84- Vi oppretter en subscription for SQL server 2 som er mottaker. Bilde 85 - publikasjonen ciaworld velges for replikering i subscription. 60

61 Bilde 86 - Publikasjonen settes opp som push distribusjon i SQL agenten Bilde 87 - Legger til server som skal abbonere på publikasjonen. 61

62 Bilde 88 - SQLserver 2 velges for abbonemement og kobler opp. Bilde 89 - Her skulle det velges database for subscription (abbonement) 62

63 Her strandet det siden ciaworld publikasjonen ikke kom opp som et valg for replikasjon. Hvor det gikk galt er vi ikke sikre på men gangen i det vi har gjort skal være i nærheten av det som er tanken. Vi kom på at vi hadde glemt å sette share på replikasjonsfolderen : Bilde 90 - Det settes share / deling på replikasjonsfolderen for SQL server2 Likevel lyktes det ikke å sette opp subscriptrion. Vi har to baser der admin på begge er er koblet mot den andre serveren som sysadmins. Det er laget en ferdig publikasjon for distribusjon men vi er ikke i stand til å sette opp et abbonement på mottaker i det vi ikke finner publikasjonen som skal mottas. På dette tidspunktet er det desverre ikke igjen tid for flere forsøk. Vi må la dette strande på grunn av tidsnød. 63

64 Replikasjon mellom MsSQL og MySQL Direkte replikasjon mellom MySQL og MsSQL er ikke en lett oppgave. Det finnes verktøy som kan løse denne jobben på en enkel måte et av disse verktøyene heter Daffodil. Denne ble prøvd installert på serveren. Siden dette programmet krevde Java ble det også innstallert. Daffodil Bilde 91- Installasjon av Daffodil 64

65 Bilde 92 - Installasjon av Daffodil Underveis i installasjonen fikk vi ingen spesielle meldinger. De forskjellige informasjonsfeltene ble fyllt ut slik vi ble bedt om. Bilde 93 - Feilmelding ved forsøk på å kjøre Daffodil 65

66 Selv om alt var satt slik det skulle fikk vi feilmeldinger. Konfigurasjonsfilene ble forsøkt redigert slik manualene ville at de skulle være. Men det gikk ikke å komme seg videre med dette programmet.dette verktøyet ble derfor skrinlagt. DbConvert Dernest kom vi over et verktøy som kom fra DbConvert. Her finnes både konverteringsverktøy og synkroniseringsverktøy. Vi installerte dette på serveren og testet ut om det fungerte. Bilde 94 - Installasjonsmelding 1 DbSync Programmet ble installert med alle mulige opsjoner vi kunne finne. Av erfaring kan det noen ganger være viktig å krysse av på alle valgmuligheter. 66

67 Bilde 95 - Installasjon av DbSync opsjoner Bilde 96 - Installasjon av Dbsync uten feilmelding 67

68 Ingen feilmeldinger kom under eller etter installasjonen. Bilde 97 - Velkomstmenyen i DbSync Velkomstmenyen i DbSync viser blant annet det faktum at vi har en demoversjon som er begrenset i bruk. For dette prosjektet vil det ikke ha betydning siden vi kun er ute etter å se at det virker, ikke at alle dataelementer er 100% korrekte i den replikerte databasen. 68

69 Bilde 98- Kobling mot MsSQL oppsett Programmet kom med grunnleggende oppsett for en MsSQL database med korrekte porter. Vi huket av for windows Authentication. Koblingen mot egen MsSQL server ble direkte godkjent. Vi valgte så den databasen vi ønsket å replikere fra. 69

70 Bilde 99 - Oppsett kobling mot MySQL Vi valgte så de parameterene som stemte overens med vår MySQL database. For sikkerhets skyld hadde vi som bildet undewr viser allerede laget en database med rett navn. Den var som bildet under i tillegg tom før vi gikk videre. Bilde 100- Opprettelse av den tomme databasen cia i MySQL 70

71 DbSync hentet opp masterdatabasen og analyserte denne. Som bildet under viser var det ikke noen delelementer av denne som ikke passet inn i DbSync sin metode å jobbe på. Bilde Konfigurasjonsmenyen for master databasen. Det neste valget var da å få en fullverdig synkronisering og derav en replikasjon av databasen cia fra MsSQL til MySQL. 71

72 Bilde Replikasjon/synkronisering av databasen Vi fikk under denne synkroniseringen heller ingen feilmelding. 72

73 Bilde Underveis i synkronisering. Når da synkroniseringen var ferdig kom det spennende øyeblikket. Var databasen cia i MySQL oppdatert. Og som bildet under viser var det denne gangen etter synkronisering tabeller tilstede i databasen. Bilde Fullført og fungerende synkronisering. Resultatet av dette programmet var en asynkron kopi. Databasen er replikert, men den er ikke real time replikert. Programmet kan kun hente sende databasen cia fra MsSQL til MySQL på fastlagte tidspunkt. Derimot viser dette programmet at det er 73