Azure 흐름 로그 보존 기간 점검

설명

흐름 로그 보존 기간이 너무 짧으면 사고를 뒤늦게 발견했을 때 필요한 네트워크 기록이 이미 삭제되어 있을 수 있습니다. 보존 기간은 조직의 조사와 감사 요구에 맞춰 정해야 하며, 90일이 모든 환경에 충분한 것은 아닙니다.

보존 정책을 비활성화하는 것과 흐름 로그 수집을 중지하는 것은 다릅니다. 실제 기록이 남는 기간은 흐름 로그 설정과 저장 계정의 수명 주기·삭제 정책을 함께 확인해야 합니다.

잠재적 영향

침해 사고 당시의 통신을 조사할 자료가 부족해질 수 있습니다.
이상 트래픽 패턴을 장기간 비교하거나 감사에 필요한 증거를 확보하기 어려워질 수 있습니다.

해결 방법

필요한 보존 기간을 정하고 지원되는 retention_policy와 저장소 정책에 반영하세요.
실제 로그 수집과 가장 오래된 기록을 확인하고, 더 일찍 삭제하는 다른 정책이 없는지 검토하세요. 접근 권한과 비용도 관리하세요.
신규 NSG 흐름 로그는 2025년 6월 30일부터 만들 수 없습니다. 기존 로그는 2027년 9월 30일 종료 전에 Virtual Network 흐름 로그로 이전하고 보존 정책도 함께 점검하세요.

예시

구 AzureRM 형식으로 기존 NSG 흐름 로그의 기간을 비교하는 발췌입니다. 이름과 참조 리소스 등은 생략했습니다. 현재 신규 NSG 흐름 로그를 만드는 예시가 아닙니다.

변경 전

hcl

resource "azurerm_network_watcher_flow_log" "example" {
  network_watcher_name     = azurerm_network_watcher.test.name
  resource_group_name      = azurerm_resource_group.test.name
  network_security_group_id = azurerm_network_security_group.test.id
  storage_account_id        = azurerm_storage_account.test.id
  enabled                   = true

  retention_policy {
    enabled = true
    days    = 89
  }
}

89일 보존은 조직의 기준이 90일이라면 하루 부족합니다. 이 숫자만으로 실제 조사 가능 기간이 결정되지는 않습니다.

변경 후

hcl

resource "azurerm_network_watcher_flow_log" "example" {
  network_watcher_name      = azurerm_network_watcher.test.name
  resource_group_name       = azurerm_resource_group.test.name
  network_security_group_id = azurerm_network_security_group.test.id
  storage_account_id        = azurerm_storage_account.test.id
  enabled                   = true

  retention_policy {
    enabled = true
    days    = 90
  }
}

예시 기준인 90일로 늘립니다. 기존에 삭제된 로그가 복구되는 것은 아니며, 실제 저장소와 조사 요구를 확인해야 합니다.