정보보안 위험관리 절차: 자산 식별부터 잔여 위험 승인까지 실무 흐름 이해하기

1장 정보보안 위험관리는 무엇을 하는 활동인가#

정보보안 위험관리는 단순히:

취약점 찾기
→ 목록 작성

으로 끝나는 활동이 아닙니다.

원문에서는 정보보안 위험관리를 자산에 어떤 사고가 발생할 수 있는지 평가하고, 조직이 감당할 수 있는 수준으로 위험을 처리하는 반복적인 활동으로 설명합니다. 또한 취약점 목록 작성에 그치지 않고 책임자·조치기한·검증 방법까지 정해야 한다고 강조합니다.

즉 위험관리는 다음과 같은 흐름입니다.

flowchart LR
    A[자산 식별]
    B[위험 평가]
    C[위험 처리]
    D[잔여 위험 승인]
    E[모니터링·재평가]

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

핵심은 반복입니다.

2장 위험관리는 왜 반복되어야 할까#

시스템은 계속 변합니다.

예를 들어:

새로운 서버 추가
새로운 외부 API 연동
관리자 계정 증가
클라우드 서비스 도입
업무 프로세스 변경

이런 변화가 생기면 기존 위험평가도 달라질 수 있습니다.

원문 역시 시스템 변경과 사고 발생 후 위험평가를 갱신해야 한다고 명시합니다.

즉 위험평가는 한 번 작성하고 보관하는 문서가 아니라 시스템 변화와 함께 계속 업데이트되는 관리 체계입니다.

3장 위험관리의 시작은 자산 식별이다#

위험을 평가하려면 먼저 무엇을 보호해야 하는지 알아야 합니다.

원문에서는 자산을 단순 서버로 제한하지 않습니다.

다음까지 포함합니다.

  • 데이터
  • 시스템
  • 계정
  • 외부 서비스
  • 업무 의존관계

즉 자산은 물리적인 장비만을 의미하지 않습니다.

4장 자산을 넓게 봐야 하는 이유#

예를 들어 쇼핑몰을 운영한다고 하겠습니다.

단순하게 보면 자산은:

웹서버
DB 서버

정도로 생각할 수 있습니다.

하지만 실제로는:

flowchart TB
    SERVICE[쇼핑몰 서비스]

    WEB[웹서버]
    DB[(고객 DB)]
    ADMIN[관리자 계정]
    PAY[결제 API]
    MAIL[메일 서비스]
    BACKUP[백업 저장소]

    SERVICE --> WEB
    SERVICE --> DB
    SERVICE --> ADMIN
    SERVICE --> PAY
    SERVICE --> MAIL
    SERVICE --> BACKUP

처럼 여러 자산과 외부 의존성이 연결됩니다.

이 중 하나라도 문제가 생기면 전체 서비스 위험으로 이어질 수 있습니다.

5장 데이터 흐름도 자산 식별의 일부다#

원문은 자산 식별 단계의 운영 증거로 자산 목록과 데이터 흐름을 제시합니다.

단순히:

고객 DB 있음

이라고 적는 것보다:

고객 입력
→ 웹서버
→ API
→ DB
→ 외부 결제사

처럼 흐름을 파악하는 것이 중요합니다.

flowchart LR
    U[고객]
    WEB[웹서버]
    API[API]
    DB[(고객 DB)]
    PAY[외부 결제 서비스]

    U --> WEB
    WEB --> API
    API --> DB
    API --> PAY

이 흐름을 알아야 어느 구간에 위험이 존재하는지 판단할 수 있습니다.

6장 위험은 무엇으로 판단하는가#

원문은 위험을 위협이 취약점을 이용했을 때의 가능성과 업무 영향을 함께 판단하는 것으로 설명합니다.

즉 위험을 단순화하면:

위험
=
발생 가능성
+
업무 영향

관점으로 볼 수 있습니다.

수학적인 공식이라기보다 판단의 두 축입니다.

7장 위협과 취약점은 다르다#

위협#

문제를 일으킬 수 있는 사건이나 행위

예:

계정 탈취
악성코드
DDoS
내부자 오남용

취약점#

위협이 실제 사고로 이어지게 만드는 약점

예:

약한 비밀번호
패치 미적용
공개된 관리 포트
과도한 권한

구조는 다음과 같습니다.

flowchart LR
    T[위협]
    V[취약점]
    A[자산]
    I[영향]

    T --> V
    V --> A
    A --> I

8장 가능성만 높다고 항상 최우선 위험은 아니다#

예를 들어 어떤 문제는 자주 발생하지만 피해가 작을 수 있습니다.

반대로 발생 가능성은 낮아도 피해가 매우 큰 위험이 있습니다.

따라서 다음 두 축을 함께 봐야 합니다.

quadrantChart
    title 위험 판단의 기본 관점
    x-axis 낮은 가능성 --> 높은 가능성
    y-axis 낮은 영향 --> 높은 영향
    quadrant-1 높은 우선순위
    quadrant-2 영향 중심 검토
    quadrant-3 낮은 우선순위
    quadrant-4 빈도 중심 검토

핵심은 가능성과 영향을 분리해서 보는 것입니다.

9장 고유 위험과 잔여 위험은 무엇이 다른가#

원문에서는 위험관리에서 중요한 두 개념을 구분합니다.

고유 위험#

통제를 적용하기 전의 위험

잔여 위험#

통제를 적용한 뒤에도 남아 있는 위험

예를 들어:

관리자 계정 탈취 위험

이 있다고 하겠습니다.

아무 통제도 없다면 고유 위험은 높을 수 있습니다.

여기에:

MFA
IP 제한
권한 분리
로그 모니터링

을 적용하면 위험은 줄어듭니다.

하지만 완전히 0이 되지는 않습니다.

남은 것이 잔여 위험입니다.

10장 고유 위험과 잔여 위험의 흐름#

flowchart LR
    A[고유 위험]
    B[보안 통제 적용]
    C[잔여 위험]

    A --> B --> C

보안의 현실적인 목표는:

모든 위험 제거

가 아니라:

수용 가능한 수준까지 위험 감소

입니다.

11장 위험 처리의 네 가지 기본 선택#

원문에서는 위험 처리 방법으로 다음 네 가지를 제시합니다.

  • 감소
  • 회피
  • 전가
  • 수용

이 네 가지는 정보보안 위험관리에서 매우 중요한 선택지입니다.

12장 위험 감소#

위험 감소는 보안 통제를 적용해 가능성이나 영향을 낮추는 것입니다.

예:

MFA 적용
방화벽 설정
접근권한 최소화
백업 구축
취약점 패치

구조:

flowchart LR
    R[높은 위험]
    C[통제 적용]
    R2[낮아진 위험]

    R --> C --> R2

가장 일반적으로 떠올리는 위험 대응 방식입니다.

13장 위험 회피#

위험 회피는 위험을 발생시키는 활동 자체를 하지 않는 것입니다.

예를 들어:

외부 인터넷에 관리자 페이지 공개

라는 위험이 있다고 하겠습니다.

이를 줄이는 것이 아니라:

외부 공개 자체를 제거

할 수도 있습니다.

즉:

flowchart LR
    A[위험한 활동]
    B[활동 중단]
    C[위험 제거 또는 대폭 감소]

    A --> B --> C

입니다.

14장 위험 전가#

원문에서는 보험이나 계약을 통해 손실을 분담하는 것을 위험 전가의 예로 설명합니다. 다만 전가한다고 해서 유출 예방 책임이 모두 없어지는 것은 아니다라고 강조합니다.

예:

사이버 보험
외부 서비스 계약
손해배상 조항

위험의 재정적 부담을 나눌 수 있지만 보안 책임 자체가 사라지는 것은 아닙니다.

15장 위험 수용#

위험 수용은:

아무것도 하지 않는다.

와 다릅니다.

원문은 위험 수용을 수용 가능한 이유와 손실 범위, 승인자, 재평가 조건을 기록하는 의사결정으로 설명합니다.

즉 다음 정보가 필요합니다.

왜 수용하는가
예상 손실은 어느 정도인가
누가 승인했는가
언제 다시 평가하는가

16장 위험 수용과 방치는 완전히 다르다#

위험 수용#

위험을 알고 있음
영향을 평가함
수용 근거가 있음
책임자가 승인함
재평가 조건이 있음

방치#

위험을 모름
평가하지 않음
책임자가 없음
기록이 없음
flowchart TB
    R[발견된 위험]

    A[위험 수용]
    N[위험 방치]

    R --> A
    R --> N

    A --> A1[평가]
    A --> A2[승인]
    A --> A3[재평가]

    N --> N1[근거 없음]

둘은 전혀 다른 상태입니다.

17장 잔여 위험은 누가 승인해야 하는가#

원문은 잔여 위험을 권한 있는 업무 책임자가 근거를 보고 승인해야 한다고 설명합니다.

이 부분이 중요합니다.

보안 담당자가 혼자:

이 정도면 괜찮다.

라고 판단하고 끝내는 구조가 아닙니다.

왜냐하면 위험은 결국:

업무 중단
금전 손실
법적 책임
고객 피해

와 연결되기 때문입니다.

따라서 업무 영향과 책임을 가진 사람이 승인 과정에 참여해야 합니다.

18장 위험관리에서 책임자가 중요한 이유#

위험관리 문서에 다음만 적혀 있다고 하겠습니다.

DB 접근통제 강화 필요

이 문장은 실제 운영으로 이어지기 어렵습니다.

다음처럼 바뀌어야 합니다.

조치
DB 관리자 MFA 적용

담당자
인프라팀

기한
10월 31일

검증
MFA 적용 로그 및 테스트 결과

원문 역시 위험마다 통제·담당자·기한·검증 증거를 연결해야 한다고 강조합니다.

19장 위험 목록은 작업 목록이어야 한다#

좋은 위험 목록은 단순한 설명문이 아닙니다.

예:

위험 조치 담당자 기한 검증
관리자 계정 탈취 MFA 적용 보안팀 10/31 로그인 테스트
공개 저장소 접근정책 수정 인프라팀 10/20 외부 접근 테스트
백업 미검증 복원 테스트 운영팀 11/05 복원 결과 기록

이렇게 해야 실제 개선으로 이어집니다.

20장 운영 증거가 왜 중요한가#

원문은 각 단계마다 운영 증거를 제시합니다.

자산 식별#

자산 목록
데이터 흐름

위험평가#

위험 시나리오
평가 근거

위험 처리#

담당자
기한
잔여 위험 승인

모니터링#

검증 기록
위험 목록 갱신

즉:

했다.

보다:

했다는 것을 무엇으로 증명할 것인가?

가 중요합니다.

21장 실제 사례: 고객 문서 저장소 공개 위험#

원문은 고객 문서 저장소가 외부에 공개될 수 있는 상황을 사례로 제시합니다.

이를 위험관리 흐름으로 풀어보겠습니다.

flowchart TB
    A[고객 문서 저장소]
    B[외부 공개 가능성]
    C[고객 문서 유출]
    D[기밀성 피해]

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

이 경우 단순히:

스토리지 취약

이라고 적는 것으로 끝내면 부족합니다.

22장 1단계: 자산을 식별한다#

자산:

고객 문서
저장소 계정
접근 정책
스토리지 서비스

데이터 흐름:

flowchart LR
    U[고객]
    APP[애플리케이션]
    STORE[(문서 저장소)]

    U --> APP --> STORE

먼저 무엇이 어디에 저장되고 누가 접근하는지 파악합니다.

23장 2단계: 위험 시나리오를 만든다#

예:

저장소 공개 설정 오류
↓
인터넷에서 파일 접근 가능
↓
고객 문서 유출

이것이 위험 시나리오입니다.

단순한 취약점 이름보다 사고가 실제 어떻게 발생하는지를 설명하는 것이 중요합니다.

24장 3단계: 통제를 선택한다#

원문에서는 이 사례에 다음 조치를 연결합니다.

  • 데이터 분류
  • 공개 설정 차단
  • 접근로그
  • 탐지 규칙

이를 구조화하면:

flowchart LR
    R[문서 공개 위험]

    C1[데이터 분류]
    C2[공개 접근 차단]
    C3[접근로그]
    C4[탐지 규칙]

    R --> C1
    R --> C2
    R --> C3
    R --> C4

25장 예방 통제와 탐지 통제를 함께 사용한다#

예를 들어 공개 설정 차단은 예방 통제입니다.

접근로그와 탐지 규칙은 탐지 통제에 가깝습니다.

flowchart TB
    R[위험]

    PRE[예방]
    DET[탐지]
    REC[복구]

    R --> PRE
    R --> DET
    R --> REC

한 종류의 통제만으로 모든 상황을 막으려 하기보다 여러 계층으로 설계하는 편이 좋습니다.

26장 위험관리 계획의 핵심 필드#

실무적으로 위험 하나를 관리할 때 다음 항목을 연결하면 이해하기 쉽습니다.

위험 ID
자산
위협
취약점
영향
가능성
위험 수준
처리 방법
보안 통제
담당자
완료 기한
검증 방법
잔여 위험
승인자
재평가 시점

이 구조는 원문의:

통제·책임자·기한·검증 증거·잔여 위험 승인

원칙을 실제 관리 항목으로 확장한 예입니다.

27장 위험관리 순환 구조#

원문은 위험관리 흐름을 다음과 같이 제시합니다.

flowchart LR
    A["자산·데이터 흐름 식별"]
    B["가능성·영향 평가"]
    C["통제·책임자·기한 선정"]
    D["잔여 위험 승인"]
    E["효과 측정·재평가"]

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

이 그림에서 가장 중요한 화살표는 마지막:

재평가
→
자산 식별

입니다.

위험관리가 순환 구조라는 의미입니다.

28장 통제를 적용했다고 끝이 아니다#

예를 들어 MFA를 적용했다고 하겠습니다.

문서에는:

관리자 MFA 적용 완료

라고 적혀 있습니다.

하지만 실제 확인해야 할 것은:

모든 관리자 계정에 적용되었는가
우회 가능한 계정이 없는가
비상 계정은 어떻게 관리하는가
실제 로그인 테스트가 되었는가

입니다.

즉 통제 적용과 통제 효과 검증은 다른 단계입니다.

29장 시스템 변경 후 재평가가 필요한 이유#

예를 들어 처음에는:

웹서버
→
내부 DB

구조였습니다.

이후 외부 SaaS를 연동했다고 하겠습니다.

flowchart LR
    WEB[웹서버]
    DB[(내부 DB)]
    SaaS[외부 SaaS]

    WEB --> DB
    WEB --> SaaS

이제 새로운 위험이 생길 수 있습니다.

  • 외부 API 인증
  • 데이터 전송
  • 공급업체 장애
  • 제3자 접근
  • 계약상 책임

따라서 시스템 구조가 변하면 위험평가도 갱신해야 합니다.

30장 사고가 발생한 뒤에도 위험평가를 다시 해야 한다#

사고는 기존 위험평가가 틀렸거나 부족했다는 신호일 수 있습니다.

flowchart LR
    A[보안 사고]
    B[원인 분석]
    C[기존 위험평가 검토]
    D[통제 개선]
    E[위험 목록 갱신]

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

따라서 사고 대응과 위험관리는 분리된 활동이 아닙니다.

31장 위험관리에서 흔히 발생하는 실수#

취약점 목록을 위험 목록이라고 생각한다#

CVE-XXXX
패치 미적용
약한 비밀번호

만 나열해서는 업무 영향을 알기 어렵습니다.

담당자가 없다#

조치 필요

라고만 적혀 있으면 실제 조치로 이어지지 않을 수 있습니다.

완료 기한이 없다#

언젠가 하겠다는 작업은 장기간 남을 가능성이 높습니다.

검증 방법이 없다#

작업자가:

완료했습니다.

라고 말하면 끝나는 구조가 됩니다.

잔여 위험 승인이 없다#

통제를 적용한 뒤 남은 위험을 누가 책임지는지 불명확해집니다.

32장 위험관리 문서를 의사결정 도구로 사용해야 한다#

위험관리 문서는 감사 대응용 문서만이 아닙니다.

실제로는 다음 의사결정을 지원해야 합니다.

무엇부터 고칠 것인가

얼마나 투자할 것인가

어떤 위험은 수용할 것인가

어떤 서비스를 중단할 것인가

어떤 위험을 외부와 분담할 것인가

즉 위험관리의 최종 목적은 보안 문제를 업무 우선순위와 연결하는 것입니다.

33장 위험 우선순위를 정할 때 중요한 것#

위험 수가 많아지면 모든 문제를 동시에 해결할 수 없습니다.

따라서 다음을 함께 봐야 합니다.

발생 가능성
업무 영향
조치 비용
조치 기간
규제·계약 영향
의존 시스템

원문은 기본적으로 가능성과 업무 영향을 중심으로 위험을 판단하며, 실제 처리 단계에서 책임자와 기한까지 연결하도록 구성하고 있습니다.

34장 위험관리 단계별 핵심 질문#

자산 식별#

무엇을 보호해야 하는가?

위험평가#

어떤 사고가 발생할 수 있고 얼마나 큰 피해가 나는가?

위험 처리#

줄일 것인가, 피할 것인가, 전가할 것인가, 수용할 것인가?

잔여 위험 승인#

통제 이후 남은 위험을 누가 책임질 것인가?

모니터링#

통제가 실제로 효과가 있으며 상황이 바뀌지 않았는가?

이 다섯 질문만 기억해도 전체 구조를 이해하기 쉽습니다.

정보보안 위험관리 FAQ#

정보보안 위험관리란 무엇인가#

자산에 발생할 수 있는 사고와 그 가능성·업무 영향을 평가하고, 조직이 감당 가능한 수준으로 위험을 처리하는 반복적인 관리 활동입니다.

자산에는 서버만 포함되는가#

아닙니다. 원문에서는 데이터·계정·외부 서비스·업무 의존관계까지 자산 범위에 포함합니다.

고유 위험이란 무엇인가#

보안 통제를 적용하기 전의 위험입니다.

잔여 위험이란 무엇인가#

통제를 적용한 뒤에도 남아 있는 위험입니다. 원문에서는 잔여 위험을 권한 있는 업무 책임자가 근거를 확인하고 승인해야 한다고 설명합니다.

위험 처리 방법에는 무엇이 있는가#

원문에서는 위험 감소·회피·전가·수용을 제시합니다.

위험 전가를 하면 책임이 없어지는가#

아닙니다. 보험이나 계약을 통해 손실을 분담할 수 있지만 예방 책임이 모두 없어지는 것은 아니라고 원문에서 설명합니다.

위험 수용은 아무것도 하지 않는 것인가#

아닙니다. 수용 근거, 손실 범위, 승인자, 재평가 조건을 기록한 의사결정입니다.

위험관리 문서에는 무엇이 포함되어야 하는가#

원문 기준으로 자산·데이터 흐름, 위험 시나리오와 평가 근거, 통제·담당자·기한, 잔여 위험 승인, 검증 기록과 갱신된 위험 목록이 중요합니다.

위험평가는 언제 다시 해야 하는가#

시스템 변경이나 보안 사고 이후 다시 평가해야 합니다.

핵심 정리#

정보보안 위험관리의 전체 흐름은 다음과 같습니다.

flowchart LR
    A[자산 식별]
    B[위험 평가]
    C[위험 처리]
    D[잔여 위험 승인]
    E[모니터링·재평가]

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

각 단계의 핵심은 다음과 같습니다.

자산 식별
→ 무엇을 보호할 것인가

위험평가
→ 무엇이 얼마나 위험한가

위험 처리
→ 감소·회피·전가·수용 중 무엇을 선택할 것인가

잔여 위험 승인
→ 남은 위험을 누가 책임질 것인가

모니터링
→ 통제가 실제 효과가 있는가

원문이 강조하는 가장 중요한 포인트는 위험관리에서 취약점 목록만 만드는 것으로 끝내지 말아야 한다는 것입니다.

실제로 관리 가능한 위험은 다음과 같이 표현되어야 합니다.

위험
+
통제
+
담당자
+
완료 기한
+
검증 증거
+
잔여 위험
+
승인자

그리고 시스템이나 업무가 바뀌면 다시 처음으로 돌아가야 합니다.

flowchart TB
    CHANGE[시스템 변경·사고]
    REVIEW[위험평가 갱신]
    CONTROL[통제 조정]
    VERIFY[효과 검증]

    CHANGE --> REVIEW --> CONTROL --> VERIFY
    VERIFY --> REVIEW

정보보안 위험관리의 핵심은 위험을 완전히 없애는 것이 아니라 무엇이 위험한지 알고, 필요한 통제를 적용하고, 남은 위험을 근거 있게 승인하며, 변화가 생길 때 다시 평가하는 것입니다.

이 페이지의 목차