Synapse Hybrid Cloud

You set up a synapse hybrid cloud by linking local servers to cloud analytics workspaces. You install integration runtimes on local machines to move data across networks safely. Many data teams build this bridge to run cloud reports on local databases. Still, broad service roles often give too much power to a single account. If an account key leaks, attackers can read or change local and cloud data.

How a synapse hybrid cloud setup works

A synapse hybrid cloud links your local data center with cloud storage and compute engines. First, you set up a self-hosted integration runtime on a local server inside your network. This runtime acts as a worker that pulls data from local databases. It then sends that data over an encrypted link to the cloud workspace. You do not need to open incoming firewall ports on your local network.

Next, you set up role permissions inside the cloud workspace and the local database. You assign an identity to the runtime so it can log in and read tables. Cloud pipelines then call this runtime on a schedule to copy data or run jobs. You also set up network rules to limit which cloud workspaces can reach the runtime. This design lets teams join old local records with new cloud tables in one query.

What native network and role settings solve

Native network links and role rules solve the basic problem of moving data across sites. They let your cloud pipelines log in to local databases without exposing them to everyone. You can group users into cloud roles and grant table permissions by team. Private network links also keep traffic off the public internet during data transfers.

Still, these native settings only check who logs in at the start of a session. They do not inspect what each query or command does while it runs. Once a user or pipeline logs in, that role keeps the session active for the whole job. An engineer with a broad role can still run a bad query that drops tables. Native roles also struggle to mask sensitive fields like emails or card numbers in flight.

Managing permissions across local and cloud data

When teams run hybrid setups, permissions often drift between the local database and the cloud. Admins create shared service accounts so pipelines and users do not hit permission errors. Over time, nobody remembers which app or person uses that shared login key. Auditing becomes hard because database logs only show the shared account name, not the person.

To keep control, teams need to check every query before it hits the database engine. You must tie each command back to an individual user identity in your directory. You also need rules that rewrite matched fields like phone numbers or national IDs in results. This keeps sensitive data safe during debug sessions while letting pipelines run their normal jobs.

Govern statements and responses across databases and APIs

Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.

First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.

Frequently asked questions

How does a local database link to a cloud workspace?

You install a local runtime agent on a machine inside your private network. This agent makes outbound calls to the cloud workspace to move data safely.

Why do hybrid cloud setups create permission risks?

Teams often use one shared account with broad rights to move data between sites. If someone steals that key or runs a bad query, nothing stops the command.

Can native database roles stop risky queries in flight?

Native roles decide who can log in and which tables they can read or write. They do not block specific risky statements or require peer approval for single commands.

Related guides

• M2m Connection
• Luigi Pipelines
• Macstadium Firewall