Forum Discussion

BalajiL's avatar
BalajiL
Resolver I
7 months ago

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.

 

data engineering

8 Replies

  • deborshi_nag's avatar
    deborshi_nag
    Super User
    6 months ago

    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.

  • v-lgarikapat's avatar
    v-lgarikapat
    Community Support
    7 months ago

    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

    • BalajiL's avatar
      BalajiL
      Resolver I
      6 months ago

      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

      • v-lgarikapat's avatar
        v-lgarikapat
        Community Support
        6 months ago

        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.