Gå til indholdet

04 - Integrity and Availability Policies

Noter til dagens tekst

Resumé af 'Integrity Policies' (Bishop kap. 6)

Integritets politikker skal addressere problematikker med at sikre dataintegritet i "vildt varierede"1 miljøer. De er vigtige, da det i mange typer af organisationer er mere kritisk om data er til at stole på end om de eks. bliver holdt fortrolige.

Intgritet kan forsøges bevaret ved at overholde nogle principper for drift2

  • Adskildelse af ansvar: Flere øjne på, hvis det er muligt.
  • Adskildelse af funktion: Udviklere, udvikler ikke i produktion og kan ikke selv deploye til produktion.
  • Auditering (revision): Analyse af systemer med det formål at undersøge hvad der sker hvornår samt hvem der har gjort hvad.

Modeller: Biba, Lipner (læs bog, ikke internet; der er forskel) og Clark-Wilson. Se også Matt Bishops egne undervisningsslides.

Trust model: Hvor integritets modeller behandler problematikken om at bevare et systems integritet, handler "trust" om tilliden til systemets initielle. Minder meget om formel epistemologi.
Tillid til entiteter både direkte og indirekte (transitiv / konditionel transitiv).

Resumé af 'Availability Policies' (Bishop kap. 7)

Skal forhindre forskellige typer af Denial of Service. Eks. deadlock3 eller (D)DoS angreb4.

Modellerne for beskrivelse af Availability Policies, Eks. Yu-Gligor (pp. 204 ->) og Millen (pp. 210 ->), har typisk to overornede politikker:

  • User agrement: Begrænsning på brug af ressourcer (eks. ingen flooding).
  • Waiting Time: Hvor lang tid man skal vente før der er tale om Denial of Service.

SYN-flood er eksempel på DoS angreb og Cisco har implemeteret mitigering i noget af deres udstyr, som afventer fuldt TCP handshake før forbindelse overgives til udførende system for at undgå at ressourcer på sytemet bliver bundet op på ventende forbindelser.

Yderligere læsning: TCP Synfloods an old yet current problem

Noter fra undervisningen (slides)

  • Jo mere der kan automatiseres af de her processer, desto bedre. I så fald bliver fejlene nemlig systematiske og kan programatikse rettelser kan føre systemet tilbage til et sikkert stade.

Relational Database Management Systems (RDBMS)

RDBMS structure

Til forklaring af deadlocks brug Dining Philosophers Problem. Forklar evt. også om deadlock detection (se også Thrashing for sammenlignelig problemstilling på OS-niveau).


  1. Ref. "environments vary wildly", "Summary" pp. 196. 

  2. Ref. "principles of operation", "Goals" pp. 173. 

  3. En proces hindres adgang til ressource. 

  4. Eks. SYN-flood (syn -> syn/ack -> ack).