로깅 및 모니터링 미흡

로깅과 모니터링은 문제가 발생한 후에야 뒤늦게 고려되는 경우가 많지만, 적절한 로깅 및 모니터링 체계를 갖추지 못하면 매우 큰 비용을 치를 수 있습니다.

극단적인 경우, 보안 관련 여부를 떠나 사고가 발생했을 때 로그가 거의 없거나 전혀 없다면 실제로 무슨 일이 일어났는지 파악하는 것이 불가능합니다. 반대로 너무 많은 데이터를 로깅하면 개인정보 보호 문제가 발생하여 규제 당국과 마찰을 빚을 수 있습니다.

아래에서는 더 나은 로깅 및 모니터링을 위한 몇 가지 모범 사례를 살펴보겠습니다.

모범 사례

효과적인 로깅과 모니터링을 위한 모범 사례를 살펴보겠습니다.

민감한 기능을 위한 감사 로깅

로그인 시도(성공 여부와 관계없이), 사용자 계정 변경, 민감한 데이터 접근 및 변경 등 민감한 이벤트에 대한 감사 로그를 생성하는 것은 매우 중요합니다. 이는 일반 사용자뿐만 아니라 내부 관리자 사용자의 접근에도 동일하게 적용됩니다.

이러한 기록은 내부자든 외부자든 상관없이 무단 접근이 의심되는 상황에서 매우 중요한 단서가 됩니다.

사고 발생 시, 누가 어떤 데이터에 접근했는지 파악하여 사건의 규모와 범위를 이해하는 것이 무엇보다 중요합니다.

오류 로깅

오류 및 경고 로그를 유지하는 것은 단순히 애플리케이션 상태를 모니터링하기 위한 일반적인 엔지니어링 관행을 넘어, 위험을 알리는 경고 신호 역할을 할 수 있습니다.

공격자가 취약점을 탐색하는 과정에서 다량의 오류와 경고가 발생하는 경우가 많으며, 이는 공격자가 애플리케이션의 취약점을 발견했을 가능성을 알려주는 지표가 됩니다.

중앙 집중식 로그 저장

로그는 항상 실시간으로 중앙 집중식 저장소로 전송 및 저장되어야 합니다. 이는 SIEM을 통한 즉각적인 분석을 가능하게 할 뿐만 아니라, 서버를 침해한 공격자가 로그를 수정하거나 삭제하는 것을 방지하기 위함입니다.

정해진 기간 동안 로그 보관

안타깝게도 대부분의 침해 사고는 탐지하는 데 며칠이 걸리며, 실제로 20%의 사고는 수개월이 지나서야 발견됩니다. 침해 발생부터 탐지까지 시간이 오래 걸릴 경우, 무슨 일이 일어났는지 파악할 수 있는 유일한 데이터는 로그뿐인 경우가 많습니다.

따라서 로그를 명확하게 정의된 기간 동안 보관하는 것이 매우 중요합니다. PCI와 같은 표준에서는 최근 3개월간의 로그를 즉시 조회할 수 있어야 하며, 최대 12개월 전의 로그도 요청 시 복구할 수 있어야 한다고 규정하고 있습니다.

이러한 접근 방식은 잠재적인 사고 조사를 원활하게 시작할 수 있게 하면서도, 콜드 스토리지를 활용하여 로그 관리 비용을 효율적으로 절감하는 균형 잡힌 방법입니다.

로그 내 개인정보(PII) 정기 감사

로그는 잠재적인 사고를 조사하는 데 유용하지만, 사실 로그 자체가 사고의 원인이 될 수도 있습니다.

사고 조사에 필요한 정보를 포함하는 것과 너무 많은 정보를 기록하는 것 사이에는 미묘한 균형이 필요합니다. 실수로 로그에 개인정보(PII)가 포함되기 쉬우며, 이는 개인정보 보호 규정 위반으로 이어질 수 있습니다.

로그 내 개인정보(PII)를 정기적으로 감사하고 이를 확실히 삭제하는 것이 중요합니다.

‍