Is it secure to have data be sent to free database at mongolab from heroku app.
Data could be like emails, and preferences.
Or do you need ssl, i've read about mongodb ssl.
I've asked around but couldn't find anything specific to mongolab.
From MongoLab's documentation:
Securing communications to your database
You should always try to place your application infrastructure and
your database in the same local network (i.e., datacenter / cloud
region), as it will be the most secure method of deployment and will
minimize latency between your application and database.
When you connect to your MongoLab database from within the same
datacenter/region, you communicate over your cloud hosting provider’s
internal network. All of our cloud hosting providers provide a good
deal of network security infrastructure to isolate tenants. The
hypervisors used do not allow VMs to read network traffic addressed to
other VMs and so no other tenant can “sniff” your traffic.
However, when you connect to your MongoLab database from a different
datacenter/region, your communications are less secure. While your
database does require username / password authentication (with
credentials that are always encrypted on the network), the rest of
your data is transmitted unencrypted over the open internet. As such
you are potentially vulnerable to others “sniffing” your traffic.
Using MongoDB with SSL connections
Available for Dedicated plans running MongoDB 2.6+ only
To further secure communications to your database, MongoLab offers
SSL-encrypted MongoDB connections on Dedicated plans running MongoDB
2.6 or later. Even when using SSL, we still recommend placing your application infrastructure and your database in the same
datacenter/region to minimize latency and add another layer of
security.
I did the same thing as you and sent email to ask mongolab for detail. I got the answer, sharing it with you and hope it can help you.
The below is the reply.
As long as your Heroku app and MongoLab database are in the same cloud
region, we consider it safe to communicate between Heroku and
MongoLab, as AWS' infrastructure prevents packet-sniffing within
regions. If you use the MongoLab addon on Heroku this is automatic,
but if you use a deployment provisioned directly at mongolab.com
you'll need to manually select the matching region.
It looks like the connection between heroku and mongolab is in the same region. Both are secured by AWS so I guesss you don't need SSL. If you need it to be very safe, you still need SSL for extra security.
Hope it can help
Related
I am creating a WebService with C# Core 3.0 that is using MySQL and Redis, but I am not so familiar with Azure so I need advice about configuring everything.
I had MySQL hosted on AWS, but I am transferring it to Azure because I think that performance (speed) will be better on Azure because they will be on same data center. Right?
But, on my MySQL page Host is like '*.mysql.database.azure.com'. That means that every connection will go out of Azure, and than come back? I don't have some local IP for connection? Same question for Redis.
Do I need to configure some local network on Azure and will that impact speed on the app? And, is MySQL a good choice for Azure or should I try with another one?
I am just reading about Azure Virtual Networks. But as I understand it, VN's sole purpose is to isolate elements from the outside network?
You will get better performance if your my-sql instance and your app service are in the same region (basically the same data centre).
The connection string is mysql.database.azure.com, but remember the connection will be a TCP/IP connection, so the DNS lookup will realise that this address mysql.database.azure.com is in the same region (same data center). Then the TCP/IP connection will go to an internal IP.
You could use tcpping in your app service's kudo console to try this and see the result.
The basic rule is that you should group your app and database in the same region for better performance and cheaper cost (as Microsoft doesn't charge traffic within the same region).
Azure Virtual network is for a different purpose. For example, if you have some on premise database servers and you want to call these servers from azure, then VM could be helpful. But for the scenario you described, it is not really needed.
The company I work for has Microsoft azure support included, and if you or your company have support contract with them, you can raise questions directly to them and get really quick responses.
So I am learning node.js,docker and mongodb.And I have a few doubts.
I have three tasks of a service(replicas) (node.js in docker services).The service is supposed to access a mongodb database.I have two options:
Use atlas-this sounds simple to me as I am a beginner.
Use mongodb containers-Which I believe could be a little more work.
So the question is if I use MongoDB atlas and connect to the database hosted on atlas is the transfer of data between node.js and atlas secure by default?what should be done to "secure" the transfer of data between the node.js container service and the Mongodb atlas?
If I choose the second option above should all three replicas/tasks communicate with only ONE mongodb container?
is the transfer of data between node.js and atlas secure by default?
Without knowing your application environment, I can't comment about security on your side of the network.
However for MongoDB Atlas, it's using TLS/SSL and authentication (SCRAM) enabled by default (and cannot be disabled).
Traffic from clients to Atlas is authenticated and encrypted in-transit, and traffic
between the customer’s internally managed MongoDB
nodes is also authenticated and encrypted in-transit using
TLS/SSL.
Also depending on which cloud provider you would choose in Atlas (AWS, GCP, or Azure) they each provides different encryption at rest features (transparent disk encryption).
Please note that there are other security features provided by MongoDB Atlas, i.e. IP Whitelisting. See also MongoDB Atlas: Security Features and Setup and MongoDB Atlas Security Controls.
If I choose the second option above should all three replicas/tasks communicate with only ONE mongodb container?
I'm not sure I understand this question. The purpose of having a replica set is to provide High Availability (in the case of a primary failover, the other will automatically take over). Having all three nodes of replica set deployed into a single Docker container will defeat this purpose.
I have a Node.js/JavaScript application deployed to Bluemix. I need my application to be able to connect to a DB2 datasource (connection string shown below).
The lexbz181112.cloud.dst.ibm.com is an IBM server running on premise.
What steps do I need to take to connect to this datasource from my application (which is running in Bluemix)? I don't want to change any of my application code in order to read/write from the database.
DRIVER={DB2};DATABASE=MYDB;HOSTNAME=lexbz181112.cloud.dst.ibm.com;UID=xxx;PWD=xxx;PORT=nnnnn;PROTOCOL=TCPIP
It is the same when you connect your application to remote database or cloud database, as long as you have hostname:port, database name and username/password.
If your application and database both on Bluemix, have you tried to bind this database service to your application directly?
The Bluemix Secure Gateway service is used in such cases. It establishes a secure, transparent bridge between your on-premises resource, in your case the DB2 server, and your cloud application. Because it is transparent to the application you don't need to change your application code. The secure connection is established from "on-prem" to the cloud, so that the on-prem administrators are in charge.
Some time I ago I wrote a sample application to walk through all the steps to create a scenario as described by you. You can find the instructions on GitHub.
If the host is reachable from the Internet you can simply access it from your application as you'd normally do, since a Bluemix application is able to connect to the Internet. The only improvement I'd do to this is to use a user provided service instance. It allows you to separate the DB connection parameters from the application code, avoiding to have those hard coded in the application.
I've recently migrated an application from heroku to amazon-ec2 because of recomendations from a security consultant. Yet, he didn't know deeply heroku and the doubt remained.
Can access to a Heroku PostgreSQL DB be restricted for it to be accessed only by the application?
Would you recommend Heroku for security critical applications?
This is a deceptively complex question because the idea of "restricted so that it can be accessed only by the application" is ill-defined. If your ultimate goal is simply to keep your data as secure as possible, then Heroku vs. AWS vs. physical servers under lock and key involves some cost-benefit analysis that goes beyond just how your database can be accessed.
Heroku limits database access via authentication. You share a secret (username/password) between the database and the application. Anyone who has that secret can access the database. To facilitate keeping the secret secret, all database access is or should be over SSL.
There are other ways to restrict access in addition to authentication, but many of them are incompatible with a cloud-based approach. Also, many of them require you to take much more control over the environment of your servers, and the more responsibility you have on that front, the bigger the chance that issues totally separate from who can hit the postgres port on your database will sink you.
The advantage in using AWS directly instead of through a paas provider like Heroku is that you can configure everything yourself. The disadvantage is that you have to configure everything yourself. I would recommend you use AWS over a managed service only if you have a team of qualified and attentive sysadmins to configure, monitor and update your environment. Read Heroku's security policy page. Are you doing at least that much to protect your servers in your own configuration on AWS? If not, then you might have bigger problems than how many layers of redundancy are in place around your database.
I'm currently performing a research on cloud computing. I do this for a company that works with highly private data, and so I'm thinking of this scenario:
A hybrid cloud where the database is still in-house. The application itself could be in the cloud because once a month it can get really busy, so there's definitely some scaling profit to gain. I wonder how security for this would exactly work.
A customer would visit the website (which would be in the cloud) through a secure connection. This means that the data will be passed forward to the cloud website encrypted. From there the data must eventually go to the database but... how is that possible?
Because the database server in-house doesn't know how to handle the already encrypted data (I think?). The database server in-house is not a part of the certificate that has been set up with the customer and the web application. Am I right or am I overseeing something? I'm not an expert on certificates and encryption.
Also, another question: If this could work out, and the data would be encrypted all the time, is it safe to put this in a public cloud environment? or should still a private cloud be used?
Thanks a lot!! in advance!!
Kind regards,
Rens
The secure connection between the application server and the database server should be fully transparent from the applications point of view. A VPN connection can connect the cloud instance that your application is running on with the onsite database, allowing an administrator to simply define a datasource using the database server's ip address.
Of course this does create a security issue when the cloud instance gets compromised.
Both systems can live separately and communicate with each other through a message bus. The web site can publish events for the internal system (or any party) to pick up and the internal system can publish events as well that the web site can process.
This way the web site doesn't need access to the internal database and the internal application doesn't have to share more information than is strictly necessary.
By publishing those events on a transactional message queue (such as MSMQ) you can make sure messages are never lost and you can configure transport level security and message level security to ensure that others aren’t tampering messages.
The internal database will not get compromised once a secured connection is established with the static Mac ID of the user accessing the database. The administrator can provides access to a Mac id through one time approval and add the user to his windows console.