In Performance tips of Cosmos DB suggested by Microsoft, it is recommended to use Direct Mode i.e. TCP and HTTPS protocol to query Cosmos DB, just wanted to know what is default connection policy of Cosmos DB document Client?
var client = new DocumentClient(new Uri(endpointUrl), _primaryKey)
If I use above code, what Connection Policy will be used?
https://learn.microsoft.com/en-us/azure/cosmos-db/performance-tips
If I use above code, what Connection Policy will be used?
I think the performance tips article already has made it clear. If you do not set the direct mode in sdk, it will be Gateway Mode (default).
You could see the statement:
Gateway Mode is supported on all SDK platforms and is the configured
default. If your application runs within a corporate network with
strict firewall restrictions, Gateway Mode is the best choice since it
uses the standard HTTPS port and a single endpoint.
Related
My company has a hard outbound network firewall rule that blocks everything except port 443. This blocks Mongo Compass from doing a direct connect to the cosmosdb via connection string. Is there any way to connect it to the Gateway API? Or are there any other desktop UI's that will work with Azure Gateway?
It's not possible to change the port for a MongoDB API account on Cosmos DB.
You can connect to the Mongo shell in the Azure Portal for your Cosmos DB account as that is over port 443, but there's no option I know of that allows you to connect to it.
I'm currently developing an application for a client and their requirement is that the application needs in transit and at rest encryption. I assured that it was and was required to provide documentation for that. I referenced this documentation from Google Cloud's website. They replied by asking if my claim stands in light of the following section
Using a connection directly to a VM using an external IP or network load balancer IP
If you are connecting via the VM's external IP, or via a network-load-balanced IP, the connection does not go through the GFE. This connection is not encrypted by default and its security is provided at the user's discretion
My mobile application uses Firebase SDK to talk to the Firebase database and Firebase functions. I have no background in networking nor do I understand what is exactly being referenced here despite Googling the concepts. Is my data still encrypted? Does the above section apply to my use case?
No, that applies only to VMs and network load balancers. Both Cloud Functions (so long as you're using https for all requests) and the Firebase Realtime database encrypt data in transit.
I want to connect to Snowflake using ODBC, and I saw that it is SSL enabled by default(Does snowflake support ssl?).
Appreciate where I can have it formally from Snowflake, as I yet to find as such documentation..
Thanks !
All snowflake connectivity is to:
https://..snowflakecomputing.com
Even the ODBC connector is just a wrapper for HTTPS calls to then https URL above. That means that everything in snowflake, Web UI, JDBC, ODBC, snowsql, Python etc all runs over HTTPS and SSL.
It's also worth noting to meet the security standards here, all traffic must be SSL:
https://www.snowflake.com/snowflakes-security-compliance-reports/
I would read the following document, which has a bunch of different sections that reference SSL, OCSP, and openSSL key-pair settings.
https://docs.snowflake.com/en/user-guide/odbc-parameters.html
Appreciate where I can have it formally from Snowflake
The Snowflake Security Policy specifies that all customer data in transit is encrypted with TLS 1.2.
https://www.snowflake.com/wp-content/uploads/2018/07/2018July12-Snowflake-Security-Policy.pdf
Reference section 3.1. Encryption of Customer Data, which states "Snowflake leverages Transport Layer Security (TLS) 1.2 (or better) for Customer Data in-transit over untrusted networks."
This statement applies to all customer data in transit, so ODBC is included.
There are the following parameters:
I use the FirebirdSql.Data.FirebirdClient library in asp .net
Now, at the test level, I connect to the remote database using the line:
string workbase = "Server="public ip";Port="port";User=sysdba;Password=masterkey;Database=C:/path/db.FDB";
Further are connection methods, requests, transactions, commits, etc.
string sqlcardpin = $"SELECT.....";
var connection = new FbConnection(workbase);
Question: is it safe? Is traffic encrypted? where can I read about it? How should I connect?
From my modest brain efforts, the following goes: I need to have a service in a local network with a database, to which a secure connection goes, and this service has credentials for connecting to the database and performs operations with it, maybe I'm wrong, please correct me.
If 'public ip' is a publicly routed IP address, and port 3050 is open to the whole world, that is not safe. Don't expose your database server to the world, it will create a very wide attack surface to get at your data.
For example, Firebird 2.5 and earlier have a very weak authentication system (max 8 character passwords), and while Firebird 3 introduces a new, more secure authentication mechanism that allows much longer passwords, for various reasons, a lot of servers are still configured with the weak authentication (also) enabled. Also consider bugs that might allow people to circumvent authentication, or that could allow people to remotely crash your database server, etc.
As to encryption, Firebird 2.5 and earlier have no encryption of the connection. This was introduced in Firebird 3, and only for connections authenticating with the new SRP (Secure Remote Password) authentication mechanism, and only if the WireCrypt setting of the server is Required or Enabled and the client actually requests authentication. For C#, this requires Firebird ADO.net provider version 7.0.0.0 or higher. However, the wire protocol encryption offered in Firebird 3 is the relatively insecure RC4 encryption; Firebird 4 will introduce ChaCha-20 as an alternative wire protocol encryption.
So, your database should be on the same network as your application, preferably on an IP address that is not routable over the internet (ie in one of the private ranges), or at least shielded from the internet by a firewall. If for some reason you need to connect to a remote database over the internet, do not expose the database directly to the internet, but use a VPN solution, or maybe something like an SSH-based tunnel.
And as corradolab points out in their answer, don't use masterkey as a password for SYSDBA. In fact, don't use SYSDBA for your application to connect, but create a specific user and assign it the necessary but minimal rights for it to do its work.
You didn't say if the web server and the database server are on same or different site, but, anyhow,
do not expose a database server to the public Internet.
If web and database server are in different sites, consider using a firewall (on the database) to allow connection only from the web server address or a VPN between the two sites.
If they are in the same site, expose only the web server to the Internet (put it in DMZ) and keep the traffic to and from the database server on the private LAN.
BTW Having Firebird on the Internet using sysdba/masterkey is like going around with "kick me" written on your back. Don't be surprised if it hurts. :)
Do we have any way to connect document dB emulator from remote system ?
Can we create procedure , triggers , user defined functions etcs in document db emulator ?
The Emulator is meant for local dev scenarios, since it runs exposing a local port, you probably could (never tried, this is purely theoretical) work around the firewall and expose it, then connect from another system using your external IP and the exposed port.
There is also the local SSL certificate that you must solve (that probably is the biggest issue), though you could try with the TCP connection setting, might want to check this thread about which ports need to be opened.
Also, the Emulator does not have the entire feature set that the live service does:
The DocumentDB Emulator supports only a single fixed account and a well-known master key. Key regeneration is not possible in the DocumentDB Emulator.
The DocumentDB Emulator is not a scalable service and will not support a large number of collections.
The DocumentDB Emulator does not simulate different DocumentDB consistency levels.
The DocumentDB Emulator does not simulate multi-region replication.
The DocumentDB Emulator does not support the service quota overrides that are available in the Azure DocumentDB service (e.g. document size limits, increased partitioned collection storage).
As your copy of the DocumentDB Emulator might not be up to date with the most recent changes with the Azure DocumentDB service, please DocumentDB capacity planner to accurately estimate production throughput (RUs) needs of your application.
So, you are probably better off installing the emulator on the other system via the installer or Chocolatey and avoid all the problems.
UPDATE: My following attempted solution doesn't work. Connection Timeout, 192.168.0.101:8881 using the Node.js DocumentDB sdk. I think because of SSL. :/ Sorry. Leaving this "Answer" for documentation on what doesn't work, and if anyone knows how to bypass DocumentDB Emulator SSL.
I am trying to connect DocumentDB Emulator across my local network. (I dev on a virtual machine)
I am trying to do a port forward, to the 8081 local port that DocumentDB Emulator listens on. In Command Prompt (Run as Administrator)
netsh interface portproxy add v4tov4 listenaddress=192.168.0.101 listenport=8080 connectport=8081 connectaddress=127.0.0.1
192.168.0.101 is the network address of the PC.
Now I'm able to navigate to:
https://192.168.0.101:8080/_explorer/index.html and see the data explorer. Optimistic I can get this working for dev, with SSL turned off?
Also tried to use node.js http-proxy couldn't get it working with self-signed certificates. :(
Update, I actually got http-proxy working, but it only works if you start the servers in a specific order...
start api server
start proxy server (on windows box) with secure: true
make a failed connection
change proxy server (on windows box) to secure: false; restart;
now it's working... but useless for dev, because if you restart the API server after code change, the connection fails again.
Sample Node.js Proxy to be run on Windows box:
```
var fs = require('fs'),
httpProxy = require('http-proxy');
//
// Create the proxy server listening on port 443
//
httpProxy.createServer({
ssl: {
key: fs.readFileSync('valid-ssl-key.pem', 'utf8'),
cert: fs.readFileSync('valid-ssl-cert.pem', 'utf8')
},
target: 'https://localhost:8081',
secure: true // Depends on your needs, could be false.
}).listen(8881);
```
You just need to start the documentdb with additional parameters:
start "" "c:\Program Files\Azure Cosmos DB Emulator\CosmosDB.Emulator.exe" /AllowNetworkAccess /NoFirewall /Key=C2y6yDjf5/R+ob0N8A7Cgv30VRDJIWEHLM+4QDU5DE2nQ9nDuVTqobD4b8mGGyPMbIZnqyMsEcaGQy67XIw/Jw==
Checkout the documentdb docker file for more details: https://github.com/Azure/azure-cosmos-db-emulator-docker/blob/master/package_scripts/startemu.cmd