제로 트러스트, 사내망을 믿지 않는 보안 설계의 실제

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

재택근무자가 사내 시스템에 접속하고, 협력사가 프로젝트 자료를 열며, 직원은 개인 스마트폰으로 업무 메일을 확인합니다. 그런데도 방화벽 안쪽에 있다는 이유만으로 사용자를 신뢰한다면 계정 하나가 탈취됐을 때 공격자가 움직일 수 있는 범위가 지나치게 넓어집니다.

G2프로는 기업 보안 컨설팅을 맡아 온 제로 트러스트 아키텍트 문현석 씨를 만나 도입 순서와 비용, 기존 VPN과의 차이, 실제 운영에서 놓치기 쉬운 지점을 물었습니다. 제품 이름보다 접근 권한을 어떻게 설계하고 검증할 것인가에 초점을 맞춘 인터뷰입니다.

Q. 제로 트러스트는 사내 사용자를 의심하는 정책인가요?

A. 사람을 불신하는 것이 아니라 접속 상황을 매번 검증하는 방식입니다

“제로 트러스트를 직원 감시 정책으로 오해하는 경우가 많습니다. 핵심은 사용자의 선의를 의심하는 것이 아니라 로그인 계정, 단말기 상태, 접속 위치, 요청한 자원과 행동 위험도를 함께 확인하는 것입니다. 어제 정상적으로 로그인한 직원이라도 오늘 관리되지 않는 노트북에서 중요한 고객 데이터에 접근한다면 추가 인증이나 접속 차단이 필요합니다.”

기존 경계형 보안은 사무실 네트워크와 외부 인터넷 사이에 높은 성벽을 세우는 방식에 가깝습니다. 반면 제로 트러스트 보안은 사용자가 이미 내부에 들어왔더라도 필요한 자원만 제한적으로 열어 줍니다. IT라는 용어가 포괄하는 정보의 수집·처리·전달 범위는 IT 관련 지식백과 설명에서도 확인할 수 있는데, 업무 데이터가 여러 기기와 서비스에 분산된 환경에서는 네트워크 위치만으로 신뢰를 판단하기 어렵습니다.

“예를 들어 인사 담당자가 급여 시스템에는 접속해야 하지만 개발 서버와 소스 저장소까지 볼 이유는 없습니다. 같은 직원이라는 이유로 모든 내부 시스템을 허용하는 대신 역할과 업무 목적에 따라 통로를 잘게 나누는 것이 출발점입니다. 독자 여러분의 회사에서는 퇴사자 계정이나 장기간 사용하지 않은 협력사 권한이 당일에 회수되고 있습니까?”

• 사용자 확인: 계정, 다중 인증, 직무와 고용 상태를 검증합니다.
• 기기 확인: 운영체제 업데이트, 백신 동작, 디스크 암호화 여부를 확인합니다.
• 자원 제한: 업무 수행에 필요한 애플리케이션과 데이터만 허용합니다.
• 지속적인 판단: 로그인 순간뿐 아니라 세션 중의 위험한 행동도 관찰합니다.

“제로 트러스트의 ‘신뢰하지 않는다’는 표현은 사람을 향한 평가가 아닙니다. 확인되지 않은 접속 요청을 자동으로 승인하지 않는다는 기술 원칙입니다.”

Q. VPN을 사용하고 있는데도 별도의 전환이 필요한가요?

A. VPN은 연결 수단이고 제로 트러스트는 권한을 결정하는 원칙입니다

“VPN을 없애야 제로 트러스트가 완성된다는 주장은 지나치게 단순합니다. VPN은 외부 단말과 회사 네트워크 사이에 암호화된 통로를 만드는 유용한 기술입니다. 문제는 접속 후 넓은 내부망을 한 번에 열어 주거나, 아이디와 비밀번호만 맞으면 단말 상태와 관계없이 연결을 허용하는 운영 방식입니다.”

전문가는 기존 VPN을 즉시 폐기하기보다 접속 대상을 분류하라고 조언합니다. 오래된 클라이언트·서버 프로그램이나 장비 관리 포트는 당분간 VPN이 필요할 수 있습니다. 반면 웹 기반 그룹웨어, 업무 포털, 고객관리 시스템은 애플리케이션 단위 접근 방식인 ZTNA로 분리하기 쉽습니다. 이때 사용자는 전체 사내망이 아니라 승인받은 서비스의 주소와 포트에만 연결됩니다.

포스트 코로나 환경은 원격근무만 남긴 것이 아니라 클라우드 협업, 외부 인력 참여, 분산된 업무 장소를 일상으로 만들었습니다. 이러한 변화의 사회적 맥락은 포스트 코로나 지식백과 항목에서도 살펴볼 수 있습니다. 사무실과 외부를 단순하게 나누는 보안 모델이 실제 업무 흐름을 충분히 설명하지 못하는 이유입니다.

• 웹 애플리케이션은 ZTNA 전환 후보로 먼저 분류합니다.
• 서버 운영자의 SSH·RDP 접근은 별도의 관리자 정책으로 묶습니다.
• 구형 ERP와 생산설비는 VPN을 유지하되 접근 출발지와 시간을 제한합니다.
• 비상 상황을 위한 우회 접속은 승인 절차와 사용 기록을 함께 남깁니다.

Q. 중소기업은 무엇부터 바꿔야 실패하지 않습니까?

A. 자산 목록보다 실제 접속 경로를 먼저 그려 보십시오

“수백 개의 보안 항목을 조사하느라 몇 달을 보내기보다 중요한 업무 하나를 골라 사용자가 어디에서 어떤 인증을 거쳐 데이터에 도달하는지 그려 보는 편이 낫습니다. 예를 들어 영업 담당자가 외부 노트북에서 고객관리 시스템의 견적서를 내려받는 흐름을 선택할 수 있습니다. 계정 발급자, 인증 방식, 단말 관리 여부, 다운로드 권한과 로그 저장 위치를 한 장에 표시하면 빈틈이 보입니다.”

첫 적용 대상으로는 사용자와 담당 부서가 명확하고, 중단됐을 때 수동 대응이 가능하며, 웹 브라우저로 접근하는 서비스를 권합니다. 전사 ERP나 공장 생산망처럼 장애 영향이 큰 시스템부터 시작하면 기술 검증보다 내부 반발이 앞설 수 있습니다. 반대로 중요도가 너무 낮은 게시판만 시험하면 보안 효과와 투자 가치를 판단하기 어렵습니다.

“파일 서버에 부서별 폴더 권한이 이미 정돈돼 있다면 좋은 출발점입니다. 그러나 ‘전 직원’ 그룹이 대부분의 폴더를 읽을 수 있다면 인증 제품을 추가하기 전에 권한부터 정리해야 합니다. 제품이 잘못된 권한 구조를 자동으로 올바르게 바꿔 주지는 않습니다.”

90일 시범 적용은 네 단계로 나눕니다

1. 1~2주차, 경로 확인: 대상 업무와 사용자 20~50명을 선정하고 현재 로그인부터 데이터 사용까지 기록합니다.
2. 3~4주차, 기준 수립: 회사 소유 기기, 최신 보안 패치, 다중 인증을 정상 접속의 최소 조건으로 정합니다.
3. 5~8주차, 관찰 모드: 정책 위반을 바로 차단하지 않고 알림만 생성해 업무에 필요한 예외를 찾습니다.
4. 9~12주차, 단계적 차단: 고위험 접속부터 막고 사용자 문의, 오탐, 인증 소요 시간을 측정합니다.

• 성공 지표에는 차단 건수뿐 아니라 로그인 실패율과 헬프데스크 문의량을 포함합니다.
• 협력사와 임시직 계정은 계약 종료일을 필수 속성으로 설정합니다.
• 예외 권한에는 승인자, 사유, 만료일을 함께 기록합니다.
• 파일 다운로드와 화면 열람을 구분할 수 있는지도 검토합니다.

“처음부터 완벽한 정책을 만들겠다는 목표보다 위험한 접속을 하나씩 줄인다는 목표가 현실적입니다. 관찰 모드 없이 차단부터 켜면 현업은 보안을 업무 방해 도구로 기억합니다.”

Q. 제품을 고를 때 어떤 기능과 비용을 확인해야 하나요?

A. 사용자 수보다 연동 범위와 운영 인력이 총비용을 좌우합니다

“제로 트러스트라는 이름이 붙은 단일 장비를 사는 것으로 끝나지 않습니다. 일반적으로 통합 인증, 다중 인증, 기기 관리, 애플리케이션 접근 제어, 로그 분석이 맞물립니다. 이미 Microsoft 365나 Google Workspace 같은 업무 플랫폼을 사용하고 있다면 보유 라이선스에 포함된 조건부 접근 기능부터 확인해야 중복 구매를 피할 수 있습니다.”

비용은 사용자당 월 구독료만 비교하면 왜곡됩니다. 초기 설계와 디렉터리 정비, 구형 시스템 연동, 에이전트 배포, 사용자 교육, 24시간 장애 대응까지 포함한 총소유비용을 계산해야 합니다. 국내 중소기업의 시범 사업은 대상 인원과 연동 난이도에 따라 수백만 원대 컨설팅으로 시작할 수 있지만, 여러 법인과 수백 개 애플리케이션을 연결하면 구축비가 수천만 원 이상으로 커질 수 있습니다. 이는 확정 가격이 아니라 예산 범위를 잡기 위한 참고 수준이며 실제 금액은 반드시 견적과 기능 명세로 확인해야 합니다.

견적서에서는 ‘사용자’의 정의도 살펴야 합니다. 휴면 계정과 외부 협력자를 모두 과금하는지, 관리 기기 수가 늘면 추가 비용이 발생하는지, 로그 보관 기간을 늘릴 때 저장 비용이 붙는지에 따라 1년 뒤 청구액이 달라집니다. 장애 때 국내 기술 지원을 받을 수 있는 시간과 긴급 연락 방식도 계약서에 명시하는 편이 좋습니다.

데모에서는 관리 화면보다 예외 상황을 시험합니다

• 인증 연동: 현재 사용하는 AD, LDAP, 클라우드 계정과 양방향 동기화가 가능한지 확인합니다.
• 기기 판별: 회사 기기와 개인 기기, 탈옥·루팅 단말, 패치 지연 단말을 구분하는지 시험합니다.
• 정책 세분화: 부서, 직무, 시간, 국가, 위험도와 애플리케이션을 조합할 수 있는지 봅니다.
• 로그 활용: 허용과 차단의 이유가 사람이 이해할 수 있는 형태로 남는지 확인합니다.
• 가용성: 인증 서비스나 인터넷 회선 장애 때 업무가 어떻게 유지되는지 묻습니다.
• 철수 가능성: 계약 종료 시 정책과 로그를 표준 형식으로 내보낼 수 있는지 확인합니다.

특히 모바일 업무가 많다면 운영체제와 기기 형태가 빠르게 바뀐다는 점을 고려해야 합니다. 폴더블 기기처럼 하드웨어 형태가 다양해지는 흐름은 모바일 기기 관련 기술 뉴스에서도 확인할 수 있습니다. 특정 제조사나 화면 형태를 무조건 차단하기보다 운영체제 지원 기간, 보안 패치, 업무 데이터 분리 기능을 정책 기준으로 삼는 편이 지속 가능합니다.

Q. 강한 인증을 적용하면 직원 불편이 커지지 않을까요?

A. 위험도가 낮을 때는 조용히 통과시키는 설계가 중요합니다

“모든 로그인에서 문자 인증번호를 요구하면 사용자는 곧 피로를 느낍니다. 공격자는 이 피로를 이용해 반복 승인 요청을 보내기도 합니다. 회사가 지급한 정상 노트북에서 평소와 같은 지역, 같은 시간대에 일반 문서를 여는 상황이라면 별도 질문 없이 허용하고, 새로운 기기에서 급여 자료를 대량 내려받을 때만 추가 인증을 요구하는 방식이 효과적입니다.”

인증 수단은 피싱 저항성도 비교해야 합니다. SMS와 일회용 코드는 도입하기 쉽지만 사용자가 가짜 로그인 페이지에 입력할 수 있습니다. 패스키나 FIDO2 보안키는 등록된 서비스 도메인과 기기를 기반으로 인증해 피싱 위험을 낮출 수 있습니다. 다만 공용 PC, 분실 기기, 대체 인증이 필요한 현장직을 고려한 복구 절차가 반드시 필요합니다.

사용자 경험을 개선하려면 차단 화면도 설계 대상에 포함해야 합니다. 단순히 ‘접근 거부’만 표시하면 직원은 원인을 알지 못한 채 헬프데스크에 전화합니다. 운영체제 업데이트 필요, 회사 기기 등록 누락, 권한 만료처럼 사용자가 직접 해결할 수 있는 이유와 담당 부서 연락처를 보여 주면 문의 시간을 줄일 수 있습니다.

• 일반 업무에는 비밀번호 없는 인증이나 생체 인증을 우선 검토합니다.
• 관리자 계정에는 별도의 보안키와 전용 단말을 적용합니다.
• 휴대전화 분실 시 본인 확인, 기기 해제, 인증 재등록 순서를 문서화합니다.
• 해외 출장자는 출국 전에 예상 접속 국가와 비상 연락처를 등록하게 합니다.
• 인증 실패가 세 번 이상 반복될 때 무조건 계정을 잠그기보다 위험 신호를 함께 분석합니다.

운영 지표는 보안성과 편의성을 함께 보여 줘야 합니다

“월별 보고서에 공격 차단 건수만 넣으면 정책이 실제 업무에 미친 영향을 알 수 없습니다. 정상 사용자의 평균 인증 시간, 재인증 빈도, 정책별 오탐률, 계정 복구에 걸린 시간도 함께 봐야 합니다. 특정 부서에서 문의가 몰린다면 사용자가 보안에 비협조적인 것이 아니라 업무 방식과 정책 조건이 맞지 않을 가능성이 있습니다.”

1. 인증 성공률과 평균 소요 시간을 부서별로 측정합니다.
2. 차단된 요청을 실제 위협, 설정 오류, 사용자 실수로 구분합니다.
3. 한 달 이상 사용하지 않은 계정과 애플리케이션 권한을 자동 검토합니다.
4. 정책 변경 전후의 문의량과 업무 지연 시간을 비교합니다.
5. 분기마다 비상 계정이 정상적으로 작동하고 기록되는지 모의 점검합니다.

Q. 구축 후 현장에서 반복되는 실수는 무엇입니까?

A. 관리자 예외와 서비스 계정을 방치하면 통제의 빈틈이 됩니다

“첫 번째 실수는 일반 직원에게만 다중 인증을 요구하고 최고관리자 계정에는 편의를 이유로 예외를 주는 것입니다. 공격자는 권한이 큰 계정을 우선 노립니다. 관리자에게 더 강한 인증과 접속 단말 제한을 적용하고, 평상시 사용하는 계정과 시스템 설정을 변경하는 계정을 분리해야 합니다.”

두 번째는 사람 계정만 관리하고 백업 프로그램, 배치 작업, API 연동에 사용하는 서비스 계정을 잊는 것입니다. 비밀번호가 수년간 바뀌지 않거나 여러 서버에서 같은 자격 증명을 공유하면 한 시스템의 침해가 다른 영역으로 번질 수 있습니다. 서비스 계정에는 담당자와 사용 목적, 호출 가능한 시스템, 자격 증명 만료일을 지정하고 가능한 경우 단기 토큰이나 관리형 ID로 전환합니다.

세 번째는 정책 예외를 한 번 승인한 뒤 영구적으로 유지하는 관행입니다. 긴급한 프로젝트 때문에 해외 접속이나 개인 기기를 허용할 수는 있지만 종료일이 없다면 임시 허용이 사실상 기본 정책이 됩니다. 예외 요청 화면에 승인자·사유·대상 자원·만료 시각을 필수로 넣고 만료 전에 자동 알림을 보내야 합니다.

• 과도한 관리자 예외: 전용 관리자 계정과 피싱 저항 인증으로 줄입니다.
• 공유 서비스 계정: 시스템별 자격 증명과 자동 교체 기능을 적용합니다.
• 만료 없는 임시 권한: 기본 만료 기간을 짧게 설정하고 재승인을 요구합니다.
• 로그만 수집하는 운영: 고위험 경보의 담당자와 처리 기한을 사전에 지정합니다.
• 퇴사 처리 지연: 인사 시스템의 퇴사 시각과 계정 비활성화를 연동합니다.

계약 전에 복구 경로를 시험하지 않는 것도 위험합니다

“인증 서버 장애, 통신 회선 단절, 휴대전화 분실이 동시에 발생하지 않으리라는 보장은 없습니다. 보안을 강화한 뒤 정작 관리자 누구도 핵심 시스템에 들어가지 못하면 복구 작업도 시작할 수 없습니다. 비상 계정은 금고에 보관하고 사용할 때 경보가 발생하도록 구성하되, 분기마다 승인된 모의훈련으로 실제 작동 여부를 확인해야 합니다.”

마지막으로 도입 완료일을 보안 프로젝트의 종료일로 잡지 마십시오. 조직 개편, 신규 SaaS 도입, 협력사 교체가 발생할 때마다 권한 관계가 달라집니다. 인사 이동 후 남은 권한, 사용하지 않는 계정, 반복되는 정책 우회를 월별로 점검하는 운영 루틴이 없다면 잘 설계한 제로 트러스트 솔루션도 시간이 지나며 다시 넓은 신뢰 구조로 돌아갑니다.

1. 월 1회 휴면 계정과 장기 예외 권한을 검토합니다.
2. 분기 1회 관리자·서비스 계정의 소유자와 사용처를 확인합니다.
3. 반기 1회 인증 장애와 비상 계정 사용 훈련을 수행합니다.
4. 조직 개편 직후에는 부서 이동자의 이전 권한이 회수됐는지 표본 검사합니다.