[CS300 #241] 보안의 3요소 — 기밀성·무결성·가용성 — 무엇을 지키는지부터 정한다

컴퓨터공학 300 주제 시리즈의 241번째 글이다. 전체 지도는 여기.

한 줄 요약

보안은 “해킹을 막는 것” 이 아니라 정보의 기밀성(Confidentiality)·무결성(Integrity)·가용성(Availability) 을 지키는 일이고, 세 가지는 서로 부딪치기 때문에 무엇을 얼마나 지킬지 먼저 정해야 한다.

왜 필요한가

“보안을 강화하자” 는 말은 아무것도 정하지 않는다. 비밀번호를 길게 하자는 건지, 백업을 늘리자는 건지, DDoS 를 막자는 건지 알 수 없다. 대책은 서로 비용을 다툰다. 암호화를 겹겹이 걸면 기밀성은 오르지만 키를 잃는 순간 가용성이 0 이 된다. 이중화로 가용성을 올리면 복제본이 늘어 기밀성 관리 대상도 늘어난다.

CIA 3요소는 이 논의를 정리하는 가장 오래된 틀이다. 미국 연방 표준 FIPS 199 는 정보와 정보시스템의 보안 범주를 정할 때 바로 이 세 축을 쓴다. 장애 보고서도, 취약점 등급도, 감사 체크리스트도 결국 “세 축 중 어디가 깨졌나” 로 환원된다. 이 언어를 먼저 익혀 두면 이후의 암호·인증·네트워크 보안이 모두 “어느 축을 지키는 도구인가” 로 정리된다.

핵심 개념

세 가지 정의

FIPS 199 는 미국 연방법(44 U.S.C. 3542)의 정의를 그대로 가져온다.

요소	정의(요지)	깨졌을 때의 예
기밀성	정보 접근과 공개에 대해 허가된 제한을 유지하는 것. 개인정보와 영업비밀 보호를 포함한다	고객 DB 유출, 로그에 찍힌 토큰
무결성	정보가 부적절하게 수정·파괴되지 않도록 지키는 것. 부인 방지와 진정성(authenticity) 보장을 포함한다	송금액 변조, 배포 바이너리 바꿔치기
가용성	정보에 시기적절하고 신뢰성 있게 접근·사용할 수 있게 하는 것	서비스 다운, 랜섬웨어로 파일 잠김

랜섬웨어는 좋은 연습 문제다. 파일을 암호화해 못 쓰게 만드는 건 가용성 침해다. 요즘처럼 파일을 먼저 빼낸 뒤 공개하겠다고 협박하면 기밀성 침해가 겹친다.

확장 요소

세 축만으로 부족하다는 지적도 많아서 다음 속성을 함께 말한다. 다만 FIPS 199 의 정의처럼 무결성 안에 포함시키는 관점도 있다.

진정성(Authenticity): 이 데이터가 정말 그 주체에게서 왔는가. MAC·전자서명이 담당한다.
부인 방지(Non-repudiation): 보낸 사람이 나중에 “안 보냈다” 고 못 하게 하는 것. 공개키 서명이 필요하다. 공유 비밀 기반 MAC 으로는 부족하다(양쪽 다 만들 수 있으므로).
책임 추적성(Accountability): 누가 무엇을 했는지 기록으로 남는 것. 감사 로그가 담당한다.

영향도로 범주를 매긴다

FIPS 199 는 각 축별 잠재 영향을 LOW·MODERATE·HIGH 로 매기고 다음처럼 적는다.

SC(급여 시스템) = {(기밀성, HIGH), (무결성, HIGH), (가용성, MODERATE)}
SC(회사 소개 페이지) = {(기밀성, N/A), (무결성, MODERATE), (가용성, LOW)}

공개 페이지는 원래 공개된 정보라 기밀성이 의미 없지만, 누가 첫 화면을 바꿔치기하면 신뢰가 무너지므로 무결성은 중요하다. 이렇게 축별로 따로 매기는 게 핵심이다. “중요한 시스템” 이라는 한 단어로 뭉뚱그리지 않는다.

축과 대책의 대응

기밀성  <- 접근 통제, 암호화(저장·전송), 최소 권한, 데이터 마스킹
무결성  <- 해시·MAC·전자서명, 입력 검증, 트랜잭션, 버전 관리, 변경 승인
가용성  <- 이중화, 백업·복구 훈련, 속도 제한, 용량 계획, DDoS 완화

세 축은 부딪친다

대책	올라가는 축	내려갈 수 있는 축
강한 계정 잠금(5회 실패 시 잠금)	기밀성	가용성 — 공격자가 일부러 틀려 정상 사용자를 잠근다
전체 디스크 암호화	기밀성	가용성 — 키 분실 시 복구 불가
다중 리전 복제	가용성	기밀성 — 사본과 접근 경로가 늘어난다
쓰기마다 서명 검증	무결성	가용성 — 지연과 장애 지점 증가

그래서 보안 설계는 “최대한 막는다” 가 아니라 “이 자산에 대해 이 축을 이만큼” 으로 표현된다. 이것이 다음 글의 위협 모델링과 위험 관리로 이어진다.

직접 해 보기

세 축을 각각 한 줄씩 체감하는 파이썬 예제다. 표준 라이브러리만 쓴다.

import hashlib, os, stat, tempfile, time

# 1) 기밀성: 파일 권한이 소유자 전용인지 본다
fd, path = tempfile.mkstemp()
os.write(fd, b"db_password=example-only\n"); os.close(fd)
os.chmod(path, 0o644)
mode = stat.S_IMODE(os.stat(path).st_mode)
print("기밀성: 다른 사용자도 읽을 수 있나?", bool(mode & 0o044))
os.chmod(path, 0o600)
mode = stat.S_IMODE(os.stat(path).st_mode)
print("기밀성: chmod 600 뒤에는?", bool(mode & 0o044))

# 2) 무결성: 내려받은 파일의 해시를 기대값과 비교한다
data = open(path, "rb").read()
expected = hashlib.sha256(data).hexdigest()
tampered = data.replace(b"example", b"EXAMPLE")
print("무결성: 원본 일치", hashlib.sha256(data).hexdigest() == expected)
print("무결성: 변조본 일치", hashlib.sha256(tampered).hexdigest() == expected)

# 3) 가용성: 토큰 버킷으로 한 클라이언트가 자원을 독점하지 못하게 한다
class TokenBucket:
    def __init__(self, rate, capacity):
        self.rate, self.capacity = rate, capacity
        self.tokens, self.last = capacity, time.monotonic()
    def allow(self):
        now = time.monotonic()
        self.tokens = min(self.capacity, self.tokens + (now - self.last) * self.rate)
        self.last = now
        if self.tokens >= 1:
            self.tokens -= 1
            return True
        return False

b = TokenBucket(rate=5, capacity=5)
results = [b.allow() for _ in range(20)]
print("가용성: 20번 연속 요청 중 허용", sum(results), "건")
os.remove(path)

실행 결과(Python 3.12):

기밀성: 다른 사용자도 읽을 수 있나? True
기밀성: chmod 600 뒤에는? False
무결성: 원본 일치 True
무결성: 변조본 일치 False
가용성: 20번 연속 요청 중 허용 5 건

주의할 점이 하나 있다. 2번의 해시 비교는 우연한 손상은 잡지만 악의적 변조는 기대값이 안전한 경로로 왔을 때만 잡는다. 공격자가 파일과 해시값을 함께 바꿀 수 있다면 소용없다. 그래서 진정성까지 원하면 MAC 이나 전자서명이 필요하다. 이 차이는 해시·MAC 편에서 다룬다.

현업에서는

장애 보고서의 분류: 사고 보고서 첫 줄에 “가용성 침해, 기밀성 영향 없음” 처럼 적는 팀이 많다. 고객 공지 여부와 규제 신고 의무가 이 분류로 갈린다.
취약점 점수: CVSS 는 취약점의 영향을 기밀성·무결성·가용성 각각에 대해 따로 평가한다. 같은 “치명적” 이라도 정보 유출형인지 서비스 중단형인지가 점수 벡터에 드러난다.
쿠버네티스 시크릿: 기본적으로 시크릿은 etcd 에 base64 로 저장될 뿐 암호화되지 않는다. 저장 시 암호화(encryption at rest)를 켜는 건 기밀성 대책이고, etcd 스냅샷 백업은 가용성 대책이다. 그런데 백업 파일에 시크릿이 평문으로 들어 있으면 가용성 대책이 기밀성 구멍이 된다. 홈랩에서도 etcd 백업을 어디에 두는지, 누가 읽을 수 있는지가 같은 무게로 따져져야 한다.
속도 제한의 양면: 로그인 API 에 속도 제한을 거는 건 무차별 대입(기밀성 위협)을 막는 동시에 자원 고갈(가용성 위협)도 막는다. 한 대책이 여러 축에 걸치는 경우가 흔하다.

확인 문제

공격자가 웹 서버의 첫 화면을 다른 그림으로 바꿨다. 주로 깨진 축은 무엇인가?
“로그인 5회 실패 시 계정 영구 잠금” 정책이 가용성을 해칠 수 있는 이유를 설명하라.
공개 다운로드 페이지에 SHA-256 값을 같은 서버에 함께 올려 두었다. 이것으로 막을 수 있는 것과 없는 것을 구분하라.
FIPS 199 표기로 사내 위키(사내 정보, 수정 이력 중요, 하루 정도 중단 허용)의 보안 범주를 직접 적어 보라.

풀이

무결성이다. 정보가 허가 없이 수정됐다. 서비스가 계속 응답하므로 가용성은 유지된다.
공격자가 피해자 아이디로 일부러 5번 틀리면 정상 사용자가 로그인할 수 없다. 기밀성을 위한 대책이 가용성 공격 도구가 된다. 그래서 영구 잠금 대신 지연 증가·추가 인증 같은 완화책을 쓴다.
전송 중 우연한 손상이나 미러 서버의 손상은 잡는다. 하지만 같은 서버가 장악되면 파일과 해시를 함께 바꿀 수 있으므로 악의적 변조는 못 막는다. 별도 채널이나 전자서명이 필요하다.
예: SC = {(기밀성, MODERATE), (무결성, MODERATE), (가용성, LOW)}. 정답은 하나가 아니다. 근거를 축별로 댈 수 있으면 된다.