Skip to Content

FAQ for the Cloud Connector

The Cloud Connector is a small component in the SAP universe but it’s crucial when it comes to connect the on-premise world with the cloud world.

Many blogs and resources have been already shared in the last years and many questions have been answered. Now we see the same questions about the installation, configuration and operation of the Cloud Connector coming again and again in the SAP community forum. That’s why we have collected them and structured them to make it easier for new users to get started with the Cloud Connector.

You can find now a new section in the official documentation called “Cloud Connector: Frequently Asked Questions“.

We have split all the questions in the following categories:

  • Technical issues
  • Administration
  • Roadmap (Feature Requests)
  • Troubleshooting



Of course it’s just the beginning and we will include more in the future.

Have a look at it and don’t hesitate to share any suggestions šŸ˜‰

Thanks in advance!


You must be Logged on to comment or reply to a post.
  • Just read the FAQ, but still have a question.

    How to configure a HANA XS application to connect to on-premises NW gateway via the SAP Cloud Connector.


  • Hi Matthieu and Philipp StehleĀ ! The FAQ is great, thanks for posting it! I thought maybe the following question would be frequent, but I could not find it in the list:

    If some company has a security guideline specifying that only centrally administrated cloud connectors are allowed to expose data from the internal network to the internet, and they wish to block individuals from connecting their local SCC to specific SAP backend systems.

    What is the best way – as an SAP backend administrator – to limit/control which cloud connectorsĀ  access the backend system?

    All the best,


    • Hi Simen,

      first of all, thank you for your feedback, we appreciate and planning to update it.

      for now, I’ll try to give an answer here.

      We have to distinguish between two different attacker models:

      • The “naive guy”, who isn’t aware of the security guideline, reads online about the Cloud Connector and wants to deploy it.
      • Ā An actual “bad guy”, who tries to steal data from the company.

      Both of them have access to the companies SAP backend system via HTTP or HTTPS (as they’re employed by the company).

      While it’s pretty easy to block the naive guy from leaking data, it not really possible to prevent the bad guy from that. If there is a way to block the SCC, the bad guy could use some other tool anyways. So we will focus on this naive guy. There are several ways to prevent this:

      • Perhaps the fastest way is, to block any domain that contains “connectivitycertsigning” from DNS resolving. This will prevent the Cloud Connector from being able to connect to the Cloud (but not to the Backend System). Keep in mind, for a malicious attacker with a reasonable technical background this is not much of a problem. Also, this is something only a network administrator can do and not the “SAP backend administrator” as you requested.
      • Blocking based on user-agent would be possible, you could block any user-agent that starts with “Apache-HttpClient”. This should work but is not documented, so the user-agent used by the Cloud Connector could change at any time.


      Is this helpful to you?


      Kind Regards,


      • Hi Philipp,

        Thank you for replying so quickly. Maybe this is overkill for the FAQ, but I still find it interesting. I agree that the “hacker” with a user in the backend system would be able to steal data anyway, so yes – the naive employee is a more likely scenario. Or the overly eager and goal-oriented, not so security focused, employee – who wants to move something from backend to cloud šŸ™‚

        The methods you provide are good ideas. I was hoping there was a flag or parameter that could be used..Ā  First method would stop all SCC communication, not only the “bad” ones, right? Second method seems better, but as you say – undocumented and sort of a hack. Anyway, I would like to test it out. Do you know if HTTP header data like the user agent can be filtered in SMICM?

        Thanks again,


        • First method would stop all SCC communication, not only the ā€œbadā€ ones, right?

          Not necessarily. When applying the first method, you’d need to somehow whitelist the “good” ones. (By the way: Obviously, this is also necessary when leveraging the second method.)

          I’m not a network administrator, but I’m pretty sure this should be possible (even my home router supports this).


          Second method seems better, but as you say ā€“ undocumented and sort of a hack. Anyway, I would like to test it out. Do you know if HTTP header data like the user agent can be filtered in SMICM?

          I’m not an expert here either, but it should be possible when settingĀ icm/HTTP/mod_0 and using a rule like this:

          if %{HTTP_USER_AGENT} regimatch Apache-HttpClient/* [AND]
          if %{REMOTE_HOST} !strcmp ""
          RegForbiddenUrl (.*) -

          In this exampleĀ is the IP address of the “good” Cloud Connector.

          SeeĀ andĀ

          I don’t know if there is any better way to achieve this, sorry.

          If you try it, let me know the result.