UIM Security Overview

1 UIM Security Overview

This chapter provides an overview of Oracle Communications Unified Inventory Management (UIM) security.

Basic Security Considerations

The following principles are fundamental to using any application securely:

Keep software up to date. This includes the latest product release and any patches that apply to it.
Limit privileges as much as possible. Users should be given only the access necessary to perform their work. User privileges should be reviewed periodically to determine relevance to current work requirements.
Monitor system activity. Establish who should access which system components, how often they should be accessed, and who should monitor those components.
Install software securely. For example, use firewalls, secure protocols (such as SSL), and secure passwords. See "Performing a Secure UIM Installation" for more information.
Learn about and use UIM security features. See "Implementing UIM Security" for more information.
Use secure development practices. For example, take advantage of existing database security functionality instead of creating your own application security. See "Security Considerations for Developers" for more information.
Keep up to date on security information. Oracle regularly issues security-related patch updates and security alerts. You must install all security patches as soon as possible. See “Critical Patch Updates and Security Alerts" on the Oracle website:

https://www.oracle.com/security-alerts/

Understanding the UIM Environment

When planning your UIM implementation, consider the following:

Which resources must be protected?

For example:
- You must protect customer data.
- You must protect internal data, such as proprietary source code.
- You must protect system components from being disabled by external attacks or intentional system overloads.
Who are you protecting data from?

For example, if your business has service subscribers, you must protect their data from other subscribers, but someone in your organization might have to access that data to manage it. You can analyze your workflows to determine who needs access to the data; for example, a system administrator could manage your system components without needing to access the system data.
What happens if protections on strategic resources fail?

In some cases, a fault in your security scheme is nothing more than an inconvenience. In other cases, a fault might cause great damage to you or your customers. Understanding the security ramifications of each resource helps you protect it properly.

Overview of UIM Security

Figure 1-1 shows all the various components that can comprise UIM, including the components to which it connects. Each installed or integrated component requires special steps and configurations to ensure system security.

Figure 1-1 UIM Components

Description of "Figure 1-1 UIM Components"

Recommended Deployment Scenarios

Note:

For UIM cloud native deployments, see UIM Cloud Native Deployment Guide.

Figure 1-2 shows a single server deployment scenario: the simplest UIM deployment architecture.

Figure 1-2 Single Sever Deployment

Description of "Figure 1-2 Single Sever Deployment"

Figure 1-3 shows a clustered server deployment: a scalable UIM deployment offering greater security and high availability.

Figure 1-3 Clustered Server Deployment

Description of "Figure 1-3 Clustered Server Deployment"

Operating System Security

This section lists UIM-specific operating system security configurations. This section applies to all supported operating systems.

Firewall Port Configuration

Note:

For UIM cloud native deployments, see UIM Cloud Native Deployment Guide.

UIM communicates through the firewall with various components on specific ports. Ensure that the operating system IPtables for the firewalls are configured to manage traffic on the following ports:

Port 22 (optional, both directions): Used by the File Transfer and Parsing cartridge for SSH communication. Close this port if you are not using the File Transfer and Parsing cartridge.
WebLogic Server SSL listen ports (both directions): Used by Administration and Managed servers for listening for traffic.
Oracle Database listener ports: Used to listen for Oracle Database traffic.

Close all unused ports, especially non-SSL ports. Opt for SSL-enabled ports, instead of non-SSL ports, for all communications (for example: HTTPS, IIOPS, t3s).

For more information about securing your operating system, see your operating system documentation.

Oracle Database Security

This section lists the UIM-specific security configurations for the Oracle Database:

For more information about securing Oracle Database, see Oracle Database Security Guide and Oracle Database Advanced Security Administrator's Guide.

Data Encryption

If your database connection is not configured to use data encryption, data is sent across the network in a format that is designed for fast transmission and can be decoded by interceptors given some time and effort.

It is also possible (but not recommended) to encrypt the UIM tablespace and schema, at the expense of system performance. Encrypting the schema and tablespace is not necessary, because the database is sufficiently secure without the encryption.

See Oracle Database Advanced Security Administrator's Guide for more information.

Secure Database Connections

Encrypting network data is a critical security measure that ensures that data traveling over the network is difficult to intercept and access. Secure network connections to the Oracle Database using the Oracle Advanced Security feature. You can configure the Oracle Database with either Network Data Encryption or SSL authentication, as both ensure that the data is secure while traveling over the network.

The Oracle Advanced Security feature also provides security against the following types of attacks:

Data modification attack, where an unauthorized party intercepts data in transit over the network, alters it, and transmits the altered data to the database.
Replay attack, where an unauthorized party repeatedly transmits entire sets of valid data.

SSL Authentication

Use the Oracle Advanced Security feature to enable SSL authentication, using a digital certificate, on data that travels over the network to the database. See Oracle Database Advanced Security Administrator's Guide for more information.

Using SSL authentication allows UIM to communicate with servers over an encrypted connection and to communicate with the database over an encrypted connection.

SSL authentication supports the following authentication modes:

Only the server authenticates itself to the client.
Both client and server authenticate themselves to each other.
Neither the client nor the server authenticate with each other (SSL encryption feature by itself).

WebLogic Server Security

For information about securing WebLogic Server, see Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server.

Authorization

Authorization is the process where the interactions between users and WebLogic Server resources are controlled, based on user identity or other information. In WebLogic Server, an Authorization provider is used to limit the interactions between users and WebLogic resources to ensure integrity, confidentiality, and availability.

For more information about changing WebLogic Server passwords, see the WebLogic Server Administration Console Help.

WebLogic Resources

A WebLogic Server resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies.

WebLogic resources are hierarchical. Therefore, the level at which you define these security roles and security policies is up to you. For example, you can define security roles and security policies on entire enterprise applications; an Enterprise Java Bean JAR containing multiple EJBs; a particular Enterprise Java Bean (EJB) within that JAR; or a single method within that EJB.

Security Policies

Security policies replace access control lists and answer the question “Who has access to a WebLogic server resource?" A security policy is created when you define an association between a WebLogic resource and one or more users, groups, or security roles. You can optionally define date and time constraints for a security policy. A WebLogic resource has no protection until you assign it a security policy.

Security policies are stored in an authorization provider's database. By default, the XACML Authorization provider is configured in a domain, and security policies are stored in the embedded LDAP server.

To use a user or group to create a security policy, the user or group must be defined in the security provider database for the authentication provider that is configured in the default security realm. To use a security role to create a security policy, the security role must be defined in the security provider database for the Role Mapping provider that is configured in the default security realm. By default, the authentication and XACML Role Mapping providers are configured in the database in the embedded LDAP server. Also by default, security policies are defined in WebLogic Server resources. These security policies are based on security roles and default global groups. You also have the option of basing a security policy on a user.

Secure Sockets Layer (SSL)

SSL enables secure communication between applications connected through the Web. WebLogic Server fully supports SSL communication. By default, WebLogic Server is configured for one-way SSL authentication. Using the WebLogic Server Administration Console, you can configure WebLogic Server for two-way SSL authentication.

To use one-way SSL from a client to a server, enable the SSL port on the server, configure identity for the server and trust for the client.
To use two-way SSL between a client and a server, enable two-way SSL on the server, configure trust for the server, and identity for the server.

In either case, the trusted CA certificates must include the trusted CA certificate that issued the peer's identity certificate. This certificate does not necessarily have to be the root CA certificate.

To acquire a digital certificate for your server, generate a public key, private key, and a Certificate Signature Request (CSR), which contains your public key. Send the CSR request to a certificate authority and follow their procedures for obtaining a signed digital certificate.

After you have your private keys, digital certificates, and any additional trusted CA certificates that you may need, you must store them so that WebLogic Server can use them to verify identity. Store private keys and certificates in keystores.

Logging Security

Oracle recommends a Logging level of ERROR for Logging Services. An explicit administrative action is required to change the log level. See UIM Developer's Guide for more information. When the log levels are set to DEBUG or lower, the log levels can contain raw exceptions and stack traces that could be exploited to compromise the security of your UIM system.

Oracle Security Documentation

UIM uses other Oracle products, such as Oracle Database and Oracle WebLogic Server. See the following documents, as they apply to UIM:

Oracle Database Security Guide
Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server
Oracle Application Server Security Guide
Oracle Application Server Administrator's Guide

File Permissions

Generally, the permissions on a file should be restrictive. However, you should allow users to perform normal application operations on the file.

Table 1-1 File Permissions

Type of File	Linux Permission	Notes
Directories that should be available to all users	755	All Oracle Home Directories unless otherwise indicated.
Directories that should not be available to all users (for example, configuration, domains, servers, and so on)	750, 770	Linux permission values: 750: ASInstance 770: Jdk, Inventory and Cfgtoollogs Domain and System instance directories and Restricted directories.
General Binaries should be available to all users, including executable shell scripts (installation)	755	All Oracle Home binaries unless otherwise indicated.
General Binaries (configuration) and Instantiated Binaries (Instantiated with sensitive install specific information such as the OS dba group name)	700	Most of the binaries in Application Server suites are currently in this category. Instantiated binaries may contain sensitive installation-specific information. Therefore, they should be read-protected to the maximum extent.
Binaries and directories imported from a database component	Inherit database install component file permissions	For example, sqlplus (755).
Setuid Binaries	4711, 4710, 4701	This type of binary should include restricted permissions and it should be located in a directory with restrictive permissions.
Setguid Binaries	2711	This type of binary should include restricted permissions and it should be located in a directory with restrictive permissions.
Setguid and setgid Binaries	6711	You should configure this type of binary when it is absolutely necessary to set both user and group identities. Also, this type of binary should be located in a directory with restrictive permissions.
Libraries (for example, .jar, .a, .so, .war, *.ear)	640 or 750	Linux permission values: 640: Most libraries belong to this category. 750: For a few specific platforms, such as HP-UX and *.so must include execute permission as required by the O/. Therefore, set this file permission specific for the platform. Note: 640 is the recommended goal. However, until the recommended goal is achieved, 750 is acceptable for all Linux platforms.
Libraries (for example, .a, .so) (installation)	644 or 755	NA
Alert, log and trace files (for example, .out, .log, .out.)	640	Only the install owner can read/write and the group can only read these files due to the nature of sensitive information of these files.
Configuration and metadata files (.xml, .properties, .sql, .pls)	640	Only the install owner should be allowed to read/write the super-sensitive information such as user passwords and the group can only read these files to copy files from ASHome to ASInstance.
Script files (.pl, .py, *.sh, e.g. root.sh)	700 or 750	The available scripts are: 700: Deployment script and security configuration script and files. It includes Root.sh. 750: Scripts that need to be available to OS group members.
Wallet files (*.sso, for example, cwallet.sso), and Keystore files, or other super sensitive non-executable files	600	Only the install owner can read/write these files due to the nature of super-sensitive information of these files.
All other files (install)	600, 640, 644	644: May allow more restricted files in some cases.
All other files (configuration)	600, 640	640, 600: For sensitive files.