서버 하드닝 정책: 예시와 팁

여러 연구에 따르면 보고된 침해 사고의 무려 80%가 IT 시스템의 구성 설정에서 발생한 취약점을 악용하는 것과 관련이 있습니다. 공격을 사전에 차단하여 막대한 비용이 드는 가동 중단과 데이터 유출을 예방하기 위해 전문가들은 서버 하드닝 정책을 적용할 것을 권장하는데, 이는 시스템 하드닝 정책의 한 유형입니다.

서버 하드닝 정책은 무단 액세스와 악용으로부터 시스템을 보호하기 위해 설계된 일련의 지침, 절차, 제어 항목의 집합입니다. 실제로 기본 상태로 배포된 서버는 손상(침해) 및 악성코드 공격의 위험에 노출되어 있습니다. 하지만 불필요한 소프트웨어와 기능을 제거하고, 보안 설정을 적절히 구성하며, 액세스 제어, 감사(auditing), 사고 대응(incident response)에 대한 모범 사례를 적용하면 공격 표면을 크게 줄일 수 있습니다.

다음 팁과 예시는 보안 강화를 위한 노력의 시작점으로 활용할 수 있습니다.

사용자 계정 및 비밀번호

• 계정 잠금 기간과 임계값이 설정되어 있나요?
• Kerberos 암호화가 활성화되어 있으며, 선택한 암호화 유형이 충분히 강한가요?
• Windows 시스템의 기본 제공 Administrator 및 Guest 계정과 같은 기본 로컬 계정이 비활성화되어 있거나 이름이 변경되어 있나요?
• NIST 지침과 같은 모범 사례에 부합하도록 사용자 비밀번호 요구 사항이 설정되어 있나요?

예시: 다음 매개변수로 계정 비밀번호 정책을 설정하세요.

• 최소 비밀번호 사용 기간: 1일 이상
• 최소 비밀번호 길이: 14자 이상
• 계정 잠금 임계값: 10회 이하 시도(단, 0은 제외)
• 계정 잠금 카운터 재설정: 15분 이상

운영 체제

• 모든 운영 체제(OS)가 공급업체의 전체 지원을 받고 있으며 최신 수준으로 패치되어 있나요? 또한 이를 최소 월 1회 검토하나요?
• 불필요한 모든 서비스와 데몬이 제거되었거나 비활성화되었나요? 웹, FTP, 텔넷, 원격 데스크톱 액세스가 제거되었나요? 가장 좋은 팁은 필요하지 않다고 알고 있는 모든 항목(예: Themes 서비스)을 비활성화한 다음, 불필요하다고 판단되는 다른 서비스에 대해 하나씩 신중하게 실험하는 것입니다. 서비스를 비활성화하면 업무 운영에 문제가 생긴다면 해당 서비스는 계속 활성화해 두세요.
• 어떤 포트가 열려 있는지 알고 있나요? 그대로 열어 두어야 할 타당한 이유가 있나요, 아니면 제거할 수 있나요? 새로 열리는 포트가 나타날 때 이를 감지할 수 있나요?
• 로컬의 Security Policy를 제대로 활용하고 있나요? 이 정책을 사용하면 악용 가능한 취약점을 완화할 수 있습니다. 또한 보안을 강화하기 위해 수백 가지의 세부 보안 구성 제어를 제공합니다.

예시: Windows 운영 체제에 대해 다음 설정을 정의합니다:

• 보안 데스크톱을 사용하지 않고 UIAccess 응용 프로그램이 상승을 요청하도록 허용: 사용 안 함
• 관리 승인 모드에서 관리자에 대한 권한 상승 프롬프트: 보안 데스크톱에서 동의 요청
• 일반 사용자에 대한 권한 상승(승격) 요청 확인: 권한 상승 요청을 자동으로 거부
• 애플리케이션 설치를 감지하고 권한 상승을 요청: 사용
• 안전한 위치에 설치된 UIAccess 애플리케이션만 권한 상승: 사용
• 모든 관리자를 관리자 승인 모드로 실행: 사용
• 파일 및 레지스트리 쓰기 실패를 사용자별 위치로 가상화: 사용

파일 시스템

• Unix 및 Linux 서버의 경우, 주요 보안 파일(예: /etc/password 및 /etc/shadow)에 대한 권한이 모범 사례 권고에 따라 설정되어 있습니까? sudo가 사용되고 있나요? 그렇다면 root wheel 구성원만 사용을 허용하고 있습니까?
• Windows 서버의 경우, System32 및 SysWOW64 폴더(뿐만 아니라 Program Files/(x86) 폴더)에서 주요 실행 파일, DLL 및 드라이버가 보호되고 있습니까?

예시: 적용 파일 무결성 모니터링 다음 파일 및 폴더에:

• %PROGRAMFILES%: SHA1 해시 사용, 시스템 파일 변경, 로그 파일 제외, 재귀
• %PROGRAMFILES(x86)%: SHA256 해시 사용, 시스템 파일 변경 사항, 로그 파일 제외, 재귀
• %SYSDIR%: SHA256 해시 사용, 시스템 파일 변경 사항, 로그 파일 제외, 재귀
• %WINDIR%SysWOW64: SHA256 해시 사용, 시스템 파일 변경 사항, 로그 파일 제외, 재귀

클라이언트/서버 네트워크

• 내장 소프트웨어 방화벽이 활성화되어 있고 “모두 거부(Deny All)”로 구성되어 있나요?
• Linux에서 TCP Wrappers가 “Deny All”로 구성되어 있나요?
• 원격으로 액세스 가능한 레지스트리 경로와 공유가 환경에 맞게 적절히 제한되어 있나요? 멤버 서버와 도메인 컨트롤러에서는 설정이 달라집니다.

예시: 보안 정책에서 다음 네트워크 클라이언트 및 네트워크 서버 설정을 지정하세요:

• 통신에 디지털 서명(서버에서 동의하는 경우): 사용
• 타사 SMB 서버에 암호화되지 않은 비밀번호 전송: 사용 안 함
• 통신을 디지털 서명합니다(항상): 사용
• 통신을 디지털 서명합니다(클라이언트가 동의하는 경우): 사용
• 로그온 시간이 만료되면 클라이언트를 연결 해제합니다: 사용

감사 및 변경 관리

• 모든 액세스, 권한 사용, 구성 변경, 그리고 개체 액세스, 생성 및 삭제에 대해 감사 로그(감사 추적)가 활성화되어 있나요?
• 감사 로그(감사 추적)가 안전하게 백업되고 최소 12개월 동안 보관되고 있나요?
• 중앙에서 보호되는 NTP 소스가 구성되어 사용되고 있나요?
• file integrity monitoring (FIM)을 사용하여 보안 빌드 표준을 유지하고 있나요?
• 정의된 change management 프로세스가 있나요? 이 프로세스에는 변경 제안(영향 분석 및 롤백 조항 포함), 변경 승인, QA 테스트, 그리고 도입 후 검토가 포함되어야 합니다.
• 기록된 이벤트가 중앙 서버로 안전하게 백업되나요? 이를 위해 모니터링되는 서버에서 로그 서버로 이벤트를 전달할 수단이 필요합니다(보통 Syslog 전달 에이전트 또는 Netwrix Change Tracker 같은 보다 포괄적인 솔루션). 또한 체계적인 audit policy도 필요합니다.

예시: 고급 감사 정책에서 다음 설정을 정의합니다:

• 로그오프 감사: 성공
• 로그온 감사: 성공 및 실패
• 기타 로그온/로그오프 이벤트 감사: 성공 및 실패
• 특수 로그온 감사: 성공

소프트웨어 및 애플리케이션

• 보안 빌드 표준에서 어떤 패키지와 애플리케이션을 정의하고 있나요? 예를 들어, 백신, 데이터 유출 방지, 방화벽 및 FIM 도구에 대한 표준이 있나요? 승인된 변경 사항이 있을 때 기준선을 주기적으로 업데이트하는 절차는 무엇인가요?
• 최신 버전을 보유하고 패치가 테스트되어 적용되었는지 확인하기 위한 프로세스가 있나요?
• 자동 패키지 업데이트는 비활성화하고, 예약된 업데이트 배포를 대신 사용하나요?

서버 하드닝 정책 선택 및 조직에 맞게 조정하기

하드닝 체크리스트나 서버 하드닝 정책을 마련하는 것은 충분히 쉽습니다. 예를 들어 Center for Internet Security (CIS)는 하드닝 체크리스트; Microsoft는 Windows 장치용 체크리스트를 제공하고, Cisco는 자사의 라우터용 체크리스트를 제공하며, NIST가 호스팅하는 National Vulnerability Database는 다양한 Linux, Unix, Windows 및 방화벽 장치에 대한 체크리스트를 제공합니다. 또한 NIST는 SCAP 및 OVAL 표준을 기반으로 한 National Checklist Program Repository도 제공합니다.

이것들은 훌륭한 출발점이지만, 서버의 운영 방식과 역할에 따라 어떤 체크리스트든 맞춤 조정해야 합니다. 예를 들어 인터넷에 직접 노출된 서버는 방화벽 뒤에 있는 데이터베이스 서버보다 더 강력한 접근 제어가 필요합니다.

서버 하드닝 정책을 수립하고 모범 사례 체크리스트를 표준 빌드에 적용한 후에는, 구성 드리프트가 발생하는지 모든 장치를 지속적으로 감사해야 합니다. 변경 관리 프로세스에서는 변경 사항을 어떻게 평가할지 정의하고, 그다음 조치(수정)하거나 구성 기준선(configuration baseline)으로 승격해야 합니다. Netwrix Change Tracker 은 지능형 변경 제어를 제공하므로, 한 서버에서 변경을 승인해야 하는 횟수는 한 번만 하면 됩니다. 이후 동일한 변경이 다른 곳에서 발생하면 자동으로 승인됩니다. 이는 대부분의 FIM 및 SIEM 시스템에서 가장 큰 문제인, 변경 소음(change noise)이 쉽게 과도해져 부담이 되는 상황을 제거해 줍니다.

요약

어떤 data security 전략에서든 가장 효과적인 첫 단계는 보안 침해를 예방하는 것입니다. 하드닝을 통해 구성 취약점을 사전에 해결하면 서버를 보다 안전하게 만들고 공격에 대한 내성을 높일 수 있습니다. 변경 관리와 file integrity monitoring 솔루션은 이후 기준선(baseline)에서 어떤 편차가 발생하는지 모니터링하여 모든 서버가 안전하게 구성된 상태를 유지하도록 보장합니다.

FAQ

서버 하드닝이란 무엇인가요?

서버 하드닝은 사용하지 않는 프로그램과 기능을 비활성화하고, 서버 보안 설정을 강화하며, 감사를 수행하고 사고 대응 모범 사례를 적용함으로써 서버가 공격에 덜 취약해지도록 만드는 사전 예방적 프로세스입니다.

하드닝 정책이란 무엇인가요?

하드닝 정책은 시스템의 공격 표면(attack surface area)을 줄이기 위해 구현하는 일련의 지침과 절차입니다. 이 정책은 액세스 제어, 로깅 및 사고 대응을 위한 내용에 기반해야 합니다. 정책은 Linux나 Windows Server처럼 특정 시스템에 맞춰 작성할 수도 있고, 데이터베이스 하드닝 정책처럼 일반화할 수도 있습니다.

시스템 하드닝 정책 템플릿이란?

시스템 하드닝 정책 템플릿은 시스템을 보안하고 보호하기 위해 따라야 할 지침과 절차를 개요로 정리한 문서입니다. 보통 특정 자산에 대해 구현해야 하는 모범 사례(best practices)와 보안 제어(security controls) 목록이 포함됩니다. 이 템플릿은 다양한 시스템에 맞춘 맞춤형 하드닝 정책을 만들기 위한 출발점으로 사용할 수 있습니다.

서버 보안을 어떻게 하드닝하나요?

주요 단계에는 보통 다음이 포함됩니다:

• 불필요한 소프트웨어와 서비스를 제거하여 공격 표면을 줄입니다
• 방화벽과 침입 탐지/방지 시스템을 구성하여 무단 액세스를 차단합니다
• 암호화와 보안 부팅 같은 보안 기능을 활성화합니다
• 다중 요소 인증과 최소 권한 같은 액세스 제어 모범 사례를 적용합니다
• 소프트웨어를 정기적으로 업데이트하고 보안 패치를 적용합니다
• 가능한 보안 사고를 탐지하고 대응하기 위해 강력한 이벤트 로깅과 트래픽 모니터링을 구현
• 취약점을 식별하고 해결하기 위해 서버 하드닝 정책을 정기적으로 테스트하고 검토합니다.