무결성

무결성은 데이터를 믿고 써도 되는지 따질 때 쓰는 말입니다. 보안에서는 데이터가 허가 없이 바뀌지 않았는지를 묻습니다. 데이터베이스에서는 데이터가 미리 정해 둔 규칙을 지키는지를 묻습니다. 두 물음은 따로 깨지므로 어느 뜻인지 먼저 정해야 말이 통합니다.

쉽고 빠른 이해

무결성은 데이터를 믿어도 되는지 따지는 말입니다. 보안에서는 내려받은 설치 파일이 올린 그 파일과 똑같은지를 묻습니다. 데이터베이스에서는 나이 칸에 음수처럼 규칙을 어긴 값이 없는지를 묻습니다. 두 물음은 따로 깨지므로 「무결성이 깨졌다」는 말을 들으면 어느 뜻인지부터 물어야 합니다.

따지지 않으면 망가지거나 바꿔치기된 데이터를 믿고 씁니다. 규칙을 어긴 값도 쌓입니다.

어떻게 도나:

1. 보안에서는 보내는 쪽이 데이터로 짧은 검증값을 계산해 함께 보냅니다
2. 받는 쪽이 같은 계산을 다시 해서 두 값을 견줍니다
3. 데이터베이스에서는 규칙을 미리 선언해 둡니다. 규칙을 어기는 쓰기는 거부됩니다

대가는 보안의 검증값이 바뀐 것을 알아챌 뿐 원래대로 되돌려 주지는 않는다는 것입니다.

상세

무결성이라는 낱말은 맥락마다 뜻이 갈립니다. 이 절은 실무에서 제일 자주 부딪히는 두 맥락을 봅니다. 하나는 정보보안이고 다른 하나는 데이터베이스입니다. 셋째 맥락인 시스템은 다음 절 「맥락별 뜻」이 받습니다.

두 맥락 모두 「이 데이터를 믿어도 되나」를 묻습니다. 갈리는 것은 깨졌는지를 판정하는 시험입니다.

보안에서 무결성은 데이터가 허가 없이 또는 사고로 바뀌거나 망가지거나 없어지지 않았다는 성질입니다. 시험은 「값이 처음 그대로인가」입니다. 내려받은 설치 파일이 배포한 곳에서 올린 파일과 한 비트도 다르지 않은지 따지는 것이 그런 예입니다.

데이터베이스에서 무결성은 데이터가 업무 규칙을 지키는 성질입니다. 시험은 「값이 규칙에 맞는가」입니다. 상품 가격은 양수여야 한다는 규칙이 여기에 드는 규칙입니다.

두 시험은 서로 독립입니다. 아래 두 값은 한 뜻으로는 멀쩡하고 다른 뜻으로는 깨졌습니다.

「무결성이 깨졌다」는 말만으로는 무엇이 잘못됐는지 알 수 없습니다. 어느 맥락의 시험인지를 먼저 대야 합니다.

두 맥락은 무결성을 지키는 방법도 다르고 시험이 걸리는 때도 다릅니다. 데이터베이스 뜻의 시험은 값이 들어올 때 걸립니다. 보안 뜻의 시험은 저장되거나 전송된 값을 나중에 쓸 때 걸립니다.

flowchart TD
    subgraph IN["들어올 때 — 데이터베이스 뜻의 시험"]
        A["값을 저장하려 한다"] --> B["제약 조건을 어기나"]
        B --> C["어긴다. 오류를 내고 쓰기를 거부한다"]
        B --> D["안 어긴다. 저장된다"]
    end
    D --> E["저장되거나 전송되는 동안 사고나 공격으로 바뀔 수 있다"]
    subgraph OUT["나중에 쓸 때 — 보안 뜻의 시험"]
        F["검증값을 다시 계산해 견준다"] --> G["어긋나면 바뀐 것으로 알린다"]
    end
    E --> F

보안에서 변경을 알아채는 검증값

데이터에 딸려 가는 검증값은 변경을 막지 못합니다. 변경이 일어나면 알아채게 할 뿐입니다. 이 소절은 그 검증값이 어떤 변경까지 알아채는지를 봅니다.

보안 쪽 무결성 도구가 전부 알아채기만 하는 것은 아닙니다. 부적절한 수정을 미리 막는 접근 규칙도 있고, 그쪽은 「배경」이 받습니다.

데이터가 바뀌는 원인은 둘입니다. 하나는 사고입니다. 네트워크를 지나는 동안, 디스크에 오래 저장된 동안, 캐시를 거치는 동안 비트가 뒤집힐 수 있습니다. 저장해 둔 데이터가 저절로 망가지는 이 현상을 비트 부패라고 부릅니다.

다른 하나는 고의입니다. 주고받는 두 쪽 사이에 끼어든 공격자가 데이터를 고쳐서 넘깁니다. 이런 공격을 중간자 공격이라고 부릅니다. 엿보는 데 그치지 않고 데이터를 고쳐 넣는 공격을 통틀어 능동 공격이라고 합니다.

검증값은 어느 원인의 변경도 막지 못합니다. 막으려면 시스템에 오류가 전혀 없고 악의를 품은 사용자가 손댈 수도 없어야 합니다. 그래서 검증값은 변경을 알아채고 알리는 일을 맡습니다.

알아채는 방법은 이렇습니다. 데이터 내용으로 짧은 값을 계산해 데이터와 함께 저장하거나 보냅니다. 나중에 데이터를 쓰는 쪽은 손에 든 데이터로 그 값을 따로 다시 계산합니다. 다시 만든 값이 딸려 온 값과 어긋나면 데이터가 도중에 바뀐 것입니다.

sequenceDiagram
    participant S as 보내는 쪽
    participant R as 받는 쪽
    S->>S: 데이터로 검증값을 계산한다
    S->>R: 데이터와 검증값을 함께 보낸다
    R->>R: 받은 데이터로 검증값을 다시 계산한다
    Note over R: 두 값이 다르면 바뀐 것으로 알린다
    R->>R: 두 값이 같으면 받아들인다

요점은 받는 쪽이 값을 다시 계산한다는 것입니다. 딸려 온 검증값을 믿는 것이 아니라 손에 든 데이터로 직접 만들어 견줍니다.

어떤 변경을 알아채는지는 계산 방법이 정합니다. 데이터 전체에 비트 하나를 붙이는 패리티 검사가 그 예입니다. 홀수 개 비트가 바뀌면 알아챕니다. 짝수 개 비트가 바뀌면 못 알아챕니다.

검증값은 무엇을 넣어 계산하느냐에 따라 알아채는 변경이 달라집니다. 실무에서 쓰는 것은 크게 셋입니다.

체크섬은 데이터만 넣어 계산합니다. 컴퓨터와 네트워크는 사고로 생긴 변경을 알아채려고 체크섬을 씁니다. 하지만 데이터를 고친 공격자는 딸려 가는 체크섬도 다시 계산해 바꿔 붙일 수 있습니다. 데이터만 넣어 계산한 체크섬은 능동 공격에 맞서는 대책이 못 됩니다.

sequenceDiagram
    participant S as 보내는 쪽
    participant A as 공격자
    participant R as 받는 쪽
    S->>A: 데이터와 체크섬을 보낸다
    A->>A: 데이터를 고치고 체크섬을 다시 계산한다
    A->>R: 고친 데이터와 새 체크섬을 넘긴다
    R->>R: 받은 데이터로 체크섬을 다시 계산한다
    Note over R: 두 값이 같아 그대로 받아들인다
    Note over A: 메시지 인증 코드라면 비밀 키가 없어 새 값을 못 만든다

능동 공격까지 견디는 검증값은 둘을 함께 갖춥니다. 하나는 검증값을 만드는 계산에 공격자가 모르는 키가 들어가는 것입니다. 다른 하나는 그 계산에 쓰는 함수를 잘 고르는 것입니다.

둘 가운데 하나만 갖추면 모자랍니다. 키가 들어가지 않으면 공격자도 같은 함수로 새 값을 다시 계산해 붙입니다. 거꾸로 키가 들어가도 함수가 허술하면 막히지 않습니다. 고친 데이터가 원래 데이터와 같은 값이 나오도록 맞출 수 있으면 딸려 온 검증값이 들어맞기 때문입니다.

해시 함수는 길이가 제각각인 데이터를 짧은 값으로 줄이는 함수입니다. 같은 입력에는 늘 같은 값을 냅니다.

그 가운데 고친 데이터로 원래와 같은 값이 나오도록 맞추기 어렵게 만든 것을 암호학적 해시 함수라고 부릅니다. 데이터가 바뀌면 그 값이 더는 들어맞지 않습니다. 함수를 잘 고른다는 것은 이 함수를 쓴다는 말입니다.

메시지 인증 코드는 계산에 비밀 키를 섞습니다. 키를 모르는 공격자는 데이터를 고친 뒤 거기 맞는 새 값을 올바르게 계산하지 못합니다. 그러므로 능동 공격의 위협이 있어도 검증값 노릇을 합니다. 해시 함수에 키를 섞어 만드는 HMAC(Hash-based Message Authentication Code)이 이 갈래에 듭니다.

이름에 인증이 들어 있지만 메시지 인증 코드가 주로 하는 일은 무결성 확인입니다. 이름만 보고 누가 보냈는지를 확인하는 도구로 읽으면 어긋납니다. 같은 비밀 키를 양쪽이 모두 가지므로 둘 중 누가 만든 값인지는 가리지 못합니다.

개인 키와 공개 키는 짝으로 만든 두 값입니다. 개인 키는 주인 혼자 갖습니다. 공개 키는 누구에게나 나눠 줍니다.

전자 서명은 데이터를 해시 함수에 넣은 결과를 보내는 쪽의 개인 키로 한 번 더 변환한 값입니다. 받는 쪽은 누구나 짝이 되는 공개 키로 이 값을 확인합니다. 개인 키를 모르면 서명을 올바르게 만들거나 고칠 수 없습니다. 그래서 데이터가 바뀌었는지와 함께 누가 보냈는지도 확인됩니다.

암호화는 무결성을 따로 주지 않습니다. 암호화가 주는 것은 허가받은 쪽만 데이터를 읽게 하는 기밀성입니다. 데이터가 허가 없이 바뀌거나 위조되지 않았음을 보장하는 일은 별개의 보안 서비스입니다. 그러므로 암호화와 메시지 인증 코드를 서로 다른 키로 함께 씁니다. 둘을 한 알고리즘으로 묶은 인증 암호를 쓰기도 합니다.

검증값은 바뀌었다는 사실만 알려 줍니다. 원래 값이 무엇이었는지는 알려 주지 않습니다. 되돌리는 일은 복사본이나 오류 정정 부호 같은 다른 도구가 맡습니다.

검증값을 고르는 기준은 「누가 데이터를 바꿀 수 있나」입니다. 사고로 생긴 변경만 걱정되면 체크섬으로 알아챕니다. 데이터를 일부러 고칠 상대가 있으면 비밀 키나 개인 키가 들어간 검증값이 필요합니다.

데이터베이스에서 규칙을 강제하는 제약 조건

데이터베이스의 무결성은 바뀐 뒤에 알아채는 성질이 아닙니다. 규칙을 어기는 값이 들어오기 전에 막는 성질입니다. 이 소절은 테이블에 거는 제약 조건이 어떤 쓰기를 거부하는지를 봅니다.

칸의 자료형만으로는 규칙을 다 담지 못합니다. 상품 가격 칸은 아마 양수만 받아야 합니다. 하지만 양수만 받는 표준 자료형은 없습니다. 상품 번호마다 행이 하나뿐이어야 한다는 규칙처럼 다른 행과 견줘야 하는 규칙도 있습니다.

그래서 SQL(Structured Query Language)로 칸과 테이블에 제약 조건을 선언합니다. 제약을 어기는 값을 저장하려 들면 데이터베이스가 오류를 내고 그 쓰기를 거부합니다. 그 값이 기본값 정의에서 나온 것이어도 마찬가지입니다.

외래 키가 지키는 규칙을 참조 무결성이라고 부릅니다. 직원은 실제로 있는 부서에만 속할 수 있다는 규칙이 그 예입니다. 기본 키 값이 비어 있으면 안 된다는 규칙은 개체 무결성이라고 부릅니다.

맥락별 뜻

무결성이 무엇을 지키는 성질인지는 맥락마다 다릅니다. 아래 표는 「상세」에서 본 두 맥락에 시스템을 더해, 세 맥락에서 이 낱말이 가리키는 것을 출처와 함께 놓습니다.

정보보안

이 맥락 안에서도 무결성이라는 낱말은 한 번 더 갈립니다. 인터넷 보안 용어집 RFC 4949 에는 이 낱말 자체의 정의가 없습니다. 데이터 무결성·정확성 무결성·출처 무결성·시스템 무결성으로 갈라 보내기만 합니다.

그중 데이터 무결성은 값이 안 바뀌었는가만 다룹니다. 그 값이 나타내는 정보가 현실과 맞는지는 정확성 무결성, 값을 내놓은 출처를 믿을 만한지는 출처 무결성이라는 다른 이름으로 떼어 둡니다. 출처 무결성은 비바 무결성이라고도 부릅니다. 「배경」의 비바 모델이 그 이름의 뿌리입니다.

갈라 두지 않는 정의도 있습니다. 미국 연방 법률의 정의를 받은 FIPS 199 는 부적절한 수정과 파괴를 막는 것에 더해 부인 방지와 진정성까지 무결성에 넣습니다. 진정성은 데이터가 주장하는 그 출처에서 온 것이 맞다는 성질이고, 부인 방지는 보낸 쪽이 나중에 보낸 사실을 부인하지 못하게 하는 성질입니다.

곧 보안 문서를 읽을 때도 그 문서가 어느 정의를 쓰는지 봐야 합니다. 값의 불변만 가리키는 좁은 정의와 출처까지 싸 담는 넓은 정의가 같은 낱말로 쓰입니다.

보안에서는 무결성을 기밀성·가용성과 나란히 세웁니다. 셋은 정보와 정보 시스템이 지켜야 할 보안 목표입니다. 영어 이름의 머리글자를 따서 CIA(Confidentiality · Integrity · Availability)라고 묶어 부릅니다.

셋은 따로 깨집니다. 암호화로 기밀성을 지킨 데이터도 바뀔 수 있습니다. 무결성을 지킨 데이터도 서비스가 멈추면 쓰지 못합니다.

데이터베이스

이 맥락에서 업무 규칙은 늘 참이어야 하거나 늘 거짓이어야 하는 조건과 관계입니다. 「상품 가격은 양수다」는 늘 참이어야 하는 조건입니다. 「상품 가격이 0 이하다」는 늘 거짓이어야 하는 조건입니다. 「직원은 실제로 있는 부서에만 속한다」는 테이블 둘 사이에 걸리는 관계입니다.

급여·사원 번호·재고 관리에 어떤 규칙을 둘지는 회사마다 따로 정합니다. 무결성 제약은 이 규칙을 강제해 틀린 정보가 테이블에 들어오지 못하게 막습니다.

무결성 제약은 SQL 로 만들고 지우는 스키마 객체입니다. 데이터가 규칙을 지키게 하려면 되도록 무결성 제약을 쓰기를 권합니다. 앞의 「상세」에서 본 NOT NULL·유니크·기본 키·외래 키·체크가 그 종류입니다.

시스템

이 맥락에서 무결성을 따지는 대상은 데이터 한 덩이가 아니라 시스템 전체입니다. 시스템이 원래 하려던 일을 허가 없는 조작 없이 해내고 있는지를 묻습니다. 위 표가 쓴 정의가 이것입니다.

RFC 4949 에는 쓰지 말라고 적어 둔 옛 정의가 하나 더 있습니다. 운영체제의 논리적 정확성·신뢰성, 보호 장치를 구현한 하드웨어와 소프트웨어의 논리적 완전성, 데이터 구조의 일관성까지 한데 담은 정의입니다. 여러 개념을 섞어 오해를 부를 수 있다는 이유로 이 옛 정의는 쓰지 않기를 권합니다. 대신 정확성·신뢰성·데이터 무결성처럼 더 구체적인 말을 덧붙여 쓰라고 합니다.

리눅스 커널의 IMA 가 이 성질을 재는 장치입니다. 실행 파일과 중요한 시스템 파일이 읽히거나 프로세스로 실행될 때 그 해시 값을 목록에 남깁니다. 공격자가 측정 대상 파일의 내용을 바꾸면 그 변경을 알아챌 수 있습니다.

기계에 TPM(Trusted Platform Module) 칩이 있으면 IMA 는 이 목록 전체를 합친 값 하나를 칩 안에도 보관합니다. 그러면 중요한 시스템 파일이 바뀌었는지를 제3자에게 증명할 수 있습니다.

배경

무결성이라는 한 낱말이 갈린 것은 세 갈래가 각자 이 이름을 세웠기 때문입니다. 이 절은 그 세 갈래를 봅니다. 군 보안 연구, 관계형 데이터베이스, 그리고 상업 데이터 처리입니다.

군 보안 쪽에서 이 이름을 세운 것은 비바 모델입니다. 그 전까지 군 보안 연구는 기밀 정보를 누가 볼 수 있나만 다뤘습니다. 정보가 타당한지, 곧 부적절하게 고쳐지지 않았는지는 따로 지켜야 했습니다. 부적절한 수정을 막는 접근 규칙을 세워 무결성 정책이라고 불렀고, 유출을 막는 벨-라파듈라 모델의 짝이 이 모델입니다.

데이터베이스 쪽에서는 관계형 모델이 테이블 사이를 포인터 없이 값으로만 잇습니다. 기본 키가 비거나 가리키는 값이 상대 테이블에 없으면 연결이 끊깁니다. 모든 삽입·갱신·삭제에 두 규칙을 걸어 이것을 막았습니다. 두 규칙의 이름이 개체 무결성과 참조 무결성입니다.

상업 데이터 처리 쪽에서는 첫째 보안 관심이 기밀이 아니라 데이터 무결성이었습니다. 사업 운영과 자산을 다루는 일이기 때문입니다. 클라크-윌슨 모델은 사기와 실수를 막는 장치로 둘을 세웠습니다. 데이터를 정해진 방식으로만 바꾸게 하는 잘 짜인 트랜잭션, 그리고 한 작업을 여러 사람에게 나누는 직무 분리입니다.

이 모델은 데이터가 무결성 규격에 맞는지 확인하는 절차도 따로 두었습니다. 회계의 감사에 해당하는 이 절차를 무결성 검증 절차라고 부릅니다. 보안의 「허가 없는 변경을 막는다」와 데이터베이스의 「값이 규칙에 맞는다」가 이 모델 안에서 만납니다.

경계

입력할 때부터 틀린 주문 금액이 저장돼 있습니다. 저장한 뒤로는 아무도 손대지 않아 체크섬도 맞습니다. 이 데이터의 무결성은 깨졌을까요?

보안 뜻으로는 깨지지 않았습니다. 이 뜻의 무결성은 값이 저장된 뒤 바뀌었는가만 묻습니다. 값이 나타내는 정보가 맞는지는 묻지 않습니다.

데이터베이스 뜻으로는 그 금액이 제약을 어길 때만 깨졌습니다. 금액은 0보다 커야 한다는 체크 제약이 있다면 −1,000원은 처음부터 저장되지 않습니다. 10,000원을 1,000원으로 잘못 친 값은 제약에 맞으므로 데이터베이스도 못 잡습니다.

값이 현실과 맞는가는 두 뜻 어디에도 들지 않습니다. 이 성질은 정확성 무결성(correctness integrity)이라는 별개 이름으로 떼어져 있습니다. 널리 알려지지도 뜻이 굳지도 않은 이름이라, 정의를 함께 주지 않고 쓰는 것은 권장되지 않습니다(SHOULD NOT).

컴퓨터에는 대개 현실을 직접 재는 감지 장치가 없습니다. 그래서 이 성질은 한 작업을 여러 사람에게 나누는 직무 분리로 간접적으로 지킵니다.

같은 선으로 헷갈리는 이웃 셋도 가릅니다.

관련 항목

무결성을 확인하는 데 쓰는 도구

해시 함수 · 체크섬 · 메시지 인증 코드 · HMAC · 전자 서명 · 개인 키 · 공개 키 · 순환 중복 검사 · SHA-1 · 머클 트리 · 패리티 비트 · 암호학적 해시 함수

무결성과 나란히 세우는 보안 성질

기밀성 · 가용성 · 인증 · 부인 방지 · 최소 권한 · 진정성

무결성을 깨뜨리는 공격과 고장

중간자 공격 · 재전송 공격 · 비트 부패 · 변조 · 데이터 손상 · 능동 공격

무결성을 지키며 데이터를 나르는 프로토콜

TLS · HTTPS · SSH · IPsec · 인증 암호

저장된 데이터의 무결성을 지키는 방법

데이터 스크러빙 · ECC 메모리 · RAID · 백업과 복구 · 오류 정정 부호

데이터베이스가 지키는 무결성 규칙

참조 무결성 · 개체 무결성 · 도메인 무결성 · 제약 조건 · 기본 키 · 외래 키 · 유니크 제약 · 체크 제약 · 트랜잭션

무결성과 헷갈리는 이웃 성질

일관성 · ACID · 데이터 출처 인증 · 정확성 무결성

무결성 정책을 세운 보안 모델과 장치

비바 모델 · 벨-라파듈라 모델 · 클라크-윌슨 모델 · 직무 분리 · 관계형 모델

시스템 무결성을 재는 장치

IMA · TPM · 보안 부팅 · 원격 증명

무결성 검증을 얹어 만든 구조

블록체인 · Git · 내용 주소 저장 · 코드 서명 · 무결성 검증