본문으로 건너뛰기
피드

국정원, 공공 AI·클라우드 막던 데이터 등급 기준 손본다

security 약 5분
vote
0
댓글
북마크

국정원이 국가망보안체계(N2SF)의 데이터 분류 가이드라인을 올해 말까지 마련한다. 기관마다 제각각이던 기밀·민감·공개 데이터 판단 기준을 구체화해 공공부문의 AI, 클라우드, SaaS 활용을 넓히려는 흐름이다.

  • 1

    국정원이 NIST SP 800-60을 참고해 N2SF 데이터 분류 가이드라인 초안을 올해 말까지 마련할 예정

  • 2

    현재 공공기관은 C·S·O 분류를 쓰지만 세부 사례가 부족해 보수적으로 상향 분류하는 문제가 있음

  • 3

    분류 기준이 구체화되면 공공 AI 서비스와 SaaS 도입, 민간 클라우드 활용이 빨라질 가능성이 큼

  • 국정원이 국가망보안체계(N2SF)의 데이터 분류 기준을 올해 말까지 더 구체화하기로 함

    • 지금 공공기관은 데이터를 기밀(C), 민감(S), 공개(O)로 나누고 있음
    • 문제는 실제 현장에서 “이 데이터가 S냐 O냐”를 판단할 세부 사례가 부족했다는 점임
    • 그래서 담당자나 기관마다 해석이 달라지고, 사고 나면 책임질까 봐 일단 더 높은 등급으로 묶는 일이 많았음
  • 참고 모델은 미국 국립표준기술연구소(NIST)의 NIST SP 800-60

    • 이 문서는 미국 연방정부 데이터를 행정, 재정, 보건, 국방, 인사 같은 업무 영역별로 쪼개서 분류함
    • 기밀성, 무결성, 가용성에 미치는 영향을 기준으로 보안 수준을 상·중·하 3단계로 나누는 방식임
    • 국정원이 이걸 보는 이유는 단순 원칙이 아니라 “현장에서 바로 적용 가능한 사례”가 많기 때문임

중요

> 핵심은 망분리 규제를 무작정 유지하는 게 아니라, 데이터 성격에 따라 보안을 다르게 적용하자는 쪽으로 무게가 이동하고 있다는 점임.

  • 이번 가이드라인의 진짜 목표는 공공 데이터 활용을 막던 애매함을 줄이는 것임

    • 현재 N2SF 보안 가이드라인 1.0은 C를 법령상 비밀·비공개 정보, S를 공개 시 기관 업무나 개인·법인 이익을 침해할 수 있는 정보, O를 그 외 정보로 정의함
    • 정의 자체는 있지만, 구체적인 데이터 예시와 적용 기준이 부족해서 현장에선 재량 판단이 많이 들어갔음
    • 국정원은 담당자 재량을 줄이고 기관별 편차를 낮추는 방향으로 새 기준을 만들겠다는 입장임
  • 기준이 명확해지면 공공 AI와 클라우드 도입에 직접 영향이 감

    • S·O 데이터 범위가 구체화되면 공공 AI 서비스에 어떤 데이터를 넣을 수 있는지 판단하기 쉬워짐
    • 서비스형 소프트웨어(SaaS) 활용도 지금보다 넓어질 가능성이 있음
    • 과도하게 C로 묶여 있던 데이터가 풀리면, 민간 클라우드나 AI 분석 환경으로 옮길 여지도 커짐
  • 전문가 코멘트도 같은 방향임

    • 김창훈 대구대 교수는 분류 기준이 구체화되면 기관별 판단 편차를 줄일 수 있다고 봄
    • 더 나아가 자동화 도구 기반 데이터 분류 체계 구축도 가능해질 수 있다고 언급함
    • 결국 사람이 매번 회의해서 등급을 정하는 방식에서, 규칙과 도구가 도와주는 방식으로 넘어갈 수 있다는 얘기임

기술 맥락

  • 이번 변화는 공공기관이 데이터를 어디까지 클라우드나 AI 시스템에 올릴 수 있는지 정하는 문제와 연결돼요. 기술적으로는 클라우드 이전이나 AI 도입인데, 실제 병목은 “이 데이터 등급이 뭔데?”에서 걸리는 경우가 많거든요.

  • N2SF가 중요한 이유는 기존 망분리 중심 보안을 데이터 중심 보안으로 바꾸려는 시도이기 때문이에요. 모든 시스템을 같은 강도로 막으면 안전해 보이지만, 공개 가능 데이터까지 묶이면서 AI 학습, 검색, 분석, SaaS 도입이 같이 느려져요.

  • NIST SP 800-60을 참고한다는 대목도 꽤 실무적이에요. 업무 영역별 데이터 유형과 보안 영향도를 같이 제시하면, 기관 담당자가 처음부터 판단 체계를 새로 만들 필요가 줄어들거든요.

  • 개발자에게는 이게 배포 환경의 제약 변화로 이어질 수 있어요. 공공 프로젝트에서 민간 클라우드, SaaS, AI API를 쓰려면 데이터 등급과 처리 위치를 설명해야 하는데, 기준이 구체화되면 아키텍처 설계와 보안 검토가 조금 더 예측 가능해져요.

공공 클라우드·AI 도입이 기술보다 보안 해석에서 막히는 경우가 많았다는 점에서 꽤 중요한 변화다. 개발자 입장에선 단순 정책 뉴스가 아니라, 앞으로 공공 SaaS나 AI 프로젝트의 배포·운영 조건이 달라질 수 있는 신호로 보면 됨.

댓글

댓글

댓글을 불러오는 중...

security

AI 에이전트 보안, 이제 권한이 아니라 ‘실행 증거’ 싸움으로 간다

오페이크가 AI 에이전트의 ID, 실행 환경, 도구 호출, 정책 적용 여부를 암호학적으로 검증하는 오페이크 3.0을 공개했다. 핵심은 에이전트 매니페스트와 컨피덴셜 MCP라는 두 오픈소스 기술이며, 기밀 컴퓨팅과 서명된 실행 증거를 결합해 감사자나 규제기관도 독립적으로 확인할 수 있게 하는 방향이다. AI 에이전트가 업무 시스템과 데이터를 직접 만지는 시대에는 접근 권한보다 ‘무슨 일을 했는지 증명할 수 있느냐’가 더 중요해지고 있다.

security

취약점 제보가 더 이상 특별하지 않은 시대가 왔다

전 Go 보안팀 리드였던 필리포 발소르다가 LLM 이후 취약점 제보의 의미가 바뀌었다고 주장한다. 예전에는 희소한 통찰과 비공개 제보가 귀했지만, 이제는 잠재 취약점을 찾는 것보다 실제 영향도를 빠르게 가려내는 triage가 병목이라는 얘기다.

security

스패로우, AI가 만든 코드 취약점 잡는 ‘Sparrow MCP’ 출시

스패로우가 AI 코딩 에이전트가 생성한 코드의 보안 취약점과 사용된 오픈소스를 실시간으로 검사하는 보안 어시스턴트 ‘Sparrow MCP’를 출시했다. 핵심 기능은 취약점 분석과 소프트웨어 자재명세서(SBOM) 생성이며, 앤트로픽의 모델 컨텍스트 프로토콜(MCP)을 지원하는 AI와 연결할 수 있다는 점이다. AI 코딩이 빨라질수록 보안 검증과 오픈소스 추적이 개발 파이프라인 안으로 더 깊게 들어오는 흐름이다.

security

오픈AI, 오픈소스 취약점 고치는 ‘패치 더 플래닛’ 시작

오픈AI가 트레일 오브 비츠와 함께 주요 오픈소스 프로젝트의 취약점을 AI로 찾고, 사람 검토를 거쳐 실제 패치까지 연결하는 프로그램을 시작했다. 파이썬, 고, cURL, 시그스토어, NATS 서버 같은 핵심 프로젝트가 초기 대상이고, 지금까지 수백 건의 보안 이슈와 수십 건의 병합된 패치가 나왔다. 핵심은 AI가 보안팀을 대체하는 게 아니라, 탐지·검증·패치·공개 조율을 빠르게 만드는 보조 엔진이라는 점이다.

security

오픈AI, 취약점 찾기부터 패치까지 돕는 ‘코덱스 시큐리티’ 공개

오픈AI가 사이버보안 이니셔티브 데이브레이크를 확대하면서 보안 전용 도구 코덱스 시큐리티와 GPT-5.5-사이버를 공개했다. 목표는 취약점 탐지에서 끝나는 게 아니라 검증, 위험도 평가, 패치 개발, 테스트, 배포까지 AI로 지원하는 것이다. cURL, Go, Python, Sigstore 등 30개 이상 오픈소스 프로젝트도 패치 지원 프로그램에 참여한다.