네이버 인프라팀에 있을 때나 AWS EC2 코어 팀에 있을 때나, 언제나 똑같은 유형의 '열정적인' 주니어를 만납니다. 보안 규정을 준수하겠다며 밤새워 수백 줄짜리 쉘 스크립트를 짜는 친구들 말이죠. 리눅스 커널 파라미터를 건드리고, SSH 설정을 한 줄 한 줄 sed 명령어로 고치는 걸 보며 그들은 뿌듯해합니다.
하지만 저는 그 모습을 볼 때마다 등골이 서늘합니다. 6개월 뒤, 그 스크립트를 짠 사람이 퇴사하고 나면 그 거대한 '레거시 덩어리'는 고스란히 제 몫이 되기 때문입니다. 그리고 높은 확률로, 그 스크립트는 어느 금요일 밤 OS 버전 업데이트와 충돌하며 전체 시스템을 마비시킵니다.
시스템 가용성 99.999%를 지키려다 제 수명의 가용성을 깎아먹은 경험으로 조언합니다. 바퀴를 다시 발명하지 마세요. 특히 보안(Security) 영역에서는 더욱 그렇습니다. 오늘은 당신의 칼퇴근과 정신 건강을 지켜줄 검증된 도구, dev-sec/ansible-collection-hardening을 소개합니다.
왜 '수동 하드닝'이 자살행위인가
서버 보안 설정, 즉 하드닝(Hardening)은 단순히 방화벽 하나 켜는 수준이 아닙니다. CIS 벤치마크 같은 보안 규정집은 수백 페이지에 달합니다. 이걸 사람이 일일이 적용한다? 불가능합니다.
1. 파편화된 OS 환경:
Ubuntu 20.04에서 잘 돌아가던 스크립트가 Rocky Linux 9에서는 에러를 뱉습니다. sysctl 파라미터 이름이 바뀌거나, 패키지 매니저가 다르기 때문입니다.
2. 관리의 지속성 부재: Nginx 버전이 올라가면서 보안 옵션이 바뀌었습니다. 수동으로 설정한 서버 100대를 언제 다 확인하시겠습니까?
3. 휴먼 에러:
sshd_config 파일에서 오타 하나 내서 원격 접속이 막혀보신 분들은 아실 겁니다. 데이터센터로 직접 뛰어가야 하는 그 공포를요.
정답은 'DevSec Hardening Framework'
실리콘밸리에서 엔지니어들이 밥 먹듯 쓰는 말이 있습니다. "Don't Roll Your Own Crypto(암호화 기술 직접 만들지 마라)." 하드닝도 마찬가지입니다. 이미 전 세계 수천 명의 엔지니어들이 검증하고, 별(Star) 4,700개를 받은 Ansible 컬렉션이 있습니다.
GitHub의 dev-sec/ansible-collection-hardening 리포지토리는 다음과 같은 핵심 컴포넌트들을 자동으로, 그리고 안전하게 잠가줍니다.
- OS Hardening: 리눅스 커널 파라미터 최적화, 불필요한 패키지 제거, 파일 권한 설정.
- SSH Hardening: 취약한 암호화 알고리즘 비활성화, 루트 로그인 차단, 아이들(Idle) 타임아웃 설정.
- Nginx Hardening: 버퍼 오버플로우 방지, 헤더 숨김, SSL/TLS 최신 프로토콜 강제.
- MySQL/MariaDB Hardening: 익명 사용자 제거, 테스트 DB 삭제, 안전한 패스워드 정책 수립.
어떻게 사용하는가 (ft. Ansible)
이 도구의 핵심은 Ansible입니다. 쉘 스크립트처럼 명령을 나열하는 게 아니라, "이 서버는 이런 상태여야 한다"고 선언(Declarative)하는 방식입니다.
1. 설치 간단합니다. 앤서블 갤럭시(Ansible Galaxy)를 통해 컬렉션을 내려받으십시오.
ansible-galaxy collection install devsec.hardening
2. 플레이북 작성 복잡한 로직은 필요 없습니다. 그저 역할을 불러오기만 하면 됩니다. 다음은 제가 실제 현업에서 베이스라인으로 사용하는 구성의 예시입니다.
- hosts: all
roles:
- devsec.hardening.os_hardening
- devsec.hardening.ssh_hardening
- devsec.hardening.nginx_hardening이렇게만 작성해두면, 이 플레이북이 실행될 때마다 수백 가지의 보안 체크리스트가 자동으로 적용됩니다. 이미 설정되어 있다면 건너뛰고, 벗어난 설정이 있다면 다시 원복 시킵니다. 이것이 바로 멱등성(Idempotency)의 힘입니다. 새벽 3시에 장애 복구하면서 스크립트 꼬일 걱정을 할 필요가 없다는 뜻입니다.
이 도구가 특별한 이유
단순히 설정을 바꾸는 게 아닙니다. 이 컬렉션은 Inspec DevSec Baseline을 준수합니다.
보안 감사를 받아보신 분들은 아실 겁니다. "이 서버가 규정을 준수하는지 증명하라"는 요구를 받으면 막막해집니다. 이 Ansible 컬렉션은 애초에 Inspec이라는 자동화된 보안 감사 도구의 기준에 맞춰 개발되었습니다. 즉, 하드닝을 적용하고 Inspec을 돌리면 바로 'Pass'가 뜬다는 이야기입니다. 감사 대응을 위해 엑셀 파일을 만들던 시간을 아껴서 잠을 더 잘 수 있습니다.
지원하는 OS 범위도 넓습니다. Debian, Ubuntu, CentOS Stream, AlmaLinux, Rocky Linux는 물론이고 심지어 Amazon Linux까지 커버합니다. AWS 환경에서 작업하는 저 같은 사람에게는 필수품이나 다름없습니다.
뼈 때리는 조언
솔직히 말해봅시다. 여러분이 아무리 뛰어난 엔지니어라도, 전 세계 수백 명의 오픈소스 기여자들이 실시간으로 업데이트하는 보안 트렌드를 혼자서 따라잡을 순 없습니다.
어설픈 완벽주의를 버리십시오. 보안은 '내가 얼마나 고생했는지'를 보여주는 영역이 아닙니다. '얼마나 실수 없이 표준을 지켰는지'가 중요한 영역입니다.
여러분의 "열정"은 비즈니스 로직을 짜거나, 더 효율적인 아키텍처를 고민하는 데 쓰세요. 리눅스 파일 권한 설정 따위는 기계와 집단지성에 맡기십시오. 그래야 시스템도 살고, 여러분의 주말도 삽니다.
기억하세요. 최고의 보안 전문가는 밤새워 로그를 보는 사람이 아니라, 애초에 로그 볼 일을 만들지 않는 사람입니다.
