특정 IP 대역에서만 S3 버킷에 접근할 수 있도록 제한하는 정책 예시는 무엇인가요?

특정 IP 대역 허용 정책 (JSON)

아래 정책은 1.2.3.4/32와 5.6.7.0/24 대역에서 온 요청이 아닐 경우, 해당 버킷(my-secure-bucket)의 모든 작업을 차단하는 예시입니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-secure-bucket",
        "arn:aws:s3:::my-secure-bucket/*"
      ],
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "1.2.3.4/32",
            "5.6.7.0/24"
          ]
        },
        "Bool": {
          "aws:ViaAWSService": "false"
        }
      }
    }
  ]
}

주요 항목 설명

• Effect: Deny & Condition: NotIpAddress: "이 IP 리스트에 포함되지 않은(NotIpAddress) 모든 요청은 거부(Deny)한다"는 뜻입니다. 가장 확실한 잠금장치입니다.

• aws:SourceIp: 요청이 시작된 공인 IP 주소를 확인합니다.

• aws:ViaAWSService: 이 옵션은 매우 중요합니다. false로 설정하면 CloudFront나 Lambda 같은 다른 AWS 서비스가 이 버킷에 접근하는 것도 차단할 수 있습니다. 만약 다른 AWS 서비스를 연동 중이라면 이 부분을 신중히 설정해야 합니다.

Tip

1. "제발, 본인 IP를 먼저 확인하고 넣으세요!" 정책을 적용하는 순간, 리스트에 없는 모든 접근이 차단됩니다. 만약 본인의 현재 공인 IP를 넣지 않고 정책을 저장하면, 본인조차 버킷 설정을 수정할 수 없는 '셀프 잠금' 상태에 빠지게 됩니다. (이 경우 루트 계정으로 접속해서 풀어야 하는 번거로움이 생깁니다.)

2. 만약 EC2 인스턴스에서 S3로 접근하는 환경이라면, IP 주소 대신 VPC 엔드포인트 ID(aws:sourceVpce)를 기준으로 제한하는 것이 훨씬 안전하고 관리하기 편합니다. 인터넷망을 타지 않기 때문에 보안 수준도 한 단계 더 올라가죠.

3. 보안 정책은 한 번에 완성하려 하지 마세요. 처음에는 Deny 대신 Allow 정책으로 테스트해 보고, 정상 작동을 확인한 뒤에 강력한 Deny 정책으로 전환하는 것이 장애를 막는 방식입니다.