방구석 IT

[N2SF] N2SF 가이드 1.0 정리 본문

Tech 학습 및 정리/Network

[N2SF] N2SF 가이드 1.0 정리

펭잉 2026. 6. 1. 09:25

N2SF 가이드 1.0 요약 정리본

#첨부파일

N2SF 보안가이드라인 1.0 및 항목 해설서 + 11가지 모델 부록

N2SF 실증 사례집 (26.04.13)

N2SF 이해 및 활용 안내

1. N2SF가 왜 필요한가

N2SF를 이해할 때 가장 먼저 바로잡아야 하는 오해는 이것이 단순한 망분리 완화 정책이라는 해석이다. 실제로는 반대에 가깝다. 기존 일률적 망분리 체계가 갖고 있던 보안 효과는 유지하되, 원격근무, 클라우드, SaaS, 생성형 AI, 모바일 행정처럼 이미 현실이 된 업무환경을 감당할 수 있도록 보호 단위를 더 정밀하게 재설계하려는 시도다.

과거에는 내부망과 인터넷망을 나누는 것만으로도 외부 침투와 정보유출을 상당 부분 줄일 수 있었다. 그러나 지금은 하나의 업무 안에서도 공개자료, 내부검토자료, 개인정보, 로그, 외부 API 호출 데이터가 함께 존재한다. 또한 직원은 같은 업무를 내부 단말, 원격 단말, 모바일 단말, 외부 SaaS, 생성형 AI 서비스와 엮어서 수행한다. 이 상태에서 망을 하나로 자르기만 해서는 활용성과 보안성을 동시에 설명하기 어렵다.

그래서 N2SF는 질문 자체를 바꾼다.

  • 어느 망에 둘 것인가가 아니라 어떤 업무를 보호할 것인가.
  • 어느 시스템이 내부냐가 아니라 어떤 정보가 얼마나 중요한가.
  • 접속 자체를 막을 것인가가 아니라 어떤 등급 정보가 어떤 경로로 이동하는가.

이렇게 보면 N2SF는 보안을 낮추는 정책이 아니라 보안설계를 더 정밀하게 만드는 정책이다. 실제 핵심은 정보 중심, 업무 단위, 시나리오 기반, 차등 통제의 네 축으로 요약할 수 있다.

2. N2SF의 핵심 개념

N2SF를 제대로 이해하려면 다섯 개념을 먼저 정확히 구분해야 한다. 이 구분이 흐리면 5단계 절차도 전부 뭉개진다.

2.1 업무

업무는 기관이 수행하는 기능이다. 핵심은 부서 단위가 아니라 기능 단위라는 점이다. 같은 과 안에도 공개 업무, 내부 검토 업무, 외부협업 업무, 시스템 개발 업무가 같이 있을 수 있으므로, 최소 소기능(레벨5) 또는 단위과제(레벨6) 수준까지 잘라야 한다.

2.2 업무정보

업무정보는 해당 업무를 수행하는 데 필요한 정보이거나 그 결과로 생산되는 공공데이터다. 문서만이 아니라 입력 데이터, 조회 데이터, 첨부파일, 로그, 임시파일, 캐시, 백업, API payload까지 포함된다. 결국 최종 산출물만 보면 안 된다가 핵심이다.

2.3 정보시스템

정보시스템은 업무정보의 생성, 저장, 처리, 이동, 보관, 폐기에 관여하는 시스템 전부를 의미한다. 서버, DB, 이용자 단말, 인증체계, 연계시스템, 모바일 단말, 외부 SaaS, 생성형 AI 서비스까지 들어갈 수 있다.

2.4 정보서비스

정보서비스는 하나 이상의 정보시스템이 묶여 실제 업무를 제공하는 운영 단위다. N2SF는 이 정보서비스를 중심으로 본다. 그래서 단순 네트워크 구성도보다 누가, 어디서, 무엇으로, 어떤 정보를 다루는지가 드러나는 시나리오 정의가 중요하다.

2.5 위치-주체-객체

위협 모델링을 위해 N2SF는 정보서비스를 위치-주체-객체로 단순화한다.

  • 위치: 주체가 놓인 물리적·논리적 영역
  • 주체: 업무정보를 활용하는 정보시스템
  • 객체: 주체가 접속하거나 이용하는 대상 정보시스템

가장 많이 틀리는 부분은 주체를 사람으로 이해하는 것이다. N2SF에서 주체는 사용자 자체가 아니라 그 시나리오에서 실제로 정보서비스를 쓰는 시스템이다.

이 개념 때문에 N2SF는 언제나 서비스 전체가 아니라 시나리오별 모델로 봐야 한다. 같은 개발환경이라도 원격접속과 내부 단말의 인터넷 활용은 완전히 다른 구조가 된다.

3. C/S/O와 5단계 전체 구조

N2SF의 절차는 Prepare → Categorize → Identify → Select → Assess의 5단계다. 이 절차를 외울 때 중요한 것은 각 단계 이름이 아니라, 단계 간 인과관계다. 앞 단계 산출물이 틀리면 뒤 단계가 연쇄적으로 무너진다.

단계 핵심 질문 핵심 산출물
Prepare 무엇을 보호할 것인가 업무, 업무정보, 정보시스템, 정보서비스, 시나리오, 보안목표
Categorize 무엇이 얼마나 중요한가 업무정보 등급표, 정보시스템 등급표, 혼재 시스템 후보
Identify 어디서 어떤 위협이 생기는가 위치-주체-객체 모델, 위협지점, 구조적 위협 목록
Select 무엇으로 막을 것인가 보안 요구사항, 보안통제, 구현계획, 반영 구성도
Assess 지금까지가 타당한가 평가결과, 재수행 범위, 최종 확인, 제출 패키지

여기서 C/S/O는 단계 전체를 관통하는 공통 언어다. 업무정보에 먼저 등급을 붙이고, 시스템은 그 정보를 따라가며, 위치 등급은 위협 모델링에서 활용된다. 중요한 점은 N2SF가 망 나누기 절차가 아니라 대상 식별 → 중요도 분류 → 위협 식별 → 통제 설계 → 적정성 검증 구조라는 점이다.

4. Prepare 단계

Prepare는 사전조사 단계가 아니라 범위와 문제를 정의하는 단계다. 뒤 단계의 품질은 거의 전부 Prepare에서 결정된다. 여기서 틀리면 뒤에서 아무리 정교하게 통제를 골라도 소용이 없다.

4.1 핵심 활동

  • N2SF 적용계획 수립
  • 기관 업무·기능 분석
  • 업무정보 식별
  • 정보시스템 식별
  • 정보서비스 식별

4.2 이 단계의 본질

Prepare의 진짜 목적은 우리 기관의 어떤 업무를 어떤 정보와 시스템, 어떤 사용 시나리오로 볼 것인가를 확정하는 것이다. 특히 마지막 정보서비스 식별이 가장 중요하다. 이 단계에서 단순 구성도를 그리는 것으로 끝나면 안 되고, 아래 세 가지가 나와야 한다.

  • 정보서비스의 구성과 구조
  • 정상 사용 시나리오
  • 정보서비스 보안목표

즉 업무시스템, DB, 방화벽 그림만 있다고 끝나는 게 아니다. 예를 들어 내부 단말에서 업무시스템 조회, 원격 단말에서 VPN 경유 접속, 업무시스템에서 외부 AI API 호출, 모바일 단말에서 문서 승인 같은 수준의 사용 시나리오가 있어야 뒤에서 위협 모델링이 가능하다.

4.3 실무 포인트

  • 보안팀 단독으로 하지 말고 현업, 정보화, BRM/조직 담당을 같이 묶어야 한다.
  • 업무는 부서명 기준이 아니라 보안분류 가능한 기능 단위로 내려가야 한다.
  • 업무정보는 문서 파일뿐 아니라 로그, 캐시, 백업, API 전송 데이터까지 포함해야 한다.
  • 정보시스템은 내부 구성요소뿐 아니라 외부 SaaS, 간편인증, 생성형 AI까지 식별해야 한다.
  • 시나리오는 너무 크지도, 너무 잘지도 않게 보안등급 경계가 보이는 수준으로 적어야 한다.

4.4 종료 기준

Prepare의 완료 기준은 자료를 모았다가 아니라 누락 없이 식별했고 다음 단계에서 분류 가능한 수준으로 정리했다다.

5. Categorize 단계

Categorize는 업무정보와 정보시스템에 C/S/O를 부여하는 단계다. 하지만 실무적으로는 분류보다 분리 판단이 더 중요하다. 한 시스템에 복수 등급 정보가 섞이는 순간 아키텍처 의사결정이 필요하기 때문이다.

5.1 업무정보 분류 원칙

  • C(기밀): 법률상 비밀, 안보·국방·외교, 국민 생명·안전과 직결되는 정보
  • S(민감): 감사, 입찰, 기술개발, 인사, 개인정보, 영업비밀, 내부검토 정보, 로그, 임시백업 등
  • O(공개): C/S 이외의 정보, 공개 요건을 충족한 정보

중요한 점은 문서 제목이 아니라 정보의 상태와 용도를 봐야 한다는 것이다. 예를 들어 내부 검토 중 보도자료 초안은 S일 수 있고, 최종 공개자료는 O가 될 수 있다.

5.2 정보시스템 분류 원칙

시스템 등급은 원칙적으로 그 시스템이 다루는 업무정보의 최고 등급을 따른다. 복수 등급이 섞일 경우 선택지는 두 가지다.

  • 상위등급 일괄 처리: 보안설계는 단순하지만 낮은 등급 정보 활용성이 낮아진다.
  • 등급별 시스템 분리: 활용성과 명확성은 좋아지지만 비용과 운영 복잡도가 증가한다.

따라서 Categorize는 단순 분류표 작성이 아니라 공개 활용, 외부연계, AI 활용, 모바일 협업을 어느 수준까지 허용할지 결정하는 설계 전 단계다.

5.3 이 단계에서 꼭 남겨야 할 것

  • 업무정보 등급표
  • 정보시스템 등급표
  • 복수 등급 혼재 시스템 목록
  • 분리 필요 후보 목록
  • 서비스별 허용 정보등급 범위

5.4 실수 포인트

  • 내부 시스템이면 무조건 S라고 두는 것
  • 로그, 임시백업, 개인정보를 빼먹는 것
  • 혼재 시스템을 상위등급으로만 올리고 활용성 문제를 검토하지 않는 것
  • 공개 가능한 정보를 과도하게 상향 분류하는 것

Categorize의 진짜 산출물은 등급표와 분리 의사결정 근거 두 가지다.

6. Identify 단계

Identify는 N2SF의 핵심 단계다. 이 단계에서야 비로소 어디에 보안대책이 필요한지가 구조적으로 보인다. 핵심은 시나리오별 위치-주체-객체 모델링과 두 가지 보안원칙 적용이다.

6.1 두 가지 보안원칙

  • 정보 생산·저장 원칙: 시스템은 자신의 등급과 같거나 더 낮은 등급 정보만 생산·저장해야 한다.
  • 정보 이동 원칙: 업무정보는 자신의 등급과 같거나 더 높은 등급의 시스템으로만 이동해야 한다.

즉 위협을 식별할 때 질문은 두 개다.

  • 낮은 등급 시스템에 더 높은 등급 정보가 저장되는가
  • 더 높은 등급 정보가 더 낮은 등급 시스템으로 이동하는가

6.2 대표 사례 해석

생성형 AI 활용

기관 단말과 업무영역이 S, 외부 AI 서비스가 O라면 핵심은 AI 사용 가능/불가가 아니다. O등급 정보만 AI에 올릴 수 있게 통제할 것인가가 핵심이다. 따라서 단말 업로드 차단, 연계구간 필터링, 비인가 AI 서비스 차단이 주요 통제 포인트가 된다.

개발환경 편의성 향상

같은 개발환경이라도 두 시나리오는 달라야 한다.

  • 원격 단말이 내부 개발시스템에 접속하는 경우
  • 기관 전산망의 개발단말이 인터넷 서비스를 활용하는 경우

둘은 구조가 다르므로 하나의 모델로 뭉치면 안 된다.

모바일 업무환경

개인 모바일 단말은 O로, 기관 지급·관리 모바일 단말은 S로 평가될 수 있다. 모바일이라는 사실보다 관리주체와 싣는 정보 등급이 더 중요하다.

무선 업무환경

S-S-S처럼 동일 등급 구성일 수도 있다. 이 경우 등급 혼용 기반 위협은 작지만, 비인가 AP, 인증 우회, 단말 노출 같은 무선 특화 위협은 여전히 존재한다.

6.3 이 단계에서 꼭 이해할 점

Identify는 모든 보안위협을 다루는 만능 단계가 아니다. 기본적으로는 정보등급 경계에서 생기는 구조적 위협을 잡는 단계다. 따라서 취약점, 악성코드, DoS, 공급망, 내부자 위협은 추가 방법론과 함께 봐야 한다.

6.4 남겨야 할 산출물

  • 시나리오별 위치-주체-객체 매트릭스
  • 등급 혼용 여부
  • 생산·저장 원칙 위배 지점
  • 이동 원칙 위배 지점
  • 구조적 보안위협 목록
  • 추가 위협 검토 필요사항

7. Select 단계

Select는 Identify에서 찾은 위협을 실제 설계와 사업 문서로 번역하는 단계다. 따라서 이 단계의 핵심은 위협 → 요구사항 → 통제 → 구현계획의 사슬을 끊기지 않게 만드는 데 있다.

7.1 보안 요구사항은 제품명이 아님

보안 요구사항은 달성해야 할 상태다. 예를 들어 MFA 도입, DLP 구축, CASB 적용은 구현수단 또는 통제에 가깝다. 반면 비인가 단말 접속 차단, O등급 외 정보의 외부 AI 전송 차단, 관리자 행위 기록 및 감사, 업무정보 무단 이동 방지는 요구사항에 가깝다.

또한 Prepare에서 정의한 보안목표가 반드시 요구사항에 포함되어야 한다. 이게 빠지면 N2SF의 앞뒤 논리가 끊어진다.

7.2 보안통제 선택 원칙

  • 부록1의 우선 검토사항을 참고하되 기계적으로 체크하지 않는다.
  • 필요하면 기관 자체 통제를 추가한다.
  • 단말, 연계구간, 외부서비스, 운영관리 등 구성요소별로 통제를 분리한다.
  • 구현 가능성과 일정, 예산, 운영주체까지 함께 본다.

7.3 반드시 남겨야 할 실무 산출물

  • 보안위협-보안요구사항 매핑표
  • 보안요구사항-보안통제 매핑표
  • 보안통제 구현계획표
  • 보안통제가 반영된 정보서비스 구성도

7.4 자주 하는 실수

  • 위협을 보자마자 특정 솔루션명을 적는다.
  • Prepare의 보안목표를 요구사항에 반영하지 않는다.
  • 부록1만 기계적으로 체크한다.
  • 구현계획 없이 통제 목록만 정리한다.
  • 구성요소별 분해 없이 서비스 전체에 통제를 한 덩어리로 적는다.

Select의 핵심은 왜 이 통제가 필요한가와 어떻게 구현할 것인가를 동시에 설명하는 것이다.

8. Assess 단계

Assess는 마지막 단계이지만, 단순 결재 절차가 아니다. 실제로는 전 단계 품질보증, 영향도 추적, 재수행 범위 조정, 최종 제출 게이트 역할을 동시에 한다.

8.1 무엇을 평가하는가

Assess는 최종 문서만 보는 게 아니라 Prepare, Categorize, Identify, Select에서 만든 중간 산출물과 지식 전부를 다시 본다. 따라서 판단 기준은 문서가 예쁘게 써졌는가가 아니라 앞뒤 논리가 맞는가다.

예를 들어 아래 중 하나만 틀려도 재작업이 필요하다.

  • Prepare의 시나리오와 Identify의 시나리오가 다르다.
  • 업무정보 등급과 시스템 등급이 맞지 않는다.
  • Identify에서 잡은 위협이 Select 요구사항으로 안 내려왔다.
  • Select에서 정의한 통제가 사업계획서나 구성도에 반영되지 않았다.

8.2 협의·조정의 핵심

부적합 항목이 발견되면 오류가 시작된 단계와 그 이후 영향받는 단계까지 재검토해야 한다. 다만 무조건 처음부터 다시 하는 것이 아니라, 영향 범위만 재수행하도록 제한할 수 있다. 실무적으로는 이 판단이 매우 중요하다.

8.3 최종 확인과 제출문서 4종

Assess의 마지막 확인은 정보보안담당관이 수행하며, 이후 국가정보원 보안성 검토 제출로 이어진다. 이때 연결되는 제출문서는 다음 네 가지다.

  • 사업계획서
  • 제안요청서
  • 정보통신망 구성도
  • 자체 보안대책

즉 Assess의 종료 조건은 내부 검토 완료가 아니라 보안성 검토 제출 가능 상태다. 그래서 자체 보안대책만 잘 써 놓고 나머지 문서와 안 맞으면 실패다.

9. 실무 적용 체크리스트와 암기 포인트

마지막으로 N2SF를 실제 업무에 적용할 때 기억해야 할 체크포인트를 한 장으로 정리하면 아래와 같다.

9.1 단계별 최소 산출물

  • Prepare: 역할·책임표, 업무 목록, 업무정보 목록, 시스템 목록, 서비스 시나리오, 보안목표
  • Categorize: 업무정보 등급표, 시스템 등급표, 혼재 시스템 목록, 분리 필요 후보
  • Identify: 위치-주체-객체 표, 위협지점표, 구조적 위협 목록
  • Select: 요구사항 표, 통제 표, 구현계획표, 반영 구성도
  • Assess: 적절성 평가 결과, 재수행 범위표, 제출문서 정합성 확인표

9.2 반드시 기억할 12문장

  • N2SF의 출발점은 망이 아니라 정보다.
  • 보호 단위는 부서가 아니라 업무기능 단위다.
  • 업무정보는 생명주기 전체에서 본다.
  • 정보시스템은 내부 서버만이 아니다.
  • 정보서비스는 시나리오 기반 운영 단위다.
  • C/S/O는 정보에 먼저 붙는다.
  • 혼재 시스템은 상위등급 처리 또는 분리 설계 판단이 필요하다.
  • Identify의 기본 문법은 위치-주체-객체다.
  • 주체는 사람이 아니라 시스템이다.
  • Select는 위협을 요구사항과 통제로 번역하는 단계다.
  • Assess는 문서 정합성과 영향도 추적 단계다.
  • N2SF의 끝은 보안성 검토 제출 가능 상태다.

9.3 최종 한 줄 요약

N2SF는 업무와 정보의 중요도를 먼저 정하고, 그 등급이 섞이는 지점에서 위협을 찾은 뒤, 그 위협을 통제와 구현계획으로 바꾸고, 마지막에 전체 문서 논리를 검증해 제출 가능한 상태로 만드는 프레임워크다.

첨부파일