73. 서버/OS/DB 패치 및 취약점 스캐닝 내역 감리

⚠️ 이 문서는 아무리 비싸고 화려한 앱 코드를 개발했더라도, 그 밑을 받치고 있는 뼈대인 서버 하드웨어, 리눅스 운영체제, 상용 데이터베이스, 웹 서버(Apache 등) 자체에 이미 세상에 알려진 낡고 치명적인 보안 구멍(CVE)이 방치되어 해커의 먹잇감이 되는 것을 막기 위해, 최신 보안 패치(Patch)가 제대로 적용되었는지 자동화 툴과 보고서로 샅샅이 검증하는 인프라 보안 감리 지침을 다룹니다.

핵심 인사이트 (3줄 요약)

1. 본질: 집(앱) 문단속은 철저히 했는데, 집을 받치고 있는 땅의 싱크홀(OS 취약점)을 메웠는지 묻는 것이다. 제로데이(0-day)가 아닌 '이미 널리 알려져 패치까지 나온 옛날 취약점(N-day)'에 당하는 한심한 인프라 사고를 원천 봉쇄한다.
2. 가치: 대형 사이버 공격(워너크라이 랜섬웨어, 로그포제이(Log4j) 사태)의 99%는 이 귀찮은 인프라/OS 패치 작업을 게을리한 서버들의 열려있는 포트를 타고 들어와 회사 전체를 잿더미로 만든다. 감리는 이 게으름을 몽둥이로 때려잡는 과정이다.
3. 기술 체계: 감리인은 시스템 오픈 전에 취약점 스캐닝 자동화 도구(Nessus, OpenVAS, 상용 CCE 진단 도구)를 돌려 나온 붉은색 결과 보고서를 검토하고, "발견된 취약점 수 = 조치 완료 수"라는 완벽한 제로 결함 증빙을 강제로 요구한다.

Ⅰ. 뼈대의 붕괴: 인프라 취약점의 무서움

앱 코드가 완벽해도, 리눅스 커널이 털리면 루트 권한을 통째로 내주게 된다.

1. CVE (Common Vulnerabilities and Exposures):
   • 전 세계 보안 전문가들이 발견한 수만 개의 소프트웨어 버그/취약점 목록표다. 해커들은 이 목록을 매일 쳐다보며 최신 무기를 만든다.
   • 예: CVE-2021-44228 (Log4j)는 자바 로깅 라이브러리의 취약점으로, 이를 찔러보기만 하면 해커가 남의 서버에 명령어를 마음대로 실행할 수 있었다.
2. N-Day 취약점의 방치 (안전 불감증):
   • 벤더(레드햇, 오라클, 아파치 등)는 취약점이 발견되면 즉시 구멍을 메우는 '보안 패치(업데이트)'를 배포한다.
   • 하지만 운영팀은 "서버 패치하다가 껐다 켜면 잘 돌아가던 앱이 충돌 날까 봐 무섭다"며 패치를 수년씩 미루고 옛날 버전을 그대로 쓴다. (최악의 직무 유기)
3. 포트 스캐닝과 웜(Worm)의 융단폭격:
   • 해커는 봇(Bot)을 돌려 전 세계 IP의 22번(SSH), 3389번(RDP) 포트를 찔러보며 구형 버전 배너(예: OpenSSH 6.0)가 뜨는 서버만 자동 수집한 뒤 준비된 해킹 툴을 원클릭으로 쏴서 1초 만에 서버를 점령한다.

📢 섹션 요약 비유: 현관문 자물쇠(앱 로그인 로직)는 최신 안면 인식기로 달아놨는데, 정작 집을 지은 시멘트 벽돌(리눅스 OS)이 불량이라 발로 차면 벽이 와르르 무너지는 끔찍한 상태입니다. 구청(제조사)에서 "불량 시멘트를 무료로 교체(패치)해 줄 테니 시공받으세요"라고 공문을 수백 번 보냈는데도, 귀찮다고 방치하다가 도둑이 벽을 차고 들어와 다 털리는 참사입니다.

Ⅱ. 감리 점검: 취약점 스캐닝 (Vulnerability Scanning) 도구 가동

눈으로 버전 번호를 대조하는 것은 불가능하므로 기계의 힘을 빌린다.

1. 인프라/OS 진단 (CCE 점검):
   • 감리인은 시스템 납품 전, 주요정보통신기반시설 취약점 진단 가이드 등 국가 표준에 따라 스크립트 기반 진단(Unix/Windows 점검 스크립트)을 돌린다.
   • 주요 적발 사례: "root 계정 원격 접속(SSH) 허용 차단 안 됨", "비밀번호 틀릴 시 계정 잠금 세팅 횟수 누락", "불필요한 FTP, Telnet 포트 열려 있음".
2. 네트워크 및 패키지 취약점 진단 (CVE 스캔):
   • Nessus나 Nexpose 같은 스캐닝 툴에 대상 서버 IP 대역을 넣고 스캔을 때린다.
   • 툴은 "현재 이 서버의 Apache Tomcat 버전이 8.5.11인데, 이 버전은 10개의 치명적(Critical) 취약점이 있습니다. 당장 8.5.50 이상으로 업데이트하세요"라는 빨간색 리포트를 수십 장 토해낸다.
3. 데이터베이스(DB) 하드닝 점검:
   • 기본 관리자 패스워드(sa/sa, scott/tiger)가 그대로 남아있는지, 오라클 TNS Listener 구버전 취약점이 있는지 스캔하여 색출한다.

📢 섹션 요약 비유: 건물 준공 허가(감리)를 내주기 전에 소방 점검관이 출동합니다. 사람의 눈으로 대충 보는 게 아니라, 열화상 카메라와 자동 진단 로봇(스캐너 툴)을 건물 전체에 돌려 "3층 화재경보기 고장", "지하 1층 스프링클러 미설치"라는 기계적인 엑스레이 리포트를 뽑아내어 시공사에게 들이미는 냉혹한 과학 수사입니다.

Ⅲ. 감리 조치 요구사항: "100% 조치 완료 및 예외 사유서"

리포트가 빨간색으로 물들었으면, 파란색이 될 때까지 돌려야 한다.

1. 조치 결과 보고서 (Remediation Report) 제출 강제:
   • 감리인은 스캐닝 도구에서 나온 High(고위험) 및 Critical(치명적) 등급의 취약점은 단 1개도 남김없이 100% 패치 및 조치가 완료되었다는 '2차 진단 결과서'를 요구한다. 이거 안 내면 시스템 오픈 도장(감리 완료)을 안 찍어준다.
2. 불가피한 미조치 예외 처리 (Exception Handling):
   • 개발사가 "서버 OS를 최신으로 패치하면, 고객사가 꼭 써야 하는 옛날 엑티브X(ActiveX) 연동 모듈이 죽어버려서 절대 패치 못 합니다!"라고 항변할 때가 있다.
   • 감리인은 이를 묵인하지 않고, **[취약점 예외 처리 승인서]**를 쓰게 한다.
   • "패치를 못 하는 대신, 그 서버의 포트를 방화벽에서 특정 IP로만 막아두고(보완 통제, Compensating Control), 이 취약점에 대한 리스크는 우리가 책임지겠다"는 발주사 보안 책임자의 도장(서명)이 찍힌 문서가 있어야만 예외로 넘겨준다.

📢 섹션 요약 비유: 소방 점검에서 지적된 사항을 시공사(개발팀)가 100% 완벽하게 수리하고 재검사(2차 스캐닝)를 받아야 건물 문을 엽니다. 만약 "오래된 한옥이라 스프링클러를 달면 지붕이 무너진다"고 항변하면, 소방관(감리인)은 그냥 봐주는 게 아니라 "그럼 그 방 옆에 24시간 경비원을 세워두고 화재 시 주인이 책임지겠다(보완 통제 및 예외 승인)"는 각서를 받아내어 철저히 책임을 남깁니다.