Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Get Fabric certified for FREE! Don't miss your chance! Learn more

Reply
BalajiL
Advocate II
Advocate II

Datasphere to ADLS security connectivity

We are ingesting data from datasphere to Fabric using replication flow from Datasphere and pushed to ADLS. 

To align on the network architecture for SAP Datasphere integration with ADLS.

The current setup appears to use public access with IP firewall exceptions and Service Principal authentication. Reliance on public endpoints and static IP allow listing may pose security and stability concerns. Can someone please suggest right network topology to connect data in secure way.

 

8 REPLIES 8
deborshi_nag
Memorable Member
Memorable Member

Hello @BalajiL,

 

The recommended approach is to ensure traffic remains on Microsoft’s private backbone, minimise public exposure, and utilise Azure AD identities.

 

To enhance the security of your integration, please consider the following measures:

1. Select the same Azure region as SAP Datasphere.
2. Enable Storage Firewall by disabling 'All Networks' and selecting 'Selected Networks'.
3. Permit the SAP Datasphere VNet/Subnet within the storage account’s network rules (you can obtain the specific Datasphere Virtual Network Subnet ID from the Datasphere “About” section).
4. Use an Entra app registration (service principal) with certificate and RBAC.

 

I trust this will be helpful. If you found this guidance useful, you are welcome to acknowledge with a Kudos or by marking it as a Solution.

I trust this will be helpful. If you found this guidance useful, you are welcome to acknowledge with a Kudos or by marking it as a Solution.
v-lgarikapat
Community Support
Community Support

Hi @BalajiL ,

Thanks for reaching out to the Fabric Community.

To better understand your scenario, could you kindly provide more details on the following points:

  • Are you using the same Azure region for both SAP Datasphere and ADLS, or are they in different regions?

  • What authentication method are you currently using (e.g., Service Principal)?

  • Do you have any private endpoints configured for your ADLS account?

  • What specific security concerns would you like to address that are not covered in this solution?

Thanks,

Lakshmi

hi @v-lgarikapat 

 

  • Are you using the same Azure region for both SAP Datasphere and ADLS, or are they in different regions? [ Balaji ] Yes

  • What authentication method are you currently using (e.g., Service Principal)? [Balaji] Yes Service principal is the authentication when connecting from datasphere to adls.

  • Do you have any private endpoints configured for your ADLS account? [ Balaji ] No

  • What specific security concerns would you like to address that are not covered in this solution? [Balaji] Currently using IP Address Exception of SAP's public IP. This IP might not be static it could be changed. So would like to understand how this can be addressed in secure network protocol

Hi @BalajiL  , Thanks for the responces 


You’re right to be concerned about relying on public endpoints, IP allow‑listing, and Service Principal authentication alone. That setup works, but it isn’t the recommended secure architecture for Datasphere → ADLS → Fabric integration.

The secure approach is:

 

1. Use Azure Private Endpoint (Private Link) for ADLS
This removes public exposure completely and forces all traffic over Microsoft’s backbone network. It also eliminates the need to maintain static IP allow lists.

 

2. Add the SAP Datasphere VNet Subnet ID to ADLS network rules
SAP Datasphere provides a VNet subnet binding. Adding that subnet to ADLS network rules enables private access instead of public egress IPs, which can change and cause instability.

 

3. Disable public network access on the ADLS account
Once Private Endpoint + VNet rules are in place, you can safely turn off public access to reduce attack surface.

 

4. Continue using Service Principal / RBAC for authentication
This is still the right way to authorize, but it should run over the private endpoint instead of a public endpoint.

 

5. (Optional) For Fabric usage, enable trusted workspace access or use shortcuts
Fabric’s security model supports fully private access to ADLS without exposing anything publicly.

 

Microsoft Fabric end-to-end security scenario - Microsoft Fabric | Microsoft Learn

Data integration security for SAP on Azure - Cloud Adoption Framework | Microsoft Learn

 

Thanks,

Lakshmi.

hi @v-lgarikapat : Thanks for your prompt response. I will discuss the above points with our infra team.  Regarding #5 - Trusted Workspace Access (TWA) is already in-place to connect ADLS -> Fabric using shortcut.  Here the data is coming from Datasphere - > ADLS and using Public IP address as exception. 

Hi @BalajiL ,

 

Just following up did you get a chance to discuss this with the infra team as mentioned in the earlier messages

 

Thanks,

Lakshmi.

Hi @BalajiL ,

 

I'm following up to check whether your issue has been resolved. If you still have any questions or need further assistance, please don't hesitate to reach out we're happy to continue supporting you.

We truly appreciate your participation and thank you for being an active member of the community.

Best regards,

Lakshmi.

Hi @BalajiL Thanks for the update 

 

Thanks,

Lakshmi.

Helpful resources

Announcements
Sticker Challenge 2026 Carousel

Join our Community Sticker Challenge 2026

If you love stickers, then you will definitely want to check out our Community Sticker Challenge!

Free Fabric Certifications

Free Fabric Certifications

Get Fabric certified for free! Don't miss your chance.

January Fabric Update Carousel

Fabric Monthly Update - January 2026

Check out the January 2026 Fabric update to learn about new features.

FabCon Atlanta 2026 carousel

FabCon Atlanta 2026

Join us at FabCon Atlanta, March 16-20, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.