전자금융기반시설 취약점 분석평가, 인프라 팀이 미리 준비하면 좋은 것들
핵심 요약: 전자금융기반시설 취약점 분석평가는 총자산 2조 원 이상, 종업원 300명 이상 금융회사에 연 1회 의무예요. 자체전담반(5인 이상, 30% 고급 기술인력)을 구성하거나 외부 전문기관에 위탁할 수 있어요. 평가를 "통과"하려면 네트워크 분리, 접근통제(PAM/MFA), 로그 5년 보관, 암호화(TLS 1.2+/AES-256/HSM)를 인프라 설계 단계부터 반영해야 해요. 결과보고서와 보완조치 이행계획서는 30일 내 금융위원회에 제출해야 해요.
취약점 분석평가를 '연례 행사'로 대하는 순간, 진짜 보안 사고가 터졌을 때 대응할 수 없어요. 평가 시점에 급하게 준비하면 미흡 사항이 쏟아지고, 보완 조치 기한에 쫓기게 돼요.
취약점 평가는 건물 정기 안전점검과 같아요. 평소에 관리를 잘 해두면 점검 때 보완 사항이 적고, 방치하면 대공사가 필요해져요. 인프라 팀이 설계 단계부터 평가 항목을 반영해두면, 평가 시점에는 증적 수집과 형식적 절차만 남게 돼요.
이전 글에서 전자금융감독규정의 기술 요건과 FDS 아키텍처를 다뤘어요. 이번에는 인프라 팀이 취약점 분석평가를 대비해서 미리 설계하고 구축해야 하는 것들을 정리할게요.
취약점 분석평가는 누가, 언제 해야 하나요
전자금융감독규정 제37조의2에 따라, 금융회사와 전자금융업자는 전자금융기반시설에 대해 정기적으로 취약점 분석·평가를 수행해야 해요.
평가 대상과 주기는 기관의 규모에 따라 달라요.
| 구분 | 대상 기준 | 평가 주기 |
|---|---|---|
| 대형 금융회사 | 총자산 2조 원 이상 또는 종업원 300명 이상 | 연 1회 |
| 중소형 금융회사 | 위 기준 미만 | 2년에 1회 |
| 홈페이지 | 모든 금융회사 | 6개월에 1회 |
여기서 "전자금융기반시설"이란 전자금융거래법 제2조 제21호에 정의된 것으로, 전자금융거래에 이용되는 정보처리시스템, 통신설비, 전산실 등을 포함해요. 단순히 서버만이 아니라 네트워크 장비, 보안장비, DB, 애플리케이션까지 모두 평가 범위에 들어가요.
운영하면서 계속 느낀 건, 평가 주기보다 더 중요한 건 "평가 시점에 증적을 얼마나 빠르게 모을 수 있느냐"라는 거예요. 평소에 로그가 체계적으로 관리되고, 접근통제 정책이 문서화되어 있으면 평가 준비 기간이 2–3주면 충분해요. 그렇지 않으면 2–3개월이 걸려요.
자체전담반 구성 요건과 현실적 대안
취약점 분석평가를 수행하려면 자체전담반을 구성하거나, 외부 평가전문기관에 위탁해야 해요.
자체전담반 구성 요건은 다음과 같아요.
| 요건 | 기준 |
|---|---|
| 인원 | 5인 이상 |
| 고급 기술인력 비율 | 전체의 30% 이상 |
| 고급 기술인력 자격 | 정보보호 관련 기사 자격증 + 실무 3년, 또는 석사 + 실무 1년, 또는 실무 경력 7년 이상 |
| 독립성 | 평가 대상 시스템의 개발·운영 담당자가 아닌 인력 |
현실적으로 5인 이상의 독립적인 보안 전문 인력을 상시 보유하기 어려운 조직이 많아요. 이 경우 두 가지 대안이 있어요.
첫째, 외부 위탁이에요. 정보보호 전문서비스 기업으로 지정된 업체에 위탁할 수 있어요. 금융보안원이 인정하는 평가전문기관 목록은 매년 갱신돼요. 위탁 시에도 내부에서 평가 결과를 검토하고 보완 조치를 이행할 담당자는 지정해야 해요.
둘째, 혼합 구성이에요. 내부 인력 일부 + 외부 전문가를 조합해서 전담반을 구성하는 방식이에요. 이 경우에도 30% 고급 기술인력 요건은 충족해야 해요.
실무에서 자주 놓치는 부분이 "독립성" 요건이에요. 해당 시스템을 직접 개발하거나 운영하는 사람이 평가에 참여하면 객관성이 훼손된다고 판단해요. SI/SM 체계에서 운영팀과 별도의 보안팀이 있다면 보안팀 인력을 활용하는 게 일반적이에요.
평가 범위는 어디까지인가요
평가 대상은 전자금융기반시설 전체예요. 구체적으로는 다음 영역을 포함해요.
| 평가 영역 | 점검 항목 예시 |
|---|---|
| 서버 | OS 패치 현황, 불필요 서비스 제거, 계정 관리, 파일 권한 |
| 네트워크 | 방화벽 정책, 망분리 적정성, VLAN 설계, IDS/IPS 운영 |
| 데이터베이스 | 접근통제, 암호화 적용, 감사 로그, 백업/복구 |
| 애플리케이션 | OWASP Top 10, 인증/인가, 세션 관리, 입력값 검증 |
| 보안장비 | 정책 최신화, 로그 수집, 장비 이중화, 펌웨어 업데이트 |
| 정보보호시스템 | DLP, DRM, NAC, 백신 운영 현황 |
여기서 트레이드오프가 발생해요. 전수 평가를 하면 완전성은 높아지지만 비용과 기간이 크게 늘어나요. 현실적으로는 위험도 기반 접근(Risk-based Approach)을 적용해서, 핵심 시스템부터 우선 평가하고 나머지는 샘플링으로 커버하는 전략을 쓰는 경우가 많아요.
금융보안원의 취약점 평가 가이드에서도 자산 중요도 분류를 먼저 수행하고, 중요도가 높은 자산에 대해 심층 평가를 권고하고 있어요. 평가 소요 기간은 대형 금융사 기준으로 보통 2–3개월이에요. 발견되는 취약점은 평균 50–100건 수준이고, 이 중 고위험 항목이 10–20% 정도를 차지해요.
네트워크 분리 설계 (DMZ, 내부망, 개발망)
취약점 평가에서 가장 먼저 확인하는 항목이 네트워크 분리 적정성이에요. 전자금융감독규정 제15조는 금융회사의 내부 통신망을 업무 목적에 따라 분리할 것을 요구하고 있어요.
한국 금융권의 망분리는 단순한 VLAN 분리가 아니라, 물리적 또는 논리적으로 완전히 격리된 네트워크를 의미해요. 해외에서는 마이크로세그멘테이션으로 충분한 경우가 많지만, 국내 금융 규제는 더 엄격한 수준을 요구해요.
각 구간별 설계 원칙을 정리하면 이래요.
| 구간 | 설계 원칙 | 허용 트래픽 |
|---|---|---|
| DMZ | 외부 접점 최소화, WAF/IPS 필수 배치 | 인바운드 HTTPS만 허용, 내부망 직접 접근 차단 |
| 내부망 | 코어 시스템 격리, DB 접근은 애플리케이션 서버만 허용 | 화이트리스트 기반 방화벽 정책 |
| 개발망 | 운영 데이터 접근 차단, 테스트 데이터만 사용 | 내부망으로의 직접 접근 차단, 배포 파이프라인만 허용 |
실수하기 쉬운 부분이 있어요. 개발망에서 운영 DB에 직접 접속하는 경로가 남아있는 경우가 의외로 많아요. 개발 편의를 위해 열어둔 포트가 평가 시점에 지적 사항이 되는 거예요. 인프라 설계 단계에서 개발망 → 내부망 경로를 원천 차단하고, 배포는 CI/CD 파이프라인을 통해서만 가능하도록 설계해야 해요.
접근통제와 특권 계정 관리
접근통제는 취약점 평가에서 지적 빈도가 가장 높은 영역 중 하나예요. 특히 특권 계정(root, admin, DBA 등)의 관리 수준이 평가의 핵심 포인트예요.
전자금융감독규정 제13조는 정보처리시스템에 대한 접근권한을 업무 수행에 필요한 최소한으로 부여하고, 업무 변경 시 즉시 변경·말소할 것을 요구해요.
특권 계정 관리(PAM, Privileged Access Management)는 다음 요소를 포함해야 해요.
| 통제 항목 | 구현 방법 | 평가 시 확인 사항 |
|---|---|---|
| 계정 분리 | 개인별 고유 계정 발급, 공용 계정 사용 금지 | 공용 계정 존재 여부, 퇴직자 계정 잔존 여부 |
| 다중 인증 | 특권 계정 접근 시 MFA 필수 적용 | MFA 미적용 계정 존재 여부 |
| 세션 녹화 | 특권 세션 전체 녹화 및 6개월 이상 보관 | 녹화 누락 구간 존재 여부 |
| 비밀번호 정책 | 90일 주기 변경, 복잡도 요건 충족 | 미변경 계정 존재 여부 |
| 접근 승인 | 사전 승인 후 접근, 긴급 시 사후 승인 절차 | 미승인 접근 이력 존재 여부 |
처음엔 서버마다 개별적으로 계정을 관리했는데, 서버가 수백 대로 늘어나면서 이 방식이 한계에 부딪혔어요. PAM 솔루션을 도입하면 중앙에서 모든 특권 계정의 생명주기를 관리할 수 있어요. 국내에서는 CyberArk, 이글루코퍼레이션의 SPiDER TM, 시큐어가드의 SAC 등이 금융권에서 많이 사용돼요.
MFA는 선택이 아니라 필수예요. 금융감독원 IT 검사에서도 특권 계정에 MFA가 적용되지 않은 경우 즉시 지적 사항으로 분류해요. OTP 토큰, 인증서 기반, 생체인증 중 최소 하나를 적용해야 해요.
로그 관리 체계 (5년 보관, 위변조 방지)
전자금융감독규정 제11조는 전자금융거래 관련 기록을 5년간 보존할 것을 요구해요. 단순히 "로그를 남긴다"가 아니라, 위변조 방지와 무결성 검증이 가능한 형태로 보관해야 해요.
로그 관리 체계를 설계할 때 고려해야 할 요소를 정리하면 이래요.
| 요소 | 요구사항 | 구현 방법 |
|---|---|---|
| 보관 기간 | 최소 5년 | 핫 스토리지(1년) + 콜드 스토리지(4년) 계층화 |
| 위변조 방지 | 로그 원본의 무결성 보장 | WORM 스토리지, 해시 체인, 디지털 서명 |
| 접근통제 | 로그 삭제/수정 권한 분리 | 로그 관리자와 시스템 관리자 역할 분리 |
| 수집 범위 | 모든 전자금융거래 관련 시스템 | 중앙 집중 로깅(SIEM) 구축 |
| 검색 가능성 | 감독 검사 시 즉시 조회 가능 | 인덱싱, 검색 엔진 연동 |
5년이라는 보관 기간은 생각보다 큰 스토리지 비용을 발생시켜요. 대형 금융사의 경우 일일 로그 발생량이 수 TB에 달하기 때문에, 계층형 스토리지 전략이 필수예요.
원인을 추적한 끝에 발견한 건, 많은 조직이 "로그를 남기고 있다"와 "로그를 관리하고 있다"를 혼동한다는 거예요. 로그가 있어도 검색이 안 되거나, 무결성을 증명할 수 없으면 평가에서 미흡 판정을 받아요.
WORM(Write Once Read Many) 스토리지는 한 번 기록된 데이터를 수정하거나 삭제할 수 없게 만드는 기술이에요. AWS의 S3 Object Lock, OCI의 Immutable Storage가 클라우드 환경에서 활용 가능한 옵션이에요. 온프레미스 환경에서는 NetApp SnapLock이나 전용 WORM 어플라이언스를 사용해요.
SIEM(Security Information and Event Management) 구축 시에는 Splunk, IBM QRadar, 이글루코퍼레이션의 SPiDER TM이 국내 금융권에서 주로 사용돼요. 로그 수집 에이전트를 모든 대상 시스템에 배포하고, 중앙 서버에서 정규화·상관분석을 수행하는 구조예요.
암호화 설계 (전송/저장/키관리)
전자금융감독규정 제32조는 전자금융거래 정보의 암호화를 요구해요. 암호화는 전송 구간, 저장 구간, 키 관리 세 영역으로 나눠서 설계해야 해요.
| 영역 | 요구사항 | 권장 기준 |
|---|---|---|
| 전송 구간 | 이용자 구간 및 내부 통신 암호화 | TLS 1.2 이상 (TLS 1.3 권장) |
| 저장 구간 | 개인정보, 인증정보, 거래정보 암호화 | AES-256 이상 |
| 키 관리 | 암호화 키의 안전한 생성·보관·폐기 | HSM(Hardware Security Module) 사용 |
전송 구간 암호화에서 주의할 점은 내부망 통신도 암호화 대상이라는 거예요. "내부망이니까 평문으로 통신해도 된다"는 생각은 평가에서 바로 지적돼요. 내부 서비스 간 통신에도 mTLS(mutual TLS)를 적용하는 게 안전해요.
저장 구간 암호화는 DB 레벨 암호화(TDE, Transparent Data Encryption)와 애플리케이션 레벨 암호화를 구분해야 해요. TDE는 디스크 도난에 대한 방어이고, 애플리케이션 레벨 암호화는 DB 관리자로부터도 데이터를 보호해요. 금융 환경에서는 두 가지를 모두 적용하는 게 일반적이에요.
HSM은 암호화 키를 하드웨어 내부에서 생성하고, 외부로 키가 노출되지 않도록 보호하는 장비예요. 소프트웨어 기반 키 관리(KMS)보다 보안 수준이 높지만, 비용과 운영 복잡도도 높아요.
| 키 관리 방식 | 보안 수준 | 비용 | 적합한 환경 |
|---|---|---|---|
| 소프트웨어 KMS | 중간 | 낮음 | 비금융, 개발/테스트 환경 |
| 클라우드 HSM | 높음 | 중간 | 클라우드 기반 금융 서비스 |
| 온프레미스 HSM | 매우 높음 | 높음 | 코어뱅킹, 인증서 발급 |
실무에서 겪었던 문제 중 하나가 키 로테이션이에요. 암호화 키를 주기적으로 교체해야 하는데, 교체 시 기존 데이터의 재암호화 부하가 상당해요. 설계 단계에서 키 버전 관리 체계를 잡아두지 않으면, 나중에 키 교체가 사실상 불가능해지는 상황이 발생해요.
AWS 환경에서는 CloudHSM, OCI 환경에서는 Vault를 활용할 수 있어요. 멀티클라우드 환경이라면 Thales Luna HSM처럼 클라우드 독립적인 HSM을 고려하는 것도 방법이에요.
평가 결과 보완 조치 대응 전략
취약점 분석평가가 끝나면 결과보고서와 보완조치 이행계획서를 작성해서 30일 이내에 금융위원회(금융감독원 경유)에 제출해야 해요.
보완 조치 대응은 다음 절차로 진행돼요.
결과보고서에는 발견된 취약점의 위험도 분류, 영향 범위, 권고 조치사항이 포함돼요. 보완조치 이행계획서에는 각 취약점별 조치 방법, 담당자, 완료 예정일을 명시해야 해요.
여기서 주의할 점은 "이행 기한"이에요. 고위험 취약점은 즉시 조치가 원칙이고, 중위험은 3개월 이내, 저위험은 6개월 이내가 일반적인 기준이에요. 기한 내 조치가 어려운 경우에는 위험 수용(Risk Acceptance) 절차를 밟아야 하는데, 이 경우 경영진의 승인이 필요해요.
실제 프로젝트에서는 평가 결과를 받은 후 보완 조치에 들어가면 이미 늦어요. 인프라 설계 단계에서 평가 항목을 반영해두면, 평가 결과에서 나오는 지적 사항이 "설정 미비" 수준에 그치게 돼요. 아키텍처 자체를 바꿔야 하는 지적이 나오면 보완 기간이 6개월 이상으로 늘어나요.
ISMS-P 인증을 이미 받은 조직이라면 취약점 평가와 중복되는 통제항목이 상당해요. ISMS-P의 "2.6 접근통제", "2.7 암호화 적용", "2.9 시스템 및 서비스 보안관리" 영역이 전자금융감독규정의 취약점 평가 항목과 겹쳐요. 클라우드 환경에서 ISMS-P 인증을 준비하는 방법에서 다룬 통제항목 매핑을 참고하면 두 인증을 통합 관리할 수 있어요. MySQL Enterprise vs Community 보안 비교에서 다룬 DB 암호화 옵션도 저장 구간 암호화 설계에 참고할 수 있어요.
핵심 요약
- 전자금융기반시설 취약점 분석평가는 총자산 2조 원 이상, 종업원 300명 이상 금융회사에 연 1회 의무예요
- 자체전담반은 5인 이상, 30% 고급 기술인력으로 구성하거나 외부 전문기관에 위탁할 수 있어요
- 네트워크 분리(DMZ/내부망/개발망), 접근통제(PAM/MFA), 로그 5년 보관(WORM/SIEM), 암호화(TLS 1.2+/AES-256/HSM)가 핵심 평가 항목이에요
- 인프라 설계 단계부터 평가 항목을 반영하면 평가 준비 기간을 2–3주로 단축할 수 있어요
- 결과보고서와 보완조치 이행계획서는 평가 완료 후 30일 내 금융위원회에 제출해야 해요
- ISMS-P와 중복되는 통제항목이 많으므로 통합 관리하면 효율적이에요
FAQ
Q. 전자금융기반시설 취약점 분석평가는 얼마나 자주 해야 하나요?
총자산 2조 원 이상이거나 종업원 300명 이상인 금융회사는 연 1회, 그 외 금융회사는 2년에 1회 수행해야 해요. 홈페이지는 규모와 관계없이 6개월에 1회 평가해야 해요. 전자금융감독규정 제37조의2에 근거한 의무 사항이에요.
Q. 자체전담반의 고급 기술인력 30% 요건은 어떤 자격을 의미하나요?
정보보호 관련 기사 자격증(정보보안기사, 정보처리기사 등) 보유 후 실무 3년 이상, 또는 관련 분야 석사 학위 후 실무 1년 이상, 또는 관련 실무 경력 7년 이상이 고급 기술인력의 자격 요건이에요. 5인 전담반이라면 최소 2인이 이 요건을 충족해야 해요.
Q. 취약점 평가를 외부에 위탁할 수 있나요?
가능해요. 정보보호 전문서비스 기업으로 지정된 업체에 위탁할 수 있어요. 다만 위탁하더라도 내부에서 평가 결과를 검토하고 보완 조치를 이행할 담당자는 반드시 지정해야 해요. 평가의 최종 책임은 금융회사에 있어요.
Q. 평가 결과 보완조치 기한은 얼마인가요?
결과보고서와 보완조치 이행계획서를 평가 완료 후 30일 이내에 금융위원회에 제출해야 해요. 고위험 취약점은 즉시 조치가 원칙이고, 중위험은 3개월 이내, 저위험은 6개월 이내 조치가 일반적인 기준이에요. 기한 내 조치가 어려우면 경영진 승인을 받아 위험 수용 절차를 밟아야 해요.