Azure SFTP on Blob

This article shows how I set up some rules for running my Azure SFTP on Blob. In the first place, have already shown how Bidone uses the new fully managed SFTP service on Microsoft Azure Blob Storage. This talk on Integration Down Under covers design, deployment and implementation. This article updates and expands on this.

Enabling an SFTP endpoint for Blob Storage accounts allows many new ways of moving files to and from Azure. This seminal article from Microsoft explain how it works far better than I can, and you should read this.

Governance

Before migrating all out customers from an on-premises FTP server to Azure SFTP on blob, Bidone first set up some rules. Here they are.

Customer Access will must be restricted to only their SFTP containers and no one else’s.
All files must be short-lived with a lifetime of less than 7 days. The server must not be used as an archive.
The convention for usernames will be sftp<site><clientname>.
Each user will have access to a container of the same name i.e. <site><clientname>-blob.
Only external users will use SFTP to access the blob containers.
Azure components will only access the blob using blob methods and not by SFTP.
Only internal users can access the blob storage. Anonymous read access to blob storage will be disabled.
Firewall inclusion will be enabled for sftp port 22.

Implementation

Our implementation follows the Microsoft guidance (Connect to Azure Blob Storage using SFTP | Microsoft Learn). I highlight the important points are highlighted here.

Create a new standard general-purpose v2 storage account.
Enable SFTP support on the blob storage.
Set up a file retention policy of seven days in Devops. This is to keep the costs of blob storage low.
Add local user containers via Devops.
Add local users and assign access to their container via Devops. Local user passwords will be stored in key vault as well.
Enable whitelisting for external users.
Implementing access control using system managed identity for all Azure components. Note user-assigned managed identities are not supported for access to SFTP on Blob.

Devops considerations

Firstly, setup and manage your network inclusions in a storage account arm template.

Secondly, setup all local users in another arm template. Configure the creation of local users to incremental because you do not what the passwords to change on every deployment. Remember you can only copy the password on creation of the user or if you regenerate the password. We regenerate the password after the first deployment and give that to external users.

Whitelisting considerations

When establishing connections from Azure Logic Apps to Azure SFTP, implementing access control using managed identity offers several benefits:

Enhanced Security: Managed identity eliminates the need to store and manage shared access keys, reducing the risk of credential exposure and unauthorized access.
Simplified Management: Assigning Logic Apps to Azure AD groups allows for centralized access control management, streamlining administration and ensuring consistent permissions.
Scalability and Flexibility: Managed identity scales effortlessly to accommodate a large number of Logic Apps, and Azure AD groups simplify adding or removing apps without modifying access control settings individually.
Auditing and Compliance: Azure AD provides comprehensive auditing capabilities, enabling easy tracking of access permissions and facilitating compliance audits.

To further enhance access control, we create Azure AD groups for each environment.

Assigning Logic Apps with system-assigned identity to their respective environment’s Azure AD group ensures proper access management. Currently, this is automatically done during deployment time.

Grant permissions to these Azure AD groups, providing access to the necessary resources. To read more about the managed identities follow this link to Microsoft’s documentation: Managed identities for Azure resources frequently asked questions” – Microsoft Entra | Microsoft Learn

Disaster Recovery Considerations

Failover for storage accounts with hierarchical namespace enabled (Azure Data Lake Storage Gen2 storage accounts) is not supported at this time. see Disaster recovery and storage account failover – Azure Storage | Microsoft Learn.

This article states that this is available in some regions but not in Australia yet. Disaster recovery and storage account failover – Azure Storage | Microsoft Learn

Even if you create another SFTP on Blob in another region, synchronization of local user passwords is not possible.

In summary currently we cannot initiate a failure of SFTP on Blob. In future we should be able to do this ourselves and we need to watch this space.

SFTP connections from third party servers hosted in Azure

Finally, mention this gotcha because maybe it will help someone else. One of our customers was unable to connect via SFTP to our blob. See my blog on this for more details.

Conclusions

SFTP on Blob is one of my favourite Azure components in by toolbox. Gone are the days of struggling to set up integration gateways to on-premises third parties. Just whip on SFTP on blob push a few buttons and you are all done.

I think the only part of the story that is a bit wanting is the lack of a good disaster recovery option.

Finally, I hope this article help to persuade you to try this new Azure component.

Azure SFTP on Blob – Governance