[보안] CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과

목차

• CIS 벤치마크 서버 보안, 쉽게 말하면 뭘까요?
• 현장에서 특히 많이 보는 점검 항목
• 제가 적용할 때 잡았던 기준: 한 번에 다 하지 않기
• 실전 구현 1: 현재 서버 설정과 계정 상태 점검
• 실전 구현 2: SSH와 계정 정책부터 우선 강화
• 1. root 직접 로그인 차단
• 2. 접속 허용 사용자 제한
• 3. 패스워드 정책 정리
• 실전 구현 3: 파일 권한과 감사 로그 보강
• 중요 파일 권한 조정
• sudo 로그 남기기
• 불필요 서비스 점검
• ⚠️ 실제로 겪었던 문제와 트러블슈팅
• 문제 1. SSH 설정 반영 후 접속 실패
• 문제 2. 보안 감사는 통과했는데 운영팀이 불편해함
• 문제 3. 자동화 스크립트가 갑자기 실패
• 검증과 결과: 무엇이 달라졌나
• 정리: 제가 배운 점과 다음 단계
• 자주 묻는 질문
• Q1. CIS 벤치마크 항목을 모두 적용해야 하나요?
• Q2. 기존 운영 서버에도 바로 적용해도 될까요?
• Q3. 보안 감사 대응에 실제 도움이 되나요?

CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과

서버를 오래 운영하다 보면 한 번쯤은 이런 순간이 옵니다. 서비스는 잘 돌아가는데, 막상 CIS 벤치마크 서버 보안 관점에서 보면 기본 설정이 생각보다 허술한 경우가 있거든요. 저도 홈랩(Home Lab, 개인 실험용 인프라 환경)과 업무 환경에서 Linux(리눅스) 서버를 같이 만지다 보니, "기능은 되는데 보안 감사(Security Audit, 보안 점검)에서 계속 걸리네?" 싶은 날이 있었습니다. 특히 계정 정책, SSH(Secure Shell, 원격 접속), 파일 권한, 로그 설정 같은 항목은 평소엔 문제 없어 보여도 실제 감사 시점에는 바로 드러나더라고요. 그래서 이번 글에서는 제가 직접 정리해서 적용했던 CIS 벤치마크 기반 서버 보안 강화 과정을 사례 중심으로 풀어보겠습니다.

이 글은 특정 제품 홍보가 아니라, 실제로 많이 부딪히는 Linux 보안 강화 흐름을 기준으로 적었습니다. 보안 감사 대응이 필요하신 분, 서버 설정을 체계적으로 정리하고 싶은 분, 그리고 "어디서부터 손대야 하지?" 막막하신 분께 특히 도움이 될 겁니다.

기본 서버에서 계정 정책, SSH 설정, 로그 수집, 감사 항목을 단계적으로 강화하는 전체 흐름을 보여주는 이미지입니다.

CIS 벤치마크 서버 보안, 쉽게 말하면 뭘까요?

CIS Benchmarks(CIS 벤치마크, Center for Internet Security에서 제공하는 보안 설정 권고안)는 운영체제와 소프트웨어를 보다 안전하게 설정하기 위한 기준 모음입니다. 쉽게 말해, "이 정도는 최소한 맞춰두면 보안 사고 가능성을 꽤 줄일 수 있습니다"라는 체크리스트에 가깝습니다.

처음엔 저도 이게 뭔가 싶었습니다. 문서를 보면 항목이 많고, 다 적용하면 서비스가 멈플 것 같아 겁부터 나거든요. 근데 실제로 써보니까 핵심은 단순합니다. 모든 항목을 기계적으로 넣는 게 아니라, 서비스 영향도를 보면서 우선순위를 나눠 적용하는 것이더라고요.

현장에서 특히 많이 보는 점검 항목

• 계정 및 인증(Authentication, 사용자 신원 확인): 패스워드 정책, 불필요한 계정 정리, sudo 권한 제한
• SSH 설정: root 직접 로그인 차단, 인증 방식 점검, 접속 가능한 사용자 제한
• 파일 권한(File Permission, 접근 권한): 중요한 설정 파일의 소유자와 권한 조정
• 로그와 감사(Auditing, 행위 기록 추적): auth 로그, sudo 로그, 변경 이력 보관
• 네트워크 최소화: 불필요한 포트와 서비스 비활성화

구분	적용 전	적용 후
계정 관리	오래된 계정 방치	불필요 계정 잠금 또는 제거
SSH 접속	기본값 위주 운영	root 로그인 차단, 접근 사용자 제한
로그 추적	기본 로그만 확인	감사 기준에 맞춰 로그 보강
설정 일관성	서버마다 편차 큼	표준 설정 베이스 확보

여기서 중요한 포인트! CIS 벤치마크 서버 보안은 만능 보안 솔루션이 아닙니다. 다만 서버 설정의 기준선을 맞춰주기 때문에, 보안 감사나 운영 안정성 측면에서 체감 효과가 꽤 큽니다.

제가 적용할 때 잡았던 기준: 한 번에 다 하지 않기

실전에서는 보통 신규 서버보다 기존 운영 서버가 더 문제입니다. 이미 서비스가 돌아가고 있으니 설정 하나 잘못 건드리면 장애로 이어질 수 있거든요. 저도 처음엔 의욕이 앞서서 SSH, PAM(Pluggable Authentication Modules, 인증 모듈), sysctl 커널 파라미터까지 한 번에 바꾸려다가 접속 정책 꼬여서 삽질 좀 했습니다 ㅎㅎ

그래서 이후부터는 아래 순서로 정리했습니다.

1. 현재 상태 수집
2. 위험도 높은 항목 우선 적용
3. 변경 전 백업
4. 적용 후 즉시 검증
5. 운영 표준 문서화

이 순서가 별거 아닌 것 같아도 진짜 중요합니다. 특히 보안 감사 대응에서는 "무엇을 바꿨는지"보다 "왜 이렇게 바꿨고, 어떻게 검증했는지"가 더 중요할 때가 많더라고요.

실전 구현 1: 현재 서버 설정과 계정 상태 점검

가장 먼저 한 일은 현황 파악이었습니다. 서버 설정을 바꾸기 전에 지금 어떤 계정이 있고, SSH가 어떻게 열려 있고, 권한이 어떤지 보는 거죠. 아래 명령어는 배포판에 크게 구애받지 않고 기본 점검에 쓸 수 있습니다.

# 접속 중인 사용자 확인
who

# 최근 로그인 이력 확인
last -a | head

# sudo 권한 그룹 확인
getent group sudo
getent group wheel

# root 원격 로그인 설정 확인
grep -Ei '^PermitRootLogin' /etc/ssh/sshd_config

# 패스워드 정책 관련 기본 설정 확인
grep -E 'PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE' /etc/login.defs

# 중요 파일 권한 확인
ls -l /etc/passwd /etc/shadow /etc/group /etc/ssh/sshd_config

제가 직접 해보니 여기서 이미 문제점이 꽤 보였습니다. 예전 작업용 계정이 남아 있거나, SSH 설정 파일에 주석만 있고 실설정은 애매한 경우도 있었고요. 이런 상태에서 바로 강화 설정부터 넣으면, 나중에 왜 접속이 막혔는지 추적이 어려워집니다.

계정 상태, SSH 설정, 파일 권한을 터미널에서 점검하는 실전 분위기의 이미지입니다.

실전 구현 2: SSH와 계정 정책부터 우선 강화

초기 단계에서는 영향도가 크지만 효과도 분명한 항목부터 만졌습니다. 제 경험상 SSH와 계정 정책만 정리해도 보안 감사 결과가 꽤 달라지더라고요.

1. root 직접 로그인 차단

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo vi /etc/ssh/sshd_config

PermitRootLogin no
PasswordAuthentication yes
X11Forwarding no
MaxAuthTries 4
ClientAliveInterval 300
ClientAliveCountMax 0

sudo sshd -t
sudo systemctl reload sshd

여기서 중요한 건 reload 전에 반드시 문법 검증입니다. 저도 예전에 오타 하나로 SSH 데몬이 reload 실패해서 콘솔로 붙었던 적이 있습니다. 원격 서버면 정말 식은땀 납니다.

2. 접속 허용 사용자 제한

# /etc/ssh/sshd_config 예시
AllowUsers adminuser deployuser

운영 서버는 접속 대상이 많을수록 관리가 어렵습니다. 그래서 관리 계정은 분리하고, 실제 접속이 필요한 사용자만 명시하는 편이 훨씬 낫더라고요.

3. 패스워드 정책 정리

sudo vi /etc/login.defs

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   7

환경에 따라 MFA(Multi-Factor Authentication, 다중 인증)나 키 기반 인증 위주로 운영하는 경우도 있겠지만, 기본 정책이 비어 있으면 보안 감사에서 자주 지적됩니다. 그래서 사용 여부와 별개로 기준은 잡아두는 편이 좋더라고요.

실전 구현 3: 파일 권한과 감사 로그 보강

그다음은 Linux 보안에서 기본 중의 기본인 파일 권한과 로그입니다. 평소엔 잘 눈에 안 띄는데, 사고 나면 가장 먼저 후회하는 부분이기도 하죠.

중요 파일 권한 조정

sudo chown root:root /etc/ssh/sshd_config
sudo chmod 600 /etc/ssh/sshd_config
sudo chown root:root /etc/shadow
sudo chmod 000 /etc/shadow
sudo chmod 644 /etc/passwd /etc/group

배포판 기본값과 다를 수 있으니 적용 전 확인은 필수입니다. 특히 자동화 도구나 이미지 템플릿이 이미 정책을 넣어둔 경우가 있어서, 무작정 덮어쓰면 오히려 표준에서 벗어날 수 있습니다.

sudo 로그 남기기

sudo visudo

Defaults logfile="/var/log/sudo.log"

이 설정은 나중에 보안 감사뿐 아니라 내부 추적에도 꽤 유용했습니다. 누가 언제 어떤 권한 명령을 쳤는지 보는 것만으로도 원인 파악 속도가 많이 달라지거든요.

불필요 서비스 점검

systemctl list-unit-files --type=service --state=enabled
ss -tulpen

여기서 안 쓰는 서비스가 떠 있으면 정리합니다. 예를 들어 테스트용으로 잠깐 열어둔 데몬이 계속 살아 있는 경우가 꽤 있습니다. 보안은 거창한 장비보다도 이런 기본 서버 설정 정리에서 차이가 납니다.

SSH 접근 제어와 sudo 로그 기록 흐름을 한눈에 보여주는 구성 다이어그램 이미지입니다.

⚠️ 실제로 겪었던 문제와 트러블슈팅

이 부분이 제일 중요할 수도 있습니다. 문서만 보면 다 간단해 보이는데, 실제 적용하면 꼭 한두 군데서 걸립니다.

문제 1. SSH 설정 반영 후 접속 실패

원인은 대부분 두 가지였습니다. 하나는 AllowUsers에 현재 운영 계정을 빼먹은 경우, 다른 하나는 sshd_config 오타였습니다.

• 해결 방법 1: 설정 변경 전 현재 세션은 유지한 상태에서 새 세션으로 접속 테스트
• 해결 방법 2: sshd -t로 문법 검증 후 reload
• 해결 방법 3: 가능하면 콘솔 접속 경로 확보 후 작업

문제 2. 보안 감사는 통과했는데 운영팀이 불편해함

이것도 많이 겪습니다. 정책은 강화됐는데 현업이 쓰기 불편하면 결국 예외 요청이 쌓이거든요. 그래서 저는 서버 역할별로 기준을 나눴습니다. 배치 서버, 운영 웹 서버, 점프 서버(Jump Server, 중간 접속용 서버)를 같은 기준으로 묶지 않았습니다.

서버 유형	강화 우선 항목	주의점
운영 웹 서버	SSH 제한, 로그 강화, 불필요 서비스 제거	배포 계정 접근 경로 확인
점프 서버	계정 감사, sudo 로그, 접속 기록 보관	관리자 편의성과 통제 균형
배치 서버	계정 만료 정책, 스크립트 권한 점검	자동 실행 계정 영향 확인

문제 3. 자동화 스크립트가 갑자기 실패

패스워드 정책이나 파일 권한을 강화하고 나면 기존 스크립트가 가정하고 있던 조건이 깨질 수 있습니다. 저도 키 파일 권한을 조정한 뒤 일부 배포 스크립트가 실패한 적이 있었는데, 원인을 찾고 보니 권한 검사가 더 엄격해졌더라고요. 드디어 됐다 싶다가 다시 되돌아가서 확인하는 과정, 다들 한 번쯤 있으시죠.

검증과 결과: 무엇이 달라졌나

설정 적용 후에는 꼭 검증을 했습니다. 그냥 파일만 바뀌었다고 끝내면 안 됩니다. 실제 접속, 권한, 로그, 서비스 상태를 같이 봐야 하거든요.

# SSH 설정 최종 확인
sshd -T | egrep 'permitrootlogin|maxauthtries|clientaliveinterval|clientalivecountmax'

# sudo 로그 확인
sudo tail -n 20 /var/log/sudo.log

# 열려 있는 포트 점검
ss -tulpen

# 최근 인증 로그 확인
sudo tail -n 50 /var/log/auth.log

검증 단계에서 제가 체감한 효과는 크게 네 가지였습니다.

1. 보안 감사 대응 속도 향상: 항목별 근거를 바로 제시하기 쉬워졌습니다.
2. 설정 표준화: 서버마다 제각각이던 서버 설정이 어느 정도 정리됐습니다.
3. 추적성 확보: sudo와 인증 로그가 정리되니 사고 분석이 편해졌습니다.
4. 운영 리스크 감소: root 직접 로그인 같은 명백한 위험 요소를 줄였습니다.

물론 한 번 적용했다고 끝은 아닙니다. 하지만 CIS 벤치마크 서버 보안 기준으로 최소선만 맞춰도, 평소 불안하게 남아 있던 부분이 꽤 정리됩니다. 특히 보안 감사 준비할 때 체감 차이가 큽니다.

적용 전후 점검 항목과 로그 확인 결과를 시각적으로 보여주는 대시보드 형태의 이미지입니다.

정리: 제가 배운 점과 다음 단계

이번 적용에서 다시 느낀 건, 보안은 대단한 도구보다도 기본을 얼마나 꾸준히 맞추느냐가 훨씬 중요하다는 점이었습니다. Linux 보안 강화는 막연히 어렵게 느껴지지만, 실제로는 계정 정책, SSH, 권한, 로그처럼 반복해서 나오는 핵심 축이 있습니다. 저도 처음엔 항목이 많아서 겁먹었는데, 하나씩 잘라서 적용하니 생각보다 정리가 되더라고요.

혹시 지금 운영 중인 서버가 있고, 보안 감사 일정이 다가오고 있다면 이렇게 시작해보세요.

1. 현재 계정과 SSH 설정부터 점검합니다.
2. root 로그인 차단과 접근 사용자 제한을 우선 적용합니다.
3. 중요 파일 권한과 로그 기록을 보강합니다.
4. 변경 직후 검증 명령으로 바로 확인합니다.
5. 서버 역할별 예외 정책을 문서화합니다.

이 흐름만 잡혀도 서버 설정 품질이 눈에 띄게 좋아집니다. 다음 글에서는 Ansible(앤서블, 자동화 도구) 같은 구성 관리 방식으로 이 작업을 반복 가능하게 만드는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 관리나 계정 표준화 주제와도 연결해서 보시면 더 이해가 쉬우실 거예요.

적용 전후 차이, 핵심 점검 항목, 다음 단계 체크리스트를 요약한 인포그래픽 이미지입니다.

자주 묻는 질문

Q1. CIS 벤치마크 항목을 모두 적용해야 하나요?

아닙니다. 서비스 특성과 운영 환경에 따라 예외가 생길 수 있습니다. 중요한 건 근거 없이 빼는 게 아니라, 왜 제외했는지 설명 가능해야 한다는 점입니다.

Q2. 기존 운영 서버에도 바로 적용해도 될까요?

가능은 하지만, 반드시 백업과 검증 경로를 확보한 뒤 단계적으로 적용하는 걸 권장합니다. 특히 원격 접속 정책은 새 세션으로 꼭 테스트해보세요.

Q3. 보안 감사 대응에 실제 도움이 되나요?

네, 꽤 도움이 됩니다. 적어도 계정 정책, 접근 통제, 로그 추적성 같은 기본 항목에서 설명이 훨씬 쉬워집니다. 저도 실제로 써보니까 이 부분이 가장 체감되더라고요.

📚 함께 읽으면 좋은 글

• HashiCorp Vault, 1년 사용 후기: 보안 강화와 운영 효율성 회고
• 중소기업 Wazuh 도입 1년 회고: SIEM 구축 성공과 실패 사례
• OAuth 2.0 보안 허점 파헤치기: 실제 공격 사례와 방어 전략
• 2026년 중급 게이밍 GPU 벤치마크: RTX 4060 vs RX 7600 가성비 비교
• Knative 성능 벤치마크, 실제 트래픽 증가에 따른 서빙 체크 포인트