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

1. 항목 설명

Object Storage 버킷의 접근과 객체 작업 이력이 로그로 수집되어 누가 언제 어떤 작업을 수행했는지 추적 가능한지 점검하는 항목입니다.

중요 버킷의 접근 로그가 별도 저장소에 보관되고 무결성과 접근 권한이 관리되는 경우 양호합니다.

2026 가이드 근거

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

2. 점검 목적

객체 조회·변경·삭제와 비인가 접근 시도를 추적하여 데이터 유출과 훼손 사고의 조사 가능성을 확보하는 것이 목적입니다.

3. 실습 환경

• 클라우드: NAVER Cloud Platform 개인 실습 계정
• Object Storage 이용 상태: 미가입
• 원본 버킷: 0개
• 로그 저장 버킷: 0개
• 과금 방지: 서비스 이용 신청과 버킷 생성을 진행하지 않음

4. 취약 상태 구성

Object Storage가 활성화되지 않아 로깅이 해제된 버킷을 만들지 않았습니다. 대상 부재를 N/A로 기록하고, 도입 시 원본 버킷과 로그 버킷을 분리하는 예방 통제를 검토했습니다.

5. 최초진단 결과

• 최초진단 판정: 해당 없음(N/A)
• 판정 근거: 접근 로그를 설정할 Object Storage 버킷이 없음
• 확인 현황: Object Storage 서비스 미가입

6. 조치 방법

버킷을 생성한 뒤 접근 로깅 기능을 활성화하고 로그는 원본 데이터와 분리된 전용 버킷에 저장합니다. 로그 버킷은 공개 접근을 차단하고 최소 권한, 암호화와 보존 정책을 적용합니다.

콘솔 경로 예시: Object Storage → Bucket Management → 대상 버킷 → 로그 관리

7. 이행진단 결과

• 이행진단 판정: 예방 통제 확인
• 판정 근거: 원본·로그 버킷 분리와 접근 통제 원칙을 정리함
• 제한 사항: 서비스 미가입으로 실제 로그 파일 생성은 검증하지 않음

8. 실무 주의사항

로그를 동일 원본 버킷에 저장하거나 로깅 대상과 로그 대상이 순환되면 관리 혼선과 비용 증가가 발생할 수 있습니다.

컨설턴트 조언

• 로그 버킷은 원본 버킷 운영자와 삭제 권한을 분리하고 가능하면 별도 계정으로 격리합니다.
• 객체 조회 로그까지 필요한지 데이터 중요도와 비용을 기준으로 결정합니다.
• 수명 주기 정책은 감사 보존 기간보다 짧지 않게 설정하고 임의 삭제를 제한합니다.
• 로그 수집 설정이 켜져 있다는 사실뿐 아니라 최근 로그 객체가 실제 생성되는지 확인합니다.

9. 마무리

현재 Object Storage가 미가입이라 N/A로 판정했습니다. 버킷 로깅은 원본과 분리된 저장, 삭제 통제와 실제 로그 유입 확인까지 갖춰야 의미가 있습니다.