I have the possibility to use a shared mysql server offered by a reliable Italian cloud provider (Aruba). The service satisfies my performance needs and would notably simplify my infrastructure.
My concern is that this shared mysql service (DBaaS) is only offered with public ip address exposed on the internet, authentication with userid and password and SSL connection.
The data that I would move to this server are reservations and accounting for a certain number of hotels. It's definitely critical and confidential data and a data breach would be definitely a disaster.
Till now, my infrastructure is based on a firewall that only exposes the web server, while the database server is a custom VM connected through a virtual switch and not visible on the internet.
How bigger is the danger of such an infrastructure (DBaaS with public ip address) compared to my actual setup with a private VM running mysql on an internal IP address?
PROS: security, updates and firewalling would be managed by the cloud provider in a more consistent and persistent way
CONS: exposure on the internet
Related
We currently have a Public API to be used by our Business' current and future clients. Due to flexibility purposes and capability for our client's systems to interface with ours, we currently have our MySQL Database IP and Port on Wild Card access so as to not encounter any restricted access issues.
Question is, due to security concerns, would it be possible to restrict the MySQL Database's Server IP and Port to not be accessed directly by third party clients but only via the Public API? My instinct says no, but I don't have much experience in the way of Public APIs nor Public Access.
When an API User sends a query on our database, does it identify it via the API Host's IP (our servers?), or via the Client Computer's IP?
Thanks!
It's considered a bad security risk to expose MySQL's port directly to external clients. MySQL supports TLS but doesn't enforce it by default. So you're at risk of unauthorized clients invading.
For this reason, it's much safer and more recommended to run your own API server, as you mentioned. The API server is the only one allowed to connect to MySQL. Typically network routing is configured to prevent any contact to the database server except from the API server.
MySQL would therefore know nothing about the client's IP address. As far as MySQL is concerned, your API server is the only IP address it knows about.
The client IP address would be known by your API server and http server, and if you have load balancers or firewalls, those too.
The "users" associated with your third-party clients aren't necessarily mapped to distinct users in the MySQL authentication system. Actually, it's more typical that the API server uses a single MySQL user to authenticate all clients. Once connected to the database, your code would look up the client's "user" as a further authentication step. In other words, you would store a table in your own database with user credentials, and you would implement code to check passwords and so on. This is distinct from MySQL's own authentication system.
Alternatively, you could write your API service to use SAML or Oauth2 or equivalent federated authentication. The API service would still need to authenticate to MySQL, but the client's identity would be provided by the Oauth2 authentication.
Lets say I have a VM instance and I then make a connection to the Cloud SQL instances IP using a MySQL client. According to the comparison table in Connection Options for External Applications, connecting with no SSL is apparently not secure (and non-encrypted).
But to what extent is it insecure? If there is a man-in-the-middle attack, query and query results could be seen. I would like to determine how big of a risk that is.
Specifically I would like to know the risks of connecting from:
A VM in the exact same zone to a Cloud SQL instance
A VM in the same region, but a difference zone to a Cloud SQL instance
A VM in another region to a Cloud SQL instance, but still from GCP
I assume that for any of these kinds of attacks to be carried out, the actual google infrastructure would have to have been compromised as it wouldn't be possible for a VM to listen to traffic outside a network that it's attached to.
The actual infrastructure wouldn't have to be compromised actually, all that it'd take is for an instance in the same network to be compromised for the details of your connection to Cloud SQL to potentially be compromised. Seeing as maintaining the instances up-to-date is a responsibility of the users, that means that the security of an insecure connection to Cloud SQL also depends on the security of your instances.
Why exactly are you doing insecure connections? I ask because it's incredibly easy to setup a safe connection from an instance to Cloud SQL by using Cloud SQL Proxy! Not to toot my own horn here, but take a look at
this answer I gave a while ago about why you should be using the Proxy.
Regardless, and keeping in mind that Cloud SQL is nothing more than a managed instance exclusively accessible via its public IP, the traffic should stay within GCP in all three of those scenarios, meaning the only thing that is likely to be compromised are the instances in the same sub-network as that of the instance that's connecting to Cloud SQL.
I have just created cloud storage on google for mysql database.
I have added local IP address and server's IP address in authorization (under access control).
It's getting connected in mysql work bench in my local machine. But, it's not connecting with the website which is running on windows azure platform.
Which IP address am I supposed to use in access control?
Website is in basic package of azure.
This is a relatively non-trivial thing to achieve as the GCP services need to know about the public source IP of the Azure service. Azure's IP surface is pretty wide so you'd be unlikely to successfully connect the two. You'll be unlikely to be able use just a single source IP address.
You may be better off looking at a VPN connection out of an Azure VNet to your GCP environment.
To be honest, trying to build any form of performant web experience that hosts the web and data tiers in different public clouds is going to be extremely challenging.
Actually I resolved this issue by opening ticket in azure support.
They have outbound IP addresses range available online. We need to provide those IP addresses to third party access control.
I am sharing you that link here.
https://social.msdn.microsoft.com/Forums/azure/en-US/fd53afb7-14b8-41ca-bfcb-305bdeea413e/maintenance-notice-upcoming-changes-to-increase-capacity-for-outbound-network-calls?forum=windowsazurewebsitespreview
Choose those IP addresses which are associated with your website.
We have developed a client app and a server app. The client communicates with the server using the http protocol and sends some data to be processed by the server.
Our structure allow us to have the server installed anywhere. I can be on the same client network or even on the cloud.
When the server is hosted on the cloud, it makes sense asking the user for the server address (since it can change if the user wishes to) but it does not make sense when the server is on the same network that the client. Besides that, we are currently asking users to configure the server ip/name in order to connect to the server.
To avoid this (asking users for the address) I have developed a discovery service based on UDP. The client broadcasts a message that the server answer with its address. It does work on some cases, but it does not when the user has some kind of firewall, proxy or even an anti virus.
I have read a lot about discovery services, and the one that a like most is Bonjour.
So, the question is: what is the best way of discovering a server's IP when the server is on the same network that the client without being blocked by firewalls, proxies, etc?
You can keep your service purely local (in the intranet) and build on top of what you are using now by implementing hole punching. You can get past firewalls, but Im really not sure about AV software policies.
Or you can establish a well-known http-based discovery service in the internet.
A server comes alive, sends its (local) ip address to the discovery service (keeps sending keep-alives)
On startup, the client queries that discovery service, identifies the local subnet he is in, and gets back the local ip address of the server.
That of course creates a single point of failure in your system in that if the discovery service kicks the bucket, your clients cannot find servers. You can remedy that by replicating the service and/or introducing fallback mechanisms (like the purely local discovery you have), which you probably want to do anyway. The only problem you might have is the subnet identification, if computers in local subnets dont share external IP addresses (then it depends on what a local subnet is for you).
i am creating an application with client-server architecture in java. What i am trying to achieve is a simple client-server architecture connected via LAN with a ethernet switch, the server is having a server module of application running and also having MySQL database, the clients do their processing and submit results on server database, database also used for authentication.
the Server would be the only machine in network that will be connected to WAN through any ISP, the IP address of server machine cannot be guaranteed to be static, in this condition how the clients may connect to the server database? As the IP address of server is fluid..
One more doubt is that i've to authenticate the clients also on the basis of there IP addresses (or it may also be physical MAC address, if simple to implement), i've a table in database that the server admin can update and stores the IP addresses of valid clients, now on connecting via LAN what will be the IP addresses allocated to the machines to be stored in database and will they be static? i've googled for this but did not found relevant answers...
I hope i am clear with my question .I am sorry if the question is not related to stackoverflow,but it contains programming with database and networking too.
Thanks.
As I see it you have a few separate problems:
1. The IP addresses on the client machine are probably NOT static - a very high proportion of users are allocated dynamic addresses by their ISPs
2. There is no way to reliably connect to your Server as it has no static IP address.
The first problem can be solved by using the MAC address as you suggest (although this is easy to spoof if an attacker wants to) or some locally stored access keys.
The second is much more difficult (and really the reason why we have static IP addresses) - you need to use a VPN or some kind of forwarding service which does have a fixed IP afaik.