Portefølje for 4. semester

CIA-Triangle

November 10, 2025, Mål: Afdækkke risici ift. vores database

I denne uge har jeg, i forbindelse med at vores system er udrullet og klar til brug, valgt at kigge på IT-sikkerhed, ift. vores forskellige teknologier. Til det findes en model, der skal hjælpe til at afdække forskellige sikkerhedrisici. CIA-Trianglen, består af de tre søjler: Confidentiality, der skal sikre at kun autoriserede personer har adgang, Integrity, der ser på at dataen ikke er ændret, og Availability, som skal sørge for at ens service altid er tilgængelig. Til at starte med har jeg brugt modellen til at se på vores database-sikkerhed. Den første sølje confidentiality: Her har jeg sat vores database til "Force Encryption = true", samt genereret certificater, vha. Vault, for på den måde at undgå, at uvedkommende kan se den trafik der bliver sendt frem og tilbage. Derudover er kryptering af vores databaser slået til, så selvom en person udefra eller internt, får adgang til serveren og stjæler .mdf/.ldf filerne, kan de ikke bruge dem uden krypteringsnøglen, der er gemt i Vault. Vault er også brugt til at styre adgangen til databasen, fordi alle andre logins - udover Vaults eget login, er disabled. Vaults eget login bruges til at oprette logins til services og personer, for på den måde at kunne se, hvem der har brugt hvilket login (admin, udvikler, readwrite), hvornår og kontrollere, hvor lang tid disse logins er gyldige. Efter at skrevet lidt med AI, kan jeg se at Integrity ikke er særlig godt afdækket. Vi har aktiveret audits, for at kunne gå tilbage og se, hvem der har lavet hvilke ændringer. Men vi har hverken sat contraints op, der skal sikre at kun validt data kan indsættes i en tabel, eller lavet stored procedures med transactions, der kan sikre at en operation kun udføres, hvis alle deloperationer kan gennemføres. Transactions kan implementeres med EF Core, men havde været væstenstligt nemmere, hvis denne del havde været tænkt ind fra starten af. I forhold til availability er vi meget godt med. Databasen er deployed på en selvstændig Kubernetes node, så risikoen ved at en anden pod crasher og tager databasen med er minimal, og hvis noden skulle være utilgængelig, er konfigurationen af databasen versioneret, og klar til at blive udrullet på en anden node. Der er også lavet en plan for backups, så dataen ikke går tabt, hvis nodens disk skulle dø. Hvis databasen er utilgængelige, bliver det også hurtigt opdaget via vores systemovervågning, der indsamler logs, metrics og traces, og præsenterer det et samlet sted i Grafana.