Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) サポート
BLOB ストレージでは、SSH ファイル転送プロトコル (SFTP) がサポートされるようになりました。 このサポートにより、SFTP エンドポイント経由で Blob Storage に安全に接続できます。ファイル アクセス、ファイル転送、ファイル管理のために SFTP を活用できます。
詳しい解説は、こちらのビデオでご覧ください。
Azure では、Azure Blob サービスの REST API、Azure SDK、および AzCopy などのツールを使用して、Blob Storage アカウントに安全にデータを転送できます。 ただし、レガシ ワークロードでは、多くの場合、SFTP などの従来のファイル転送プロトコルが使用されます。 カスタム アプリケーションを更新して REST API と Azure SDK を使用することもできますが、コードを大幅に変更する必要があります。
この機能がリリースされる前は、SFTP を使用してデータを Azure Blob Storage に転送する場合は、サード パーティ製品を購入するか、独自のソリューションを調整する必要がありました。 カスタム ソリューションの場合は、SFTP サーバーをホストする仮想マシン (VM) を Azure に作成し、複雑なアーキテクチャを更新、修正、管理、スケーリング、保守する必要があります。
現在は、Azure Blob Storage の SFTP サポートにより、1 回クリックすることで Blob Storage アカウントの SFTP エンドポイントを有効にできます。 その後、認証用のローカル ユーザー ID を設定して、ポート 22 を介して SFTP を使用しストレージ アカウントに接続できます。
この記事では、Azure Blob Storage の SFTP サポートについて説明します。 ストレージ アカウントに対して SFTP を有効にする方法については、「SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する」を参照してください。
注意
SFTP はプラットフォーム レベルのサービスであるため、アカウント オプションが無効になっている場合でもポート 22 は開きます。 SFTP アクセスが構成されていない場合は、すべての要求がサービスから切断を受信します。
SFTP と階層型名前空間
SFTP のサポートでは、階層型名前空間を有効にする必要があります。 階層型名前空間は、コンピューター上のファイル システムを整理するのと同じ方法で、オブジェクト (ファイル) をディレクトリとサブディレクトリの階層に整理します。 階層型名前空間は、スケールが線形で、データ容量もパフォーマンスも低下しません。
階層型名前空間では、さまざまなプロトコルがサポートされています。 SFTP は、これらの使用可能なプロトコルの 1 つです。 次の図は、複数のプロトコルと REST API を介したストレージ アクセスを示しています。 読みやすさを考慮して、この画像では Gen2 REST という用語を使用して、Azure Data Lake Storage Gen2 REST API を参照しています。
SFTP アクセス許可モデル
Azure Blob Storage は、SFTP 経由の Microsoft Entra 認証または認可をサポートしていません。 代わりに、SFTP には、"ローカル ユーザー" と呼ばれる新しい形式の ID 管理を使います。
ローカル ユーザーは、認証にパスワードまたは Secure Shell (SSH) 秘密キー資格情報のいずれかを使う必要があります。 1 つのストレージ アカウントに最大で 2,000 人のローカル ユーザーを作成できます。
アクセス許可を設定するには、ローカル ユーザーを作成し、認証方法を選択します。 次に、アカウント内の各コンテナーに対して、そのユーザーに付与するアクセス レベルを指定できます。
注意
ローカル ユーザーは、RBAC (ロールベースのアクセス制御) や ABAC (属性ベースのアクセス制御) などの他の Azure Storage アクセス許可モデルと同時に使用することはできません。 ACL (アクセス制御リスト) は、プレビュー レベルでローカル ユーザーに対してサポートされます。
たとえば、Jeff は、Microsoft Entra の ID を介して、コンテナー con1 に格納されているファイル foo.txt に対する読み取り専用アクセス許可 (RBAC または ABAC を使って制御できます) を持っているとします。 Jeff が NFS (ルート/スーパーユーザーとしてマウントされていない場合)、BLOB REST、または Data Lake Storage Gen2 REST を介してストレージ アカウントにアクセスしている場合、これらのアクセス許可が適用されます。 ただし、Jeff にコンテナー con1 内のデータの削除アクセス許可を持つローカル ユーザー ID がある場合は、ローカル ユーザー ID を使用して SFTP 経由で foo.txt を削除できます。
SFTP が有効なストレージ アカウントの場合、Azure Blob Storage のセキュリティ設定をすべて使い、Azure portal、Azure CLI、Azure PowerShell コマンド、AzCopy だけでなく、Azure SDKS と Azure REST API を使って BLOB Storage にアクセスするユーザーの認証と認可を行うことができます。 詳細については、「Azure Data Lake Storage Gen2 のアクセス制御モデル」を参照してください。
認証方法
パスワードまたは Secure Shell (SSH) の公開キーと秘密キーのペアを使って、SFTP 経由で接続するローカル ユーザーを認証できます。 両方の形式の認証を構成し、接続しているローカル ユーザーにどちらを使用するかを選んでもらうことができます。 ただし、認証を成功させるために、有効なパスワードと有効な公開キー/秘密キーのペアの両方が必要な多要素認証はサポートされていません。
パスワード
カスタム パスワードを設定することはできません。代わりに、Azure がパスワードを生成します。 パスワード認証を選択した場合、ローカル ユーザーの構成が完了すると、パスワードが提供されます。 必ずそのパスワードをコピーし、後で見つけられる場所に保存してください。 そのパスワードを Azure から再度取得することはできません。 パスワードを紛失した場合は、新しいパスワードを生成する必要があります。 セキュリティ上の理由から、自分でパスワードを設定することはできません。
SSH キーの組
公開キーと秘密キーのペアは、Secure Shell (SSH) の認証の最も一般的な形式です。 秘密キーはシークレットであり、ローカル ユーザーのみが知っている必要があります。 公開キーは Azure に格納されます。 SSH クライアントでは、ローカル ユーザー ID を使ってストレージ アカウントに接続するときに、公開キーとシグネチャを含むメッセージを送信します。 Azure では、メッセージが検証され、そのユーザーとキーがストレージ アカウントによって認識されることが確認されます。 詳細については、SSH とキーの概要に関するページをご覧ください。
秘密キーと公開キーの組で認証することを選択した場合は、それを生成するか、Azure に既に保存されているものを使用するか、既存の公開キーとプライベート キーのペアの公開キーを Azure に提供することができます。 ローカル ユーザーごとに最大 10 個の公開キーを使用できます。
コンテナーのアクセス許可
コンテナー レベルのアクセス許可の場合、アクセスを許可するコンテナーと、許可するアクセス レベル (読み取り、書き込み、一覧表示、削除、作成、所有権の変更、アクセス許可の変更) を選択できます。 これらのアクセス許可は、コンテナー内のすべてのディレクトリとサブディレクトリに適用されます。 各ローカル ユーザーには、最大 100 のコンテナーへのアクセス権を付与できます。 コンテナーのアクセス許可は、ローカル ユーザーの作成後にも更新できます。 次の表では、各アクセス許可について詳しく説明します。
| アクセス許可 | Symbol | 説明 |
|---|---|---|
| Read | r | |
| Write | 。 | |
| List | l | |
| 削除 | d | |
| 作成 | c | |
| 所有権を変更する | o | |
| アクセス許可の変更 | P |
サブディレクトリ内の BLOB に対して書き込み操作を実行する場合、ディレクトリを開いて BLOB プロパティにアクセスするには、読み取りアクセス許可が必要です。
ACL
ディレクトリまたは BLOB のレベルのアクセス許可では、ADLS Gen2 ACL によって使われる所有ユーザー、所有グループ、モードを変更できます。 ほとんどの SFTP クライアントでは、これらのプロパティを変更するためのコマンドが公開されています。 次の表では、一般的なコマンドについて詳しく説明します。
| コマンド | 必要なコンテナーのアクセス許可 | 説明 |
|---|---|---|
| chown | o | |
| chgrp | o | |
| chmod | P |
所有ユーザーおよび所有グループを変更するために必要な ID は、ローカル ユーザーの新しいプロパティの一部です。 次の表では、ローカル ユーザーの新しい各プロパティについて詳しく説明します。
| プロパティ | 説明 |
|---|---|
| UserId | |
| GroupId | |
| AllowAclAuthorization |
必要な ACL が構成されていれば、ローカル ユーザーは、AllowAclAuthorization を有効にすると、ACL を使って要求を認可できます。 RBAC と同様に、コンテナーのアクセス許可は ACL と併用できます。 ローカル ユーザーが十分なコンテナー アクセス許可を持っていない場合にのみ、ACL が評価されます。 詳細については、「Azure Data Lake Storage Gen2 のアクセス制御モデル」を参照してください。
ホーム ディレクトリ
アクセス許可を構成する場合は、ローカル ユーザーのホーム ディレクトリを設定することができます。 SFTP 接続要求で他のコンテナーが指定されていない場合、ホーム ディレクトリは、ユーザーが既定で接続するディレクトリになります。 たとえば、Open SSH を使用して次の要求を行ったとします。 この要求では、sftp コマンドの一部としてコンテナー名またはディレクトリ名が指定されていません。
sftp myaccount.myusername@myaccount.blob.core.windows.net
put logfile.txt
ユーザーのホーム ディレクトリを mycontainer/mydirectory に設定すると、そのディレクトリに接続します。 その後、logfile.txt ファイルは mycontainer/mydirectory にアップロードされます。 ホーム ディレクトリを設定しなかった場合、接続の試行は失敗します。 代わりに、ユーザーを接続するには、要求と共にコンテナーを指定し、SFTP コマンドを使用して、ファイルをアップロードする前にターゲット ディレクトリに移動する必要があります。 次の例はこのことを示します。
sftp myaccount.mycontainer.myusername@myaccount.blob.core.windows.net
cd mydirectory
put logfile.txt
Note
ホーム ディレクトリは、接続するローカル ユーザーが最初に配置されるディレクトリに過ぎません。 ローカル ユーザーは、適切なコンテナー アクセス許可を持っている場合、接続しているコンテナー内の他のパスに移動できます。
サポートされているアルゴリズム
さまざまな SFTP クライアントを使って、安全に接続し、ファイルを転送することができます。 接続クライアントは、次の表に記載されているアルゴリズムを使う必要があります。
| 種類 | アルゴリズム |
|---|---|
| ホスト キー 1 | rsa-sha2-256 2 rsa-sha2-512 2 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 |
| キーの交換 | ecdh-sha2-nistp384 ecdh-sha2-nistp256 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group-exchange-sha256 |
| 暗号/暗号化 | aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-ctr aes192-ctr aes256-ctr |
| 整合性/MAC | hmac-sha2-256 hmac-sha2-512 hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com |
| 公開キー | ssh-rsa 2 rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 |
1 ホスト キーはここで公開されています。 2 RSA キーの長さを 2048 ビット以上にする必要があります。
現在、SFTP による Azure Blob Storage のサポートでは、セキュリティの考慮事項に基づいて、暗号アルゴリズムのサポートを制限しています。 データに安全にアクセスするために、Microsoft セキュリティ開発ライフサイクル (SDL) で承認されたアルゴリズムを利用することを強くお勧めします。
現時点では、Microsoft Security SDL に従っており、ssh-dss、diffie-hellman-group14-sha1、diffie-hellman-group1-sha1、diffie-hellman-group-exchange-sha1、hmac-sha1、hmac-sha1-96 のサポートは計画されていません。 アルゴリズムのサポートは今後変更される可能性があります。
SFTP を使用した接続
開始するには、SFTP サポートを有効にし、ローカル ユーザーを作成し、そのローカル ユーザーにアクセス許可を割り当てます。 続いて、任意の SFTP クライアントを使用して、ファイルを安全に接続してから転送できます。 ステップ バイ ステップ ガイダンスについては、「SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する」を参照してください。
既知のサポートされているクライアント
次のクライアントでは、Azure Blob Storage 用の SFTP と互換性のあるアルゴリズムがサポートされています。 接続で問題が発生している場合は、Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) のサポートに関する制限事項と既知の問題に関するページを参照してください。 この一覧は完全なものではなく、時間が経つと変更される可能性があります。
- AsyncSSH 2.1.0 以降
- Axway
- Cyberduck 7.8.2 以降
- edtFTPjPRO 7.0.0 以降
- FileZilla 3.53.0 以降
- libssh 0.9.5 以降
- Maverick Legacy 1.7.15 以降
- Moveit 12.7
- OpenSSH 7.4 以降
- paramiko 2.8.1 以降
- phpseclib 1.0.13 以降
- PuTTY 0.74 以降
- QualysML 12.3.41.1 以降
- RebexSSH 5.0.7119.0 以降
- Salesforce
- ssh2js 0.1.20 以降
- sshj 0.27.0 以降
- SSH.NET 2020.0.0 以降
- WinSCP 5.10 以降
- Workday
- XFB.Gateway
- JSCH 0.1.54+
- curl 7.85.0+
- AIX1
- MobaXterm v21.3
1AllowPKCS12KeystoreAutoOpen オプションを no に設定する必要があります。
制限事項と既知の問題
Azure Blob Storage の SFTP サポートに関する制限事項と問題の完全なリストについては、制限事項と既知の問題に関する記事を参照してください。
価格と課金
SFTP エンドポイントを有効にすると、時間単位のコストがかかります。 最新の価格情報については、「Azure Blob Storage の価格」を参照してください。
ヒント
パッシブ料金を回避するには、SFTP をアクティブに使用してデータを転送する場合にのみ、SFTP を有効にすることを検討してください。 SFTP サポートを有効にしてから無効にする方法のガイダンスについては、「SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する」を参照してください。
基になるストレージ アカウントのトランザクション、ストレージ、ネットワークの価格が適用されます。 すべての SFTP トランザクションは、ストレージ アカウントでの読み取り、書き込み、またはその他のトランザクションに変換されます。 これには、すべての SFTP コマンドと API 呼び出しが含まれます。 詳細については、「Azure Blob Storage の詳細な課金モデルを理解する」を参照してください。