Are there have way to access private server database without creating virtual private network (VPN), as my mind I need solution like these; I able to install application each client and through it create full duplex connection between client server machine and cloud server through it database should be access anywhere else to use some specific app or public users as stream. according to the below diagram, If someone know the solution please mention.
Related
I am creating simple application where I need get and fetch data to DB. As I find out from Xamarin app is standard using of HTTP request to DB instead of directly connect to DB.
I create Azure SQL DB, I create application with connection to this DB. But I cant really find out how it now should works.
There is no many tutorials or they are not fully described.
I read this one https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started#download-and-run-the-xamarinforms-solution
I find many references on this one but it seems out of date. Everybody recommended download the project from section
Run the Xamarin.Forms solution
On the settings blade for your Mobile App, click Quickstart (under Deployment) > Xamarin.Forms. Under step 3, click Create a new app if it's not already selected. Next click the Download button.
Under this tab I have only references to next tutorials but not any to Project Download. (screenshot below)
https://imgur.com/THCdUE1
Can you give me some advice if I do something wrong? Or link to updated tutorials? I am little desperate from this
Many Thanks
Azure SQL is not an HTTP/s service-- it runs proprietary SQL Server protocol on port 1433, just like on-premise versions of SQL Server.
If you are trying to connect directly to SQL Server from a Xamarin App, you are almost certainly making a mistake. Doing so would require providing credentials to your Xamarin app that can connect directly to your database, which opens your database up for a malicious user to do pretty much whatever they want to. The reason this kind of 2-tier application is dangerous is because the Xamarin app runs on an untrusted device (your user's mobile device), and a malicious user can intercept any data that your application has in memory, including your database credentials. They can then use those credentials to gain access to your database. Unless you were to use unique database credentials for each user (very impractical) and setup very stringent security roles in SQL Server, it'd be impossible to keep a malicious user from accessing the database for all of your other users (which is very, very bad). The other problem is that many networks block traffic on port 1433, or only allow access via an HTTPS proxy server, so your application would not function on many networks if it tried to connect directly to SQL.
This is the answer to your question, but please don't do this:
If you are certain that you have taken care of the security correctly, you should be able to install the System.Data.SqlClient nuget package and use that to communicate with SQL Server as you would with any .NET application. Here's a code example from Microsoft.
This is my opinion on what you should do instead:
The correct way for most Xamarin applications to communicate with Azure SQL database would be via an intermediary application server.
If your application access data specific to a user, should have per-user credentials in it (username and password that get exchanged for an authorization token when the user logs in is a common technique). The Xamarin app would then use HTTPS to make requests to your application server using those user credentials. The application server would validate the user credentials (authenticate that they are legitimate and authorize the data being requested based on who the user is) and make requests to Azure SQL.
If your application only access public data anonymously, then you can make unauthenticated requests to your application server which will blindly request that data from Azure SQL and return it to your client (though it would also return the same data to any attacker on the internet, so be sure if you use this approach you intend all data served to be public to the world).
In both cases, your application server would be the only piece that communicates with Azure SQL. For a .NET application this would typically be done via System.Data.SqlClient or perhaps indirectly through an ORM like Entity Framreworks. The advantage to this 3-tier approach is that the untrusted client tier does not have unrestricted access to your database tier. Only the middle application server tier has the credentials for SQL Server, and it is trusted and runs in a secure environment (a server you manage, not an end-user's mobile device). This means that an attacker cannot intercept the database credentials and misuse them. It also means that your application only requires HTTPS data access to function, so your application will work on almost any network.
This is probably not the answer you are looking for, since it involves authoring an entire application server that has to be hosted by you (Azure App Service would be my recommendation, if you are already using Azure SQL). It also requires you to implement an API on the server, and then write an API client for your Xamarin application. This is no small amount of work.
Is it possible to connect an Azure logic app to an FTP server residing on an Azure VM that lives in a subnet under a private IP address ? I cannot, when trawling the internet, find many (-if any at all) references to anybody trialling this, although we felt it might be a valid test of a need to access sFTP under unusual network circumstances. We have such a server, initially created to act as a 'remote' development VM but accessible via another Azure VM which can connect with our on-premise network, acting as a 'jump' server.
It is not a showstopper if we cannot do this - we can, after all, set up non-private VMs to act as FTP servers. And I understand that 'private' might be private for a reason ! But I was surprised that I cannot find any definite content, from Microsoft or anyone else, that this isn't possible: it seems that the only way to engineer such connection might be through an expensive Azure Integration Account or Application Service Environment. But the hint that such connection might be possible via those additional Azure facilities has caused my organisation to investigate the possibilities via the usual logic-app connector features. Thanks
No, your supposition is correct. Private means private. You can't directly access your private VM on Azure for the same reason you can't access a private VM on an internal network.
But, all the same facilities are available. If it's a Windows VM, you can use the On Premise Data Gateway with the File Connector.
I was moving all website to google cloud and encounter a performance problem.
I set up a VM instance on Compute Engine and a Cloud SQL server.
And connect the Joomla website from VM to Cloud SQL server using provided IP address. (Seems public IP)
The performance is really slow compared to the website using local database inside the VM itself.
So, my question is, is there a way to find local IP to connect to Cloud SQL since our web server is also on the Google Cloud infra itself.
Or, the only way is to stick with the database inside VM?
Update
I set up the Cloud proxy using this guide.
Can connect to mysql prompt with the proxy now.
But still cannot find a way to let joomla use this cloud proxy to connect to the database.
The fastest, easiest, and most secure way to connect to your Cloud SQL instance from your Compute instance is by using the Cloud SQL Proxy. There are multiple reasons for this, but here are the main ones:
Secure connections: The proxy automatically encrypts traffic to and from the database using TLS 1.2 with a 128-bit AES cipher; SSL certificates are used to verify client and server identities.
Easier connection management: The proxy handles authentication with Google Cloud SQL, removing the need to provide static IP addresses.
There's also the fact that you only need a static and small number of instances (1 in your case) connecting to the database, so you don't really need to overcomplicate your setup, you can just drop this binary into your instance, run it as a daemon, and instantly have a fast lane to your Cloud SQL instance (I use "fast lane" here because the traffic will go through Google Cloud's internal network).
Setting up the Cloud SQL Proxy comes down to enabling the Cloud SQL API, giving the service account of your intance access to the Cloud SQL API, making sure the binary has execution permissions (chmod +x), and giving it the connection string to the Cloud SQL instance. You seem to be having issues using the Proxy, so if you need more troubleshooting ideas, you can find them in the documentation. The tutorial you've followed should have detailed instructions on how to do these steps.
After all of that and after making sure the Proxy is running, connecting Joomla to the database should be similar to how you do it via the MySQL client. You should point your Joomla installation to localhost (or 127.0.0.1), give it a set of credentials to access the database itself (you can create database users via the Console), give your Joomla database's name, and that should be it!
Don't forget that the Proxy needs to be running in TCP mode! That should be as simple as adding =tcp:LOCAL_PORT_TO_LISTEN_ON to the connection string parameter you're passing to the Proxy. Here's an example of how to run the Proxy:
./cloud_sql_proxy -instances=<INSTANCE_CONNECTION_NAME>=tcp:3306
Virtual Private Cloud (VPC) helps to increase the performance.
Private Google access enables virtual machine (VM) instances on a subnetwork to reach Google APIs and Services using an internal IP address rather than an external IP address. You can use Private Google access to allow VMs without Internet access to reach Google services.
Here you get more details: https://cloud.google.com/vpc/docs/private-google-access
I want to deploy my web application including a SQL Server 2008 database from my local machine to my hoster.
So far I used the Windows authentication, is it necessary to switch to username and password when I want to make my application public on the internet?
And if that's the case, what's the best practice to hide that information if they are saved as strings in the web.config?
Side note: I use Linq to Entities as Object Mapper and within the code I use
HttpContext.Current.User to authenticate the user
If you are not using shared hosting, then you can keep using windows authentication which is more secure than having SQL server user.
You should also disable remote connections so that no one can directly access SQL server to make it more secure.
For encrypting connection string check this site.
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.