CUI 보호: 관리 대상 비기밀 정보를 안전하게 처리하는 방법

관리 대상 비기밀 정보(Controlled Unclassified Information, CUI)는 민감하지만 비기밀로 분류된 정보로, 연방법, 규정 또는 정부 전반의 정책에 따라 보호하거나 유포를 통제해야 합니다. 국방, 에너지, 의료 등 규제가 적용되는 여러 분야에서 연방 기관과 계약업체는 CUI를 올바르게 처리해야 할 의무가 있으며, 이는 상당한 준수 및 계약상의 의미를 가집니다.

하지만 많은 조직이 여전히 연방 요구사항을 충족하는 데 필요한 절차, 시스템 통제, 그리고 가시성을 갖추지 못하고 있습니다. CMMC Phase 1 구현 이 진행되고, 정부가 FAR CUI rule 를 통해 더 일관된 계약업체 처리 요구사항으로 나아가면서, CUI 준수는 더 이상 ‘희망사항’이 아닙니다. 이제 계약의 필수 전제 조건입니다.

CUI에 대해 적절한 식별, 표시, 보호, 및 배포 통제를 입증하지 못하는 조직은 불리한 감사 결과, 계약 지연, 그리고 향후 수상 자격 상실의 위험이 있습니다.

이 가이드는 CUI가 실제로 무엇인지, 보호 요구사항이 어떤 형태로 제시되는지, 그리고 이를 안전하게 처리하기 위한 실질적인 접근 방식을 구축하는 방법을 설명합니다.

관리되는 비기밀 정보(Controlled Unclassified Information, CUI)とは 무엇입니까?

관리되는 비기밀 정보(CUI)는 연방 정부가 생성하거나 보유하는 정보, 또는 정부를 대신하여 어떤 기관이 생성하거나 보유하는 정보 중에서, 적용 가능한 법률, 규정, 그리고 정부 전체에 적용되는 정책과 일치하는 보호 또는 배포 통제가 필요로 하는 정보를 말합니다.

정식 정보 범주로서 CUI는 Executive Order 13556에 의해 제정되었으며 32 CFR Part 2002에 법제화되었습니다. 이는 FOUO, LES, SBU 같은 기존의 제각각 표기 체계를 대체하여, 연방 기관과 그 계약자 전반에 걸쳐 민감하지만 비기밀 정보의 보호를 위한 단일하고 일관된 프레임워크를 제공했습니다.

전체 프로그램을 뒷받침하는 핵심 원칙은 다음과 같습니다. 연방법, 규정 또는 정부 전반에 적용되는 정책에 따라 보호가 필요한 정보만 CUI로 지정할 수 있습니다. 기관은 행정적 선호만을 근거로 CUI 범주를 만들어서는 안 됩니다.

CUI는 두 가지 처리 범주로 나뉩니다:

• CUI Basic 는 기본값입니다. NARA CUI Registry가 특정 범주를 CUI Specified로 명시적으로 주석 처리하지 않는 한, 32 CFR Part 2002의 일관된 표준이 모든 CUI에 적용됩니다. 배너 표기는 CUI 또는 CUI//PRVCY처럼 보입니다.
• CUI Specified 는 승인 법률 또는 규정에 CUI Basic 기본값과 다른 특정 처리 통제가 포함되어 있을 때 적용됩니다. 이러한 범주에는 CUI//SP-CTI와 같은 "SP-" 접두사가 붙습니다.

차이는 민감도 수준이 아니라 통제 조치의 출처에 있습니다. 즉, 특정 권한 기관이 언급하지 않은 부분은 CUI Basic가 메웁니다.

NARA CUI Registry 는 권위 있는 출처로, 125개+ 범주를 포괄합니다. 계약업체는 자신이 마주치는 어떤 CUI에 대해서도 적절한 분류, 표기, 취급 방법을 결정하기 위해 이곳을 확인해야 합니다.

CUI의 일반적인 예시

모든 민감 데이터 가 CUI인 것은 아닙니다. CUI 레지스트리에 나열된 권한 기관과 연결되어야 합니다. 다음은 주요 범주에 걸친 일반적인 CUI 예시입니다:

• 국방(CTI): 통제 기술 정보(CTI)에는 기술 도면(스키매틱), 시스템 설계 문서, 군사 목적을 위해 개발된 소스 코드가 포함되며, DFARS 252.204-7012의 권한에 따라 CUI//SP-CTI로 표시됩니다.
• 수출 통제: 미국 탄약 목록(U.S. Munitions List)에 있는 방산 물품에 대한 기술 도면과, 수출 허가 대상인 기술 데이터는 CUI 레지스트리의 수출 통제 범주에 포함됩니다.
• 법 집행: 범죄 경력 기록 정보, DNA 프로필, 그리고 정보 제공자 식별 데이터는 법 집행과 관련된 CUI 범주에 포함됩니다.
• 프라이버시: 주민등록번호, 금융 계좌 번호, 생체 데이터, 그리고 HIPAA 적용 대상 건강 정보는 프라이버시/보건 관련 CUI 범주에 따라 처리됩니다.
• 핵심 인프라: 화학 테러 취약성 정보, 중요 에너지 인프라 정보, 그리고 정보 시스템 취약성 정보는 핵심 인프라 범주에 포함됩니다.

이 예시는 대표적인 사례일 뿐이며, 결정적인 기준은 아닙니다. 처리 규칙을 설정하기 전에 CUI Registry와 계약 문구에서 해당 범주, 권한, 그리고 요구되는 표기가 무엇인지 항상 확인(검증)하세요.

CUI(제어된 비공개 정보) 보호의 핵심 요구사항

CUI 보호는 단지 파일을 잠그는 것만을 의미하지 않습니다. CUI 보호에는 표시(마킹), 물리적 및 디지털 보호, 그리고 누가 정보에 접근하고 공유할 수 있는지를 통제하는 일이 모두 포함됩니다. 이들 각 영역에는 특정한 연방 요구사항이 따르며, 어느 한 부분이라도 공백이 생기면 전체 컴플라이언스 수준이 흔들릴 수 있습니다. 다음은 세 가지 핵심 보호 기둥 전반에서 반드시 제대로 갖춰야 할 사항입니다.

CUI의 표시 및 라벨링

일관되지 않은 마킹은 컴플라이언스 평가에서 탈락하는 가장 빠른 방법 중 하나입니다. 마킹은 전체 CUI 처리 체인을 좌우합니다. 즉, 마킹은 승인된 보유자에게 누가 정보를 열람할 수 있는지, 정보가 어떻게 공유될 수 있는지, 그리고 어떤 보호 조치가 적용되는지를 알려줍니다.

표준 마킹 예시:

• 분류가 없는 CUI Basic: CUI
• CUI 지정: CUI//SP-CTI
• 전파 통제가 적용된 CUI 지정: CUI//SP-SGI//FEDONLY

실제로는 정확한 배너 표시와 일관된 하위(전달) 라벨링(이메일 제목, 파일 헤더, 표지, 저장소)이 CUI가 통제되지 않은 채널로 유출되지 않도록 합니다.

모든 CUI 문서에는 통제 기관을 식별하는 지정 표시(designation indicator)가 포함되어야 합니다. 또한 지침에서는 이메일에 CUI가 포함된 경우 이메일의 제목 줄과 메시지 본문에 CUI 배너 표시를 적용할 것을 권장합니다.

보호 조치와 통제된 환경

CUI는 충분한 접근 통제 및 무단 열람 또는 도청에 대한 보호가 갖춰진 통제된 환경에서 처리되어야 합니다.

NIST SP 800-171 Rev. 1 은 기준선을 수립했습니다. CUI의 기밀성 영향 값은 FIPS 199의 중간(moderate) 등급보다 낮아서는 안 됩니다. FIPS 199에 따르면 중간은 기밀성이 상실될 경우 "조직의 운영, 조직 자산 또는 개인에게 심각한 불리한 영향을 미칠 것으로 예상될 수 있음"을 의미합니다.

조직은 System Security Plan (SSP)에서 운영 환경, 요구사항이 어떻게 이행되는지, 그리고 다른 시스템과의 연결을 포함하여 CUI 시스템 경계를 설명해야 합니다.

물리적 보안 요구사항에는 승인된 개인으로의 접근을 제한하고, 방문자를 동행하며, 접근 감사 로그를 유지하고, 대체 작업 장소에서 보호 조치를 시행하는 것이 포함됩니다.

접근 통제 및 전파(배포) 통제

CUI에 대한 접근은 명확한 원칙을 따릅니다. 즉, 정당한 need-to-know가 있고 적절한 교육을 받은 승인된 사용자만 접근할 수 있습니다.

NIST SP 800-171 Rev. 3 는 허용되는 계정 유형을 정의하도록 요구하고, 유효한 need와 의도된 사용 목적에 따라 접근을 승인하며, 시스템 계정 사용을 지속적으로 모니터링하도록 계정 관리 요건을 강화했습니다.

에 따라 32 CFR 2002.16 의 전파(배포)는 CUI 범주를 제정한 법을 준수해야 하며, 적법한 정부의 목적을 뒷받침해야 하고, 승인된 제한된 전파 통제에 의해 제한되어서는 안 됩니다.

외부 당사자와 CUI를 공유하기 전에 수신자가 정당한 need-to-know를 가지고, CUI 요구 사항을 이해하며, 정보를 적절하게 보호할 수 있는지 확인하십시오.

여기서도 교육은 중요합니다. 2025년 1월 FAR CUI 규칙은, 계약자가 직원이 CUI를 취급하도록 허용하려면 해당 직원이 적절한 교육을 완료해야 한다고 규정합니다. 또한 계약자는 요청이 있을 경우 교육 이수 증거를 제공해야 합니다.

CUI와 사이버보안 프레임워크

CUI 보호 의무는 진공 상태에서 존재하지 않습니다. 이는 정책 요구사항을 구체적이고 감사(검증) 가능한 보안 통제로 전환하는, 연방 사이버보안 프레임워크의 다층 구조 안에 자리합니다.

이러한 프레임워크들이 어떻게 연결되는지 이해하는 것은, 특히 서로 다른 계약이 서로 다른 개정판이나 기준선을 참조하는 경우 준수 환경을 구축하는 데 필수적입니다.

NIST SP 800-171과 CUI

NIST SP 800-171 는 CUI 보호 의무를 비연방 시스템에 대한 구체적인 보안 요구 사항으로 변환합니다. 현재 버전인 Rev. 3에는 17개 제어 패밀리에 걸쳐 97개의 보안 요구 사항이 포함되어 있습니다. Rev. 2에는 14개 패밀리에 걸쳐 110개의 요구 사항이 있었습니다.

CUI 처리에 직접적으로 영향을 미치는 핵심 영역에는 다음이 포함됩니다:

• 접근 제어: 계정 관리, 최소 권한, 직무 분리, 정보 흐름 제어
• 감사 및 책임성: 이벤트 유형, 타이밍, 소스, 결과, 그리고 신원을 포착하는 감사 로그; 조직 및 계약 요구 사항에 맞춘 보관 기간
• 사고 대응: 조직이 정의한 주기에 따라 운영상의 처리 역량, 추적, 및 테스트를 수행
• 미디어 보호: 폐기 전 데이터 삭제(정보 제거), 운송 중 암호화 기반 보호

이러한 영역을 함께 보면, 감사자가 CUI 취급이 실제로 이행되고 있는지—단지 문서로만 존재하는지—를 평가할 때 확인하는 일상적인 운영 통제를 정의합니다.

FIPS 199 영향 수준과 CUI

컴플라이언스(규정준수) 캐스케이드는 다음과 같이 작동합니다. FIPS 199는 영향 수준을 분류하고, FIPS 200은 최소 보안 요구사항을 설정하며, 통제 선택은 NIST 보안 통제 기준선(baseline)에서 도출됩니다. 그런 다음 이러한 기준선은 CUI를 취급하는 비(非)연방 조직을 위해 NIST SP 800-171로 맞춤 조정됩니다.

실질적인 영향은 상당합니다:

• 클라우드 호스팅: 클라우드 환경의 CUI 시스템의 경우, FedRAMP Moderate는 중간 영향 정보 시스템에 대한 최소 적절 기준선으로 널리 간주됩니다.
• 암호화: 암호화 모듈은 FIPS 승인 알고리즘을 사용하기만 하는 것이 아니라 FIPS 140-2 검증을 받아야 합니다. NIST의 CMVP 가이드에서는 검증되지 않은 암호화는 보호를 제공하지 않는 것으로 간주된다고도 명시합니다.
• 네트워크 보호: 중간 수준의 기준선에는 액세스 제어, 경계 보호, 네트워크 분리, 전송 기밀성 및 무결성, 그리고 네트워크 모니터링이 포함됩니다.

중요 프로그램 또는 고가치 자산과 관련된 CUI의 경우, NIST SP 800-172는 강화된 보안 요구사항을 제공합니다. 다만 이러한 요구사항은 계약 문구에서 명시적으로 지정된 경우에만 적용됩니다.

CUI를 안전하게 처리하기 위한 모범 사례

다음 모범 사례는 CUI 컴플라이언스 의무를 팀이 실제로 수행할 수 있는 구체적인 단계로 전환합니다. 초기 데이터 검색부터 액세스 거버넌스, 암호화, 사고 대응에 이르기까지 전 과정을 다룹니다.

1. CUI를 정확하게 식별하고 분류하기

연방 기관만이 정보를 CUI로 지정할 수 있습니다. 계약업체가 표기가 되어 있지 않을 수 있는 잠재적 CUI를 발견하면, 스스로 표시하지 말고 공식 판단을 위해 발주 담당관(Contracting Officer)에게 보고해야 합니다. FAR CUI 규정은 잠재적 CUI의 발견을 8시간 이내에 보고하도록 요구합니다.

계약 건별 검토부터 시작하세요. 각 계약서에 명시된 CUI 범주를 실제 정보 흐름과 대조하여 매핑합니다. 흔한 범위 설정 실패 사례는 다음과 같습니다.

• 누락된 시스템: 주요 환경 밖에서 CUI를 처리하는 시스템을 놓치는 경우
• 3자(제3자)로 인한 사각지대: 귀하를 대신해 CUI를 다루는 서비스 제공업체를 고려하지 않는 경우
• 섀도 IT: 협업 도구와 클라우드 서비스를 잊어 CUI가 거기에 저장되거나 유입될 수 있는 점을 간과하는 경우

교육도 마찬가지로 중요하며, 다음 세 가지 수준에서 진행되어야 합니다:

• 전사적 인식 제고: CUI를 접할 수 있는 모든 사람을 대상으로
• 역할(직무)별 교육: 정기적으로 CUI를 처리하는 직원들을 대상으로
• 고급 기술 교육: CUI 환경을 관리하는 시스템 관리자 대상

교육에 대한 투자는 매우 중요합니다. 인간의 요인은 여전히 가장 큰 취약점이기 때문입니다. Netwrix 2024 Hybrid Security Trends Report 에 따르면, IT 전문가의 47%가 직원의 실수와 태만을 최우선 보안 과제로 꼽았습니다.

식별(발견)의 과제도 마찬가지로 광범위합니다. Netwrix가 후원한 2025 SANS Attack Surface Management (ASM) Survey 조사에 따르면, 조직의 28%만이 ASM 플랫폼이 민감한 파일을 효과적으로 식별한다고 믿고 있으며, 또 다른 41%는 부분적으로만 식별한다고 답했습니다.

바로 이 지점에서 도구가 진정한 차이를 만들어냅니다. 예를 들어 First National Bank Minnesota 는 Netwrix Auditor와 Netwrix Data Classification을 사용해 민감한 데이터를 찾아 분류한 뒤 안전한 위치로 이동했으며, Active Directory 재구축을 6개월이 아니라 3주 만에 완료했습니다.

2. 개체(오브젝트) 수준에서 액세스 관리

폴더 수준 및 사이트 수준의 권한은 CUI에 대해 충분히 세분화되어 있지 않습니다. NIST SP 800-171에서는 CUI에 대한 보호를 강화하기 위해 애플리케이션 및 서비스 수준에서 액세스 강제 메커니즘을 구현할 수 있음을 인정합니다.

NIST SP 800-162에서 정의한 특성 기반 접근 제어(ABAC)는 모든 액세스 요청마다 사용자, 데이터, 환경의 특성을 정의된 정책 규칙과 비교하여 평가합니다. CUI에 대한 이점은 동적 최소 권한입니다:

• 역할 변경: 누군가의 임무 할당이 변경되면, 더 이상 필요하지 않은 CUI에 대한 접근 권한이 업데이트된 주체 속성을 통해 자동으로 해지됩니다
• 분류 변경: 데이터의 분류가 변경되면, 수동 재구성 없이 영향을 받는 모든 사용자 전반에 걸쳐 액세스 제한이 조정됩니다

3. 전송 중 및 저장 중에 CUI를 암호화

NIST SP 800-171은 통제된 환경 밖에서 전송되거나 저장되는 CUI에 대해 암호화를 요구합니다. 보호된 환경 내에서는 다른 보호 조치로 요건을 충족할 수 있지만, 그 경계를 벗어나는 모든 CUI는 반드시 암호화되어야 합니다

핵심 요구사항은 암호화 모듈이 FIPS 140-2 검증을 받아야 하며, 인증서 번호를 문서로 남겨야 한다는 것입니다. 특정 모듈이 NIST의 Cryptographic Module Validation Program을 거치지 않았다면, 단순히 AES-256을 사용하는 것만으로는 충분하지 않습니다.

키 관리에도 동등한 관심을 기울여야 하므로, 사후 조치가 아니라 기반 인프라로 취급해야 합니다.

4. 사고를 모니터링하고, 로그를 남기며, 대응한다

NIST SP 800-171은 이벤트 유형, 타이밍, 위치, 소스, 결과 및 관련된 신원을 포착하는 감사 기록을 요구합니다. 개별 사용자 작업은 고유하게 추적 가능해야 하며, 감사 기록 보관 기간은 조직이 정의한 요구사항 및 계약이 정의한 요구사항에 맞춰야 합니다.

사고 대응에서는 타임라인이 점점 더 촉박해지고 있습니다. 업종에 따라 적용되는 보고 의무가 다릅니다:

• FAR CUI 규정: 의심 또는 확인된 CUI 사고를 보고하기 위한 8시간 이내의 시간
• DFARS 252.204-7012: 국방부(DoD) 계약업체는 DIBNet을 통해 보고
• CIRCIA: 중요 기반시설(critical infrastructure) 관련 기관은 72시간 이내에 CISA에 보고

이러한 기한을 맞추려면 탐지만이 아니라 포렌식 역량과 사전에 수립된 조사 절차가 필요합니다.

여기서는 활동 데이터와 액세스 권한을 상관 분석하는 것이 효과를 발휘합니다. 실제 환경에서는 파일 변경에서 의심스러운 급증이 단 한 번만 나타나도, 팀이 서로 연결되지 않은 로그에서 답을 맞춰 조합해야 한다면 며칠 동안 허둥대는 상황으로 이어질 수 있습니다.

Netwrix가 조직의 CUI 보호를 돕는 방법

단 하나의 프로세스나 체크리스트만으로는 CUI 준수가 하룻밤 사이에 이루어지지 않습니다. 계약업체가 직면한 과제는, 평가자가 찾아낼 수 있는 공백이 생기지 않도록 서로 연결되지 않은 도구들을 억지로 이어 붙이지 않으면서도 데이터 검색, 액세스 거버넌스, 감사 준비 상태 사이의 연결 고리를 찾아내는 것입니다.

환경이 온프레미스 파일 서버, Active Directory, Microsoft 365가 혼합된 형태로 Microsoft 인프라에서 운영된다면, 한 곳에서 이 모든 것을 포괄하는 플랫폼이 필요합니다.

The 1Secure Platform 는 파일 시스템, 데이터베이스, 협업 플랫폼, 클라우드 스토리지 전반에 걸쳐 자동으로 검색을 수행하므로, 평가자보다 먼저 CUI 관련 데이터를 찾을 수 있습니다.

보안이 취약한 위치에 있는 민감한 파일을 격리하고, 이를 안전한 영역으로 이동하며, 과도한 권한을 제거하고, classification tags 를 파일에 내장해, 수주에 걸친 수동 재고 조사를 자동화되고 반복 가능한 프로세스로 전환합니다.

하지만 검색만으로는 충분하지 않습니다. 더 어려운 질문은 이것입니다. 그 데이터에 누가 접근할 수 있는지, 그 접근이 적절한지, 그리고 이를 입증할 수 있는지요. 1Secure Platform은 과도하게 노출된 민감한 데이터 오브젝트, 분류된 콘텐츠에 대한 상세 권한 구조, 그리고 민감한 파일 및 폴더와 관련된 활동을 보고합니다.

즉, 과도한 권한이 부여된 상태에서 CUI가 위치한 곳을 파악하고, 감사 지적 사항이 되기 전에 이를 시정할 수 있습니다.

Netwrix Endpoint Protector 는 해당 보장 범위를 엔드포인트 계층까지 확장하여, 승인되지 않은 경로를 통해 CUI가 통제된 환경 밖으로 유출되는 것을 방지합니다. 승인되지 않은 USB 장치로의 전송을 차단하고, 브라우저, 이메일 클라이언트, 클라우드 스토리지 애플리케이션을 통한 업로드를 모니터링 및 제어합니다. 또한 승인된 이동식 매체에 대해 암호화를 강제하여, CUI 취급 요구사항이 예방하도록 설계된 유출 위험을 직접적으로 해결합니다.

사전 구성된 컴플라이언스 보고서는 누가 데이터를 액세스했는지, 무엇이 변경되었는지, 그리고 언제 변경되었는지를 보여주며, 대화형 검색을 통해 수일이 아니라 수 분 안에 감사인의 질문에 답할 수 있습니다.

Netwrix 데모를 요청하세요 단일 플랫폼이 하이브리드 환경 전반에서 CUI를 식별하고 보호하며 규정 준수를 입증하는 데 어떻게 도움이 되는지 확인해 보세요.