Azure SQL Server Database security not considering the System current IP - azure

I understand that Microsoft Azure is very secure and the Azure SQL Server as well. However, the question is bit scenario based:
I'm accessing Azure SQL Server DB using SSMS, which is asking me to login using SQL Server authentication.
In Azure DB firewall security setting when I'm trying to add my current PC IP address ( which is Dynamic in nature ),its not adding.However, its actually considering my ISP provided IP address. The questions are: why its not allowing me to add my current IP address? Should not there be a security issue, if its considering my ISP IP ( which I can found "what is my IP") ? How and what level of security Microsoft is providing in this case? Is not it that, if someone will get my SQL Server credential they will go inside my SQL Sever in Azure?
OR
is it like that, the HOST/Computer name and IP address (which got via What is my IP) should be matched then the SQL Server credential will work? - Which is kind of more secure.
Hope I have explained this correctly.This is just to get more clarification not to compare.
I understand that, I think, I should have static IP. But, the local IP is dynamic.
Thanks.

It is the IP address assigned by your ISP what Azure SQL Database firewall can "see". That is the one you need to add as firewall rule. The private IP address your computer is using on your local network cannot be "seen" by Azure SQL database firewall.
Azure SQL Database security is more than just a firewall rule. All data in transit coming from any Azure SQL Database or going to any Azure SQL Database is encrypted. Azure SQL Database does not allow non-encrypted connections. All this is happening on TCP port 1433. You cannot communicate to Azure SQL Database on a different port.
When a client first attempts a connection to SQL Azure Database, it sends an initial connection request. Consider this a "pre-pre-connection" request. At this point the client does not know if SSL/Encryption is required and waits an answer from SQL Azure to determine if SSL is indeed required throughout the session (not just the login sequence, the entire connection session). A bit is set on the response indicating so. Then the client library disconnects and reconnects armed with this information.
When you set Encrypt to true you avoid the "pre-pre-connection", and you are preventing any proxy from turning off the encryption bit on the client side of the proxy, this way attacks like man-in-the-middle attack are avoided.
When secure connections are needed, it is recommended to enable "Encrypt connection" setting on SSMS.
In addition to all this, when you create a new database on Azure SQL Database data at rest is encrypted. Transparent Data Encryption is enabled by deafult.

Related

Connecting Azure SQL Server PASS DB

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

How to connect to Azure pass DB from a secure network

I would like to connect to Azure SQL server from a Window server via SSMS. In the “set server firewall” from Azure, I have given my server IP ( from the system I would like to connect). I need to know the destination IP adders of the Azure DB Server. From Azure portal the location is showing central US . To allow firewall I need to know the destination IP address.
My questions are:
1. As Central US could have multiple IP addresses, do I need to provide all IPs to my Firewall team?
2. How can I know the destination IP address ( i.e. Azure) so that I can provide that to my firewall team?
Note: From SQL server management studio, the tcp default port for SQL is enabled and services are running fine.
Hope I have explained it correctly.Thanks
No. You cannot get a static IP address assignment for your Azure SQL Database. Moreover, what you refer (mysqlserverdatabase.mysql.database.azure.com designates your Azure SQL Database Server, not a single Database. This is a logical server, in which you can put up to 149 Databases (150 with the Master DB).
You have to workaround your requirement for static IP address assingment to work with the DNS Name (mysqlserverdatabase.mysql.database.azure.com).
Otherwise if your company firewall can't work with the DNS Name ,you need to set the server connection policy to Proxy as documented in Azure SQL Connectivity Architecture. This allows the database gateway to proxy all traffic between the client and the DB server. The gateways all have static IP addresses, which are listed in the above document.
If you have setup a VNet in Azure, checkout VNet Service Endpoints to connect Azure SQL.
https://azure.microsoft.com/en-in/blog/vnet-service-endpoints-for-azure-sql-database-now-generally-available/

Import database bacpac firewall issue

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.

connect to azure sql server through datacenter ip address

I trying connect to azure sql server (xxxx.database.windows.net) through datacenter ip addres, i changed connect policy by proxy, but now i don't know how connect to instance the sql server.
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-connectivity-architecture
You may have to add the datacenter IP range as a rule on the Azure SQL Database firewall rule. Please download and read this document to know the current IP range of the datacenter where your database resides.
Alternatively you can also set "Allow Access to Azure Services" to On (see image below), although this option configures the firewall to allow all connections from Azure including connections from the subscriptions of other customers.
In addition to configure the firewall, for security reasons make sure your login and user permissions limit access to only authorized users.
This guide may provide you additional valuable information to connect to your Azure SQL databases.

Secure access to SQL Azure

What is the best way to create a secure connection to SQL Azure from a customer location?
We are currently using IP address and setting the firewall, but this is not very secure
That's pretty much all you have with the Azure SQL Database offering today. The TDS protocol is sent to the client over TLS so the transport is secured.
Note that you could theoretically create a "jump" or "bastion" host in Azure on a VM, and allow only connections to Azure SQL from the public VIP of that host, but I'd question how much more secure that is than what you have now.

Resources