SWD sikkerheds noter

Logical Security - Beskyttelse imod computer baseret trusler, som f.eks Malware og hack


Physical Security - Beskyttelse imod fysiske trusler som f.eks miljø, teknisk og menneske skabte problemer.


Premises Secutiry - Beskyttelse imod trusler på områder, bygninger og personale etc. som er lovpligtigt.
Under dette ligger:
ting som brand sikring (alarmer),
adgangs kontrol (adgangs kort),
område sikkerhed (video overvågning etc.).


____________________________________________________________________

Psysical Security

Natur Katastrofer - Dette dækker et stort område af miljø trusler imod data-centre og personale.

f.eks Tornadoer - som ka skade centrene med hård vind og brudstykker af andre bygninger.

Jordskælv - har potentialet for den største skade, hvis it center er tæt på Epicenter ka det betyde total ødelæggelse.

Miljø trusler -

høj temperatur - De fleste computer systemer virker bedst ved rum temperature omkring 10-32 grader, hvis computere bliver for varme vil de have svært ved at fungere til deres fuldest.

Lav temperatur - Hvis de bliver for kolde ka det skabe et kulde shock som ka få

Fugtig miljø - kredsløb/printplader til at flække. længere varig fugt ka også skabe rust i computere. og kondens vand kan være en trussel imod magnetiske og optiske lagrings moduler, som ka få det til at kortslutte. luft fugtigheden skal være imellem 40 og 60% for at give det bedste resultat/performance.

Ild / Røg -

Er farligt for computere, ikke kun direkte, men også røg og varme ka være trusler her. røg(aske) vil samle sig inde i computeren og lave skade.

Vand skade -

*Primær fare: Elektronic kort slutter*

sprinklere, burst pipes, oversvømmede toiletter, oversvømmelse.

Oversvømmelser er specielt svær at gøre rent efter.

Kemisk, radioaktivitet og biologiske farer -

er både med vilje og uheld er trusler.

Som vil kunne komme ind være ventilation, og åbne vinduer.

Radioaktivitet vil kunne komme igennem vægge også.

oversvømmelse kan skabe biologiske eller/og kemiske farer.

Støv -

udstyr med bevægelige dele som f.eks roterende lagrings moduler, og computer kølere er ret udsat for skade fra støv.

infestation -

- Mug

- meldug

- insekter

- gnavere

Menneske skabte fysiske trusler -

uforudsigelig og svært at stoppe

- tyverig

- fejlbrug

- uautoriseret fysisk adgang

- vandalisme

First Normal Form

http://en.wikipedia.org/wiki/First_normal_form

First normal form (1NF or Minimal Form) is a normal form used in database normalization. A relational database table that adheres to 1NF is one that meets a certain minimum set of criteria. These criteria are basically concerned with ensuring that the table is a faithful representation of a relation^[1] and that it is free of repeating groups.^[2]

The concept of a "repeating group" is, however, understood in different ways by different theorists. As a consequence, there is no universal agreement as to which features would disqualify a table from being in 1NF. Most notably, 1NF as defined by some authors (for example, Ramez Elmasri and Shamkant B. Navathe,^[3] following the precedent established by Edgar F. Codd) excludes relation-valued attributes (tables within tables); whereas 1NF as defined by other authors (for example, Chris Date) permits them.

-----------------------------------------------------

http://en.wikipedia.org/wiki/Database_normalization

In the field of relational database design, normalization is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics—insertion, update, and deletion anomalies—that could lead to a loss of data integrity

ACID2

Et databasesystem skal stille følgende faciliteter til rådighed:

• Atomare transaktioner, hvilket betyder, at en ændring enten skal gennemføres helt eller også skal der ryddes så godt op, at det ser ud som om ændringen ikke er forsøgt gennemført.
• Konsistens De atomare transaktioner skal føre databasen fra en sammenhængende tilstand til en anden. Dette kræver, at de enkelte transaktioner er designet korrekt og hænger ikke kun på databasesystemet.
• Isolation To eller flere programmer, der bruger samme database, må ikke kunne se hinandens ændringer, før de er helt gennemførte. Der anvendes dog forskellige grader af isolation.
• Varighed Det skal sikres, at data ikke bare forsvinder. Det stiller krav til den anvendte hardware og krav om at skrivninger til disk laves, så data ikke kun lander i en cache undervejs.

På engelsk kaldes disse krav om bestemte egenskaber for ACID-properties efter forbogstaverne i de engelske betegnelser atomicy, consistency, isolation og durability.

[redigér]Atomare transaktioner

Hvis en transaktion kun omfatter læsning, vil den altid kunne startes forfra. Resten af afsnittet handler om transaktioner, der omfatter skrivning til databasen. Der findes flere måder at implementere atomare transaktioner på, men det almindeligste er at bruge en "skriv-foran-log" (write ahead log). Denne log vil i det følgende blive omtalt som en transaktionslog. Først skrives en beskrivelse af ændringen i transaktionsloggen og derefter gennemføres ændringen i selve databasen. Når en transaktion er gennemført, markeres den som gennemført i loggen.

Fejl håndteres forskelligt alt efter om det er fejl, der opdages af databasesystemet eller det er fejl, der opdages af det opdaterende program. Hvis fejl opdages af programmet, markeres transaktionen som fejlbehæftet, og alle opdateringer føres tilbage til udgangspunktet ved hjælp af oplysningerne i transaktionsloggen. Selvom databaseprogrammet finder en fejl, skal transaktionen så vidt muligt gennemføres. Hvis det er lykkedes at skrive transaktionen i loggen, gennemføres den fra oplysningerne her, ellers ikke. I visse tilfælde kan hensynet til korrekt isolation gøre, at en transaktion ikke kan gennemføres. I disse tilfælde bliver ændringerne ført tilbage, og det opdaterende program må forsøge at gennemføre transaktionen på ny.

[redigér]Isolation

Der opstår forskellige problemer, hvis forskellige programmer, der bruger den samme database, kan se hinandens ændringer inden de er helt gennemførte. Løsningen er, at isolere de enkelte databasetransaktioner fra hinanden. En høj grad af isolation sikrer, data hænger rigtigt sammen, men begrænser også parallelle opdateringer, hvilket kan give lange afviklingstider for de opdaterende programmer.

De mest gængse niveauer af isolation er fra det laveste til det højeste:

• Læs ikke gennemførte (read uncommitted): Ingen isolation. Et program kan læse data, som måske bliver tilbageført eller overskrevet senere.
• Læs gennemførte (read committed): Et program kan kun læse data, der er skrevet endeligt til databasen. Det er muligt, at de læste data ændres fra anden side inden transaktionen er slut.
• Gentagelige læsninger: Et program kan læse de samme data flere gange og få det samme resultat inden for den aktuelle transaktion.
• Serialisering: Ud over gentagelige læsninger er mulige, sikres det, at en transaktion ikke har kunnet læst data, der er slettet eller ændret inden transaktionen er gennemført. Data, der er tilføjet fra en anden transaktion kan heller ikke ses.

I mange tilfælde er niveauet "læs gennemførte" tilstrækkeligt.

[redigér]Varighed

For at sikre, at data opbevares i databasen så længe, det er nødvendigt, er sikkerhedskopiering en nødvendighed. Det er i den sammenhæng vigtigt, at data hænger rigtigt sammen (er konsistente) inden backup foretages. Løsningen er, at etablere et kontrolpunkt (checkpoint).

Etablering af et kontrolpunkt kan ske på denne måde:

1. Der lukkes af for nye transaktioner
2. Transaktioner, der er i gang gennemføres
3. Det sikres, at alle data er skrevet til disk
4. Det markeres i databasens log, at der er lavet et kontrolpunkt
5. Der laves backup og eventuelt anden vedligeholdelse
6. Transaktionsloggen tømmes
7. Der åbnes for transaktioner igen

Nogle databasesystemer kan sætte transaktioner i kø under oprettelse af et kontrolpunkt.

ACID

ACID er en måde at sikre at database transaktioner forløber ordentligt.

- Atomicity - Enden skal alle dele af en transaktion udføres, eller ingen bliver udført. Hvis et system f.eks. går ned halvvejs gennem en transaktion, skal der enden roles back til før transaktionen blev startet eller også skal resten af transaktionen udføres.

- Consistency - Consistency sikrer at databasen er i en valid stadie hele tiden, f.eks. at integrity constrains bliver overholdt. Har vi foreksempel en attribut som kun kan indeholde positive integers, og der i en transaktion forsøges at sætte den til en negativ integer skal der "roles back" til det tidligere stadie, hvor integriteten var valid.

- Isolation - Isolation sikrer at to transaktioner, som bliver udført samtidig ikke har indflydelse på hinanden. Det gøres ved at udføre den ene transaktion før den anden, eller færdig gøre en del af transaktionen som som har med en bestemt tabel at gøre, før den næste transaktion får lov at komme til denne tabel.

- Durability - Sikrer at database udføre resten af en transaktion hvis der skulle ske server nedbrud, dette sikres ved at have logs over de udførte handlinger.

http://databases.about.com/od/specificproducts/a/acid.htm

http://en.wikipedia.org/wiki/ACID

Databasenoter

Relationer = en tabel

Tuple = en række i en tabel

Række = tuple (En relation består af tupler == en table består af rækker)

Kardinalitet i en tabel = antal rækker i en tabel

Null værdi = ingen værdi

Attributter = Overskrift på kolonnen

Domain = attributtens type (varChar, int, osv.)

Primære nøgle = Formål er at udpege en bestemt række (unik) – alle tabeller skal have en primære nøgle der ikke må være null

Kandidat nøgle = De nøgler der kan være primære nøgle

Fremmed nøgle = Er en attribut der ikke er primære nøgle i en tabel, men primære nøgle i en anden tabel

Referentiel integritet:

Hvis man har en fremmed-nøgle (FK) der refererer til en primær-nøgle (PK) skal alle FK-værdier findes som PK-værdier (e.g. FK'ere skal refere til eksisterende PK'ere).

Hvis man sletter rækker med PK'ere kan der derfor opstå problemer. Disse problemer kan håndteres på en af følgende måder:

1. RESTRICT: Checker om det vil give et problem at slette, og hvis det gør, så bliver det ikke gjort (e.g. man får en "exception"). Man kan så løse de problemer der måtte være, og så dernæst slette.

2. CASCADE: Sletter rækker med tilhørende FK (cascade-effekten gentages om nødvendigt også for disse, osv.). En automatisk proces, men til gengæld har vi ikke rigtig styr på hvad der sker.

3. SET TO NULL: Man sætter FK til null, for at indikere manglende reference.

Normalformer:

Man normaliserer fordi:

- Det fjerne redundans (e.g. at det samme står flere steder)

- Anomalier:

- Update: ændrer et sted mere ikke alle steder

- Insert: indsætter allerede eksisterende data, men "staver" forkert

- Det minimere brug af null-værdier

- tvetydig semantik (e.g. uklar betydning)

("hvad betyder semantik, og hvordan staver man til syntaks?")

- Man vil undgå tab af information

- at man sletter en ting, kan bevirke at andre informationer kan gå tabt

(at slette en studerende kan f.eks. slette oplysninger om et fag)

1NF:

- Alle attributter må kun have én værdi ("ingen repeterende felter")

= Man laver _ikke_ flere tabeller (det gør man ellers ifm. 2NF og 3NF)

= Man laver flere rækker (én for hver af værdierne i attributterne med flere værdier)

+ Det skaber mere redundans!

2NF:

- 1NF + Alle attributter skal være fuldt funktionel afhængig (FD) af PK. Dvs. at ved en sammensat PK er en attribut ikke kun afhængige af dele af PK.

= Man finder først en PK for hver tabel, ved at se på FD imllem attributterne.

= _Fuldt_ afhængig er kun et problem hvis man har en _sammensat_ PK

= Man deler tabeller i to

= e.g. laver en ny tabel med de attributter, der ikke er _fuldt_ FD af PK, med

de dele af PK, som de er (fuldt) FD af (som bliver PK i den nye tabel).

= den oprindelige tabel mister disse attributter, dog beholder den PK fra den nye tabel som FK.

+ Fjerner normalt redundans i den oprindelige tabel (e.g. den får færre rækker)

3NF:

- 2NF + Ingen transitive afhængigheder (e.g. ingen FD mellem ikke-PK-nøgle-attributter)

= Man deler tabeller i to

= e.g. laver en ny tabel med de attributter, der er FD af ikke-PK-nøgle-attribut,

med den attribut som de er FD af (som bliver PK i den nye tabel).

= den oprindelige tabel mister disse attributter, dog beholder den PK fra den nye tabel som FK.

+ Fjerner normalt redundans i den oprindelige tabel (e.g. den får færre rækker)

= Postnummer-eksempel er et velkendt eksempel på 3NF

SWK - 22 feb - Monday

http://www.docjava.dk/default_1024_0768.htm

http://en.wikipedia.org/wiki/Singleton_pattern
In software engineering, the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.

3 Lags Deling

En Lagdeling i 3 lag, brugt i programmering hvor pilene representere hvad der snakker med hvad. præsentations laget, snakker med logik-laget, som snakker med data-laget.

Præsentations laget: Er det lag der representere vores User Interface, altså det brugeren ka se på skærmen.

(Business) Logik-laget: Er det lag der sørger for at præsentations laget, forstår og ka snakke med Data-laget.

Data-lager: Er det lag der sørger for alt data, lagring af data, samt tilgang til data.