왜 별도의 보안 소프트웨어가 필요한가

09편에서 로그와 백업으로 “사고가 난 뒤” 대응하는 방법을 다뤘습니다. 하지만 이상적으로는 사고가 나기 전에 취약점을 찾아 막고, 사고가 나는 순간 즉시 알아채야 합니다. 운영체제 기본 기능만으로는 이 두 가지가 충분하지 않습니다.

• 리눅스의 sudo, 윈도우의 그룹 정책만으로는 관리자 여러 명의 서버 접속 자체를 통합 통제하기 어렵습니다
• ps, netstat 같은 기본 명령으로는 수백 대 서버의 알려진 취약점을 체계적으로 스캔할 수 없습니다
• 파일이 몰래 바뀌었는지는 사람이 매번 손으로 대조할 수 없습니다

그래서 이 세 가지 공백을 메우는 전용 소프트웨어 범주가 시험 출제기준의 “서버 보안 S/W 설치 및 운영” 항목입니다.

쉽게 말하면: 운영체제가 기본으로 주는 자물쇠 말고, 누가 언제 어떻게 문을 열었는지 기록하고, 문에 뚫린 구멍을 미리 찾아주는 전용 장비를 들이는 단계입니다.

1. 서버 접근통제 시스템 — SAC

서버 접근통제 시스템(SAC, Server Access Control)은 여러 서버에 대한 관리자 접속을 하나의 지점으로 모아 통제하는 솔루션입니다. 흔히 PAM(Privileged Access Management, 권한 있는 접근 관리)이라는 더 넓은 범주 안에 포함됩니다.

왜 필요한가

관리자 100명이 서버 50대에 각자 SSH로 직접 접속한다고 합시다. 각 서버의 /etc/passwd와 sudoers를 관리자가 바뀔 때마다 50번씩 손으로 고쳐야 하고, “누가 3주 전에 이 서버에서 무슨 명령을 쳤는지”를 알아내려면 50대의 auth.log를 일일이 뒤져야 합니다. SAC는 이 문제를 다음 구조로 해결합니다.

핵심 기능

시험 포인트: SAC는 접근통제를 “개별 서버 단위”에서 “중앙 집중 단위”로 옮기는 것이 핵심입니다. 22편에서 다룰 최소권한 원칙과 직무분리가 SAC를 통해 실제로 강제되는 대표적인 사례로 함께 출제됩니다.

2. 취약점 점검 도구 — OpenVAS·Nessus 계열

CVE와 CVSS

취약점을 다루려면 먼저 취약점을 부르는 방법이 통일돼 있어야 합니다.

• CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출): 전 세계에서 발견된 개별 취약점에 부여하는 고유 식별번호입니다. 예를 들어 CVE-2021-44228은 Log4Shell로 알려진 Log4j 취약점을 가리킵니다.
• CVSS(Common Vulnerability Scoring System, 공통 취약점 등급 시스템): 각 취약점의 심각도를 0.0부터 10.0까지 점수로 매기는 표준입니다. 공격 벡터(네트워크로 가능한지), 공격 복잡도, 필요 권한, 사용자 상호작용 여부 등을 조합해 계산합니다.

스캔 절차

OpenVAS(오픈소스, 현재는 Greenbone Vulnerability Management의 일부)와 상용 제품 Nessus는 사용법이 크게 다르지 않습니다. 공통 절차는 다음과 같습니다.

# CLI 기반 대안 예: nmap의 취약점 스크립트를 활용한 간이 점검
nmap -sV --script vuln 192.168.10.20

인증 스캔과 비인증 스캔의 차이가 시험 포인트입니다. 비인증 스캔은 외부 공격자의 시야와 비슷해 “밖에서 무엇이 보이는가”를 알려주지만, 패치 누락처럼 내부에 로그인해야만 알 수 있는 정보는 못 잡습니다. 인증 스캔은 실제 관리자 시야로 더 정확하지만, 계정 정보를 스캐너에 등록해야 하므로 그 자체가 관리 대상이 됩니다.

3. 무결성·로깅 도구 설치와 운영

파일 무결성 점검 도구 — AIDE 실습

07편에서 파일 무결성 점검 도구(Tripwire·AIDE)의 원리를 다뤘습니다. 여기서는 실제 설치·운영 절차를 봅니다. AIDE(Advanced Intrusion Detection Environment)는 지정한 경로의 파일 해시값·권한·소유자 등을 데이터베이스로 만들어 두고, 이후 실제 상태와 비교해 변경을 탐지합니다.

# 설치 (데비안 계열)
sudo apt install aide
 
# /etc/aide/aide.conf 에서 감시 대상 경로 지정 예시
# /etc/aide/aide.conf 발췌
/bin    NORMAL
/sbin   NORMAL
/etc    NORMAL
 
# 최초 기준 데이터베이스 생성
sudo aideinit
 
# 이후 정기 점검 (cron 등록해 매일 새벽 실행)
sudo aide --check

aide --check를 실행하면 기준 데이터베이스와 현재 상태를 비교해 추가(added)·삭제(removed)·변경(changed)된 파일 목록을 출력합니다. 핵심 함정: 기준 데이터베이스 자체가 공격자에게 변조되면 무결성 점검이 무의미해지므로, 기준 데이터베이스는 반드시 읽기 전용 매체나 외부 저장소에 별도 보관해야 합니다.

호스트 기반 통합 로깅·탐지 도구

OSSEC과 그 후속 오픈소스인 Wazuh는 파일 무결성 점검, 로그 분석, 루트킷 탐지, 실시간 경보를 하나로 묶은 HIDS(Host-based Intrusion Detection System, 호스트 기반 침입탐지시스템)입니다. 09편의 SIEM이 여러 서버의 로그를 중앙에서 상관분석하는 도구라면, HIDS 에이전트는 각 서버에 상주하며 그 서버 자체의 파일 변경·프로세스·로그를 감시하고 결과를 중앙 서버로 올려보내는 역할을 합니다. 즉 HIDS는 SIEM의 데이터 소스 중 하나로 자주 함께 구성됩니다.

4. 정기 점검 체크리스트

취약점 점검과 무결성 점검은 한 번 하고 끝나는 일이 아니라 주기적으로 반복해야 의미가 있습니다. 실무에서 흔히 쓰는 점검 주기는 다음과 같습니다.

시험 함정: “취약점 스캔을 한 번만 하면 충분하다”거나 “무결성 점검 도구를 설치하면 별도 점검 주기가 필요 없다”는 서술은 모두 오답입니다. 도구는 자동화 수단일 뿐, 점검 자체는 정책으로 주기를 못박아 반복해야 합니다.

핵심 정리

• SAC는 여러 서버에 대한 관리자 접속을 중앙 게이트웨이로 모아 계정 통합관리·명령어 필터링·세션 녹화를 제공해, 접근통제를 서버 단위에서 중앙 집중 단위로 옮긴다.
• CVE는 취약점의 고유 식별번호, CVSS는 0.0에서 10.0까지의 심각도 점수 체계다.
• 취약점 점검은 대상 등록 → 정책 선택 → (인증 정보 입력) → 스캔 → 리포트 → 재점검 순서로 진행되며, 인증 스캔이 비인증 스캔보다 내부 패치 누락까지 정확히 잡아낸다.
• AIDE 같은 무결성 점검 도구는 최초 기준 데이터베이스를 만들고 이후 --check로 비교하며, 기준 데이터베이스 자체를 외부에 안전하게 보관해야 한다.
• HIDS(OSSEC·Wazuh)는 서버에 상주하며 파일·로그·프로세스를 감시하는 도구로, 중앙 SIEM의 데이터 소스로 자주 함께 구성된다.
• 취약점 스캔·무결성 점검·계정 점검은 모두 주기적으로 반복해야 하며, 도구 도입이 점검 주기의 필요성을 없애지 않는다.

마무리 복습

참고 자료

• itwiki - 정보보안기사 필기 출제기준 
• 공공데이터포털 - 한국방송통신전파진흥원_국가기술자격검정 정보보안 종목 출제기준 
• KISA 보호나라&KrCERT/CC - 사이버 위협 동향 보고서