이전 과정들을 통해 서비스와 네트워크 구축이 끝났다. 그럼 이제 그냥 서비스를 운영하면 될까?
우리는 보안 관점에서 안전한 서버 사이드 설계를 마쳤고, 네트워크 배치까지 완성 했지만 그렇다고 시스템이 안전하다고 볼 수는 없다.
내부 시스템에 존재하는 보안 취약점이 있을 수도 있고, 내부자의 실수로 데이터가 유출될 수도 있으며, 악의적인 공격자가 시스템을 지속적으로 공격할 수도 있다. 하지만, 관리자가 내부 시스템에서 어떤 일들이 일어났는지 확인할 수 있는 방법이 없다면 이를 알아챌 수도, 방어할 수도, 대응할 수도 없다.
이번 과정에서는 정보보호 침해사고로부터 우리의 서비스와 네트워크를 보호하고 관리하기 위해 무엇이 필요한지 또, 어떻게 구현해야 하는지에 대해 배워볼 것이다.
새벽에 WAS 서버에서 알 수 없는 프로세스가 실행됐다는 경보가 발생해, 아침에 서버에 접속해 확인해 보았다고 상황을 가정해보자. 이미 프로세스는 종료되어 ps 명령에서 보이지 않고 history 기록도 비워져 있다.
즉, 이상 징후는 확인했지만 그 원인과 발생한 피해를 알아낼 수 있는 행위 기록이 없는 것이다.
따라서 사고를 분석하려면 현재 상태뿐 아니라 누가 어떤 행위가 언제 발생했는지에 대한 과거 행위를 지속적으로 기록해야 한다.
Endpoint Telemetry는 서버나 사용자 PC와 같은 단말기에서 관찰하고 수집한 행위 및 상태 데이터를 의미한다.
그리고 우리가 이번 설계에서 수집해야하는 Endpoint Telemetry는 다음과 같다.
| 구분 | 수집할 이벤트 | 주요 기록 항목 |
|---|---|---|
| 누가 실행했는가? | 로그인, 인증, 권한 변경 | 계정, 세션 식별자, 실행 권한 |
| 무슨 명령을 실행했는가? | 프로세스 실행 기록 | 실행 파일 경로, 명령행 인수, PID/PPID |
| 어떤 파일을 만들거나 변경했는가? | 파일 생성・수정・삭제・권한 변경 | 파일 경로, 작업 종류, 수행 프로세스와 계정 |
| 어떤 IP에서 통신했는가? | 네트워크 연결 시도와 결과 | 출발지・목적지 IP와 포트, 프로토콜 |
Linux 서버를 기준으로 보았을 때, 인증 로그와 감사 기능 등을 기본적으로 제공하지만, 우리가 필요한 프로세스 실행・파일 변경・네트워크 연결 정보를 기록하려면 수집 범위를 미리 설정해주어야 한다.
예를 들어 Linux의 감사 서비스인 auditd를 활용해 특정 프로그램 실행이나 파일 작업을 기록할 수 있다. 필요한 항목에 따라 별도 수집 Agent를 사용할 수도 있다. Agent는 서버와 같은 단말기에 설치되어 데이터를 수집・전송하거나 조사 작업을 수행하는 프로그램이다.
각 서버에 Endpoint Telemetry를 기록한다고 해도 서버가 여러 대라면 사고 발생 시 각 서버에 접속해 기록을 확인해야 하고, 공격자가 충분한 서버 권한을 가졌으면 내부 기록을 삭제하거나 수집 기능을 중지할 수도 있다.
따라서, 필요한 이벤트를 서버 밖의 중앙 시스템으로 지속 전송하고 보관하는 구조가 필요하다.