Azure Blob Storage 認証エラーの解決方法 — NetDrive

先週まで問題なくマウントできていた Azure Blob ドライブが、突然再接続を拒否するようになった――エクスプローラーにはビルド成果物の代わりにドライブレターと認証エラーが表示され、パイプライン側には何も変更していない。こうしたケースはほぼ次の3つのいずれかが原因です。SAS トークンの期限切れ、NetDrive がまだ把握していないアカウントキーのローテーション、あるいはマシンのパブリック IP をブロックし始めたストレージアカウントのファイアウォールルールです。

Azure Blob Storage をローカルドライブとしてマウント

NetDrive を使えば Google Drive、OneDrive、S3、SFTP、WebDAV などが Windows と macOS でネイティブドライブとして表示されます — 同期も、まるごとダウンロードも不要です。

• アカウントキーまたはスコープ付き SAS トークンで接続
• File Browser でマウント前にコンテナアクセスをテスト可能
• バックグラウンドアップロードで大きな書き込みをクリティカルパスから排除

WindowsmacOS

NetDrive をダウンロード →

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

動いていた Azure Blob ドライブが突然認証に失敗する理由

パスワード間違いとは異なり、Azure Blob の認証失敗が「最初から間違っていた」ケースはまれです。NetDrive は Azure Blob Storage に対して2種類の認証情報をサポートしています。ストレージアカウントのプライマリまたはセカンダリのaccount key、あるいはコンテナにスコープされたShared Access Signature (SAS) トークンです。どちらも異なる意味で時間に左右されます――SAS トークンは生成時に設定した明確な有効期限を持ち、アカウントキーは Azure Portal で誰かが再生成するまで有効ですが、再生成されると古い値を使い続けているすべての接続が即座に無効になります。

3つ目の原因は認証情報とはまったく別のところにあります。ストレージアカウントのネットワークファイアウォールです。Networking → Firewalls and virtual networks が「All networks」ではなく「Selected networks」に設定されている場合、Azure は認証情報をチェックする前にリクエストを拒否します――そしてその結果生じるエラーは、キーの間違いとまったく同じように見えることがあります。

確認1: SAS トークンの期限切れまたはアカウントキーのローテーション

まずはここから確認しましょう――「昨日は動いていたのに今日は動かない」というケースの大半はこれで解決します。

1. Azure Portal でストレージアカウントを開き、ドライブがどちらの認証情報タイプで設定されているかを確認します。
2. SAS トークンを使用している場合: Security + networking → Shared access signature に移動し、生成したトークンの Expiry date がまだ過ぎていないことを確認します。SAS トークンは30日、90日、365日で期限切れになるよう設定されることが多く、設定時には十分な期間に思えた値です。
3. アカウントキーを使用している場合: Security + networking → Access keys に移動し、key1 または key2 が最近再生成されていないか確認します。キーの再生成は、NetDrive を含め古い値を使用しているすべてのクライアントに対して即座に無効化されます。
4. 新しい SAS トークン(コンテナに対して最低でも Read、Write、Delete、List、Add、Create 権限)を生成するか、現在のアカウントキーをコピーします。
5. NetDrive を開き → 対象の Azure Blob ドライブの歯車アイコンをクリックして接続設定を開き、新しい認証情報を Authentication フィールドに貼り付けます。
6. Save をクリックし、ドライブを再接続します。

確認2: ストレージアカウントのファイアウォールルール

認証情報が最新であるにもかかわらずドライブが認証できない場合、次に確認すべきはストレージアカウントのネットワークルールです。

1. Azure Portal でストレージアカウントの Networking → Firewalls and virtual networks を開きます。
2. 設定が Enabled from selected virtual networks and IP addresses になっている場合、マシンのパブリック IP が明示的に許可されていない限り NetDrive のリクエストは拒否されます。
3. マシンの現在のパブリック IP を確認します――ブラウザ検索やコマンドラインツールから簡単に確認できますが、変わっていないと決めつけず直接確認する価値があります。

4. その IP を Firewall → Address range に追加するか、セットアップで IP ベースの制限が不要であればすべてのネットワークを許可するようルールを切り替えます。
5. Azure でネットワークルールの変更を保存します――反映まで1〜2分かかることがあります――その後 NetDrive で接続を再試行します。

自宅やオフィスの動的 IP のインターネット接続は、ここで繰り返し問題を起こしやすい要因です。ファイアウォールルールを追加した時点では正しかったのに、その後 ISP が新しいアドレスを割り当てたケースです。

修正の確認

認証情報またはファイアウォールルールを更新したら、ドライブを再接続し、ドライブ一覧に「Connected」と表示されているだけでなく、実際にデータを提供していることを確認します。

マウントされたドライブをエクスプローラーまたは Finder で開き、見覚えのあるファイルが入ったフォルダを一覧表示します。ディレクトリ一覧が表示され、ファイルがエラーなく開ければ、認証情報とネットワークパスの両方が正常に機能しています。

まとめ

NetDrive における Azure Blob 認証失敗は、元のセットアップのタイプミスよりも、SAS トークンの期限切れ、アカウントキーのローテーション、ストレージアカウントのファイアウォールルールに起因することがはるかに多いです。まずは確認が早い認証情報から確認し、次にネットワーキングに進みましょう。初回接続の手順については Mount Azure Blob Storage on Windows with NetDrive を、ストレージアカウントが Blob ではなく Azure File Storage を使用している場合は Mount Azure File Storage on Windows で同等のセットアップを確認できます。

— Alex, NetDrive