Go to main content

Oracle® SuperCluster M8 and SuperCluster M7 Security Guide

Exit Print View

Updated: June 2020
 
 

Access Control

For organizations adopting a cloud-hosted environment strategy, access control is one of the most critical challenges to be solved. Tenants must have confidence that information stored on the shared infrastructure is protected and available only to authorized hosts, services, individuals, groups, and roles. Authorized hosts, individuals, and services must further be constrained, in accordance with the principle of least privilege, such that they have only the rights and privileges needed for a particular operation.

SuperCluster facilitates a flexible, layered access control architecture covering every layer of the stack and supporting a variety of roles including end users, database administrators, and system administrators. This enables organizations to define policies that protect hosts, applications, and databases individually and to protect the underlying compute, storage, and network infrastructure on which those services run.

At the virtualization and OS layers, access control begins with reducing the number of services exposed on the network. This helps to control access to Oracle VM Server for SPARC consoles, domains, and zones. By reducing the number of entry points through which systems can be accessed, the number of access control policies can also be reduced and more easily maintained over the life of the system.

Within the Oracle Solaris OS, access controls are implemented using a combination of POSIX permissions along with the Oracle Solaris role-based access control (RBAC) facility. Equally important is the ability to protect the hosts, applications, databases, and related services running on SuperCluster from network-based attacks. To do this, tenants should first verify that only approved network services are running and listening for incoming network connections. Once the network attack surface has been minimized, tenants then configure the remaining services such that they are listening for incoming connections only on approved networks and interfaces. This simple practice will help ensure that management protocols, such as Secure Shell, are not accessible from anywhere other than the management network.

Figure 6  Summary of End-to-End Access Control

image:An illustration showing key security features for the compute notes,                         storage, network, and database components.

In addition, tenants can also choose to implement a host-based firewall such as the IP Filter service of Oracle Solaris. Host-based firewalls are useful because they provide hosts with a more feature-rich way of controlling access to network services. For example, IP Filter supports stateful packet filtering, and it can filter packets by IP address, port, protocol, network interface, and traffic direction. These capabilities are important for platforms such as SuperCluster that operate many network interfaces and support a variety of inbound and outbound network communications.

On SuperCluster, IP Filter can be configured inside an Oracle VM Server for SPARC domain or operated from within an Oracle Solaris Zone. This allows network access control policy to be enforced in the same OS container in which database services are offered. In a multitenant scenario, the amount of outbound network activity will likely be minimal and can easily be categorized so that a policy can be created that limits communications to specific network interfaces and destinations. All other traffic would be denied and logged as part of a “default deny” policy to block unauthorized communications, both inbound and outbound.

Oracle end user security allows tenants to integrate their applications and databases with their existing identity management services in order to support single sign-on (SSO) and centralized user and role management. Specifically, Oracle End User Security helps by centralizing (1) provisioning and deprovisioning of database users and administrators, (2) password management and self-service password reset, and (3) management of authorizations using global database roles. Organizations requiring multi-factor authentication methods, such as Kerberos or PKI, can leverage Oracle Advanced Security.

Oracle Exadata Storage Server technology supports a predefined set of user accounts, each with distinct privileges. Administrators performing Oracle Exadata Storage Server administration must use one of these predefined roles to access the system. ZFS storage appliance, on the other hand, supports the creation of local and remote administrative accounts, both of which are capable of supporting the individual assignment of roles and privileges.

By default, the Oracle Exadata Storage Servers used in SuperCluster are accessed by the database domains using the Oracle Automatic Storage Management facility. This facility allows cloud providers to create distinct disk groups for each tenant that are capable of satisfying their capacity, performance, and availability requirements. In terms of access control, Oracle Automatic Storage Management supports three access control modes: open security, Oracle Automatic Storage Management–scoped security, and database-scoped security.

In a multitenant scenario, database-scoped security is recommended, because it offers the most fine-grained level of access control. In this mode, it is possible to configure disk groups such that they can be accessed by only a single database. Specifically, this means that both database administrators and users can be limited to accessing only those grid disks that contain information for which they have access privileges. In database consolidation scenarios in which individual databases might be supporting different organizations or tenants, it is important that each tenant be able to access and manipulate only their own storage. In particular, when combined with the workload and database isolation strategies discussed earlier, it is possible for tenants to effectively compartmentalize access to individual databases.

Database-scoped security is an effective tool for limiting access to Oracle ASM grid disks. This figure shows Oracle ASM–scoped security along with ZFS security. In situations where there are large numbers of Oracle Database instances being deployed on the SuperCluster platform, a per-tenant Oracle ASM–scoped security strategy might make more sense, because it significantly reduces the number of keys that have to be created, assigned, and managed. Further, because database-scoped security requires separate disk groups to be created for each database, this approach will also significantly reduce the number of separate grid disks that have to be created on an Exadata Storage Server.

Figure 7  Per-Tenant Oracle ASM-Scoped Security

image:A figure showing per-tenant Oracle ASM-scoped security.

SuperCluster leverages Oracle Solaris data link protection, which seeks to prevent the potential damage that can be caused by malicious tenant virtual machines to the network. This integrated Oracle Solaris feature offers protection against the following basic threats: IP and MAC address spoofing as well as L2 frame spoofing (for example, Bridge Protocol Data Unit attacks). Oracle Solaris data link protection must be applied individually to all Oracle Solaris non-global zones deployed within the multitenant environment.

Because individual tenants should never require administrative or host-level access to the Exadata Storage Servers, it is strongly recommended that such access be restricted. The Exadata Storage Servers should be configured to prevent direct access for tenant non-global zones and database I/O domains while still permitting access from SuperCluster database domains (which are operated by the cloud provider). This ensures that the Exadata Storage Servers can be managed only from trusted locations on the management network.

Once the security configuration of the tenants has been defined and implemented, service providers can consider the additional step of configuring tenant-specific global and non-global zones to be immutable as read-only environments. Immutable zones create a resilient, high-integrity operating environment within which tenants may operate their own services. Building upon the inherent security capabilities of Oracle Solaris, immutable zones ensure that some (or all) OS directories and files are unable to be changed without intervention by the cloud service provider. The enforcement of this read-only posture helps to prevent unauthorized changes, promote stronger change management procedures, and deter the injection of both kernel and user-based malware.