DEEP DIVE REPORT

제3자 사이버 리스크 운영: 공급업체 접속·권한·사고 통지 점검표

SecurityDesk
2026.08.08 조회 10

서론

현대 조직의 디지털 인프라는 단일 사내 시스템으로 구성되지 않는다. 클라우드 플랫폼, SaaS 제공업체, 외부 개발 컨설팅, 물류 파트너, 마케팅 대행사 등 수십乃至 수백 개의 제3자가 조직의 데이터와 시스템에 직접 또는 간접적으로 접근한다. 이러한 생태계는 효율성을 높이고 비용을 줄이지만, 동시에 공격 면적을 기하급수적으로 확장한다.

2024년 Change Healthcare ransomware 공격은 이 문제를 잘 보여준다. Change Healthcare는 미국 의료 청구 처리의 핵심 중개 서비스였으며, 공격으로 인해 전 미국 의료기관의 청구 처리가 마비되는 광범위한 영향이 발생했다. CISA는 이에 공식 대응 애드버토리를 발간했다. 이 사례는 제3자 관계를 경유한 공격이라기보다, 특정 의료 청구 중개 서비스의 높은 시장 집중도가 한 곳의 보안 침해로 인해 전체 생태계에 파급효과를 미친 사례로 이해해야 한다.

제3자 사이버 리스크는 단순히 기술 문제가 아니다. 이는 비즈니스, 운영, 거버넌스 전반에 걸친 통제 문제이며, 방화벽 내부의 보안 수준과 무관하게 외부 파트너의 약점이 조직 전체를 위협할 수 있다. 본고에서는 CISA의 제3자 리스크 관리 가이드와 NIST CSF Governance 기능의 공급망 리스크 관리(GV.SC) 카테고리를 기준으로, 실제 운영에서 적용 가능한 점검표를 제시한다.

공급업체 생태계 파악 및 분류

제3자 리스크 관리의 첫 단계는 "누가 어디에 접근하는지"를 정확하게 아는 것이다. 많은 조직이 공급업체 목록을 유지하지만, 보안 관점에서 구조화된 인벤토리는 드물다.

공급업체 인벤토리 구성 요소

항목 설명 수집 주기
업체명·연락처 기본 정보 및 책임자 계약 체결 시
접근 시스템 목록 접근 가능한 애플리케이션/네트워크 분기별
데이터 유형 처리하는 데이터의 민감도 분류 분기별
계약 기간·종료일 서비스 기간 및 갱신 조건 연차별
보안 인증 현황 SOC 2, ISO 27001 등 연차별
하위 계약자 목록 공급업체의 공급업체 정보 연차별

리스크 기반 분류

모든 공급업체가 동일한 리스크 수준을 가지는 것은 아니다. 접근 범위와 비즈니스 중요도에 따라 우선순위를 분류해야 한다.

  • 고위험: 고객 데이터·재정 정보·핵심 인프라에 직접 접근하는 클라우드 제공업체, MSP(관리형 서비스 제공업체), 핵심 소프트웨어 벤더
  • 중간 리스크: 내부 도구 접근 또는 제한적 데이터 처리를 하는 마케팅 대행사, 컨설팅 업체
  • 저위험: 사무 용품 공급자, 시설 관리 업체 등 최소 접근만 필요한 업체

고위험 공급업체에 대해서는 분기별 보안 검토, 계약상 감사 권한 요구, 실시간 모니터링 연동 등 강화된 통제를 적용해야 한다.

계약 전 보안 평가

보안은 계약 체결 후에 고려하는 사항이 아니라, 공급업체 선정 과정의 핵심 평가 항목이어야 한다.

평가 체크리스트

  • [ ] 보안 정책 문서 검토: 정보 보안 정책, 접근 통제 정책, 데이터 분류 정책이 공식적으로 문서화되어 있는가
  • [ ] 접근 통제 메커니즘: 역할 기반 접근 제어(RBAC), 최소 권한 원칙 적용 현황
  • [ ] 데이터 보호 방안: 전송 중/저장 중 암호화 표준 적용 여부
  • [ ] 사고 대응 절차: 보안 사건 발생 시 탐지·보고·대응·회복 프로세스
  • [ ] 준수 인증 현황: SOC 2 Type II, ISO/IEC 27001, PCI DSS 등 적용 분야별 인증
  • [ ] 과거 보안 기록: 과거 침투 이력, 공개된 침해 사건, 규제 제재 기록

계약서 보안 조항 (조직별 요구사항 예시)

CISA와 NIST는 모든 조직에 특정 통지 기간이나 암호화 알고리즘을 강제하는 보편적 의무를 부과하지 않는다. 조직은 자신의 위험 허용 범위와 규제 환경에 맞춰 다음 요건 중 일부를 계약서에 포함할 수 있다.

조항 항목 예시 요구사항 (조직별 조정 필요) 참고
데이터 보호 암호화 표준, 데이터 보관 기간, 파기 절차 조직의 데이터 분류 기준에 따라 정의
침해 통지 발견 후 일정 기간 내 서면 통지 (조직별 조정) GDPR 72시간, PCI DSS는 카드브랜드/취득사 계약에 따라 통지 요건 상이
접근 관리 MFA 의무화, 역할 기반 권한, 세션 시간 제한 NIST SP 800-63B/CISA는 위험 기반 계약 통제 권고 (모든 공급업체에 대한 보편 의무 아님)
암호화 전송 중 TLS, 저장 중 AES 이상 (조직별 수준) NIST SP 800-57에서 알고리즘 권장사항 제공
감사권 연차별 보안 감사 또는 제3자 검증 결과 제출 SOC 2 Type II 리포트 참고
데이터 삭제 계약 종료 후 일정 기간 내 데이터 완전 삭제 및 증빙 조직별 데이터 파기 정책 참조
SBOM 제공 사용 소프트웨어 구성품 목록 제공 (주기 조직별 정의) NTIA에서 SBOM 최소 요소 정의
로그 제공 접근 로그·변경 로그 보관 (기간 조직별 정의) 조직의 탐지/대응 요구사항에 맞춰 설정
복구 요건 RTO/RPO 목표 정의 (조직별 서비스 중요도 기준) 조직의 BCP/DRP 기준에 따름

참고: 위 표의 수치는 특정 규제나 표준에서 모든 조직에 강제하는 보편적 의무가 아니다. 조직은 자신의 데이터 민감도, 규제 준수 의무, 위험 허용 범위에 맞춰 적절한 수준을 계약 조항으로 정의해야 한다.

접근 통제 및 권한 관리

공급업체에게 필요한 만큼의 접근 권한만 부여하고, 정기적으로 검토·회수하는 것이 가장 효과적인 통제 전략이다.

최소 권한 원칙 적용

공급업체 A가 단일 애플리케이션에 접근해야 한다면, 전체 기업 네트워크나 다른 시스템에 대한 접근 권한은 부여하지 않아야 한다.

  • 네트워크 분리: 공급업체 전용 네트워크 세그먼트 또는 VPN으로 접근 경로 제한
  • 역할 기반 접근: 업무 수행에 필요한 최소 권한만 할당 (예: 읽기 전용, 특정 폴더 접근만)
  • 세션 관리: 세션 자동 타임아웃 (15~30분), 동시 세션 수 제한
  • 권한 회수: 계약 종료 또는 업무 변경 시 24시간 내 접근 권한 완전 회수

MFA 및 세션 통제

NIST SP 800-63B는 인증 강도를 위험 평가에 따라 단계화하며, CISA도 MFA 도입을 권고한다. 이는 모든 공급업체에 강제하는 보편 의무가 아니라, 조직이 위험 기반 평가 후 계약 통제로 채택할 수 있는 권고사항이다.

  • MFA 적용: 고위험 공급업체의 외부 접근은 패스워드 단독 인증 금지 (위험 기반 적용)
  • FIDO2/WebAuthn 권장: NIST SP 800-63B에서 피싱 방지 인증 방식 우선 권장 (고위험 환경 대상)
  • 세션 토큰 무효화: 의심 활동 발생 시 즉시 모든 세션 무효화 가능
  • 접근 로그 모니터링: 비정상 시간/위치 접근 시도 실시간 경고

정기 권한 검토

검토 항목 주기 담당
활성 계정 목록 월별 IAM 운영팀
불필요한 권한 회수 분기별 보안팀 + 각 부서
비활성 계정 삭제 장기 미사용 계정 정기 삭제 IAM 운영팀
공급업체 접근 매핑 반기별 CISO/보안팀

공급망 보안 및 기술적 통제

NIST CSF 2.0의 공급망 리스크 관리 기능(GV.SC)과 CISA 제3자 리스크 관리 권고를 기준으로, 기술적 통제를 구체화한다. NIST SP 800-161 Rev.1은 Withdrawn 상태로 교체되었으나, NIST CSF 2.0은 이를 C-SCRM(Cybersecurity Supply Chain Risk Management) 관련 심화 정보로 참조한다.

SBOM 및 VEX 관리

소프트웨어 구성품 목록(SBOM - Software Bill of Materials)과 취약성 영향 교환(VEX - Vulnerability Exploitability eXchange)은 공급망 투명성을 확보하는 핵심 문서다.

  • SBOM 요구: 제3자 소프트웨어 제공업체가 CycloneDX 또는 SPDX 형식의 SBOM을 제공하도록 요구
  • VEX 활용: 공개된 CVE 중 실제 해당 제품/버전에 적용되는지 판단하여 불필요한 패치 작업 최소화
  • 자동 스캔: 공급업체 제공 소프트웨어를 내부 취약점 스캐너로 정기 분석

NTIA(National Telecommunications and Information Administration)는 2021년 「Software Supply Chain Security: Software Bill of Materials」에서 SBOM의 최소 7개 데이터 필드를 정의한다. 컴포넌트 이름과 버전(Component Name, Version), 공급업체명(Supplier Name), 컴포넌트 간 종속성 관계(Dependencies), 기타 고유 식별자(Other Unique Identifiers), SBOM 데이터 작성자(Author of SBOM Data), 생성 시각(Timestamp)가 포함된다. 미국 연방정부는 2021년 행정명령 EO 14028에 따라 연방정부에 공급하는 소프트웨어에 대해 SBOM 제출을 요구하나, 이 요건은 비정부 조직에 직접 적용되는 사항은 아니다. 비정부 조직도 자체 정책이나 계약 조항으로 SBOM 요구를 채택할 수 있다.

NIST CSF 2.0 기반 통제 매핑

NIST CSF 2.0은 2024년에 업데이트되면서 공급망 리스크 관리 범주를 "Identify" 기능에서 "Governance" 기능으로 이전했다.

NIST CSF 2.0 기능 제3자 리스크 관련 통제 적용 방법
Governance (거버넌스) Supply Chain Risk Management (GV.SC) 공급업체 인벤토리·리스크 분류·의존성 매핑·외부 리스크 거버넌스
Protect (보호) Access Control (PR.AA), Data Protection (PR.DS) 최소 권한·MFA·암호화·네트워크 세그먼테이션
Detect (탐지) Anomalies (DE.AE), Continuous Monitoring (DE.CM) 실시간 접근 로그 모니터링·비정상 패턴 탐지
Respond (대응) Response Planning (RS.RP), Communications (RS.CO) 공급업체별 사고 대응 절차·통지 체제
Recover (복구) Recovery Planning (RC.RP) RTO/RPO 목표·백업 검증·복구 훈련

지속적 모니터링

계약 체결 후 보안 평가가 종료되는 것이 아니다. 공급업체의 보안态势는 계속 변화한다.

  • 자동 취약점 스캔: 공급업체-facing 외부 시스템의 정기 스캔
  • 보안 이벤트 모니터링: 공급업체 침해 사건 관련 뉴스·보안 애드버토리 실시간 추적
  • 준수 상태 검증: 연차별 SOC 2 리포트 또는 ISO 인증 갱신 확인
  • 하위 계약자 추적: 공급업체의 공급업체(2차/3차) 정보 수집 및 리스크 평가

사고 통지 및 복구 체제

강력한 보안 프로그램도 모든 리스크를 제거할 수 없다. 공급업체가 침해당했을 때 조직이 어떻게 대응하느냐가 손실 규모를 결정한다.

계약상 사고 통지 요건 (조직별 예시)

항목 예시 요구사항 참고
통지 기간 침해 발견 후 일정 기간 내 초보 통지, 상세 보고서 제출 (조직별 조정) GDPR은 72시간 의무, PCI DSS는 적용 카드브랜드/취득사 계약에 따라 통지 요건 상이
통지 내용 침해 유형·영향 데이터·취약점·대응 현황·기대 복구 일정 조직의 IR 절차와 연동
통지 경로 지정된 보안 담당자 이메일 + 비상 연락처 24시간 비상 연락처 설정
반복 보고 사안 해결까지 정기 진행 상황 보고 조직별 보고 주기 정의

참고: 특정 통지 기간(24시간, 72시간 등)은 모든 조직에 적용되는 보편적 의무가 아니다. GDPR은 개인 데이터 침해 시 72시간 통지를 의무화하며, PCI DSS의 통지 요건은 적용되는 카드브랜드와 취득사 계약 조건에 따라 상이하다. 조직은 자신의 규제 환경에 맞춰 적절한 통지 기간을 계약 조항으로 정의해야 한다.

로그 제공 및 공유

공급업체는 다음 로그를 조직이 정의한 기간 동안 보관하고, 요청 시 제공해야 한다.

  • 접근 로그: 누가, 언제, 어디에 접근했는지
  • 변경 로그: 설정 변경·권한 변경·소프트웨어 업데이트 기록
  • 사고 로그: 보안 이벤트·침투 시도·악성 활동 탐지 기록
  • 백업 로그: 백업 실행·복구 테스트 기록

참고: 특정 보관 기간(예: 90일)은 보편적 의무가 아니다. 조직은 자신의 탐지/대응 요구사항과 규제 준수 의무에 맞춰 적절한 보관 기간을 정의해야 한다. SOX(Sarbanes-Oxley Act)의 7년 보관 요건은 공시기업의 회계 감사 기록·내부 통제 문서에 관한 규정이며, HIPAA의 6년 보관 요건은 개인건강정보(PHI) 관련 정책·절차 문서를 대상으로 한다. 두 제도 모두 일반적인 IT 보안 로그의 보존 기간을 정하는 근거는 아니다.

복구 및 비즈니스 연속성

  • RTO(Recovery Time Objective): 핵심 서비스 복구 목표 시간 정의 (조직별 서비스 중요도 기준)
  • RPO(Recovery Point Objective): 데이터 손실 최소화를 위한 백업 간격 정의 (조직별 기준)
  • 복구 테스트: 연 1~2회 공급업체와 공동 복구 훈련 수행
  • 대체 공급체비: 핵심 서비스의 백업 공급체 미리 선정 및 계약 준비

참고: RTO/RPO 수치는 조직의 비즈니스 중요도에 따라 정의되는 예시다. 금융/의료 등 고가용성 조직은 더 엄격한 목표를 설정할 수 있으며, 일반 기업은 더 유연한 목표를 설정할 수 있다.

실행 점검표

다음 점검표를 조직의 제3자 리스크 관리 성숙도 평가에 활용한다.

기본 통제 (모든 조직 필수)

  • [ ] 공급업체 인벤토리가 최신 상태이며 접근 권한이 매핑되어 있다
  • [ ] 고위험 공급업체 계정에 MFA가 적용되어 있다
  • [ ] 최소 권한 원칙이 적용되고 불필요한 접근이 제거되어 있다
  • [ ] 계약서에 보안 조항(데이터 보호·침해 통지·암호화)이 포함되어 있다
  • [ ] 비활성 공급업체 계정이 정기적으로 삭제되어 있다
  • [ ] 공급업체 침해 사건에 대비한 사고 대응 절차가 문서화되어 있다

강화 통제 (고위험 공급업체 대상)

  • [ ] 분기별 보안 평가 또는 검증 결과를 공급업체로부터 수령하고 있다
  • [ ] SBOM/VEX 문서를 정기적으로 제공하고 있다
  • [ ] 실시간 접근 로그 모니터링이 구성되어 있다
  • [ ] 연 2회 이상 공동 복구 훈련이 수행되고 있다
  • [ ] 하위 계약자(2차/3차)에 대한 리스크 평가가 이루어지고 있다
  • [ ] NIST CSF 2.0 GV.SC 카테고리에 기반한 통제 점검이 반기별로 수행된다

결론

제3자 사이버 리스크 관리는 단발성 작업이 아니라 지속적인 프로세스다. 공급업체 생태계를 파악하고, 계약 전 보안을 평가하며, 접근 권한을 최소로 유지하고, 지속적 모니터링을 수행하고, 사고 통지 체제를 확립하는 것이 핵심이다.

CISA와 NIST가 제시하는 프레임워크는 출발점이다. NIST CSF 2.0의 Governance(GV.SC) 기능이 공급망 리스크 관리의 핵심 기준이 되며, NIST SP 800-161 Rev.1은 Withdrawn 상태로 교체되었으나 CSF 2.0은 이를 C-SCRM 관련 심화 정보로 참조한다. 조직의 실제 공급망 구조와 비즈니스 중요도에 맞춰 통제를 구체화하고, 점검표를 정기적으로 실행하는 것이 실질적인 방어력을 높이는 길이다. 방화벽 내부만 보호하는 시대는 지났다. 연결된 모든 파트너의 보안을 이해하고 통제하는 것이, 오늘날 기업 보안의 새로운 표준이다.

참고문헌

  1. Original Article - Beyond Your Firewall: Managing Third Party Cyber Risks
    https://medium.com/@raksha.acceligize/beyond-your-firewall-managing-third-party-cyber-risks-before-they-become-your-problem-9c9410ccfd28

  2. CISA - Third-Party Risk Management
    https://www.cisa.gov/

  3. NIST CSF 2.0 - Cybersecurity Framework
    https://www.nist.gov/cyberframework

  4. C-SCRM - Cybersecurity Supply Chain Risk Management
    https://csrc.nist.gov/projects/cross-sector-cybersecurity-reference-model

  5. NIST SP 800-218 Rev.1 - Secure Software Development Framework (SSDF)
    https://csrc.nist.gov/pubs/sp/800-218/rev-1/final

  6. NIST SP 800-63B - Digital Identity Guidelines
    https://pages.nist.gov/800-63-1/sp800-63b.html

  7. NTIA - Software Supply Chain Security: Software Bill of Materials
    https://www.ntia.gov/page/ntia-report-software-supply-chain-security-software-bill-materials

  8. Change Healthcare Cyberattack (CISA Advisory)
    https://www.cisa.gov/news-events/cybersecurity-articles/federal-response-february-2024-change-healthcare-cyber-incident


본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.

댓글 (0)

댓글을 작성하려면 로그인이 필요합니다.

로그인

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

IT 도구 서랍

→ Unix: 2025-01-15T09:30:00
→ 날짜: 1736934600

→ ASCII: ABC
→ 문자: 65 66 67

ASCII 코드표 — 클릭하면 입력란에 추가

DecHex약어설명
DecHex문자
DecHex문자

→ 유니코드: 홍길동
→ 문자: \ud64d\uae38\ub3d9