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.
Related
I have been researching for a couple days and looking at pluralsight courses but I Can't seem to find a decent answer on how to setup a proper Azure infrastructure.
I have a client app, api backend, and a database as a core of my overall application. I know I need 2 different Web App services and an SQL database.
I also have a need to only allow access to all 3 from our company's IP address.
I'm getting lost with all the VNET and VPN talk and I am wondering if that is even required. Is it considered good to do IP restrictions and call it a day? Should I add an Application Gateway infront of the client application none the less?
If VNETs are required, is it a must to do site-to-site? (don't think we have the authority to do that) If not, how do we access the backend services like the database and API if everything is locked down?
Any help is appreciated because there is too much information and I can't seem to make sense of any of it.
Thanks
It depends a lot on both the purpose of your client application, web application and database, as well as the capabilities that currently exist within your organisation. Have you had a look at the references architectures Microsoft has as a starting point ?
If you are looking at a fairly simple application, deployed to Azure with minimal internal only use, then use something like this reference architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/vpn. You can actually simplify that a little further by removing the load balancers etc if you think traffic will be generally low.
If you are looking for an external application that can only be managed internally, you should adopt something similar to this reference architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/n-tier-sql-server. Maybe even add a VPN component to the management jump box similar to this architecture: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/hybrid-networking/vpn.
Even this, however may be too complicated for your use case. If your application is pretty basic, is secured using username/password or identity federation, and has low risk data associated with it, then just the basic web application architecture would do fine, just read through the various considerations here: https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/basic-web-app
To who it may concern,
I am looking to move more of our applications that the company uses to azure. I have found that Remote App will allow people to us the apps I have allowed via the Remote App. The application which will be used is linked to a database which is on site, I am just worried about people being able to access this database as it will contain important data which cant be leaked. I am trying to work out what are some security precautions which could be taken to prevent the data from being viewed by the wrong people. I have seen app locker to stop applications on the virtual machine from being accessed. Any other security suggestions would be greatly appreciated.
You should be fine. Remote app is running remotely - meaning that theres no way of getting to the connection string (reverse engineering). Access to the app is also ensured by AAD login. The database should be protected as well with AD credentials. Also, adding a service tier that fronts the database would provide a facade.
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
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.
Scenario: We have our dedicated servers hosted with a hosting provider. They are running web apps, console apps along with the database which is Sql Server Express edition.
The applications encrypt/decrypt the data to/from the DB. We also store the keys in their server. So theoretically, the hosting provider can access our keys and decrypt our data.
Question: How we can prevent the hosting providers to access our data?
We don't want hosting provider's users to just log into Sql Server and see the data.
We don't want an un-encrypted copy of database files in the box.
To mitigate no. 1: Encrypting app.configs to not store plain text DB username and password.
To mitigate no. 2: Turn on EFS on Sql Server data folder. We could use TDE but the Sql Server is Web Edition version and the hosting company is going to charge us a fortune to use Enterprise Edition.
I'd really appreciate if you guys have any suggestions about above.
You can help mitigate it, but prevention is probably impossible.
It's generally considered that if an attacker has physical access to the machine, they own everything on it.
If this is a concern, you should consider purchasing a server, a virtual server, or using a colocation center and providing your own machine or hosting it yourself entirely.
When you purchase a server, virtual server, or colocate your own hardware, the service provider doesn't have an account on your OS. If you use an encrypted file system, and only access your box via SSH (SSL/TLS), then they will not be able to easily access any data on your computer that isn't being sent out to the network.
The only fool proof way is to have your own hardware in your own secure location and bring the network to your box.
It's possible to do database encryption such that the client does the decryption (though if your indexes are sorted, the server obviously needs to be able to figure out relative order of things in the index). I can't think of a link off the top of my head. However, if the client is the web app, there's not much you can do.
There are also various types of homomorphic encryption, but I'm not sure there's anything that scales polynomially. In any case, the overheads are huge.
I'm curious if there's a reason why you don't trust your hosting provider - or is this just a scenario?
If this is something you have to worry about, sounds like you should be looking at other providers. Protecting yourself from your hosting partner seems counterproductive, IMO.