01. 주요정보통신기반시설
▶ 주요정보통신기반시설이란 무엇인가?
국가안보, 행정, 국방, 치안, 금융, 통신, 운송, 에너지 등 국가적 기능이 마비될 경우 국가 경제와 국민의 안전에 중대한 영향을 미칠 수 있는 정보통신체계
▶ 법적 근거 (정보통신기반 보호법 제2조)
정보통신기반 보호법 제2조(정의) 제1항 :
“정보통신기반시설”이라 함은 국가안전보장ㆍ행정ㆍ국방ㆍ치안ㆍ금융ㆍ통신ㆍ운송ㆍ에너지 등의 업무와 관련된 전자적 제어ㆍ관리시스템 및 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」제2조 제1항 제1호에 따른 정보통신망을 말한다.
- 해당 시스템이 침해될 경우 국가 기능 또는 사회·경제적 안정에 중대한 영향을 미칠 수 있는지가 중요
- 단순히 규모가 크다거나 민감 데이터가 많다는 기준이 아님
▶ 지정 대상 및 분야
| 분야 | 대표 예시 | 마비 시 영향 |
| 정보통신 | KT, SKT, 인터넷 교환망 | 전국 통신 두절 |
| 금융 | 은행 전산망, 증권거래소 | 금융거래 전면 중단 |
| 에너지 | 한전 전력망, 가스공사 | 전국 정전 · 가스 공급 중단 |
| 교통 | 철도, 항공 관제 | 교통 마비, 대형사고 |
| 보건 · 의료 | 병원 전산, 의약품 유통 | 응급 치료 불가 |
| 환경 | 수도 · 하수 처리 시스템 | 식수 오염 |
| 행정 | 주민등록, 전자정부 | 행정 서비스 전면 마비 |
| 방송 | KBS, 국가재난방송 | 재난 정보 전달 불가 |
- 관계 중앙행정기관장이 심의를 거쳐 특정 시스템을 지정함
- 지정 대상은 기관 전체가 아니라 특정 시스템 단위
→ A 은행이 지정을 받았다고 해서 A 은행의 모든 IT 시스템이 대상이 되는 건 아님
▶ 법적 강제 구조
- 가이드는 법적 구속력이 없음
- but, 관계 부처 고시에서 "KISA가 제공하는 기술적 기준을 따른다"라고 위임하고 있음
→ 가이드를 따르지 않으면 고시 위반이 되고, 고시 위반은 법령 위반으로 이어지는 구조
02. 전자금융기반시설
▶ 전자금융기반시설이란 무엇인가?
전자금융거래가 정상적으로 이루어지도록 하기 위해 필수적으로 운영되는 정보통신시스템으로, 해당 시스템이 장애·침해될 경우 금융거래의 안전성과 신뢰성이 훼손될 수 있는 기반 시설
▶ 법적 근거
전자금융거래법 제2조(정의) 21항 :
“전자금융기반시설”이란 전자금융거래에 이용되는 정보처리시스템 및 정보통신망 이용촉진 및 정보보호 등에 관한 법률」제2조 제1항 제1호에 따른 정보통신망을 말한다.
▶ 지정 대상 및 분야
| 분야 | 대표 예시 | 장애 시 영향 |
| 은행 | 계정계 시스템, 인터넷뱅킹 | 이체·조회 불가 |
| 증권 | HTS/MTS, 주문처리 시스템 | 주식 거래 중단 |
| 카드 | 승인·결제 시스템 | 결제 불가 |
| 전자금융업자 | 간편결제, PG 시스템 | 온라인 결제 마비 |
| 지급결제 인프라 | 금융결제워, 한은 지급시스템 | 금융 시스템 전체 혼란 |
- 전자금융업무를 수행하는 금융회사와 전자금융업자가 대상
→ 인터넷 거래, 모바일 뱅킹, ATM 운영, 전자결제 등 전자적 방식으로 이루어지는 금융 거래 서비스 - 금융 분야 주요정보통신기반시설로 지정되어 있고, 전자금융거래법상 전자금융기반시설 관리 의무도 있다면, 동일 기관이 두 제도의 의무를 중복으로 이행해야 함
▶ 법적 강제 구조
- 주요정보통신기반시설과 마찬가지로 가이드 자체는 법적 구속력이 없음
- but, 전자금융감독규정에서 준용됨
→ 가이드를 따르지 않으면 감독규정 위반이 되고, 감독규정 위반은 법령 위반으로 이어지는 구조
▶ 전자금융 특화 점검 영역
| 특화 영역 | 주요 점검 항목 | 관련 규정 |
| 암호화 수준 | - TLS 버전 및 암호 알고리즘 등급 - 저장 데이터 암호화 - ARIA·LEA 등 국가 승인 알고리즘 적용 |
전자금융감독규정 |
| 접근통제·인증 | - 전자금융 거래 시 이중 인증(2FA) - FDS 연동 - 관리자 계정 세분화 |
전자금융감독규정 |
| 로그·감사 추적 | - 금융 거래 로그 무결성 보장 - 로그 보존 5년 이상 - 부인방지 기능 구현 |
전자금융감독규정 제26조 |
| 재해복구(DR) | - RTO/RPO 기준 설정 및 검증 - DR 훈련 실시 및 결과 기록 |
전자금융감독규정 |
| 이용자 보호 | - 금융 거래 정보 마스킹 - 개인정보 암호화 저장 - 오류 메시지 정보 노출 최소화 |
개인정보보호법 연계 |
03. 주요정보통신기반시설 vs 전자금융기반시설
▶ 두 제도의 비교
| 구분 | 주요정보통신기반시설 | 전자금융기반시설 |
| 근거법률 | 정보통신기반 보호법 | 전자금융거래법 |
| 주관 부처 | 과학기술정보통신부, 행정안전부 등 관계 중앙행정기관 | 금융위원회 |
| 감독·점검 기관 | KISA (한국인터넷진흥원) | 금융감독원 |
| 기술 가이드 발행 | KISA (한국인터넷진흥원) | 금융보안원 |
| 적용 대상 | 8개 분야 국가 핵심 인프라 전반 | 전자금융업무를 수행하는 금융회사·전자금융업자 |
| 보고 체계 | 관계 중앙행정기관장 → KISA | 금융감독원 |
▶ 보호 목적의 차이
| 주요정보통신기반시설 | 전자금융기반시설 |
| 국가 안보·사회적 안정·공공 서비스 연속성 확보 | 금융거래의 안전성·신뢰성 확보, 이용자 자산 보호 |
| CIA Triad 중 가용성(Availability) 최우선 |
CIA Triad 중 무결성(Integrity) + 가용성(Availability) 동시 중시 → 금융 데이터가 변조되면 거래 자체의 신뢰성이 무너지니까 |
04. 취약점 진단 가이드
▶ 가이드의 목적
다양한 IT 자산(OS, DB, WEB 등)에 대해 일관된 점검 기준을 제공하여, 진단 수행자의 주관을 배제하고 객관적인 보안 수준을 측정하기 위해 존재한다.
▶ 왜 영역별로 나뉘어지는가?
1. 기술적 특성에 따른 전문적 대응 (Technological Specificity)
NW 점검 중 "Telnet 서비스 차단 여부"를 확인할 때
→ 라우터·방화벽의 ACL 룰셋 확인
OS 점검 중 "Telnet 데몬 실행 여부"를 확인할 때
→ systemctl 또는 /etc/inetd.conf에서 서비스 활성화 여부 확인
동일하게 "Telnet 차단"이라는 목적이지만, 점검 대상·명령어·판단 기준이 전혀 다름
- IT 시스템은 계층적(Layer) 구조로 되어 있고, 각 계층에서 발생하는 취약점의 원인과 점검 방식이 다름
- NW 취약점은 방화벽 룰·라우팅 설정 문제
- OS 취약점은 계정 설정·파일 권한 문제
- DB 취약점 : 접근 권한·감사 로그 문제
- 이것들을 하나의 체크리스트에 합쳐놓으면 점검 항목 간 맥락이 끊기고, 어떤 기술적 기준으로 판단해야하는지 혼란스러워짐
2. 관리적 책임 및 직무 분리 (Separation of Duties, SoD)
"패스워드 복잡도 미설정" 취약점이 발견됐을 때
→ OS 영역: /etc/pam.d/common-password 설정 → 시스템 운영팀 조치
→ DB 영역: Oracle의 PASSWORD_VERIFY_FUNCTION 미설정 → DBA 조치
→ 웹 영역: 애플리케이션 레벨 패스워드 정책 미적용 → 개발팀 조치
동일한 "패스워드 정책" 이슈지만 조치 주체와 방법이 다름
- 취약점을 발견했을 때, 누가 고쳐야 하는지가 불명확하면 실제로 조치가 이뤄지지 않을 수 있음
- 영역별로 가이드가 분리되어 있어야 진단 결과를 받은 관리기관이 책임 귀속을 즉시 할 수 있음
3. 점검자의 전문성과 점검도구의 영역
NW 점검 시 사용하는 것:
→ Cisco IOS CLI, show access-lists, show running-config 등
OS 점검 시 사용하는 것:
→ Linux 쉘 명령어 (find, ls -la, grep, netstat 등)
DB 점검 시 사용하는 것:
→ SQL 쿼리 (SELECT * FROM DBA_USERS, SHOW GRANTS 등)
현실적으로 모든 영역을 동등한 수준으로 점검할 수 있는 인력은 거의 없음
→ 영역 분리는 전문 인력을 효율적으로 배치하기 위한 구조적 설계
▶ 가이드 제작 배경 및 참조 표준
| 참조 표준 | 내용 | 어떻게 반영되었나 |
| CIS Benchmark | 미국 CIS가 만든 OS/SW별 보안 설정 기준 | 점검 항목의 기술적 기준 |
| NIST SP 800-53 | 미국 NIST의 보안 통제 카탈로그 | 통제 항목 분류 체계 |
| ISO/IEC 27001 | 국제 정보보호 관리체계 표준 | 관리적 프로세스 구조 |
| CVE/NVD | 공개 취약점 데이터베이스 | 위험도 산정 참조 |
| OWASP | 웹 취약점 TOP 10 | 웹/애플리케이션 점검 기준 |
05. 진단 핵심 용어 및 판단 로직
▶ 양호/취약 판단 (양취 판단)
- 판단 로직 : 현황과 기준을 비교하여, 기준이 제시하는 보안 수준 이하일 경우 '취약'으로 판단
- 설정값이 존재하더라도, 그 값이 기본값(Default)이거나 취약한 알고리즘을 사용중이라면 '취약'으로 간주
- 점검 항목을 적용할 수 없거나 특정 서비스를 아예 사용하지 않는 경우 해당 없음(N/A)
예시 ) 패스워드 최소 길이 설정
- 취약 판정: 패스워드 최소 길이가 8자 미만으로 설정됨 → 무차별 대입 공격에 취약하기 때문
- 양호 판정: 패스워드 최소 길이가 8자 이상으로 설정됨 → 직접 설정이 기준에 부합
- 양호 판정(보완 통제): 길이는 6자지만, OTP 이중 인증이 적용됨 → 설정값이 기준 미달이어도, 동등 이상의 보안 효과를 내는 통제가 있으면 양호
▶ 위험도 산정 기준
- 취약점이 발견되었을 때, 이를 해결하는 우선순위를 결정하기 위해 위험 등급 부여
| 위험 등급 | 산정 근거 | 의미 및 영향도 |
| 상(High) | 공격 성공 가능성이 매우 높고, 시스템 전체 권한 탈취가 가능한 경우 | 즉시 조치가 필요한 'Critical' 보안 결함 |
| 중(Medium) | 특정 조건 하에 공격이 가능하거나, 내부망 침투 후 2차 공격 수단이 되는 경우 | 단기 계획 수립 후 조치가 필요한 결함 |
| 하(Low) | 공격 난이도가 매우 높거나, 단순 정보 노출 등 피해 범위가 국소적인 경우 | 중장기적으로 개선이 필요한 설정 미흡 |
산정 공식
위험도 = 가능성(Likelihood) × 영향도(Impact)
05. 취약점 진단 프로세스
▶ 사전 준비
- 진단 목적을 명확히 하고, '무엇을, 어떻게' 점검할지 설계하는 단계
- 자산 식별 : 진단 대상이 되는 서버(OS), 데이터베이스(DB), 웹 어플리케이션(Web), 네트워크 장비(NW) 등의 리스트 작성
- 범위 정의 : 식별된 자산 중 이번에 점검할 대상을 확정(예 : 대외 서비스망 전체, 특정 금융 결제 시스템 등)
- 팀 구성 : 진단을 수행할 인력을 배치하고 업무 분장
- 계획서 수립 : 진단 일정, 점검 방식, 협조 사항을 포함한 수행 계획서 작성
▶ 진단 수행
- 가이드라인에 따라 실제 시스템의 설정 상태와 보안 약점 파악
- 인터뷰 : 관리자 대면 조사를 통해 정책 적용 여부 확인
- 도구 점검 : 자동화 스캐너(취약점 진단 툴) 등을 사용하여 자산을 빠르게 점검
- 수동 점검 : 직접 CLI(터미널)에 접근하여 가이드 항목별 설정값 확인
- 증적 수집 : '양호' 혹은 '취약'으로 판단한 근거 확보 (보고서의 객관성을 증명하는 핵심 자료)
▶ 결과 분석
- 수집된 데이터를 바탕으로 위험의 크기를 결정하고 해결책 제시
- 취약점 목록 정리 : 진단 수행 과정에서 발견된 모든 보안 결함을 항목별로 리스트업
- 위험도 산정: 발견된 취약점이 서비스에 미치는 영향력을 고려하여 상/중/하 등급 부여
- 보고서 작성 : 진단 결과 요약, 발견된 문제점, 통계 자료 등을 포함한 보고서 작성
- 조치 계획 수립 : 각 취약점을 해결하기 위한 기술적 가이드라인(조치방안)을 제시
▶ 이행 점검
- 취약점이 실제로 해결되었는지 확인하여 리스크를 최종적으로 제거하는 단계
- 조치 이행 확인 : 관리자가 보고서의 가이드에 따라 보안 설정을 변경했는지 확인
- 재점검 수행 : 취약했던 항목들이 양호로 변경되었는지 다시 한 번 진단을 실시하여 기술적으로 검증
- 잔존 위험 처리 : 시스템 영향성(가용성 문제) 등으로 인해 도저히 조치할 수 없는 항목에 대해 우회 제어를 적용하거나, 위험 수용 절차를 진행하며 마무리