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.
Related
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
I'm new to cloud computing so this might be an obvious question. I have a desktop Java application that will connect to an AWS RDS MySQL database using JDBC. Is using the endpoint, username and password for the database the preferred commercial way of connecting to the database?
To encrypt communication I plan to use SSL.
You could open your database instance to the outside, using regular credentials. But, a safer way to proceed might be to create an endpoint in AWS, possibly running in Java, which would expose one or more APIs which in turn would hit the MySQL database running in RDS. That is, you would not expose the RDS instance to the outside world directly, but only internally to this API, also running in AWS. Then, your desktop Java application would talk to this intermediary application when it needs to access the database.
The advantage of this suggestion is that it lessens the risk of your RDS instance being attacked via something like DOS. Of course, the API you create on top of the database could also be attacked. But, Java web application running in a container (and other similar applications in other languages) were designed to be exposed to the outside, much less so database instances.
Per this, Cloud SQL requires the external IP address of the client in order to allow connections to it. The other suggested way is the sql proxy with a big disclaimer that the method may change over time.
Question: If I am auto scaling compute engine VMs running webservers, do I need to assign them all external IPs and then go set those in the Cloud SQL instance? Or am I missing something huge? Noob question perhaps, thanks for reading through.
The recommended way is to use the Cloud SQL proxy (but if you really don't want to use it you would need to add static IPs to your GCE VMs and whitelist them on the Cloud SQL instance).
Also, you can setup a single VM instance with cloud_sql_proxy and listen to your subnet interface (for example) to make possible to connect any new VM instance to the one with a proxy.
I have deployed my web server which requires a MySQL database for storage. I've created a Second Generation MySQL instance with one failover replica but I am not sure how I can connect to those.
I am not sure how to configure these instances and what I have to consider here e.g. region/zone. Flexible Environment appears to be unavailable in Europe unfortunately - at the moment at least - so I guess I'll have to place the SQL instances in the US too.
Will those instances have to be in the same local network or can they communicate over regions? Will I even be able to control this or will all this be decided by Google Cloud?
Could anybody who has done this before give me a few details about what to do here?
For best performance, you should place your App Engine instances in the same region.
For information on how to connect from your application to the Cloud SQL MySQL instance see the following documentation: https://cloud.google.com/sql/docs/dev-access#gaev2-csqlv2
The short summary is that you have to modify your app.yaml file to list the Cloud SQL instances you will be connecting to. Once that's done, a local socket will appear inside the App Engine VM that will allow you to connect to your Cloud SQL instance.
I was wondering if someone could tell me if there is any potential security breeches that could occur by connecting to a MySQL database that does not reside at 'localhost' i.e. via IP address?
Yes, breaches do occur by not protecting the connection to your database. This is a network secuirty question more so than an Application secuirty question. Thus this answer is entirely dependent on your network topography.
If a segment of your network maybe accessible by an attacker, then you must protect yourself with cryptography. For instance you have a malicious individual who has compromised a machine on your network, then they can conduct an ARP Spoofing attack to "Sniff" or even MITM devices on a switched network. This could be used to see all data that flows in and out of your database, or modify the database's response to a specific query (like a login!). If the network connection to your database is a single rj45 twisted connection to your httpd server all residing inside a locked cabinet, then you don't have to worry about a hacker sniffing this. But if your httpd is on a wifi network and then connecting to a database in China, then you might want to think about encryption.
You should connect to your MySQL database using MySQL's built-in SSL ability. This insures that all data transferred is highly protected. You should create self-signed x509 certificates and hard code them. This is free, and you don't need a CA like Verisign for this. If there is a certificate exception then there is a MITM and thus this stops you from spilling the password.
Another option is a VPN, and this is better suited if you have multiple daemons that require secure point to point connections.
It's usually the other way round that the bigger problem lies, vulnerabilities in the MySQL server being exploited by untrustworthy clients.
However, yes, there have also been client vulnerabilities in the past (eg.) that would allow an untrustworthy server to attack the client.
Naturally you should keep your MySQL client libraries up to date to avoid such possibilities, as well as updating the server.
If your connection to the server is going over the internet (rather than a private network), you should consider running it over an encrypted link (either MySQL's own SSL scheme or using a tunnel). Otherwise any man-in-the-middle could fiddle with the data going in and out of the database, and if there are client or server vulnerabilities those could also be targeted.
If the servers are in the same rack, you can use dedicated high-speed MySQL cable, or use switch VLAN isolation, and protect the database OS. In cloud with the virtual cloud network you can connect it the way that arp spoof is not possible, and for the geo-ip replication, you can use user/password and firewall, and then measure the performance, and then setup a tunnel and measure performance again, if it's not bad, it might be worth against unknown threats or just useful in using spare cpu cycles.
Simply SQL servers has to be on isolated network, and not into the public, as rule of thumb, you never publish open database connection to anyone, and keep it with seriously good firewall filtering on separate subnet made for handling sensitive data with very good arp spoofing protection, otherwise it's crackable and the major parts of the system can be compromised using several techniques, and it's very nice and sometimes very easy to handle it this way, e.g. to control, monitor and policy the MySQL traffic with hardware layer - and it really does the job and makes a real difference.
Optionally you can keep it on encrypted hard-drive in physically safe place along with the switch, so upon breaking the power its switched off, and the private key erased, hence both layer-1 and layer-2 are secured.
On the switch to use the static ARP table plus the filtering for the static entries versus the port is very easy to do because it's also physical layer - the port number.