Part 2 of 4 - Oracle IaaS and Seven Pillars of Trusted Enterprise Cloud Platform

 Sanjay Basu

Note: My original blog series was published in ORACLE CLOUD INFRASTRUCTURE blog site. I have republished it here with permission.

Official Disclaimer: The views and opinions expressed in this blog are those of the author and do not necessarily reflect the official policy or position of Oracle Corporation.

This is the second part of our blog series where we do a deep dive into the Oracle Cloud Infrastructure security approach. As a recap, we design our security architecture and build security solutions based on seven core pillars. And under each of these pillars, we focus on delivering solutions and capabilities to help ensure our customers can improve the security posture of their overall cloud infrastructure. In the first post, we discussed how we enable customers to achieve isolation and encrypt their data. In this post, we dig into our 3rd and 4th pillars, and discuss how you can obtain the security controls and visibility needed for your cloud environment.

3. Security Controls

Security controls offer customers effective and easy-to-use security management. The solutions that we offer allow you to control access to your services and segregate operational responsibilities to reduce the risk associated with potentially malicious and accidental user actions.

User authentication and authorization-based security controls:

Each user has one or more of the following credentials to authenticate themselves to Oracle Cloud Infrastructure. Users can generate and rotate their own credentials. In addition, a tenancy security administrator can reset credentials for any user within their tenancy.

  • Console password: Used to authenticate a user to the Oracle Cloud Infrastructure Console.
  • API key: All API calls are signed using a user-specific 2048-bit RSA private key. The user creates a public key pair and uploads the public key in the Console. A user can access an instance via SSH. This requires that the user has an SSH key pair. 
  • Swift password: Used by Recovery Manager (RMAN) to access the Object Storage service for database backups. To ensure sufficient complexity, the IAM services create the password and the customer cannot provide it.
  • Customer secret key: Used by Amazon S3 clients to access the Object Storage service’s S3-compatible API. To ensure sufficient complexity, the IAM services create the password and the customer cannot provide it.

Instances:

Instances are a new principal type in IAM. Customers no longer need to configure user credentials on the services running on their compute instances or rotate those credentials. Each compute instance has its own identity, and it authenticates using the certificates that get added to the instances by instance principals. Because these certificates are automatically created, assigned to instances, and rotated, customers do not need to distribute credentials to their hosts nor rotate them. You can group instances in logical groups called dynamic groups and you can define IAM policies for these groups. ynamic groups allow you to group Oracle Cloud Infrastructure instances as principal actors, similar to user groups. You can then create policies to permit instances in these groups to make API calls against Oracle Cloud Infrastructure services. Membership in the group is determined by a set of matching rules.

Federated Users:

Federated users who attempt to authenticate to the Oracle Cloud Infrastructure graphical administration console are redirected to the configured identity provider, after which they can manage Oracle Cloud Infrastructure resources in the console just like a native IAM user. Currently Oracle Cloud Infrastructure supports the Oracle Identity Cloud Service and Microsoft Active Directory Federation Service (ADFS) as identity providers. Federated groups can be mapped to native IAM groups to define what policy applies to a federated user.

Security Lists:

Oracle IaaS also provides a native firewall-as-a-service in the form of security lists that are applied at the subnet level. The security list rules for the database subnet restrict it to connecting from and to the web server’s subnet. The security list for the web server subnet allows all outgoing connections while restricting incoming connections.

A security list provides a virtual firewall for an instance, with ingress and egress rules that specify the types of traffic allowed in and out. Each security list is enforced at the instance level. However, you configure your security lists at the subnet level, which means that all instances in a given subnet are subject to the same set of rules. The security lists apply to a given instance whether it's talking to another instance in the VCN or a host outside the VCN.

When you create a security list rule, you choose whether it's stateful or stateless. 

Stateful: If you add a stateful rule to a security list, that indicates that you want to use connection tracking for any traffic that matches that rule (for instances in the subnet the security list is associated with). This means that when an instance receives traffic matching the stateful ingress rule, the response is tracked and automatically allowed back to the originating host, regardless of any egress rules applicable to the instance. When an instance sends traffic that matches a stateful egress rule, the incoming response is automatically allowed, regardless of any ingress rules.

Stateless: If you add a stateless rule to a security list, that indicates that you do not want to use connection tracking for any traffic that matches that rule (for instances in the subnet that the security list is associated with). This means that response traffic is not automatically allowed. To allow the response traffic for a stateless ingress rule, you must create a corresponding stateless egress rule.

Containers:

For containers, the Kubernetes RBAC Authorizer can enforce more fine-grained access control for users on specific clusters via Kubernetes RBAC roles and clusterroles. A Kubernetes RBAC role is a collection of permissions. For example, a role might include read permission on pods and list permission for pods. A Kubernetes RBAC clusterrole is just like a role, but can be used anywhere in the cluster. A Kubernetes RBAC rolebinding maps a role to a user or set of users, granting that role's permissions to those users for resources in that namespace. Similarly, a Kubernetes RBAC clusterrole binding maps a clusterrole to a user or set of users, granting that clusterrole's permissions to those users across the entire cluster.

IAM and the Kubernetes RBAC Authorizer work together to enable users who have been successfully authorized by at least one of them to complete the requested Kubernetes operation. When a user attempts to perform any operation on a cluster (except for create role and create clusterrole operations), IAM first determines whether the group that the user belongs to has the appropriate permissions. If so, the operation succeeds. If the attempted operation also requires additional permissions granted through a Kubernetes RBAC role or clusterrole, the Kubernetes RBAC Authorizer then determines whether the user has been granted the appropriate Kubernetes role or clusterrole. By default, users are not assigned any Kubernetes RBAC roles (or clusterroles). So before attempting to create a new role (or clusterrole), users must be assigned an appropriately privileged role (or clusterrole).

You can connect to worker nodes using SSH. If you provided a public SSH key when creating the node pool in a cluster, the public key is installed on all worker nodes in the cluster. On UNIX and UNIX-like platforms (including Solaris and Linux), you can then connect through SSH to the worker nodes using the SSH utility (an SSH client) to perform administrative tasks. Before you can connect to a worker node using SSH, you must define a security ingress rule in the security list for the worker node subnet to allow SSH access.

4. Visibility

In order to give you the visibility you need over your cloud infrastructure, Oracle offers comprehensive log data and security analytics that you can use to audit and monitor actions on your resources. This allows you to meet your audit requirements and reduce security and operational risk.

The Oracle Cloud Infrastructure Audit service records all API calls to resources in a customer’s tenancy as well as login activity from the graphical management console. Using the Audit service, customers can achieve their own security and compliance goals by monitoring all user activity within their tenancy. Because all Console, SDK, and command line (CLI) calls go through our APIs, all activities from those sources are included. 

Audit records are available through an authenticated, filterable query API or can be retrieved as batched files from Oracle Cloud Infrastructure Object Storage. You can also search for API calls via the Console. Audit log contents include what activity occurred, the user that initiated it, the date and time of the request, as well as source IP, user agent, and HTTP headers of the request. New activities are usually appended to the audit logs within 15 minutes of occurrence.

By default, audit logs are retained for 90 days, but you can configure it to retain logs for up to 365 days.

In addition to the audit services, Oracle CASB-based security monitoring performs Oracle Cloud Infrastructure resource activity configuration checks, IAM user behavior analysis, and IP reputation analysis.

Examples of CASB Oracle Cloud Infrastructure security checks:

  • Publicly accessible object store buckets
  • Open VCN Security Lists
    • 0.0.0.0/0
  • VCN accessible to the internet
  • IAM user password not rotated for more than 90 days
  • IAM user API keys not rotated for more than 90 days
  • IAM user password complexity checks
  • MFA not enabled on admin account

In my next blog post, I will cover the next 2 pillars - secure hybrid cloud and high availability. In the meantime, use these resources to learn more about Oracle Cloud Infrastructure security:

• Oracle Cloud Infrastructure Security White Paper 

• Oracle Cloud Infrastructure GDPR White Paper

• Oracle Cloud Infrastructure Security Best Practices Guide

• Services Security Documentation

 

Blogs:


Comments

Post a Comment

Popular posts from this blog

OCI Object Storage: Copy Objects Across Tenancies Within a Region

Image
Note : My original blog was published in ORACLE CLOUD INFRASTRUCTURE blog site on April 15th, 2019. I have republished it here with permission. Official Disclaimer : The views and opinions expressed in this blog are those of the author and do not necessarily reflect the official policy or position of Oracle Corporation. This post was developed jointly with Mohamad Charaf, Oracle Enterprise Cloud Architect. If you have two tenancies in the same region, and you want to copy data that is stored in Object Storage from one tenancy to the other without making the buckets public, this action requires some additional types of identity and access management (IAM) policies. This blog post walks you through how to create these policies. For this example, the source tenancy is named ACMEBMCS and the destination tenancy is named ACMEOCISA. In ACMEBMCS, the Object Storage buckets are in the benchmark compartment. In ACMEOCISA, the target compartment is oracleexa . The follow
Read more

The Legal Rights of an Algorithm

Image
  At first glance, you might think how it’s possible for something that doesn’t have a mind, body, or soul to have any legal entitlement. After all, algorithms don’t have physical attributes, and their existence can’t be easily tracked unless you’re a tech specialist responsible for creating them.  However, while algorithms don’t have any physical attributes, they have become smarter over time, mimicking human behaviors and traits to produce actionable results. Initially, algorithms started as simple data sets combined in several valuable ways to create patterns. They generate suggestions and solutions that help guide you, whether you’re on social media or search engines, while also providing insights within several fields, including the legal, medical, and marketing fields. Algorithms also consistently correct their mistakes without requiring human intervention.  Believe it or not, algorithms have legal rights too. While many users are skeptical about algorithms because of security an
Read more

Religious Perspectives on Artificial Intelligence: My views

Image
  I am an Atheist. Born in a Hindu family, I have experimented with Christianity and Buddhism. Jokingly, I describe my journey from Many Gods to One and then None. I followed Hinayana Buddhism for a long time. Lately, I have been studying Lokayata/Carvaka school of the Hindu Darsana (philosophy). I like to be identified as a Hindu Atheist. Why Hindu? Because my birthplace is on the east side of the River Indus.
Read more