제로트러스트 운영 체크리스트: 예외 계정·긴급계정 관리

제로트러스트는 ‘예외를 어떻게 다루는가’에서 무너진다

제로트러스트 실패 사례의 공통점은 정책이 없어서가 아니라, 예외를 예외답게 관리하지 않았다는 데 있다.

실제 운영 현장에서는 시스템 점검, 외부 인력 접속, 야간 장애 대응 같은 이유로 임시 계정이 계속 생긴다.
문제는 그 계정이 하루만 쓰이고 끝나는 것이 아니라, 종료 시각이 빠지고 승인 흔적이 사라진 채 상시 통로가 된다는 점이다.
한 번 편의를 위해 열어둔 예외는 다음 장애 때 더 쉽게 재사용되고, 결국 원래 정책보다 더 넓은 우회 경로가 된다.
그래서 제로트러스트는 차단 정책만으로 완성되지 않는다. 예외 계정과 긴급계정을 어떻게 분리하고, 얼마나 짧게 쓰고, 무엇을 남기느냐가 실제 완성도를 결정한다.

짧은 현장 사례를 보자.
SSO 장애가 발생한 조직에서 공유 관리자 계정으로 임시 접속을 열어 장애를 복구했다.
문제는 복구 이후에도 해당 계정이 비활성화되지 않았고, 3주 뒤 외부 유지보수 작업에 같은 계정이 다시 사용됐다는 점이다.
처음에는 긴급 대응이었지만, 종료 시각과 사유 기록이 없었던 순간부터 그 계정은 긴급계정이 아니라 상시 우회 계정이 된다.

– 예외 유형 정의 : 예외를 한 종류로 묶는 순간 통제가 흐려진다

예외 계정은 목적이 다르면 관리 방식도 달라져야 한다. 가장 먼저 해야 할 일은 예외를 3개 유형으로 나누는 것이다.

첫째, 업무 예외 계정은 시스템 전환, 점검, 데이터 이관처럼 일정이 정해진 작업에 쓰는 계정이다. 사용 기간은 1일에서 7일 이내로 제한하고, 종료 즉시 비활성화해야 한다.

둘째, 벤더·외주 예외 계정은 외부 인력이 접속하는 계정이다. 허용 시간대, 허용 IP, 접근 대상 자산을 함께 묶어야 하고, 내부 담당자 1명을 반드시 소유자로 지정해야 한다.

셋째, 긴급계정(Break Glass) 은 인증 체계 장애, 권한 관리자 부재, 중대 장애처럼 정상 승인 절차가 작동하지 않을 때만 사용하는 계정이다. 이 계정은 편의용 예외가 아니라 복구용 최후 수단이다.

예외 유형이 섞이면 승인 기준이 흐려지고, 로그를 봐도 왜 발급됐는지 해석이 어려워진다.
그래서 예외는 “누가 쓰는가”보다 “왜 지금 필요한가” 기준으로 분류해야 한다.

– 왜 이런 문제가 생기는가

① 예외 계정은 원래 짧게 쓰려고 만들지만 종료 시점을 미리 적지 않으면 상시 계정으로 남는다.
② 상시 계정이 되면 MFA 예외, IP 예외, 승인 생략이 연쇄적으로 붙어 원래 정책보다 더 넓은 우회 경로가 생긴다.
③ 운영자는 장애 복구 속도를 우선하기 때문에 한 번 통과된 예외를 다음 요청에도 반복 적용하게 된다.
④ 긴급계정을 일반 관리자 계정처럼 보관하면 평상시에도 접근 가능한 숨은 통로가 된다.
⑤ 사유 기록 없이 발급된 예외는 사후 감사 때 정상 작업과 비정상 작업을 구분하기 어렵게 만든다.
⑥ 로그 항목이 부족하면 누가, 언제, 어느 자산에, 얼마 동안 접근했는지 재구성하지 못해 같은 통제 실패가 반복된다.

결국 제로트러스트를 무너뜨리는 것은 예외의 존재 자체가 아니다.
예외를 짧고 좁게 관리하지 못하고, 상시 운영처럼 굳혀 버리는 습관이 문제다.

– 긴급계정 분리 : 평상시에도 열 수 있으면 이미 실패다

긴급계정은 반드시 일반 관리자 계정과 보관 위치부터 분리해야 한다. 가장 안전한 운영 방식은 아래 4가지다.

1. 보관 분리
긴급계정 자격증명은 일반 비밀관리 저장소와 별도 금고에 보관한다. 평상시 열람 가능 인원은 2명 이하로 제한하고, 단독 열람이 아니라 이중 승인으로 열어야 한다.

2. 인증 분리
긴급계정은 평상시 SSO 우회용으로 쓰지 않는다. 별도 강력 비밀번호와 별도 MFA 수단을 두고, 정상 인증 체계 장애 시에만 활성화해야 한다.

3. 권한 분리
긴급계정은 “모든 것 가능” 계정이 아니라 복구 목적에 필요한 최소 권한만 가진다. IDP 복구 계정, 서버 접근 복구 계정, 네트워크 장비 복구 계정처럼 1계정 1목적으로 나누는 편이 안전하다.

4. 사용 후 강제 원복
사용 후 1시간 안에 비밀번호 교체, 세션 로그 검토, 예외 종료 확인을 끝내야 한다. 이 세 가지 중 하나라도 빠지면 다음 장애 때 같은 우회가 반복된다.

긴급계정은 빠르게 열 수 있어야 하지만, 쉽게 남아 있어서는 안 된다.
속도와 통제는 동시에 가져가야 한다.

– 비교 기준 : 예외 계정과 긴급계정은 승인선이 달라야 한다

예외 계정과 긴급계정을 같은 프로세스로 처리하면 긴급 상황은 느려지고, 평상시 운영은 과하게 느슨해진다. 아래처럼 목적과 승인 기준을 분리해야 운영 속도와 통제를 동시에 맞출 수 있다.

구분	사용 목적	최대 사용 시간	승인 기준	필수 로그	종료 조건
업무 예외 계정	전환, 점검, 일시 작업	24시간~7일	팀장 1명 + 시스템 소유자 1명	계정명, 실제 사용자, 대상 시스템, 시작/종료 시각, 사유, 작업 ID	종료 즉시 비활성화
벤더·외주 예외 계정	외부 인력 제한 접속	4시간~24시간	내부 담당자 1명 + 보안 승인 1회	계정명, 업체명, 담당자, IP, 접근 자산, 세션 기록	작업 종료 후 잠금
긴급계정(Break Glass)	인증 장애, 관리자 부재, 중대 장애	1시간~4시간	사전 지정자 2인 또는 사후 1시간 내 2인 검토	계정명, 호출 시각, 호출자, 사유 코드, 세션 영상 또는 명령 로그	원인 복구 후 즉시 비밀번호 교체

판단 기준은 단순하다.
정상 절차가 살아 있으면 예외 계정이고, 정상 절차가 죽어 있으면 긴급계정이다.
이 기준이 문장 1개로 정리되지 않으면 현장에서는 거의 모든 요청이 “긴급”으로 변한다.

– 로그·승인 기준 : 남겨야 하는 것은 기록이 아니라 재구성 가능성이다

예외 운영에서 로그는 사후 처벌용이 아니라 사후 복구와 사후 검증을 위한 데이터다.
그래서 “기록을 남겼다”가 아니라 “상황을 다시 재구성할 수 있다”가 기준이어야 한다.

최소 로그 항목은 8개로 고정하는 편이 안정적이다.

1. 계정명
2. 실제 사용한 사람 이름
3. 요청 사유 코드
4. 승인자 이름
5. 시작 시각
6. 종료 시각
7. 접근 자산 또는 시스템
8. 실행 명령 또는 세션 기록 위치

승인 기준도 숫자로 고정해야 한다.
업무 예외 계정은 사전 승인 2명을 기본으로 두고, 긴급계정은 즉시 사용 가능 + 1시간 내 사후 검토 2명 구조로 나누면 속도와 책임을 동시에 확보할 수 있다.
로그 보존 기간은 최소 90일, 가능하면 180일 이상으로 설정하면 분기 감사와 사고 조사에 활용하기 쉽다.

중요한 점은 계정명만 남기지 않는 것이다.
실제 사용자와 시작·종료 시각이 빠진 로그는 감사에는 보여도 조사에는 약하다.

– 보호 방법 : 바로 적용하려면 우선순위 3개부터 자른다

보안 운영은 우선순위가 선명해야 실제로 움직인다. 예외 운영도 같은 방식이 효과적이다.

즉시 실행 1개
현재 살아 있는 예외 계정 목록을 뽑아 종료일이 없는 계정을 전수 표시한다. 종료일이 비어 있으면 그 계정은 이미 정책 바깥에 있다.

오늘 안에 1개
긴급계정과 일반 관리자 계정을 분리하고, 긴급계정 수를 시스템별 1개 또는 역할별 1개로 줄인다.

이번 주 1개
예외 신청 양식에 사유 코드, 종료 시각, 승인자 2명, 로그 위치를 의무 입력값으로 넣고, 미입력 시 발급이 되지 않게 바꾼다.

이 순서가 좋은 이유는 단순하다.
먼저 숨은 상시 계정을 줄이고, 다음에 우회 계정을 분리하고, 마지막으로 재발 방지 장치를 시스템에 심는 구조이기 때문이다.

– 설정 : 운영 체크리스트를 절차로 고정하는 4단계

예외 운영은 사람의 기억이 아니라 절차로 굳혀야 오래 간다. 아래 4단계를 문서와 시스템에 함께 넣으면 기본 골격이 생긴다.

1. 분류표 만들기
예외 계정, 벤더 계정, 긴급계정 3종으로 나누고 각 계정의 최대 사용 시간과 승인선을 표로 고정한다.

2. 만료 정책 넣기
모든 예외 계정에 종료 시각을 강제하고, 최대 시간 초과 시 자동 잠금되게 한다. 업무 예외는 7일, 벤더 계정은 24시간, 긴급계정은 4시간을 상한으로 두면 운영이 단순해진다.

3. 승인 흐름 묶기
요청자, 시스템 소유자, 승인자, 실제 사용자를 한 요청서에 연결한다. “요청자와 실제 사용자 동일”을 기본값으로 두지 말고 별도 입력 칸으로 분리해야 한다.

4. 사용 후 원복 자동화
예외 종료 시 비밀번호 교체, 세션 로그 저장, 티켓 종료 확인을 한 번에 묶는다. 원복 자동화가 없으면 예외는 다음 근무조까지 남는다.

– 30초 체크리스트

• 종료 시각이 없는 예외 계정이 0개다.

• 긴급계정은 일반 관리자 계정과 보관 위치가 다르다.

• 긴급계정 사용 후 1시간 내 사후 검토 절차가 있다.

• 요청 사유, 승인자, 대상 자산, 시작·종료 시각이 모두 로그에 남는다.

• 벤더 계정은 내부 담당자 1명이 소유자로 지정돼 있다.

– 자주 하는 실수 : 편의 계정이 되는 순간 긴급계정은 끝난다

가장 흔한 실수는 긴급계정을 “관리자 편의 계정”처럼 쓰는 것이다.
긴급계정은 장애 복구용이지, 야간 빠른 작업용이 아니다.

두 번째 실수는 승인만 받고 종료를 확인하지 않는 것이다.
발급보다 회수가 더 중요하다.

세 번째 실수는 실제 사용자를 기록하지 않고 팀 계정으로 뭉개는 것이다.
계정명만 남으면 감사도 조사도 어려워진다.

주의할 점은 예외를 없애는 것이 목표가 아니라, 예외가 생겨도 기간 제한과 사유 기록이 빠지지 않게 만드는 것이다.

– 마무리 : 예외를 허용하는 조직이 아니라, 종료 시각 없는 예외를 방치하는 조직이 위험하다

인증 체계가 살아 있는 조직은 예외 계정의 종료 시각과 승인선을 먼저 고정하는 것이 우선이다.
외부 인력 접속이 잦은 조직은 벤더 계정의 소유자 지정과 세션 로그 저장을 먼저 강화하는 편이 효과적이다.
야간 장애 대응이 많은 조직은 긴급계정 보관 분리와 사용 후 1시간 내 원복 절차를 가장 먼저 문서화해야 한다.

예외는 ‘기간 제한+사유 기록’ 두 가지가 필수다.
예외를 허용하는 조직이 위험한 것이 아니다. 종료 시각 없는 예외를 방치하는 조직이 위험하다.

– 요약

• 예외 계정, 벤더 계정, 긴급계정은 목적과 승인선을 분리해야 한다.

• 긴급계정은 평상시 접근 불가, 사용 후 1시간 내 원복이 핵심이다.

• 예외 운영의 최소 기준은 기간 제한, 사유 기록, 승인 2명, 로그 8항목이다.

– FAQ