구성 변경 이력 타임라인 보기

추적 중인 모든 리소스에 대해 구성 서비스는 구성 타임라인을 생성합니다. 이는 해당 리소스에 기록된 모든 구성 항목을 순서대로 정리한 기록입니다. 과거 어느 시점이든 돌아가 리소스가 정확히 어떻게 설정되어 있었는지 확인할 수 있으므로, 인프라를 위한 타임머신과 같습니다.

사고가 발생했을 때 타임라인은 중요한 질문에 답합니다. 바로 무엇이 언제 변경되었는가입니다. 보안 그룹이 갑자기 모든 곳에서 오는 트래픽을 허용했다면 타임라인에서 해당 규칙이 추가된 시점을 확인할 수 있습니다. 변경 시점을 특정하면 조사해야 할 범위가 좁아지고 다른 이벤트와의 상관관계를 파악하는 데 도움이 됩니다.

타임라인의 각 항목은 타임스탬프와 함께 구성 변경 및 변경 전후의 차이를 표시합니다. 포트 범위가 넓어졌는지, 암호화가 해제되었는지처럼 어떤 속성이 변경되었는지 정확히 볼 수 있습니다. 이 차이 보기에서는 막연한 "무언가 변경됨"이 구체적이고 명확한 발견 사항으로 바뀝니다.

구성 서비스는 상태가 무엇으로 변경되었는지 보여 줍니다. 이를 일으킨 누가를 알아내려면 구성 항목의 타임스탬프를 사용해 CloudTrail로 이동하십시오. 변경 시점을 CloudTrail 이벤트와 대조하면 책임 주체, 출처 IP 및 관련 API 호출을 식별할 수 있습니다. 이러한 구성 서비스에서 CloudTrail로의 이동은 핵심 조사 기법입니다.

타임라인은 관계의 변경도 기록합니다. 예를 들어 Volume이 다른 인스턴스에 연결되거나 서브넷의 라우팅 테이블이 변경되는 경우입니다. 개별 리소스 속성이 변하지 않은 것처럼 보여도 이러한 관계의 변화가 사고의 실질적인 원인을 드러낼 수 있으며, 공격자가 연결 구조를 어떻게 재배선했는지 보여 줍니다.

리소스별 타임라인 외에도 구성 서비스는 기록된 모든 리소스의 전체 구성 스냅샷을 일정에 따라 S3로 전달할 수 있습니다. 스냅샷은 특정 시점의 완전한 인벤토리이므로, 감사 중 전체 환경의 상태를 입증하거나 날짜별 보안 상태를 비교하는 데 유용합니다.

구성 서비스는 구성 가능한 기간 동안 구성 기록을 보존하며, 최대 몇 년까지 설정할 수 있습니다. 기본 데이터는 사용자의 S3 버킷에도 저장됩니다. 장기적인 포렌식 및 규정 준수 요구 사항을 위해서는 기록 자체만큼이나 버킷을 보호하고 보존하는 일이 중요합니다. 기록은 남아 있어야만 유용하기 때문입니다.

타임라인은 리소스가 의도한 안전한 상태에서 조용히 벗어나는 구성 드리프트를 조사하는 방법입니다. 현재 CI를 이전의 정상 상태인 CI와 비교하면 무엇이 어떻게 어긋났는지 정확히 알 수 있습니다. 어제는 준수하던 제어 항목이 오늘 실패하는 상황에서 특히 유용합니다.

콘솔에서 구성 서비스의 리소스를 열면 타임라인을 바로 볼 수 있으며, 각 시점에 규정 준수 상태가 함께 표시됩니다. 리소스가 어떻게 변경되었는지뿐 아니라 각 버전이 규칙을 준수했는지도 확인할 수 있어, 과거 상태를 해당 시점의 보안 상태와 연결해 파악할 수 있습니다.

구성 서비스는 삭제된 리소스에 대해서도 기록을 보존하며, 삭제를 표시하는 최종 CI를 기록합니다. 이는 공격자가 흔적을 감추기 위해 리소스를 생성한 뒤 삭제하는 조사 상황에서 중요합니다. 삭제 이벤트와 리소스의 이전 상태가 모두 기록에 남아 있으므로 찾아볼 수 있습니다.

구성 타임라인은 포렌식의 기반입니다. 리소스가 언제, 무엇이 변경되었는지 보여 주고 CloudTrail과 결합하면 누가 변경했는지도 알려 줍니다. 상태 변경에서 책임 있는 API 호출로 이동하는 방법을 익히는 것은 시험에서 요구하는 조사 유형을 정확히 수행하는 데 핵심입니다.

구성 서비스 기록 활용 능력을 테스트해 보십시오.

구성 타임라인은 리소스의 구성 항목을 순서대로 정리한 기록으로, 타임스탬프와 함께 변경 전후의 차이 및 관계 변경을 보여 줍니다. 무엇이 언제 변경되었는지 특정할 수 있으며, CloudTrail로 이동하면 누가 변경했는지 확인할 수 있습니다. 구성 서비스는 삭제된 리소스의 기록을 보존하고 스냅샷을 지원하므로, 드리프트와 사고를 조사하는 포렌식의 기반이 됩니다.