Azure Blob StorageのSSHファイル転送プロトコル(SFTP)サポートにより、ストレージアカウントがポート22に直接応答できるようになり、ユーザーがすでに接続しているプロトコルと同じものをサーバーを動かさずに利用できます。 今日、仮想マシン(VM)上でSFTPサーバーをホストしている場合、パッチを当てるOSや容量、ランディングディスクからファイルを移動するコピージョブもありません。なぜなら、アップロードしたデータが自動的にブロブになるからです。
この記事では、セルフホスト型SFTPサーバーとAzure Blob Storage SFTPをコスト、パフォーマンス、運用、セキュリティの面で比較します。 また、移行前に互換性を確認する方法や、単一のワークロードで変更を検証する方法も説明しています。
ファイルがストレージアカウントに届く仕組み
セルフホストサーバーでは、転送はあなたが所有し管理する複数のコンポーネントを通過します。 以下の画像は典型的な転送のパターンを示しています。
ファイルはディスクに届き、あなたが作成したプロセスが必要な場所に移動します。 すべてのホップはあなたが所有しています:VM、オペレーティングシステム、SSHデーモン、ディスクとその保持、コピージョブ、そしてその周囲の監視。 コピーが完了するまでは、データは2か所に存在し、どちらも記録システムではありません。
Azure Blob Storage SFTPでは、ストレージアカウント自体がプロトコルを終了します。 以下の画像はこの転送パターンを示しています。
アップロードはブロブ です 。 ランディングディスクもコピージョブもありません。コピーするものが何もないからです。 転送が完了すると、そのファイルはBlob REST API、Azure Data Lake Storage、Network File System(NFS) 3.0、Azure Event Grid、そしてすでにそのアカウントを指す処理で利用可能になります。
変わるのはホスト名だけです。 接続してデータを転送するユーザーにとっては、それ以外はすべて同じままです。 同じプロトコル、同じクライアントツール、同じ認証モデルを使っています。
コストとセキュリティを考慮しつつクラウドへの移行を目指すなら、この方法は実用的な出発点となります。 新しい移転パターンを採用しているわけではなく、すでに運用しているインフラの下にあるインフラを取り除くのです。
Cost
SFTPを有効にすると、誰も接続していなくても、SFTPが有効になるたびに時間単位の料金が発生します。 それ以外のものはすべて標準の口座料金で請求されており、静止時の容量、取引、退出を含めて。 すべてのSFTPコマンドはアカウント内の読み取り、書き込み、その他の取引に変換されます。 SFTP経由でデータが移動した場合、別途ギガバイト単位の料金がかかることはありません。
送金が定められた期間内に行われる場合は、必要な時だけSFTPを有効にし、その間の料金を回避できます。
Note
現在の時間単価料金については、Azure Blob Storage Pricingページをご覧ください。 そのページで、ファイル構造ドロップダウンリストで階層的な名前空間(NFS v3.0、SFTPプロトコル)を選択した場合のみ、そのページで充電が見えます。
以下の表は、今日あなたが走ったものに基づいて期待できる結果を示しています。
| 現在実行しているもの | Blob Storage SFTPはおそらく | なぜでしょうか |
|---|---|---|
| 1台または2台のvCPUを搭載した単一のVMです | より高額 | 1時間あたりのエンドポイント料金は、小規模なVMの計算コストを上回ります。 それが現在の設置規模のすべてであれば、コストを理由に移行することはありません。 しかし、運用効率が引っ越しの理由になるかもしれません。 これらの効率化については、この記事の 「オペレーション 」セクションで詳しく知ることができます。 |
| 持続的なスループット対応のVMで、マネージドディスクとバックアップを備えています | ほぼ同じです | エンドポイントのチャージは計算、ディスク、バックアップを相殺します。 |
| 可用性のために複数のインスタンス、または災害復旧のための第二のリージョンが必要です | 大幅に少ない | 余分なコンピューティングリソースや第2リージョンの費用を支払わずに済むようになります。 |
| エンジニアリング工数を含めた場合、前述のいずれの行でも該当します | Less | パッチ、キーローテーション、オンコールタイムはどちらの請求にも含まれていません。 |
各選択肢を公平に比較するために、計算コスト、オペレーティングシステムとランディングディスク、バックアップのコストも見積もりに含めてください。 ロードバランサーやパブリックIPアドレス、または展開している場合の第二のリージョンを含めてください。多くのSFTPサーバーはこれらを使わずに単一のVMとして動作します。
見落としやすいコストが二つあります。 まず、データは通常、ランディングディスク と 宛先に保持期間中ずっと保管されるため、両方に料金を支払うことになります。 次に、パッチ適用、キーローテーション、コピー作業のメンテナンスにかかるエンジニアリング時間は請求書には全く記載されません。
価格計算機ではなく既存のリソースグループで コスト分析 を使い、実際に請求されているものから計算できるようにしましょう。 現在の料金については、Azure Blob Storageの価格設定およびAzure Blob Storageのプランおよび管理コストをご覧ください。
Performance
VMの上限は、そのSKUによって決まります。ネットワーク帯域幅、ディスクスループット、そしてSSH暗号化に残るCPUです。 ストレージアカウントの上限は、アカウントの入金およびリクエストレートの上限であり、かなり高く、あなたが手間をかけずに達成できます。
スループットは同時接続数に応じてスケールし、プレミアムブロックブロブアカウントは標準的な汎用v2アカウントの約2.3倍の帯域幅をシングルクライアントで達成します。 チューニングガイダンスについては SFTP性能の考慮事項を参照してください。
オペレーション
Azure Blob Storage SFTPは運用効率を向上させます。
ストレージアカウントがSFTPを終了するため、VM、ランディングディスク、コピージョブはすべて消え、それらを稼働させる作業も消えてしまいます。 もはやオペレーティングシステムのパッチ適用、SSHデーモンの強化、容量計画、高可用性や災害復旧の構築・テスト、ファイルをストレージに移すパイプラインのサポートなど、必要ありません。
ホストキー管理はその一例です。 VMを再構築するとSSHホストキーが変わります。意図的に保持しない限り、クライアントツールは予期せぬホストキーの変更を機械の中間攻撃とみなします。 したがって、定期的なメンテナンスは接続するすべての人との調整作業となります。 対照的に、AzureはSFTPホストキーを公開するため、クライアントツールはそれらを文書化されたソースと照らして検証できます。 SFTPについてはホストキーを参照してください。
セキュリティ
セルフホスト型のOpenSSHサーバーは、パスワード認証と公開鍵認証の両方をサポートしています。 アカウント、 sshd 設定、鍵の配布やローテーションはあなたが所有します。
Azure Blob Storage SFTPはこれら両方の方法をサポートし、Microsoft Entra IDも追加しています。 各ユーザーに適した方法を選択できます:
| Method | どのように機能するのか | 最適な用途 |
|---|---|---|
| Password | Azureはパスワードを生成し、一度表示されます。 カスタムパスワードは設定できないので、弱いパスワードや使い回しはできません。 | すぐに始める |
| SSHキーペア | 公開鍵を提供または生成し、ローカルユーザーごとに最大10個まで可能です。 | 非アテンド型の自動転送 |
| Microsoft Entra ID | ユーザーはEntra IDで認証し、Azureロールベースアクセス制御(RBAC)、Azure属性ベースアクセス制御(ABAC)、POSIXアクセス制御リスト(ACL)によって認可された65分間有効な証明書を受け取ります。 | アイデンティティガバナンスが重要な場所では推奨されています |
Microsoft Entra IDは両アプローチの最も重要な違いです。 VM上でもストレージアカウントでも、どんなローカル認証情報でも、その秘密は長持ちし、他の資産に適用するアイデンティティコントロールの外に位置します。
Entra IDの証明書は65分で期限切れになるため、誤った認証情報は自動的に機能しなくなります。 多要素認証と条件付きアクセスは、ファイル転送にも他のすべてのものと同様に適用されます。 アカウントが無効になると、SFTPへのアクセスは同時に終了します。 外部IDを使うことで、ファイルを交換する組織は自分のテナントから認証できるようになり、もはやその組織の代わりに認証情報を発行・保存する必要がなくなりました。
ローカルユーザーは引き続き完全にサポートされているため、Entra IDの採用ペースは自由に可能です。
ID 機能に加えて、ストレージ アカウントには、本来であれば自分で構築して維持しなければならない各種制御機能が用意されています:
Microsoft セキュリティ開発ライフサイクルで承認されたアルゴリズムのみが受け入れられるため、
ssh-dssやSHA-1ベースの鍵交換のような弱い選択肢は利用できません。プライベートエンドポイントは トラフィックを仮想ネットワーク上に保持します。
Microsoft Defender for Storageは、インストールやメンテナンスが必要なスキャナーなしでアップロードされたマルウェアをスキャンします。
静止時の暗号化、顧客管理鍵、不変性ポリシー、診断ログは、SFTPを通じてアップロードされたファイルに対して、他のブロブと同様に適用されます。
詳細については、「SFTP権限モデル」および「Microsoft Entra IDを使ったSFTP上のBlob Storageへのアクセスを認可する」をご覧ください。
移行前に互換性を確認してください
ほとんどのワークロードは変更なしで移行し、Azure Blob Storageは幅広いSFTPクライアントツールをサポートしています。 ご自身のシナリオを確認するために、 サポートされている既知のクライアント や SFTPの制限や既知の問題点をご覧ください。
これらの項目は早めに確認してください。なぜなら、これらは仕事量が as-is移動できない最も一般的な理由だからです:
アクセスパス内の既存のACL構成。
他の組織が許可リストにする静的なアウトバウンドIPアドレスです。
管理されたファイル転送ワークフローやAS2の要件です。
1つの負荷で試してみてください
非本番ストレージアカウントでSFTPを有効にし、既存のサーバーと並行して2週間、低リスクフィードを1つ稼働させましょう。 スループット、互換性、コストの数値は自分のワークロードから得られ、見積もりよりも有用です。