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 経由の Azure Active Directory (Azure AD) 認証または認可をサポートしていません。 代わりに、SFTP には、"ローカル ユーザー" と呼ばれる新しい形式の ID 管理を使います。

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

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

注意事項

ローカル ユーザーは、RBAC (ロールベースのアクセス制御)、ABAC (属性ベースのアクセス制御)、ACL (アクセス制御リスト) などの他の Azure Storage アクセス許可モデルと相互運用できません。

たとえば、Jeff には、コンテナー con1 に保存されているファイル foo.txt の Azure AD ID を介して読み取り専用アクセス許可 (RBAC、ABAC、または ACL を使用して制御できます) があります。 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
  • アップロード ファイルが存在しない場合は作成する
  • ディレクトリが存在しない場合は作成する
    		•

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

    ホーム ディレクトリ

    アクセス許可を構成する場合は、ローカル ユーザーのホーム ディレクトリを設定することができます。 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
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384

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

    現在、SFTP による Azure Blob Storage のサポートでは、セキュリティの考慮事項に基づいて、暗号アルゴリズムのサポートを制限しています。 データに安全にアクセスするために、Microsoft セキュリティ開発ライフサイクル (SDL) で承認されたアルゴリズムを利用することを強くお勧めします。

    現時点では、Microsoft Security SDL に従っており、ssh-dss、diffie-hellman-group14-sha1、diffie-hellman-group1-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

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

    制限事項と既知の問題

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

    価格と課金

    SFTP エンドポイントを有効にすると、時間単位のコストがかかります。 最新の価格情報については、「Azure Blob Storage の価格」を参照してください。

    ヒント

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

    基になるストレージ アカウントのトランザクション、ストレージ、ネットワークの価格が適用されます。 詳細については、「Azure Blob Storage の詳細な課金モデルを理解する」を参照してください。

    関連項目