※본 기사는 당사 내부 논의·경험 및 일반적인 보안 원칙을 바탕으로 정리한 내용입니다. 특정 기업·조직의 공식 견해나 특정 벤더의 내부 구현을 나타내는 것이 아닙니다.

✅ 면책 사항 #

• 본 기사의 내용은 정보 시스템의 일반적인 설계·운영 방법론을 소개하는 것이며, 모든 조직에 대해 안전성·적합성을 보장하는 것이 아닙니다.

• 실제 도입 시에는 자사의 규모·업종·리스크 허용도·법규·계약 의무 등을 고려하여 전문가의 자문이나 내부 검토를 수행할 것을 권장합니다.

• 본 기사에 근거하여 수행된 운영·설정·조직 변경 등으로 인해 발생한 어떠한 손해에 대해서도 저자 및 소속 조직은 일체의 책임을 지지 않습니다.

들어가며: 한 사람이 “모든 것을 아는” 상태는 강력하지만 위험하다 #

인프라·클라우드·보안 분야에서는
“무엇이든 할 수 있고 무엇이든 아는 ‘신 엔지니어'”가 중용되는 경향이 있습니다.

하지만 동시에 이는 다음과 같은 리스크를 내포하고 있습니다:

• 그 사람이 없어지면 운영이 돌아가지 않음(Bus Factor가 1)

• 권한이 지나치게 집중되어 오조작·사고 발생 시 영향이 치명적

• 보안상으로도 “내부 범행 리스크”가 높은 구조가 됨

대규모 클라우드나 금융기관, SWIFT 등의 세계에서는
이 문제를 피하기 위해 “누구도 전체를 지배할 수 없는 구조”가 상식이 되어가고 있습니다.

하지만 같은 방식을 중소 규모 조직에 그대로 적용하려 하면
관리 비용이 폭증하여 현장이 감당하지 못하는 현실도 있습니다.

이에 본 기사에서는 **중소~중규모 조직에서도 도입하기 쉬운 “경량 제로 트러스트 분할 모델”**을 정리해 보았습니다.

모델의 목표 #

이 모델이 목표로 하는 것은 다음과 같은 상태입니다.

• ✅ 한 사람이 “모든 것을 알고·모든 것을 건드릴 수 있는” 상태를 없앤다

• ✅ 그래도 일상 운영은 지나치게 복잡해지지 않는다

• ✅ 긴급 상황에서도 제대로 대응할 수 있다(비상 대응도 고려)

“제로 트러스트”라고 하면 거창하게 들리지만
여기서는 “사람도 시스템도 필요한 것에만 접근하게 한다” 정도의 이미지로 OK입니다.

단계 1: 역할을 3개로 나누기(도메인 분할) #

우선 매우 간단하게
시스템을 3개의 도메인으로 나누어 생각하는 것부터 시작합니다.

A. 인프라 담당 #

• 가상 기반(VMware / Proxmox / Hyper-V 등)

• OS(Linux / Windows)

• 스토리지

• 기본 네트워크

• 백업 기반

B. 애플리케이션 담당 #

• Web / API 서버

• 미들웨어(nginx / Apache / Redis / MQ 등)

• 데이터베이스

• CI/CD 파이프라인

• 애플리케이션 설정·배포

C. 보안·인증 담당 #

• IAM / 계정 관리

• VPN / SSO / AD / LDAP

• 권한 설계

• 인증서·키 관리

• 로그·감사 기반

포인트:

동일인이 A + B + C 전체를 완전한 권한으로 장악하지 않도록 한다.

작은 조직이라도,

• 메인 담당 + 서브 담당

• 또는 “여기까지는 접근 가능하지만, 여기부터는 다른 사람에게 요청”

이라는 경계를 명문화해두는 것만으로도 리스크는 상당히 감소합니다.

스텝2: 권한 레벨을 “3단계만” 준비한다 #

제로 트러스트라고 하면, 세밀한 RBAC나 역할 설계를 떠올리기 쉽지만,
소규모 현장에서는 지나치게 복잡하면 파탄납니다.

그래서 오히려 3단계만으로 한정합니다.

D1. 운영자(운영 오퍼레이터) #

• 모니터링 및 로그 조회

• 서비스 재시작

• 간단한 설정 변경

• 절차서대로의 조작

D2. 유지보수 관리자(인프라/애플리케이션 관리) #

• VM 생성·삭제

• 스토리지 볼륨 추가

• 네트워크 설정 변경

• 미들웨어 업데이트·설정 변경

D3. 보안 관리자(IAM / 인증) #

• 계정 생성·삭제

• 역할·그룹 정의 변경

• 비밀번호 정책 변경

• VPN / 키 / 인증서 라이프사이클 관리

절대 규칙:

D2(유지보수 관리자)와 D3(보안 관리자)를
동일인이 “상시” 겸임하지 않도록 한다.

즉, “VM도 IAM도 무엇이든 할 수 있는 슈퍼 관리자”를 상시화하지 않는다.

인원상 어쩔 수 없이 겸임이 필요하다면,

• 평소에는 둘 중 하나만 활성화해두고

• 나머지는 긴급용 권한 상승 절차 + 로그와 함께 임시 사용

하는 형태를 권장합니다.

3단계: 작업 로그를 “제대로 남기는” 것만으로도 상당히 강력하다 #

완벽한 권한 설계를 하지 못하더라도,
“누가 언제 무엇을 했는지”를 추적할 수 있는 것만으로도 억제력과 안심감이 완전히 다릅니다.

예시 #

• 가상 기반: 감사 로그(Proxmox / vCenter의 Audit Log 등)

• OS: journalctl / auditd

• 네트워크 장비: syslog 집계

• IaC / Git: 커밋 로그·Pull Request

최소 기준:

1. 중요 컴포넌트는모두 어떤 형태로든 로그 출력을 활성화

2. 로그는 가능하면한 곳에 집중(syslog 서버나 로그 기반)

3. “누가·언제·어떤 계정으로·무엇을 했는지”를 알 수 있도록 구성

로그가 남는 것만으로도,
“함부로 행동하기 어려운 환경”이 자연스럽게 조성됩니다.

4단계: 자동화·IaC로 “사람의 머릿속”을 시스템으로 끌어내기 #

속인화의 큰 원인은,

“설정이나 구성이 그 사람의 머릿속에만 있다”

는 것입니다.

이를 깨는 가장 빠른 방법은 **자동화와 IaC(Infrastructure as Code)**입니다.

예시 #

• Terraform으로 클라우드/가상 기반의 구성 관리

• Ansible로 OS / 미들웨어 설정 공통화

• GitHub Actions / GitLab CI로 배포 표준화

• 쉘 스크립트도 좋으니수작업을 스크립트화

핵심은,

“사람이 직접 콘솔을 만지는 횟수를 줄여나간다”

는 방향성입니다.

5단계: 비밀 정보는 “사람”이 아닌 “시스템”에 맡기기 #

SSH 비밀 키, API 키, 비밀번호, 인증서——
이러한 정보를 개인의 로컬 PC나 개인 관리에 두지 않는 것이 중요합니다.

대표적인 방법 #

• 비밀번호 매니저(1Password, Bitwarden, KeePass 등)

• Secrets 관리 서비스(Vault, AWS Secrets Manager 등)

• Git에 평문으로 두지 않기(암호화/참조 ID화)

「누가 어떤 비밀에 액세스할 수 있는가」를 시스템 측 권한으로 제어함으로써,
개인에게 비밀이 연결되지 않는 구조를 목표로 합니다.

단계 6: 설계 문서도 「분할」해 두기 #

문서도 한 덩어리로 만들어버리면,
그것을 전부 이해하는 사람만 강해집니다.

따라서, 설계서도 역할별로 분할해 둡니다.

• 네트워크 설계서(인프라 담당 A가 관리)

• 서버 구성·역할 목록(인프라/앱 공통)

• 애플리케이션 구성서(앱 담당 B가 관리)

• 인증·IAM 설계서(보안 담당 C가 관리)

• 로그·감사 설계서(보안 담당 C)

「전부 혼자 작성하여, 한 사람만 이해하는 설계서」보다,
「여러 명이 작성하여, 역할별로 나뉜 설계서」가 더 건전합니다.

단계 7: 긴급 시를 위한 “2단계 모드”를 정해 두기 #

작은 조직일수록,
**「긴급 시에 아무도 아무것도 할 수 없어서 막히는」**패턴을 피할 필요가 있습니다.

따라서, 평시와 긴급 시로 규칙을 나눕니다.

평시 #

• 권한은 D1 / D2 / D3로 분리하여 운영

• 위험한 작업은 원칙적으로 D3만

긴급 시 #

• 예를 들어 「서비스 전면 중단」「중대 인시던트」 등의 조건을 정한다

• 리더 + 보안 담당 등 2명 이상의 합의로 일시적으로 권한 상승

• 복구 후에는 상승을 되돌리고, 작업 로그를 확인·검토

그렇게 함으로써,

「평소에는 분리된 상태」
「정말 필요할 때만, 제대로 흔적을 남기고 일시적으로 “신 모드”를 해제」

라는 균형을 잡을 수 있습니다.

정리: 「신 엔지니어 불필요」는 이상론이 아니라, 설계의 문제 #

본 기사에서 소개한 경량 모델을 정리하면, 다음과 같습니다.

1. 인프라 / 앱 / 보안의 3 도메인으로 역할을 분할한다

2. 권한을 3단계(운영 / 관리 / 보안)로 나누어 “항상・무엇이든 할 수 있는 사람”을 없앤다

3. 작업 로그를 제대로 남겨 “누가 무엇을 했는지”를 추적할 수 있는 상태로 만든다

4. 인프라・설정을 자동화/IaC화하여 “사람 머릿속”을 코드로 옮긴다

5. 비밀 정보는 사람이 아닌 시스템에 맡긴다

6. 설계서도 역할별로 분할하여 관리한다

7. 긴급 시에만 “2명 승인을 통해 신 모드 해제”하는 규칙을 정한다

이것들은 대형 클라우드나 금융 기관・SWIFT 등에서 사용되는 개념을
중소〜중규모 현장에서도 무리 없이 사용할 수 있도록 완화한 모델입니다.

마치며 #

“한 사람이 전부 알고 있는” 상태는
단기적으로는 매우 편리하지만
장기적으로는 비즈니스 연속성・보안・조직의 건전성 관점에서 큰 리스크가 됩니다.

반대로 말하면
조금씩이라도 “분할” “분리” “자동화”를 진행해 나가면
“신 엔지니어 전제 조직”에서 탈피할 수 있다는 의미이기도 합니다.

본 기사의 내용은 어디까지나 하나의 초안이므로
각 회사의 사정에 맞게 조정해 주시면 감사하겠습니다.