정보보안 CIA 3요소란? 기밀성·무결성·가용성의 차이와 설계 방법

1장 정보보안 CIA 3요소란 무엇인가#

정보보안을 공부할 때 가장 먼저 등장하는 개념 중 하나가 CIA 3요소입니다.

여기서 CIA는 정보기관을 의미하는 것이 아니라 다음 세 가지 보안 목표의 앞 글자를 뜻합니다.

  • Confidentiality
  • Integrity
  • Availability

한국어로는 각각 다음과 같습니다.

  • 기밀성
  • 무결성
  • 가용성

원문에서는 이를 다음 질문으로 구분합니다.

기밀성
누가 정보를 볼 수 있는가?

무결성
정보가 정당하게 변경되었는가?

가용성
필요할 때 서비스를 사용할 수 있는가?

세 요소는 서로 비슷해 보이지만 보호하려는 대상이 다릅니다.

2장 CIA 3요소를 한눈에 보면#

flowchart TB
    CIA[정보보안 CIA 3요소]

    C[기밀성<br/>Confidentiality]
    I[무결성<br/>Integrity]
    A[가용성<br/>Availability]

    CIA --> C
    CIA --> I
    CIA --> A

    C --> C1[인가]
    C --> C2[암호화]
    C --> C3[데이터 분류]

    I --> I1[변경 권한]
    I --> I2[HMAC]
    I --> I3[전자서명]

    A --> A1[이중화]
    A --> A2[백업·복구]
    A --> A3[자원 제한]

CIA는 단순한 보안 암기 용어가 아니라 보안 통제를 설계할 때 무엇을 보호하려는지 판단하는 기준입니다.

3장 기밀성 Confidentiality이란 무엇인가#

기밀성은 허가받지 않은 사용자가 정보를 보지 못하게 하는 것입니다.

핵심 질문은 간단합니다.

이 정보를 누가 볼 수 있는가?

예를 들어 고객 주문 시스템에 다음 정보가 있다고 하겠습니다.

이름
주소
전화번호
결제정보
주문내역

고객 A의 정보를 고객 B가 볼 수 있다면 기밀성이 깨진 것입니다.

따라서 기밀성을 보호하려면 정보에 접근할 수 있는 사람을 제한해야 합니다.

4장 기밀성을 보호하는 대표적인 방법#

원문에서는 기밀성 보호 수단으로 다음을 제시합니다.

  • 접근통제
  • 암호화
  • 데이터 분류

예를 들어:

flowchart LR
    U[사용자]
    AUTH[인증]
    AUTHZ[인가]
    DATA[(고객정보)]

    U --> AUTH
    AUTH --> AUTHZ
    AUTHZ -->|허용| DATA
    AUTHZ -->|거부| X[접근 차단]

사용자의 신원을 확인하는 것만으로는 충분하지 않습니다.

누가 어떤 데이터까지 볼 수 있는지를 별도로 통제해야 합니다.

5장 무결성 Integrity이란 무엇인가#

무결성은 데이터가 허가되지 않은 방식으로 변경되지 않았는지를 보호하는 개념입니다.

핵심 질문은 다음과 같습니다.

이 정보가 정당하게 변경되었는가?

예를 들어 주문 금액이 원래:

100,000원

이었는데 공격자가 요청 값을 수정해:

1,000원

으로 결제할 수 있다면 무결성이 깨진 것입니다.

6장 무결성에서 중요한 것은 변경 권한이다#

무결성은 단순히:

데이터가 바뀌지 않았다.

만을 의미하지 않습니다.

정상적인 시스템에서는 데이터가 계속 변경됩니다.

예를 들어:

주문 생성
결제 완료
배송 시작
배송 완료

처럼 상태가 바뀌어야 합니다.

따라서 진짜 질문은:

이 변경이 허가된 사용자와 정상적인 절차에 의해 발생했는가?

입니다.

7장 무결성을 보호하는 대표적인 방법#

원문은 무결성 보호 방법으로 다음을 제시합니다.

  • 변경 권한
  • HMAC
  • 전자서명

개념적으로 보면 다음과 같습니다.

flowchart LR
    DATA[데이터]
    CHECK{검증}

    H[HMAC]
    S[전자서명]
    P[변경 권한]

    DATA --> CHECK

    H --> CHECK
    S --> CHECK
    P --> CHECK

    CHECK -->|정상| OK[변경 허용]
    CHECK -->|비정상| BLOCK[거부]

8장 해시값만 저장하면 무결성이 보장될까#

원문에서 중요한 질문 중 하나입니다.

답은 아닐 수 있습니다.

공격자가 데이터와 함께 해시값도 변경할 수 있다면:

원본 데이터 변경
+
해시값 재계산

이 가능하기 때문입니다.

원문도 공격자가 데이터와 해시값을 함께 바꿀 수 있는 경우 단순 해시만으로는 충분하지 않다고 설명합니다.

따라서 위협 모델에 따라:

  • 별도 신뢰 기준값
  • HMAC
  • 전자서명

등을 고려해야 합니다.

9장 해시와 HMAC의 차이를 간단히 보면#

단순 해시#

데이터
↓
Hash
↓
해시값

누구나 같은 데이터를 가지고 있으면 같은 해시값을 계산할 수 있습니다.

HMAC#

데이터
+
비밀 키
↓
HMAC
↓
인증 코드

비밀 키가 있어야 올바른 값을 만들 수 있습니다.

따라서 단순 변조 탐지보다 더 강한 검증이 필요한 경우 HMAC을 사용할 수 있습니다.

10장 가용성 Availability이란 무엇인가#

가용성은 필요한 시점에 시스템과 정보를 사용할 수 있는 상태를 의미합니다.

핵심 질문은:

필요할 때 사용할 수 있는가?

입니다.

보안이라고 하면 흔히 해킹이나 정보 유출만 생각하지만 서비스가 계속 중단되는 것도 중요한 보안 문제입니다.

11장 주문 서비스에서 가용성이 깨지면#

예를 들어 쇼핑몰 데이터베이스에 장애가 발생했다고 하겠습니다.

flowchart LR
    USER[고객]
    WEB[주문 서비스]
    DB[(Database)]

    USER --> WEB
    WEB --> DB
    DB -. 장애 .-> X[주문 불가]

고객정보가 유출되지 않았고 데이터 변조도 없더라도 주문 자체가 불가능하다면 가용성 문제가 발생한 것입니다.

12장 가용성을 보호하는 방법#

원문에서는 다음 방법을 제시합니다.

  • 이중화
  • 복원
  • 자원 제한

또 백업은 단순 보관이 아니라 실제 복원 가능성까지 확인해야 합니다.

예:

flowchart TB
    APP[Application]

    DB1[(Primary DB)]
    DB2[(Standby DB)]
    BK[(Backup)]

    APP --> DB1
    DB1 --> DB2
    DB1 --> BK

    DB1 -. 장애 .-> DB2

13장 백업이 있다고 가용성이 확보된 것은 아니다#

다음 상태를 생각해보겠습니다.

백업 파일 존재

이것만으로 충분하지 않습니다.

중요한 것은:

실제로 복원 가능한가?

입니다.

원문에서도 백업 성공 기록과 실제 복원 가능성을 함께 확인해야 한다고 강조합니다.

즉:

flowchart LR
    A[백업 생성]
    B[백업 검증]
    C[복원 테스트]
    D[서비스 복구]

    A --> B --> C --> D

까지 확인해야 진짜 복구 전략이 됩니다.

14장 CIA 중 무엇이 가장 중요한가#

정답은 없습니다.

원문에서도 세 요소에 보편적인 우선순위는 없다고 설명합니다.

시스템의 특성에 따라 달라집니다.

예를 들어:

의료·산업제어 시스템#

서비스 중단 피해가 매우 크기 때문에 가용성이 특히 중요할 수 있습니다.

개인정보 서비스#

정보 유출 피해가 크므로 기밀성이 높은 우선순위를 가질 수 있습니다.

금융·결제 시스템#

거래 데이터의 변경 여부가 중요하기 때문에 무결성이 매우 중요할 수 있습니다.

즉 보안 설계는 CIA 세 요소를 동일한 비율로 적용하는 것이 아니라 위험에 따라 우선순위를 정하는 과정입니다.

15장 CIA를 위험관리 관점에서 보면#

flowchart TB
    ASSET[자산]

    C{기밀성 피해}
    I{무결성 피해}
    A{가용성 피해}

    RISK[위험 평가]
    CONTROL[보안 통제]

    ASSET --> C
    ASSET --> I
    ASSET --> A

    C --> RISK
    I --> RISK
    A --> RISK

    RISK --> CONTROL

먼저 자산을 확인하고:

  • 유출되면 어떤 피해가 발생하는가
  • 변경되면 어떤 피해가 발생하는가
  • 사용할 수 없으면 어떤 피해가 발생하는가

를 판단한 뒤 보안 통제를 선택하는 것입니다.

16장 인증 Authentication이란 무엇인가#

원문에서는 CIA와 함께 인증·인가·책임추적성을 구분합니다.

인증은:

당신은 누구인가?

를 확인하는 과정입니다.

예:

ID / Password
MFA
인증서
생체인증

등이 있습니다.

17장 인가 Authorization이란 무엇인가#

인가는:

이 사용자가 이 자원을 사용할 수 있는가?

를 결정하는 과정입니다.

flowchart LR
    U[사용자]
    AUTH[인증]
    AUTHZ[인가]

    A[일반 데이터]
    B[관리자 데이터]

    U --> AUTH --> AUTHZ

    AUTHZ -->|허용| A
    AUTHZ -->|권한 없음| B

따라서:

인증
= 누구인가

인가
= 무엇을 할 수 있는가

입니다.

18장 책임추적성 Accountability이란 무엇인가#

책임추적성은:

누가 무엇을 했는가?

를 확인할 수 있는 능력입니다.

원문은 책임추적성을 행위와 주체를 연결하는 기록으로 설명합니다.

대표적인 수단은 감사로그입니다.

예:

사용자: admin01
시간: 14:31
행위: 주문 금액 수정
대상 주문: ORDER-1024
결과: 성공

이런 기록이 있어야 사고 발생 후 원인을 추적할 수 있습니다.

19장 CIA와 인증·인가·감사의 관계#

flowchart TB
    USER[사용자]

    AUTH[인증<br/>누구인가]
    AUTHZ[인가<br/>무엇을 할 수 있는가]

    C[기밀성]
    I[무결성]
    A[가용성]

    LOG[책임추적성<br/>누가 무엇을 했는가]

    USER --> AUTH
    AUTH --> AUTHZ

    AUTHZ --> C
    AUTHZ --> I

    C --> LOG
    I --> LOG
    A --> LOG

CIA는 보호 목표이고, 인증·인가·감사는 그 목표를 달성하기 위한 통제 체계로 볼 수 있습니다.

20장 주문 서비스 사례로 CIA 이해하기#

원문은 주문 서비스를 예로 들어 CIA를 설명합니다.

이를 조금 더 구조화해 보겠습니다.

21장 기밀성 사례: 고객 주소#

고객 A의 주문에는 다음 정보가 포함되어 있습니다.

이름
전화번호
주소
주문상품

고객 B가 고객 A의 주소를 볼 수 있다면 기밀성 문제가 발생합니다.

따라서:

flowchart LR
    A[고객 A]
    DATA[(고객 A 주문정보)]
    B[고객 B]

    A -->|허용| DATA
    B -. 접근 차단 .-> DATA

처럼 접근통제가 필요합니다.

22장 무결성 사례: 결제 금액#

클라이언트가 다음 데이터를 보낸다고 하겠습니다.

상품 가격: 100,000원
수량: 1
결제 금액: 1,000원

클라이언트가 보낸 결제 금액을 그대로 신뢰하면 위험합니다.

원문에서는 서버에서 결제 금액을 다시 계산하는 것을 무결성 보호 사례로 제시합니다.

구조는 다음과 같습니다.

sequenceDiagram
    participant C as Client
    participant S as Server
    participant DB as 상품 DB

    C->>S: 상품 ID + 수량
    S->>DB: 상품 가격 조회
    DB-->>S: 100,000원
    S->>S: 결제 금액 재계산
    S-->>C: 최종 결제금액

즉 중요한 값은 클라이언트 요청을 그대로 신뢰하지 않는 것이 좋습니다.

23장 가용성 사례: 데이터베이스 장애#

주문 DB가 장애를 일으키면 고객은 주문을 할 수 없습니다.

flowchart LR
    USER[고객]
    WEB[주문 서버]

    DB1[(Primary DB)]
    DB2[(Recovery / Standby)]

    USER --> WEB
    WEB --> DB1
    DB1 -. 장애 .-> DB2

이 경우 복구 구조가 가용성을 지키는 핵심 요소가 됩니다.

24장 암호화만 하면 보안이 완성될까#

아닙니다.

원문에서도 암호화만 적용한다고 해서:

  • 잘못된 주문 수정
  • 서비스 장애

문제까지 해결되는 것은 아니라고 설명합니다.

암호화는 주로 기밀성을 보호하는 중요한 수단이지만 모든 보안 문제를 해결하는 만능 기술은 아닙니다.

25장 하나의 보안 통제가 모든 CIA를 해결하지 못한다#

예를 들어 데이터베이스 전체를 강하게 암호화했다고 하겠습니다.

그래도 다음 문제가 남을 수 있습니다.

관리자 권한 오남용
데이터 삭제
잘못된 주문 변경
DB 장애
서비스 과부하

따라서 보안 설계는 여러 통제를 조합해야 합니다.

flowchart TB
    SYSTEM[서비스]

    ENC[암호화]
    ACCESS[접근통제]
    VERIFY[무결성 검증]
    HA[이중화]
    BACKUP[백업·복구]
    LOG[감사로그]

    SYSTEM --> ENC
    SYSTEM --> ACCESS
    SYSTEM --> VERIFY
    SYSTEM --> HA
    SYSTEM --> BACKUP
    SYSTEM --> LOG

26장 데이터마다 CIA 우선순위가 다를 수 있다#

같은 서비스 안에서도 모든 데이터가 동일한 보호 수준을 가질 필요는 없습니다.

예:

데이터 기밀성 무결성 가용성
고객 주소 높음 높음 중간
상품 가격 낮음~중간 매우 높음 높음
결제 기록 높음 매우 높음 높음
공개 상품 설명 낮음 높음 높음
감사로그 중간 매우 높음 중간

이 표는 이해를 위한 일반적인 예이며 실제 위험 수준은 서비스 특성에 따라 달라질 수 있습니다.

27장 보안 설계는 데이터 분류에서 시작한다#

원문은 적용 전 확인할 사항으로 데이터별 조회·수정·중단 피해를 구분하라고 제시합니다.

즉 먼저 다음 질문을 해야 합니다.

이 데이터가 유출되면?

이 데이터가 변경되면?

이 데이터를 사용할 수 없으면?

이를 CIA 관점으로 바꾸면:

flowchart LR
    DATA[데이터]

    C[유출 피해]
    I[변조 피해]
    A[중단 피해]

    DATA --> C
    DATA --> I
    DATA --> A

입니다.

28장 위협에 맞는 통제를 선택해야 한다#

예를 들어 무결성을 보호하려고 단순 Hash를 사용한다고 하겠습니다.

하지만 공격자가:

데이터
+
Hash

둘 다 변경할 수 있다면 검증 의미가 없습니다.

원문에서 강조하듯 무결성 검증은 신뢰할 수 있는 기준값이나 인증 키와 연결되어야 합니다.

따라서 통제는 항상 위협 모델과 함께 설계해야 합니다.

29장 CIA 기반 보안 설계 절차#

실무에서는 다음과 같은 흐름으로 생각할 수 있습니다.

flowchart TB
    A[자산 식별]
    B[데이터 분류]
    C[CIA 영향 분석]
    D[위협·취약점 분석]
    E[보안 통제 선택]
    F[운영·모니터링]
    G[복구 검증]

    A --> B --> C --> D --> E --> F --> G

원문의 CIA 개념을 실제 위험관리 프로세스로 연결하면 이런 구조로 이해할 수 있습니다.

30장 CIA를 체크리스트로 바꾸면#

기밀성#

  • 누가 데이터를 볼 수 있는가
  • 인증은 되어 있는가
  • 인가 정책이 있는가
  • 민감 데이터는 암호화되어 있는가
  • 데이터 분류가 되어 있는가

무결성#

  • 누가 데이터를 수정할 수 있는가
  • 변경 권한이 검증되는가
  • 중요한 데이터는 서버에서 다시 검증하는가
  • HMAC·전자서명 같은 검증이 필요한가
  • 감사로그가 남는가

가용성#

  • 장애 시 서비스가 계속 가능한가
  • 이중화가 필요한가
  • 백업이 존재하는가
  • 복원 테스트를 했는가
  • 과도한 요청을 제한할 수 있는가

CIA 3요소 FAQ#

CIA 3요소란 무엇인가#

기밀성 Confidentiality, 무결성 Integrity, 가용성 Availability을 의미합니다. 정보보안에서 가장 기본적인 보호 목표입니다.

기밀성과 무결성의 차이는 무엇인가#

기밀성은 누가 데이터를 볼 수 있는지를 보호하고, 무결성은 데이터가 정당한 방식으로 변경되었는지를 보호합니다.

가용성이 왜 보안에 포함되는가#

시스템과 정보가 필요할 때 사용할 수 없다면 서비스 목적을 달성할 수 없기 때문입니다. 서비스 중단도 중요한 보안 위험입니다.

CIA 중 가장 중요한 것은 무엇인가#

정해진 우선순위는 없습니다. 원문에서도 서비스 특성과 위험에 따라 우선순위가 달라져야 한다고 설명합니다.

암호화를 하면 CIA를 모두 보호할 수 있나#

아닙니다. 암호화는 기밀성 보호에 중요한 기술이지만 잘못된 데이터 변경이나 시스템 장애 문제까지 해결하지는 못합니다.

해시만 저장하면 무결성을 보장할 수 있나#

항상 그렇지는 않습니다. 공격자가 데이터와 해시를 모두 변경할 수 있다면 충분하지 않으며 별도의 기준값, HMAC, 전자서명 같은 수단이 필요할 수 있습니다.

인증과 인가는 무엇이 다른가#

인증은 사용자 신원을 확인하고, 인가는 해당 사용자가 특정 자원에 접근하거나 기능을 실행할 수 있는지를 결정합니다.

책임추적성이란 무엇인가#

누가 언제 어떤 작업을 수행했는지 확인할 수 있도록 행위와 주체를 연결하는 기록입니다. 감사로그가 대표적인 수단입니다.

백업만 있으면 가용성이 확보되는가#

아닙니다. 원문에서도 백업 성공 기록뿐 아니라 실제 복원 가능성을 확인해야 한다고 설명합니다.

핵심 정리#

CIA 3요소는 정보보안을 설계할 때 가장 기본적인 질문을 제공합니다.

flowchart LR
    DATA[정보 자산]

    C[기밀성<br/>누가 볼 수 있는가]
    I[무결성<br/>정당하게 변경되었는가]
    A[가용성<br/>필요할 때 사용할 수 있는가]

    DATA --> C
    DATA --> I
    DATA --> A

각 요소는 서로 다른 보호 전략을 필요로 합니다.

기밀성
→ 접근통제 · 암호화 · 데이터 분류

무결성
→ 변경 권한 · HMAC · 전자서명

가용성
→ 이중화 · 복구 · 백업 · 자원 관리

그리고 CIA만으로 보안 설계가 끝나는 것은 아닙니다.

인증
= 누구인가

인가
= 무엇을 할 수 있는가

책임추적성
= 누가 무엇을 했는가

이 세 가지도 함께 고려해야 합니다.

가장 중요한 것은 모든 시스템에 동일한 보안 대책을 적용하는 것이 아닙니다.

먼저:

유출되면 얼마나 위험한가

변조되면 얼마나 위험한가

중단되면 얼마나 위험한가

를 판단해야 합니다.

그 결과에 따라 기밀성·무결성·가용성의 우선순위를 정하고 적절한 통제를 적용하는 것이 위험 기반 정보보안 설계의 출발점입니다.

이 페이지의 목차