次の方法で共有

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 を介したストレージ アクセスを示しています。 読みやすさを考慮して、この画像では REST という用語を使用して、Azure Data Lake Storage REST API を参照しています。

階層型名前空間

SFTP アクセス許可モデル

SFTP クライアントは、Microsoft Entra ID を使用して認証することはできません。 代わりに、SFTP には、"ローカル ユーザー" と呼ばれる新しい形式の ID 管理を使います。

ローカル ユーザーは、認証にパスワードまたは Secure Shell (SSH) 秘密キー資格情報のいずれかを使う必要があります。 1 つのストレージ アカウントに最大で 8,000 のローカル ユーザーを作成できます。

アクセス許可を設定するには、ローカル ユーザーを作成し、認証方法を選択します。 次に、アカウント内の各コンテナーに対して、そのユーザーに付与するアクセス レベルを指定できます。

注意

ローカル ユーザーは、RBAC (ロールベースのアクセス制御) や ABAC (属性ベースのアクセス制御) などの他の Azure Storage アクセス許可モデルと同時に使用することはできません。 アクセス制御リスト (ACL) は、プレビュー レベルでローカル ユーザーに対してサポートされます。

たとえば、Jeff は、Microsoft Entra の ID を介して、コンテナー con1 に格納されているファイル foo.txt に対する読み取り専用アクセス許可 (RBAC または ABAC を使って制御できます) を持っているとします。 Jeff が NFS (ルート/スーパーユーザーとしてマウントされていない場合)、BLOB REST、または Data Lake Storage 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 のアクセス制御モデル」を参照してください。

認証方法

パスワードまたは 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 のアクセス制御リスト (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 クライアントを使って、安全に接続し、ファイルを転送することができます。 接続クライアントは、次の表に記載されているアルゴリズムを使う必要があります。

    種類 アルゴリズム
    ホスト キー 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 キーの長さを 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 以降
    • Five9
    • libssh 0.9.5 以降
    • Maverick Legacy 1.7.15 以降
    • Moveit 12.7
    • Mule 2.1.2 以降
    • 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 の有効化には、1 時間あたりのコストがかかります。 最新の価格情報については、「Azure Blob Storage の価格」を参照してください。

    ヒント

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

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

    関連するコンテンツ