Cloud Security Perspectives and Insights
-
Cloud Access Security
September 12, 2019
Enhancing EBS Security in Oracle Cloud - Part 2
Welcome to the second article in my series on “Enhancing EBS Security on OCI”. In the first article, I looked at the threats and risks associated with moving an application like EBS to the Cloud, and also discussed the first of eight attack vectors, Infrastructure Attack.
In this article, I am going to talk about two more attack vectors: user authentication and authorisation.
When discussing Cloud security, I always find the topic of user authentication and authorisation interesting because, irrespective of whether you are looking at SaaS, PaaS, or IaaS, user security is always a customer responsibility, not a Cloud provider one. As with infrastructure security though, as discussed in the previous article, where the Cloud provider can help is by providing a strong and easy to use set of tools to help you manage your users and their access.
So, let’s look at the problem in respect to EBS. Firstly, we need to understand the different users we are talking about. There are two primary types of users we need to consider:
- EBS Application Users – these are the users of your application (EBS) and include your end users as well as your power users and even system administrative users.
- Cloud Infrastructure Users – these are the users of the Cloud platform and will usually be administrative users only, i.e. the ones who are managing the compute, storage, and networking of the platform underpinning EBS. End users will not typically access the infrastructure.
Starting with EBS Application Users, we need to consider how an organization will secure this type of user’s access to EBS. By default, within EBS, authentication for application users is controlled by username and password, stored and managed within EBS itself. It may be that you are limiting access to EBS for your application users through a private connection such as a VPN or FastConnect. However, some organizations want to take advantage of the move to Cloud to provide additional access to EBS for their users and therefore want to open up controlled access over the internet. In these situations, you need to consider how you can strengthen the authentication process.
It is possible to integrate EBS with an external access management solution. Supported solutions are either Oracle Access Management (OAM), or Oracle Identity Cloud Service (IDCS), both of which in turn would integrate with any 3rd party solution you may already have. In this article, I talk about the two different approaches. It is common to see the integration of EBS with an access management solution as only being to enable single sign-on (SSO). However, integration can also provide additional security benefits that will enhance the security of EBS. For example, both OAM and IDCS support risk-based, as well as multi-factor authentication (MFA).
Here we can see the MFA options provided out-of-the-box by IDCS.
The adaptive security engine then allows risk events to be combined with other contextual factors to determine access.
As a result, this is one of the key areas where security can be improved. Furthermore, in the above linked article I also talk about how the use of IDCS can greatly simplify the EBS solution footprint versus an OAM-based integration, which lots of organizations using EBS have deployed today. This simplification supports a move and improve strategy by removing unnecessary complexity from your EBS deployment, whilst taking advantage of the Identity-As-A-Service platform that IDCS offers. Allowing you to keep up to date with the latest in access management features, without the constant need to patch and upgrade your access management platform.
For example, IDCS supports a range of different factors for MFA, each of which can be enabled through simple configuration. As new factors are introduced, organizations will be able to immediately take advantage of them within IDCS without any need to upgrade or patch IDCS (since it is delivered as a service). In addition, the risk-based authentication available through IDCS’s adaptive authentication mean that you can use IDCS’s own risk factors as well as integrate with other external risk engines )such as Cloud Access Security Brokers) to obtain a more informed risk score for a user before deciding on whether to allow access or not.
Authorization of the EBS Application Users within EBS remains with the application, using EBS’s roles and responsibilities. However, authorisation at a coarse level, can be outsourced to IDCS. Determining whether a user is authorised to access the PRODUCTION instance of EBS versus the DEVELOPMENT instance can be controlled by IDCS, applying factors such as the user’s location, and/or risk level.
The second type of users are the Cloud Infrastructure Users. The security of these users is also of paramount importance since these are the users who will be managing the infrastructure (e.g. compute, networking and storage) as well as any platform services underpinning your EBS deployment. As with EBS Application Users, the access for the Cloud Infrastructure Users can also be secured by IDCS, meaning a single place to configure and manage both kinds of users. It also means that the same levels of flexibility and control over how these users are challenged to authenticate can be applied. Similarly, determining what capabilities these types of users have within OCI is controlled through a tight integration between OCI and IDCS.
Let’s look at a simple example of how you might apply access policies using a scenario shown in the following diagram.
Your access policies within IDCS could specify:
|
User Type |
EBS Env |
Location |
Access |
Factors |
|
EBS App Users |
TRG / PROD |
Internet |
Allowed |
Strong password |
|
EBS App Users (Power Users) |
PROD |
Internet |
Allowed |
MFA + Risk-based |
|
Cloud Infra Users |
Manage TRG resources |
Internet |
Allowed |
MFA |
|
Cloud Infra Users |
Manage PROD resources |
Corporate Network |
Allowed |
MFA + Risk-based |
|
Cloud Infra Users |
Manage PROD resources |
Internet |
Denied |
N/A |
To summarize, authentication and authorization of users for both your EBS application and the underpinning Cloud infrastructure is critical to minimise attacks against your user population. Fortunately, a common approach using IDCS can be used for both types of users, providing you a feature-rich, easy to use Identity-As-A-Service platform that can apply contextual access decisions to your users, thus minimising the risk of unauthorised access to EBS and the sensitive data contained within it.
In the next article, I will look at how you protect the EBS application itself from attack.