The downside of it is that people who do not oversee security implications are able to deploy new environments without being forced to thoroughly implement security. The recent MongoDB debacle in which random MongoDB databases have been compromised and lost or ransom demands have been made by the criminals who downloaded the data and removed it from the server after that.
In this case MongoDB is in effect not to blame, most of the MonogDB servers that have been compromised are in effect not hacked. The servers have been exposed to the public internet and have not been secured by a password or with a default / very weak password. This in effect left the door open to attackers to gain access and download the data.
This means that not a software bug has caused the avalanche of hacked MongoDB servers, the way people implement solutions in the cloud and do not think about security caused this issue. By enabling people to deploy systems with a click of a button is on one side a blessing, on the other side it is causing a major risk as people can easily forget to implement the needed levels of security.
Consider the traditional security rules
When deploying systems and entire IT footprints on the cloud, in this example the Oracle Public Cloud, you still need to apply a number of the traditional IT security rules in place. The main reason why you need to apply them is simple, they make sense and they have been created for a reason. The technical implementation of them might differ however the theoretical model applies both for cloud based solutions and traditional based solutions.
Network zones
In traditional IT environments the concept of multiple zones or tiers has been well established. The below model used in many cases when deploying Oracle centric IT footprints consists out of four network zones or tiers.
Un-trusted tier / zone : un-trusted zone can hold systems that connect to “unknown: parties in an uncontrolled area. As an example, the un-trusted zone can hold systems that are connected to the public internet. The un-trusted zone cannot hold data and can only hold stateless systems. Systems in the un-trusted zone can connected (in a controlled manner) to the systems in the semi-trusted zone directly.
Semi-trusted tier / zone: the semi-trusted zone can hold systems that can connect to “unknown” parties in a controlled area. As an example, the semi-trusted zone can hold systems that connect to a customer network or a third party network. The semi-trusted zone cannot hold0data and can only hold stateless systems. Systems in the semi-trusted zone can connect (in a controlled manner) to systems in the trusted zone directly.
Trusted tier / zone : The trusted zone can hold systems that connect to the semi-trusted zone and is in general for hosting databases and data-storage applications. As an example, the trusted zone can hold a database which provide support to applications in the semi trusted zone. Systems in the trusted zone can connect (n a controlled manner) to systems in the fully trusted zone directly.
Fully trusted tier / zone: The fully trusted zone holds generic systems that are sued for management, support and control. As an example; Oracle Enterprise Manager will be hosted in the trusted zone.
Using this model, or a model like this, provides a clear segregation from a network point of view. By implementing such model you will prevent that a malicious attacker can easily gain access to systems with a higher level of confidentiality or impact. Implementing this solution in the Oracle Public Cloud requires understanding how to manage the Oracle Public Cloud firewall configurations and implement them in a manner that you can achieve the same as you would like to achieve in a standard IT footprint.
Network segments
Where network zones can be seen as the vertical split of where you deploy servers in a network the network segments can be seen as the horizontal split. Commonly network segments are used to segregate production, acceptance, test and development systems in segregated stacks of network tiers /zones.
This could mean that you will have a production segment which has an Un-trusted tier, Semi-trusted, Trusted tier and a fully trusted tier. And you would have the same tiers in the acceptance segment, the test segment and the development segment.
One of the main traditional reasons network segments are for splitting this is that in a development environment people will have (and need) a lot more freedom on system in comparison to the production segment. The production segment will be tightly controlled and monitored while the development environment people are allowed (and expected) to experiment and find new ways of doing things.
Local firewall rules
A highly debated subject is the local firewall and the need to have them implemented on top of network segmentation and tiering.
In cases where local firewall rules are NOT implemented you will be able to create connections on all ports towards all servers in the specific network tier and network segment the server resides. This makes that if someone gains access to a server it is relatively easier to also acquire access to servers in this same segment and tier as no firewall is preventing you from creating a connection to the other servers.
In cases where local firewall rules are implemented the effect of a compromised server in your network is somewhat more contained. All other servers in the same network segment / tier will only allow incoming connections from the compromised server on ports they explicitly allow.
As stated this is a highly debated subject as a large number of administrators see it as a burden to ensure the local firewall rules are implemented and maintained. However, this is to a certain extend being removed by having a good and central mechanism to control local settings. Solutions like Puppet, in combination with other tools, can play a great role managing local firewall rules on distributed servers.
When deploying Oracle Linux servers on the Oracle Public Cloud you will be able to use (depending on your version) iptables or firewalld as a local firewall. Both are core Linux local firewalls and are implemented and used throughout the industry and are seen as a great implementation for local firewalls.
Painting the picture
The above examples are pointing all to network related security, however, they are just an example to illustrate that “old fashion” security rules and best practices should not be forgotten when moving to the cloud. Some people try to diminish the need for security and claim it will hold back speed and agility of operations in a cloud environment.
The claim that good and proper security is holding back the speed and agility in cloud is an incorrect claim. Ensuring that your cloud deployment processes are able to include the proper level of security will not take any speed away from using a cloud based platform.
When looking at the Oracle Cloud, one can use
- API’s to control and implement network firewall rules and by doing so ensure that deployed servers are always, automatically, placed in the correct location from a network segment and zone/tier point of view
- Puppet / chef based solutions will enable you to control local firewalls in your landscape and ensure changes are distributed easily
- Security hardened templates will enable you to deploy secured and hardened operating systems without the need to manually harden them
Common sense and architecture
However, the most important thing is to ensure you apply common sense and ensure you do your architecture correctly, which should always include a healthy portion of security considerations as part of its foundation.
The majority of the hacked MongoDB servers could have been secured with just a little more thought and common sense. Ensuring you do not forget the rules created in the pre-cloud era and thinking how you can apply them in the cloud before hitting the default “deploy button” can mean the difference between losing your data and being able to sleep well at night without having to worry.
