APAC 시스템을 위한 Linux 인프라 하드닝

대부분의 프로덕션 Linux 시스템은 누구도 인정하고 싶지 않은 만큼 기본 구성에 가깝게 돌아갑니다. 하드닝 문서는 존재합니다. 흔히 몇 년 전 감사를 위해 쓰였겠죠. 하지만 서버는 문서와 다릅니다. “문서화된 베이스라인"과 “실제 구성” 사이의 간극이 바로 공격자가 안정적으로 머무는 곳입니다.

Linux 하드닝은 그 간극을 메우는 규율이며, 다음 배포에서도 살아남는 방식으로 해내는 것입니다.

기본값은 출발점이지 태세가 아니다 #

기본 Linux 설치는 보안보다 호환성을 우선합니다. 쓰지 않는 서비스, 불필요한 커널 기능, 데스크톱에는 충족하지만 침해당한 프로덕션 호스트에는 부족한 로깅이 함께 옵니다. 하드닝은 범용 기계를 전용 기계로 바꾸는 과정입니다.

핵심 작업은 몇 가지 범주로 나뉩니다:

커널 및 sysctl 튜닝: 네트워크 보호(ICMP 리디렉션 무시, 소스 라우트 필터링 등), 파일시스템 제한, 주소 공간 배치 난수화 같은 메모리 보호.
서비스 최소화: 호스트가 실행하지 않는 것을 비활성화하고 제거해, 사용하지 않는 공격면을 남기지 않습니다.
강제 접근 통제: SELinux나 AppArmor로 프로세스가 침해당하더라도 할 수 있는 일을 제한합니다.
Systemd와 컨테이너 하드닝: capability drop, raw socket 차단, seccomp 프로파일로 syscall 제한.
감사와 로깅: 중요한 이벤트를 포착하고 호스트 밖으로 전송해 공격자가 자기 흔적을 지울 수 없게 합니다.

CIS Benchmarks가 이런 통제의 가장 실용적이고 폭넓게 인정된 성문화이며, OpenSCAP이 적용과 감사를 모두 자동화합니다.

코드로 된 구성, 아니면 존재하지 않는 것 #

위키에 있는 하드닝 가이드는 소망 목록입니다. 코드 속 하드닝(Ansible role, Packer 이미지, Kubernetes admission policy)은 사실입니다. 베이스라인이 코드가 되면 세 가지가 바뀝니다:

재현 가능합니다. 누군가 구성하는 걸 기억한 호스트가 아니라 모든 새 호스트가 베이스라인을 상속합니다.
테스트 가능합니다. 설정이 드리프트되면 CI의 컴플라이언스 스캔이 빌드를 실패시킵니다.
검토 가능합니다. 베이스라인 변경은 pull request이며, 애플리케이션 코드와 같은 리뷰 규율을 받습니다.

연례 행사로서의 하드닝과 플랫폼의 속성으로서의 하드닝의 차이입니다.

불변성이라는 종착역 #

논리적 결론은 불변 인프라입니다. 호스트와 컨테이너는 제자리에서 패치되지 않고 교체됩니다. 새 이미지를 빌드하고, 스캔하고, 배포합니다. 오래된 것은 파괴됩니다. 구성 드리프트는 불가능해집니다. 드리프트할 대상이 없기 때문입니다. 실행 중인 시스템은 빌드 산출물입니다.

불변 인프라는 코드형 하드닝과 자연스럽게 짝을 이룹니다. 베이스라인을 유지관리하는 게 아니라 보안을 이미지에 컴파일하는 것입니다. 취약점이 나타나면 수정은 자정의 SSH 세션이 아니라 재빌드입니다.

flowchart LR A[CIS benchmark 베이스라인 as code] --> B[CI에서 하드닝 이미지 빌드] B --> C[파이프라인 내 컴플라이언스 스캔] C -- 통과 --> D[배포 및 인스턴스 로테이션] C -- 실패 --> B style C stroke:#0EA5E9,stroke-width:2px style D stroke:#10B981,stroke-width:2px

호스트 너머 #

하드닝은 운영체제에서 멈추지 않습니다. 같은 규율이 여러 방향으로 뻗어 나가며, 각 방향마다 고유한 실패 양상이 있습니다.

컨테이너는 전부 물려받고, 자신만의 위험도 더합니다. 하드닝되지 않은 base layer에서 만든 컨테이너 이미지는 호스트 수준의 모든 약점을 이를 실행하는 모든 pod에 그대로 옮깁니다. 해결책은 상류에 있습니다: 최소화된 base image, CI에서의 스캔, read-only 파일시스템을 갖춘 non-root 실행, capabilities 제거, 그리고 워크로드가 실제 필요한 syscall로 한정하는 seccomp 프로파일 말입니다. 기본 seccomp 프로파일만으로도 상당 부분을 막습니다. 실제 관찰된 syscall 행동에 맞게 튜닝한 프로파일이 나머지를 막습니다. Kubernetes 어드미션 정책이 이 모든 것을 플릿 전체에서 강제하기 때문에, 기준 미달 배포는 아예 스케줄링되지 않습니다.

OT 환경은 판돈을 올립니다. 산업 및 운영기술(OT) 환경에서는 하드닝이 사무실 IT는 겪어보지 못한 방식으로 가용성과 충돌합니다. 건물관리시스템이나 생산라인 PLC 네트워크, 병원 장비 구간에 CIS 통제 항목 하나를 잘못 적용하면 finding이 나오는 게 아니라 다운타임이 발생하고, 때로는 인명 안전 문제로 이어집니다. 그래서 OT 하드닝은 순서를 뒤집습니다: 수동 모니터링과 자산 목록화가 먼저고, 변경은 롤백 계획과 함께 유지보수 창구에서 이루어지며, 통제 항목은 실제 환경을 만지기 전에 production 미러 위에서 파일럿합니다. IT는 “이 시스템이 안전한가?“라고 묻지만, OT는 “멈추지 않으면서 보호할 수 있는가?“를 물어야 합니다.

드리프트 감지가 고리를 닫습니다. 베이스라인은 일상적 변화로 쇠퇴합니다: 엔지니어가 디버깅하려 포트를 열고, 설치 프로그램이 서비스를 다시 켜고, 핫픽스가 코드로 돌아오지 않습니다. 감지가 없다면 오늘의 하드닝된 호스트는 내년의 물러진 호스트입니다. 효과적인 패턴: 매일 구성 스캔을 돌려 실제 호스트와 이미지를 코드화된 베이스라인과 비교하고, 결과를 분기 보고서에 묻어두지 않고 alert로 소유자에게 직접 라우팅하는 것입니다. 하루 안에 잡힌 드리프트는 티켓입니다. 일 년 뒤에 잡힌 드리프트는 사고 조사입니다.

과하게 관대한 클라우드 IAM 역할 뒤의 하드닝된 호스트, 스캔되지 않는 컨테이너 파이프라인 속의 하드닝된 호스트도 여전히 노출되어 있습니다. 가장 내구적인 태세는 호스트 베이스라인, 컨테이너 빌드 체인, 클라우드 구성, 신원 경계를 하나의 연속된 표면으로 다루고, 그렇게 모니터링하는 것입니다.

서버가 하드닝 문서와 실제로 일치하는지 확신이 서지 않으신가요? 부담 없이 현황 점검을 요청하세요. LINE(@PureSecurity) 또는 이메일(hello@puresecurity.com)로 연락 주시면 됩니다.

저희 Linux & 인프라 하드닝은 베이스라인을 코드로, 자동 드리프트 감지를 함께 전달하고, 구성 & 아키텍처 평가는 호스트 주변의 클라우드와 신원 계층을 검토합니다. 전체 그림이 필요하시면 엔지니어링 & 스코핑 세션을 예약하세요.