Guidance Required for Azure SFTP Architecture with Private Storage Account

Sumit Gaur 455 Reputation points

Hi Team,

We have a requirement to set up SFTP on Azure for our team and are currently evaluating the use of an SFTP-enabled Azure Storage Account as the SFTP server.

Our organization policy requires all Storage Accounts to remain private, so the Storage Account has been configured with a Private Endpoint and is currently accessible only internally or through on-premises connectivity.

However, we now have a requirement to expose SFTP access externally/publicly for a limited set of users while still maintaining the Storage Account itself as private.

We are exploring whether there is an Azure-native service or recommended architecture that can be placed in front of the Storage Account to act as a reverse proxy or secure entry point for SFTP traffic, similar to how Application Gateway or reverse proxies are used for HTTPS-based workloads.

Could you please suggest:

  • Recommended architecture patterns for this scenario
  • Azure-native services/components that support this setup
  • Any reference documentation or best practices for securely exposing SFTP-backed Storage Accounts externally while keeping the Storage Account private

PS: we don't want to enable storage account with limited public access with providing access to users by whitelisting their public IP on the storage account.

  1. Saraswathi Devadula 16,025 Reputation points • Microsoft External Staff • Moderator

    Hello Sumit Gaur you can absolutely keep your Storage Account completely locked down on a private endpoint and still let a handful of external users SFTP in. In Azure there are two common “reverse‐proxy” patterns you can lean on:

    Azure Firewall DNAT “hub-and-spoke” pattern • Deploy Azure Firewall in a central (hub) VNet with its own public static IP. • Peer or deploy your Storage Account’s private endpoint into that VNet (or into a spoke that’s peered to the hub). • On the Firewall create a DNAT rule: map inbound TCP/22 on the firewall’s public IP → the Storage Account’s privatelink.blob.core.windows.net:22 hostname. • Lock down the DNAT rule to only the source IP(s) of your external users. • All other traffic to the firewall or storage stays private.

    Self-hosted SFTP gateway behind a Standard Load Balancer • Spin up a Linux VM (or Container Instance/AKS) in a VNet, mount your blob container via BlobFuse or Azure File via a private endpoint. • Drop a Standard Load Balancer in front, assign it a public IP and an inbound NAT rule on port 22 → your VM/Container. • Use NSGs on the VM/subnet or the LB’s built-in allow lists to lock down who can connect. • The VM or container simply proxies SFTP traffic onto the storage account over the private link.

    Both patterns let you:

    • Keep the Storage Account firewall set to “private endpoint only”
    • Expose just port 22 on a single public IP that you can tightly restrict
    • Use Azure-native components (Azure Firewall, Load Balancer, Private Link, NSGs)
    • Monitor and log all inbound SFTP connections in Azure Monitor

    https://learn.microsoft.com/azure/firewall/firewall-sftp?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider
    https://learn.microsoft.com/azure/storage/blobs/secure-file-transfer-protocol-support?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider https://learn.microsoft.com/azure/storage/blobs/secure-file-transfer-protocol-support-how-to?WT.mc_id=Portal-Microsoft_Azure_Support
    https://learn.microsoft.com/azure/storage/common/storage-network-security

    Hope that gives you two turnkey, fully-Azure-native options to proxy external SFTP traffic into your private storage account! Let me know if you need more architecture diagrams or sample scripts.

  2. Praveen Bandaru 11,635 Reputation points • Microsoft External Staff • Moderator

    Hello Sumit Gaur

    Considering Azure's design constraints and service capabilities, Azure Storage Account (SFTP-enabled) does not offer a native reverse proxy pattern like HTTP/HTTPS services such as Application Gateway or Front Door. Since SFTP uses SSH (TCP port 22), most Azure Layer‑7 services are not built for this protocol. Although Application Gateway now supports TCP/TLS proxying, it is not generally suitable for SSH/SFTP and does not provide deep protocol support for SFTP traffic.

    Therefore, Microsoft suggests exposing SFTP securely using network-level components, keeping the Storage Account behind a private endpoint.

    The recommended Azure-native architecture is a hub-and-spoke model with Azure Firewall and DNAT (Destination NAT). In this setup, the Storage Account stays private and connects to a virtual network via a Private Endpoint. Azure Firewall, deployed in a central hub with a public IP, forwards approved SFTP traffic (TCP port 22) to the Storage Account using DNAT rules. Access is restricted by allowed source IPs, ensuring only authorized users can connect. This maintains privacy while enabling secure external access.

    Another option is a self-managed SFTP gateway (VM or container-based) within a virtual network. Here, a Linux VM or container acts as the SFTP endpoint, exposed via a public IP (using a Standard Load Balancer). This gateway connects privately to the Storage Account and serves as a proxy. Access controls can be enforced using NSGs and firewall rules.

    For best practices, public network access should remain disabled on the Storage Account, relying solely on Private Endpoint connectivity. Security can be strengthened with SSH key authentication and identity-based controls. Using centralized entry points like Azure Firewall improves visibility, logging, and auditing of SFTP traffic.

    In summary, while Azure does not offer a managed reverse proxy for SFTP, these architectures are best practice:

    • Azure Firewall with DNAT (preferred for management and security)
    • Self-hosted SFTP gateway behind a controlled public entry point

    Both methods keep the Storage Account private while securely allowing external SFTP access.

    Check the below documents for more understanding:
    https://learn.microsoft.com/en-us/azure/firewall/firewall-sftp

    https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider

    https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security

    https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insiderhttps://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support-how-to?WT.mc_id=Portal-Microsoft_Azure_Support&tabs=azure-portal

    Hope the above answer helps! Please let us know do you have any further queries.

    Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

  3. Praveen Bandaru 11,635 Reputation points • Microsoft External Staff • Moderator

    Hello  Sumit Gaur

    I just wanted to follow up and see if you had a chance to review my answer to your question. Please let us know if you found it useful, and don't hesitate to contact us if you have any further questions.

    Hope the above answer helps! Please let us know do you have any further queries.

    Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members. 

  4. Sumit Gaur 455 Reputation points

    Hello @Praveen Bandaru - what about associating a network security perimeter to the azure storage account and use that to have all these roles.

Sign in to comment

1 answer

  1. AI answer

    Azure Blob SFTP can be exposed externally while the storage account itself remains private by combining:

    1. A private endpoint on the storage account
    2. A network “front door” that terminates public SFTP and forwards it over the private endpoint

    From the provided material, the Azure-native pattern that matches this requirement is to place Azure Firewall in front of the storage account and use DNAT for SFTP, with the storage account restricted to private access via a private endpoint.

    Recommended architecture pattern

    High-level flow:

    1. Storage account
      • Create a general-purpose v2 storage account.
      • On the Advanced tab, enable SFTP for Blob storage.
      • On the Networking tab, restrict public network access and use a private endpoint for Blob.
    2. Private endpoint
      • Create a private endpoint for the storage account (Blob service) into a dedicated subnet in a virtual network.
      • This ensures all data-plane traffic (including SFTP on port 22) flows over the Microsoft backbone via Private Link and not the public internet.
    3. Azure Firewall as SFTP reverse proxy
      • Deploy Azure Firewall with a static public IP in a subnet of the same virtual network.
      • Create a firewall policy with a DNAT rule that:
        • Listens on the firewall public IP, port 22 (or a custom external port if desired).
        • Translates traffic to the storage account’s private endpoint IP, port 22.
      • The firewall becomes the public SFTP endpoint; the storage account remains private and reachable only via the private endpoint.
    4. SFTP configuration on the storage account
      • Enable SFTP support and configure authentication:
        • Either via local users (password/SSH key) and ACLs, or
        • Via Microsoft Entra ID–based SFTP access (preview) using RBAC/ACLs.
      • Assign least-privilege access per container and path.
    5. Client connectivity
      • External users connect with any supported SFTP client (for example, OpenSSH, WinSCP, FileZilla) to:
        • Host: the Azure Firewall public IP or DNS name
        • Port: 22 (or the chosen external port)
        • Username/credentials: the SFTP local user or Entra ID–based identity configured on the storage account.
      • The firewall DNATs the connection to the storage account’s private endpoint.

    This pattern satisfies:

    • Storage account remains private (no direct public endpoint access).
    • SFTP is exposed externally via a controlled, Azure-native entry point.
    • Centralized control and logging at the firewall.

    Azure-native services/components involved

    • Azure Storage account (Blob / ADLS Gen2)
      • Enable SFTP on the storage account.
      • Use ACLs and either local users or Microsoft Entra ID–based access for SFTP.
    • Private endpoint for Azure Storage
      • Provides private IP connectivity from the virtual network to the storage account.
      • Allows blocking or restricting the public endpoint while still enabling access from Azure Firewall and other internal resources.
    • Azure Firewall (with static public IP)
      • Acts as the public SFTP endpoint.
      • Uses DNAT rules to forward SFTP traffic to the storage account’s private endpoint.
      • Can be combined with firewall policies for IP allowlists, threat intelligence, and logging.

    This is directly aligned with the documented pattern “Access a storage account by using SFTP over an Azure Firewall static public IP address,” which describes:

    1. Deploying the network infrastructure and firewall.
    2. Creating a firewall policy with DNAT rules for SFTP.
    3. Creating the storage account and container.
    4. Enabling SFTP on the storage account.
    5. Creating a private endpoint for the storage account.
    6. Testing SFTP connectivity via the firewall public IP.

    Security and best-practice considerations

    • Keep the storage account public endpoint blocked or restricted; rely on the private endpoint for all SFTP traffic.
    • Use Azure Firewall DNAT rules instead of opening the storage account directly to the internet.
    • Use least-privilege permissions for SFTP users:
      • With local users, configure per-container permissions and ACLs.
      • With Entra ID–based SFTP (preview), use RBAC + ACLs and avoid ABAC for SFTP (ABAC is ignored for SFTP in preview).
    • Consider using Microsoft Entra External Identities if external partners need SFTP access via Entra ID.
    • Use firewall logging and storage account logging to monitor SFTP activity.

    This architecture gives a reverse-proxy–like pattern for SFTP using only Azure-native components, while keeping the storage account private and avoiding IP whitelisting on the storage account itself.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer