[인프라진단] #CA-16 오브젝트 스토리지 버킷 로깅 설정

1. 항목 설명

오브젝트 스토리지 버킷의 접근 요청을 추적할 수 있도록 서버 액세스 로깅이 설정되어 있는지 점검하는 항목입니다.

판단 기준은 조직 정책에 따라 버킷 로깅이 설정된 경우 양호, 설정되지 않은 경우 취약입니다.

2026 가이드 근거

출처: 과학기술정보통신부·한국인터넷진흥원, 「2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드」, CA-16, p.869.
본 게시글은 위 가이드의 판단 기준을 참고하여 작성했으며, 진단 결과와 증적은 개인 실습 환경에서 직접 수집했습니다.

2. 점검 목적

객체 조회·변경·삭제 요청의 주체와 결과를 추적해 데이터 오용, 비인가 접근과 장애 조사에 필요한 기록을 확보하는 것이 목적입니다.

3. 실습 환경

• 클라우드: 개인 AWS 실습 계정
• 작업 도구: AWS Management Console, AWS CloudShell, AWS CLI
• 원본 저장소: 기존 CA 실습용 비공개 S3 버킷
• 최초 상태: 서버 액세스 로깅 비활성화, 로그 대상 버킷 없음
• 조치 상태: 별도 비공개 S3 로그 버킷과 ca16-access/ 접두사 사용
• 전달 주체: logging.s3.amazonaws.com
• 비용 주의: 로그 객체 저장, 요청과 수명 주기 처리에 계정 플랜별 비용이 발생할 수 있음

실습·비용·안전 고지

서버 액세스 로그는 즉시 전달을 보장하는 실시간 스트림이 아니며 전달이 지연될 수 있습니다. 이행진단 시점에는 설정과 권한을 확인했고, 즉시 객체 수가 0이어도 로깅 구성 자체의 실패로 단정하지 않았습니다.

4. 취약 상태 구성

원본 버킷의 로깅 설정을 조회해 LoggingEnabled 구성이 없고 별도 로그 대상 버킷도 없는 상태를 확인합니다.

aws s3api get-bucket-logging --bucket <SOURCE_BUCKET>

접근 로그가 없으면 객체 요청의 원격 주소, 요청자, 작업, 응답 코드 등을 사후에 확인하기 어려워집니다.

5. 최초진단 결과

• 최초진단 판정: 취약
• 실제 확인 결과: 원본 버킷의 서버 액세스 로깅 설정 없음
• 실제 확인 결과: CA-16 전용 액세스 로그 대상 버킷 없음
• 영향: 객체 접근 요청을 별도 보관·추적할 경로가 없음
• 실제 최초진단 증적 파일: ca11_ca19_initial_diagnosis.txt

6. 조치 방법

원본과 분리된 비공개 대상 버킷을 만들고 S3 로그 전달 서비스에 지정 접두사 쓰기 권한을 부여한 뒤 서버 액세스 로깅을 활성화합니다.

{
  "LoggingEnabled": {
    "TargetBucket": "<ACCESS_LOG_BUCKET>",
    "TargetPrefix": "ca16-access/"
  }
}

aws s3api put-bucket-logging \
  --bucket <SOURCE_BUCKET> \
  --bucket-logging-status file://ca16-logging.json

aws s3api get-bucket-logging --bucket <SOURCE_BUCKET>

대상 버킷 정책에는 서비스 주체 logging.s3.amazonaws.com의 s3:PutObject를 허용하고 원본 버킷 ARN과 계정 조건으로 범위를 제한합니다.

클라우드 콘솔 경로: S3 → 원본 버킷 → 속성 → 서버 액세스 로깅

UI 증적 수집(2026-08-25): 실제 S3 콘솔에서 서버 액세스 로깅이 활성화되고 별도 대상 버킷과 객체 키 접두사가 지정된 상태를 확인했습니다.

7. 이행진단 결과

• 이행진단 판정: 양호
• 실제 확인 결과: LoggingEnabled 구성 적용
• 대상 저장소: 원본과 분리된 비공개 액세스 로그 버킷
• 객체 접두사: ca16-access/
• 전달 권한: S3 로그 전달 서비스 주체에 제한적으로 허용
• 수집 시점 참고: 서버 액세스 로그는 지연·최선형 전달 방식이라 즉시 객체가 없을 수 있음
• 실제 이행진단 증적 파일: ca11_ca19_after_diagnosis.txt

8. 실무 주의사항

대상 버킷을 원본과 동일하게 지정하면 로그 객체 생성이 다시 로그를 만들어 비용과 객체 수가 증가할 수 있습니다. 별도 버킷·접두사를 사용하고 로그 전달 권한이 지나치게 넓지 않은지 확인해야 합니다.

컨설턴트 조언

• 버킷 목록에서 중요도와 데이터 등급을 분류한 뒤 필수 로깅 대상을 누락 없이 관리합니다.
• 서버 액세스 로그와 CloudTrail S3 데이터 이벤트는 목적·필드·비용이 다르므로 조사 요구사항에 맞게 조합합니다.
• 대상 버킷은 퍼블릭 차단, 최소 권한, 암호화, 보존·삭제 정책과 운영 계정 분리를 적용합니다.
• 로그 생성 여부를 설정 화면만으로 판단하지 말고 충분한 전달 시간을 둔 뒤 샘플 요청과 실제 객체를 확인합니다.
• 로그 전달 서비스 정책의 SourceArn, SourceAccount, 대상 접두사를 제한하고 다른 주체의 쓰기 권한을 검토합니다.

9. 마무리

버킷 로깅은 설정값과 별도 저장소 권한이 함께 맞아야 동작합니다. 이번 실습에서는 실제 서버 액세스 로깅 구성과 전달 대상을 확인하고 지연 전달 특성까지 기록했습니다.