[인프라진단] #CA-12 통신구간 암호화 설정

1. 항목 설명

클라우드 리소스와 사용자·시스템 사이의 통신 구간에 암호화가 적용되어 있는지 점검하는 항목입니다.

판단 기준은 조직 정책에 따라 클라우드 통신 구간 암호화가 적용된 경우 양호, 적용되지 않은 경우 취약입니다.

2026 가이드 근거

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

2. 점검 목적

네트워크 구간에서 인증정보와 업무 데이터가 도청되거나 변조되는 위험을 줄이고 암호화되지 않은 접속을 명시적으로 차단하는 것이 목적입니다.

3. 실습 환경

• 클라우드: 개인 AWS 실습 계정
• 작업 도구: AWS Management Console, AWS CloudShell, AWS CLI
• 점검 대상: 기존 CA 실습용 비공개 S3 버킷
• 취약 상태: 비암호화 전송을 거부하는 버킷 정책 없음
• 조치 상태: aws:SecureTransport=false 요청을 명시적으로 거부
• 안전 통제: 버킷 퍼블릭 액세스 차단 유지, 실제 HTTP 데이터 전송 없이 정책 상태로 검증
• 비용 주의: S3 저장공간과 API 요청은 계정 플랜에 따라 비용이 발생할 수 있어 0원을 보장하지 않음

실습·비용·안전 고지

AWS CLI는 기본적으로 HTTPS를 사용하므로 실습에서는 민감 데이터를 HTTP로 전송하지 않았습니다. 버킷 정책의 aws:SecureTransport 조건을 직접 점검하여 비암호화 요청이 서버 측에서 거부되도록 구성했습니다.

4. 취약 상태 구성

실습 버킷의 정책을 조회해 aws:SecureTransport=false 요청을 거부하는 문장이 없는 상태를 확인합니다.

aws s3api get-bucket-policy --bucket <LAB_BUCKET>

버킷이 비공개여도 허가된 사용자가 HTTP 엔드포인트를 이용할 여지가 남아 있으면 전송 구간 암호화를 강제하지 못한 상태입니다.

5. 최초진단 결과

• 최초진단 판정: 취약
• 실제 확인 결과: 실습 버킷 정책 없음
• 기대 통제: DenyInsecureTransportCA12 정책문과 aws:SecureTransport=false 조건
• 안전 제한: 실제 HTTP로 객체나 인증정보를 전송하지 않음
• 실제 최초진단 증적 파일: ca11_ca19_initial_diagnosis.txt

6. 조치 방법

버킷과 버킷 내부 객체에 대한 비암호화 요청을 명시적으로 거부합니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransportCA12",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<LAB_BUCKET>",
        "arn:aws:s3:::<LAB_BUCKET>/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

aws s3api put-bucket-policy \
  --bucket <LAB_BUCKET> \
  --policy file://ca12-tls-only-policy.json

클라우드 콘솔 경로: S3 → 버킷 → 권한 → 버킷 정책

UI 증적 수집(2026-08-25): 실제 S3 버킷 정책에서 비암호화 전송을 거부하는 조건과 Deny 효과를 확인했습니다.

7. 이행진단 결과

• 이행진단 판정: 양호
• 실제 확인 결과: DenyInsecureTransportCA12 정책문 적용
• 거부 조건: aws:SecureTransport=false
• 적용 범위: 버킷과 버킷 내부 객체의 s3:* 요청
• 보완 통제: 퍼블릭 액세스 차단과 비공개 상태 유지
• 실제 이행진단 증적 파일: ca11_ca19_after_diagnosis.txt

8. 실무 주의사항

비암호화 요청을 차단하면 오래된 애플리케이션, 프록시, 사설 도구의 S3 접속이 실패할 수 있습니다. HTTPS 사용 여부와 인증서 검증, TLS 종료 지점, 내부 구간 재암호화 여부를 변경 전에 확인해야 합니다.

컨설턴트 조언

• S3뿐 아니라 로드 밸런서, API Gateway, 데이터베이스, 관리 콘솔, VPN과 사설 API 엔드포인트의 전송 암호화를 자산별로 확인합니다.
• 정책 존재만 확인하지 말고 리소스 ARN 범위, Principal, 예외 조건과 다른 허용 정책의 우회 가능성을 검토합니다.
• TLS 버전 정책과 인증서 만료 알림을 운영하고, 구형 TLS가 필요한 예외는 승인·만료일·대체 계획을 문서화합니다.
• 프록시나 로드 밸런서에서 TLS가 종료되면 백엔드 구간도 민감도에 맞게 다시 암호화합니다.
• 적용 전 애플리케이션 접속 로그에서 HTTP·구형 TLS 사용 주체를 식별하고 소유자와 전환 일정을 합의합니다.

9. 마무리

통신 암호화는 클라이언트가 HTTPS를 선택할 것이라는 기대가 아니라 리소스 정책으로 비암호화 요청을 거부해야 안정적으로 유지됩니다. 이번 실습에서는 S3 정책으로 해당 통제를 직접 확인했습니다.