공격자는 어려운 익스플로잇부터 찾지 않는다

공격자가 선택하는 침투 경로
인터넷 노출 영역에서 최초 접근을 만드는 조건
- 2.1 관리에서 빠진 외부 자산과 개발 환경
- 2.2 서비스별 인증 통제의 빈틈이 연결될 때
- 2.3 협력사 접점에 생기는 보안 통제의 격차
침해 이후 권한 상승과 내부 이동을 만드는 조건
- 3.1 서비스 계정의 민감 권한과 잘못된 접근 권한
- 3.2 재사용된 로컬 관리자 자격증명
- 3.3 레거시 인증·권한 구조라는 기술 부채
공격 경로의 연결 끊기
- 4.1 외부 자산과 개발 환경 관리
- 4.2 계정 발급·활성화·인증·복구·회수 전 과정 관리
- 4.3 협력사 계정·접속 책임과 데이터 경계
- 4.4 내부 권한 상승과 이동 제한
마치며: 비싼 공격을 강요하는 가장 효율적인 보안
참고 자료

1. 공격자가 선택하는 침투 경로

기업 침투를 떠올리면 제로데이나 복잡한 익스플로잇으로 보안 장비를 우회한 뒤 핵심 서버를 장악하는 장면이 먼저 떠오릅니다. 그래서 보안 수준을 평가할 때도 개별 시스템에 심각한 취약점이 있는지가 우선적인 판단 기준이 되곤 합니다. 이 관점만으로는 공격이 실제로 어디서 시작해 어디까지 이어지는지 놓치기 쉽습니다.

공격자의 판단 기준은 취약점 등급보다 목표까지 드는 비용에 가깝습니다. 공격자는 현재 확보한 정보와 접근 수단으로 성공 가능성이 높은 경로를 찾습니다. MFA가 적용되지 않은 계정, 잘못 부여된 권한, 기본 자격증명, 패치되지 않은 소프트웨어와 불필요하게 노출된 서비스는 그 경로를 짧게 만듭니다. (Microsoft, Implementing Least-Privilege Administrative Models)

하나의 결정적인 취약점이 없어도 여러 시스템에 흩어진 관리 공백이 연결되면 침투 경로가 만들어집니다. 조직은 자산과 계정을 담당 부서나 서비스 단위로 나누어 관리하지만, 공격자는 같은 기업의 도메인, 계정 체계, 외부 접속 서비스와 시스템 사이의 신뢰 관계를 하나의 환경으로 봅니다. 한 영역에서 얻은 정보나 권한이 다음 영역의 접근 수단이 되면 조직도상의 분리는 공격 경로의 분리가 되지 않습니다.

이 글에서는 인터넷에서 직접 접근할 수 있는 서비스와 자산을 인터넷 노출 영역, 최초 접근 이후 도달할 수 있는 조직 내부의 시스템·관리 영역과 그 사이의 신뢰 관계를 내부 시스템·신뢰 영역으로 부릅니다. 인터넷 노출 서비스와 계정 체계에서 시작해 Windows·AD(Active Directory) 환경의 내부 권한으로 이어지는 경로에 초점을 둡니다.

먼저 인터넷 노출 영역에서 최초 접근을 만드는 조건을 살펴봅니다. 이어서 확보한 계정과 장비가 내부에서 더 높은 권한과 다른 시스템으로 확장되는 과정을 다루고, 마지막으로 외부 자산, 인증, 협력사 접점과 내부 권한의 각 단계에서 이 연결을 끊는 원칙을 정리합니다.

아래 사례는 공개 자료가 설명하는 기술적 위험과 보안 원칙을 바탕으로 구성한 독립적인 가상 상황입니다. 실제 침해 가능성과 피해 범위는 외부 노출, 자격증명, 네트워크 도달성, 실행 권한과 신뢰 관계가 어떻게 연결되는지에 따라 달라집니다.

2. 인터넷 노출 영역에서 최초 접근을 만드는 조건

인터넷 노출 영역에서는 관리되지 않은 자산, 서비스별 인증 통제의 차이와 협력사 접점의 예외가 각각 다른 문제처럼 보입니다. 그러나 한곳에서 노출된 정보가 다른 서비스의 인증에 사용되는 것처럼, 개별적으로는 영향이 작아 보이는 조건이 연결되면 최초 접근 경로가 만들어질 수 있습니다.

2.1 관리에서 빠진 외부 자산과 개발 환경

외부 공격 표면에서 반복해서 살펴야 할 문제 중 하나는 조직이 존재를 파악하지 못한 자산입니다. 현업·개발 조직이나 협력사가 업무상 필요에 따라 서버와 서비스를 구축하면서 자산 등록이나 보안 검토 절차를 거치지 않고 인터넷에 공개하는 경우가 있습니다. 보안팀이 알지 못하는 자산은 정기적인 취약점 점검과 패치, 접근 통제와 로그 모니터링의 대상에서도 빠질 수 있습니다. 그 결과 공개된 취약점이 패치되지 않거나 기본 자격증명 또는 관리 서비스가 인터넷에 노출된 채 남을 수 있습니다.

개발·스테이징 환경은 이러한 관리 공백이 나타나기 쉬운 대표적인 유형입니다. 임시로 구축되거나 별도 조직에서 운영되면서 담당자가 불분명해지고, 사용이 끝난 뒤에도 외부에 남기 쉽습니다. 여기에 위험에 상응하는 인증·접근 통제가 적용되지 않고 운영 데이터나 운영용 비인간 자격증명까지 공유된다면, 개발 환경의 침해가 운영 데이터와 자원에 대한 침해로 이어질 수 있습니다.

가령 관리되지 않은 자산에서 임직원 정보, 실제 데이터, 서비스 구조와 계정 규칙이 노출되면 다른 서비스의 계정 추정과 인증 시도에 활용될 수 있습니다. 서버 측 코드 실행이나 내부 호출 권한처럼 내부 연결을 이용할 수 있는 조건이 있거나 운영 자격증명과 신뢰 관계까지 공유한다면, 하나의 미승인 자산이 내부 확장의 출발점이 될 수 있습니다.

2.2 서비스별 인증 통제의 빈틈이 연결될 때

기업의 로그인과 계정 정책은 서비스별로 운영되지만, 계정명 규칙과 비밀번호 사용 관행은 조직 전체에서 반복되는 경우가 많습니다. 이 때문에 한 서비스에서 노출된 계정 정보와 느슨한 인증 통제가 다른 서비스의 접근 위험으로 이어질 수 있습니다.

기업 계정의 아이디는 이름·이메일·사번 등을 조합한 일정한 규칙으로 생성되는 경우가 많습니다. 비밀번호에도 사용 편의와 조직의 관행이 반영됩니다. 기업명이나 계절·연도에 숫자 또는 특수문자를 덧붙이는 방식처럼 조직 맥락에서 추측하기 쉬운 비밀번호가 사용되면, 공개된 정보만으로도 계정 정보의 예측 가능성이 높아집니다.

로그인·회원가입·복구 기능의 응답 차이는 계정 존재 여부를 드러낼 수 있습니다. 여기에 예측 가능한 비밀번호와 약한 로그인 시도 제한이 겹치면 패스워드 스프레이의 위험이 커지고, 다른 서비스에서 유출된 아이디·비밀번호가 재사용되면 크리덴셜 스터핑으로 이어질 수 있습니다. (MITRE ATT&CK T1110.003: Password Spraying, MITRE ATT&CK T1110.004: Credential Stuffing) 대상 서비스가 해당 자격증명을 받아들이고 추가 인증을 요구하지 않으면 실제 계정 접근이 가능해집니다. 같은 자격증명이 VPN·VDI, 원격 데스크톱 게이트웨이와 ZTNA(제로 트러스트 네트워크 액세스) 같은 외부 접속 수단에도 사용되고 계정에 접속 권한이 있다면 내부 접근으로 이어질 수 있습니다.

계정 발급 범위와 실제 이용 범위의 차이도 비슷한 공백을 만듭니다. 가령 이용 대상보다 넓은 범위에 계정을 미리 만들고 아이디와 초기 비밀번호에 모두 사번처럼 알려진 식별자를 사용하면, 미사용 계정에 예측 가능한 초기 비밀번호가 남습니다. 별도의 본인 확인이나 활성화 절차까지 없다면 정상 사용자가 처음 로그인하기 전에 외부에서 계정이 점유될 수 있습니다. (OWASP WSTG, Testing for Default Credentials)

따라서 인증 위험은 서비스별 로그인 설정만 따로 보지 말고 조직 전체의 계정 체계에서 살펴야 합니다. 계정 정보가 어디에서 노출되는지, 어느 서비스의 로그인·복구·활성화 통제가 약한지, 추가 인증이 적용되는지, 같은 자격증명이 어디까지 통용되는지를 함께 확인해야 합니다.

2.3 협력사 접점에 생기는 보안 통제의 격차

임직원과 협력사가 같은 서비스를 사용하더라도 계정과 접속 환경을 관리하는 방식은 다를 수 있습니다. 임직원 계정과 단말은 발주 조직이 직접 발급·관리하며 보안 정책을 적용할 수 있습니다. 협력사 접속에서는 발주 조직이 서비스 계정과 권한을 관리하고, 협력사가 사용자의 재직 여부와 단말 상태를 관리하는 식으로 역할이 나뉩니다. 관련 정보가 제때 공유되지 않거나 책임 범위가 불분명하면 계정 변경·회수, 단말 점검과 본인 확인 절차에 공백이 생길 수 있습니다.

이러한 역할 분담은 계정 복구 절차에도 영향을 줍니다. 발주 조직이 협력사 사용자의 신원 정보와 연락 수단을 직접 관리하지 않으면 임직원 계정과 별도의 복구 절차를 두기도 합니다. 가령 이름과 주소, 생년월일처럼 조직이 이미 보유한 정적 정보를 질문하고, 답이 일치하면 비밀번호 재설정을 허용하는 방식입니다. (OWASP, Choosing and Using Security Questions Cheat Sheet)

이런 정보는 공개 프로필이나 업무 연락처, 유출된 자료 등에서 확인할 수 있고 비밀번호처럼 사용자만 알고 있다고 보기 어렵습니다. 별도의 등록 수단이나 소유 증명 없이 정적 정보만으로 복구가 완료된다면 정상 로그인보다 약한 인증 경로가 됩니다. 협력사 계정이 중요 기능이나 데이터에 접근할 수 있다면, 가장 약하게 통제된 경로가 서비스 전체의 위험을 좌우할 수 있습니다. 사용자·역할·업체별 접근 범위까지 분리되지 않았다면 하나의 계정 침해가 다른 조직의 정보로 확대될 수 있습니다. (OWASP, Multi-Tenant Security Cheat Sheet)

3. 침해 이후 권한 상승과 내부 이동을 만드는 조건

인터넷 노출 자산이나 계정에서 확보된 접근은 내부 시스템의 권한과 신뢰 관계를 만나면서 피해 범위가 달라집니다. 서비스 계정의 민감 권한, 재사용된 관리자 자격증명과 오래된 인증 구조는 제한된 접근을 더 높은 권한과 다른 시스템으로 확대하는 조건이 됩니다.

내부 네트워크의 위치 자체를 신뢰의 근거로 삼거나, AD의 계정·권한 정책과 개별 시스템의 로컬 권한·원격 접속 설정을 따로 관리하면 계정 탈취 이후 이어지는 이동 경로가 통제 밖에 남을 수 있습니다.

3.1 서비스 계정의 민감 권한과 잘못된 접근 권한

업무 서비스를 실행하는 계정에는 운영체제 기능과 자원에 접근하기 위한 권한이 부여됩니다. 서비스 동작에 필요한 권한이라도 서비스 취약점이나 자격증명 노출로 해당 계정의 보안 컨텍스트에서 코드가 실행되면 이후의 피해 수준을 결정하는 조건이 됩니다. Windows에서는 whoami /priv로 현재 액세스 토큰에 포함된 사용자 권한과 활성화 상태를 확인할 수 있습니다.

예를 들어 인증한 클라이언트의 보안 컨텍스트를 가장할 수 있는 SeImpersonatePrivilege, 백업·복구 작업에서 각각 파일과 레지스트리의 읽기·쓰기 접근 통제를 우회할 수 있는 SeBackupPrivilege와 SeRestorePrivilege, 다른 프로세스와 커널을 조사하거나 제어하는 데 사용되는 SeDebugPrivilege, 장치 드라이버와 커널 모드 코드를 적재·해제할 수 있는 SeLoadDriverPrivilege 등이 있습니다. 정상적인 관리와 서비스 운영을 위해 설계된 권한이지만, 필요하지 않은 계정에 부여되거나 권한을 사용할 수 있는 다른 조건과 결합하면 제한된 코드 실행을 더 높은 권한으로 확대하는 수단이 될 수 있습니다. (Microsoft, Privilege Constants)

운영체제의 특수 권한 외에 서비스 실행 파일과 해당 파일이 위치한 디렉터리의 접근 권한도 중요합니다. 일반 사용자나 낮은 권한의 서비스 계정이 높은 권한으로 실행되는 서비스의 실행 파일을 변경할 수 있다면, 서비스가 다시 시작될 때 변경된 파일도 같은 권한으로 동작할 수 있습니다. 운영과 배포의 편의를 위해 넓게 부여한 쓰기·수정 권한이 실행 권한과 연결되면서 권한 상승 조건이 만들어지는 것입니다. (MITRE ATT&CK T1574.010: Services File Permissions Weakness)

따라서 로컬 권한 상승 가능성은 특정 도구나 하나의 취약점만으로 판단하기 어렵습니다. 서비스 계정이 보유한 운영체제 권한, 실행 중인 기능, 파일과 레지스트리의 접근 제어, 서비스와 예약 작업의 구성, 해당 계정으로 코드를 실행할 수 있는 경로를 함께 살펴야 합니다. 이미 부여된 권한과 잘못된 접근 제어가 연결되면 제한된 접근이 장비의 관리 권한으로 확대될 수 있습니다.

3.2 재사용된 로컬 관리자 자격증명

배포 이미지나 자동화된 구축 과정에서 여러 Windows 장비에 같은 로컬 관리자 계정과 암호를 적용하면, 각 장비에는 같은 암호에서 파생된 NT 해시가 저장됩니다.

한 장비에서 이 해시가 노출되고 다른 장비에도 같은 로컬 관리자 계정이 존재한다면, NTLM 기반 네트워크 로그온과 원격 관리가 허용된 환경에서는 원래 암호를 알아내지 않고도 해시를 인증에 재사용할 수 있습니다. 이를 Pass-the-Hash라고 합니다. 이 경로가 열려 있으면 하나의 장비 침해가 여러 시스템으로 이어질 수 있습니다. (Microsoft, Local accounts)

이때 암호의 복잡도와 별개로 같은 자격증명이 배포된 장비의 범위가 침해 범위를 좌우합니다. 한 장비에서 노출된 자격증명이 여러 장비에 그대로 통한다면 그 배포 범위가 곧 내부 이동 가능 범위가 됩니다.

3.3 레거시 인증·권한 구조라는 기술 부채

레거시 시스템에서는 인증과 권한이 업무 절차와 시스템 간 연계에 깊게 묶여 있습니다. 오래된 인증 방식, 공유 계정, 애플리케이션에 내장된 자격증명과 넓은 권한이 오랜 운영 과정에서 정상 기능의 전제처럼 굳어지면, 계정이나 권한 하나를 바꾸는 작업도 여러 서비스에 영향을 주게 됩니다.

오래된 업무 연계 프로그램이 하나의 도메인 서비스 계정으로 여러 서버의 Windows 서비스와 예약 작업을 실행하고, 파일 공유와 데이터베이스에도 접근하는 경우를 생각해 볼 수 있습니다. 같은 계정이 여러 서버의 서비스 설정과 연계 스크립트에 사용되면 암호를 교체할 때 연결된 서비스와 작업을 모두 찾아 수정하고 재시작해야 합니다. 의존 관계가 빠짐없이 파악되지 않은 환경에서는 일부 업무가 중단될 수 있어 암호 교체가 계속 미뤄지고, 한곳에서 노출된 자격증명이 여러 시스템에 통하는 구조가 유지됩니다. (MITRE ATT&CK T1552.001: Credentials In Files)

권한 모델에서도 비슷한 문제가 생깁니다. 오래된 업무 시스템이 세분화된 역할을 지원하지 않고 일반 사용자와 관리자처럼 몇 개의 넓은 역할만 제공하면, 특정 승인이나 조회 기능이 필요한 담당자에게 관리자 역할을 부여해야 할 수 있습니다. 이때 설정 변경, 전체 데이터 조회와 계정 관리처럼 담당 업무와 무관한 권한까지 함께 따라옵니다. 이를 분리하려면 애플리케이션 코드와 업무 절차를 함께 바꿔야 하므로 과도한 권한이 장기간 유지되고, 계정 침해 시 피해 범위도 본래 업무 영역을 넘어설 수 있습니다.

서비스 계정의 의존성과 넓게 묶인 역할은 형태는 다르지만, 필요한 접근 범위와 실제 부여된 범위를 분리하기 어렵게 만든다는 공통점이 있습니다. 변경의 영향을 파악하기 어려울수록 예외는 장기화되고, 하나의 자격증명이나 계정이 침해됐을 때 어디까지 영향을 받는지도 예측하기 어려워집니다. 레거시 인증·권한 구조가 기술 부채로 작동하는 지점입니다.

4. 공격 경로의 연결 끊기

2장에서 살펴본 조건은 최초 접근 가능성을 만들고, 3장의 권한과 신뢰 관계는 그 이후의 피해 범위를 결정합니다. 이 연결을 끊기 위해 외부 자산, 계정, 협력사 접점과 내부 권한의 순서로 통제를 정리합니다.

4.1 외부 자산과 개발 환경 관리

자산 식별은 취약점 조치와 접근 통제, 로그 모니터링의 전제입니다. 운영 서비스뿐 아니라 개발·스테이징 환경, 과거 도메인, 협력사가 운영하거나 사용하는 외부 접점까지 지속적으로 식별하고 담당자와 용도, 인터넷 노출 상태를 관리해야 합니다. 식별한 자산은 취약점 점검과 패치, 접근 통제, 인증서·도메인 갱신, 로그 수집과 모니터링의 관리 범위에 편입해야 합니다. 사용이 끝난 서비스는 외부 노출을 제거하고, 인터넷 공개가 필요한 자산은 노출 필요성과 보호 상태를 반복해서 검토해야 합니다. (NCSC, Asset Management)

공개가 필요한 개발 환경은 위험에 상응하는 인증·접근 통제로 보호해야 합니다. 개발 환경에서 운영망, 관리 API와 클라우드 관리 영역으로 향하는 통신과 신뢰 관계는 기본적으로 차단하고 업무에 필요한 경로만 허용해야 합니다. 운영 데이터를 사용해야 한다면 그 사용을 승인·기록·통제하고 데이터의 영향도와 분류 수준에 맞게 비운영 환경을 보호해야 합니다. 실제 데이터는 가능한 한 대체 데이터로 바꾸고, 운영용 서비스 계정·API 키·클라우드 역할 같은 비인간 자격증명은 비운영 환경용과 분리해야 합니다. (NIST SP 800-53 Rev. 5, SA-3(1)·(2), OWASP NHI8: Environment Isolation)

4.2 계정 발급·활성화·인증·복구·회수 전 과정 관리

계정 운영의 시작점은 발급과 활성화입니다. 계정은 실제 이용 대상에게 필요한 시점에 발급해야 합니다. 전 임직원이나 협력사 대상 계정을 미리 만들어야 한다면 별도의 활성화 절차와 최초 로그인 기한을 두고, 기한 내 활성화되지 않거나 장기간 사용되지 않은 계정은 자동으로 비활성화해야 합니다. 초기 비밀번호에는 사번이나 기업명 같은 예측 가능한 값을 사용하지 말고 사용자별 일회용 무작위 값을 발급해야 합니다.

여러 사람이 함께 사용하는 공용 계정은 개인별 계정으로 전환해야 합니다. 업무상 유지해야 한다면 비밀정보 금고를 통한 사용 승인과 대여, 사용자별 행위 기록, 정기적인 자격증명 교체를 적용하고 길고 고유한 비밀번호를 사용해야 합니다.

서비스마다 별도의 비밀번호를 사용한다면 비밀번호 관리 도구를 지원해 서비스별로 고유한 값을 사용하도록 하고, 유출되었거나 널리 사용되는 비밀번호는 발급과 변경 단계에서 차단해야 합니다. 인터넷을 통해 내부 자원, 민감 데이터나 관리 기능에 도달하는 계정에는 MFA를 적용하고, 인증 수단의 강도와 재인증 시점은 계정의 접근 범위에 맞게 정해야 합니다. (NIST SP 800-63B-4)

인증 단계에서는 계정명 규칙이 외부에 알려질 수 있다고 전제해야 합니다. 로그인, 회원가입, 계정 찾기와 비밀번호 복구 기능은 계정의 존재 여부와 관계없이 가능한 한 일관된 응답을 반환해야 합니다. 오류 문구뿐 아니라 HTTP 상태 코드, 응답 본문과 처리 시간의 차이도 계정 존재 여부를 구분하는 단서가 될 수 있으므로 함께 점검해야 합니다. (OWASP, Authentication Cheat Sheet)

로그인 시도 방어는 계정이나 IP 하나의 실패 횟수만 보지 말고, 여러 계정에 소수의 비밀번호를 분산하는 패스워드 스프레이와 유출된 아이디·비밀번호 조합을 반복 사용하는 크리덴셜 스터핑 패턴을 함께 탐지해야 합니다. 계정, IP, 기기, 네트워크 범위와 시간대를 함께 살피고, 같은 계정 체계를 사용하는 서비스 사이에서도 인증 실패 신호를 연계해야 합니다. 자격증명 노출이 확인되면 비밀번호를 재설정하고 활성 세션과 토큰을 폐기한 뒤 관련 서비스의 영향 범위를 확인해야 합니다.

복구 단계의 본인 확인 수준은 정상 로그인보다 낮아지지 않도록 설계해야 합니다. 이름과 주소, 생년월일처럼 외부에서 확인할 수 있는 정적 정보나 보안 질문만으로 비밀번호를 재설정하지 말고, 사전에 등록하고 검증한 연락 수단으로 일회용 링크나 코드를 보내거나 기존 인증 수단과 별도의 승인을 함께 사용해야 합니다. (OWASP, Forgot Password Cheat Sheet)

역할 변경과 접근 권한 회수도 같은 수명주기 안에서 관리해야 합니다. 부서·직무·소속 업체가 바뀌면 기존 권한을 재검토하고, 퇴직·계약 종료처럼 접근 필요성이 사라진 경우에는 계정과 세션, 토큰과 원격 접속 권한을 지체 없이 회수해야 합니다.

4.3 협력사 계정·접속 책임과 데이터 경계

발주 조직과 협력사는 계정 발급·변경·복구·회수, 사용자의 재직 여부와 단말 상태 확인을 각각 누가 맡고 언제 통보할지 정해야 합니다. 양측의 사용자 명단과 계정 상태를 정기적으로 대조하고, 퇴직·계약 변경처럼 즉시 반영해야 하는 사건은 통보 기한과 처리 책임자를 명확히 해야 합니다.

협력사 포털의 접속 통제는 단말 관리 상태, 접속 위치, 계정이 접근할 수 있는 기능과 데이터의 위험을 기준으로 정해야 합니다. 외부 네트워크나 관리되지 않는 단말에서 접속하는 경우에는 세션 시간과 다운로드 범위를 제한하고, 중요 기능을 사용할 때 추가 인증이나 관리된 접속 환경을 요구해야 합니다. (NIST SP 800-207, Zero Trust Architecture)

임직원과 협력사 사이의 권한을 분리하고, 협력사별·역할별 권한과 데이터 경계도 구분해야 합니다. 하나의 업체 계정이나 요청값이 다른 업체의 데이터에 접근할 수 없는지 인증 이후의 모든 경로에서 검증해야 합니다.

발주 조직이 협력사 사용자의 신원을 직접 확인하기 어려운 복구 절차에는 등록된 협력사 관리자와 검증된 연락 수단을 함께 사용해야 합니다. 이름과 주소, 생년월일 같은 정적 정보만으로 복구를 완료하지 말고, 복구와 예외 승인 내역, 평소와 다른 위치나 단말에서의 접근을 함께 모니터링해야 합니다. 운영 편의를 위해 허용한 예외에는 승인 책임자와 적용 범위, 만료 시점을 지정하고 계약·업무 종료 시 계정과 원격 접속 권한을 회수해야 합니다.

4.4 내부 권한 상승과 이동 제한

VPN·VDI, 원격 데스크톱·SSH 게이트웨이와 ZTNA를 통과한 원격 세션은 업무에 필요한 자원과 관리 포트에만 도달하도록 제한해야 합니다. 개발과 운영, 일반 사용자와 관리자 영역은 별도의 권한과 관리 경로로 나누고, 경계를 넘을 때는 추가 인증을 요구해야 합니다. 접근 범위는 사용자·단말·시간과 업무 필요를 기준으로 정하고 성공·실패 기록을 함께 모니터링해야 합니다.

AD도 개별 설정 항목만 확인하는 데 그치지 말고, 낮은 권한의 계정에서 시작해 어떤 시스템과 민감 계정, 관리 권한으로 이동할 수 있는지 경로 단위로 점검해야 합니다. 권한 그룹의 구성과 위임 관계, 로컬 관리자 권한, 원격 로그온 가능 범위와 시스템 사이의 신뢰 관계를 함께 살펴야 합니다.

서비스 계정에는 필요한 운영체제 권한만 부여하고 대화형 로그인과 원격 로그인, 실행·네트워크 범위를 제한해야 합니다. 계정별 권한 할당과 관리자 그룹 포함 여부를 정기적으로 검토하고, 사용하지 않는 민감 권한과 기능은 제거해야 합니다. 서비스 실행 파일과 스크립트, 플러그인, 설정 파일, 레지스트리와 예약 작업은 관리자나 승인된 배포 계정만 변경할 수 있도록 접근 권한을 제한하고 변경 여부를 점검해야 합니다.

로컬 관리자 암호는 Windows LAPS와 같은 체계로 장비별 무작위 값을 생성·회전하고, 승인된 관리자만 조회할 수 있도록 관리해야 합니다. 로컬 관리자 계정의 네트워크 로그온과 원격 대화형 로그온은 필요한 관리 경로로 제한하고, SMB·WinRM·RDP 같은 관리 서비스는 승인된 관리 단말과 네트워크에서만 접근하도록 해야 합니다. 암호 조회 기록을 감사하고 사용되거나 노출이 의심된 암호는 회전해야 합니다. (Microsoft, Windows LAPS Overview)

레거시 서비스 계정은 소유자, 실행 위치, 연결된 서비스와 예약 작업, 자격증명 저장 위치와 필요한 권한을 목록화해야 합니다. Windows 도메인 환경에서 지원되는 워크로드는 관리형 서비스 계정으로 전환하고, 나머지는 비밀정보 관리 체계와 단계적 배포·검증 계획을 바탕으로 자격증명을 회전해야 합니다. 설정 파일과 스크립트에 내장된 자격증명도 중앙에서 관리하고 회전할 수 있는 저장소로 옮겨야 합니다. (Microsoft, Service Accounts in Windows Server)

세분화된 역할을 지원하지 않는 시스템은 관리자용 계정을 일반 업무 계정과 분리하고, 관리자 기능의 사용을 승인·기록하며 적용 시간과 사용자를 제한해야 합니다. 이러한 보완 통제와 함께 역할 모델 개선이나 시스템 교체 일정을 관리해 과도하게 묶인 권한을 단계적으로 줄여야 합니다. (NIST SP 800-53 Rev. 5, AC-6)

5. 마치며: 비싼 공격을 강요하는 가장 효율적인 보안

공격자는 굳이 어려운 길을 택하지 않습니다. 관리 대상에서 빠진 서버가 인터넷에 노출돼 있거나, 패치되지 않은 취약점과 지원이 끝난 제품이 그대로 운영되고, 추측할 수 있는 비밀번호와 재사용된 관리자 자격증명이 남아 있다면 복잡한 익스플로잇을 준비할 이유가 없습니다. 이미 드러난 약점만 따라가도 다음 단계로 넘어갈 수 있기 때문입니다.

보안의 우선순위도 이 경로를 따라 정해야 합니다. 인터넷에 노출된 자산을 관리 범위에 넣고, 서비스마다 남아 있는 우회 로그인과 복구 경로를 점검해야 합니다. 사용이 끝난 협력사 계정은 회수하고, 관리자 자격증명과 서비스 계정의 재사용을 줄여야 합니다. 어느 한곳이 뚫리더라도 다른 시스템까지 그대로 이어지지 않도록 권한과 접속 범위도 나눠야 합니다.

쉬운 경로를 하나씩 끊으면 공격자의 계산이 달라집니다. 준비해야 할 것은 많아지고, 성공 가능성은 낮아지며, 탐지될 위험은 커집니다. 공개된 서버 하나나 재사용된 암호 하나로 목적지에 닿지 못하게 해야 합니다.

자산·계정·권한에서 시작되는 쉬운 길부터 끊어, 공격자가 처음부터 어렵고 비싼 익스플로잇을 준비해야 하는 환경을 만듭시다.

6. 참고 자료

NCSC, Asset Management — 인터넷 자산을 포함한 전체 자산의 지속적 발견·목록화와 취약점·패치·모니터링의 연계
NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations — SA-3의 비운영 환경·운영 데이터 보호와 AC-6의 최소 권한
NIST SP 800-63B-4 (2025), Digital Identity Guidelines: Authentication and Authenticator Management — 취약·유출 비밀번호 차단, 비밀번호 관리 도구 지원과 인증 수단의 강도
NIST SP 800-207, Zero Trust Architecture — 네트워크 위치만으로 신뢰하지 않고 사용자·단말·접속 맥락과 자원별 위험에 따라 접근을 결정하는 원칙
OWASP NHI8: Environment Isolation — 개발·테스트·스테이징·운영 환경 사이의 서비스 계정·API 키·역할 분리와 운영 자원 접근 차단
OWASP, Authentication Cheat Sheet — 로그인·회원가입·복구 응답과 상태 코드·처리 시간 차이를 통한 계정 열거 방지
OWASP WSTG, Testing for Default Credentials — 예측 가능한 기본·초기 자격증명과 최초 로그인 전 미변경 계정의 위험
OWASP, Choosing and Using Security Questions Cheat Sheet — 이름·주소·생년월일 등 외부에서 확인할 수 있는 정적 정보의 낮은 인증 강도와 보안 질문의 단독 사용 위험
OWASP, Forgot Password Cheat Sheet — 별도 채널의 무작위 일회용 토큰을 이용한 비밀번호 재설정
OWASP, Multi-Tenant Security Cheat Sheet — 업체·사용자·테넌트 간 데이터와 권한 경계의 분리 및 교차 테넌트 접근 방지
MITRE ATT&CK T1110.003: Password Spraying — 소수의 흔한 비밀번호를 여러 계정에 분산해 시도하는 기법
MITRE ATT&CK T1110.004: Credential Stuffing — 다른 서비스에서 확보한 아이디·비밀번호 쌍을 재사용하는 기법
MITRE ATT&CK T1574.010: Services File Permissions Weakness — 잘못된 서비스 파일·디렉터리 권한을 이용해 상위 권한으로 코드를 실행하는 기법
MITRE ATT&CK T1552.001: Credentials In Files — 구성 파일·스크립트·소스 코드 등에 저장된 서비스 계정 자격증명의 노출 위험
Microsoft, Privilege Constants — Windows의 SeImpersonatePrivilege, SeBackupPrivilege, SeRestorePrivilege, SeDebugPrivilege, SeLoadDriverPrivilege 기능 정의
Microsoft, Local accounts — 로컬 관리자 암호와 해시의 재사용에 따른 Pass-the-Hash 위험
Microsoft, Windows LAPS Overview — 장비별 로컬 관리자 암호의 자동 생성·회전·백업과 측면 이동 위험 감소
Microsoft, Implementing Least-Privilege Administrative Models — 공격자가 저항이 적은 경로를 선택하는 경향과 과도한 권한·자격증명 재사용을 줄이는 원칙
Microsoft, Service Accounts in Windows Server — Windows 서비스·예약 작업·응용 프로그램의 서비스 계정 사용과 관리형 서비스 계정의 자동 암호 관리