설명
CloudTrail 로그를 저장한다는 사실만으로 해당 S3 버킷의 요청 이력까지 수집되는 것은 아닙니다. 서버 액세스 로깅을 사용하면 감사 로그 저장소에 대한 요청을 조사하는 데 도움이 됩니다.
서버 액세스 로그는 최선 노력 방식으로 전달되므로 모든 요청이 빠짐없이 또는 즉시 기록된다고 보장할 수 없습니다. 필요한 객체 작업의 감사에는 CloudTrail 데이터 이벤트도 검토하세요.
잠재적 영향
- 감사 추적 약화: 별도의 접근 기록이 부족하면 로그 버킷에 대한 요청을 조사하기 어렵습니다.
- 사고 분석 지연: 감사 로그의 조회나 삭제 시도를 확인하는 데 시간이 더 걸릴 수 있습니다.
해결 방법
aws_s3_bucket_logging으로 서버 액세스 로깅을 설정하고 실제 로그 전달을 확인하세요.- 같은 계정과 리전의 별도 대상 버킷에 로그 전달 권한을 부여하세요. ACL이 비활성화된 버킷에는 버킷 정책을 사용하세요.
- 로그 버킷과 대상 버킷의 접근 권한, 보관 기간, 삭제 보호를 함께 점검하세요.
예시
다음은 AWS 공급자 3.x의 인라인 logging과 ACL 문법을 사용한 예시입니다. 현재 구성에서는 별도 로깅 리소스와 대상 버킷 정책을 사용하세요. 버킷 이름과 CloudTrail 전달 정책은 환경에 맞게 준비해야 하며, 예제의 force_destroy = true는 감사 로그 보존 요구에 맞는지도 확인하세요.
변경 전
hcl
resource "aws_cloudtrail" "example" {
name = "tf-trail-foobar"
s3_bucket_name = aws_s3_bucket.foo.id
s3_key_prefix = "prefix"
include_global_service_events = false
}
resource "aws_s3_bucket" "foo" {
bucket = "tf-test-trail"
force_destroy = true
}
변경 후
hcl
resource "aws_cloudtrail" "example" {
name = "tf-trail-foobar"
s3_bucket_name = aws_s3_bucket.foo2.id
s3_key_prefix = "prefix"
include_global_service_events = false
}
resource "aws_s3_bucket" "log_bucket" {
bucket = "my-tf-log-bucket"
acl = "log-delivery-write"
}
resource "aws_s3_bucket" "foo2" {
bucket = "my-tf-test-bucket"
acl = "private"
logging {
target_bucket = aws_s3_bucket.log_bucket.id
target_prefix = "log/"
}
}
설명:
변경 후 예시는 CloudTrail 저장 버킷의 서버 액세스 로그를 별도 버킷으로 보냅니다. 로깅 설정 자체가 요청의 차단이나 로그 삭제 방지를 제공하지는 않습니다.