Fivetran Ip Addresses
To let the data pipeline reach your database, add fivetran ip addresses to your firewall rules. You match the right address range to your cloud region and open your database port. Most teams pair this network rule with a dedicated database user for the sync tool. If you give that user broad database permissions, any pipeline flaw exposes all your tables. Network rules check where traffic starts, not what queries the sync tool runs inside. How to set up fivetran ip addresses in your network Da
IP Allowlisting / Denylisting: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To let the data pipeline reach your database, add fivetran ip addresses to your firewall rules. You match the right address range to your cloud region and open your database port. Most teams pair this network rule with a dedicated database user for the sync tool. If you give that user broad database permissions, any pipeline flaw exposes all your tables. Network rules check where traffic starts, not what queries the sync tool runs inside.
How to set up fivetran ip addresses in your network
Data sync tools run in specific cloud regions around the world. Each region uses a fixed set of outbound network addresses. Before you start a sync, you check which region hosts your sync account. Then you look up the matching address ranges from the provider docs. You add those ranges to the inbound rules on your cloud firewall or database security group.
This rule tells your firewall to drop traffic from unknown outside sources. Only packets coming from the approved sync servers can reach your database port. For deeper security, teams also place the database in a private subnet. In that setup, traffic routes through an encrypted SSH tunnel or a private cloud link. Even with a tunnel, you still filter traffic using the approved regional address list.
After the network path is open, the sync service logs in with a database role. You create a specific user account and grant read permissions on the source tables. The sync service uses these keys to pull rows on a set schedule. Both the firewall rule and the user role must work together for the sync to run.
What IP allowlists solve and what they miss
Allowing specific network ranges stops random scanners on the public internet from hitting your database. It blocks attackers who steal a database password but work from an unapproved network. This network rule is a strong first step for any cloud data setup. It sets a clear boundary at the edge of your cloud network.
Still, network rules and static database roles leave big security gaps during daily operations. An IP rule only checks the source address when a session starts. Once the session opens, the firewall does not inspect the SQL queries inside the traffic. If a sync job pulls sensitive columns by mistake, the firewall lets it pass.
Static database credentials also create risk for engineering teams. Teams often reuse the same service login for manual debugging or quick data checks. When an engineer uses that shared account, audit logs only show the generic service user. You cannot tell which person ran a query or why they read sensitive rows. Also, static roles do not rewrite sensitive fields like emails, phone numbers, or card numbers. If the role can read a table, it gets all raw values in full.
IP Allowlisting / Denylisting: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing database roles alongside network rules
To keep data safe, separate automated sync traffic from human database sessions. Give your sync tool a locked-down role that only reads required schemas. Never share that service password with developers or analysts on your team. When engineers need to check source data, make them log in with their own identities.
You should also watch for changes in regional network ranges over time. Cloud providers add new servers and update their address lists when regions grow. If you miss an update, your data syncs will fail when traffic shifts to new servers. Set up a routine check to review your firewall rules against the vendor docs. Remove old ranges right away so you do not leave unused network paths open.
Finally, audit the tables and columns that your sync jobs pull each day. A network rule cannot stop a pipeline from copying raw national IDs into a warehouse. Keep sensitive columns out of broad sync roles, or mask matched fields in query results. Combining strict network rules with tight query controls keeps your data pipeline safe.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why did my data sync stop working after a network update?
Your sync tool likely moved traffic to a new server range in your cloud region. Check the provider status page and add any new regional addresses to your firewall rules.
Do I still need IP rules if I use an SSH tunnel?
Yes, you must still restrict traffic on the SSH host itself. Add the provider address ranges to the firewall in front of your tunnel server.
Can an IP allowlist stop a sync tool from reading sensitive columns?
No, firewall rules only filter network packets by their source address and port. You need database permissions or query masking rules to control which columns and values return.