Welcome to the final article in my series, where we have been discussing “Enhancing EBS Security on OCI”. Congratulations on making it through the first five parts. If you've missed any of the previous parts, the link above takes you to part 1, which contains links to all of the other articles.
We have covered a lot of ground in this series, looking at a range of threats that need addressing for your EBS (or any enterprise) application being moved to the Cloud. We also discussed how different Oracle technologies can help you to address these threats. Of course, i’m not suggesting that we have covered every single threat and use case. What I have aimed to do is pick out some of the main ones that I see organisations struggling with on a regular basis.
In this article, we will be looking at the final threat on my list, Database Bypass.
To clarify the use case, when I refer to Database bypass I am considering an attacker that is looking at obtaining sensitive information, not through the application tier, or even the database tier. No, in this use case, the attacker is going directly for the files that hold the sensitive information. These could be the actual files that the Database uses to store its information, or they could be other sensitive, non-structured files. For example:
All of these type of files may be stored within Oracle cloud storage services such as object storage.
In some ways, we have already covered some of the security controls that will help to mitigate this threat. In part, we talked briefly in earlier parts about Infrastructure Security and how OCI has been architected from the ground up with security at its core. Built-in controls can be utilised to minimise the risk of a user (legitimate or otherwise) getting unauthorised access to resources that they shouldn’t have. For example :
All of the above controls are available to all OCI customers at no additional cost within your tenancies. But, for some customers, more stringent security requirements mean that they need to complement the above controls with additional levels of protection. Of course, there are multiple ways that this can be done, and multiple solutions available for doing this. However, as you would expect, I will focus on the Oracle technologies that can help.
The first area is key management. We have already discussed in this series about how your data is encrypted at-rest and in-transit within OCI. If you think of where this data resides, it tends to fall into two categories; data held within the database and data held within storage. Two different mechanisms protects these two sources.
Database Key Management
As I pointed out in the previous article, when talking about database encryption, Transparent Data Encryption (TDE) is enabled by default for all Oracle Database-as-a-Service offerings within Oracle Cloud. The keys are created and stored in the Oracle Wallet. Those of you who have used Oracle Database or any Oracle Middleware will, no doubt, be familiar with the Oracle Wallet, which is essentially a file, stored by on the filesystem, and holds the Master Encryption Key for the Database. There are various options available to ‘lockdown’ this wallet, such as password protecting it, or configuring it to open only on the machine it is created on.
For some customers, the thought of having the keys to the database on the same server as the database is a concern. Fortunately, Oracle has a good solution for addressing this. Oracle Key Vault (OKV) is a software appliance that can be deployed by a customer, either in the Oracle Cloud, in a 3rd party cloud, or even on-premises.
The wallet can uploaded to OKV and the database configured to use OKV in real-time, whenever a key operation is needed, thus removing the wallet from the database’s filesystem. OKV’s highly available, multi-master architecture mean that your database will never lose connection to your key servers. More information on OKV can be found here.
Storage Key Management
When we talk about storage, we are thinking about all of the different types of storage used within Oracle Cloud, including Object Storage, Block Storage (including Boot Volumes), and File System Storage. Again, as discussed previously, all data stored in any of these storage cloud services is encrypted, with the keys being managed by Oracle.
For some customers, they have a requirement to manage their own keys. To meet these requirements, OCI includes the Key Management Service (KMS).
This service allows customers to create their own virtual wallets and keys on FIPS 140-2 Level 3 compliant Hardware Security Modules (HSMs). Customers can then assign the keys to the different storage services, at a granular level. Standard key operations such as key rotation, creation, disabling, and deleting are all available, with the security for access to KMS functions being controlled by OCI’s IAM policies. Further information on KMS can be found here.
In summary, across this entire series, I have covered a range of threats and some of the different ways that these may be mitigated. Anyone who has worked in security for a while will know that there is no, single, silver bullet that will give you 100% protection against all threats. Instead, it is all about risk, identifying the threats that your organisation faces, determining the likelihood of that threat being realised, as well as the impact of that threat being executed, then putting appropriate controls in place to mitigate that risk if required. Of course, recognising that all controls must be proportional to the threats you are addressing.
I hope this series has given you an insight into the different types of threats that I talk to customers about regularly and how Oracle is helping customers to address these threats.