서버 보안 강화

IT 위키
(최소 권한 원칙에서 넘어옴)
Server Hardening; 서버 하드닝
서버가 기본 설치 상태에서 가지고 있는 불필요한 기능·계정·권한·서비스를 제거하고 설정을 안전한 값으로 바꾸어 공격 표면(attack surface)을 줄이는 일련의 작업

운영체제와 응용 프로그램은 설치 직후 잘 동작하는 것을 목표로 기본값이 잡혀 있지, 안전한 것을 목표로 잡혀 있지 않다. 그래서 설치 후에 별도의 강화 작업이 필요하다. 하드닝은 취약점을 하나씩 막는 대증적 조치가 아니라, 애초에 공격자가 건드릴 수 있는 표면 자체를 줄이는 예방적 조치다.

설계 원칙

[편집 | 원본 편집]

하드닝의 개별 항목은 운영체제마다 다르지만, 그 근거가 되는 원칙은 공통이다. 아래는 1975년 살처(Jerome Saltzer)와 슈로더(Michael Schroeder)가 정리한 보호 메커니즘 설계 원칙에서 비롯한 것으로, 오늘날의 보안 기준서 대부분이 이를 바탕에 두고 있다.

최소 권한의 원칙

[편집 | 원본 편집]

Principle of Least Privilege

주체(사용자·프로세스·서비스)에게는 맡은 일을 수행하는 데 필요한 최소한의 권한만, 필요한 기간에만 부여한다.

  • 권한이 넘치면 그 계정이나 프로세스가 탈취되었을 때 피해 범위가 그대로 넓어진다. 최소 권한은 사고를 막는 원칙이 아니라 사고가 났을 때 피해를 가두는 원칙이다.
  • 적용 예
    • 서비스 데몬을 root 나 Administrator 가 아닌 전용 저권한 계정으로 실행한다. 웹 서버가 apache·nginx 계정으로 도는 것이 그 예다.
    • 관리자는 평소에 일반 계정을 쓰고 필요할 때만 sudo·UAC 로 권한을 올린다.
    • 데이터베이스 계정에 조회만 필요하면 SELECT 권한만 준다. DROP·GRANT 까지 주지 않는다.
    • 파일과 디렉터리 권한을 필요한 주체에게만 준다. 리눅스의 umask·퍼미션, 윈도우의 NTFS 권한이 수단이다.
    • 퇴직·부서 이동 시 권한을 즉시 회수하고, 주기적으로 권한을 재검토한다.
  • 혼동하기 쉬운 개념
    • 알 필요성의 원칙(Need to Know) : 권한이 아니라 정보를 대상으로 한 같은 취지의 원칙이다.
    • 직무 분리(Separation of Duty) : 한 사람이 요청·승인·실행을 모두 하지 못하게 나누는 것. 최소 권한과 짝을 이루어 내부자 위협을 줄인다.
    • 역할 기반 접근통제는 최소 권한을 대규모 조직에서 실현하기 위한 대표적인 구현 방식이다.

그 밖의 원칙

[편집 | 원본 편집]
  • 최소 기능의 원칙 : 쓰지 않는 서비스·포트·프로토콜·계정·패키지는 설치하지 않거나 제거한다. 서버를 강화할 때 서비스를 많이 활성화해 두는 것은 정반대 방향이다.
  • 안전한 기본값(Fail-safe Defaults) : 명시적으로 허용한 것만 허용하고 나머지는 거부한다. 방화벽 정책을 화이트리스트로 잡는 것이 같은 원리다.
  • 심층 방어(Defense in Depth) : 한 겹이 뚫려도 다음 겹이 막도록 통제를 여러 층으로 겹친다. 네트워크 방화벽 → 호스트 방화벽 → 서비스 접근통제 → 파일 권한 순으로 쌓는다.
  • 메커니즘의 경제성(Economy of Mechanism) : 보호 장치는 단순해야 검증할 수 있다. 복잡한 설정은 그 자체가 결함의 원인이 된다.
  • 완전한 중재(Complete Mediation) : 모든 접근을 예외 없이 검사한다. 한 번 통과한 주체를 이후에 검사하지 않으면 우회 경로가 생긴다.
  • 공개 설계(Open Design) : 메커니즘의 비밀이 아니라 키의 비밀에 안전성을 둔다(커크호프의 원리).
  • 심리적 수용성(Psychological Acceptability) : 지키기 어려운 통제는 우회된다. 과도한 암호 정책이 메모지 부착을 부르는 것이 대표적이다.

적용 영역

[편집 | 원본 편집]

계정과 인증

[편집 | 원본 편집]
  • 기본 계정·게스트 계정·시험용 계정을 제거하거나 비활성화한다.
  • 관리자 계정 이름을 기본값에서 바꾸고, 원격 직접 로그인을 막는다(리눅스의 PermitRootLogin no).
  • 암호 복잡도·최대 사용 기간·재사용 제한·계정 잠금 임계값을 정책으로 강제한다.
  • 가능하면 암호 대신 키 기반 인증이나 다중 인증을 쓴다.
  • 사람과 서비스 계정을 구분하고, 서비스 계정에는 대화형 로그인 셸을 주지 않는다.

서비스와 네트워크

[편집 | 원본 편집]
  • 쓰지 않는 서비스를 중지하고 자동 시작에서 뺀다.
  • 열린 포트를 점검해 필요한 것만 남긴다.
  • 관리용 접속은 출발지 IP 를 제한하고 전용 관리망으로 분리한다.
  • 평문 프로토콜(Telnet, FTP, rlogin)을 암호화된 것(SSH, SFTP, TLS)으로 바꾼다.
  • 업무 자원과 서비스 자원을 분리한다. 웹·DB·인증 서버를 한 대에 몰아 놓으면 한 서비스의 취약점이 전체 침해로 이어진다.

패치와 형상

[편집 | 원본 편집]
  • 보안 패치를 정해진 주기로 적용하고, 적용 전에 시험 환경에서 검증한다.
  • 변경은 정책과 절차에 따라 승인받은 뒤 반영하고 이력을 남긴다.
  • 기준 설정값(baseline)을 정의해 두고 실제 서버가 그와 어긋나는지 주기적으로 점검한다.

로그와 감사

[편집 | 원본 편집]
  • 인증 성공·실패, 권한 변경, 주요 설정 변경을 기록하도록 감사 정책을 켠다.
  • 로그를 서버 바깥의 별도 저장소로 보내 침입자가 지우지 못하게 한다.
  • 로그를 쌓아 두기만 하지 말고 주기적으로 검토한다.

파일 시스템과 무결성

[편집 | 원본 편집]
  • 중요 디렉터리의 권한을 최소화하고 SetUID·SetGID 파일을 목록으로 관리한다(리눅스 특수권한).
  • 주요 시스템 파일의 해시를 기록해 두고 변경을 탐지한다(트립와이어 등 무결성 검사 도구).
  • 데이터는 암호화해 저장하고, 백업본도 같은 수준으로 보호한다(백업).

참고 기준

[편집 | 원본 편집]
  • CIS Benchmarks : 운영체제·미들웨어별 설정 항목을 수치까지 명시한 사실상의 업계 표준
  • DISA STIG : 미국 국방부의 보안 기술 구현 지침
  • 주요정보통신기반시설 취약점 분석·평가 기준 : 국내 기반시설 점검 항목(주요정보통신기반시설)
  • ISO/IEC 27002 : 정보보호 통제 실무 지침

같이 보기

[편집 | 원본 편집]