We are using snowflake enterprise edition.
One of the client systems wants to access our snowflake account to consume the data.
We have created user and password and share with them to connect to snowflake.
Now we want to add extra security to this user by whitelisting the DNS name, so that username created for this client will not be misused.
Is there anyway that we can whitelist DNS in enterprise edition.
I read that VPC version have this feature by setup some firewall behind the snowflake.
We can achieve this using IP Mapping in Enterprise but client using dynamic IP which will keep change.
Regards,
Srinivas.
The network policy feature is IP address or range only so you won't be able to do name resolution with this currently (i.e., would be a feature request). I don't think there's one perfect solution to your request.
If the changing IPs are all part of a CIDR range, you could use that, or a proxy solution would have a stable IP. VPN could be another alternative and include the VPN-issued IP addresses in the Snowflake Network Policy.
I'm sure there's other methods too and worth a discussion with your security team for more ideas. Welcome others to comment with their ideas as well.
Related
I'm using SSMS to connect to Azure DB from my laptop. I have provided my laptop IP address in "Set server firewall". However, each time when connecting from SSMS it's considering my public IP address, instead of laptop IP.
My questions are:
why is it not considering my Laptop IP?
How safe is it to configure a public IP address in Azure's "set server firewall"? Will not it possible someone having same public IP can able to connect to Azure DB?
How the Azure DB can be configured so that it should account the request from my laptop IP only?
Azure PaaS service has a public endpoint, so it means that you cannot connect to them from your private IP, you must configure your Azure PaaS with your public IP. There is an option to make a public endpoint as a private endpoint using a private link, vpn point to site, virtual network gateway. Please, have a look at this article for more details.
You can keep security your connection from public IP using Azure PaaS firewall once your connection from your source to azure allows only you public IP, but you have to change this IP in firewall for each time your IP is renewed in case it is dynamic. For the best practice you should consider a private link or a Azure Instance Manager SQL which has more option, but it is more expensive then Azure PaaS SQL.
To help you answer these questions, we first must consider the network topology involved. Your laptop is likely connected to a wireless access point which is connected to a network switch. All traffic on the switch (or series of switches depending on the location you are at) uses a private IP addresses to communicate. These addresses cannot be routed on the public internet. In order for you to access the Azure SQL Database which sits on a different private network then your laptop, it had to travel over the public internet. This means your traffic is going through a series of routers and in order for the connection to correctly route between you and Azure, it needs your public IP address.
It is safe to a certain point. The Azure SQL Server you are connecting too uses SSL/TLS to encrypt the traffic so communication over the public web is encrypted. Your concern for essentially spoofing the public IP is valid which is why it is crucial to make sure you have selected a strong password for the SQL login. Microsoft also deploys a series of edge security services that monitors for attacks on any of their services to ensure the safety of their platform and will flat out block suspected attacks.
If you want to restrict traffic so that only your laptop can be used, now we are introducing a complex but doable architecture. You will need to setup a VNet and VPN Gateway in Azure and connect the two services. You will have to then connect the Azure SQL Database to the VNet you just setup. Once completed, you will need to access the VPN from your laptop which will grant you access to the database. The actual setup isn't trivial as there are many things to take into consideration such as cost, hardware capabilities on your side and security requirements.
At the end of the day, what should drive the "right solution" should be your security requirements. For some, running via a public IP is sufficient, for others they need to access it over a VPN.
To address your comment below, I needed more space so I'm amending the solution.
Anytime you make something publicly accessible over the internet, there is a possibility for someone else to access it. The chances are lowered the more complex you make the password to the resource. If you do not have a static IP address for your internet or someone spoofs your public IP address, there is a chance an attacker will have the ability to connect to the Azure SQL Server. This is where the password complexity comes into play. The stronger the password, the harder/longer it will take to brute force their way in.
If you have time to do the research/learning on this, I'd suggest taking a look at the online training Microsoft has for the Azure Solutions Architect certification. I think it will help you to better understand the intricacies involved with building a solution such as this.
https://learn.microsoft.com/en-us/learn/certifications/azure-solutions-architect
We have a sql server firewall setup with no IP access and "Allow Azure Services" flag also set to off.
I understand this means no azure services and no external clients will be able to access the sql server and database.
however, when i try Import Database option on sql server, with bacpac stored in azure storage, we get a strange error of an IP that needs to be given access in sql server firewall. The error reads.
Client with IP address 65.52.129.125 is not allowed to access the server.
While our azure infra is in West Europe, there is no mention of what this IP belongs to and what is the purpose of it.
The same error of course also occurs from Infra as a code approach and CI-CD Pipelines. and I think adding an IP without any information is risky.
Has anyone faced this before? or if anyone knows , what is azure database import using underneath for which this IP needs access and will it always be the same?
65.52.129.0 - 65.52.129.255 is an IP address range owned by Microsoft Corporation and located in Netherlands.
Please read the following explanation about why you should enable Azure Services access on the firewall at least while doing export/import operations. When you finish import/export operations, then disable Azure Services access.
"The IP address space used for outbound connections from the Import/Export Service infrastructure to the target logical server is not documented, and is subject to change at any time. Therefore, given that connections to the target Azure SQL Database server are gated by server firewall, the only fully reliable way to ensure that the Import/Export service will be able to connect is to enable the firewall rule that allows access from all Azure services (or, equivalently, from the 0.0.0.0 IP address). Obviously, opening the firewall to a large IP address space is a network security risk. Security conscious organizations will want to mitigate this risk by disabling this firewall rule as soon as the import operation completes successfully..."
Source is here.
I have created a Windows 2016 data center on Microsoft Azure cloud. I also downloaded its RDP file. However, when I am trying to access it from my Organization I get below error. (of course, organization uses proxy/firewall). When I access it from my home internet, I can access the VM successfully.
Currently the networking of the VM has below setting:
Please help to access the azure VM via proxy.
Edit:
Got few great answers. However, being a trainer, I need to keep creating and deleting the VMs on day to day basis, hence requesting network admin to add a particular VM IP to exception list won't help. Is there any other way possible?
Go with Jason's suggestion. Your network admin needs to configure the corresponding rules for the firewall or proxy. What you need to tell the network admin depends on your setup:
If you are dealing with one VM only, then you could either configure the public IP that is assigned to the VM as static and ask the network admin to allow rdp to that IP address, or, alternatively,
if you would like to save costs for the public IP and your organisation's proxy/firewall is capable of working with DNS names, then you could assign a DNS name to the public IP and let the network admin know the DNS name. The DNS name would be something similar to this: myazurevmname.azurelocation.cloudapp.azure.com
If you are planning to access several VM's in Azure, you can either repeat above steps for each of the VM's, however, may want to think about establishing a point-to-site VPN from your local computer which would remove the need for assigning public IP addresses to each of the VM's. The network setup in Azure will be more complex upfront, but it may be worth the effort. However, this will be a separate discussion.
You could set up teamviewer as a service(!) on your VM and then connect to it with teamviewer from your company pc. it'll be a bit laggy but you'll get used to it
Use this tutorial to set up teamviewer
It seems your organization network block it, you should contact your network admin to add it to firewall/proxy.
We have a client who wants to connect their premises to Azure. Their main hindrance at this point is determining the best way to connect to Azure given their current connectivity configuration. They have two redundant ISP connections going to the head office for internet access. They want to be able to configure a VPN connection to Azure that would operate in a similar way i.e. if ISP A went down it would seamlessly use ISP B and vice versa. The normal multi-site VPN configuration does not fit this since there is one local network behind which means the network behind separate VPNs over each ISP would have overlapping IP address ranges which is not supported. Is such a configuration possible? (See diagram below)
Either that or is there a way to abstract the two ISP connections onto one VPN connection to Azure.
They’re currently considering using a Cisco ASA device to help with this. I’m not familiar with the features of this device so I cannot verify if it will solve their issue. I know there is also a Cisco ASAv appliance in the Azure marketplace don't know if that could also be a part of a possible solution if they went with such a device.
required vpn configuration
The Site-to-Site VPN capability in Azure does not allow for automatic failover between ISPs.
What you could do are the following
- Have automation task created that would re-create the local network and gateway connection upon failover. Manual and would take some RTO to get it up and running
- Use the Cisco CSRs to create a DMVPN mesh. You should be able to achieve the configuration you want using that option. You would use UDRs in Azure to ensure proper routing
I havent done it in Azure, but here is what you do in AWS (And I am sure there would be parallel in Azure)
Configure a "detached VGW" (virtual Private gateway) in aws. Use DMVPN cloud to connect CSRs to multi-site on-prem.
Also, for failover between ISPs you could have a look at DNS load balancing via a parallel to AWS's Route 53 in Azure.
Reference thread :
https://serverfault.com/questions/872700/vpc-transit-difference-between-detached-vgw-and-direct-ipsec-connection-csr100
I have two servers that provide a service to clients.
The client devices access the server through a DNS name. example.com
Now we generally use server1 (primary) but if server one becomes inaccessible, I want the DNS to change its resolving name to server 2 (secondary server)
How can I go about doing this, Is there a service that dyndns provides?
The only way I know to do it is to log into the DNS server and manually change the addresses that the dns resolves 2.
It sounds like you're looking to create an automated failover in the event of an outage. While this is a service that Dyn provides as an added service in the DynECT Managed DNS service (hit up sales#dyn.com for more info on that), you can also use the Dyn Updater API to push an IP update up to your Standard DNS account as well. It would be a matter of using a 3rd party monitoring solution to trigger the update in your code using their API, then using the Dyn Updater API to switch the IP.
http://dyn.com/support/developers/api/
Whether you want to spend the money on upgrading to DynECT Managed DNS or keep using your Standard DNS account, we can help you either way.
Good luck, and if you have any other questions, please do not hesitate to ask.
CL