Integritet

ISO/IEC 27000 definerer integritet kort som egenskaben nøjagtighed og fuldstændighed, mens den amerikanske FISMA-definition, som FIPS 199 bygger på, taler om beskyttelse mod uretmæssig ændring eller sletning og udtrykkeligt medregner ægthed og uafviselighed. I praksis dækker begrebet to forskellige problemer: at opdage uautoriserede eller utilsigtede ændringer af data, og at sikre, at autoriserede ændringer i sig selv er korrekte, hvilket handler om forretningsregler, validering og processer snarere end kryptografi.

Den kryptografiske værktøjskasse udgør en stige. En checksum eller CRC opdager tilfældig korruption, men beskytter ikke mod en bevidst angriber, som blot kan beregne den igen. En kryptografisk hash som SHA-256 er kollisionsresistent, men en hash alene hjælper kun, hvis referenceværdien selv leveres via en betroet kanal. En message authentication code som HMAC (RFC 2104) binder integriteten til en delt hemmelig nøgle, så enhver med nøglen både kan verificere og forfalske; den giver derfor integritet og autentificering af afsender mellem to parter, men ikke uafviselighed. En digital signatur bruger et asymmetrisk nøglepar, så kun indehaveren af den private nøgle kan signere, mens alle kan verificere, og det er det, der gør uafviselighed mulig. Moderne protokoller bruger authenticated encryption (AEAD), fx AES-GCM eller ChaCha20-Poly1305 i TLS 1.3, så fortrolighed og integritet leveres samlet, og manipuleret ciffertekst afvises, før dekrypteret output tages i brug.

På modelniveau er Biba-modellen (1977) integritetens modstykke til Bell-LaPadula og forbyder subjekter at læse ned i mindre troværdige data eller skrive op i mere troværdige data, mens Clark-Wilson-modellen (1987) beskriver kommerciel integritet gennem velformede transaktioner, begrænsede dataelementer og funktionsadskillelse. Databaser håndhæver integritet med constraints, transaktioner og ACID-egenskaber; lagring bruger filsystemer med checksummer og Merkle-træer; backup bruger immutable eller WORM-lagring, så ransomware ikke kan overskrive den; og softwareforsyningskæden bygger på kodesignering, reproducerbare builds og provenance-rammer som SLSA.

Typiske fejl er at verificere en hash hentet fra den samme kompromitterede server som filen, at signere data uden nogensinde at tjekke signaturen, og logs, som en administrator kan redigere, hvilket undergraver både den forensiske værdi og ansvarligheden. Business email compromise viser, at integritetsangreb ofte rammer processen og ikke bittene: en korrekt overført faktura med et ændret kontonummer består alle tekniske tjek. Databeskyttelsesforordningens art. 5, stk. 1, litra f, og art. 32, stk. 1, litra b, nævner integritet direkte, og en uautoriseret ændring af personoplysninger er et brud på persondatasikkerheden efter art. 4, nr. 12.