사고 대응·네트워크 세분화·검증·운영 지표

핵심 요약

보안 아키텍처·솔루션·로그·취약점 관리를 연결해 이해하는 보조 정리다. 보안 사고가 발생했을 때 확산을 제한하고, 원인을 제거하고, 정상 서비스를 복구한 뒤 통제를 개선하는 관계를 살펴본다.

장비를 설치했다는 사실과 통제가 실제로 동작한다는 사실은 다르다. 네트워크를 나눴다는 사실과 접근을 제한했다는 사실도 구분해야 한다.

1. 사고 대응의 기본 흐름

이는 활동 간 관계를 이해하기 위한 기본 흐름이다. 실제 사고에서는 분석과 격리 등이 반복·병행될 수 있다. 모든 대응 체계가 동일한 이름과 개수의 단계만을 사용한다는 뜻은 아니다.

격리는 피해의 확대를 제한하는 것이고, 제거는 침해 원인을 없애는 것이다. 감염 서버를 망에서 분리했어도 내부의 악성 요소가 사라진 것은 아니다. 반대로 악성 파일 하나를 삭제했어도 이미 탈취된 계정이나 다른 감염 자산이 남아 있을 수 있다.

조사에 필요한 로그와 기록을 보존하고 수행한 변경을 남긴다. 확인 없이 흔적을 삭제하거나 무조건 전원을 끄는 행동은 조사에 필요한 정보를 잃게 할 수 있다. 구체적인 현장 조치는 사고 상황과 승인된 대응 절차에 따른다.

2. 네트워크 세분화와 접근통제

세분화는 사용자·서버·관리·백업·공개 서비스 등의 성격에 따라 네트워크 구역을 나누는 것이다. 불필요한 통신 경로를 줄이면 한 구역의 침해가 다른 구역으로 퍼지는 범위를 제한하는 데 도움이 된다.

VLAN은 논리적인 L2 구역 분리이며, VLAN 사이를 라우팅하면서 모든 통신을 허용하면 강한 보안 격리가 완성되었다고 볼 수 없다. 구역 간 ACL·방화벽·서버 인가 등이 정책에 맞게 집행되어야 한다.

관리망과 백업망을 분리해도 공용 관리자 계정이 모든 시스템을 제어할 수 있다면 그 계정의 탈취가 여러 통제를 함께 무너뜨릴 수 있다. 네트워크뿐 아니라 계정·권한·데이터 보호도 함께 고려한다.

3. 통제의 검증

허용해야 하는 요청이 성공하는지와 거부해야 하는 요청이 실패하는지를 함께 확인한다. 모든 통신이 끊긴 상태는 접근통제를 잘한 것이 아니라 장애일 수 있다.

예를 들어 응용 서버만 DB에 접근하도록 설계했다면 응용 서버의 정상 DB 접속과 일반 사용자 단말의 직접 접속 거부를 각각 확인한다. 접속 실패만으로 방화벽이 차단했다고 단정하지 않고 정책·로그·서비스 상태를 대조한다.

문서상 복구 절차가 존재하는 것과 실제 복원이 성공하는 것은 다르다. 도상훈련만으로 저장장치·백업 데이터의 복구 가능성을 모두 검증할 수는 없다.

4. RTO와 RPO

RTO(Recovery Time Objective)는 장애 이후 서비스가 복구되어야 하는 시간 목표다. RPO(Recovery Point Objective)는 어느 시점까지의 데이터를 복구해야 하는지 나타내는 목표로, 허용 가능한 데이터 손실을 시간으로 표현한다.

예를 들어 10시에 장애가 발생하여 11시 10분에 복구되고, 복구된 최신 데이터가 9시 40분 시점이라고 하자. RTO가 90분이고 RPO가 15분이라면 다음과 같다.

서비스가 빨리 재개되었다고 데이터 복구 목표까지 자동으로 충족한 것은 아니다. 백업 횟수만으로 판단하지 않고 실제 복구 가능한 시점을 확인한다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

5. 운영 지표를 읽는 기본 관점

운영 지표는 통제 상태를 이해하는 보조 정보다. 패치 건수·경보 건수 같은 활동량과 실제 취약점 해결·탐지·복구 같은 결과를 구분한다.

MTTD는 평균 탐지 시간이라는 의미로 사용된다. MTTR은 문맥에 따라 평균 수리·복구·해결 시간 등으로 사용되므로 측정 구간을 먼저 확인해야 한다. 이러한 실제 측정값과 목표인 RTO는 같은 개념이 아니다.

경보가 줄어든 이유가 공격 감소인지, 탐지 성능 개선인지, 로그 수집 실패인지 확인해야 한다. 평균 복구 시간이 목표보다 짧더라도 개별 중요 사고는 목표를 넘을 수 있다. 숫자 하나만으로 모든 보안 상태를 판단하지 않는다.