Amazon S3 마운트 시 Access Denied 오류 해결하기 — NetDrive

NetDrive에서 S3 버킷을 마운트하면 Windows 탐색기에 드라이브 문자가 나타나지만, 이후 모든 파일 작업에서 “Access Denied”가 반환됩니다. 드라이브는 보이는데 아무것도 접근할 수 없는 상태입니다. 이는 NetDrive가 사용 중인 IAM 자격 증명에 필요한 S3 작업 권한이 없거나, IAM 정책은 올바른데 버킷 정책이 이를 덮어쓸 때 발생합니다.

S3 버킷을 로컬 드라이브로 마운트

NetDrive 는 Google Drive, OneDrive, S3, SFTP, WebDAV 등을 Windows 와 macOS 에서 일반 드라이브처럼 보이게 합니다 — 동기화도, 전체 다운로드도 없이.

• Amazon S3와 S3 호환 스토리지(Wasabi, MinIO 등) 지원
• 파일 브라우저로 마운트 전에 버킷 접근 권한 테스트 가능
• NetDrive 3.19.7부터 S3 리전 자동 감지 지원

WindowsmacOS

Download NetDrive →

무료 체험. 평생 라이선스와 구독 플랜 제공.

마운트된 S3 드라이브에서 Access Denied가 나타나는 이유

Amazon S3 접근 권한은 두 개의 독립적인 계층으로 제어됩니다: 입력한 액세스 키가 속한 사용자 또는 역할에 연결된 IAM 정책, 그리고 버킷 자체에 연결된 버킷 정책입니다. 두 계층 중 어느 쪽이든 다른 쪽과 무관하게 작업을 거부할 수 있습니다.

NetDrive가 버킷을 정상적으로 마운트하고 작업하려면 최소한 다음 S3 작업 권한이 필요합니다:

• s3:ListBucket — 객체 목록을 가져와 디렉터리 뷰를 구성
• s3:GetObject — 파일을 열 때 내용을 읽음
• s3:PutObject — 버킷에 파일을 다시 씀 (읽기-쓰기 마운트에만 해당)
• s3:DeleteObject — 마운트된 드라이브에서 파일 삭제 (읽기-쓰기 마운트에만 해당)

작업 권한이 하나라도 빠지면 해당 작업에서 “Access Denied”가 발생합니다. 디렉터리는 탐색되지만 파일을 열 때 거부되거나, 파일은 열리지만 저장할 때 거부될 수 있는데, 둘 다 완전한 자격 증명 실패가 아니라 부분적인 IAM 권한 부여의 증상입니다.

확인 1: NetDrive에 입력한 자격 증명

먼저 자격 증명 자체부터 확인하세요. 액세스 키의 문자 하나가 뒤바뀌거나 시크릿 키가 오래된 값이어도 IAM 정책이 잘못된 것과 동일한 “Access Denied” 증상이 나타납니다.

1. Open NetDrive → S3 드라이브의 설정 아이콘(톱니바퀴)을 클릭해 설정을 엽니다.
2. AWS 콘솔의 IAM → Users → [사용자명] → Security credentials에 표시된 값과 Access Key ID를 문자 단위로 대조합니다. 다시 입력하지 말고 복사해서 붙여넣으세요.
3. Secret Access Key를 다시 입력합니다. AWS는 최초 생성 이후 이 값을 다시 보여주지 않으므로, 정확성에 조금이라도 의심이 있다면 IAM에서 새 키 쌍을 생성하고 NetDrive를 새 값으로 즉시 업데이트하세요.
4. Region 필드를 확인합니다. 버킷이 eu-west-1에 있는데 us-east-1을 설정하는 등 리전이 일치하지 않으면 요청이 잘못된 엔드포인트로 라우팅되어 403 오류가 반환됩니다. NetDrive 3.19.7부터 새 연결에는 리전 자동 감지 기능이 추가되었지만, 업그레이드 이전에 생성된 드라이브 설정에는 여전히 처음 입력한 값이 남아 있습니다. 필요하면 리전을 수동으로 업데이트하세요.

자격 증명 문제를 수정한 후 Mount를 클릭하고 IAM 계층으로 넘어가기 전에 디렉터리 탐색을 시도해 보세요.

확인 2: IAM 정책 — 필요한 S3 작업

자격 증명은 맞는데도 여전히 접근이 거부된다면, 연결된 IAM 정책에 필요한 작업 하나 이상이 빠져 있는 것입니다. 이를 가장 빠르게 확인하는 방법은 AWS IAM Policy Simulator입니다.

AWS 콘솔에서 IAM → Policy Simulator로 이동해 NetDrive에 입력한 키가 속한 IAM 사용자를 선택하고, 버킷 ARN(arn:aws:s3:::my-bucket)에 대해 s3:ListBucket을, 객체 ARN(arn:aws:s3:::my-bucket/*)에 대해 s3:GetObject를 테스트합니다. 시뮬레이터가 “Denied”를 반환하면 누락된 작업을 부여하는 정책을 추가하세요.

단일 버킷에 대한 읽기-쓰기 접근을 위한 최소 정책 예시:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": "arn:aws:s3:::my-bucket"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

두 개의 서로 다른 Resource 값에 주목하세요: ListBucket은 버킷 ARN 자체에 적용되고, GetObject, PutObject, DeleteObject는 그 안의 객체(/*)에 적용됩니다. 이를 하나의 Resource 줄로 합치는 것은 목록 조회나 객체 접근을 조용히 망가뜨리는 흔한 실수입니다.

IAM 정책을 업데이트한 후 객체 접근이 작동하는지 빠르게 확인하려면 NetDrive의 File Browser(마운트 없이 사용 가능)를 이용하세요. 마운트된 드라이브와 동일한 API 호출을 수행하지만 드라이브 문자를 할당하지 않으므로, 문제 해결 중 빠른 피드백 루프로 활용할 수 있습니다.

확인 3: 버킷 정책의 명시적 거부

허용적인 IAM 정책이라도 버킷 정책의 명시적 Deny에 의해 덮어써질 수 있습니다. S3 → [해당 버킷] → Permissions → Bucket policy로 이동해 "Effect": "Deny" 문이 있는지 확인하세요. 흔한 원인은 다음과 같습니다:

• VPC 엔드포인트 제한 — 특정 VPC 엔드포인트(aws:SourceVpc)에서 시작되지 않은 요청을 거부하는 정책. 데스크톱 NetDrive는 VPN을 경유하지 않는 한 공용 인터넷을 통해 연결됩니다.
• IP 허용 목록 — aws:SourceIp를 사용해 내 컴퓨터의 공인 IP가 아닌 요청을 차단하는 정책.
• HTTP 거부 — aws:SecureTransport가 false일 때 요청을 거부하는 문. NetDrive는 S3 요청에 HTTPS를 사용하므로(버전 3.1.234부터 확인됨) 보통은 문제가 되지 않지만, 버킷 정책이 방어적으로 작성되었다면 확인할 가치가 있습니다.

내 접근 패턴에 해당하는 제한 조건을 발견했다면, 조건을 완화하거나 우선 적용되는 명시적 Allow에 해당 IAM 사용자를 추가하세요.

마무리

NetDrive에서 발생하는 S3 “Access Denied” 오류는 거의 항상 세 가지 원인 중 하나로 귀결됩니다: 잘못된 자격 증명, 필요한 작업이 빠진 IAM 정책, 명시적 거부가 있는 버킷 정책. 이 순서대로 확인하세요. 자격 증명이 가장 빠르게 배제할 수 있는 원인입니다. 다른 객체 스토리지 공급자 마운트에 대해서는 mounting Amazon S3 on macOS 또는 DevOps S3 fixture workflow with NetDrive를 참고하세요.

— Casey, NetDrive