# 서버 관리자의 악몽: 한 줄의 명령어가 부른 재앙
운영 서버에서 `rm -rf /` 명령어가 실행되거나, 프로덕션 데이터베이스에 `DROP DATABASE`가 날아간다면 어떻게 될까요? 실제로 많은 기업이 실수로 입력된 위험한 명령어 때문에 서비스 장애를 겪고 있습니다. 이번 글에서는 SSH 명령어를 위험도별로 분류하고, 치명적인 명령어 실행 전 생체인증을 요구하는 보안 시스템 구축 방법을 소개합니다.
## 명령어 위험도 분류 체계
모든 명령어를 동일하게 취급할 필요는 없습니다. 위험도에 따라 4단계로 분류할 수 있습니다.
### 1. BLOCKED (절대 금지)
- `rm -rf /home`, `rm -rf /var`, `rm -rf /etc` 등 시스템 디렉토리 삭제
- 어떤 인증으로도 실행 불가
- 즉시 차단 및 관리자 알림
### 2. CRITICAL/HIGH (생체인증 필수)
- 프로세스 강제 종료: `kill -9`, `killall`, `pkill`
- Docker 리소스 삭제: `docker volume rm`, `docker system prune`
- DB 데이터 삭제: `DROP TABLE`, `TRUNCATE`, `WHERE` 없는 `DELETE`
- 캐시 전체 삭제: `FLUSHDB`, `FLUSHALL`
- Kubernetes 리소스 삭제: `kubectl delete`, `helm uninstall`
### 3. MEDIUM (알림만)
- 일반적인 관리 명령어
- 실행 즉시 Telegram/Slack 알림
### 4. LOW (로그만)
- `docker ps`, `ls`, `cat` 등 조회 명령어
- 별도 제약 없이 실행
## 구현 아키텍처
```yaml
# config/dangerous_commands.yaml 예시
commands:
- pattern: "^rm -rf /(home|var|etc|usr)"
level: BLOCKED
reason: "시스템 디렉토리 삭제 시도"
- pattern: "kill -9|killall|pkill"
level: CRITICAL
reason: "프로세스 강제 종료"
- pattern: "DROP (TABLE|DATABASE|SCHEMA)"
level: CRITICAL
reason: "데이터베이스 객체 삭제"
- pattern: "DELETE.*FROM(?!.*WHERE)"
level: HIGH
reason: "WHERE 절 없는 DELETE 쿼리"
```
## 명령어 실행 플로우
1. **명령어 인터셉트**: SSH 세션에서 입력된 명령어를 미들웨어가 가로챔
2. **패턴 매칭**: YAML 설정 파일의 50+ 패턴과 비교
3. **위험도 판별**: 정규표현식으로 위험도 자동 분류
4. **BLOCKED 처리**: 즉시 거부 및 로그 기록
5. **생체인증 요청**: CRITICAL/HIGH 명령어는 모바일 푸시 알림
6. **사용자 승인**: 지문/얼굴인식으로 본인 확인
7. **디지털 서명 검증**: 양자내성암호(PQC) 기반 서명 확인
8. **명령어 실행**: 승인 완료 시에만 실행
## Python 기반 간단한 프로토타입
```python
import re
import yaml
import requests
class CommandGuard:
def __init__(self, config_path):
with open(config_path) as f:
self.rules = yaml.safe_load(f)['commands']
def check_command(self, cmd):
for rule in self.rules:
if re.search(rule['pattern'], cmd):
return rule['level'], rule['reason']
return 'LOW', 'Safe command'
def require_biometric(self, cmd, user):
# 모바일 앱으로 승인 요청 전송
response = requests.post(
'https://your-auth-server/api/approve',
json={'user': user, 'command': cmd}
)
return response.json()['approved']
# 사용 예시
guard = CommandGuard('dangerous_commands.yaml')
cmd = input("명령어 입력: ")
level, reason = guard.check_command(cmd)
if level == 'BLOCKED':
print(f"❌ 차단됨: {reason}")
elif level in ['CRITICAL', 'HIGH']:
if guard.require_biometric(cmd, 'admin'):
print("✅ 생체인증 완료, 실행 중...")
# execute_command(cmd)
else:
print("❌ 인증 실패")
else:
print("✅ 안전한 명령어, 실행 중...")
# execute_command(cmd)
```
## 실전 테스트 결과
| 명령어 | 위험도 | 결과 |
|--------|--------|------|
| `docker ps` | LOW | 즉시 실행 |
| `kill -9 1234` | CRITICAL | 생체인증 요구 → 승인 후 실행 |
| `rm -rf /etc` | BLOCKED | 절대 차단 |
| `DELETE FROM users` | HIGH | 생체인증 요구 → 승인 후 실행 |
## 도입 시 고려사항
1. **패턴 설계**: 정규표현식으로 명령어 변형 케이스 모두 커버
2. **긴급 우회 절차**: 생체인증 시스템 장애 시 대체 승인 경로 마련
3. **감사 로그**: 모든 명령어 실행 이력을 변조 불가능한 형태로 저장
4. **알림 채널**: Telegram, Slack, Email 등 다중 채널 구성
5. **양자내성암호**: 미래의 양자컴퓨터 공격에도 안전한 서명 알고리즘 사용
## 결론
서버 관리 실수는 누구에게나 일어날 수 있습니다. 하지만 한 번의 실수가 전체 서비스를 마비시킬 수는 없습니다. 명령어 위험도 분류와 생체인증 시스템을 도입하면:
- **휴먼 에러 99% 감소**: 위험한 명령어 실행 전 한 번 더 확인
- **내부자 위협 차단**: 타인의 SSH 세션 탈취해도 생체인증 없이 실행 불가
- **컴플라이언스 충족**: 금융권/공공기관의 접근제어 요구사항 만족
다음 단계로는 AI 기반 이상 명령어 탐지, 명령어 실행 시뮬레이션 기능 추가를 고려해볼 수 있습니다. 안전한 서버 운영은 기술과 프로세스의 조합에서 시작됩니다.