Oracle® Auto Service Request for Sun ZFS Storage Appliances

Security White Paper

E37468-02

April 2014

This document explains the technical aspects of the Oracle Auto Service Request (ASR)

service that automates the Oracle Support process by using fault event telemetry from

your qualiﬁed ZFS Storage Appliance to initiate a Service Request.

The following topics are described:

• Introduction to Oracle Auto Service Request (ASR)

• Conﬁguration

• ZFS Storage Appliance Telemetry

• Telemetry Data

• Auto Service Request Infrastructure at Oracle

• Authentication Infrastructure

Introduction to Oracle Auto Service Request (ASR)

Auto Service Request automates the Support Services process by using fault event

telemetry from your qualiﬁed ZFS Storage Appliance to initiate a service request. This

service detects faults at your site and forwards the telemetry data to systems at Oracle

for analysis and service request generation. Auto Service Request is included with

Oracle Premier Support for Systems and Hardware Warranty contracts.

All of the systems that compose the Auto Service Request infrastructure have been

built to provide conﬁdentiality, integrity, and availability of data. The Auto Service

Request security strategy has been designed with multiple layers of encryption,

authorization, access controls and data security, to ensure that organizational data is

protected.

There are several ASR implementations for various Oracle products. This white paper

refers speciﬁcally to the conﬁguration of ASR for Sun ZFS Storage Appliances. For

other ASR implementations, please refer to the speciﬁc product documentation.

Configuration

ASR is enabled within the product during the initial guided setup or later by going to

the Conﬁguration>Services>Phone Home Page (Figure 1). The page asks the user for

their My Oracle Support username and password in addition to the optional HTTPS

proxy information.

Figure 1 ASR Configuation

The ASR solution is delivered to the internal product groups through a number of

interconnected platforms and systems. These are all built with a focus on security and

use defense-in-depth to provide multiple layers of protection.

ZFS Storage Appliance Telemetry

Once the ZFS Storage Appliance is conﬁgured to Phone Home via ASR, the storage

appliance sends its conﬁguration, heartbeat and any faults that occur in XML over

HTTPS using the ASR service. On critical faults, a service request is created

automatically. This enables Oracle to provide better support for the appliance. In order

to send data back to Oracle, the appliance connects to the sites and ports in Table 1.

Table 1 Protocols and Ports

Source Destination Protocol Port Description

ASR Service

asr-services.oracle.com

HTTPS

443

For sending telemetry

messages to ASR

Backend.

ASR Service inv-cs.oracle.com HTTPS 443 For sending product

registration.

Support Bundles transport.oracle.com HTTPS 443 For sending support

(2011.1.9 and later)

bundles that contain state

(2013.1.1.6 and later)

of the appliance during a

failure.

Telemetry Data

The ZFS Storage Appliance collects three different types of messages. These include

audit messages describing the conﬁguration of the appliance, fault messages

containing description of the faults and a heartbeat message used to determine if the

appliance is up. For details and examples on message types refer to My Oracle

Support (MOS) document Sample ASR/Phone Home Messages from the ZFS Storage

Appliance (Doc ID 1510567.1), which is a sample telemetry message from the ZFS

Storage Appliance:

https://support.oracle.com/rs?type=doc&id=1510567.1

Message Header

All messages sent back to Oracle contain the following information in the header:

• System-id: A unique identiﬁer to indicate serial number of the system.

• Host-id: hostname of the system sending the message.

• Message-time: time the message was generated.

• Product-name: Model name of the ZFS appliance.

Audit Messages

• Audit messages are XML formatted messages containing a message header and

conﬁguration data

•

• Audit messages are sent once per week or when signiﬁcant system changes occur.

•

• Each message describes the following hardware and software components of the

appliance.

Hardware-components

The conﬁguration data from the appliance consists of a list of hardware components.

Each hardware component describes the parts of the appliance, such as, disks attached

to the appliance, memory and CPU. For each component, following attributes are

collected:

• FRU: This stands for ﬁeld replacement unit that can be replaced to ﬁx a fault that

occurs on the appliance.

•

• Model: is the hardware model.

• Manufacturer: is the hardware manufacturer.

• Serial: is the serial number of the hardware component.

• Revision: is the ﬁrmware revision of the component, if applicable.

• Size: memory and disk size, if applicable.

•

Software-components

The software components is a listing of the key software installed on the appliance. In

order to provide better support, data such as os-version and a list of services on the

appliance is collected.

Fault Messages

A message (XML) containing the fault description is sent back to Oracle when a

hardware fault occurs on the appliance. Each message contains the message header

along with the name of the fault, description and other attributes as listed below:

• message-id: is the fault code reported by the fault manager (fmd).

• event-uuid: is the unique identiﬁer for the problem

• event-time: is the time the fault occurred.

• severity: is the severity of the error

• description: is a brief description of the actual error.

• component: has the name of the component where the error occurred.

• fmdump details: diagnostic details on the component that caused failure from the

fault manager (fmd).

Heartbeat Messages

A heartbeat message containing message header is sent on a daily basis to conﬁrm the

ability to phone home when failure conditions occur as well as to indicate when an

appliance may not be operating properly. The heartbeat message only contains the

standard header and current timestamp.

Support Bundles

When a failure is detected, a full system support bundle will be sent to the support

ﬁles endpoint deﬁned in Table 1. This ﬁle will contain system conﬁguration

information, log ﬁles, and state information, which can possibly include core dumps

from the controller. This information is used solely for the purpose of addressing the

detected fault and is retained only for seven days after the closure of the associated

Service Request.

Auto Service Request Infrastructure at Oracle

At the heart of the Auto Service Request solution lies the core backend infrastructure

hosted within oracle.com. The core ASR infrastructure utilizes user account credentials

for validation of users, and digitally signed and encrypted trafﬁc for validation of

systems. All of the systems within the Auto Service Request infrastructure require

real-time access to the core infrastructure to process alarm and telemetry messages

received from end-devices, and to perform authentication lookups.

The core backend infrastructure is a mixture of systems, user interfaces, databases, and

web services that are managed and maintained by Oracle. All data stored by ASR is

segregated by organization in a multi-tenancy security model, and this security is

enforced through multiple layers of API-based access and authorization controls. Data

stored within the core infrastructure includes telemetry event data, registration data,

hardware and software conﬁguration, and ASR activation data.

There is no direct, outside access to the data stores of the Auto Service Request system.

All access requests are validated in real-time against the ASR authentication system

and pass through multiple layers of security and validation, before being granted

access to data elements (for more information, see the next section, Authentication

Infrastructure).

Authentication Infrastructure

All requests to the Auto Service Request infrastructure, whether system-generated or

human-generated, must pass through multiple layers of business logic and

authentication checks in order to gain access to telemetry data.

After passing through perimeter network security measures, requests are ﬁrst

analyzed for proper adherence to system API calls. Requests that use an improper

syntax, improperly formatted requests, or requests with a payload that violates

prescribed boundaries are immediately discarded at the outermost layer.

If the incoming request is an approved format, the authentication credentials provided

with the initial registration request are immediately veriﬁed against the Oracle Single

Sign On (SSO) database for validation. If the credentials presented are authenticated

successfully, the request is then compared against the authorization models currently

within the system to make sure that the user or system (although authenticated in

their identity) has the appropriate level of authorization to perform the request that

has been submitted. Following the initial registration with ASR, a private key is

generated by the ASR back end service and used by the client for the authentication of

all future messages.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle

Accessibility Program website at

http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc

Oracle Auto Service Request Security White Paper, Release 4.1

E37468-02

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected

by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce,

translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse

engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report

them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the

following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the

hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal

Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the

programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject

to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use

in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in

dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe

use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous

applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are

trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or

registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle

Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products,

and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of

third-party content, products, or services.

This product includes software developed by the JDOM Project.