NetDriveでS3マウント時のアクセス拒否エラーを解決する

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

NetDriveをダウンロード →

無料トライアル。永久ライセンスとサブスクリプションプランあり。

マウント済みS3ドライブでAccess Deniedが表示される理由

Amazon S3へのアクセスは、2つの独立したレイヤーによって制御されている。入力したアクセスキーが属するユーザーまたはロールに付与されたIAMポリシーと、バケット自体に付与されたバケットポリシーだ。どちらのレイヤーも、もう一方の状態を知らないまま操作を拒否できる。

NetDriveがバケットを正常にマウントし、操作するには、少なくとも以下のS3アクションが必要だ。

• s3:ListBucket — オブジェクトを一覧表示し、ディレクトリビューを構築するため
• s3:GetObject — ファイルを開いた際にファイル内容を読み取るため
• s3:PutObject — ファイルをバケットに書き戻すため（読み書きマウントのみ）
• s3:DeleteObject — マウントしたドライブからファイルを削除するため（読み書きマウントのみ）

アクションが1つでも不足していると、その特定の操作で「Access Denied」が発生する。ディレクトリの閲覧はできてもファイルを開く際に拒否される、あるいはファイルを開けても保存時に拒否される、といった状況は、いずれも資格情報の完全な失敗ではなく、IAM権限が部分的にしか付与されていない兆候だ。

チェック1：NetDriveに入力した資格情報

まずは資格情報そのものを確認しよう。アクセスキーの1文字の入れ替わりや、古くなったシークレットキーは、IAMポリシーの設定ミスと同じ「Access Denied」の症状を引き起こす。

1. Open NetDrive → S3ドライブの歯車アイコンをクリックして設定を開く。
2. Access Key IDを、AWSコンソールのIAM → Users → [username] → Security credentialsに表示されている値と1文字ずつ照合する。再入力ではなくコピー＆ペーストで行うこと。
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ポリシーに必要なアクションが1つ以上不足している。これを確認する最も速い方法は、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/*"
    }
  ]
}

2つのResource値が分かれている点に注目してほしい。ListBucketはバケットARN自体に適用され、GetObject、PutObject、DeleteObjectはバケット内のオブジェクト（/*）に適用される。これらを1つのResource行にまとめてしまうのはよくあるミスで、一覧表示またはオブジェクトアクセスを静かに壊してしまう。

IAMポリシーを更新した後、オブジェクトアクセスが機能するかを素早く確認するには、NetDriveのFile Browser（マウントなしで利用可能）を使うとよい。マウントしたドライブと同じAPI呼び出しを行うが、ドライブレターは割り当てられないため、トラブルシューティング中の高速なフィードバックループになる。

チェック3：バケットポリシーの明示的な拒否

寛容なIAMポリシーであっても、バケットポリシー内の明示的なDenyによって上書きされることがある。S3 → [your bucket] → 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」エラーは、ほぼ常に次の3つの原因のいずれかに行き着く。資格情報の誤り、必要なアクションが不足したIAMポリシー、そして明示的な拒否を含むバケットポリシーだ。この順序で確認していこう — 資格情報が最も早く除外できる。他のオブジェクトストレージプロバイダーのマウントについては、macOSでAmazon S3をマウントする方法やNetDriveを使ったDevOps S3フィクスチャワークフローを参照してほしい。

— Casey, NetDrive