I've been looking at setting up a MongoDB as a Service on Mongo HQ/Compose.io or some other service.
From what I can gather the major security hole is the data in transit. Mongo doesn't support native driver SSL by default, and most DBaaS providers don't offer it standard.
It seems to me that it is a big security risk. Am I wrong here?
thanks.
Yes, That is correct. MongoDB does not support SSL by default and few DbaaS providers don't usually offer one. You might have to manage mongodb yourself. The easiest way I guess is to docker it up.
Btw, Did you check out CloudBoost.io (https://www.cloudboost.io). We have SSL on our API's and have all the features which MongoDB has and more.
P.S : I work at CloudBoost.io
Related
I'm trying to encrypt the data of my MongoDB database (very sensitive data). MongoDB Entreprise advises to use a KMIP server.
What do you advise me to use to manage my keys compatible with the KMIP protocol? I find that installing my own server can be complicated to maintain.
That's why I would be more reassured to go through a company that offers a KMS. AWS or Google offers this kind of service but are not compatible with the KMIP protocol.
What do you advise me?
Thank you
I'm trying to apply security best practices to an AWS RDS postgresql instance, but Amazon seems to have gone out of its way to prevent some fairly common and routine features around authentication. I don't seem to be able to authenticate against any external source, which sucks, since now I have to maintain db users completely separately from normal user management. But it seems that, despite the fact that I can use SSL to connect, none of the functionality that might actually validate a client's cert against the server's CA is accessible in RDS. Is this true? It seems like the easiest thing in the world to have amazon sign certs with it CA and then validate those certs against that CA when connections are established, yet I cannot find any mention of how to do it in the documentation or out on the web. Am I really confined ONLY to password authentication of db-internal users? This is almost hard to believe, but after days of research, is the only conclusion I have been able to support.
I've got a spring boot app which is connected to mongodb atlas.
Everything is working locally.
I now want to publish this to pivotal cloud foundry.
Secure connection between PCF and atlas
In mongodb atlas I need to open up the firewall an allow certain ip numbers.
How should I configure mongodb atlas to connect to pcf in the most secure way?
Autoconfigure getting in the way
cloud foundry is overriding my connection urls to point to localhost:27017 instead of my atlas cluster.
What is the recommended way to connect to mongodb atlas?
In mongodb atlas I need to open up the firewall an allow certain ip numbers. How should I configure mongodb atlas to connect to pcf in the most secure way?
White listing IP addresses for applications that run on CF is not particularly effective. The reason it's not effective is that you don't know the IP address from which you'll be connecting, because it depends on where Diego decides to run your application. In other words, it depends on the cell where your application is told to run. To compound matters, that will change when you restart / restage your application.
Because the IP can vary, what you end up needing to do is white list all of your Cells. The problem with this and why it's not effective is that you've ended up white listing every app running on the platform.
What you can do to improve the security a bit is to make use of application security groups. ASG's can be used to limit outgoing traffic. You can also control them at the space level. That means you can configure your default running security group to not allow access to your MongoDb server, but you can allow access for individual spaces by binding an ASG to only those spaces with apps that need to talk to your MongoDb servers.
The downside of this approach is that it requires you to be a platform administrator, which means it will only work if you own your CF installation (not going to work for public providers).
More on ASG's here: https://docs.cloudfoundry.org/adminguide/app-sec-groups.html
For public providers, you can use a proxy. To make this work, you need to have your application configured to talk through a proxy when it attempts to access your Mongodb servers. You control the proxies, which have fixed IPs, so you can white list the proxies to allow access to just your app. If you don't want to run your own proxy servers, there are public proxy providers that you can use.
cloud foundry is overriding my connection urls to point to localhost:27017 instead of my atlas cluster. What is the recommended way to connect to mongodb atlas?
It's possible to disable auto configuration. One way is described in the docs here. If you include the Spring Cloud Connectors dependencies and use them manually, then the auto configuration will not run.
https://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html#manual
The other option is to tell the Java build pack not to install the auto configuration. You can do that by setting the following environment variable for your application, either with cf set-env or via a manifest.yml file.
Ex: JBP_CONFIG_SPRING_AUTO_RECONFIGURATION='[enabled: false]'
Be careful if you do this as it will disable everything provided by the auto reconfiguration, which includes setting the "cloud" profile for your app. If you use this option to disable auto reconfiguration, you'll probably also want to set SPRING_PROFILES_ACTIVE='cloud' to manually enable the cloud profile.
I suppose your other option is to simply embrace the auto configuration. It's a little confusing / magical at first, but I've found this article to explain it very well.
https://spring.io/blog/2015/04/27/binding-to-data-services-with-spring-boot-in-cloud-foundry
Hope that helps!
I'm using CloudFlare to get free SSL coverage for a domain I own on GoDaddy. That's great and if you haven't checked out those services you might find them handy to use. I do have a question though, I'd like to provide HTTPS/SSL encryption for data transmitted from my MongoLab DB to my Heroku App. Both of these are through Heroku. So,
(1) Do I need additional SSL encryption to protect the sensitive data I'll be transmitting between those two endpoints?
(2) How do I go about acquiring that?
(3) If yes to (1) and no good answer for (2), what's an alternative (nearly free) option to accomplish the same thing. I'm not wed to MongoDB for this project.
Thanks in advance and hope this question helps someone else out as well.
Apparently, Heroku maintains that if you provision a MongoLab DB through them (and not through MongoLab directly) and have your Heroku app in the same AWS region you're fine as no packet sniffing can occur.
Otherwise you can purchase separate SSL encryption.
I've also decided to encrypt the data going into my database as well.
How are Cassandra clusters usually built in security way? Should they always be kept locally or are there any security functions that makes it reasonable to open up for external connections to the cluster? As far as I've understand I seems like Cassandra doesn't have any "inbuild security engine" for handling these kind of things. I'm planning on building a service to talk with the Cassandra from, should that connection be made locally (on the same net as the cluster) or from external using the DNS?
Cassandra supports builtin password authentication and authorisation since version 1.2.
User credentials and privileges are kept internally, in system auth tables. This can be viewed as its "inbuild security engine".
As for protecting connections (encryption), since version 1.2, there's SSL support for both internode and client-to-node communication. DataStax Enterprise platform additionally extends that with Kerberos/LDAP support to allow single-sign-on.
Configure a stateful firewall to allow incoming connections, but allow outgoing only if someone requested something from the server. Also C* has inbuilt SSL support, but not all APIs can use the SSL, so you'll have to pick a compatible one.