공공기관 N2SF 보호 범위 점검: 개발·백업 데이터를 살펴야 하는 이유
2026.11.11목차
국내 ERP(전사적 자원관리) 업체에서 개발서버의 비인가 접속·조회와 외부 백업 데이터 반출 정황이 확인됐습니다. 공공기관도 업무정보를 개발·복구용 사본으로 보관한다면, 운영시스템 밖의 데이터까지 보호 범위에 포함돼 있는지 돌아볼 사례입니다.
이번 글에서는 민간 침해 사례를 출발점으로 공공기관이 N2SF를 적용할 때 개발·백업 데이터의 보호 범위를 어떻게 식별하고 운영 상태를 확인할지 살펴봅니다. 국가 망 보안체계(N2SF)는 국가·공공기관의 업무정보 중요도와 시스템 환경에 맞춰 보안통제를 적용하는 체계입니다.
1. 국내 ERP 업체의 개발서버·외부 백업 침해 정황
VPN 비인가 접속·조회와 암호화된 백업 데이터 반출 정황
국내 ERP 업체의 개발서버에서 비인가 접속·데이터 조회 정황이 확인됐습니다. 업체 설명에 따르면, 개발서버 공격 징후를 조사하던 중 2026년 10월 15일 가상사설망(VPN) 계정을 통한 비인가 접속·데이터 조회 기록 등의 정황을 확인했고, 해당 계정 차단과 VPN 기능 비활성화 조치를 취했습니다. 정확한 유출 발생일과 최종 영향 대상·반출 범위는 당시 조사 중이었습니다.
이와 별도로, 외부 백업서비스에서도 일부 암호화 데이터가 외부로 반출된 정황이 확인됐습니다. 해당 업체는 백업 솔루션 제공사로부터 취약점 존재를 통보받은 뒤, 내부조사에서 그 취약점을 통한 반출 정황을 확인했다고 밝혔습니다. 암호화 키 유출 정황은 발견되지 않았다는 회사 입장입니다. 정확한 유출 발생일과 영향 범위 역시 당시 조사 중이었습니다.
2. 민간 침해 사례를 공공기관의 N2SF 점검에 연결하는 이유
N2SF 보호대상 식별: 외부 서비스의 데이터 위치와 접근 주체
이번 사례에서 공공기관이 돌아볼 대목은 개발·백업 데이터의 운영 방식입니다. 기관도 업무정보를 시험용으로 복사하거나 외부 서비스에 백업한다면, 운영시스템의 보호 상태만으로 사본의 안전성까지 판단하기는 어렵습니다. 이때 N2SF는 기관 내부와 외부 서비스에 걸친 보호 범위를 검토하는 틀이 됩니다.
N2SF 가이드라인의 활동-1-4는 연동된 외부 정보서비스도 함께 식별하도록 설명합니다. 부록2의 외부 클라우드 업무협업 모델은 위치·주체·객체를 분석하고 위협과 요구사항에 맞는 통제를 선택하되, 기관 특성에 맞춰 검토·적용하도록 안내합니다.
이를 ‘서비스·연계 식별 → 데이터 위치·접근 주체 확인 → 등급·위협별 통제 검토 → 설정·로그로 결과 확인’으로 정리할 수 있습니다. 이 관계를 파악해야 외부에 맡긴 데이터까지 포함해 필요한 보호 조치를 검토할 수 있습니다.
위치와 접근 주체를 확인했다면, 사본을 보관하는 목적도 함께 살펴볼 차례입니다. 같은 업무정보라도 테스트에 쓰는 사본과 장애 복구를 위해 남긴 백업본은 필요한 접근 범위와 관리 책임이 다르기 때문입니다.
3. 개발용 사본과 복구용 백업, 이용 목적에 따라 달라지는 보호 기준
테스트 데이터의 보관 기한과 삭제 책임
기관의 업무정보를 테스트에 사용하기 전에는 대체 데이터로 같은 시험이 가능한지 판단합니다. 실제 업무정보를 복사한다면 이용 목적과 보관 기한, 삭제 담당자를 정합니다. 테스트가 끝난 뒤에도 사본이 남을 수 있기 때문입니다.
💡용어 정리: 테스트용 사본과 복구용 백업본
• 테스트용 사본: 기능 검증이나 시험을 위해 복사한 데이터입니다. 시험에 필요한 정보와 보관 기간을 기준으로 관리합니다.
• 복구용 백업본: 장애·사고 뒤 복구를 위한 사본입니다. 테스트용 사본과 이용 목적·복구 역할을 구분해 점검합니다.
백업 데이터 암호화, 암호키 접근과 복구 책임까지 확인하기
외부 백업 데이터의 반출 정황에서 구분해볼 것은 데이터가 반출됐는지와, 반출된 데이터를 해독할 수 있는지입니다. 암호화돼 있다는 설명은 반출 여부에 대한 답과 같지 않습니다. 따라서 백업본의 내부·외부 보관 위치와 관리 주체뿐 아니라, 복구에 필요한 암호키의 관리 책임도 함께 살펴야 합니다.
외부 백업은 내부 담당자와 공급사 중 누가 복구를 요청·실행하고 결과를 확인할지 정해둡니다. 역할을 정했다면 실제 계정 권한에도 반영돼 있는지 살펴볼 차례입니다.
4. VPN 접속 후 데이터 접근통제: 계정별 조회·전송 권한 점검
계정에 허용한 권한과 실제 데이터 조회·전송 기록 비교
💡용어 정리:인증과 인가
• 인증: 접근하려는 주체가 누구인지 확인하는 과정
• 인가: 확인한 주체에게 어떤 데이터와 기능을 어디까지 허용할지 결정하는 과정
인증을 거쳐 접속한 계정이라도, 읽거나 내보낼 수 있는 정보의 범위까지 적절하다고 볼 수는 없습니다. 이는 VPN 접속 이후의 데이터 접근을 살펴보는 이유입니다. 계정별 조회·전송 내역을 담당자의 역할과 허용 범위에 대조하면, 설정한 권한과 실제 사용 사이의 차이를 확인할 수 있습니다.
N2SF 부록1의 LP-M4는 접근권한과 정보 접근 범위를 연계하는 원칙을 제시합니다. AC-M2·M3는 계정·세션 활동 기록을, IF-8·9는 전송 정보와 출발지·도착지 확인을 다룹니다.
사용자·서비스 계정별로 다음 항목을 확인합니다.
• 사용자·관리·서비스 계정별 실제 조회·내보내기 권한
• 허용된 접속 출발지·데이터 목적지와 예외 승인 내역
• 인증 구성, 계정·세션 활동 기록과 전송 허용·차단 기록
5. 개발·백업 데이터 점검: 설정·로그와 조치 결과 확인
데이터 위치·접근 경로를 실제 설정·로그와 대조하는 방법
앞서 살펴본 데이터 위치와 계정 권한을 실제 운영과 대조하려면, 무엇을 확인했고 어떤 차이가 있었는지 남겨둘 필요가 있습니다. 데이터 위치·접근 경로와 확인 기록을 연결해두면, 발견한 문제의 조치 여부도 이어서 확인할 수 있습니다.
• 데이터 위치 목록: 개발용 사본·백업본에 어떤 데이터가 있는지와 내부·외부 보관 위치를 적습니다.
• 접근 경로 목록: 각 위치에 접근하는 주체와 권한, 조회·전송 목적지와 허용 조건을 적습니다.
• 확인 기록: 점검 대상별 책임자와 점검일, 확인한 로그를 남깁니다. 조치한 내용과 아직 고치지 못한 항목의 개선 기한도 적습니다.
기록을 남기는 목적은 발견한 문제의 조치까지 이어가기 위해서입니다. 미사용 계정이나 불필요한 사본, 과도한 권한이 확인되면 담당자와 개선 기한을 정하고, 이후 권한 변경·삭제 기록으로 처리 결과를 확인합니다. 이렇게 정리한 데이터 위치·접근 경로·확인 기록은 사고 통보를 받았을 때도 쓰입니다. 기관이 이용하는 정보서비스 중 어떤 업무정보가 관련되는지, 어느 기간의 접근 내역을 확인할지 범위를 좁혀볼 수 있습니다. 이 확인이 사고 시점에도 가능하려면, 평소 로그 보존 범위와 담당자, 공급사의 연락 창구가 정리돼 있어야 합니다. 기관과 공급사가 확인·차단·복구를 각각 어디까지 맡을지 미리 공유해두면, 사고 통보 뒤 필요한 자료와 조치를 협의하는 데 도움이 됩니다.
6. 계정·권한과 암호키 관리, 드림시큐리티 솔루션의 지원 범위
Magic ICAM·Magic KMS 연계 시 확인할 기능과 적용 조건
계정 회수와 권한 변경, 암호키 관리를 실제 운영에 반영하는 과정에는 관련 솔루션을 활용할 수 있습니다. 다만 지원 기능이 있다는 설명과 기관의 대상 시스템에서 실제로 동작하는지는 구분해 살펴볼 문제입니다.
드림시큐리티의 Magic ICAM은 사용자·기기·자원의 신원과 자격증명, 접근 권한을 통합 관리하는 제로트러스트 기반 솔루션입니다. 인사정보와 연계한 계정 생성·회수, 정기 권한 검토를 지원합니다. 기관에 적용할 때 확인할 것은 대상 시스템에 반영된 결과입니다. 계정 회수나 권한 변경을 요청한 기록과 실제 처리 결과를 대조하면, 정한 관리 기준이 운영에 반영됐는지 살펴볼 수 있습니다.
Magic KMS는 암호키의 생성·갱신·백업·복구·폐기 등 생명주기를 관리하는 통합 암호키 관리 솔루션입니다. 백업·복구 대상은 업무 데이터가 아닌 암호키입니다. 메인 시스템 뿐 아니라 개발·백업 시스템의 암호키도 키 소유자 또는 키 이용장치에 대한 식별 및 인증 등 접근 제어를 통해 안전한 키 관리를 수행합니다.
7. FAQ: 개발·백업 데이터 보호에 관한 자주 묻는 질문
Q1. 백업 데이터가 암호화됐다면 유출 위험은 없나요?
A1. 암호화와 반출 여부는 별개입니다. 키 유출 정황이 없더라도 안전성을 확정할 수는 없으며, 키 접근 조건과 조사 결과를 함께 살펴야 합니다.
Q2. VPN이나 다중요소 인증(MFA)을 쓰면 개발·백업 데이터 점검은 끝나나요?
A2. 끝나지 않습니다. 인증 구성을 확인한 뒤에는 그 계정이 어떤 데이터를 읽고 어디로 보낼 수 있는지도 살펴야 합니다. VPN이나 MFA 같은 특정 수단만으로 사고 예방을 보장할 수는 없습니다.
Q3. N2SF를 적용하면 개발·백업 데이터의 사고 위험도 해소되나요?
A3. N2SF 적용만으로 사고 예방이 보장되지는 않습니다. 기관의 개발·백업 데이터와 외부 연계가 보호대상에 포함됐는지, 필요한 통제가 실제로 구현·운영되고 있는지 확인해야 합니다.
8. 결론: 보호 기준은 데이터의 중요도와 이용 목적
기관의 정보서비스 하나부터 시작하는 데이터·권한 점검
이번 사례가 공공기관에 남기는 질문은 운영시스템 밖에 보관한 업무정보까지 보호 범위에 포함돼 있느냐는 것입니다. 개발용 사본과 백업본은 용도가 다르지만, 담긴 정보의 중요도에 맞는 보호가 필요하다는 점은 같습니다. N2SF의 보호대상 식별과 통제 검토는 이러한 사본과 외부 연계의 보호 상태를 살펴보는 데 활용할 수 있습니다.
출발점은 기관의 정보서비스 하나면 됩니다. 그 서비스의 개발·백업 사본과 접근 계정, 내부 담당자와 공급사의 역할을 정리해 실제 설정·기록과 대조합니다. 차이가 발견되면 담당자와 기한을 정해 조치 결과를 확인하고, 다음 점검에 반영합니다. 업무나 연계 서비스가 바뀔 때 이 기록을 함께 갱신하면, 한 번의 점검을 이후 운영으로 이어갈 수 있습니다.
※ 본 글은 국가 망 보안체계(N2SF) 보안 가이드라인과 국가 사이버보안 기본지침의 주요 내용을 이해하기 쉽게 정리한 참고 자료입니다. 실제 적용 여부와 대응 방안은 본 글만으로 판단하지 말고 최신 지침·가이드라인의 원문과 국가정보원 안내를 확인한 뒤 구체적인 사안에 대해서는 보안·법률 전문가의 검토를 거쳐 판단하시기 바랍니다.
출처
• 국가정보원 — 「국가 망 보안체계 보안 가이드라인 1.0」 본문, 2025.9., 활동-1-4, PDF 39쪽(인쇄 38쪽). 공식 배포 게시글: https://www.ncsc.go.kr:4018/main/cop/bbs/selectBoardArticle.do?bbsId=Notification_main&nttId=218022&menuNo=null&subMenuNo=010300&thirdMenuNo=
• 국가정보원 — 「국가 망 보안체계 보안 가이드라인 1.0 — 부록2 정보서비스 모델 해설서 모델3 외부 클라우드 활용 업무협업 체계」, 2025.9., PDF 8~9쪽(인쇄 7~8쪽). 국립목포대학교 재게시: https://mnuk2.mokpo.ac.kr/bbs/mnusecu/1544/250572/download.do
• 국가정보원 — 「국가 망 보안체계 보안 가이드라인 1.0 — 부록1 보안통제 항목 해설서」, 2025.9., PDF 6·35·65쪽(인쇄 5·34·64쪽). 국립목포대학교 재게시: https://mnusecu.mokpo.ac.kr/bbs/mnusecu/1544/250570/download.do
• 국가정보원 — 「국가 사이버보안 기본지침」, 2026-05-01 개정, 제39조의3~5, PDF 59~60쪽(인쇄 45~46쪽). https://www.ncsc.go.kr/template/resources/file/nis_guide_lines_2023_1_31.pdf
