정보보호가 기업의 생존과 직결되는 시대입니다. 특히 ISMS-P 인증을 준비하거나 정보보안 체계를 강화하려는 기업이라면 정보자산 위험성평가와 중요도 평가는 반드시 이해하고 실행해야 할 핵심 과제죠. 2025년 현재, 많은 기업들이 이 부분에서 어려움을 겪고 있는데요. 오늘은 실무 예시 중심으로 정보자산 위험성평가와 중요도 평가를 쉽게 설명해드리겠습니다.
Table of Contents
정보자산이란? 실제 사례로 이해하기
정보자산은 단순히 데이터만을 의미하는 게 아닙니다. 정보 그 자체는 물론, 정보를 생성하고 가공하며 저장하는 모든 설비를 포함하는 개념이에요.
쇼핑몰 A사의 정보자산 예시:
- 하드웨어: 웹서버 3대, DB서버 2대, 파일서버 1대, 백업서버 1대
- 소프트웨어: 쇼핑몰 솔루션, 결제 모듈, 주문관리 시스템
- 데이터: 회원정보 DB, 주문내역 DB, 상품정보 DB
- 네트워크: 방화벽, 침입탐지시스템(IDS), 부하분산장비
- 문서: 개인정보처리방침, 정보보호 규정, 시스템 매뉴얼
- 인력: 시스템 운영자, 개발자, 정보보호담당자
이렇게 세분화해서 목록을 만들어야 평가가 가능합니다.
정보자산 중요도 평가 실전 예시
중요도 평가는 위험평가의 첫걸음입니다. 실제로 어떻게 평가하는지 구체적인 예시를 보여드릴게요.
예시 1: 회원정보 데이터베이스 평가
자산명: 회원정보 DB 서버 (고객 이름, 연락처, 주소, 이메일 등 저장)
기밀성: 3점 (최고)
- 이유: 개인정보가 유출되면 고객 피해 발생, 과징금 부과, 기업 신뢰도 추락
- 실제 사례: B사는 개인정보 유출로 3억원 과징금 부과
무결성: 3점 (최고)
- 이유: 데이터가 변조되면 잘못된 배송, 고객 불만, 법적 분쟁 발생
- 실제 사례: 주소 정보가 잘못되어 1,000건의 오배송 발생
가용성: 3점 (최고)
- 이유: 서버 중단 시 로그인, 주문, 배송이 모두 불가능
- 실제 사례: 2시간 서비스 중단으로 3,000만원 매출 손실
법적 준거성: 3점 (최고)
- 이유: 개인정보보호법 준수 필수, 미준수 시 과징금 및 형사처벌
- 관련 법규: 개인정보보호법 제29조, 정보통신망법 제28조
총점: 12점 → VH(Very High) 등급
예시 2: 사내 공지사항 게시판 평가
자산명: 사내 공지사항 게시판 (일반 업무 공지, 회사 소식)
기밀성: 1점 (낮음)
- 이유: 대부분 공개 가능한 일반 정보
무결성: 2점 (보통)
- 이유: 변조되면 혼란이 생기지만 치명적이지 않음
가용성: 1점 (낮음)
- 이유: 잠시 중단되어도 업무에 큰 지장 없음
법적 준거성: 1점 (낮음)
- 이유: 특별한 법적 규제 없음
총점: 5점 → L(Low) 등급
예시 3: 결제 시스템 평가
자산명: 신용카드 결제 처리 시스템 (PG 연동)
기밀성: 3점 (최고)
- 이유: 카드정보 유출 시 금융사고, PCI-DSS 위반
무결성: 3점 (최고)
- 이유: 결제 금액 변조 시 금전적 손실 직접 발생
가용성: 3점 (최고)
- 이유: 결제 불가 시 매출 중단, 고객 이탈
- 실제 데이터: 10분 중단 = 약 500만원 매출 손실
법적 준거성: 3점 (최고)
- 이유: 전자금융거래법, PCI-DSS 준수 필수
총점: 12점 → VH(Very High) 등급
위험성평가 실전 사례
중요도 평가가 끝났다면 이제 본격적인 위험성평가입니다. 실제 사례로 보여드릴게요.
사례 1: 웹서버 위험평가
자산: 쇼핑몰 웹서버 (중요도: VH)
식별된 위협:
- SQL Injection 공격
- DDoS 공격
- 제로데이 취약점 공격
- 내부자의 악의적 접근
- 자연재해(화재, 침수)
현재 취약점 분석:
취약점 1: 보안 패치 미적용
- 현황: 최근 6개월간 보안 패치 미수행
- 발생가능성: 높음 (4점/5점)
- 영향도: 매우 높음 (5점/5점)
- 위험도: 4 × 5 = 20점 (치명적 위험)
취약점 2: 접근 로그 미관리
- 현황: 접근 로그를 수집하지만 분석하지 않음
- 발생가능성: 보통 (3점/5점)
- 영향도: 높음 (4점/5점)
- 위험도: 3 × 4 = 12점 (높은 위험)
취약점 3: DDoS 대응 체계 부재
- 현황: DDoS 방어 솔루션 미설치
- 발생가능성: 보통 (3점/5점)
- 영향도: 매우 높음 (5점/5점)
- 위험도: 3 × 5 = 15점 (높은 위험)
위험처리 계획:
- 즉시 조치 (위험도 15점 이상): 보안 패치 수행, DDoS 방어 솔루션 도입
- 3개월 내 조치 (위험도 10~14점): 로그 모니터링 체계 구축
- 연간 계획 수립 (위험도 9점 이하): 정기 점검 프로세스 마련
사례 2: 개인정보 DB 서버 위험평가
자산: 회원정보 DB 서버 (중요도: VH)
식별된 위협:
- 데이터베이스 해킹
- 랜섬웨어 감염
- 물리적 도난
- 내부자 유출
- 백업 실패
현재 취약점 분석:
취약점 1: 암호화 미적용
- 현황: 주민등록번호를 평문으로 저장
- 발생가능성: 높음 (4점/5점)
- 영향도: 치명적 (5점/5점)
- 위험도: 4 × 5 = 20점 (치명적 위험)
- 실제 사례: C사는 암호화 미적용으로 과징금 5억원 부과
취약점 2: 접근통제 미흡
- 현황: DB 관리자 계정 3명이 공유해서 사용
- 발생가능성: 보통 (3점/5점)
- 영향도: 매우 높음 (5점/5점)
- 위험도: 3 × 5 = 15점 (높은 위험)
취약점 3: 백업 검증 부재
- 현황: 백업은 하지만 복구 테스트를 한 적이 없음
- 발생가능성: 낮음 (2점/5점)
- 영향도: 치명적 (5점/5점)
- 위험도: 2 × 5 = 10점 (보통 위험)
- 실제 사례: D사는 랜섬웨어 공격 시 백업 복구 실패로 3일간 서비스 중단
위험처리 계획:
- 긴급 조치 (1개월 내): 개인정보 암호화 적용
- 즉시 조치 (2개월 내): 개인별 계정 분리, 접근로그 관리
- 정기 조치 (분기 1회): 백업 복구 테스트
사례 3: 클라우드 환경 위험평가
자산: AWS 클라우드 인프라 (웹서버 5대, DB 2대)
식별된 위협:
- 잘못된 보안그룹 설정
- IAM 권한 오남용
- S3 버킷 공개 설정
- 비용 폭탄
- 서비스 장애
현재 취약점 분석:
취약점 1: S3 버킷 공개 설정
- 현황: 고객 이미지 저장 S3 버킷이 Public으로 설정됨
- 발생가능성: 확실함 (5점/5점)
- 영향도: 높음 (4점/5점)
- 위험도: 5 × 4 = 20점 (치명적 위험)
- 실제 사례: E사는 S3 공개 설정으로 20만건 개인정보 노출
취약점 2: 루트 계정 사용
- 현황: 관리자가 루트 계정으로 일상 업무 수행
- 발생가능성: 높음 (4점/5점)
- 영향도: 매우 높음 (5점/5점)
- 위험도: 4 × 5 = 20점 (치명적 위험)
취약점 3: MFA 미적용
- 현황: 다단계 인증 미설정
- 발생가능성: 보통 (3점/5점)
- 영향도: 매우 높음 (5점/5점)
- 위험도: 3 × 5 = 15점 (높은 위험)
위험처리 계획:
- 즉시 조치: S3 버킷 권한 재설정, 루트 계정 사용 중단
- 1주일 내: IAM 사용자 생성 및 권한 분리, MFA 적용
- 1개월 내: CloudTrail 로그 모니터링 체계 구축
실무에서 자주 발생하는 실수와 해결책
실수 1: 클라우드 자산 식별 누락
잘못된 사례:
- 정보자산 목록에 EC2 인스턴스만 기재
- S3, RDS, CloudWatch, VPC 등 누락
올바른 사례:
- AWS 전체 리소스 스캔 도구 사용
- S3 버킷 목록, RDS 인스턴스, Lambda 함수, API Gateway 등 모두 포함
- 각 리소스별 중요도 평가 수행
실제 적용 예시 (F사):
[EC2] web-server-01 (VH 등급)
[EC2] web-server-02 (VH 등급)
[RDS] customer-db (VH 등급)
[S3] product-images (M 등급)
[S3] log-storage (L 등급)
[CloudWatch] monitoring (L 등급)
[VPC] main-vpc (H 등급)
실수 2: 개발 시스템 자산 누락
잘못된 사례:
- 운영 서버만 자산 목록에 포함
- Git, Jenkins, 테스트 서버 제외
올바른 사례:
- 개발환경도 고객 데이터를 다루므로 반드시 포함
- GitLab, Jenkins, 개발서버, 테스트서버 모두 식별
실제 사고 사례 (G사):
- 개발 서버에 실제 고객 DB를 복사해서 사용
- 개발 서버는 보안이 허술해서 해킹당함
- 50만건 고객정보 유출, 과징금 8억원
실수 3: 보안등급 평가의 비합리성
잘못된 사례 (H사):
- 고유식별정보(주민등록번호) 저장 서버: 기밀성 ‘하’ 등급
- 사내 공지사항 게시판: 기밀성 ‘상’ 등급
- 결과: 심사 시 부적합 판정
올바른 사례 (I사):
- 고유식별정보 저장 서버: 기밀성 ‘최상’ 등급
- 근거: 개인정보보호법 제24조 고유식별정보 처리 제한
- 과징금 사례: 유출 시 최대 매출액 3% 과징금
- 사내 공지사항: 기밀성 ‘하’ 등급
- 근거: 일반 업무 정보, 공개 가능
실수 4: 위험평가를 기술적 진단으로만 처리
잘못된 사례 (J사):
- 취약점 스캐너 결과만 제출
- 관리적, 물리적 위험 미평가
- 결과: 심사 시 부적합 판정
올바른 사례 (K사):
기술적 위험:
- 웹 취약점 진단 (SQL Injection, XSS 등)
- 서버 보안 패치 현황
- 네트워크 보안 설정
관리적 위험:
- 정보보호 규정 미비
- 직원 보안 교육 부족 (연 1회 미만)
- 외주 인력 계약서에 보안 조항 누락
물리적 위험:
- 서버실 출입통제 미흡 (출입카드 없음)
- CCTV 사각지대 존재
- 소화설비 점검 미실시 (2년간)
중요도별 보안대책 실전 예시
VH(Very High) 등급 자산 보안대책
대상: 고객 개인정보 DB, 결제 시스템, 핵심 업무 서버
필수 보안대책:
- 암호화: 개인정보 암호화 적용 (AES-256)
- 접근통제: IP 제한, 개인별 계정, 2단계 인증
- 로그관리: 모든 접근 로그 기록 및 3개월간 보관
- 백업: 일 1회 백업, 월 1회 복구 테스트
- 모니터링: 24시간 실시간 모니터링
- 침입탐지: IDS/IPS 설치 및 운영
실제 적용 예시 (L사):
- 투자비용: 연 3,000만원
- 효과: 개인정보 유출 사고 0건 유지 (3년간)
H(High) 등급 자산 보안대책
대상: 사내 업무시스템, 인사정보, 재무데이터
필수 보안대책:
- 접근통제: VPN 필수, 부서별 권한 분리
- 로그관리: 주요 작업 로그 기록
- 백업: 주 1회 백업
- 보안 패치: 월 1회 정기 점검
M(Medium) 이하 등급 자산 보안대책
대상: 일반 문서, 공개 정보, 개발 문서
필수 보안대책:
- 기본 접근통제: 로그인 필수
- 백업: 분기 1회 백업
- 보안 패치: 분기 1회 점검
ISMS-P 심사 시 자주 받는 질문과 답변
Q1: 작년에 위험평가를 했는데 올해도 꼭 해야 하나요? 자산 변동이 없는데요.
A: 네, 반드시 해야 합니다. 자산 변동이 없어도 위협 환경은 계속 변합니다.
실제 사례: M사는 자산 변동이 없다는 이유로 위험평가를 생략했다가 부적합 판정을 받았습니다. 그 사이 새로운 랜섬웨어가 등장했고, 보안 패치 누락으로 실제 공격을 받았습니다.
Q2: 중요도가 낮은 자산은 평가에서 제외해도 되나요?
A: 안 됩니다. 관리체계 범위 내 모든 자산을 평가해야 합니다.
실제 사례: N사는 ‘중요하지 않다’고 판단한 테스트 서버를 제외했는데, 심사에서 해당 서버에 고객 데이터가 있다는 사실이 발견되어 부적합 판정을 받았습니다.
Q3: 취약점 스캔 결과만 제출하면 안 되나요?
A: 안 됩니다. 관리적, 물리적 위험도 함께 평가해야 합니다.
심사위원이 확인하는 항목:
- 정보보호 규정이 있는가?
- 직원 보안 교육을 하는가?
- 서버실 출입통제가 되는가?
- 외주 인력 관리가 되는가?
- 비상 대응 계획이 있는가?
위험관리 연간 일정표 예시
실제로 어떻게 운영하는지 O사의 사례를 보여드립니다.
1월: 위험관리 계획 수립 및 경영진 보고
- 목표: 올해 위험평가 범위, 일정, 담당자 확정
3월: 정보자산 목록 업데이트
- 목표: 신규/변경/폐기 자산 반영
5-6월: 정기 위험평가 수행
- 목표: 전체 자산 대상 위험평가 실시
7월: 위험평가 결과 보고 및 대책 수립
- 목표: 경영진 보고, 예산 확보
8-11월: 보안대책 이행
- 목표: 고위험 항목부터 순차적으로 조치
12월: 연간 실적 평가 및 차년도 계획
- 목표: 위험감소 효과 측정, 내년 계획 수립
수시: 중요 변경 시 추가 위험평가
- 신규 시스템 도입 시
- 조직 개편 시
- 중요 보안사고 발생 시
마치며
정보자산 위험성평가와 중요도 평가는 단순히 인증을 위한 요식 행위가 아닙니다. 조직의 소중한 정보자산을 보호하고, 실제 사고를 예방하기 위한 핵심 프로세스예요.
실제 성공 사례 (P사):
- 체계적인 위험평가로 보안 투자 우선순위 명확화
- 3년간 정보보호 예산 20% 절감하면서도 보안사고 0건 달성
- ISMS-P 인증 1회 만에 통과
이 글의 예시들을 참고해서 여러분 조직의 상황에 맞게 적용해보세요. 처음에는 어렵지만, 한 번 체계를 잡아두면 매년 업데이트하는 것은 훨씬 수월해집니다.
궁금한 점이 있다면 한국인터넷진흥원(KISA) 상담센터(118)나 전문 컨설팅 기관의 도움을 받으시는 것도 좋은 방법입니다!