I'm having some mongodb connection securtity concerns for my env.
Here is my environment:
one ECS hosted on cloud that has a public IP but no domain and no ssl certificate neither.
installed mongodb service on this ECS that needs username/password to authenticate
only specific IPs in the whitelist can access the ECS/mongodb
I'm wondering if the data transfer between this mongodb and my local pc is safe or not?
Will the data be encrpyted during the transmission or just plain text so that everyone on the internet can catch and read it? (As I don't have https so it's not using TLS/SSL)
Can canyone explain the machanism or give some some doc links?
Thanks!
As your not using SSL, your data on fly is not encrypted. You need to use TLS/SSL to encrypt the network transmission. You must have the TLS/SSL certificates as PEM files, which are concatenated certificate containers
In addition to encrypting connections, TLS/SSL allows for authentication using certificates, both for client authentication and for internal authentication of members of replica sets and sharded clusters
Related
I have 2 aws accounts having their own RDS instances(not publicly accessible) with db engine as postgresql 12.5. I downloaded RDS certificate from "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem".
I am using JDBC(postgresql driver) with properties ssl=true and sslrootcert="path to above certificate" to establish secure connections.
My questions:
This certificate is same for both aws accounts which have different names, so how does it work , Does ssl hand shake verifies that client(jdbc connection) is talking to rds.amazonaws.com or the actual RDS instance which has separate name ?
RDS certificates are replaced every 5 years, i.e. applications also have to update the certificate every 5 years or sooner than that once new certificate is available from RDS, is this correct ?
Q1.
Yes, its same for all accounts. You can download it from docs here. Its about the instances as explained in the docs:
Using a server certificate provides an extra layer of security by validating that the connection is being made to an Amazon RDS DB instance.
Q2.
You can update before actual expiration few months before. Last year it happened as explained here:
The server's certificates are each different. Each server sends its own cert when you ask to establish a SSL connection to it. The thing you download is the cert for the authority which signs each of the server certs. You (Or your JDBC) use it to verify that the per-server certs are genuine.
For GCP managed SQL databases: we want to enable SSL/TLS using a common client cert across all our GCP databases. From reviewing the official google docs (https://cloud.google.com/sql/docs/mysql/configure-ssl-instance), it seems the server certificate is not customizable and we require a different client certificate for each database instance.
Is there any solution where we can use a common client cert for multiple database instances?
How do we create client certificate to get validated by aws document db?In aws docs https://docs.aws.amazon.com/documentdb/latest/developerguide/connect_programmatically.html#connect_programmatically-tls_enabled, it is mentioned only about one way ssl i.e.,clients authenticating server certificate.I didn't find information regarding two way ssl supported by aws document db.Can anyone help on this?
Amazon DocumentDB does not support using client certificates to connect to your cluster. Are you looking for client-side certificates to be used by the server for authentication? Amazon DocumentDB only supports SCRAM based authentication.
After reviewing several MongoDB official documents (see list at the bottom) I understand that MongoDB security in communications (as in community version 4.2) works as follows:
For internal communication authentication (i.e. between the members of a replica set or between mongos and the replica sets which implement the different shards) there are two mechanisms available:
shared keyfile (--keyFile)
x.509 certificates
For internal communication encryption, SSL/TLS is the only possibility. In other words, shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative. Using SSL/TLS requires to use x.509 certificates also (so, we can say that encryption also provides authentication)
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster):
there isn't keyfile option
the only way to secure communication (which provides both authentication and encryption) is SSL/TLS with x.509 certificates
I'd like just to confirm my understanding, as the documentation I have browsed is a little "disperse" and I'm not sure if I have got the point. Any feedback, comment, extra info or documentation pointers is really welcome!
PD: the statement which I'm most unsure is this one: "shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative"
References checked:
https://docs.mongodb.com/manual/tutorial/configure-ssl
https://docs.mongodb.com/manual/tutorial/configure-ssl-clients/
https://docs.mongodb.com/manual/core/security-internal-authentication
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster) there are several authentication methods:
No authentication
Internal authentication with username/password
Kerberos Authentication
LDAP Proxy Authentication
LDAP Authentication
Note, you can always connect to MongoDB database, even without an account. However, you are not permitted to execute any command unless you are authenticated.
Does the client x.509 certificate encrypt the data as well as handle authorization?
Documentation says it handles authorization and message signing. But does that mean the data is encrypted in transit?
It is NOT encrypted when using Secure-Cluster with Certificates (Node2Node + Client2Node) with default Rpc-Endpoints. In Wireshark you can see the whole communication. It seems just for authorization.
Endpoints with https are encrypted of course.
Yes, a given x509 certificate will be used to encrypt the data while communication happens between a client and the cluster. As for authorization, it means that you could set what client certificates will posses 'SF Cluster Admin' privileges, and the ones that will allow only to query the info about your cluster.
In addition to the cluster certificates, you can add client
certificates to perform management operations on a service fabric
cluster. You can add two kinds of client certificates - Admin or
Read-only. These then can be used to control access to the admin
operations and Query operations on the cluster. By default, the
cluster certificates are added to the allowed Admin certificates list.
you can specify any number of client certificates. Each
addition/deletion results in a configuration update to the service
fabric cluster