Azure Blob Storage での SSH ファイル転送プロトコル (SFTP) サポート

[アーティクル]
05/05/2024

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 アクセス許可モデル

SFTP クライアントは、Microsoft Entra ID を使用して認証することはできません。代わりに、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 サポートを有効にしても、他の種類のクライアントが Microsoft Entra ID を使用することはできません。 Azure portal、Azure CLI、Azure PowerShell コマンド、AzCopy だけでなく、Azure SDK と Azure REST API を使用して Blob Storage にアクセスするユーザーの場合は、引き続き Azure 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	ファイルまたはディレクトリの ACL を変更する

サブディレクトリ内の BLOB に対して書き込み操作を実行する場合、ディレクトリを開いて BLOB プロパティにアクセスするには、読み取りアクセス許可が必要です。

アクセス制御リスト (ACL)

重要

この機能は現在プレビューの段階です。ベータ版、プレビュー版、または一般提供としてまだリリースされていない Azure の機能に適用される法律条項については、「Microsoft Azure プレビューの追加使用条件」を参照してください。

ACLを使用すると、特定のディレクトリやファイルへの書き込みアクセスなど、「きめ細かい」アクセスを許可できます。 ACL の詳細については、Azure Data Lake Storage Gen2 のアクセス制御リスト (ACL) に関するページを参照してください。

ACL を使用してローカルユーザーを認証するには、まずそのローカルユーザーに対して ACL 認証を有効にする必要があります。「コンテナーにアクセス許可を付与する」を参照してください。

Note

ACL はさまざまな種類の ID に対してアクセス許可レベルを定義できますが、ローカルユーザーの認可を行うために使用できるのは、所有ユーザー、所有グループ、および他のすべてのユーザーの ID だけです。名前付きユーザーと名前付きグループは、ローカルユーザー認証ではまだサポートされていません。

次の表は、ACL 認証に使用されるローカルユーザーのプロパティについて説明したものです。

プロパティ	説明
UserId	ストレージアカウント内でのローカルユーザーの一意識別子ローカルユーザーの作成時に既定で生成されますファイルまたはディレクトリの所有ユーザーを設定するために使われます
GroupId	ローカルユーザーのグループでの識別子ファイルまたはディレクトリの所有グループを設定するために使われます
AllowAclAuthorization	ACL でこのローカルユーザーの要求を認可できるようにします

ACL のアクセス許可を評価する方法

ACL は、ローカルユーザーが操作を実行するのに必要なコンテナーのアクセス許可がない場合にのみ評価されます。アクセス許可がシステムで評価される方法が原因で、ACL を使用して、コンテナーレベルのアクセス許可によって既に付与されているアクセスを制限することができません。これは、コンテナーのアクセス許可が最初に評価され、そのアクセス許可で十分なアクセス許可が付与されている場合は、ACL が無視されるためです。

重要

ローカルユーザーにファイルの読み取りまたは書き込みアクセス権を付与するには、コンテナーのルートフォルダー、およびそのファイルに至るフォルダー階層内の各フォルダーに対する実行アクセス許可をそのローカルユーザーに付与する必要があります。ローカルユーザーが所有ユーザーまたは所有グループである場合、所有ユーザーまたは所有グループのいずれかに実行アクセス許可を適用できます。それ以外の場合は、実行アクセス許可を他のすべてのユーザーに適用する必要があります。

SFTP クライアントを使用した ACL の変更

ACL アクセス許可は、サポートされている Azure ツールまたは SDK を使用して変更でき、ローカルユーザーも変更できます。ローカルユーザーが ACL アクセス許可を変更できるようにするには、まずローカルユーザーに Modify Permissions アクセス許可を付与する必要があります。「コンテナーにアクセス許可を付与する」を参照してください。

ローカルユーザーは、ACL の所有ユーザー、所有グループ、および他のすべてのユーザーのアクセス許可レベルのみを変更できます。名前付きユーザー、名前付きグループ、および名前付きセキュリティプリンシパルの ACL エントリの追加または変更は、まだサポートされていません。

また、ローカルユーザーは、所有中のユーザーと所有グループの ID を変更することもできます。実際、所有ユーザーまたは所有グループの ID をローカルユーザー ID に変更できるのはローカルユーザーだけです。 Azure ツールや SDK を使用して ACL でローカルユーザー ID を参照することはまだできません。ディレクトリまたは BLOB の所有ユーザーまたは所有グループを変更するには、ローカルユーザーに Modify Ownership アクセス許可を付与する必要があります。

例を表示するには、「ファイルまたはディレクトリの ACL を変更する」を参照してください。

ホームディレクトリ

アクセス許可を構成する場合は、ローカルユーザーのホームディレクトリを設定することができます。 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 クライアントを使って、安全に接続し、ファイルを転送することができます。接続クライアントは、次の表に記載されているアルゴリズムを使う必要があります。

種類	アルゴリズム
ホストキー ¹	rsa-sha2-256 ² rsa-sha2-512 ² 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 ² rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹ ホストキーはここで公開されています。 ² RSA キーの長さを 2,048 ビット以上にする必要があります。

現在、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 に接続する」を参照してください。

ネットワークに関する考慮事項

SFTP はプラットフォームレベルのサービスであるため、アカウントオプションが無効になっている場合でもポート 22 は開きます。 SFTP アクセスが構成されていない場合は、すべての要求がサービスから切断を受信します。 SFTP を使用しているとき、ファイアウォール、仮想ネットワーク、またはプライベートエンドポイントの構成を通じてパブリックアクセスを制限することができます。これらの設定はアプリケーション層で適用されます。つまり、SFTP に固有のものではなく、すべての Azure Storage エンドポイントへの接続に影響を与えます。ファイアウォールおよびネットワークの構成の詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。

注意

プロトコル層で TLS のサポートを確認しようとする監査ツールは、ストレージアカウントエンドポイントに対して直接実行された場合、最低限必要なバージョンに加えて、TLS バージョンを返す場合があります。詳細については、「ストレージアカウントへの要求に必要な最小バージョンのトランスポート層セキュリティ (TLS) を適用する」を参照してください。

既知のサポートされているクライアント

次のクライアントでは、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+
AIX¹
MobaXterm v21.3

¹AllowPKCS12KeystoreAutoOpen オプションを no に設定する必要があります。

制限事項と既知の問題

Azure Blob Storage の SFTP サポートに関する制限事項と問題の完全なリストについては、制限事項と既知の問題に関する記事を参照してください。

価格と課金

SFTP の有効化には、1 時間あたりのコストがかかります。最新の価格情報については、「Azure Blob Storage の価格」を参照してください。

ヒント

パッシブ料金を回避するには、SFTP をアクティブに使用してデータを転送する場合にのみ、SFTP を有効にすることを検討してください。 SFTP サポートを有効にしてから無効にする方法のガイダンスについては、「SSH ファイル転送プロトコル (SFTP) を使用して Azure Blob Storage に接続する」を参照してください。

基になるストレージアカウントのトランザクション、ストレージ、ネットワークの価格が適用されます。すべての SFTP トランザクションは、ストレージアカウントでの読み取り、書き込み、またはその他のトランザクションに変換されます。これには、すべての SFTP コマンドと API 呼び出しが含まれます。詳細については、「Azure Blob Storage の詳細な課金モデルを理解する」を参照してください。