IEC 62443를 처음 검색하면 표준 번호부터 여러 개 나오기 때문에 상당히 복잡하게 느껴집니다.

스마트공장 담당자 입장에서는 더 단순한 질문이 궁금할 수 있습니다.

“우리 공장에도 IEC 62443가 필요한가?”

“어떤 제품이 대상인가?”

“인증을 받으려면 보안솔루션부터 설치해야 하나?”

IEC 62443를 이해할 때 가장 먼저 알아야 할 것은 이것입니다.

IEC 62443는 특정 보안제품 하나를 의미하는 것이 아니라 산업자동화 및 제어시스템을 안전하게 개발하고 운영하기 위한 일련의 국제 보안 표준입니다.

PLC, HMI, SCADA, 산업용 PC, 네트워크 장비처럼 생산현장에서 사용하는 시스템은 일반 사무용 IT 환경과 운영조건이 다릅니다.

그래서 스마트공장이나 산업제어시스템의 보안을 준비한다면 일반적인 PC 보안만 생각하기보다 설비의 안정적인 운영까지 고려한 OT 보안체계가 필요합니다.

IEC 62443를 아주 쉽게 설명하면?

공장에 생산설비가 있다고 생각해보겠습니다.

설비 하나만 놓고 보면 문제가 없어 보일 수 있습니다.

하지만 실제 공장에서는 여러 장비가 연결됩니다.

ERP → MES → 생산서버 → 산업용 PC → PLC → 생산설비

여기에 외부 유지보수 업체의 VPN 접속과 원격지원까지 추가될 수 있습니다.

그러면 보안은 장비 하나의 문제가 아닙니다.

다음과 같은 것들을 모두 생각해야 합니다.

• 누가 시스템에 접속할 수 있는가?
• 어떤 장비끼리 통신할 수 있는가?
• 관리자 권한은 누구에게 있는가?
• 보안사고가 발생하면 어떻게 확인하는가?
• 제품은 처음부터 안전하게 개발됐는가?
• 운영 중 발견된 취약점은 어떻게 관리하는가?

IEC 62443는 이런 산업현장의 보안 문제를 제품·시스템·개발과정·운영조직 등 여러 관점에서 나누어 관리하도록 만든 표준체계라고 이해하면 쉽습니다.

IEC 62443가 일반 IT 보안과 다른 이유

일반적인 회사 PC에서 문제가 생기면 재부팅하거나 업데이트한 뒤 다시 사용할 수 있습니다.

생산현장은 상황이 다를 수 있습니다.

공장을 운영하는 PLC나 산업용 컴퓨터를 마음대로 중지하면 생산라인 전체에 영향을 줄 수 있기 때문입니다.

예를 들어 보안 업데이트 하나를 적용하는 데도 다음 내용을 고려해야 합니다.

• 설비를 정지해도 되는가?
• 생산계획에 영향을 주지 않는가?
• 기존 프로그램과 충돌하지 않는가?
• 통신이 정상적으로 유지되는가?
• 문제가 생기면 이전 상태로 복구할 수 있는가?

그래서 OT 보안에서는 단순히 “최신 업데이트를 적용하세요”라는 접근만으로 해결하기 어렵습니다.

보안과 가용성을 동시에 생각해야 한다는 것이 핵심입니다.

IT와 OT의 차이를 먼저 이해하고 싶다면 아래 글을 함께 보면 이해하기 쉽습니다.

IT 보안과 OT 보안 차이｜스마트공장 보안이 일반 회사와 다른 이유

IEC 62443는 하나의 규격이 아니다

IEC 62443를 처음 보는 사람이 가장 많이 헷갈리는 부분입니다.

“IEC 62443 인증을 받는다”고 한 문장으로 말하기도 하지만 실제 표준은 여러 파트로 나뉩니다.

대략적으로 보면 다음처럼 이해할 수 있습니다.

예를 들어 장비 제조사가 보안기능이 있는 산업용 제품을 개발하는 경우와, 공장을 운영하는 회사가 전체 생산시스템의 보안을 관리하는 경우는 같은 기준만 볼 필요가 없습니다.

따라서 가장 먼저 할 일은 “IEC 62443 인증이 필요하다”가 아니라 우리 회사가 어떤 역할에 해당하는지 확인하는 것입니다.

IEC 62443-2 계열은 무엇을 보는 걸까?

쉽게 말하면 조직과 운영관리 측면을 보는 영역입니다.

공장에서 보안제품을 몇 개 설치했다고 해서 보안관리가 완성되는 것은 아닙니다.

예를 들어 다음 질문에 답할 수 있어야 합니다.

• 보안 담당자는 누구인가?
• 계정은 어떻게 생성하고 삭제하는가?
• 외부업체 접속은 어떻게 관리하는가?
• 사고가 발생하면 누가 대응하는가?
• 보안패치는 누가 검토하는가?
• 백업과 복구는 어떻게 하는가?
• 직원 보안교육은 어떻게 진행하는가?

즉, 장비보다 사람과 절차에 가까운 영역도 중요합니다.

중소 제조기업에서 IEC 62443를 준비한다면 비싼 솔루션부터 구매하기보다 현재 회사의 보안업무가 어떻게 운영되는지를 먼저 정리하는 것이 좋습니다.

IEC 62443-3 계열은 무엇을 보는 걸까?

IEC 62443-3 계열에서는 산업제어시스템 전체의 보안을 생각할 수 있습니다.

개별 PLC 하나가 안전한지만 확인하는 것이 아니라 공장 시스템이 어떤 구조로 연결되어 있는지를 봅니다.

예를 들어,

인터넷 → 방화벽 → 업무망 → 생산망 → PLC

구조가 있다고 생각해보겠습니다.

이때 모든 장비가 서로 자유롭게 통신할 필요는 없습니다.

업무상 필요한 시스템끼리만 연결하고 중요도가 다른 구간을 나눠 관리하는 방식을 고려할 수 있습니다.

이 과정에서 자주 등장하는 개념이 Zone과 Conduit입니다.

어렵게 생각할 필요는 없습니다.

Zone

보안 특성이 비슷한 시스템을 묶은 구역입니다.

예를 들어,

• 사무업무 구역
• 생산관리 구역
• PLC 제어 구역
• 중요설비 구역

처럼 나눌 수 있습니다.

Conduit

각 구역 사이에서 통신이 이루어지는 경로라고 이해할 수 있습니다.

핵심은 모든 장비를 한 네트워크에 넣는 것이 아니라 어떤 시스템과 어떤 시스템이 통신해야 하는지 명확하게 만드는 것입니다.

IEC 62443의 Security Level은 무엇인가?

IEC 62443를 알아보다 보면 SL, Security Level이라는 용어도 만나게 됩니다.

단순히 숫자가 높을수록 무조건 좋은 제품이라는 의미로만 이해하면 안 됩니다.

보호해야 하는 시스템과 예상되는 위협 수준에 따라 필요한 보안수준을 판단하는 개념에 가깝습니다.

일반적으로 SL1부터 SL4까지의 수준이 사용됩니다.

아주 쉽게 개념만 잡으면 다음과 같습니다.

SL1

우발적이거나 단순한 보안위험에 대한 기본적인 보호

SL2

낮은 수준의 자원과 일반적인 기술을 가진 공격에 대한 보호

SL3

전문적인 기술과 비교적 충분한 자원을 가진 공격자를 고려한 보호

SL4

매우 높은 수준의 자원과 전문성을 가진 공격까지 고려하는 높은 수준의 보호

중요한 것은 모든 시스템을 무조건 높은 보안수준으로 만드는 것이 아닙니다.

예를 들어 일반 모니터링 장비와 핵심 생산라인을 제어하는 시스템은 위험도가 다를 수 있습니다.

따라서 자산의 중요도와 예상되는 위험을 분석한 뒤 적절한 보안수준을 정하는 것이 필요합니다.

IEC 62443-4 계열은 제품 개발회사에서 중요하다

산업용 장비나 소프트웨어를 개발해 판매하는 기업이라면 IEC 62443-4 계열을 눈여겨볼 필요가 있습니다.

특히 중요한 생각은 제품을 만든 뒤 마지막에 보안을 붙이는 것이 아니라 개발과정에서부터 보안을 고려한다는 것입니다.

예를 들어 제품을 개발하면서 다음 내용을 관리할 수 있습니다.

• 보안 요구사항
• 위협 분석
• 안전한 개발방법
• 소스코드 관리
• 취약점 처리
• 업데이트 정책
• 보안 테스트
• 제품 출시 후 취약점 대응

이를 흔히 Secure Development Lifecycle, 즉 안전한 개발 생명주기 관점으로 생각할 수 있습니다.

중소기업에서도 처음부터 거대한 개발관리 시스템이 필요한 것은 아닙니다.

중요한 것은 최소한 다음 질문에 답할 수 있도록 만드는 것입니다.

제품에 어떤 보안 요구사항을 적용했는가?

발견된 취약점을 누가 처리하는가?

업데이트는 어떻게 제공하는가?

개발자가 퇴사하면 접근권한은 삭제되는가?

스마트공장이라면 무엇부터 준비해야 할까?

IEC 62443를 처음 접하면 문서부터 만들려고 하기 쉽습니다.

하지만 실제 현장을 먼저 파악하는 편이 좋습니다.

1단계. 생산설비 목록 만들기

먼저 무엇을 보호해야 하는지 확인합니다.

다음 항목 정도부터 정리할 수 있습니다.

• PLC
• HMI
• 산업용 PC
• 서버
• 스위치
• 방화벽
• 로봇
• 센서
• 원격접속 장비

가능하다면 IP 주소, 제조사, 모델명, 운영체제, 담당자도 함께 기록합니다.

2단계. 네트워크 구조 그리기

전문적인 도면부터 만들 필요는 없습니다.

현재 시스템이 어떻게 연결되는지만 간단하게 그려봅니다.

예를 들어,

인터넷 → 업무망 → MES → 생산서버 → PLC

정도로 시작할 수 있습니다.

그리고 외부업체 VPN이나 원격접속 경로도 함께 표시합니다.

직접 그림을 그려보면 생각보다 쉽게 위험한 연결을 발견할 수 있습니다.

3단계. 외부접속 확인하기

스마트공장에서는 설비업체가 원격으로 유지보수하는 경우가 많습니다.

다음 항목을 확인해보는 것이 좋습니다.

• 외부업체 계정은 몇 개인가?
• 공용계정을 사용하는가?
• VPN을 사용하는가?
• 접근 가능한 설비는 제한되어 있는가?
• 작업 후 세션이 종료되는가?
• 접속기록이 남는가?
• 계약 종료 후 계정을 삭제하는가?

원격접속은 편리하지만 생산망으로 들어오는 중요한 경로이기도 합니다.

4단계. 계정과 권한 정리하기

보안에서 가장 기본적인 부분입니다.

관리자 계정을 여러 사람이 함께 사용한다면 실제 작업자를 추적하기 어렵습니다.

가능하다면 사용자별 계정을 발급하고 업무에 필요한 만큼만 권한을 부여하는 것이 좋습니다.

특히 다음 계정은 정기적으로 확인할 필요가 있습니다.

• 관리자 계정
• 퇴사자 계정
• 외부업체 계정
• 장기 미사용 계정
• 원격접속 계정

5단계. 백업과 복구 확인하기

OT 보안의 목적은 공격을 막는 것만이 아닙니다.

문제가 생겨도 공장을 다시 가동할 수 있어야 합니다.

그래서 다음 질문이 중요합니다.

PLC 프로그램이 삭제되면 복구할 수 있는가?

산업용 PC가 고장 나면 설정을 다시 만들 수 있는가?

생산서버가 멈추면 백업에서 복원할 수 있는가?

백업파일의 존재만 확인하지 말고 실제 복원 가능 여부까지 점검하는 것이 좋습니다.

6단계. 패치와 취약점 관리방법 정하기

OT 환경에서는 최신 업데이트가 나왔다고 무조건 바로 설치하기 어려울 수 있습니다.

그래서 다음 과정이 필요합니다.

취약점 확인 → 영향도 판단 → 제조사 권고 확인 → 테스트 → 생산일정 조율 → 적용

업데이트하지 않는 것도 위험하지만 충분한 검토 없이 생산설비에 바로 적용하는 것도 문제가 될 수 있습니다.

회사 상황에 맞는 패치관리 절차를 만드는 것이 중요합니다.

IEC 62443 준비 체크리스트

현재 우리 회사의 상태를 아래 항목으로 확인해볼 수 있습니다.

• 생산망 장비 목록이 있는가?
• PLC와 산업용 PC의 담당자를 알고 있는가?
• 전체 네트워크 연결 구조를 알고 있는가?
• IT망과 OT망의 연결지점을 파악하고 있는가?
• 외부에서 접속 가능한 경로를 알고 있는가?
• 외부업체 계정을 관리하고 있는가?
• 관리자 계정을 사용자별로 관리하는가?
• 사용하지 않는 계정을 삭제하는가?
• 주요 시스템 로그를 확인할 수 있는가?
• 취약점과 패치를 관리하는 담당자가 있는가?
• 중요 설비를 백업하고 있는가?
• 실제 복구방법을 알고 있는가?
• 보안사고 발생 시 연락할 담당자가 정해져 있는가?
• 시스템 변경사항을 기록하고 있는가?
• 제품 또는 시스템의 보안 요구사항을 정리하고 있는가?

답을 모르는 항목이 많다고 해서 바로 인증을 포기할 필요는 없습니다.

오히려 모르는 항목을 하나씩 확인하는 과정이 IEC 62443 준비의 시작이라고 볼 수 있습니다.

IEC 62443 인증을 준비할 때 흔히 하는 실수

인증기관부터 알아보는 것

가장 먼저 해야 할 일은 인증비용을 알아보는 것이 아닐 수 있습니다.

우리 회사가 제품 제조사인지, 시스템 통합업체인지, 자산 운영자인지부터 구분해야 합니다.

그래야 어떤 IEC 62443 영역을 확인해야 할지가 명확해집니다.

보안제품만 추가하면 된다고 생각하는 것

방화벽이나 보안솔루션은 중요한 수단입니다.

하지만 계정관리, 개발절차, 취약점관리, 백업, 사고대응 같은 운영체계가 없다면 장비만으로 해결하기 어렵습니다.

문서만 먼저 만드는 것

현실과 다른 문서는 실제 운영에서 도움이 되지 않습니다.

먼저 현장을 조사하고 실제 업무방식에 맞춰 절차를 정리하는 것이 좋습니다.

생산팀을 빼고 IT팀만 준비하는 것

OT 보안은 생산현장을 이해해야 합니다.

IT 담당자가 안전하다고 판단한 설정이 생산설비의 가용성에 영향을 줄 수도 있습니다.

따라서 최소한 다음 담당자가 함께 검토하는 것이 좋습니다.

보안·IT 담당자

생산 담당자

설비·자동화 담당자

제품 개발 담당자

중소기업은 비싼 솔루션부터 사야 할까?

반드시 그렇지는 않습니다.

IEC 62443를 준비하면서 현재 상태를 점검해보면 비용 없이 개선할 수 있는 항목도 많습니다.

예를 들면 다음과 같습니다.

• 사용하지 않는 계정 삭제
• 관리자 공용계정 최소화
• 외부업체 접속기간 제한
• 장비목록 작성
• 네트워크 구성도 작성
• 백업 위치 확인
• 담당자 지정
• 보안사고 연락체계 만들기
• 패치관리 기록 남기기

이런 기본관리가 되어 있지 않은 상태에서 비싼 솔루션부터 구입하면 실제 운영과 연결되지 않을 수 있습니다.

보안제품은 관리체계를 대신하는 것이 아니라 관리체계를 구현하는 도구라고 생각하는 편이 좋습니다.

IEC 62443와 제로트러스트는 같은 것일까?

같은 것은 아닙니다.

제로트러스트는 사용자의 신원과 접근권한을 지속적으로 확인하고 최소한의 권한만 허용하는 보안 접근방식입니다.

IEC 62443는 산업자동화 및 제어시스템의 보안을 폭넓게 다루는 표준체계입니다.

하지만 실제 적용에서는 서로 연결되는 부분이 있습니다.

예를 들어,

• 사용자별 계정
• 최소 권한
• 접근통제
• 네트워크 구분
• 외부접속 관리
• 지속적인 모니터링

같은 기본적인 보안원칙은 함께 활용될 수 있습니다.

IEC 62443 준비의 시작은 보안제품이 아니라 현장 파악이다

IEC 62443를 처음 공부할 때 가장 어려운 것은 표준의 용어와 번호입니다.

하지만 실무에서는 더 단순하게 접근할 수 있습니다.

먼저 다음 질문에 답해보면 됩니다.

우리 공장에는 어떤 장비가 있는가?

각 장비는 어떻게 연결되어 있는가?

누가 접속할 수 있는가?

외부에서는 어디를 통해 들어오는가?

문제가 발생하면 어떻게 복구할 것인가?

발견된 취약점은 누가 관리하는가?

이 질문에 하나씩 답하다 보면 필요한 보안조치와 부족한 관리항목이 자연스럽게 보이기 시작합니다.

IEC 62443를 준비한다고 해서 첫날부터 수백 페이지의 규정을 만들어야 하는 것은 아닙니다.

중소 제조기업이라면 생산망 장비 목록과 네트워크 구성도 한 장을 만드는 것부터 시작하는 것이 훨씬 현실적입니다.

자주 묻는 질문

IEC 62443란 무엇인가요?

산업자동화 및 제어시스템을 안전하게 개발하고 운영하기 위한 국제 사이버보안 표준 시리즈입니다. 조직, 시스템, 제품 및 개발과정 등 여러 영역을 다룹니다.

IEC 62443는 스마트공장에도 적용할 수 있나요?

PLC, HMI, SCADA, 산업용 PC 등 산업제어시스템을 사용하는 제조현장의 보안체계를 설계하고 점검할 때 참고할 수 있습니다.

IEC 62443 인증은 하나인가요?

IEC 62443는 여러 파트로 구성된 표준 시리즈입니다. 기업의 역할과 제품·시스템·개발과정 등에 따라 검토해야 하는 영역이 달라질 수 있으므로 단순히 하나의 인증으로 이해하지 않는 것이 좋습니다.

IEC 62443 Security Level이란 무엇인가요?

산업제어시스템에서 고려해야 하는 보안위협과 필요한 보호 수준을 구분하기 위한 개념입니다. 무조건 높은 등급을 적용하기보다 시스템의 위험도와 중요성을 고려해 목표 수준을 설정하는 것이 중요합니다.

중소기업은 무엇부터 준비해야 하나요?

생산설비와 네트워크 장비 목록을 작성하고 IT망과 OT망의 연결 구조, 외부접속 경로, 관리자 계정, 백업 및 복구방법을 파악하는 것부터 시작하는 것이 좋습니다.

IEC 62443를 준비하려면 방화벽부터 사야 하나요?

반드시 그렇지는 않습니다. 장비목록, 계정관리, 외부접속 관리, 백업, 취약점 관리와 같은 기본체계를 먼저 확인한 뒤 부족한 부분에 필요한 보안기술을 적용하는 방식이 현실적입니다.

CNAPP란 무엇인지 검색해보면 CSPM, CWPP, CIEM, 컨테이너, 쿠버네티스 같은 생소한 용어가 한꺼번에 나옵니다.

클라우드를 전문적으로 운영하지 않는 중소기업 담당자라면 첫 문장부터 어렵게 느껴질 수 있습니다.

하지만 CNAPP의 기본 개념은 생각보다 단순합니다.

클라우드에 흩어져 있는 여러 보안문제를 각각 따로 관리하지 말고 하나의 관점에서 확인하자는 것입니다.

예를 들어 회사 홈페이지와 내부 업무시스템을 AWS에서 운영하고 있다고 생각해보겠습니다.

서버만 안전하면 끝나는 것이 아닙니다.

누가 관리자 권한을 가지고 있는지, 저장공간이 외부에 공개되어 있지는 않은지, 취약한 서버가 없는지, 컨테이너 설정은 안전한지, 개발자가 실수로 인증키를 노출하지 않았는지까지 함께 확인해야 합니다.

이처럼 클라우드 환경이 복잡해지면서 등장한 통합적인 보안 접근이 CNAPP입니다.

CNAPP란 무엇일까?

CNAPP는 Cloud Native Application Protection Platform의 약자입니다.

쉽게 표현하면 클라우드에서 개발되고 운영되는 애플리케이션과 인프라를 여러 단계에 걸쳐 보호하는 통합 보안 플랫폼이라고 이해할 수 있습니다.

과거에는 서버 보안, 설정 점검, 접근권한, 컨테이너 보안을 각각 다른 제품으로 관리하는 경우가 많았습니다.

하지만 클라우드 환경에서는 이런 영역이 서로 연결되어 있습니다.

예를 들어 하나의 서비스에도 다음 요소가 포함될 수 있습니다.

• 클라우드 계정
• 가상서버
• 데이터베이스
• 스토리지
• 컨테이너
• 쿠버네티스
• 사용자 권한
• API
• 개발 파이프라인
• 애플리케이션

CNAPP는 이런 환경에서 발생하는 위험을 통합적으로 파악하도록 돕는 개념입니다.

일반 서버 보안과 클라우드 보안은 무엇이 다를까?

과거 회사 내부에 서버 한 대를 설치했다면 관리 대상이 비교적 명확했습니다.

서버가 어디에 있고 누가 관리하는지 눈으로 확인할 수 있었습니다.

클라우드는 다릅니다.

관리자가 몇 번의 클릭만으로 새로운 서버나 저장공간을 만들 수 있습니다.

개발자가 테스트용 자원을 만들었다가 삭제하지 않을 수도 있고, 필요 이상으로 넓은 권한을 부여할 수도 있습니다.

즉, 공격만 문제가 아니라 설정 실수와 관리 누락 역시 중요한 보안위험이 됩니다.

클라우드 보안에서는 다음 질문이 중요합니다.

현재 몇 개의 자원이 만들어져 있는가?

외부에 공개된 것은 무엇인가?

누가 관리자 권한을 가지고 있는가?

취약한 설정은 없는가?

사용하지 않는 자원이 남아 있지는 않은가?

CNAPP는 이런 질문들을 한곳에서 확인하기 위한 방향이라고 볼 수 있습니다.

CNAPP를 이해하려면 CSPM부터 알아야 한다

CNAPP를 검색하면 가장 자주 등장하는 용어 가운데 하나가 CSPM입니다.

CSPM은 Cloud Security Posture Management를 의미합니다.

쉽게 표현하면 클라우드 설정이 안전한지 계속 확인하는 기능입니다.

예를 들어 다음과 같은 문제를 찾아볼 수 있습니다.

• 저장공간이 외부에 공개됨
• 관리자 권한이 너무 넓음
• 보안그룹이 불필요하게 개방됨
• 암호화 설정이 빠짐
• 로그 기록이 꺼져 있음
• 중요한 설정이 권장기준과 다름

클라우드 환경에서는 이런 설정 하나가 보안문제로 이어질 수 있습니다.

특히 사람이 직접 수십 개, 수백 개의 클라우드 자원을 확인하기 어려워지면서 자동 점검의 필요성이 커집니다.

CSPM을 쉽게 비유하면

건물의 보안점검표와 비슷합니다.

매일 다음을 확인한다고 생각해보겠습니다.

비상문이 열려 있지 않은가?

잠겨 있어야 할 문이 열려 있지 않은가?

CCTV가 꺼져 있지 않은가?

클라우드에서도 이런 식으로 잘못된 설정을 찾아주는 역할에 가깝습니다.

CWPP란 무엇일까?

두 번째로 많이 등장하는 용어가 CWPP입니다.

Cloud Workload Protection Platform을 의미합니다.

여기서 Workload는 클라우드에서 실제로 실행되는 서버나 컨테이너 등의 작업환경이라고 이해하면 됩니다.

CSPM이 설정 상태를 확인하는 것에 가깝다면 CWPP는 실제로 동작하는 시스템 자체를 보호하는 것에 더 가깝습니다.

예를 들어 다음을 확인할 수 있습니다.

• 서버 취약점
• 악성 프로그램
• 비정상 프로세스
• 컨테이너 위험
• 실행 중인 워크로드의 이상행동

쉽게 구분하면 다음과 같습니다.

CSPM → 클라우드 설정이 안전한가?

CWPP → 실제 서버와 워크로드가 안전한가?

CIEM이란 무엇일까?

세 번째로 알아두면 좋은 것이 CIEM입니다.

Cloud Infrastructure Entitlement Management를 의미합니다.

이름은 어렵지만 핵심은 권한관리입니다.

클라우드에서는 한 사람이 매우 많은 권한을 가질 수 있습니다.

예를 들어 개발자에게 편의를 위해 관리자 권한을 줬다고 생각해보겠습니다.

처음에는 필요한 것 같았지만 시간이 지나면서 실제 업무보다 훨씬 많은 권한을 계속 가지고 있을 수 있습니다.

CIEM에서는 이런 과도한 접근권한을 찾아 관리하는 데 초점을 둡니다.

예를 들면 다음과 같은 질문입니다.

• 관리자 권한을 가진 사람은 누구인가?
• 실제 사용하는 권한은 무엇인가?
• 사용하지 않는 권한이 남아 있지 않은가?
• 퇴사자 권한이 남아 있지 않은가?
• 서비스 계정에 너무 많은 권한이 있는 것은 아닌가?

결국 제로트러스트에서 이야기하는 최소 권한 개념과도 연결됩니다.

CSPM·CWPP·CIEM 차이 한눈에 보기

제품에 따라 실제 제공 기능과 범위는 달라질 수 있습니다.

따라서 CNAPP라는 이름만 보고 제품을 선택하기보다 우리 회사에서 어떤 문제를 해결해야 하는지 먼저 확인하는 것이 중요합니다.

AWS를 사용하면 CNAPP가 반드시 필요할까?

AWS를 사용한다는 이유만으로 모든 회사가 별도의 CNAPP 제품을 바로 도입해야 하는 것은 아닙니다.

회사 규모와 클라우드 환경에 따라 다릅니다.

예를 들어 회사 홈페이지 하나를 클라우드 서버에서 운영하고 있고 관리자가 한 명뿐이라면 처음부터 복잡한 CNAPP 플랫폼이 필요한지 따져볼 필요가 있습니다.

반면 다음과 같은 환경이라면 필요성이 커질 수 있습니다.

• AWS 계정이 여러 개다.
• 개발자와 운영자가 많다.
• 서버 수가 계속 증가한다.
• 컨테이너를 사용한다.
• 쿠버네티스를 운영한다.
• 여러 클라우드를 함께 사용한다.
• 사용자 권한 관리가 복잡하다.
• 보안설정 점검을 사람이 하기 어렵다.
• 개발부터 운영까지 자동 배포한다.

즉, 클라우드를 사용하는가보다 얼마나 복잡하게 사용하는가가 더 중요합니다.

직원 20명 회사에서 AWS 서버 하나만 쓴다면?

작은 회사의 상황을 생각해보겠습니다.

직원 20명이고 회사 홈페이지와 간단한 업무서비스를 AWS에서 운영한다고 가정합니다.

이 경우 가장 먼저 해야 할 일은 CNAPP 솔루션 견적을 받는 것이 아닐 수 있습니다.

먼저 다음을 확인하는 것이 좋습니다.

관리자 계정은 몇 개인가?

필요 이상으로 관리자 계정을 많이 만들지 않았는지 확인합니다.

MFA가 적용되어 있는가?

중요한 관리자 계정에 추가 인증을 적용할 수 있습니다.

외부에 공개된 자원은 무엇인가?

서버와 저장공간 중 인터넷에서 접근할 필요가 없는 것이 공개되어 있지 않은지 확인합니다.

사용하지 않는 서버는 없는가?

테스트용으로 만들었다가 방치된 서버나 스토리지를 확인합니다.

백업은 있는가?

문제가 발생했을 때 데이터를 복구할 수 있는지 확인합니다.

이런 기본적인 관리가 우선입니다.

클라우드 보안에서 가장 많이 놓치는 것은 권한이다

클라우드는 서버를 만드는 것보다 권한을 관리하는 것이 더 어려워질 수 있습니다.

처음에는 직원 한 명에게 관리자 권한을 주고 시작합니다.

직원이 늘면서 개발자와 외주업체에도 계정을 추가합니다.

몇 년 뒤에는 누가 어떤 권한을 가지고 있는지 아무도 정확하게 모르는 상황이 생길 수 있습니다.

예를 들어 다음 계정을 확인해보는 것이 좋습니다.

• 퇴사한 직원
• 프로젝트가 끝난 외주업체
• 테스트 계정
• 오래된 서비스 계정
• 관리자 권한을 가진 개발자
• 사용 목적을 모르는 API Key

클라우드 보안에서도 결국 중요한 것은 누가 무엇을 할 수 있는가입니다.

클라우드 저장공간 공개 설정도 확인해야 한다

클라우드에서는 파일 저장공간을 쉽게 만들 수 있습니다.

업무 편의를 위해 인터넷에서 접근할 수 있도록 설정했다가 그대로 방치되는 경우도 생각할 수 있습니다.

문제는 그 안에 중요한 데이터가 들어간 뒤에도 설정이 유지되는 것입니다.

따라서 클라우드 저장공간을 관리할 때는 최소한 다음을 확인해볼 필요가 있습니다.

• 외부 공개가 필요한가?
• 누구나 접근할 수 있게 되어 있지 않은가?
• 개인정보가 저장되어 있지 않은가?
• 암호화가 필요한 데이터인가?
• 접근기록을 확인할 수 있는가?
• 사용하지 않는 저장공간은 없는가?

클라우드 보안사고가 항상 고도의 해킹 때문에 발생하는 것은 아닙니다.

단순한 설정 실수도 중요한 사고원인이 될 수 있습니다.

개발환경까지 보안 범위를 넓혀야 하는 이유

클라우드 네이티브 환경에서는 프로그램을 개발하고 배포하는 과정도 자동화되는 경우가 많습니다.

개발자가 코드를 저장하면 자동으로 테스트하고 서버에 배포하는 구조를 사용할 수 있습니다.

편리하지만 개발단계에서 발생한 문제가 운영환경까지 빠르게 이어질 수 있습니다.

예를 들어 다음 문제가 있을 수 있습니다.

• 소스코드에 API Key가 포함됨
• 취약한 오픈소스 라이브러리 사용
• 위험한 컨테이너 이미지 사용
• 잘못된 클라우드 설정이 자동 배포됨

그래서 CNAPP에서는 운영 중인 시스템뿐 아니라 개발에서 배포까지 전체 과정의 위험을 함께 보는 방향이 중요합니다.

컨테이너와 쿠버네티스를 사용하면 왜 더 복잡해질까?

전통적인 서버에서는 서버 한 대를 하나의 단위로 관리하는 것이 비교적 쉬웠습니다.

컨테이너 환경에서는 작은 실행환경이 빠르게 생성되고 사라질 수 있습니다.

쿠버네티스를 사용하면 이런 컨테이너를 여러 개 자동으로 운영하게 됩니다.

즉, 관리할 대상이 훨씬 많아집니다.

몇 대의 서버를 사람이 직접 확인하는 방식으로는 관리가 어려워질 수 있습니다.

그래서 다음과 같은 것을 자동으로 확인하는 기능이 중요해질 수 있습니다.

• 취약한 이미지
• 잘못된 설정
• 과도한 권한
• 외부 노출
• 비정상 실행
• 위험한 네트워크 연결

다만 컨테이너나 쿠버네티스를 전혀 사용하지 않는 회사라면 이 부분을 지나치게 복잡하게 고민할 필요는 없습니다.

중소기업 클라우드 보안 시작 순서

CNAPP 도입 여부를 결정하기 전에 다음 순서로 현재 환경을 정리해보는 것을 권합니다.

1단계. 클라우드 계정 파악

회사가 사용하고 있는 AWS, Azure, Google Cloud 등의 계정을 정리합니다.

개인 카드나 직원 개인 계정으로 만들어진 클라우드가 없는지도 확인합니다.

2단계. 자산 목록 만들기

현재 운영 중인 자원을 확인합니다.

• 서버
• 데이터베이스
• 스토리지
• 컨테이너
• 네트워크
• API

사용 목적과 담당자를 함께 기록하면 좋습니다.

3단계. 관리자 권한 확인

누가 관리자 권한을 가지고 있는지 확인합니다.

사용하지 않는 계정과 퇴사자 계정을 정리합니다.

4단계. 외부 공개 자원 확인

인터넷에서 접근할 필요가 없는 서버나 저장공간이 공개되어 있지 않은지 점검합니다.

5단계. 취약점 확인

오래된 운영체제나 취약한 패키지가 사용되고 있지 않은지 확인합니다.

6단계. 로그와 알림 설정

누가 언제 중요한 설정을 변경했는지 확인할 수 있도록 기록을 남깁니다.

7단계. 자동화 필요성 판단

여기까지 사람이 관리하기 어려울 정도로 환경이 커졌다면 CNAPP 등 통합적인 클라우드 보안관리 도구를 검토할 수 있습니다.

CNAPP 도입을 검토할 시점

다음 항목 가운데 여러 개가 해당된다면 CNAPP의 필요성을 검토해볼 수 있습니다.

• 클라우드 계정이 여러 개다.
• 서버와 클라우드 자원이 계속 늘어나고 있다.
• AWS 외에 다른 클라우드도 사용한다.
• 컨테이너를 사용한다.
• 쿠버네티스를 운영한다.
• 개발자 수가 많다.
• 권한구조가 복잡하다.
• 누가 관리자 권한을 가졌는지 파악하기 어렵다.
• 클라우드 설정을 사람이 정기적으로 확인하기 어렵다.
• 취약점 관리를 여러 도구에서 따로 하고 있다.
• 개발부터 배포까지 자동화되어 있다.
• 보안 관련 경고가 여러 시스템에 흩어져 있다.

반대로 대부분 해당되지 않는다면 기본적인 계정·설정·백업 관리부터 정리해도 좋습니다.

CNAPP 제품을 선택할 때 확인할 것

CNAPP라는 이름이 붙었다고 모두 같은 기능을 제공하는 것은 아닙니다.

제품을 검토한다면 다음 질문을 먼저 해보는 것이 좋습니다.

우리가 사용하는 클라우드를 지원하는가?

AWS만 사용하는지 멀티클라우드인지 확인합니다.

현재 사용 중인 보안도구와 연동할 수 있는가?

기존 SIEM이나 XDR 등을 사용하고 있다면 연동 여부도 중요합니다.

우리에게 필요한 기능이 무엇인가?

CSPM이 필요한지, 워크로드 보안이 필요한지, 권한관리가 더 중요한지 구분합니다.

경고가 너무 많이 발생하지 않는가?

좋은 보안도구라도 매일 수천 개의 경고를 쏟아낸다면 소규모 보안팀에서는 운영하기 어렵습니다.

실제 담당자가 사용할 수 있는가?

복잡한 기능보다 담당자가 이해하고 지속적으로 운영할 수 있는지가 중요합니다.

CNAPP와 SIEM·XDR은 같은 것일까?

같지는 않습니다.

역할이 일부 겹칠 수 있지만 기본적인 목적이 다릅니다.

쉽게 구분하면 다음과 같습니다.

CNAPP → 클라우드 환경 자체의 보안상태와 워크로드를 관리

SIEM → 다양한 시스템에서 발생한 로그를 통합

XDR → 여러 영역의 보안 이벤트를 연결해 위협을 탐지

회사의 환경이 커지면 서로 연동해서 사용할 수도 있습니다.

하지만 작은 기업에서는 처음부터 모든 제품을 구축할 필요는 없습니다.

현재 가장 큰 문제가 무엇인지부터 확인해야 합니다.

클라우드 보안 체크리스트

AWS나 다른 클라우드를 사용하고 있다면 아래 항목부터 확인해보세요.

• 회사가 사용하는 클라우드 계정을 모두 알고 있는가?
• 각 클라우드 계정의 담당자가 있는가?
• 관리자 권한 보유자를 알고 있는가?
• 관리자 계정에 MFA를 적용했는가?
• 퇴사자 계정을 바로 삭제하는가?
• 사용하지 않는 서버를 정리하고 있는가?
• 외부 공개 저장공간을 확인하고 있는가?
• 중요한 데이터에 암호화를 적용하고 있는가?
• 서버와 프로그램의 취약점을 관리하고 있는가?
• 중요한 설정 변경기록을 확인할 수 있는가?
• 데이터 백업이 존재하는가?
• 실제 복구가 가능한가?
• API Key와 인증정보를 안전하게 관리하는가?
• 개발자가 불필요한 관리자 권한을 가지고 있지 않은가?
• 현재 클라우드 환경을 사람이 관리할 수 있는 규모인가?

마지막 항목이 특히 중요합니다.

관리자가 현재 환경을 직접 파악하고 통제할 수 있다면 복잡한 플랫폼이 반드시 필요한 것은 아닙니다.

반대로 무엇이 만들어졌는지조차 사람이 따라가기 어려운 단계라면 자동화된 관리도구의 가치가 커집니다.

CNAPP를 도입하기 전에 반드시 해야 할 일

CNAPP를 검토하면서 제품 기능표부터 비교하기 쉽습니다.

하지만 그 전에 다음 질문에 답하는 것이 좋습니다.

우리 회사는 어떤 클라우드를 사용하는가?

중요한 자산은 무엇인가?

누가 관리자 권한을 가지고 있는가?

가장 자주 발생하는 보안문제는 무엇인가?

현재 사람이 관리하기 어려운 부분은 어디인가?

이 질문에 답하지 못하면 기능이 많은 제품을 도입해도 제대로 활용하기 어렵습니다.

결국 CNAPP는 클라우드 보안을 대신 해주는 마법 같은 시스템이 아니라 복잡해진 클라우드를 더 잘 보고 관리하도록 도와주는 도구입니다.

CNAPP란 결국 복잡해진 클라우드를 한눈에 관리하기 위한 방법이다

CNAPP란 무엇인지 어려운 용어를 모두 외울 필요는 없습니다.

핵심만 정리하면 이렇습니다.

CSPM은 설정을 보고, CWPP는 워크로드를 보고, CIEM은 권한을 봅니다.

CNAPP는 이런 여러 클라우드 보안기능을 하나의 관점에서 관리하려는 플랫폼입니다.

중소기업이라면 AWS를 사용한다는 이유만으로 당장 CNAPP를 도입할 필요는 없습니다.

먼저 계정, 관리자 권한, 외부 노출, 자산, 백업, 취약점 같은 기본적인 항목부터 확인하는 것이 좋습니다.

그리고 클라우드가 커져 사람이 모든 자원과 권한을 확인하기 어려워지는 순간이 오면 그때 자동으로 찾아주고 우선순위를 알려주는 도구의 필요성이 커질 수 있습니다.

결국 가장 먼저 해야 할 일은 CNAPP 제품의 가격을 알아보는 것이 아닙니다.

오늘 AWS 콘솔에 접속해서 현재 몇 개의 자원이 운영되고 있고 누가 관리자 권한을 가지고 있는지 확인하는 것부터 시작하면 됩니다.

자주 묻는 질문

CNAPP란 무엇인가요?

CNAPP는 Cloud Native Application Protection Platform의 약자로 클라우드 네이티브 환경의 설정, 워크로드, 권한, 취약점 등 여러 보안영역을 통합적으로 관리하는 플랫폼을 의미합니다.

AWS를 사용하면 CNAPP가 꼭 필요한가요?

모든 기업에 반드시 필요한 것은 아닙니다. 클라우드 자원이 적고 관리구조가 단순하다면 기본적인 계정·설정·취약점 관리부터 시작할 수 있습니다. 환경이 복잡해질수록 통합관리 도구의 필요성이 커질 수 있습니다.

CSPM과 CNAPP의 차이는 무엇인가요?

CSPM은 주로 클라우드의 잘못된 설정과 보안상태를 관리하는 기능입니다. CNAPP는 CSPM을 포함해 워크로드 보호와 권한관리 등 보다 넓은 클라우드 보안영역을 통합하는 개념으로 이해할 수 있습니다.

CWPP란 무엇인가요?

CWPP는 Cloud Workload Protection Platform의 약자로 클라우드에서 실행되는 서버, 가상머신, 컨테이너 등의 워크로드에서 발생하는 취약점과 위협을 보호하는 데 초점을 둡니다.

CIEM은 무엇을 관리하나요?

CIEM은 클라우드 사용자와 서비스 계정이 가진 접근권한을 파악하고 과도하거나 사용하지 않는 권한을 줄이는 데 초점을 둡니다.

중소기업의 클라우드 보안은 무엇부터 시작해야 하나요?

회사에서 사용하는 클라우드 계정과 자산 목록을 만들고 관리자 권한, MFA, 외부 공개 여부, 백업 상태를 확인하는 것부터 시작하는 것이 좋습니다.

양자내성암호 PQC라는 말을 처음 들으면 아직 먼 미래의 기술처럼 느껴질 수 있습니다.

“양자컴퓨터가 실제 회사 보안과 무슨 관계가 있을까?”

“지금 사용하는 비밀번호가 갑자기 풀리는 걸까?”

“중소기업도 벌써 준비해야 할까?”

이런 궁금증이 생길 수 있습니다.

결론부터 말하면 일반 기업이 당장 기존 암호화 시스템을 모두 교체할 필요는 없습니다.

하지만 회사가 장기간 보호해야 하는 중요정보를 가지고 있거나 인증서, VPN, 서버, 소프트웨어 제품처럼 암호기술에 의존하는 시스템을 운영한다면 어떤 암호기술을 사용하고 있는지부터 파악해두는 것은 의미가 있습니다.

PQC는 양자컴퓨터가 발전한 이후에도 안전성을 유지할 수 있도록 설계된 새로운 암호기술을 의미합니다.

중요한 것은 어려운 암호 알고리즘 이름을 외우는 것이 아닙니다.

우리 회사에서 현재 암호화가 어디에 사용되고 있고, 나중에 교체해야 할 부분이 무엇인지 알아두는 것이 실무적인 준비의 시작입니다.

PQC란 무엇일까?

PQC는 Post-Quantum Cryptography의 약자입니다.

한국에서는 보통 양자내성암호 또는 양자후암호라고 부릅니다.

아주 쉽게 말하면,

강력한 양자컴퓨터가 등장하더라도 안전하게 사용할 수 있도록 설계하는 암호기술

이라고 이해하면 됩니다.

현재 인터넷에서는 수많은 암호기술이 사용되고 있습니다.

예를 들어 우리가 웹사이트에 접속할 때 주소 앞에 HTTPS가 표시되는 것도 암호기술과 관련이 있습니다.

기업에서도 다음과 같은 곳에 암호가 사용됩니다.

• 홈페이지 HTTPS
• VPN
• 서버 인증서
• 이메일 암호화
• 전자서명
• 소프트웨어 서명
• 클라우드 통신
• API 통신
• 원격접속
• 데이터 보호

평소에는 눈에 잘 보이지 않지만 현대의 IT 시스템 상당 부분이 암호기술 위에서 작동하고 있습니다.

양자컴퓨터가 나오면 지금 암호가 모두 깨질까?

이 부분은 오해하기 쉽습니다.

양자컴퓨터가 등장한다고 해서 지금 사용하는 모든 암호가 한순간에 무용지물이 된다고 단순하게 생각할 필요는 없습니다.

영향을 받는 정도는 암호기술에 따라 다릅니다.

특히 많이 이야기되는 것이 RSA와 ECC 같은 공개키 암호체계입니다.

이런 기술은 현재 웹 통신, 인증서, 전자서명, VPN 등 다양한 곳에서 사용됩니다.

충분히 강력하고 안정적인 양자컴퓨터가 현실화되면 현재 널리 사용되는 일부 공개키 암호체계에 큰 영향을 줄 가능성이 있기 때문에 새로운 암호방식이 준비되고 있는 것입니다.

반면 AES 같은 대칭키 암호까지 RSA와 완전히 동일하게 생각할 필요는 없습니다.

즉,

“양자컴퓨터 등장 = 모든 암호 즉시 무력화”

라는 식으로 이해하기보다

“현재 널리 쓰이는 일부 핵심 공개키 암호기술을 장기적으로 다른 기술로 전환해야 한다”

정도로 이해하면 좋습니다.

RSA는 왜 계속 언급될까?

RSA는 오래전부터 널리 사용되어 온 공개키 암호방식입니다.

우리가 직접 RSA를 설정하지 않았더라도 사용하는 제품이나 서비스 내부에서 활용되고 있을 수 있습니다.

예를 들어 다음과 같은 영역입니다.

• 인증서
• 웹 통신
• VPN
• 전자서명
• 소프트웨어 서명
• 인증 시스템

현재 일반적인 컴퓨터 환경에서는 적절한 키 길이와 안전한 구성으로 사용되는 RSA가 널리 활용되고 있습니다.

하지만 미래의 충분히 강력한 양자컴퓨터에서는 현재와 다른 계산방식을 사용할 수 있기 때문에 기존 공개키 암호기술의 장기적인 안전성 문제가 제기됩니다.

그래서 PQC 전환 논의가 이루어지는 것입니다.

지금 양자컴퓨터가 RSA를 모두 해독하고 있는 것은 아니다

PQC 이야기를 접하면 회사 시스템을 당장 교체해야 할 것처럼 불안해질 수 있습니다.

하지만 이 부분은 구분해서 볼 필요가 있습니다.

현재 기업들이 사용하는 대규모 RSA 암호체계를 양자컴퓨터가 일상적으로 해독하고 있는 상황으로 이해해서는 안 됩니다.

PQC 준비의 목적은 오늘 당장 발생한 암호 붕괴에 대응하는 것이 아니라 미래의 기술변화를 대비해 긴 시간에 걸쳐 암호체계를 전환하는 것에 가깝습니다.

기업 입장에서는 급하게 모든 시스템을 교체하는 것보다 다음 질문이 더 중요합니다.

우리 회사는 어떤 암호기술을 사용하는가?

그 암호기술은 어느 제품에 들어 있는가?

필요하면 다른 방식으로 바꿀 수 있는가?

이 세 가지를 파악하는 데도 생각보다 시간이 오래 걸릴 수 있습니다.

왜 지금부터 PQC를 준비한다는 이야기가 나올까?

양자컴퓨터가 충분히 발전한 이후에 암호를 교체하면 되지 않을까 생각할 수 있습니다.

문제는 기업의 시스템을 한 번에 바꾸기 어렵다는 것입니다.

오래된 서버와 네트워크 장비는 수년 이상 사용됩니다.

산업용 장비는 10년 이상 운영하는 경우도 있습니다.

하나의 인증방식을 변경하면 연결된 프로그램과 장비를 모두 테스트해야 할 수도 있습니다.

따라서 실제 전환에는 상당한 시간이 필요합니다.

또 하나 중요한 개념이 있습니다.

‘지금 수집하고 나중에 해독’한다는 것은 무엇일까?

PQC를 설명할 때 Harvest Now, Decrypt Later라는 표현이 자주 등장합니다.

쉽게 설명하면 다음과 같습니다.

공격자가 오늘 암호화된 데이터를 확보합니다.

현재는 암호를 풀지 못합니다.

하지만 데이터를 보관해두었다가 미래에 더 강력한 기술이 등장하면 다시 해독을 시도할 수 있습니다.

즉,

지금 훔침 → 보관 → 미래에 해독

하는 방식입니다.

따라서 1~2년 후에는 가치가 없어지는 정보와 10년 이상 비밀로 유지해야 하는 정보는 다르게 볼 필요가 있습니다.

예를 들어 다음과 같은 정보는 장기간의 기밀성이 중요할 수 있습니다.

• 핵심 연구개발 자료
• 장기 기술로드맵
• 중요 설계정보
• 국가·공공 관련 중요자료
• 장기 계약정보
• 지식재산 관련 자료

모든 회사가 동일한 위험을 가지고 있는 것은 아닙니다.

중요정보를 얼마나 오랫동안 보호해야 하는지가 PQC 준비 우선순위를 판단하는 기준 중 하나가 될 수 있습니다.

중소기업도 PQC를 준비해야 할까?

직원 20~30명 정도의 일반 중소기업이 지금 당장 전용 PQC 장비를 구매해야 한다는 의미는 아닙니다.

오히려 먼저 확인해야 할 것이 있습니다.

회사가 직접 암호기술을 관리하고 있는가?

많은 중소기업은 암호 알고리즘을 직접 개발하지 않습니다.

대부분 다음 제품이나 서비스 안에 포함된 암호기술을 사용합니다.

• 윈도 서버
• 네트워크 장비
• 방화벽
• VPN
• NAS
• 클라우드
• 웹서버
• ERP
• 그룹웨어

이 경우 제품 제조사와 클라우드 제공업체의 업데이트를 통해 향후 새로운 암호기술이 지원될 가능성이 있습니다.

따라서 중소기업이 먼저 해야 할 일은 암호기술을 직접 개발하는 것이 아니라 어떤 제품에 얼마나 의존하고 있는지를 파악하는 것입니다.

첫 번째 준비는 ‘암호 자산 목록’ 만들기

PQC 준비에서 가장 현실적인 출발점입니다.

회사에서 암호가 사용되는 시스템을 한번 정리해보세요.

예를 들어 다음과 같습니다.

처음부터 정확한 알고리즘 이름까지 파악할 필요는 없습니다.

먼저 어디에 암호기술을 사용하고 있는지부터 찾으면 됩니다.

그 다음 중요한 시스템부터 세부 정보를 확인합니다.

Crypto Inventory가 중요한 이유

암호 관련 자산과 기술을 정리하는 것을 흔히 Cryptographic Inventory, 즉 암호 자산 목록 관리 관점으로 생각할 수 있습니다.

예를 들어 회사에서 갑자기 이런 안내를 받았다고 가정해보겠습니다.

앞으로 특정 암호 알고리즘을 단계적으로 다른 방식으로 전환해야 합니다.

그런데 어떤 시스템에서 해당 암호를 사용하는지 모른다면 어떻게 될까요?

웹서버 담당자에게 물어보고,

VPN 업체에 연락하고,

외주개발사에 문의하고,

장비 제조사에 확인해야 합니다.

이 과정에서 오래된 장비 하나가 빠질 수도 있습니다.

그래서 PQC 전환에서는 새 기술 자체만큼 현재 암호를 어디에서 사용하는지 찾는 능력이 중요합니다.

Crypto Agility란 무엇일까?

PQC와 함께 알아두면 좋은 개념이 Crypto Agility입니다.

한국어로는 암호 민첩성 정도로 표현할 수 있습니다.

쉽게 말하면,

필요할 때 암호방식을 비교적 쉽게 교체할 수 있는 능력

입니다.

예를 들어 프로그램 내부에 특정 알고리즘이 완전히 고정되어 있다고 생각해보겠습니다.

암호방식을 바꾸려면 프로그램 전체를 새로 만들어야 할 수도 있습니다.

반대로 암호 모듈을 변경할 수 있도록 설계되어 있다면 전환이 훨씬 쉬워집니다.

PQC 시대에는 어떤 알고리즘 하나가 영원히 안전하다고 생각하기보다 보안환경이 변했을 때 다른 암호방식으로 바꿀 수 있도록 준비하는 것이 중요합니다.

자체 소프트웨어를 개발한다면 더 중요하다

소프트웨어를 직접 개발해 고객에게 판매하는 기업이라면 PQC를 조금 더 적극적으로 살펴볼 필요가 있습니다.

특히 다음과 같은 제품입니다.

• 보안장비
• 네트워크 장비
• IoT 제품
• 산업용 장비
• 클라우드 서비스
• 통신 소프트웨어
• 인증 시스템

제품 안에 특정 암호 알고리즘이 깊숙하게 들어가 있다면 향후 교체가 어려워질 수 있습니다.

개발 단계에서 다음을 기록해두는 것이 좋습니다.

• 어떤 암호 알고리즘을 사용하는가?
• 어떤 라이브러리를 사용하는가?
• 인증서는 어디에서 사용하는가?
• 암호 모듈을 업데이트할 수 있는가?
• 장치 출시 후 펌웨어 업데이트가 가능한가?
• 오래된 제품도 업데이트할 수 있는가?

앞서 살펴본 소프트웨어 공급망 보안과도 연결되는 부분입니다.

어떤 외부 라이브러리와 구성요소를 사용하는지 알아야 암호기술의 변경 여부도 확인하기 쉽습니다.

VPN도 PQC와 관련이 있을까?

관련이 있습니다.

VPN은 외부에서 회사 내부망으로 접속할 때 암호화된 통신을 만드는 데 사용됩니다.

이 과정에서도 여러 암호 알고리즘과 인증방식이 사용될 수 있습니다.

따라서 회사에서 VPN을 장기간 운영한다면 향후 다음 사항을 제조사 또는 공급업체에 확인할 필요가 생길 수 있습니다.

• 현재 어떤 암호방식을 지원하는가?
• 소프트웨어 업데이트가 가능한가?
• 향후 PQC 관련 기능을 지원할 계획이 있는가?
• 장비 교체가 필요한가?
• 기존 사용자와 호환 가능한가?

다만 미래 대비라는 이유로 검증되지 않은 기능을 임의로 적용할 필요는 없습니다.

현재 사용 중인 제품을 안전하게 업데이트하고 제조사의 지원계획을 확인하는 것이 우선입니다.

HTTPS 인증서도 영향을 받을까?

웹사이트에서 사용하는 HTTPS도 공개키 암호기술과 밀접하게 연결되어 있습니다.

하지만 일반적인 웹사이트 운영자가 직접 새로운 PQC 알고리즘을 구현할 필요는 없습니다.

브라우저, 서버 소프트웨어, 인증서 생태계가 변화하면서 점진적으로 새로운 기술이 적용될 가능성이 높기 때문입니다.

웹사이트 운영자가 지금 할 수 있는 것은 비교적 기본적인 관리입니다.

• 서버 소프트웨어 최신 상태 유지
• 지원 종료 운영체제 교체
• 오래된 TLS 설정 제거
• 인증서 정상 관리
• 서버 업데이트 가능 여부 확인

PQC 준비라고 해서 미래의 암호만 바라보다 현재의 기본적인 서버 보안을 놓치면 안 됩니다.

하이브리드 방식이란 무엇일까?

PQC 전환 과정에서는 기존 암호방식과 새로운 PQC 기술을 함께 사용하는 방식도 이야기됩니다.

이를 이해하기 쉽게 표현하면,

현재 검증된 방식 + 새로운 양자내성 방식

을 함께 사용하는 것입니다.

새로운 암호체계로 한 번에 바꾸기보다 기존 시스템과의 호환성이나 안전성을 고려하면서 단계적으로 전환하기 위한 접근입니다.

기업 입장에서는 구체적인 알고리즘 조합까지 외울 필요는 없습니다.

중요한 것은 PQC 전환이 어느 날 갑자기 모든 것을 하나로 바꾸는 방식이 아닐 수 있다는 것입니다.

기존 환경과 새로운 환경이 일정 기간 함께 운영될 가능성을 고려해야 합니다.

PQC 준비에서 가장 주의해야 할 실수

1. 검증되지 않은 암호를 직접 만드는 것

보안이 필요하다고 해서 자체 암호 알고리즘을 만드는 것은 좋은 접근이 아닙니다.

검증된 표준과 신뢰할 수 있는 구현체를 사용하는 것이 중요합니다.

2. 지금 사용하는 보안부터 무시하는 것

미래의 양자컴퓨터보다 오늘 유출된 관리자 비밀번호가 더 직접적인 위험일 수 있습니다.

패치, MFA, 백업, 접근권한 같은 기본 보안을 먼저 유지해야 합니다.

3. 제품 이름에 PQC가 들어갔다고 바로 구매하는 것

PQC라는 이름만 보고 제품을 선택하기보다 어떤 표준을 지원하고 기존 시스템과 어떻게 연동되는지 확인해야 합니다.

4. 암호 알고리즘만 확인하는 것

실제 전환에서는 프로그램, 장비, 인증서, 네트워크와의 호환성이 중요합니다.

암호 하나만 교체해서 끝나는 문제가 아닐 수 있습니다.

5. 오래된 장비를 잊는 것

지원이 종료된 네트워크 장비나 산업용 장비는 새로운 암호기술을 지원하기 어려울 수 있습니다.

장기적으로 교체계획까지 고려해야 합니다.

중소기업 PQC 준비 순서

복잡하게 접근할 필요는 없습니다.

1단계. 중요정보 찾기

10년 이상 보호해야 할 자료가 있는지 확인합니다.

2단계. 암호가 사용되는 시스템 목록 만들기

VPN, 웹서버, 인증서, 클라우드, 소프트웨어 등을 정리합니다.

3단계. 담당 업체 확인하기

직접 관리하는 시스템인지 외부업체가 관리하는지 구분합니다.

4단계. 지원 종료 제품 확인하기

업데이트가 불가능한 오래된 서버와 네트워크 장비가 있는지 확인합니다.

5단계. 공급업체 지원계획 확인하기

중요한 제품의 제조사가 향후 새로운 암호표준을 지원할 수 있는지 확인합니다.

6단계. 새 시스템 도입 시 교체 가능성 확인하기

앞으로 구매하는 시스템은 암호방식을 업데이트할 수 있는지 확인하는 습관을 들입니다.

이 정도만 해도 미래 전환을 훨씬 쉽게 만들 수 있습니다.

PQC 준비 체크리스트

현재 회사 상태를 아래 항목으로 확인해볼 수 있습니다.

• 장기간 보호해야 하는 중요정보를 알고 있는가?
• 회사에서 사용하는 VPN을 파악하고 있는가?
• HTTPS 인증서를 누가 관리하는지 알고 있는가?
• 서버와 네트워크 장비 목록이 있는가?
• 사용 중인 장비의 지원 종료일을 확인하는가?
• 중요 소프트웨어의 암호기술을 확인할 수 있는가?
• 자체 개발제품에서 사용하는 암호 라이브러리를 알고 있는가?
• 프로그램 업데이트가 가능한 구조인가?
• IoT·산업장비의 펌웨어를 업데이트할 수 있는가?
• 외부 공급업체 연락처가 정리되어 있는가?
• 새로운 암호표준 지원 여부를 공급업체에 확인할 수 있는가?
• 오래된 시스템의 교체계획이 있는가?

체크되지 않는 항목이 많더라도 당장 문제가 있다는 의미는 아닙니다.

하지만 미래에 암호체계를 변경해야 할 때 어디부터 손대야 할지 알 수 있도록 만드는 자료가 될 수 있습니다.

PQC와 제로트러스트는 무엇이 다를까?

둘은 전혀 다른 개념입니다.

제로트러스트는 사용자의 신원과 접근권한을 확인하고 필요한 만큼만 접근하도록 하는 보안전략입니다.

PQC는 양자컴퓨터 시대를 고려해 암호기술 자체의 안전성을 준비하는 분야입니다.

쉽게 말하면,

제로트러스트 → 누가 접근할 수 있는가?

PQC → 그 통신과 인증에 사용하는 암호는 미래에도 안전한가?

라고 구분할 수 있습니다.

실제 기업 보안에서는 둘 중 하나만 선택하는 관계가 아닙니다.

계정과 접근권한도 관리해야 하고 안전한 암호통신도 필요합니다.

PQC와 소프트웨어 공급망도 연결된다

기업이 직접 암호 알고리즘을 만들지 않더라도 사용하는 소프트웨어 안에는 수많은 암호 라이브러리가 포함될 수 있습니다.

문제는 우리 회사가 어떤 라이브러리를 사용하는지 모르는 경우입니다.

나중에 특정 암호방식을 변경해야 하는 상황이 발생했을 때 해당 구성요소를 사용하는 프로그램을 찾지 못하면 대응이 늦어질 수 있습니다.

따라서 SBOM과 같은 소프트웨어 구성요소 관리가 잘 되어 있다면 PQC 전환에도 도움이 될 수 있습니다.

결국 공급망 보안에서도 중요한 질문은 동일합니다.

우리 시스템 안에 무엇이 들어 있는가?

기업이 지금 PQC 때문에 해야 할 가장 현실적인 일

양자컴퓨터 관련 뉴스를 볼 때마다 기존 서버를 모두 교체할 필요는 없습니다.

오히려 다음 세 가지부터 확인하면 됩니다.

첫째, 장기간 보호해야 하는 데이터가 있는가?

둘째, 회사에서 암호가 사용되는 중요 시스템은 무엇인가?

셋째, 그 시스템의 암호방식을 나중에 변경할 수 있는가?

여기에 답할 수 있다면 미래의 암호 전환 과정도 훨씬 수월해집니다.

양자내성암호 PQC의 핵심은 ‘지금 교체’가 아니라 ‘교체할 수 있게 준비’하는 것

양자내성암호 PQC를 처음 접하면 새로운 보안제품을 당장 설치해야 할 것처럼 느껴질 수 있습니다.

하지만 일반 중소기업에서 더 중요한 것은 다른 부분입니다.

현재 사용하는 암호기술을 파악하고 오래된 시스템을 관리하며 미래에 새로운 표준으로 전환할 수 있는 구조를 만드는 것입니다.

결국 다음 질문 하나로 정리할 수 있습니다.

우리 회사가 사용하는 암호기술을 5년 또는 10년 뒤 바꿔야 한다면 어디를 수정해야 하는지 알고 있는가?

바로 답할 수 없다면 PQC 준비의 첫 번째 단계는 새로운 제품 구매가 아닙니다.

VPN, 서버, 인증서, 클라우드, 자체 개발 소프트웨어 등 암호가 사용되는 시스템 목록을 한 장으로 정리하는 것부터 시작하면 됩니다.

미래의 양자컴퓨터가 언제 충분히 발전할지를 정확하게 예측하는 것보다 우리 회사 시스템이 변화에 대응할 수 있도록 준비하는 것이 기업 입장에서는 훨씬 현실적인 보안전략입니다.

자주 묻는 질문

PQC란 무엇인가요?

PQC는 Post-Quantum Cryptography의 약자로 충분히 강력한 양자컴퓨터 환경에서도 안전하게 사용할 수 있도록 설계되는 암호기술을 의미합니다.

양자컴퓨터가 나오면 현재 암호가 모두 깨지나요?

모든 암호기술이 동일하게 영향을 받는 것은 아닙니다. 특히 RSA와 ECC 같은 현재의 주요 공개키 암호체계에 대한 장기적인 영향을 고려해 새로운 암호표준이 준비되고 있습니다.

중소기업도 지금 PQC를 도입해야 하나요?

일반적인 중소기업이 모든 시스템을 즉시 교체해야 하는 것은 아닙니다. 먼저 회사에서 암호기술이 사용되는 서버, VPN, 인증서, 소프트웨어 등의 목록을 파악하는 것이 현실적인 시작입니다.

Harvest Now, Decrypt Later란 무엇인가요?

현재는 해독하지 못하는 암호화 데이터를 미리 수집한 뒤 미래에 더 강력한 기술이 등장했을 때 해독을 시도하는 위험을 의미합니다. 따라서 장기간 기밀성을 유지해야 하는 데이터에서는 특히 고려할 필요가 있습니다.

Crypto Agility란 무엇인가요?

환경이나 보안표준이 바뀌었을 때 기존 암호기술을 새로운 방식으로 비교적 원활하게 교체할 수 있는 능력을 의미합니다.

PQC 준비에서 가장 먼저 해야 할 일은 무엇인가요?

장기간 보호해야 하는 데이터를 확인하고 회사에서 암호가 사용되는 시스템의 목록을 만드는 것이 좋습니다. 이후 해당 제품과 서비스가 앞으로 새로운 암호기술을 지원할 수 있는지 확인하면 됩니다.

회사에서 ChatGPT 사용할 때 보안을 생각하지 않고 업무에 바로 활용하는 직원이 늘고 있습니다.

메일 문장을 다듬거나 보고서를 요약하고, 엑셀 수식을 만들고, 회의내용을 정리하는 데 생성형 AI를 사용하면 업무시간을 크게 줄일 수 있기 때문입니다.

문제는 편리함 때문에 회사 내부정보까지 그대로 입력하는 경우입니다.

예를 들어 거래처에서 받은 계약서를 통째로 붙여넣어 요약하거나, 고객 명단을 입력해 분석을 요청하거나, 개발 중인 프로그램의 소스코드를 그대로 올리는 상황을 생각해볼 수 있습니다.

직원 입장에서는 단순히 업무를 빨리 처리하려는 행동일 수 있습니다.

하지만 회사 입장에서는 어떤 정보가 외부 AI 서비스에 입력되고 있는지조차 파악하지 못하는 상황이 생길 수 있습니다.

따라서 ChatGPT를 무조건 사용하지 못하게 하는 것보다 무엇을 입력해도 되고 무엇은 입력하면 안 되는지 기준부터 만드는 것이 중요합니다.

회사에서 ChatGPT 사용이 늘어나는 이유

생성형 AI는 전문 개발자가 아니어도 바로 사용할 수 있다는 장점이 있습니다.

실제 회사에서는 다음과 같은 업무에 활용할 수 있습니다.

• 이메일 문장 작성
• 보고서 초안 작성
• 회의내용 요약
• 아이디어 정리
• 엑셀 함수 만들기
• 번역
• 코드 작성 보조
• 자료 분류
• 고객응대 문구 작성

이런 업무는 생성형 AI를 잘 활용하면 시간을 줄일 수 있습니다.

그래서 회사가 공식적으로 도입하지 않아도 직원 개인이 먼저 사용하는 경우가 생깁니다.

문제는 이때부터입니다.

회사가 사용 여부를 모르면 어떤 직원이 어떤 회사정보를 AI에 입력하는지도 관리하기 어려워집니다.

ChatGPT에 회사 정보를 입력하면 왜 주의해야 할까?

생성형 AI에 질문하기 위해서는 사용자가 내용을 입력해야 합니다.

업무용 질문을 자세하게 할수록 답변도 구체적으로 받을 수 있기 때문에 직원은 자연스럽게 실제 회사정보를 입력하게 될 수 있습니다.

예를 들어 다음과 같습니다.

이 고객 200명의 구매내역을 분석해서 VIP 고객을 골라줘.

분석 자체는 편리합니다.

하지만 고객 이름, 전화번호, 이메일, 구매내역 등이 그대로 포함되어 있다면 이야기가 달라집니다.

또 이런 상황도 있습니다.

이 계약서에서 우리 회사에 불리한 조항을 찾아줘.

계약서에는 거래조건뿐 아니라 회사명, 담당자, 가격, 기술정보가 들어 있을 수 있습니다.

즉, ChatGPT 보안에서 중요한 것은 AI 자체를 무조건 위험하다고 보는 것이 아니라 사용자가 어떤 데이터를 입력하는지를 관리하는 것입니다.

1. 고객 개인정보는 그대로 입력하지 않는 것이 좋다

가장 먼저 조심해야 할 것이 개인정보입니다.

다음 정보가 포함되어 있다면 특히 주의해야 합니다.

• 이름
• 전화번호
• 이메일
• 주소
• 주민등록번호
• 계좌번호
• 고객번호
• 구매내역

예를 들어 고객 불만 내용을 AI로 분류하고 싶다면 실제 이름이나 전화번호를 그대로 입력할 필요는 없습니다.

홍길동 / 010-1234-5678

대신

고객 A

처럼 식별할 수 없는 형태로 바꾼 뒤 작업할 수 있습니다.

AI를 사용할 때 가장 먼저 습관화하면 좋은 것이 바로 불필요한 개인정보 제거입니다.

2. 회사 비밀번호와 인증정보는 절대 입력하지 않는다

업무를 하다가 오류를 해결하기 위해 ChatGPT에 질문할 수 있습니다.

이때 실제 설정파일을 그대로 복사해 붙여넣으면 안에 중요한 인증정보가 포함될 수 있습니다.

대표적으로 다음과 같습니다.

• 아이디
• 비밀번호
• API Key
• Access Token
• Secret Key
• 인증서 비밀번호
• 서버 접속정보
• 데이터베이스 계정

예를 들어 프로그램 오류를 질문할 때 실제 API Key가 포함된 코드를 그대로 붙여넣기보다 해당 부분을 다음처럼 변경하는 것이 좋습니다.

API_KEY="실제키"

가 아니라

API_KEY="YOUR_API_KEY"

처럼 바꿔서 질문합니다.

비밀번호와 인증키는 AI뿐 아니라 이메일, 메신저 등 어떤 외부 서비스에도 불필요하게 공유하지 않는 것이 기본입니다.

3. 계약서와 견적서를 통째로 올리지 않는다

ChatGPT를 이용해 계약서를 요약하면 편리합니다.

하지만 계약서에는 생각보다 많은 회사정보가 들어갑니다.

• 계약금액
• 납품조건
• 고객사명
• 담당자
• 기술조건
• 위약조건
• 내부 협상내용

견적서 역시 마찬가지입니다.

제품 원가, 할인율, 공급가격과 같은 정보가 경쟁사에 알려지면 곤란할 수 있습니다.

AI를 이용해 문장을 검토해야 한다면 실제 회사명과 금액 등 민감한 부분을 제거하거나 가상의 값으로 변경한 뒤 사용하는 방법을 생각할 수 있습니다.

예를 들어,

A기업에 7억 8천만원으로 납품한다

대신

고객사 A에 ○억원 규모로 납품한다

처럼 바꾸는 것입니다.

4. 개발 중인 소스코드를 그대로 입력하지 않는다

개발자에게 ChatGPT와 같은 생성형 AI는 상당히 유용한 도구입니다.

오류를 찾거나 코드를 개선하고 새로운 함수를 작성하는 데 활용할 수 있습니다.

하지만 회사의 전체 소스코드를 그대로 입력하는 것은 별개의 문제입니다.

특히 다음 내용이 포함되어 있는지 확인해야 합니다.

• 회사만의 핵심 알고리즘
• 데이터베이스 구조
• 서버 주소
• 인증키
• 고객정보
• 내부 API
• 미공개 제품 기능

질문에 필요한 최소한의 코드만 떼어서 사용하고 회사 고유정보는 제거하는 것이 좋습니다.

개발업무에서는 문제 해결에 필요한 코드와 회사의 핵심 기술을 구분하는 습관이 중요합니다.

5. 출시 전 제품정보와 사업계획을 입력할 때 주의한다

아직 공개하지 않은 정보도 회사에서는 중요한 자산입니다.

예를 들어 다음과 같습니다.

• 신제품 출시일
• 신규 서비스 기획
• 연구개발 계획
• 투자계획
• 정부지원사업 제안서
• 기술개발 로드맵
• 특허 출원 전 아이디어

이런 내용을 AI에게 그대로 입력해 사업계획서를 작성하게 하는 것은 신중하게 판단해야 합니다.

특히 외부 공개 전인 기술 아이디어나 사업전략이라면 필요한 부분만 일반화해서 질문하는 방법이 좋습니다.

예를 들어,

우리 회사가 개발 중인 ○○ 제품의 2027년 출시전략을 만들어줘.

보다는

중소 제조기업이 새로운 산업용 장비를 출시할 때 필요한 시장진입 전략을 알려줘.

처럼 구체적인 회사정보 없이도 도움을 받을 수 있습니다.

6. 직원 인사정보를 그대로 입력하지 않는다

인사담당자도 AI를 활용하기 좋은 업무가 많습니다.

평가문구 작성, 채용공고 작성, 교육계획 수립 등이 대표적입니다.

하지만 실제 직원의 정보를 그대로 입력해 평가를 요청하는 것은 주의할 필요가 있습니다.

예를 들어,

김○○ 과장은 올해 실적이 이렇고 연봉은 얼마인데 승진시켜야 할까?

처럼 실제 인사정보를 입력하기보다 개인을 특정할 수 없도록 내용을 바꾸는 편이 좋습니다.

특히 다음 정보는 조심해야 합니다.

• 연봉
• 인사평가
• 징계내용
• 주민번호
• 연락처
• 건강 관련 정보
• 개인 상담내용

AI를 활용하더라도 사람을 특정할 필요가 없는 업무라면 익명화부터 하는 것이 안전합니다.

7. 고객사에서 받은 비공개 자료도 우리 마음대로 입력하면 안 된다

우리 회사 자료가 아니라고 해서 자유롭게 입력해도 되는 것은 아닙니다.

거래처로부터 받은 자료에는 NDA나 비밀유지 의무가 적용될 수 있습니다.

예를 들어 다음과 같은 자료입니다.

• 고객 요구사항
• 설계도면
• 제품사양서
• 입찰자료
• 미공개 견적
• 기술문서
• 시스템 구성도

직원이 편의를 위해 이런 자료를 생성형 AI에 올릴 경우 계약상 문제가 될 가능성도 생각해야 합니다.

따라서 회사 AI 사용규칙에는 우리 회사 정보뿐 아니라 고객과 협력사 정보도 포함시키는 것이 좋습니다.

그러면 회사에서 ChatGPT를 사용하면 안 될까?

그렇지는 않습니다.

업무에 활용할 수 있는 정보와 입력하면 안 되는 정보를 구분하면 됩니다.

예를 들면 다음과 같습니다.

핵심은 AI 사용 여부가 아니라 입력 데이터의 민감도입니다.

중소기업용 ChatGPT 보안수칙 7가지

규정이 전혀 없는 회사라면 어렵게 만들 필요가 없습니다.

우선 다음 7가지만 직원들과 공유해도 좋습니다.

1. 개인정보 입력 금지

고객과 직원의 이름, 전화번호, 주소 등 개인을 식별할 수 있는 정보는 입력하지 않습니다.

2. 비밀번호와 인증키 입력 금지

ID, 비밀번호, API Key, Token 등 인증정보를 입력하지 않습니다.

3. 고객사 비공개 자료 입력 금지

NDA나 비밀유지 대상 자료는 외부 AI 서비스에 입력하지 않습니다.

4. 핵심 기술정보 입력 금지

소스코드, 설계도면, 연구자료 등 회사의 핵심 기술정보는 별도로 관리합니다.

5. 필요한 부분만 입력

문서 전체를 올리기보다 질문에 필요한 부분만 사용합니다.

6. 개인정보와 회사명을 제거

AI 사용 전에 실제 이름과 회사명을 고객 A, 업체 B처럼 바꿉니다.

7. AI 답변은 다시 확인

생성형 AI가 작성한 내용이 항상 정확한 것은 아니므로 계약, 법률, 기술, 재무처럼 중요한 내용은 담당자가 다시 검토합니다.

ChatGPT에 넣기 전에 10초만 확인해보자

직원들에게 복잡한 보안규정을 외우게 하는 것보다 하나의 질문을 습관화하는 것도 좋은 방법입니다.

“이 내용을 회사 밖 사람에게 이메일로 보내도 괜찮은가?”

괜찮다면 AI 입력도 상대적으로 부담이 적을 수 있습니다.

반대로 이메일로 외부 사람에게 보내기 곤란한 자료라면 AI에 그대로 입력하는 것도 다시 생각해봐야 합니다.

추가로 다음 네 가지를 확인해볼 수 있습니다.

• 개인정보가 있는가?
• 회사 기밀이 있는가?
• 고객사의 비공개 정보가 있는가?
• 로그인이나 인증정보가 있는가?

하나라도 해당된다면 그대로 입력하기보다 내용을 제거하거나 익명화하는 편이 좋습니다.

직원이 이미 ChatGPT를 사용하고 있다면 어떻게 해야 할까?

많은 회사에서 AI 도입을 결정하기 전에 직원들이 먼저 사용합니다.

이 상황에서 무조건 금지부터 하면 개인 계정으로 몰래 사용하는 이른바 Shadow AI 문제가 생길 수도 있습니다.

차라리 어떤 업무에 사용하고 있는지 파악하는 것이 먼저입니다.

1단계. 실제 사용현황 확인

직원들이 ChatGPT나 다른 생성형 AI를 어떤 업무에 사용하는지 조사합니다.

2단계. 입력 금지정보 결정

개인정보, 계약정보, 소스코드처럼 회사에서 보호할 자료를 정합니다.

3단계. 허용 업무 제시

메일 작성, 공개자료 요약, 아이디어 정리처럼 사용 가능한 업무도 알려줍니다.

4단계. 익명화 방법 안내

고객명과 직원명을 제거한 뒤 사용하는 방법을 교육합니다.

5단계. 정기적으로 규칙 업데이트

AI 서비스와 회사의 업무환경이 바뀌기 때문에 규칙도 한 번 만들고 끝내기보다 필요할 때 수정합니다.

사내 생성형 AI 사용 체크리스트

직원이 ChatGPT를 사용하기 전 다음 항목을 확인하도록 할 수 있습니다.

• 고객 개인정보가 포함되어 있지 않은가?
• 직원 개인정보가 포함되어 있지 않은가?
• 비밀번호나 API Key가 없는가?
• 비공개 계약정보가 없는가?
• 고객사 기밀자료가 아닌가?
• 미공개 사업계획이 포함되지 않았는가?
• 회사 핵심 기술정보가 없는가?
• 필요한 정보만 입력했는가?
• 회사명과 개인명을 제거할 수 없는가?
• AI 결과를 사람이 다시 확인했는가?

10개 가운데 하나라도 확신하기 어렵다면 자료를 그대로 입력하기 전에 담당자에게 확인하는 구조가 좋습니다.

생성형 AI 보안도 결국 계정과 데이터 관리다

앞서 살펴본 제로트러스트나 공급망 보안과 생성형 AI 보안은 완전히 별개의 문제처럼 보일 수 있습니다.

하지만 실제로는 공통점이 있습니다.

누가 어떤 데이터에 접근하고 어디로 전달할 수 있는지를 관리하는 것입니다.

ChatGPT를 사용한다고 갑자기 새로운 보안 원칙이 필요한 것은 아닙니다.

기존에 회사가 중요하게 관리하던 개인정보, 영업비밀, 인증정보, 고객사 비밀자료를 AI 환경에서도 동일하게 관리하면 됩니다.

새로운 것은 도구이고, 지켜야 하는 정보는 대부분 기존과 같습니다.

회사에서 ChatGPT 사용할 때 가장 먼저 정할 것

회사에서 ChatGPT 사용할 때 보안을 어렵게 시작할 필요는 없습니다.

수십 페이지짜리 AI 보안규정부터 만드는 것보다 직원들이 바로 이해할 수 있는 기준을 만드는 것이 현실적입니다.

가장 먼저 아래 네 가지만 정해도 좋습니다.

어떤 AI 서비스를 사용할 수 있는가?

어떤 업무에 사용할 수 있는가?

어떤 정보는 절대 입력하면 안 되는가?

애매할 때 누구에게 물어볼 것인가?

생성형 AI를 무조건 막는다고 보안이 완성되는 것은 아닙니다.

반대로 편리하다는 이유로 모든 정보를 자유롭게 입력하는 것도 좋은 방법은 아닙니다.

중소기업이라면 AI를 못 쓰게 하는 규칙보다 안전하게 사용할 수 있는 간단하고 명확한 규칙을 만드는 것부터 시작하는 편이 현실적입니다.

자주 묻는 질문

회사에서 ChatGPT를 사용해도 되나요?

회사 정책과 사용하는 서비스에 따라 달라질 수 있습니다. 개인적으로 판단하기보다 회사가 허용한 서비스와 사용범위를 확인하고 개인정보와 기밀정보는 입력하지 않는 것이 좋습니다.

계약서를 ChatGPT로 요약해도 되나요?

계약서에는 거래조건, 금액, 개인정보와 비공개 정보가 포함될 수 있습니다. 회사의 보안정책과 계약상 비밀유지 의무를 먼저 확인하고 민감한 내용을 제거한 뒤 사용하는 것이 좋습니다.

소스코드를 ChatGPT에 입력해도 되나요?

일반적인 예제 코드는 활용할 수 있지만 회사의 핵심 알고리즘, 인증키, 서버정보, 고객정보 등이 포함된 실제 코드는 주의해야 합니다. 필요한 최소 부분만 사용하고 민감정보를 제거하는 것이 좋습니다.

직원이 개인 ChatGPT 계정을 업무에 사용하면 어떻게 해야 하나요?

무조건 금지하기보다 실제 사용현황부터 파악한 뒤 허용 서비스, 허용 업무, 입력 금지정보를 정하는 것이 좋습니다. 회사가 모르는 상태에서 개인 AI 서비스가 업무에 사용되는 상황을 줄이는 것이 중요합니다.

ChatGPT 사용 시 가장 입력하면 안 되는 정보는 무엇인가요?

비밀번호와 API Key 같은 인증정보, 고객·직원의 개인정보, 회사 핵심기술, 미공개 사업정보, 고객사 비밀자료 등을 우선적으로 주의해야 합니다.

사내 AI 보안규정은 어떻게 시작하면 되나요?

복잡하게 시작할 필요가 없습니다. 사용할 수 있는 AI 서비스, 허용 업무, 입력 금지정보, 문의 담당자를 먼저 정하고 직원들이 쉽게 확인할 수 있는 1페이지 기준으로 만드는 방법이 좋습니다.

랜섬웨어 대비 백업 방법을 알아볼 때 가장 많이 듣는 말이 있습니다.

“중요한 파일은 NAS에 백업해두면 됩니다.”

물론 백업은 랜섬웨어 대응에서 매우 중요합니다. 하지만 회사 PC의 파일을 NAS에 복사해두었다는 이유만으로 모든 준비가 끝났다고 보기는 어렵습니다.

PC와 NAS가 항상 연결되어 있고 같은 관리자 계정을 사용한다면 공격 상황에 따라 백업 데이터까지 영향을 받을 수 있기 때문입니다.

더 중요한 문제도 있습니다.

백업파일이 존재한다고 해서 실제로 복구할 수 있다는 뜻은 아닙니다.

몇 년 동안 자동백업이 정상적으로 작동한다고 생각했는데 막상 필요한 순간 파일이 손상되어 있거나, 복구방법을 아는 직원이 없거나, 최근 정상 백업 시점을 찾지 못한다면 백업의 효과는 크게 떨어집니다.

따라서 랜섬웨어 대비에서는 단순한 파일 복사보다 백업 → 분리 → 확인 → 복구 테스트까지 하나의 과정으로 생각하는 것이 좋습니다.

랜섬웨어에 백업이 중요한 이유

랜섬웨어는 PC나 서버의 파일을 사용할 수 없게 만든 뒤 금전을 요구하는 형태의 공격으로 많이 알려져 있습니다.

회사에서 이런 사고가 발생하면 단순히 문서 몇 개를 잃는 문제로 끝나지 않을 수 있습니다.

예를 들어 다음 자료가 모두 영향을 받았다고 가정해보겠습니다.

• 고객 주문자료
• 회계자료
• 계약서
• 견적서
• 설계도면
• 생산자료
• ERP 데이터
• 공유폴더
• 홈페이지 데이터

이때 정상적인 백업이 있다면 시스템을 초기화한 뒤 데이터를 복원해 업무를 다시 시작할 가능성이 높아집니다.

반대로 백업까지 사용할 수 없다면 회사의 선택지가 크게 줄어듭니다.

결국 랜섬웨어 대응에서 중요한 것은 공격을 100% 막겠다는 생각뿐 아니라 공격을 당해도 다시 일어날 수 있도록 준비하는 것입니다.

NAS에 백업하면 안전하지 않을까?

NAS는 여러 사람이 파일을 공유하고 백업하기에 편리합니다.

중소기업에서도 많이 사용하는 이유입니다.

하지만 NAS를 사용하는 것과 랜섬웨어에 안전한 백업을 가지고 있는 것은 같은 의미가 아닙니다.

예를 들어 다음과 같은 구조를 생각해보겠습니다.

직원 PC → 사내 네트워크 → NAS

직원 PC에서 NAS 공유폴더를 항상 사용할 수 있다면 정상적인 업무에는 편리합니다.

하지만 감염된 계정이나 시스템이 NAS 데이터까지 변경할 수 있는 구조라면 백업 영역 역시 위험에 노출될 가능성을 고려해야 합니다.

따라서 한 가지 질문을 해볼 필요가 있습니다.

PC가 감염되어도 백업파일까지 바로 수정하거나 삭제할 수 없는가?

이 질문에 확실하게 답하기 어렵다면 백업 구조를 한번 점검해볼 필요가 있습니다.

1. 원본과 백업을 같은 곳에 두지 않는다

가장 쉽게 발생하는 실수입니다.

업무파일과 백업파일이 사실상 같은 시스템 안에 존재하는 경우입니다.

예를 들어 PC의 업무자료 폴더를 같은 PC의 백업 폴더에 복사했다고 가정해보겠습니다.

이것은 파일을 하나 더 만들어둔 것이지 충분한 의미의 백업이라고 보기 어렵습니다.

PC 자체에 문제가 생기면 둘 다 영향을 받을 수 있기 때문입니다.

백업은 가능한 한 원본과 분리하는 것이 좋습니다.

예를 들면,

업무 PC → 별도 NAS

또는

서버 → 별도 백업장비

처럼 물리적 또는 논리적으로 분리할 수 있습니다.

중요한 데이터라면 한 단계 더 나아가 별도 장소나 클라우드 백업을 함께 검토할 수도 있습니다.

2. 항상 연결된 백업만 믿지 않는다

자동백업은 편리합니다.

직원이 직접 백업하지 않아도 일정 시간마다 자료가 저장되기 때문입니다.

하지만 백업장치가 항상 운영시스템과 연결되어 있다면 공격이나 관리자 계정 탈취 등의 상황에서 함께 영향을 받을 수 있습니다.

그래서 중요한 데이터는 항상 연결되어 있지 않은 백업도 고려할 필요가 있습니다.

예를 들어 외장 저장장치에 주기적으로 백업한 뒤 평소에는 분리해서 보관하는 방법이 있습니다.

규모가 있는 환경에서는 변경이나 삭제를 제한하는 별도의 백업 저장구조를 검토할 수도 있습니다.

핵심은 간단합니다.

사고가 발생한 시스템에서 백업까지 마음대로 변경할 수 없게 만드는 것입니다.

3. 3-2-1 백업 원칙을 쉽게 이해하기

백업 방법을 찾아보면 3-2-1 백업이라는 말을 자주 볼 수 있습니다.

처음 보면 어려워 보이지만 원리는 단순합니다.

3개의 데이터 사본

원본을 포함해 데이터 사본을 여러 개 준비합니다.

예를 들면,

1. 업무용 원본
2. 사내 백업
3. 별도 백업

입니다.

2가지 서로 다른 저장수단

모든 사본을 같은 장비나 같은 방식으로 저장하지 않는 것입니다.

예를 들어 NAS와 클라우드처럼 서로 다른 저장방식을 사용할 수 있습니다.

1개는 별도 위치에 보관

화재, 침수, 도난처럼 사무실 전체에 문제가 발생하는 상황까지 고려해 한 개는 다른 위치에 두는 방식입니다.

소규모 회사가 처음부터 복잡한 백업시스템을 만들 필요는 없지만, 최소한 원본과 백업이 한 번의 사고로 동시에 사라지는 구조는 피하는 것이 중요합니다.

4. 백업 계정과 관리자 계정을 분리한다

백업장비를 설치해도 관리자 계정을 제대로 관리하지 않으면 문제가 생길 수 있습니다.

예를 들어 회사의 여러 PC에서 같은 관리자 계정을 사용하고 NAS 관리계정까지 동일한 비밀번호를 사용한다면 하나의 계정 문제가 여러 시스템으로 이어질 수 있습니다.

가능하다면 다음처럼 분리하는 것이 좋습니다.

일반 업무 계정

파일을 열고 저장하는 용도

백업 계정

백업 작업에 필요한 용도

관리자 계정

설정 변경이 필요한 경우에만 사용

특히 백업파일을 삭제하거나 백업정책을 변경할 수 있는 권한은 최소한의 관리자만 갖도록 하는 것이 좋습니다.

관리자 계정에는 MFA를 적용할 수 있다면 함께 검토하는 것도 좋습니다.

5. 백업 성공 메시지만 믿지 않는다

자동백업 프로그램에서 매일 “백업 완료”라는 메시지가 표시된다고 해서 마음을 놓기 쉽습니다.

하지만 실제로 중요한 것은 다른 질문입니다.

그 백업으로 시스템을 되살릴 수 있는가?

다음과 같은 문제가 있을 수 있습니다.

• 필요한 폴더가 백업 대상에서 빠져 있음
• 오래된 파일만 저장됨
• 백업파일 자체가 손상됨
• 데이터베이스 복구방법을 모름
• 암호화된 백업 비밀번호를 모름
• 담당자가 퇴사해 복구 절차를 아무도 모름

그래서 일정한 주기로 실제 파일을 복원해보는 것이 좋습니다.

복구 테스트는 거창할 필요가 없습니다.

임의의 파일 하나를 선택해 별도 폴더에 복원한 뒤 정상적으로 열리는지 확인하는 것부터 시작할 수 있습니다.

6. 백업 보관기간도 정해야 한다

백업을 매일 하고 있어도 모든 백업이 최근 파일 하나로 덮어쓰기 되는 구조라면 문제가 생길 수 있습니다.

랜섬웨어 감염 사실을 바로 알아차리지 못하는 경우를 생각해보겠습니다.

월요일에 문제가 시작됐지만 금요일에 발견했다면 화요일, 수요일, 목요일 백업에도 이미 문제가 반영되었을 가능성을 고려해야 합니다.

그래서 최근 백업 하나만 보관하기보다 여러 시점의 백업을 유지하는 방법이 좋습니다.

예를 들어 회사 상황에 따라,

• 최근 7일 일별 백업
• 최근 4주 주별 백업
• 월별 장기 백업

처럼 보관정책을 만들 수 있습니다.

정답이 하나 있는 것은 아닙니다.

중요한 것은 언제 문제가 시작됐는지 모르는 상황에서도 정상 시점으로 돌아갈 수 있도록 여러 복구 지점을 남겨두는 것입니다.

7. 무엇부터 복구할지 미리 정해둔다

랜섬웨어 사고가 발생하면 모든 시스템을 동시에 복구하기 어려울 수 있습니다.

그래서 평소에 업무 중요도를 정해두면 좋습니다.

예를 들어 제조기업이라면 다음처럼 생각해볼 수 있습니다.

1순위

생산에 직접 필요한 시스템

2순위

ERP·MES·주문관리 시스템

3순위

파일서버와 공유폴더

4순위

일반 직원 PC

5순위

과거 문서나 보관자료

회사마다 순서는 달라질 수 있습니다.

중요한 것은 사고가 발생한 뒤 회의하면서 결정하는 것이 아니라 어떤 시스템을 몇 시간 또는 며칠 안에 복구해야 하는지 미리 생각해두는 것입니다.

랜섬웨어 발생 상황을 한번 가정해보자

직원 30명인 중소기업을 예로 들어보겠습니다.

월요일 오전 직원 한 명이 파일을 열었는데 잠시 뒤 공유폴더의 문서가 정상적으로 열리지 않기 시작합니다.

확인 결과 여러 PC와 파일서버에 문제가 발생했습니다.

이때 백업이 있다고 가정해보겠습니다.

회사 A

NAS에 매일 자동백업

하지만 NAS가 항상 연결되어 있고 백업 계정도 일반 관리자 계정과 동일합니다.

마지막 정상 백업이 언제인지 아무도 모릅니다.

회사 B

NAS 자동백업 + 별도 백업

관리자 계정이 분리되어 있고 일정한 주기로 복구 테스트를 합니다.

백업 날짜별로 여러 버전을 보관하고 있습니다.

두 회사 모두 “백업을 하고 있다”고 말할 수 있습니다.

하지만 실제 사고가 발생했을 때 복구 가능성에는 큰 차이가 생길 수 있습니다.

그래서 중요한 것은 백업 여부가 아니라 복구 가능한 백업인지 확인하는 것입니다.

중소기업 랜섬웨어 백업 구축 순서

백업시스템을 처음 정리한다면 다음 순서로 접근해볼 수 있습니다.

1단계. 중요한 데이터 찾기

먼저 잃어버리면 업무가 중단되는 데이터를 확인합니다.

• 회계자료
• 고객자료
• 계약자료
• 생산자료
• 설계파일
• 데이터베이스
• 홈페이지
• 업무 공유폴더

모든 데이터를 동일하게 관리할 필요는 없습니다.

중요도가 높은 데이터부터 시작합니다.

2단계. 현재 백업 위치 확인

자료가 어디에 백업되는지 확인합니다.

“전산업체가 알아서 한다”가 아니라 실제 저장 위치를 파악하는 것이 좋습니다.

3단계. 원본과 백업 분리

업무시스템의 문제가 백업까지 바로 영향을 주지 않는 구조인지 확인합니다.

4단계. 관리자 권한 정리

누가 백업파일을 삭제하거나 정책을 변경할 수 있는지 확인합니다.

5단계. 여러 시점의 백업 보관

최근 한 개 파일만 남기는 것이 아니라 정상 시점으로 돌아갈 수 있도록 여러 버전을 남깁니다.

6단계. 복구 테스트

실제 파일을 꺼내 정상적으로 사용할 수 있는지 확인합니다.

여기까지 해놓으면 단순히 “백업장비를 가지고 있는 회사”에서 실제로 복구 준비가 된 회사로 한 단계 나아갈 수 있습니다.

랜섬웨어 대비 백업 체크리스트

현재 백업 상태를 아래 항목으로 확인해볼 수 있습니다.

• 중요한 데이터가 무엇인지 알고 있는가?
• 어디에 백업되는지 알고 있는가?
• 원본과 백업이 분리되어 있는가?
• 별도의 백업 사본이 존재하는가?
• 항상 연결되지 않은 백업이 있는가?
• 백업 관리자 계정이 분리되어 있는가?
• 여러 날짜의 백업을 보관하는가?
• 백업 성공 여부를 정기적으로 확인하는가?
• 실제 파일 복원을 테스트한 적이 있는가?
• 데이터베이스도 복구할 수 있는가?
• 복구 담당자가 정해져 있는가?
• 담당자가 없을 때도 복구할 수 있는 문서가 있는가?
• 어떤 시스템부터 복구할지 순서가 정해져 있는가?
• 백업장비 자체의 보안도 관리하고 있는가?

체크가 많이 되지 않는다고 해서 당장 큰 장비를 구매할 필요는 없습니다.

우선 중요 데이터 → 백업 위치 → 관리자 → 복구 가능 여부부터 확인하면 됩니다.

랜섬웨어 발생 후 바로 백업을 연결하면 안 되는 이유

실제 사고가 발생하면 당황해서 백업부터 연결하고 싶을 수 있습니다.

하지만 감염 범위나 침입 원인을 확인하지 않은 상태에서 정상 백업을 기존 환경에 바로 연결하는 것은 신중해야 합니다.

복구 과정에서는 일반적으로 다음과 같은 순서를 생각해야 합니다.

감염 시스템 분리 → 영향 범위 확인 → 정상 백업 확인 → 안전한 환경 준비 → 데이터 복구

백업은 마지막 남은 정상 데이터일 수 있기 때문에 복구 과정에서 오염되지 않도록 보호하는 것이 중요합니다.

특히 내부에서 대응하기 어려운 규모의 사고라면 전문 보안업체나 관련 기관의 지원을 검토하는 편이 안전합니다.

랜섬웨어 대비에서 보안솔루션보다 먼저 물어볼 질문

백신, EDR, XDR 등 다양한 보안제품은 랜섬웨어 탐지와 대응에 도움이 될 수 있습니다.

하지만 어떤 보안제품도 모든 공격을 완벽하게 막는다고 보기는 어렵습니다.

그래서 기술적인 방어와 함께 복구 준비도 필요합니다.

결국 회사가 답할 수 있어야 하는 질문은 다음과 같습니다.

오늘 모든 업무파일을 사용할 수 없게 되면 어디에서 복구할 것인가?

마지막 정상 백업은 언제인가?

백업파일을 공격자가 삭제할 수 있는가?

누가 복구할 것인가?

몇 시간 또는 며칠 안에 업무를 다시 시작할 수 있는가?

이 질문에 바로 답하지 못한다면 현재 백업 구조를 한번 점검해볼 필요가 있습니다.

랜섬웨어 대비 백업의 목적은 ‘저장’이 아니라 ‘복구’다

랜섬웨어 대비 백업 방법에서 가장 중요한 것은 백업파일 개수를 늘리는 것이 아닙니다.

필요한 순간에 사용할 수 있는 정상 데이터를 확보하는 것입니다.

그래서 백업은 다음 네 단어로 기억하면 쉽습니다.

분리하고, 여러 개 남기고, 확인하고, 직접 복구해본다.

특히 NAS를 사용하고 있다면 NAS가 있다는 사실만 확인하지 말고 PC가 감염되어도 NAS의 백업까지 함께 영향을 받지 않는지 살펴보는 것이 좋습니다.

중소기업이라면 오늘 가장 먼저 해볼 수 있는 일이 있습니다.

백업 프로그램 화면을 보는 것이 아니라 지난주 파일 하나를 실제로 복구해보는 것입니다.

정상적으로 복원된다면 현재 백업이 실제로 작동하고 있다는 것을 확인할 수 있습니다.

복구되지 않는다면 사고가 발생하기 전에 문제를 발견한 것이므로 오히려 다행입니다.

자주 묻는 질문

NAS에 백업하면 랜섬웨어에 안전한가요?

NAS는 유용한 백업수단이지만 항상 연결되어 있고 일반 계정에서 백업파일을 자유롭게 변경할 수 있다면 공격 상황에서 영향을 받을 가능성을 고려해야 합니다. 별도의 백업 사본과 권한 분리도 함께 검토하는 것이 좋습니다.

3-2-1 백업이란 무엇인가요?

원본을 포함해 데이터 사본을 여러 개 유지하고, 서로 다른 저장수단을 사용하며, 최소 하나는 별도 위치에 보관하는 백업 원칙입니다.

외장하드 백업도 도움이 되나요?

주기적으로 백업한 뒤 평소 시스템에서 분리해 보관한다면 하나의 추가 백업수단으로 활용할 수 있습니다. 다만 분실이나 물리적 고장 가능성도 있으므로 이것 하나에만 의존하는 것은 피하는 것이 좋습니다.

백업은 얼마나 자주 해야 하나요?

업무에서 허용할 수 있는 데이터 손실 범위에 따라 달라집니다. 하루치 데이터를 잃어도 되는 회사와 10분치 데이터도 잃으면 안 되는 회사의 백업주기는 다를 수 있으므로 데이터 중요도에 맞춰 정해야 합니다.

백업을 하고 있는데 복구 테스트도 해야 하나요?

네. 백업 성공 메시지만으로 실제 복구 가능 여부까지 확인할 수는 없습니다. 중요한 데이터는 일정한 주기로 실제 복원해 정상적으로 열리는지 확인하는 것이 좋습니다.

랜섬웨어 대비에서 가장 먼저 해야 할 일은 무엇인가요?

회사의 중요 데이터가 무엇이며 현재 어디에 백업되고 있는지를 파악하는 것이 우선입니다. 이후 원본과 백업의 분리 여부, 관리자 권한, 여러 시점의 백업 보관, 실제 복구 가능성을 차례로 확인할 수 있습니다.

특히 내부에서 대응하기 어려운 규모의 사고라면 전문 보안업체나 관련 기관의 지원을 검토하는 편이 안전합니다. 감염 확인과 신고 절차는 한국인터넷진흥원(KISA)이 운영하는 보호나라 STOP 랜섬웨어 페이지에서 확인할 수 있습니다.

이렇게 정리한 중요 데이터 목록은 백업에만 쓰이는 것이 아닙니다. 직원이 외부 서비스에 어떤 자료를 올려도 되는지 판단하는 기준으로도 그대로 사용할 수 있습니다. 이 부분은 회사에서 ChatGPT 사용할 때 보안 주의사항에서 자세히 다뤘습니다.

소프트웨어 공급망 공격이라는 말을 들으면 대형 IT기업이나 개발회사에서만 신경 써야 하는 보안 문제처럼 느껴질 수 있습니다.

하지만 회사 홈페이지에 워드프레스를 사용하거나, 외주업체가 만든 프로그램을 사용하거나, 무료 플러그인과 오픈소스 라이브러리를 사용하는 회사라면 이야기가 달라집니다.

직접 프로그램을 개발하지 않는 회사도 이미 수많은 외부 소프트웨어에 의존하고 있기 때문입니다.

예를 들어 회사 홈페이지에 설치한 플러그인 하나에 문제가 생겼다고 생각해보겠습니다.

우리 회사가 직접 만든 프로그램은 아니지만 해당 플러그인이 공격받으면 홈페이지 역시 영향을 받을 수 있습니다.

즉, 우리 회사 시스템을 직접 공격하지 않고 우리가 믿고 사용하는 프로그램이나 업체를 먼저 공격하는 방식이 소프트웨어 공급망 공격의 핵심입니다.

소프트웨어 공급망 공격이란?

우리가 사용하는 프로그램 하나는 생각보다 많은 요소로 만들어집니다.

개발자가 모든 기능을 처음부터 직접 만드는 경우는 많지 않습니다.

보통 다음과 같은 것들을 조합합니다.

• 오픈소스 라이브러리
• 외부 API
• 프로그램 패키지
• 플러그인
• 개발 도구
• 클라우드 서비스
• 외주개발 코드
• 업데이트 서버

문제는 이 가운데 하나가 공격당하면 해당 요소를 사용하는 다른 기업까지 영향을 받을 수 있다는 것입니다.

일반적인 공격이

공격자 → 우리 회사

라면 공급망 공격은 다음과 같은 구조가 될 수 있습니다.

공격자 → 소프트웨어 또는 공급업체 → 우리 회사

우리 회사를 직접 뚫는 것보다 이미 많은 회사에서 신뢰하고 사용하는 프로그램을 공격하는 편이 더 효과적일 수 있기 때문입니다.

오픈소스를 쓰면 위험한 걸까?

그렇지는 않습니다.

오픈소스 자체가 위험하다는 의미는 아닙니다.

현대적인 웹사이트와 애플리케이션을 만들면서 외부 라이브러리를 전혀 사용하지 않는 것은 오히려 드문 일입니다.

문제는 무엇을 사용하고 있는지 모르는 상태입니다.

예를 들어 홈페이지 제작을 외주업체에 맡겼다고 가정해보겠습니다.

완성된 홈페이지는 잘 작동합니다.

하지만 다음 질문에는 답하지 못할 수도 있습니다.

• 어떤 플러그인을 설치했는가?
• 어떤 라이브러리를 사용하는가?
• 업데이트는 누가 하는가?
• 사용하지 않는 플러그인은 없는가?
• 보안 문제가 발견되면 누가 패치하는가?

홈페이지가 작동한다고 해서 내부에 사용된 모든 프로그램이 안전하게 관리되고 있다는 뜻은 아닙니다.

그래서 공급망 보안에서는 프로그램 자체뿐 아니라 그 프로그램을 구성하는 요소까지 관리하는 관점이 중요합니다.

1. 오래된 오픈소스 라이브러리를 계속 사용할 수 있다

한 번 만들어진 프로그램이 오랫동안 아무 문제 없이 작동하면 굳이 수정하지 않는 경우가 많습니다.

특히 외주개발로 만든 시스템은 담당자가 바뀌면서 내부 구조를 아는 사람이 없어질 수도 있습니다.

그런데 프로그램 안에서는 몇 년 전에 설치한 오픈소스 라이브러리가 그대로 사용되고 있을 수 있습니다.

이 라이브러리에 새로운 취약점이 발견되면 문제가 생깁니다.

그래서 중요한 프로그램이라면 단순히 정상 작동 여부만 보지 말고 어떤 구성요소가 사용되고 있는지도 확인할 필요가 있습니다.

2. 무료 플러그인을 너무 많이 설치하면 관리하기 어려워진다

워드프레스 같은 CMS를 사용하는 회사라면 쉽게 이해할 수 있는 부분입니다.

필요한 기능이 있을 때마다 플러그인을 설치하다 보면 어느 순간 수십 개가 될 수 있습니다.

문제는 시간이 지나면서 발생합니다.

사용하지 않는 플러그인이 남아 있고 업데이트가 중단된 플러그인도 생길 수 있습니다.

특히 다음과 같은 플러그인은 한번 확인해볼 필요가 있습니다.

• 현재 사용하지 않는 플러그인
• 업데이트가 장기간 없는 플러그인
• 개발자가 더 이상 관리하지 않는 플러그인
• 설치 목적을 모르는 플러그인
• 비슷한 기능의 플러그인이 여러 개 있는 경우

보안은 많이 설치한다고 좋아지는 것이 아닙니다.

관리할 수 없는 프로그램의 개수가 늘어날수록 확인해야 할 범위도 함께 늘어납니다.

3. 외주개발을 맡겼다면 소스코드만 받으면 끝일까?

중소기업에서는 자체 개발팀보다 외주개발 업체를 이용하는 경우가 많습니다.

홈페이지, ERP 연동 프로그램, 모바일 앱, 내부 관리시스템 등을 외주로 만들 수 있습니다.

프로그램을 납품받을 때 기능만 정상적으로 작동하면 프로젝트가 끝났다고 생각하기 쉽습니다.

하지만 유지보수까지 생각하면 몇 가지를 추가로 확인하는 것이 좋습니다.

예를 들어 다음과 같습니다.

• 사용한 개발언어와 버전
• 주요 오픈소스 라이브러리
• 외부 API 사용 여부
• 관리자 계정
• 서버 접속정보 관리방법
• 프로그램 업데이트 방법
• 소스코드 보관 위치
• 유지보수 종료 후 계정 처리방법

특히 개발업체가 서버의 최고관리자 계정을 계속 가지고 있는 구조라면 계약 종료 후에도 접근 가능 여부를 확인하는 것이 좋습니다.

4. 업데이트도 하나의 공급망이 될 수 있다

프로그램 업데이트는 보안을 강화하기 위해 필요합니다.

그런데 업데이트 파일을 제공하는 과정 자체가 공격받을 가능성도 생각해야 합니다.

우리가 사용하는 프로그램은 보통 다음 과정을 거쳐 업데이트됩니다.

개발사 → 업데이트 서버 → 인터넷 → 회사 시스템

사용자는 개발사가 제공하는 업데이트라고 생각하기 때문에 별다른 의심 없이 설치할 가능성이 높습니다.

따라서 중요한 시스템에서는 업데이트라고 해서 바로 적용하기보다 최소한 다음을 확인하는 습관이 좋습니다.

• 공식 사이트에서 받은 파일인가?
• 파일이나 배포처가 정상적인가?
• 갑자기 새로운 설치파일을 요구하지 않는가?
• 업데이트 전 백업이 있는가?
• 업데이트 이후 문제가 생기면 되돌릴 수 있는가?

생산설비나 중요한 업무시스템이라면 테스트 이후 적용하는 방식도 고려할 수 있습니다.

5. 개발자 계정 하나가 전체 시스템으로 이어질 수 있다

공급망 공격에서 놓치기 쉬운 것이 개발환경의 계정입니다.

개발자는 일반 직원보다 다양한 시스템에 접근하는 경우가 많습니다.

예를 들어,

• 소스코드 저장소
• 클라우드
• 개발서버
• 운영서버
• 배포 시스템
• 데이터베이스

등에 접근할 수 있습니다.

개발자 계정 하나가 탈취되면 공격자가 여러 시스템으로 이동할 가능성이 커질 수 있습니다.

따라서 개발과 배포 관련 계정은 일반 계정보다 더 엄격하게 관리하는 것이 좋습니다.

가능하다면 MFA를 적용하고 개인별 계정을 사용하며, 퇴사자나 프로젝트 종료 인원의 권한을 바로 정리해야 합니다.

SBOM이란 무엇일까?

소프트웨어 공급망 보안을 알아보다 보면 SBOM이라는 용어를 자주 만나게 됩니다.

SBOM은 Software Bill of Materials의 약자입니다.

쉽게 말하면 소프트웨어 구성품 목록입니다.

자동차를 만들 때 어떤 부품이 들어갔는지 부품표를 만드는 것처럼 프로그램 안에 어떤 라이브러리와 구성요소가 들어갔는지를 정리하는 개념입니다.

예를 들어 하나의 프로그램에 다음과 같은 구성요소가 있다고 가정해보겠습니다.

나중에 Library B 5.4 버전에서 심각한 취약점이 발견됐다고 가정해보겠습니다.

SBOM이 있다면 우리 프로그램이 해당 버전을 사용하고 있는지 비교적 빠르게 확인할 수 있습니다.

반대로 어떤 구성요소를 사용하는지 모른다면 개발자에게 하나씩 확인해야 할 수도 있습니다.

SBOM의 핵심 가치는 거창한 문서를 만드는 데 있는 것이 아닙니다.

문제가 발견됐을 때 우리도 영향을 받는지 빠르게 확인할 수 있도록 만드는 것입니다.

중소기업도 SBOM이 필요한가?

모든 소규모 회사가 당장 전문적인 SBOM 관리시스템을 구축해야 하는 것은 아닙니다.

하지만 자체 프로그램을 개발하거나 외주개발 시스템을 장기간 운영한다면 최소한 주요 구성요소 목록 정도는 받아두는 것이 좋습니다.

특히 다음과 같은 회사라면 검토할 가치가 있습니다.

• 소프트웨어 제품을 판매한다.
• 고객사에 프로그램을 납품한다.
• 공공기관에 소프트웨어를 공급한다.
• 여러 오픈소스를 이용해 제품을 개발한다.
• 클라우드 기반 서비스를 운영한다.
• 산업용 프로그램을 자체 개발한다.
• 외주개발 시스템을 오랫동안 운영한다.

처음부터 복잡하게 시작할 필요는 없습니다.

사용하는 주요 라이브러리 이름과 버전을 엑셀에 정리하는 것부터 시작할 수도 있습니다.

외주개발 업체에 꼭 물어볼 7가지

개발을 직접 하지 않는 회사라면 공급망 보안을 어렵게 느낄 필요가 없습니다.

납품업체에 아래 질문을 하는 것만으로도 현재 상태를 상당 부분 파악할 수 있습니다.

1. 어떤 오픈소스와 외부 라이브러리를 사용했나요?

주요 구성요소와 버전을 요청합니다.

2. 보안 취약점이 발견되면 누가 업데이트하나요?

유지보수 책임을 명확히 합니다.

3. 관리자 계정을 누가 가지고 있나요?

개발업체와 우리 회사의 관리자 권한을 확인합니다.

4. 소스코드는 어디에 보관되어 있나요?

개발업체에서만 가지고 있는지 확인합니다.

5. 외부 서비스와 API는 무엇을 사용하나요?

서비스가 중단되면 우리 시스템에도 영향을 주는지 확인합니다.

6. 계약이 끝나면 업체 계정은 어떻게 처리하나요?

유지보수 종료 후 접근권한이 남지 않도록 합니다.

7. 문제가 발생하면 이전 버전으로 복구할 수 있나요?

업데이트 실패나 사고에 대비한 복구방법을 확인합니다.

이 질문들을 계약이나 유지보수 과정에서 미리 확인하면 나중에 담당자가 바뀌어도 시스템을 관리하기 쉬워집니다.

소프트웨어 공급망 보안 체크리스트

현재 우리 회사가 사용하는 프로그램을 떠올리면서 아래 항목을 확인해볼 수 있습니다.

• 회사에서 사용하는 주요 소프트웨어 목록이 있는가?
• 외주개발 시스템의 담당업체를 알고 있는가?
• 주요 오픈소스 라이브러리와 버전을 확인할 수 있는가?
• 사용하지 않는 플러그인을 삭제하고 있는가?
• 소프트웨어 업데이트 담당자가 정해져 있는가?
• 취약점이 발견됐을 때 연락할 담당자가 있는가?
• 외주업체 관리자 계정을 파악하고 있는가?
• 프로젝트 종료 후 외부 계정을 삭제하는가?
• 중요한 업데이트 전에 백업하고 있는가?
• 소스코드가 어디에 보관되어 있는지 알고 있는가?
• 외부 API나 클라우드 서비스 목록이 있는가?
• 주요 프로그램의 구성요소를 확인할 수 있는가?

모든 항목을 완벽하게 관리할 필요는 없습니다.

중요한 것은 무엇을 사용하고 있는지도 모르는 상태를 줄이는 것입니다.

돈이 부족한 중소기업은 어디서부터 시작할까?

별도의 공급망 보안 솔루션을 바로 도입하기 어렵다면 다음 순서로 시작할 수 있습니다.

1단계. 프로그램 목록 만들기

회사에서 중요한 업무에 사용하는 프로그램부터 적습니다.

ERP, 홈페이지, 그룹웨어, 생산관리 프로그램, 앱 등을 정리합니다.

2단계. 담당자 확인

각 프로그램을 누가 관리하는지 표시합니다.

내부 직원인지 외주업체인지도 구분합니다.

3단계. 외부업체 계정 확인

현재도 접속할 수 있는 개발사와 유지보수 업체가 있는지 확인합니다.

4단계. 사용하지 않는 구성요소 정리

사용하지 않는 플러그인과 프로그램은 삭제합니다.

5단계. 주요 프로그램 업데이트 상태 확인

오래된 버전이 방치되어 있지 않은지 살펴봅니다.

6단계. 구성요소 목록 확보

중요한 외주개발 프로그램부터 사용된 주요 라이브러리와 버전을 요청합니다.

이 정도만 해도 공급망 보안의 기본적인 가시성을 상당히 높일 수 있습니다.

공급망 보안도 결국 ‘누가 무엇에 접근하는가’의 문제다

소프트웨어 공급망 공격이라고 하면 복잡한 해킹 기술부터 떠올리기 쉽습니다.

하지만 중소기업이 먼저 관리할 부분은 의외로 기본적인 것들입니다.

외부업체가 어떤 권한을 가지고 있는지, 개발자 계정은 제대로 관리되는지, 필요 없는 계정이 남아 있지는 않은지를 확인해야 합니다.

이런 접근권한 관리에는 제로트러스트의 기본 원칙도 연결할 수 있습니다.

필요한 사용자에게 필요한 권한만 주고, 필요하지 않으면 제거하는 것입니다.

소프트웨어 공급망도 결국 사람, 계정, 프로그램, 외부업체가 연결된 하나의 체계이기 때문입니다.

소프트웨어 공급망 공격을 막기 위해 가장 먼저 알아야 할 것

소프트웨어 공급망 공격을 완벽하게 차단하는 방법 하나가 존재하는 것은 아닙니다.

중요한 것은 우리 회사가 어떤 프로그램과 외부 서비스를 사용하고 있는지 아는 것입니다.

다시 말하면 다음 질문에 답할 수 있어야 합니다.

우리는 어떤 프로그램을 사용하고 있는가?

그 프로그램은 어떤 구성요소로 만들어졌는가?

누가 업데이트하고 관리하는가?

문제가 발생하면 영향을 받는 시스템을 찾을 수 있는가?

외부업체가 언제까지 접근할 수 있는가?

이 질문에 답할 수 있다면 공급망 보안의 절반은 이미 시작했다고 볼 수 있습니다.

중소기업이라면 처음부터 복잡한 보안 플랫폼을 구축하기보다 현재 사용하는 소프트웨어와 외부업체 목록을 만드는 것부터 시작해보는 것이 현실적입니다.

자주 묻는 질문

소프트웨어 공급망 공격이란 무엇인가요?

기업을 직접 공격하는 대신 기업이 사용하는 소프트웨어, 오픈소스, 외주개발 업체 또는 업데이트 과정 등을 공격해 최종 사용 기업까지 영향을 주는 공격방식을 의미합니다.

오픈소스를 사용하면 위험한가요?

오픈소스 사용 자체가 문제는 아닙니다. 어떤 오픈소스를 어떤 버전으로 사용하고 있으며 취약점이 발견됐을 때 업데이트할 수 있는지 관리하는 것이 중요합니다.

SBOM은 무엇인가요?

SBOM은 Software Bill of Materials의 약자로 프로그램을 구성하는 소프트웨어와 라이브러리 등의 목록을 의미합니다. 특정 구성요소에서 문제가 발견됐을 때 영향을 받는 시스템을 찾는 데 도움이 됩니다.

중소기업도 SBOM을 만들어야 하나요?

모든 기업이 전문 시스템을 바로 구축할 필요는 없습니다. 다만 소프트웨어를 개발하거나 고객에게 납품하고 있다면 주요 라이브러리와 버전 정도부터 관리하는 것이 좋습니다.

외주개발 시스템은 무엇부터 확인해야 하나요?

어떤 외부 라이브러리를 사용했는지, 업데이트 담당자는 누구인지, 관리자 계정을 누가 보유하고 있는지, 소스코드는 어디에 있는지부터 확인하는 것이 좋습니다.

공급망 보안에서 가장 먼저 해야 할 일은 무엇인가요?

회사가 사용하는 주요 소프트웨어와 외부 개발·유지보수 업체 목록부터 만드는 것을 권장합니다. 무엇을 사용하고 있는지 알아야 취약점이나 보안사고가 발생했을 때 우리 회사의 영향을 판단할 수 있습니다.

중소기업 제로트러스트 구축 방법을 검색하면 가장 먼저 드는 생각이 있습니다.

“직원 20~30명인 회사에도 이런 복잡한 보안이 필요할까?”

제로트러스트라는 이름 때문에 대기업이나 금융회사에서 사용하는 비싼 보안시스템이라고 생각하기 쉽습니다.

하지만 기본 개념은 생각보다 단순합니다.

한 번 로그인했다고 계속 믿지 않고, 필요한 사람에게 필요한 권한만 주는 것입니다.

직원 30명인 회사에서도 직원 계정, 클라우드, NAS, ERP, 이메일, VPN을 사용하고 있다면 이미 여러 사람이 회사 정보에 접근하고 있습니다.

퇴사자의 계정이 남아 있거나, 여러 사람이 관리자 계정을 공유하거나, 외부업체가 필요 이상으로 많은 시스템에 접속할 수 있다면 회사 규모와 관계없이 위험은 생길 수 있습니다.

제로트러스트는 이런 문제를 해결하기 위해 모든 것을 새로 구축하는 것이 아니라 현재 회사의 계정과 접근권한을 다시 정리하는 것부터 시작할 수 있습니다.

제로트러스트는 영어로 Zero Trust입니다.

직역하면 ‘아무도 믿지 않는다’는 의미처럼 보이지만 실제 보안에서는 조금 다르게 이해하는 것이 좋습니다.

핵심은 다음과 같습니다.

접속했다고 무조건 신뢰하지 말고 계속 확인한다.

예를 들어 회사 직원이 정상적인 아이디와 비밀번호로 로그인했다고 해도 항상 안전하다고 볼 수는 없습니다.

비밀번호가 유출됐을 수도 있고 평소와 전혀 다른 장소에서 접속했을 수도 있습니다.

그래서 제로트러스트에서는 다음과 같은 요소를 함께 확인합니다.

• 누구인지
• 어떤 기기를 사용하는지
• 어디에서 접속하는지
• 어떤 시스템에 접근하는지
• 필요한 권한인지
• 평소와 다른 행동은 없는지

즉, 회사 내부에서 접속했다는 이유만으로 모든 것을 허용하는 방식에서 벗어나는 것입니다.

일반적인 보안과 제로트러스트 차이

기존 회사 보안을 건물에 비유해보겠습니다.

회사 정문에서 출입증을 확인한 뒤 건물 안으로 들어오면 여러 공간을 비교적 자유롭게 이동할 수 있는 구조가 전통적인 방식과 비슷합니다.

제로트러스트는 다릅니다.

정문을 통과했더라도 서버실에 들어갈 때 다시 확인하고, 중요 문서에 접근할 때도 권한을 확인합니다.

이를 표로 정리하면 다음과 같습니다.

제로트러스트에서 가장 중요한 것은 비싼 장비가 아니라 신뢰를 자동으로 주지 않는 운영 원칙입니다.

직원 30명 중소기업에도 제로트러스트가 필요한 이유

직원이 적으면 보안 위험도 적을 것이라고 생각할 수 있습니다.

하지만 실제로는 직원 수보다 몇 개의 계정과 시스템이 서로 연결되어 있는지가 중요합니다.

직원 30명인 회사를 생각해보겠습니다.

회사가 다음 서비스를 사용한다고 가정합니다.

• 이메일
• NAS
• ERP
• 그룹웨어
• 클라우드
• VPN
• 회계 프로그램
• 회사 홈페이지 관리자
• 원격지원 프로그램

직원은 30명이지만 실제 관리해야 하는 계정과 접근경로는 훨씬 많아질 수 있습니다.

여기에 외부 세무사, 홈페이지 관리업체, 전산업체, 설비업체까지 추가된다면 회사 밖에서 접근하는 사용자도 생깁니다.

제로트러스트는 이런 환경에서 효과가 있습니다.

1. 공용 계정부터 없애기

중소기업에서 가장 먼저 확인하기 좋은 것이 공용 계정입니다.

예를 들어 다음과 같은 계정입니다.

admin

office

manager

service

여러 직원이 하나의 계정을 공유하면 편하기는 합니다.

하지만 문제가 발생했을 때 누가 사용했는지 확인하기 어렵습니다.

가능하면 직원마다 개별 계정을 사용하는 것이 좋습니다.

예를 들어,

기존

admin → 직원 5명이 공동사용

보다는

개선

kim01
lee02
park03

처럼 사용자별로 나누는 것입니다.

그러면 퇴사자가 발생했을 때 해당 직원 계정만 차단하면 됩니다.

제로트러스트의 첫 번째 단계는 의외로 거창하지 않습니다.

누가 사용하는 계정인지 알 수 있도록 만드는 것입니다.

2. MFA를 적용하기

비밀번호만으로 로그인하는 회사라면 MFA 적용을 검토할 수 있습니다.

MFA는 Multi-Factor Authentication, 다중인증을 의미합니다.

쉽게 말하면 비밀번호 외에 한 가지 인증을 더 요구하는 것입니다.

예를 들어,

아이디 + 비밀번호 + 휴대폰 인증

방식입니다.

비밀번호가 유출되어도 추가 인증을 통과하지 못하면 계정 접근을 막을 수 있습니다.

모든 시스템에 한꺼번에 MFA를 적용하기 어렵다면 중요한 시스템부터 적용할 수 있습니다.

우선순위는 다음과 같이 잡아볼 수 있습니다.

1. 관리자 계정
2. 회사 이메일
3. 클라우드
4. VPN
5. 중요 업무시스템

특히 관리자 계정과 외부에서 접근할 수 있는 계정에는 MFA 적용 효과가 큽니다.

3. 직원마다 필요한 권한만 주기

제로트러스트의 핵심 중 하나가 최소 권한입니다.

업무에 필요한 만큼만 접근하도록 하는 것입니다.

예를 들어 회사에 인사팀, 영업팀, 생산팀이 있다고 가정해보겠습니다.

영업팀 직원이 급여자료까지 볼 필요는 없습니다.

생산팀 직원이 회계자료를 수정할 필요도 없습니다.

따라서 모든 직원에게 동일한 폴더와 시스템 권한을 주기보다 업무별로 나누는 것이 좋습니다.

예를 들면 다음과 같습니다.

여기서 중요한 원칙은 이것입니다.

혹시 필요할 수도 있으니 권한을 주는 것이 아니라 실제 필요한 권한만 준다.

작은 회사일수록 직원들이 여러 업무를 담당해 권한이 넓어지기 쉽기 때문에 한번 정리해볼 필요가 있습니다.

4. 퇴사자 계정을 바로 정리하기

직원이 퇴사하면 출입카드와 회사 노트북은 반납받으면서 계정은 그대로 남겨두는 경우가 있습니다.

특히 다음 계정을 놓치기 쉽습니다.

• 회사 이메일
• VPN
• NAS
• 클라우드
• 홈페이지 관리자
• ERP
• 공유드라이브
• 원격지원 프로그램

퇴사자 계정 관리에서는 퇴사 당일 처리할 체크리스트를 만들어두는 것이 좋습니다.

예를 들어,

• 이메일 차단
• VPN 차단
• NAS 계정 삭제
• 클라우드 접근권한 삭제
• 관리자 계정 비밀번호 변경
• 회사 장비 회수
• 외부 서비스 계정 확인

이 정도만 정해놓아도 담당자가 바뀌었을 때 빠뜨릴 가능성을 줄일 수 있습니다.

5. 관리자 계정을 일반 업무에 사용하지 않기

관리자 계정은 일반 직원 계정보다 할 수 있는 일이 많습니다.

프로그램 설치, 계정 생성, 설정 변경, 데이터 접근까지 가능한 경우가 있습니다.

문제는 이 관리자 계정을 평소 인터넷 검색이나 이메일 확인에도 사용하는 것입니다.

관리자 계정이 탈취되면 공격자 역시 높은 권한을 얻을 가능성이 있습니다.

그래서 가능하다면 다음처럼 구분하는 것이 좋습니다.

일반 업무 → 일반 계정

시스템 설정 → 관리자 계정

관리자 계정을 항상 사용할 이유는 없습니다.

필요한 순간에만 관리자 권한을 사용하는 습관이 중요합니다.

6. 외부업체도 내부 직원과 똑같이 관리하기

중소기업에서는 외부업체가 여러 시스템을 관리하는 경우가 많습니다.

예를 들어,

• 홈페이지 제작업체
• ERP 유지보수 업체
• 전산업체
• 스마트공장 구축업체
• 설비 유지보수 업체
• 회계·세무 관련 업체

등이 있습니다.

문제는 프로젝트가 끝났는데도 계정이 그대로 남아 있는 경우입니다.

외부업체 계정에는 특히 네 가지 기준을 적용하면 좋습니다.

누가 접속하는가?

어디까지 접속하는가?

언제까지 사용할 수 있는가?

접속기록이 남는가?

외부업체라고 해서 무조건 위험하다는 뜻이 아닙니다.

누가 어떤 권한을 가지고 있는지가 불분명한 상태가 위험한 것입니다.

7. 회사 안에서 접속한다고 무조건 믿지 않기

과거에는 회사 내부망이면 비교적 안전하다고 보는 경우가 많았습니다.

하지만 노트북, 스마트폰, 클라우드, 재택근무, VPN 등이 늘면서 내부와 외부의 경계가 예전만큼 명확하지 않습니다.

직원이 회사 와이파이에 연결되어 있다고 해서 모든 시스템에 자동으로 접근하도록 할 필요는 없습니다.

중요 시스템은 다시 인증하도록 하거나 사용자별 권한을 확인하는 방식을 적용할 수 있습니다.

제로트러스트에서 중요한 생각은 이것입니다.

장소보다 사용자와 권한을 확인한다.

돈 적게 들이고 제로트러스트 시작하는 순서

중소기업에서 처음부터 새로운 보안 플랫폼을 구축할 필요는 없습니다.

현재 사용하고 있는 계정과 기능부터 정리할 수 있습니다.

1단계. 계정 목록 만들기

회사에서 사용하는 시스템을 적어봅니다.

• 이메일
• NAS
• ERP
• VPN
• 클라우드
• 홈페이지
• 원격지원

그리고 각 시스템에 누가 계정을 가지고 있는지 정리합니다.

2단계. 사용하지 않는 계정 삭제

퇴사자, 계약 종료 업체, 장기 미사용 계정을 찾습니다.

불필요한 계정은 비활성화하거나 삭제합니다.

3단계. 관리자 권한 줄이기

직원 중 관리자 권한을 가진 사람이 몇 명인지 확인합니다.

업무상 필요하지 않다면 일반 사용자 권한으로 변경합니다.

4단계. 중요 계정에 MFA 적용

관리자 계정, 이메일, VPN, 클라우드처럼 외부에서 접근 가능한 시스템부터 MFA를 적용합니다.

5단계. 업무별 접근권한 구분

모든 직원이 모든 자료를 볼 수 있는 구조라면 부서와 업무에 따라 권한을 나눕니다.

6단계. 접속기록 확인

중요 시스템은 누가 언제 로그인했는지 확인할 수 있도록 합니다.

여기까지만 해도 상당 부분은 별도의 대규모 보안 프로젝트 없이 시작할 수 있습니다.

직원 30명 회사 제로트러스트 예시

직원 30명인 제조기업을 예로 들어보겠습니다.

기존에는 다음과 같이 운영하고 있었다고 가정합니다.

기존 상태

• NAS 관리자 계정 5명 공동사용
• 외부업체 VPN 공용계정 사용
• 퇴사자 이메일 일부 유지
• 모든 직원이 공용폴더 전체 접근
• 관리자 계정 MFA 없음

이 회사가 처음부터 비싼 제로트러스트 시스템을 살 필요는 없습니다.

먼저 이렇게 바꿀 수 있습니다.

1개월차

공용계정 사용자별 분리

2개월차

퇴사자·미사용 계정 정리

3개월차

관리자와 VPN 계정 MFA 적용

4개월차

부서별 NAS 접근권한 분리

5개월차

외부업체 계정 기간 제한

6개월차

중요 시스템 접속기록 정기 확인

이것도 제로트러스트 접근의 시작입니다.

중요한 것은 제품 이름이 아니라 누구에게 어떤 권한을 줄 것인가를 계속 관리하는 것입니다.

중소기업 제로트러스트 구축 체크리스트

우리 회사가 현재 어느 정도 준비되어 있는지 아래 항목으로 확인해볼 수 있습니다.

• 직원마다 개인 계정을 사용하는가?
• 관리자 공용계정을 최소화했는가?
• 퇴사자 계정을 바로 삭제하는가?
• 관리자 계정에 MFA를 적용했는가?
• VPN 등 외부접속 계정에 MFA를 적용했는가?
• 부서별 접근권한이 구분되어 있는가?
• 외부업체 계정을 별도로 관리하는가?
• 외부업체 계정 사용기간을 정하고 있는가?
• 중요 시스템 접속기록을 확인할 수 있는가?
• 관리자 권한을 가진 사용자를 파악하고 있는가?
• 사용하지 않는 계정을 정기적으로 확인하는가?
• 중요 데이터에 접근할 수 있는 사용자를 알고 있는가?

모든 항목을 한 번에 해결할 필요는 없습니다.

답하기 어려운 항목이 있다면 바로 그 부분이 우리 회사가 먼저 정리할 부분이라고 생각하면 됩니다.

제로트러스트 도입에서 자주 하는 실수

제로트러스트를 새로운 보안제품 하나를 설치하는 프로젝트라고 생각하면 시작부터 복잡해질 수 있습니다.

특히 다음과 같은 접근은 주의할 필요가 있습니다.

모든 시스템을 한꺼번에 바꾸려는 것

업무 영향이 커질 수 있습니다.

관리자 계정이나 외부접속처럼 위험도가 높은 영역부터 시작하는 것이 현실적입니다.

직원에게 설명하지 않고 권한만 줄이는 것

어제까지 열리던 폴더가 갑자기 차단되면 업무 불편으로 받아들여질 수 있습니다.

왜 권한을 변경하는지 설명하는 과정도 필요합니다.

MFA만 적용하면 끝났다고 생각하는 것

MFA는 중요한 보안수단이지만 제로트러스트 전체를 의미하지는 않습니다.

계정관리, 최소 권한, 외부접속 관리 등이 함께 이루어져야 합니다.

너무 많은 보안제품부터 구입하는 것

실제 운영할 사람이 없다면 좋은 제품도 제대로 활용하기 어렵습니다.

기존 환경에서 할 수 있는 계정과 권한 관리부터 정리한 이후 부족한 기능을 추가하는 편이 좋습니다.

SIEM·XDR·SOAR과 제로트러스트는 어떤 관계일까?

제로트러스트는 특정 보안제품 이름이라기보다 접근을 관리하는 보안 원칙에 가깝습니다.

반면 SIEM, XDR, SOAR은 보안 운영 과정에서 로그를 수집하고 위협을 탐지하거나 대응을 자동화하는 데 활용할 수 있는 기술입니다.

쉽게 구분하면,

제로트러스트 → 누가 무엇에 접근하도록 허용할 것인가

SIEM → 어떤 기록이 발생했는가

XDR → 위험한 행동이 발생했는가

SOAR → 문제가 발생하면 어떻게 대응할 것인가

라고 볼 수 있습니다.

회사 보안이 어느 정도 커지면 이런 기술을 서로 연결할 수도 있습니다.

중소기업 제로트러스트는 계정 정리부터 시작하면 된다

중소기업 제로트러스트 구축 방법을 어렵게 생각할 필요는 없습니다.

직원 30명 회사라면 처음부터 거대한 시스템을 도입하는 것보다 먼저 현재 회사에 존재하는 계정을 확인해보는 것이 좋습니다.

그 다음 네 가지를 순서대로 확인하면 됩니다.

누가 접속할 수 있는가?

그 사람에게 정말 필요한 권한인가?

접속한 사람이 실제 본인인지 확인할 수 있는가?

더 이상 필요하지 않은 권한은 없어지는가?

제로트러스트는 모든 직원을 의심하자는 개념이 아닙니다.

사용자를 불편하게 만드는 것이 목적도 아닙니다.

계정이 탈취되거나 실수가 발생하더라도 한 번의 문제가 회사 전체로 번지지 않도록 접근범위를 줄이는 것에 가깝습니다.

중소기업이라면 가장 먼저 비싼 보안솔루션의 견적을 받기보다 오늘 회사에서 사용하고 있는 관리자 계정과 퇴사자 계정이 몇 개인지 확인하는 것부터 시작해볼 수 있습니다.

자주 묻는 질문

제로트러스트란 무엇인가요?

한 번 인증했다고 사용자를 계속 신뢰하는 것이 아니라 사용자, 기기, 접근대상 등을 확인하고 필요한 최소한의 권한만 부여하는 보안 방식입니다.

직원 30명 중소기업에도 제로트러스트가 필요한가요?

직원 수보다 회사가 사용하는 계정, 클라우드, VPN, NAS, 외부업체 접속 등 접근경로가 얼마나 있는지가 중요합니다. 소규모 회사도 계정과 권한 관리 원칙을 적용할 수 있습니다.

제로트러스트를 구축하려면 비싼 솔루션이 필요한가요?

반드시 그렇지는 않습니다. 사용자별 계정 사용, 퇴사자 계정 삭제, 관리자 권한 최소화, MFA 적용, 외부업체 계정 관리처럼 기존 시스템에서도 시작할 수 있는 항목이 많습니다.

제로트러스트와 MFA는 같은 것인가요?

아닙니다. MFA는 제로트러스트를 구현하는 데 활용할 수 있는 인증 방법 중 하나입니다. 제로트러스트에는 인증뿐 아니라 최소 권한, 계정관리, 접근통제, 접속기록 등의 개념도 포함됩니다.

중소기업에서 가장 먼저 해야 할 것은 무엇인가요?

회사에서 사용하는 계정 목록부터 만드는 것이 좋습니다. 누가 어떤 시스템에 접근할 수 있는지 정리하면 미사용 계정이나 과도한 관리자 권한을 발견하기 쉬워집니다.

SIEM XDR SOAR 차이를 처음 찾아보면 세 가지 모두 보안위협을 탐지하고 대응하는 솔루션처럼 보여 구분하기 어렵습니다.

하지만 실제 역할은 조금씩 다릅니다.

아주 쉽게 표현하면 SIEM은 여러 보안기기의 기록을 모아 분석하는 역할, XDR은 여러 영역에서 발생하는 공격 흐름을 연결해 탐지하는 역할, SOAR은 탐지된 보안사고에 대한 대응 절차를 자동화하는 역할에 가깝습니다.

문제는 중소기업 입장에서 이 세 가지를 모두 도입해야 하는지입니다.

직원 30명인 회사와 서버 수백 대를 운영하는 기업의 보안환경은 같을 수 없습니다. 보안솔루션도 유명한 제품부터 구매하는 것보다 현재 우리 회사에서 어떤 보안 문제가 발생하고 있는지부터 파악하는 것이 중요합니다.

이번 글에서는 SIEM, XDR, SOAR의 차이와 중소기업이 어떤 순서로 접근하면 좋은지 쉽게 정리해보겠습니다.

SIEM XDR SOAR 차이부터 간단히 이해하기

세 가지 용어를 한 번에 외우려고 하면 어렵습니다.

회사에 CCTV가 설치되어 있다고 생각하면 조금 쉽습니다.

SIEM은 여러 장소의 기록을 한곳에 모아 확인하는 관제실,
XDR은 여러 카메라의 움직임을 연결해 수상한 행동을 찾아내는 분석가,
SOAR은 문제가 발견됐을 때 정해진 절차에 따라 출입을 막고 담당자에게 연락하는 자동 대응 시스템에 비유할 수 있습니다.

정리하면 다음과 같습니다.

세 가지가 경쟁관계라기보다는 서로 연결해서 사용할 수 있는 기술이라고 이해하는 것이 좋습니다.

SIEM이란? 흩어진 보안 로그를 한곳에 모으는 시스템

SIEM은 Security Information and Event Management의 약자입니다.

회사에는 생각보다 많은 로그가 만들어집니다.

예를 들어 다음과 같습니다.

• 방화벽 접속 기록
• 서버 로그인 기록
• VPN 접속 기록
• 직원 PC 보안 이벤트
• 이메일 보안 기록
• 클라우드 접속 기록
• 관리자 계정 사용 기록

각 장비를 따로 확인하려면 사고가 발생할 때마다 여러 시스템에 접속해야 합니다.

SIEM은 이런 기록을 한곳으로 모아 검색하고 분석할 수 있게 도와줍니다.

예를 들어 새벽 3시에 관리자 계정으로 서버에 로그인했고, 몇 분 뒤 대량의 데이터가 외부로 전송됐다면 각각의 기록만 봐서는 이상 여부를 알아채기 어려울 수 있습니다.

SIEM에 로그가 모여 있다면 시간 순서대로 사건을 확인하기 쉬워집니다.

SIEM이 필요한 회사

다음과 같은 상황이라면 SIEM을 검토할 이유가 있습니다.

• 서버가 여러 대 있다.
• 방화벽이나 VPN 등 보안장비가 많다.
• 클라우드 서비스를 여러 개 사용한다.
• 보안 로그를 장기간 보관해야 한다.
• 사고 발생 시 원인을 추적하기 어렵다.
• 보안 담당자가 여러 시스템을 매일 확인하고 있다.

반대로 PC 몇 대와 간단한 공유기 정도만 사용하는 소규모 사업장이라면 처음부터 대규모 SIEM을 구축하는 것은 과할 수 있습니다.

XDR이란? 여러 영역에서 공격 흐름을 연결해 찾는 기술

XDR은 Extended Detection and Response의 약자입니다.

핵심은 탐지와 대응입니다.

기존에는 PC, 이메일, 서버, 네트워크, 클라우드에서 발생하는 보안 문제를 각각 다른 제품이 확인하는 경우가 많았습니다.

문제는 실제 사이버공격이 한 곳에서만 발생하지 않는다는 것입니다.

예를 들어 이런 흐름이 생길 수 있습니다.

피싱메일 수신 → 직원 계정 탈취 → PC 로그인 → 서버 접근 → 중요파일 외부 전송

각 단계만 따로 보면 평범한 행동처럼 보일 수도 있습니다.

하지만 여러 이벤트를 연결하면 하나의 공격 흐름으로 판단할 가능성이 높아집니다.

XDR은 이런 서로 다른 영역의 데이터를 연결해 위협을 찾는 데 초점을 둡니다.

XDR이 필요한 회사

다음과 같은 환경이라면 XDR을 검토할 수 있습니다.

• 직원 PC가 많다.
• 이메일 공격이 자주 발생한다.
• 클라우드와 사내 시스템을 함께 사용한다.
• EDR 등 여러 보안솔루션을 운영한다.
• 보안 알림이 너무 많이 발생한다.
• 개별 이벤트보다 전체 공격 흐름을 파악하고 싶다.

특히 보안 담당자가 한두 명뿐인 회사라면 의미 없는 경고를 일일이 확인하는 것이 큰 부담이 될 수 있습니다.

이럴 때 중요한 것은 경고의 개수보다 실제로 위험한 이벤트를 얼마나 빠르게 찾아낼 수 있느냐입니다.

SOAR이란? 반복되는 보안대응을 자동화하는 시스템

SOAR은 Security Orchestration, Automation and Response의 약자입니다.

쉽게 말하면 보안사고가 발생했을 때 사람이 반복해서 하던 대응 절차를 자동화하는 개념입니다.

예를 들어 회사에서 악성 IP 접속이 발견됐다고 가정해보겠습니다.

기존에는 담당자가 다음과 같은 작업을 직접 해야 할 수 있습니다.

1. 보안 경고 확인
2. 해당 IP 조회
3. 관련 사용자 확인
4. 방화벽 차단
5. 해당 PC 격리
6. 담당자에게 알림
7. 처리 결과 기록

하루 한두 건이라면 사람이 처리할 수 있습니다.

하지만 수십 건씩 발생하면 보안 담당자가 반복 작업에 대부분의 시간을 사용하게 됩니다.

SOAR에서는 미리 정한 대응 절차, 즉 플레이북을 만들어 일부 과정을 자동화할 수 있습니다.

예를 들어 위험도가 높은 악성 IP가 발견되면 담당자에게 알림을 보내고, 승인 후 자동으로 차단하도록 만드는 방식입니다.

SIEM과 XDR은 무엇이 다를까?

가장 많이 헷갈리는 부분입니다.

SIEM과 XDR 모두 보안 데이터를 분석하기 때문입니다.

차이는 어디에 더 초점을 두는지에서 찾을 수 있습니다.

SIEM

기록을 폭넓게 수집하고 분석하는 것에 강점이 있습니다.

다양한 시스템의 로그를 모으고 검색하거나 보안사고 발생 후 원인을 분석하는 데 활용할 수 있습니다.

XDR

공격을 탐지하고 공격 흐름을 연결하는 것에 더 초점이 있습니다.

엔드포인트, 이메일, 네트워크, 클라우드 등 서로 다른 영역의 이벤트를 연결해 실제 공격 가능성이 높은 행동을 식별하는 데 활용됩니다.

쉽게 말하면,

SIEM = 기록 중심

XDR = 위협 탐지 중심

이라고 생각하면 처음 개념을 잡는 데 도움이 됩니다.

다만 실제 제품은 기능이 서로 겹치는 경우가 많기 때문에 제품 이름만 보고 판단하기보다 우리 회사에 필요한 기능을 먼저 정하는 것이 중요합니다.

XDR과 SOAR의 차이는 무엇일까?

XDR이 위험한 행동을 발견했다면 그 다음에는 대응이 필요합니다.

이 과정에서 SOAR이 활용될 수 있습니다.

예를 들어 XDR이 특정 PC에서 랜섬웨어로 의심되는 행동을 탐지했다고 가정해보겠습니다.

SOAR에 대응 절차가 설정되어 있다면 상황에 따라 다음과 같은 작업을 연결할 수 있습니다.

위협 탐지 → 위험도 확인 → 담당자 알림 → PC 격리 → 계정 잠금 → 티켓 생성

즉,

XDR이 “문제가 생겼다”고 알려주는 역할이라면 SOAR은 “그러면 무엇을 할 것인가”를 자동화하는 역할이라고 이해하면 쉽습니다.

중소기업은 SIEM XDR SOAR 중 무엇부터 도입해야 할까?

가장 중요한 부분입니다.

결론부터 말하면 회사마다 다릅니다.

세 가지를 모두 도입하는 것이 정답은 아닙니다.

현재 보안환경을 먼저 확인해야 합니다.

직원 10~30명 정도의 소규모 회사

처음부터 SIEM과 SOAR까지 구축하는 것보다 기본적인 보안관리가 우선일 수 있습니다.

먼저 확인할 것은 다음과 같습니다.

• 사용자별 계정 사용
• MFA 적용
• 백신 또는 엔드포인트 보안
• 운영체제 업데이트
• 관리자 계정 분리
• 데이터 백업
• 퇴사자 계정 삭제

기본 관리가 되지 않은 상태에서 복잡한 통합보안 시스템을 도입하면 운영하기 어려울 수 있습니다.

직원과 PC가 많고 보안담당자가 적은 회사

XDR 또는 EDR 계열의 위협 탐지 시스템을 먼저 검토할 수 있습니다.

PC와 서버에서 발생하는 이상행동을 빠르게 발견하는 것이 우선이기 때문입니다.

특히 직원 PC가 많아 사람이 모든 보안 경고를 확인하기 어렵다면 탐지 자동화의 효과가 커질 수 있습니다.

서버와 보안장비가 많은 회사

SIEM의 필요성이 커질 수 있습니다.

방화벽, 서버, VPN, 클라우드 등 여러 시스템의 기록이 흩어져 있다면 사고 발생 시 원인을 찾는 데 시간이 오래 걸리기 때문입니다.

로그를 한곳에서 관리하면 보안사고 분석뿐 아니라 운영 문제를 찾을 때도 도움이 됩니다.

보안 이벤트가 많고 반복 업무가 많은 회사

이 단계에서는 SOAR을 검토할 수 있습니다.

보안 경고가 발생할 때마다 같은 조사와 차단 과정을 반복하고 있다면 자동화 효과가 생길 수 있습니다.

하지만 발생하는 보안 이벤트 자체가 많지 않은 회사라면 SOAR을 먼저 도입할 필요성은 낮을 수 있습니다.

중소기업 보안솔루션 도입 순서

복잡하게 생각하지 않고 단계별로 접근한다면 다음과 같이 생각해볼 수 있습니다.

1단계. 자산 파악

먼저 보호해야 할 대상을 알아야 합니다.

• PC 몇 대인가?
• 서버 몇 대인가?
• 클라우드를 사용하는가?
• VPN이 있는가?
• 외부업체가 접속하는가?
• 중요한 데이터는 어디에 있는가?

2단계. 기본 보안체계 구축

계정관리, MFA, 백업, 패치, 엔드포인트 보호처럼 기본적인 보안부터 적용합니다.

3단계. 위협 탐지 강화

PC와 서버가 많아지면 EDR 또는 XDR 등을 이용해 이상행동 탐지를 강화할 수 있습니다.

4단계. 로그 통합

여러 보안장비와 서버를 운영하면서 로그가 분산된다면 SIEM 등을 이용한 통합관제를 검토할 수 있습니다.

5단계. 대응 자동화

사고 대응 업무가 반복되고 운영해야 할 보안도구가 많아졌다면 SOAR을 이용한 자동화를 검토할 수 있습니다.

이 순서가 모든 기업에 절대적인 기준은 아니지만 기본 보안 → 탐지 → 통합 → 자동화라는 흐름으로 생각하면 훨씬 이해하기 쉽습니다.

보안솔루션 도입 전에 확인해야 할 체크리스트

제품 상담을 받기 전에 아래 질문부터 확인해보는 것을 권합니다.

• 우리 회사가 보호해야 할 중요 시스템을 알고 있는가?
• 현재 사용 중인 보안제품 목록이 있는가?
• 사용자와 관리자 계정을 구분하고 있는가?
• 보안 로그를 어디에 보관하는지 알고 있는가?
• 사고가 발생했을 때 누가 대응하는지 정해져 있는가?
• 하루에 발생하는 보안 경고가 얼마나 되는지 알고 있는가?
• 보안솔루션을 운영할 담당자가 있는가?
• 클라우드와 사내 시스템을 함께 사용하는가?
• 외부업체의 원격접속을 관리하고 있는가?
• 도입 후 실제 운영할 수 있는 예산과 인력이 있는가?

특히 마지막 질문이 중요합니다.

보안솔루션은 설치하는 것으로 끝나지 않습니다.

경고를 확인하고 정책을 수정하며 사고가 발생했을 때 대응할 사람이 필요합니다.

따라서 기능이 가장 많은 제품보다 우리 회사가 실제로 운영할 수 있는 제품이 더 좋은 선택일 수 있습니다.

스마트공장을 운영한다면 IT와 OT까지 함께 봐야 한다

제조기업이라면 한 가지를 더 고려해야 합니다.

사무실 PC와 서버뿐 아니라 PLC, 산업용 PC, 생산설비 같은 OT 시스템까지 연결되어 있을 수 있기 때문입니다.

특히 ERP, MES, 원격유지보수 시스템 등이 생산망과 연결되어 있다면 일반 IT 보안만으로 전체 위험을 판단하기 어렵습니다.

IT와 OT 환경의 차이가 궁금하다면 아래 글도 함께 확인해볼 수 있습니다.

IT 보안과 OT 보안 차이｜스마트공장 보안이 일반 회사와 다른 이유

SIEM XDR SOAR 선택보다 먼저 해야 할 것

SIEM, XDR, SOAR 가운데 어떤 제품이 가장 좋은지를 먼저 고민할 필요는 없습니다.

오히려 다음 세 가지 질문이 더 중요합니다.

지금 우리 회사에서 가장 찾기 어려운 보안사고는 무엇인가?

보안 담당자가 가장 많은 시간을 사용하는 업무는 무엇인가?

사고가 발생했을 때 가장 오래 걸리는 과정은 무엇인가?

로그가 흩어져 있어 사고 원인을 찾기 어렵다면 SIEM이 도움이 될 수 있습니다.

여러 시스템에서 발생하는 공격을 연결해 탐지하기 어렵다면 XDR을 검토할 수 있습니다.

반복적인 대응 업무 때문에 사람이 부족하다면 SOAR의 자동화 기능이 도움이 될 수 있습니다.

즉, 제품 이름에서 출발하는 것이 아니라 현재 문제에서 출발해야 합니다.

자주 묻는 질문

SIEM XDR SOAR 차이를 가장 쉽게 설명하면 무엇인가요?

SIEM은 여러 시스템의 보안 로그를 모아 분석하는 역할, XDR은 여러 영역에서 발생하는 보안 이벤트를 연결해 위협을 탐지하는 역할, SOAR은 탐지된 사고의 대응 절차를 자동화하는 역할이라고 이해하면 쉽습니다.

중소기업은 SIEM이 꼭 필요한가요?

모든 중소기업에 반드시 필요한 것은 아닙니다. 서버와 보안장비가 많고 여러 시스템의 로그를 통합해 관리해야 하는 환경이라면 필요성이 커질 수 있습니다.

XDR과 EDR은 무엇이 다른가요?

EDR은 주로 PC와 서버 같은 엔드포인트의 위협 탐지와 대응에 초점을 둡니다. XDR은 엔드포인트뿐 아니라 이메일, 네트워크, 클라우드 등 더 넓은 영역의 보안 데이터를 연결해 분석하는 방향으로 이해할 수 있습니다.

SOAR을 먼저 도입해도 되나요?

기술적으로 가능하지만 자동화할 보안절차와 연동할 보안도구가 많지 않다면 효과가 제한적일 수 있습니다. 기본 보안체계와 탐지·로그 관리가 어느 정도 갖춰진 이후 검토하는 편이 이해하기 쉽습니다.

SIEM과 XDR을 함께 사용할 수 있나요?

가능합니다. 두 시스템의 기능이 일부 겹칠 수 있지만 로그 통합과 장기 분석에는 SIEM을 활용하고 위협 탐지와 연관분석에는 XDR을 활용하는 식으로 구성할 수 있습니다.

보안 담당자가 한 명뿐이라면 무엇이 중요할까요?

제품의 기능 개수보다 운영 부담을 먼저 확인하는 것이 좋습니다. 너무 많은 경고가 발생하는 제품보다 실제 위험도가 높은 이벤트를 빠르게 확인하고 대응할 수 있는 환경을 만드는 것이 중요합니다.

결론

SIEM XDR SOAR 차이를 어렵게 외울 필요는 없습니다.

SIEM은 기록을 모으고, XDR은 위협을 연결해서 찾고, SOAR은 대응을 자동화한다고 생각하면 기본적인 차이를 이해할 수 있습니다.

중소기업에서는 세 가지 솔루션을 모두 갖추는 것보다 현재 회사에 가장 부족한 부분을 찾는 것이 먼저입니다.

로그를 찾느라 시간이 오래 걸리는지, 공격을 발견하기 어려운지, 아니면 반복 대응에 사람이 너무 많이 필요한지를 확인해보세요.

보안솔루션의 목적은 제품을 많이 설치하는 것이 아니라 사고를 더 빨리 발견하고, 피해 범위를 줄이고, 정상적인 업무로 더 빨리 돌아가기 위한 것입니다.

그 기준으로 보면 우리 회사에 SIEM, XDR, SOAR 중 무엇이 먼저 필요한지도 훨씬 명확해질 수 있습니다.

일반 회사의 IT 보안에서는 PC, 서버, 이메일, 개인정보처럼 정보와 데이터 보호가 중요합니다.

IT 보안과 OT 보안 차이를 이해하려면 먼저 무엇을 보호하는지 살펴보는 것이 가장 쉽습니다.

반면 스마트공장이나 생산현장의 OT 보안에서는 PLC, 산업용 PC, 로봇, 센서, 생산설비처럼 실제로 움직이는 장비와 생산공정의 안정적인 운영까지 함께 보호해야 합니다.

그래서 사무실에서 효과적인 보안 방법을 생산현장에 그대로 적용하면 예상하지 못한 문제가 발생할 수 있습니다.

예를 들어 사무용 PC는 보안 업데이트를 위해 재부팅해도 업무를 잠시 멈추는 수준에서 끝날 수 있습니다. 그러나 24시간 움직이는 생산설비와 연결된 시스템을 갑자기 재부팅한다면 생산 자체에 영향을 줄 수 있습니다.

스마트공장 보안을 제대로 이해하려면 바로 이 차이부터 알아둘 필요가 있습니다.

IT 보안과 OT 보안이란?

IT는 Information Technology, 즉 정보기술을 의미합니다.

일반적으로 회사에서 사용하는 다음과 같은 시스템을 IT 영역으로 볼 수 있습니다.

• 업무용 PC
• 이메일
• ERP
• 그룹웨어
• 파일서버
• 데이터베이스
• 클라우드 서비스
• 사내 네트워크

IT 보안에서는 기업정보와 개인정보를 보호하고, 외부 침입이나 데이터 변조로부터 시스템을 안전하게 운영하는 것이 중요합니다.

반면 OT는 Operational Technology, 즉 운영기술을 의미합니다.

공장이나 산업현장에서 실제 설비를 감시하고 제어하는 기술입니다.

대표적으로 다음과 같은 시스템과 장비가 있습니다.

• PLC
• 산업용 PC
• 생산설비
• 산업용 로봇
• 센서
• HMI
• SCADA
• 각종 제어장치

쉽게 표현하면 IT가 정보를 처리하는 영역이라면 OT는 현실의 장비와 공정을 움직이는 영역이라고 이해할 수 있습니다.

OT 보안에 대해 좀 더 전문적인 내용을 확인하고 싶다면 미국 국립표준기술연구소(NIST)의 공식 OT 보안 가이드도 참고할 만합니다.

NIST Operational Technology(OT) Security 공식 가이드 보기

IT 보안과 OT 보안 차이 한눈에 보기

두 환경의 차이를 표로 보면 이해하기 쉽습니다.

가장 중요한 차이는 보안의 우선순위입니다.

IT 환경에서는 기업의 중요한 정보가 외부로 유출되거나 변경되지 않도록 보호하는 것이 중요합니다.

OT 환경에서는 여기에 하나가 더 추가됩니다.

바로 설비가 멈추지 않고 정상적으로 작동해야 한다는 것입니다.

스마트공장 보안이 일반 회사와 다른 이유

스마트공장은 과거의 공장과 구조가 많이 달라졌습니다.

예전에는 생산설비가 독립적으로 움직이는 경우가 많았지만 지금은 생산실적을 ERP로 전송하거나 MES와 연결하고, 외부 설비업체가 원격으로 장비를 점검하기도 합니다.

생산현장에서 만들어지는 데이터를 클라우드로 전송하는 경우도 있습니다.

결국 생산설비와 일반 정보시스템 사이의 경계가 점점 흐려지고 있는 것입니다.

예를 들면 다음과 같은 연결 구조가 만들어질 수 있습니다.

인터넷 → 회사 IT망 → 생산관리 시스템 → 산업용 PC → PLC → 생산설비

이처럼 IT와 OT가 연결되면 앞쪽 시스템에서 발생한 문제가 생산설비 쪽으로 영향을 미칠 가능성도 생각해야 합니다.

그래서 스마트공장에서는 IT 보안과 OT 보안을 각각 따로 생각하기보다 두 영역이 어디에서 연결되는지를 파악하는 것이 중요합니다.

1. 생산설비는 마음대로 재부팅하기 어렵다

IT 보안에서는 문제가 발생했을 때 PC를 재부팅하거나 서버를 잠시 중지한 뒤 업데이트하는 방법을 사용할 수 있습니다.

하지만 OT 환경에서는 상황이 다릅니다.

공장의 핵심 생산설비가 계속 가동되고 있다면 보안 업데이트 하나를 위해 갑자기 시스템을 중단하기 어렵습니다.

설비가 중단되면 다음과 같은 문제가 연쇄적으로 발생할 수 있습니다.

• 생산량 감소
• 납기 지연
• 제품 불량
• 공정 재설정
• 생산라인 재가동
• 협력업체 일정 변경

따라서 OT 보안에서는 단순히 최신 보안패치를 빠르게 설치하는 것보다 생산에 영향을 최소화하면서 안전하게 적용할 방법까지 함께 고려해야 합니다.

보안을 위해 생산을 무조건 중단할 수도 없고, 생산 때문에 보안을 계속 미룰 수도 없습니다.

이 균형을 찾는 것이 OT 보안의 중요한 특징입니다.

2. 오래된 운영체제와 장비가 남아 있을 수 있다

일반 회사에서 사용하는 PC는 일정 기간이 지나면 새로운 장비로 교체하는 경우가 많습니다.

생산설비는 이야기가 다릅니다.

한 번 설치한 장비를 오랫동안 사용하는 경우가 있고, 설비를 제어하는 산업용 PC도 장기간 함께 운영될 수 있습니다.

여기서 문제가 생길 수 있습니다.

운영체제를 업데이트했더니 기존 제어 프로그램이 작동하지 않거나, 오래된 장비라 최신 보안기능을 적용하기 어려울 수 있기 때문입니다.

그래서 스마트공장 보안을 시작할 때는 새로운 솔루션을 알아보기 전에 먼저 다음 질문에 답해보는 것이 좋습니다.

우리 공장에는 어떤 장비가 있는가?

각 장비는 어떤 운영체제를 사용하는가?

어떤 장비가 네트워크에 연결되어 있는가?

인터넷이나 외부 네트워크에서 접근할 수 있는 장비는 무엇인가?

결국 OT 보안의 첫 번째 단계는 새로운 보안 프로그램을 설치하는 것이 아니라 현재 보유한 자산을 정확히 파악하는 것이라고 볼 수 있습니다.

3. IT에서 발생한 사고가 생산라인으로 번질 수 있다

한 직원의 업무용 PC에서 보안 문제가 발생했다고 가정해보겠습니다.

생산망과 업무망이 완전히 독립되어 있다면 영향 범위가 제한될 수 있습니다.

하지만 스마트공장에서는 ERP, MES, 생산관리 서버, 데이터 수집 시스템, 산업용 PC 등이 서로 연결되어 있는 경우가 있습니다.

IT망과 생산망 사이의 통신이 적절하게 관리되지 않는다면 일반 업무 영역에서 시작된 문제가 다른 시스템으로 이동할 가능성도 생각해야 합니다.

그래서 중요한 것이 네트워크 구조와 접근권한을 파악하는 것입니다.

모든 시스템이 서로 자유롭게 통신하도록 두기보다는 실제 업무에 필요한 구간과 그렇지 않은 구간을 구분하는 것이 좋습니다.

쉽게 기억할 수 있는 원칙이 있습니다.

연결할 수 있다고 해서 모두 연결할 필요는 없습니다.

스마트공장이 데이터를 연결하고 자동화하는 과정에서 반드시 함께 생각해야 할 보안 원칙입니다.

4. 외부 유지보수 업체도 중요한 보안 대상이다

스마트공장의 또 다른 특징은 외부업체와의 연결이 많다는 것입니다.

설비 제조사나 자동화 업체가 직접 방문해 장비를 확인하기도 하지만, VPN이나 원격지원 프로그램을 이용해 외부에서 접속하는 경우도 있습니다.

이때 공장 내부 직원의 계정만 관리해서는 충분하지 않습니다.

외부 유지보수 업체가 사용하는 계정도 함께 확인해야 합니다.

특히 다음 항목은 한번 점검해보는 것이 좋습니다.

• 업체별 계정이 구분되어 있는가?
• 여러 사람이 하나의 계정을 공유하지 않는가?
• 접근할 수 있는 생산설비가 제한되어 있는가?
• 접속 가능한 시간이 관리되는가?
• 누가 언제 접속했는지 기록되는가?
• 작업이 끝나면 연결이 종료되는가?
• 계약 종료 후 계정이 삭제되는가?

외부업체와 오랫동안 거래했다고 해서 보안관리를 생략할 필요는 없습니다.

오히려 누가, 언제, 어느 장비에 접근했는지를 명확하게 관리하는 것이 공장과 협력업체 모두를 보호하는 방법이 될 수 있습니다.

5. 보안을 강화하다 생산을 멈추는 것도 문제가 될 수 있다

OT 보안이 어려운 이유 중 하나입니다.

보안을 강화하기 위해 새로운 프로그램이나 정책을 적용했는데 생산설비가 제대로 작동하지 않는다면 현장에서는 해당 보안조치를 유지하기 어렵습니다.

예를 들어 보안 프로그램을 설치한 이후 산업용 프로그램의 속도가 느려지거나 필요한 네트워크 통신이 차단된다면 생산에 직접적인 영향을 줄 수 있습니다.

그래서 OT 보안에서는 보안담당자만의 판단으로 모든 것을 결정하기보다 생산·설비·IT 담당자가 함께 확인하는 과정이 중요합니다.

새로운 보안정책이나 프로그램을 적용하기 전에는 다음과 같은 부분을 살펴보는 것이 좋습니다.

• 생산공정에 영향을 주지 않는가?
• 기존 산업용 프로그램과 충돌하지 않는가?
• 필요한 네트워크 통신을 방해하지 않는가?
• 문제가 발생했을 때 원래 상태로 복구할 수 있는가?
• 실제 적용 전 시험할 방법이 있는가?
• 설비 제조사의 권고사항은 무엇인가?

좋은 OT 보안은 생산을 방해하는 것이 목적이 아닙니다.

생산을 안전하게 계속할 수 있도록 만드는 것이 목적입니다.

OT 환경에서는 보안뿐 아니라 안전성, 신뢰성, 운영 연속성을 함께 생각해야 합니다.

CISA에서도 OT 보안을 단순한 기술 문제로만 보지 않고 조직의 의사결정과 사업 연속성까지 함께 고려하도록 권고하고 있습니다.

CISA OT 사이버보안 원칙 공식 자료 보기

중소 제조기업은 OT 보안을 어디서부터 시작해야 할까?

처음부터 복잡한 OT 보안 시스템을 구축하려고 하면 무엇부터 해야 할지 막막해질 수 있습니다.

이럴 때는 솔루션 구매보다 현재 상태 파악을 먼저 해보는 것이 현실적입니다.

1단계. 생산망에 연결된 장비 목록 만들기

PLC, 산업용 PC, 서버, 네트워크 장비 등 현재 생산망에 어떤 장비가 연결되어 있는지 정리합니다.

가능하다면 다음 정보까지 함께 기록해두면 좋습니다.

• 장비명
• 제조사
• 모델명
• IP 주소
• 운영체제
• 사용 목적
• 담당자
• 외부접속 여부

처음부터 전문적인 자산관리 시스템을 사용할 필요는 없습니다.

엑셀이나 스프레드시트 한 장으로 시작해도 충분합니다.

중요한 것은 우리가 무엇을 보호해야 하는지 알고 있는 상태를 만드는 것입니다.

2단계. 외부에서 들어올 수 있는 경로 확인하기

다음으로 공장 밖에서 내부 시스템으로 접속할 수 있는 방법을 확인합니다.

예를 들면 다음과 같습니다.

• VPN
• 원격데스크톱
• 원격지원 프로그램
• 설비업체 유지보수 프로그램
• 클라우드 관리 서비스
• 별도의 외부 접속 게이트웨이

예전에 설치했지만 지금은 사용하지 않는 프로그램이 그대로 남아 있지 않은지도 확인합니다.

사용하지 않는 외부접속 경로는 불필요한 위험이 될 수 있기 때문입니다.

3단계. IT망과 생산망의 연결 구조 확인하기

ERP, MES, 생산서버, 산업용 PC, PLC 등이 어떻게 연결되어 있는지 간단한 그림으로 그려보는 것도 좋은 방법입니다.

전문적인 네트워크 도면일 필요는 없습니다.

예를 들어,

사무실 PC → ERP → MES → 생산서버 → 산업용 PC → PLC

정도만 표시해도 데이터가 어디에서 어디로 이동하는지 파악할 수 있습니다.

연결 구조가 보이면 어떤 부분을 우선적으로 관리해야 하는지도 훨씬 명확해집니다.

4단계. 계정과 관리자 권한 확인하기

다음으로 사용자를 확인합니다.

• 퇴사자 계정
• 외부업체 공용계정
• 장기간 사용하지 않은 계정
• 관리자 권한 계정
• 오래된 원격접속 계정

같은 것들이 그대로 남아 있지 않은지 확인합니다.

특히 여러 사람이 같은 관리자 계정을 사용하는 구조라면 실제 사용자를 파악하기 어려울 수 있습니다.

가능하면 사람별 계정을 사용하고 필요한 권한만 부여하는 것이 좋습니다.

5단계. 백업과 복구 가능 여부 확인하기

마지막으로 꼭 던져봐야 할 질문이 있습니다.

오늘 생산설비 PC가 작동하지 않는다면 언제까지 복구할 수 있을까?

백업 파일이 있다는 사실만으로 충분하지 않을 수 있습니다.

실제로 필요한 프로그램과 설정값을 복원할 수 있는지도 중요합니다.

주요 시스템이라면 다음을 확인해두는 것이 좋습니다.

• 무엇을 백업하는가?
• 어디에 백업하는가?
• 얼마나 자주 백업하는가?
• 누가 관리하는가?
• 실제 복원 방법을 알고 있는가?
• 복구 테스트를 해본 적이 있는가?

사고를 완벽하게 막는 것만큼 사고 이후 정상적인 생산으로 돌아갈 수 있는 능력도 중요합니다.

스마트공장 OT 보안 체크리스트

현재 우리 공장의 상태가 궁금하다면 다음 항목부터 확인해볼 수 있습니다.

• 생산망에 연결된 장비 목록이 있는가?
• 각 장비의 IP와 담당자를 알고 있는가?
• 외부에서 접속 가능한 장비를 파악하고 있는가?
• 사용하지 않는 원격접속 프로그램이 없는가?
• IT망과 생산망의 연결 구조를 알고 있는가?
• 외부업체 계정을 별도로 관리하고 있는가?
• 관리자 권한을 최소화하고 있는가?
• 오래된 운영체제를 사용하는 장비를 파악하고 있는가?
• 주요 생산시스템을 백업하고 있는가?
• 실제 복구가 가능한지 확인한 적이 있는가?

여기서 중요한 것은 모든 항목을 당장 완벽하게 해결하는 것이 아닙니다.

답을 모르는 항목이 발견됐다면 그 항목을 파악하는 것부터 시작하면 됩니다.

오히려 어떤 장비가 있는지도 모르는 상태에서 고가의 보안솔루션부터 도입하면 제대로 활용하기 어려울 수 있습니다.

IT팀과 생산팀이 함께 움직여야 하는 이유

스마트공장 보안을 IT팀만의 업무라고 생각하기는 어렵습니다.

IT 담당자는 네트워크와 서버에 익숙하지만 특정 생산설비를 중단했을 때 어떤 문제가 발생하는지는 생산이나 설비 담당자가 더 정확히 알 수 있습니다.

반대로 생산 담당자는 설비를 잘 알고 있지만 네트워크 구조나 계정관리에는 IT 담당자의 도움이 필요할 수 있습니다.

그래서 중요한 변경을 할 때는 최소한 세 가지 관점에서 확인하는 것이 좋습니다.

IT 담당자: 보안상 안전한가?

설비 담당자: 장비가 정상적으로 작동하는가?

생산 담당자: 생산일정과 품질에 영향을 주지 않는가?

이 세 가지 질문을 함께 검토하는 것이 스마트공장 OT 보안을 안정적으로 운영하는 데 도움이 됩니다.

IT 보안과 OT 보안 차이를 이해하면 무엇부터 해야 할지가 보인다

IT 보안과 OT 보안은 완전히 별개의 분야는 아닙니다.

계정관리, 접근제어, 로그, 네트워크 보호, 백업처럼 기본적인 보안 원칙은 서로 연결되어 있습니다.

다만 보호하는 대상과 운영환경이 다르기 때문에 적용방법에 차이가 생깁니다.

일반 IT 환경에서는 정보와 데이터 보호가 핵심이라면 스마트공장에서는 여기에 생산설비의 안정성과 가용성이라는 조건이 추가됩니다.

그래서 스마트공장 보안을 시작할 때 가장 먼저 해야 할 일이 최신 보안솔루션을 검색하는 것은 아닐 수 있습니다.

먼저 공장을 살펴보면서 다음 네 가지 질문에 답해보는 것을 권합니다.

우리 공장에는 어떤 장비가 연결되어 있는가?

외부에서 들어올 수 있는 경로는 어디인가?

IT망과 생산망은 어떻게 연결되어 있는가?

문제가 발생했을 때 생산을 복구할 수 있는가?

이 네 가지에 답할 수 있다면 우리 회사에 필요한 OT 보안의 우선순위도 훨씬 명확해질 수 있습니다.

자주 묻는 질문

IT 보안과 OT 보안의 가장 큰 차이는 무엇인가요?

보호 대상과 운영 목적에서 차이가 있습니다. IT 보안은 PC, 서버, 데이터 등 정보자산 보호가 중요한 반면 OT 보안은 PLC, 산업용 PC, 생산설비 등 실제 공정을 운영하는 시스템의 안정적인 가동까지 함께 고려해야 합니다.

스마트공장이라면 반드시 OT 보안이 필요한가요?

생산설비가 네트워크에 연결되어 있거나 ERP, MES, 원격유지보수 시스템 등 다른 시스템과 데이터를 주고받고 있다면 OT 영역의 보안을 함께 점검하는 것이 좋습니다.

일반 백신을 산업용 PC에 설치하면 되나요?

산업용 PC의 운영환경과 연결된 설비에 따라 다릅니다. 보안 프로그램이나 운영체제 업데이트가 제어 프로그램에 영향을 줄 가능성이 있으므로 장비 제조사의 권고사항과 운영환경을 확인한 후 적용하는 것이 좋습니다.

OT 보안을 처음 시작할 때 가장 먼저 해야 할 일은 무엇인가요?

생산망에 연결된 장비 목록을 만드는 것부터 시작할 수 있습니다. 어떤 장비가 존재하고 어디에 연결되어 있는지를 알아야 외부접속 관리, 네트워크 구분, 계정관리 등 다음 단계의 우선순위를 정하기 쉽습니다.

중소기업도 비싼 OT 보안솔루션이 필요한가요?

처음부터 모든 보안솔루션을 구축할 필요는 없습니다. 장비 목록 작성, 외부접속 경로 확인, 미사용 계정 제거, 관리자 권한 최소화, 백업 및 복구 확인처럼 비교적 적은 비용으로 시작할 수 있는 관리항목부터 점검하는 것이 현실적입니다.

하지만 VPN을 설치했다고 해서 스마트공장 원격접속 보안이 완성되는 것은 아닙니다.

실제 위험은 VPN 자체보다 누가 접속하는지, 어느 설비까지 접근할 수 있는지, 작업 내용이 기록되는지, 사용하지 않는 계정이 그대로 남아 있는지에서 발생할 수 있습니다.

특히 스마트공장은 일반 사무실과 달리 생산설비와 산업용 PC, 서버, PLC 등 다양한 장비가 연결되어 있어 작은 보안 문제가 생산중단으로 이어질 가능성도 있습니다.

이번 글에서는 스마트공장이나 스마트팩토리를 운영하면서 원격 유지보수를 허용할 때 반드시 확인해야 할 보안 항목을 쉽게 정리해보겠습니다.

스마트공장 원격접속 보안이 중요한 이유

스마트공장이 확대되면서 설비업체가 현장을 방문하지 않고 원격으로 장비를 점검하는 경우가 많아졌습니다.

원격 유지보수는 상당히 편리합니다.

설비에 오류가 발생했을 때 외부 엔지니어가 바로 접속해 상태를 확인할 수 있고, 프로그램 수정이나 설정 변경도 빠르게 진행할 수 있기 때문입니다.

반대로 생각하면 공장 밖에서도 내부 시스템에 접근할 수 있는 통로가 생겼다는 의미이기도 합니다.

예를 들어 다음과 같은 상황을 생각해볼 수 있습니다.

설비업체에 VPN 계정을 하나 만들어줬고 여러 엔지니어가 같은 계정을 사용한다. 담당자가 퇴사했지만 비밀번호를 변경하지 않았다. 몇 달 후 해당 계정으로 공장 내부망에 접속이 발생했다.

VPN 입장에서는 정상 아이디와 비밀번호가 입력됐기 때문에 정상 접속으로 판단할 수 있습니다.

결국 스마트공장 원격접속 보안은 단순히 통신을 암호화하는 것에서 끝나는 것이 아니라 계정과 권한, 접속기록까지 함께 관리하는 것이 핵심입니다.

VPN만으로 스마트공장 보안이 충분하지 않은 이유

VPN은 외부 사용자와 내부 네트워크 사이의 통신을 보호하는 데 중요한 역할을 합니다.

하지만 다음 문제까지 자동으로 해결해주지는 않습니다.

• 접속자가 실제 허가받은 사람인지
• 접속 후 어떤 설비에 접근하는지
• 관리자 권한을 사용하는지
• 어떤 작업을 수행했는지
• 사용이 끝난 계정인지
• 접속 PC가 안전한 상태인지

따라서 VPN은 원격접속 보안의 출발점이라고 보는 편이 적절합니다.

이제 실제로 점검해야 할 항목을 하나씩 살펴보겠습니다.

1. VPN 공용 계정을 사용하지 않는 것이 좋다

외부 유지보수 업체에 계정을 제공할 때 편의를 위해 하나의 공용 VPN 계정을 발급하는 경우가 있습니다.

예를 들어 service01이라는 아이디를 협력업체 직원 여러 명이 함께 사용하는 방식입니다.

관리자는 계정 하나만 관리하면 되기 때문에 편리하지만 문제가 발생하면 실제 접속자를 확인하기 어렵습니다.

가능하면 원격접속 계정을 사용자별로 구분하는 것이 좋습니다.

예를 들면 다음과 같습니다.

• 엔지니어별 개별 계정 발급
• 담당 업무별 권한 구분
• 프로젝트 종료 후 계정 비활성화
• 장기간 미사용 계정 잠금
• 퇴사자 계정 즉시 삭제

특히 외부업체 직원이 자주 변경되는 환경이라면 계정 관리가 더욱 중요합니다.

누가 접속했는지 확인할 수 없는 계정은 만들지 않는 것이 가장 기본적인 원칙입니다.

2. VPN 접속 후 내부망 전체에 접근하게 하면 위험하다

VPN에 연결됐다고 해서 공장 내부의 모든 장비에 접근할 필요는 없습니다.

특정 생산설비를 유지보수하는 업체라면 해당 설비와 관련된 시스템만 접근할 수 있도록 제한하는 것이 좋습니다.

예를 들어 다음과 같은 구조입니다.

외부 사용자 → VPN → 원격접속 서버 → 허용된 생산설비

반대로 VPN에 연결되는 순간 생산서버, 파일서버, 다른 설비까지 모두 접근할 수 있다면 하나의 계정이 탈취됐을 때 피해 범위도 커집니다.

원격접속 보안에서는 최소 권한 원칙이 중요합니다.

필요한 사용자에게 필요한 장비만, 필요한 시간 동안 접근하도록 제한하는 방식입니다.

관리자 권한 역시 업무상 반드시 필요한 경우에만 부여하는 것이 좋습니다.

3. 원격접속 기록을 반드시 남겨야 한다

스마트공장 원격접속 보안에서 의외로 중요한 것이 접속 로그입니다.

정상적으로 운영되고 있을 때는 로그의 중요성을 크게 느끼지 못할 수 있습니다.

하지만 보안사고나 설비 이상이 발생하면 상황이 달라집니다.

누가 언제 접속했는지 확인할 수 없다면 사고 원인을 찾기 어려워지기 때문입니다.

최소한 다음 정보는 확인할 수 있는 것이 좋습니다.

특히 평소 작업이 없는 새벽이나 휴일에 접속이 발생한다면 별도로 확인할 필요가 있습니다.

접속기록은 단순히 저장하는 것보다 필요할 때 바로 확인할 수 있는 상태로 관리하는 것이 중요합니다.

4. 퇴사자와 외부업체 계정을 정기적으로 정리해야 한다

원격접속 보안에서 자주 놓치는 것이 사용하지 않는 계정입니다.

설비 설치 프로젝트가 끝났는데 협력업체 계정이 그대로 남아 있거나 담당자가 퇴사했지만 기존 VPN 계정이 유지되는 경우가 있습니다.

이런 계정은 시간이 지나면 관리자도 존재 자체를 잊어버리기 쉽습니다.

따라서 3개월이나 6개월처럼 일정한 주기를 정해 계정을 점검하는 것이 좋습니다.

점검할 때 다음 질문을 확인해볼 수 있습니다.

• 현재 실제 사용자가 존재하는 계정인가?
• 지금도 원격접속이 필요한가?
• 마지막 접속일은 언제인가?
• 해당 업체와 계약이 유지되고 있는가?
• 관리자 권한이 필요한가?
• 담당 설비가 변경되지 않았는가?

필요하지 않은 계정은 삭제하거나 비활성화하는 것이 안전합니다.

새 계정을 만드는 절차뿐 아니라 계정을 없애는 절차도 미리 정해두는 것이 중요합니다.

5. 원격접속에 사용하는 PC도 확인해야 한다

VPN 계정이 안전해도 외부에서 접속하는 PC가 악성코드에 감염되어 있다면 새로운 문제가 발생할 수 있습니다.

예를 들어 외부 유지보수 업체 직원이 개인용 노트북으로 여러 회사의 설비에 접속한다면 보안 위험이 커질 수 있습니다.

중요한 생산설비에 접속해야 한다면 가능하면 업무용 원격접속 장비를 별도로 지정하는 것이 좋습니다.

최소한 다음 항목을 확인할 수 있습니다.

• 운영체제가 최신 상태인지
• 백신이나 보안 프로그램이 동작하는지
• 화면 잠금이 설정되어 있는지
• 브라우저에 비밀번호가 저장되어 있지 않은지
• 불필요한 프로그램이 설치되어 있지 않은지
• 관리자 계정을 무분별하게 사용하지 않는지

스마트공장 보안에서는 공장 내부 장비뿐 아니라 공장에 접속하는 외부 장비까지 하나의 보안 영역으로 보는 관점이 필요합니다.

스마트공장 원격접속 보안 체크리스트 10가지

복잡한 보안솔루션을 바로 도입하기 어렵다면 아래 항목부터 점검해보는 것이 좋습니다.

• VPN 계정을 사용자별로 발급하고 있는가?
• 여러 사람이 사용하는 공용 계정을 최소화했는가?
• 퇴사자와 계약 종료 업체 계정을 삭제하는가?
• 원격접속 가능한 장비를 제한했는가?
• 관리자 권한을 필요한 사람에게만 부여했는가?
• 원격접속 시간과 사용자를 기록하고 있는가?
• 로그인 실패 기록을 확인할 수 있는가?
• 비정상 시간대 접속을 확인할 수 있는가?
• 원격작업이 끝난 후 세션이 종료되는가?
• 원격접속용 PC의 보안 상태를 관리하는가?

10개 항목 가운데 여러 항목에 답하기 어렵다면 새로운 보안장비를 구매하기 전에 현재 원격접속 구조부터 확인해보는 것이 좋습니다.

보안 예산이 부족한 중소기업은 무엇부터 해야 할까?

스마트공장을 운영한다고 해서 모든 기업이 처음부터 고가의 보안솔루션을 구축할 수 있는 것은 아닙니다.

예산이 제한되어 있다면 우선순위를 정하는 방법이 현실적입니다.

1단계. 현재 원격접속 계정 확인

VPN과 원격 프로그램에 등록된 계정이 몇 개인지 먼저 확인합니다.

사용자를 알 수 없는 계정이나 오랫동안 사용하지 않은 계정이 있다면 정리합니다.

2단계. 접근권한 최소화

모든 설비에 접근할 수 있는 계정을 줄이고 담당 업무에 필요한 장비만 접근하도록 제한합니다.

3단계. 접속기록 확보

누가 언제 어떤 시스템에 접속했는지를 확인할 수 있도록 로그를 남깁니다.

4단계. 외부업체 계정 관리

계약이나 유지보수 기간이 끝나면 해당 계정을 즉시 비활성화할 수 있도록 담당자를 정합니다.

5단계. 추가 보안수단 적용

기본 관리체계가 만들어졌다면 MFA, 접근제어, 세션 모니터링, 이상행위 탐지 등의 기능을 단계적으로 검토할 수 있습니다.

중요한 것은 비싼 보안제품부터 구입하는 것이 아니라 현재 누가 어떤 권한을 가지고 있는지 파악하는 것입니다.

스마트공장 원격접속 보안에서 가장 먼저 확인할 것

원격접속 보안을 어렵게 생각할 필요는 없습니다.

먼저 다음 네 가지 질문에 답해보면 현재 상태를 어느 정도 파악할 수 있습니다.

누가 접속할 수 있는가?

접속하면 어디까지 들어갈 수 있는가?

접속 후 무엇을 했는지 확인할 수 있는가?

더 이상 필요하지 않은 권한은 삭제되는가?

이 네 가지 질문에 명확하게 답할 수 없다면 원격접속 체계를 한번 점검해볼 필요가 있습니다.

VPN은 스마트공장 원격접속 보안에서 매우 중요한 수단이지만 VPN 하나만 설치했다고 모든 위험이 해결되는 것은 아닙니다.

계정 관리, 최소 권한, 접속기록, 외부업체 관리, 접속장비 관리까지 함께 이루어져야 보다 안전한 원격 유지보수 환경을 만들 수 있습니다.

자주 묻는 질문

스마트공장 원격접속에 VPN은 꼭 필요한가요?

공장 내부 시스템을 외부에서 직접 노출하는 것보다 VPN과 같은 보호된 접속방식을 사용하는 것이 좋습니다. 다만 VPN을 사용하는 것과 계정·권한·접속기록을 관리하는 것은 별개의 문제이므로 함께 관리해야 합니다.

VPN을 설치하면 해킹을 완전히 막을 수 있나요?

VPN은 통신 구간 보호에 도움이 되지만 탈취된 계정이나 과도한 접근권한까지 자동으로 해결해주지는 않습니다. 사용자별 계정, 다중인증, 최소 권한, 로그 관리 등을 함께 적용하는 것이 좋습니다.

외부 유지보수 업체에 공용 계정을 줘도 되나요?

가능하면 사용자별 계정을 발급하는 것이 좋습니다. 여러 사람이 하나의 계정을 이용하면 사고 발생 시 실제 작업자를 확인하기 어려울 수 있습니다.

스마트공장 보안을 위해 가장 먼저 해야 할 일은 무엇인가요?

현재 외부에서 접속할 수 있는 계정 목록부터 확인하는 것을 권장합니다. 계정 사용자, 접근 가능 설비, 권한 수준, 최근 접속일을 정리하면 우선적으로 개선해야 할 부분을 찾기 쉽습니다.

소규모 제조기업도 원격접속 보안이 필요한가요?

기업 규모와 관계없이 외부에서 생산설비나 내부 시스템에 접근할 수 있다면 기본적인 원격접속 관리가 필요합니다. 특히 공용계정 제거, 권한 제한, 접속기록 관리 등은 큰 비용 없이도 점검할 수 있습니다.

한국인터넷진흥원(KISA) 스마트공장 사이버보안 가이드
스마트공장의 보안위협과 대응 방향을 좀 더 자세히 확인하려면 한국인터넷진흥원의 스마트공장 사이버보안 가이드를 참고할 수 있습니다.
KISA 스마트공장 사이버보안 가이드 바로가기

미국 CISA 원격접속 보안 가이드
VPN이나 원격접속 프로그램을 운영하는 기업이라면 CISA의 원격접속 보안 가이드도 참고할 만합니다. 원격접속 도구 악용 위험과 보안 권고사항을 확인할 수 있습니다.
CISA 원격접속 보안 가이드 바로가기