Disaster Recovery Reference Guide
Contents
1. Agmunuoo ssoursnq 1940291 0 IWY ur jurod e sr axoug e durexo sty UJ cuc JEIg 000215 MES sueps 04 33 v0000L1 WOOOOLL sojensiu upy 7 D 91S jouseui3 UNMS Jausa ial did TTTTITTTTED spino a Roy OPIM gt f j Ja Loo XIOMJON Revision B e 316197102 20 KMS 2 x Disaster Recovery Reference Guide April 2010 Replication from Another Site FIGURE 3 2 Service Network Continuation Recovery Time Objective Sojnurui JO JayeuUr e SI jgmnuguoo ssaursnq 1940291 0 IWY qunowre y o durexa sry ug r Aria 0018 A fueaqr1 000678 8000011 B0000LL Q0r961 104138 WOOOOLL VOODOLL opino z sonsu LUPY O yams 19049413 91S jous pPUSVETWTPVES uonejs juowobeuey Kay 1 pass OMION TI Bey opm _T Chapter 3 Data Recovery 21 316197102 Revision B Scenario 1 Pre positioned KMAs Scenario 1 Pre positioned KMAs In this scenario the customer has a big environment with multiple sites Each site uses m A pair of KMAs and the infrastructure to support automated tape encryption m A single cluster where all KMAs share keys Along with the multiple sites this customer also maintains and uses equipment at a Disaster Recovery DR site that is part of t2. Devices 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 UNIX is a registered trademark licensed through X Open Company Ltd 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 Summary of Changes Date Revision Description April 2009 A Initial release April 2010 B Updates to this revision include a New Oracle branding m Engineering updates including a Backup and Key Sharing Considerations on page 16 u Key Pool Size Determination on page 17 m Added support for the IBM LTO4 Note Change bars are included in this revision 316197102 Revision B iv KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Contents Preface vii 1 Introduction 1 Architecture 2 Role Based Operations 4 Tape Drive and Media Comparison 5 T Series Tape Drives 6 LTO4 Tape Drives 7 Enabling and Disabling Enc
3. KMA Version 2 x Use tokens C Yes C No UNKN L Permanently encrypting UNKN C ves C No n 2 Permanently encrypting Select Set FIPS mode permanent UNKN C On C off m Yes J permanent cannot disable AgentID Enroll n No Q switchable E ni B KMS IPv4 6 addr Enroll 4 Enter the KMS values for Agent ID Pass Phrase KMS IP address of the appliance Load Drive Config Commit Cancel 8 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Enabling and Disabling Encryption Enrolling the LTO4 Tape Drives The enrollment process and the VOP screens are different for LTO4 tape drives The Enroll Drive tab allows the initial enrollment of the tape drives Once enrolled the tab and Enroll button change to Unenroll FIGURE 1 4 T Series Enrollment Selections LTO 4 virtual Operator Panel Version 1 0 13 on 10 0 0 1 2 0 xi Online connect 10 0 0 1 Empty serve un Encrypt microsystems Monitor Drive Enroll Drive Configure Drive Service Drive Change Enrollment Settings KMA Agent ID mi KMA IP Address LI Passphrase mi Confirm Passphrase a Set Offline Commit Enroll Cancel 316197102 Revision B Chapter 1 Introduction 9 Enabling and Disabling Encryption 10 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 CHAPTER 2 Component Recovery The Key Management System Version 2 x KM
4. software or commercial technical data pursuant to the applicable Federal Acquisition Regulation and agency specific supplemental regulations As such the use duplication disclosure modification and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract and to the extent applicable by the terms of the Government contract the additional rights set forth in FAR 52 227 19 Commercial Computer Software License December 2007 Oracle USA Inc 500 Oracle Parkway Redwood City CA 94065 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 which 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 ackup redundancy and other measures to ensure the 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 is a registered trademark of Oracle Corporation and or its affiliates Oracle and Java are registered trademarks of Oracle and or its affiliates Other names may be trademarks of their respective owners AMD Opteron the AMD logo and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
5. 290m LTOI Note Encryption is only supported with LTO4 Data Cartridges on LTO4 tape drives To avoid a security breach these drives will not write in these modes once the drive is enabled for encryption 316197102 Revision B Chapter 1 Introduction 7 Enabling and Disabling Encryption Enabling and Disabling Encryption Notes The T10000 tape drives must be at a minimum firmware level of 1 37 114 The service representatives must install the Hardware Activation Keys for the tape drives and have the required levels of the Virtual Operator Panel VOP available The customers partners and disaster recovery DR sites must use the current Customer version of the virtual operator panel VOP 1 0 12 or higher Enrolling the T Series Tape Drives During the initial T Series tape drive enrollment process the customer has the chance to configure the tape drives to Use Tokens with an air gap configuration and KMS Version 1 x Select if the drive can be switched between encryption and non encryption modes Select FIPS mode Enter Agent values for the Key Management System Enroll IPv4 and IPv6 addressing FIGURE 1 3 T Series Enrollment Selections Configure Drive Parameters x Pass Phrase Enroll Re enter Pass Phrase Enroll Fibre Idsnmp Logaing Network 1 Use tokens Select Yes A if using KMS Version 1 x 3 Set FIPS mode Version 2 1 Parameter pco s pn No O if using
6. 6 1 Yes LJ No Domain Address Hostname KMA Number Number of KMAs in Cluster KMA Location KMS Manager Location Configuration Types 1 SL8500 library 1 SL3000 library 1 SL500 library d 9310 library L700 1400 library Tape Drive Types A T10000A tape drive 1 T10000B tape drive A T9840D tape drive 1 HP LTO4 tape drive IBM LTO4 tape drive Site Location KMA S N KMA Name KMA Firmware Level KMA IP Address Service Network IP KMS Manager IP ELOM IP NTP Yes 1 No IP DHCP d Yes U No Gateway 1 Yes No IP DNS 2 Yes No IP IPv6 1 Yes LJ No Domain Address Hostname KMA Number Number of KMAs in Cluster KMA Location KMS Manager Location Configuration Types SL8500 library 1 SL3000 library SL500 library 9310 library L700 1400 library Tape Drive Types A T10000A tape drive A T10000B tape drive A T9840D tape drive 1 LTO4 tape drive 316197102 Revision B Chapter 2 Component Recovery 13 Component Configuration 14 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 CHAPTER Data Recovery Disaster recovery is the process policies and procedures that relate to preparing for recovery or continuation of business critical information to an organization after a natural or human induced disaster This includes m R
7. MAs provided by the shared resource site This avoids the need for a wide area network WAN link and the on site dedicated KMAs but requires additional time to restore the database In this approach the restore operation requires both normal KMS backup files and a Core Security backup This restore approach requires a quorum of the Key Split Credential members for the core security backup Restore operations take about 20 minutes per 100 000 keys After the restore is completed the drives must be enrolled and configured Three files are needed to take to a DR site Core Security backup file xml backup file dat backup file These files are created by a Backup Officer 18 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 Replication from Another Site Replication from Another Site FIGURE 3 1 on page 20 and FIGURE 3 2 on page 21 show two examples of two geographically separate sites one KMS cluster with four KMAs in the cluster two KMAs at each site During the initial install after the first KMA is configured any additional KMAs new or replacements self replicate from the other KMAs in the cluster Recovery of a single KMA can be accomplished with no impact to the rest of the cluster as long as at least one KMA remains operational FIGURE 3 1 is an example of a Recovery Point Objective In this example a point in time to recover business continuity to an entire site could take month
8. S uses a cluster design that requires at least two key management appliances KMAs This design helps reduce the risk of disrupting business continuity In addition some design and safe guard requirements are in place to assist in component recovery Clustering KMAs allows for replication of database entries and workload balancing In the unlikely event that a component should fail it can be easily replaced and restored to operation While designing an encryption and archive strategy an important design guideline is to make sure that critical data generated at any site is replicated and vaulted off site This is described in Chapter 3 Data Recovery on page 15 This chapter provides information about the replacement of components in the Key Management System KMA Outage A single KMA can be recovered without any impact to the rest of the cluster as long as at least one KMA remains operational The following sections address scenarios that require recovery of a single KMA Software Upgrade Software upgrades do not imply a repair or a recovery however sometime during this action a KMA will be out of service as the upgrade takes place An upgrade can be done without interrupting the active encryption agents Downloading the new software can be done concurrently on all KMAs in the cluster 1 Multiple Servers Exceptions to this standard configuration must be made with the approval of KMS Engineering and Global Support Se
9. Storage Tek Crypto Key Management System Disaster Recovery Reference Guide SS 4 Sun Part Number 316197102 April 2010 Revision B Submit comments about this document by clicking the Feedback link at http docs sun com Crypto Key Management System Disaster Recovery Reference Guide 316197102 Revision B Copyright 2009 2010 Oracle and or its affiliates All rights reserved 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 art in any form or by any means Reverse engineering disassembly or decompilation of this software unless required by law or 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 software 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 RIGHTS Programs software databases and related documentation and technical data delivered to U S Government customers are commercial computer
10. ackup then database backups before all generated keys from a single KMA are issued to Data Units Example Two Database Backup One physical site in a KMS Cluster m A localized disaster may destroy the entire KMS m Database backups are the only protection for the keys Maintain offsite copies of the Core Security and Database backups For bare minimum protection TABLE 3 1 Database Backup Calculations 1 Calculate how many tapes will be initially encrypted using one key per tape 2 How many hours days or weeks will it take to issue the initially created keys Note Each KMA creates 1000 keys default when created 3 Calculate how many tapes mounted will have an expired key encryption period 4 Add these two calculations together 5 Assume only one KMA issues all the keys and backup the database before the initial keys are all issued This provides a 50 safety factor to the calculation 6 Repeat this calculation based on new tape influx and Re use the encryption period expiration Things to remember m Archive copies or do not archive copies Remember old backups contain users passwords and other sensitive data you may not want to keep m Make and archive two current Database backups and in case of backup media failure m Because you computed a 50 safety factor in the above assumption that only one KMA was issuing keys either backup contains all the active keys m Never archive old c
11. ate this information active active This way if any KMA should go down encryption operations continue Agent tape drive A device that performs encryption using keys managed by the KMA Cluster and KMS Manager Note With Version 2 1 the latest KMS software and the latest tape drive firmware the following drives are FIPS compliant Tape Drive FIPS Level T10000A 1 T10000B 2 T9840D 1 HP and IBM LTO4 No plans for FIPS FIPS levels of security for the above tape drives includes Levels 1 and 2 Level 1 The lowest level with production grade requirements Level 2 Adds requirements for physical tamper evidence and role based authentication Built on a validated operating platform This selection provides a higher level of security for the KMAs and tape drives Data unit Media a data cartridge Key groups An organization for keys and associates them with a Key Policy Network connections The Key Management System consists of two networks Management network KMS manager GUI to KMAs a Service network KMAs to encryption agents These two networks isolate the storage devices from heavy corporate network traffic and improves the response time for key requests FIGURE 1 1 on page 3 shows the rear panel of a Key Management Appliance the connections and a brief description of the components to which it connects 1 FIPS Federal Information Processing Standards are public
12. ated at a suitable distance such that a single building fire does not destroy all the data The distance should also take into account natural disasters For example if all the backup sites are located in buildings across New Orleans the destruction of data is unavoidable in a Katrina like disaster a hurricane that struck New Orleans in 2005 Restore A restore from backup is only required if all KMAs in the cluster have failed such as if a site is destroyed by fire Note Restoring the KMS from a backup requires a Quorum that a Backup Operator creates and maintains the backups and a Security Officer to restore them Make sure the required number of Quorum users are available 28 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Scenario 4 Restore From Backup To restore the system from a backup refer to the KMS Administrator Guide and 1 Select Secure Information Management Backup List This allows you to view the history and details of the backup files 2 From the Backup List screen highlight the Backup you want to restore from and double click the Backup entry The Backup Details dialog box is displayed 3 Click on the Restore button The Restore Backup dialog box is displayed FIGURE 3 6 Restore from Backup Restore Backup x Backup File Name E Browse Backup Wrapping Key File Name oo Browse Core Security Backup File Name Doo Browse C
13. c 88 sec Tape Unload 23 sec 23 sec 12 sec 22 sec 15 sec Emulation Modes 3490E 3590 3490E 3592 Native 3592 T9940 3490E 3590H Interface Support FC2 FC4 FC4 FICON FC2 FICON FC4 FC4 FICON ESCON SCSI Ultra320 MTBF 100 duty cycle 290 000 hrs 290 000 hrs 290 000 hrs 250 000 hrs 250 000 hrs Media Format Compatibility Read Write Proprietary Format Proprietary LTO2 Read only T10000 Cartridge Format LTO3 Rd Write LTO4 Rd Write VolSafe WORM Yes Yes Yes Power Auto ranging 88 264 VAC 48 63 Hz 100 240 VAC Amperage 50 60 Hz at 0 8A max Consumption 90 W 82 W 35 W 30 W 316197102 Revision B Chapter 1 Introduction 5 Tape Drive and Media Comparison T Series Tape Drives TABLE 1 2 shows the media compatibilities for the T Series T10000 and T9840 drives m Encryption capable T Series tape drives m Non encryption T Series tape drives TABLE 1 2 T Series Tape Drive Media Compatibilities Enrolled for Not Enrolled Task Encryption for Encryption Write new data encrypted Yes No Write new data not encrypted No Yes Read encrypted data with key available Yes No Read non encrypted data Yes Yes Append non encrypted data to encrypted tape No No TABLE 1 3 shows a comparison between m Encryption enabled and non encrypted tape drives m Encrypted and non encrypted media TABLE 1 3 T Series Ta
14. configuring Key Transfer Partners administrators must perform tasks in a specific order that requires several roles including m Security Officer role m Compliance Officer role m Operator role To configure Key Transfer Partners refer to the KMS Administrator Guide and 1 Configure a Key Transfer Partner for both KMS Clusters participating in key exchange 2 Establish a public private key exchange to communicate with the KMS clusters For example in case of sending an e mail two sites can use an established communication method to secure an e mail exchange and authenticate its source and recipient Note There are mechanisms such as the fingerprint in place to prevent modification of this information during transit 3 Gather a quorum to approve the creation of the new Transfer Partner 4 Assign the Transfer Partner to one or more Key Groups 5 The next step in the process is to export keys from one KMS cluster and import them into another This can be done many times 26 KMS2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 Scenario 3 Key Transfer Partners FIGURE 3 5 Transfer Key Partners 48 sn 9 3uapuadapuj Sossesssasasazenencecesdacescscccoseneconcocieeeeseoee Chapter 3 Data Recovery 27 316197102 Revision B Scenario 4 Restore From Backup Scenario 4 Restore From Backup A backup refers to Making copies of data so that the
15. d T10000A 798400 LTO4 7100008 EE 319 i B SL8500 3000 SL500 Library Library Library Storage coni ene Pi ie Fao i dat Backup File Off Site 316197102 Revision B Chapter 3 Data Recovery 25 Scenario 3 Key Transfer Partners Scenario 3 Key Transfer Partners Key Transfer is also called Key Sharing Transfers allow keys and associated data units to be securely exchanged between Partners or independent clusters and is required if you want to exchange encrypted media Note A DR site may also be configured as a Key Transfer Partner This process requires each party in the transfer to establish a public private key pair Once the initial configuration is complete m The sending party uses Export Keys to generate a file transfer m The receiving party then uses Import Keys to receive the keys and associated data As a practice it is not recommended to use Key Transfer Partners for Disaster Recovery However if or when DR sites create keys during the backup process doing a key transfer can incrementally add the DR sites keys to the already existing data base The Key Transfer process requires each user to configure a Transfer Partner for each KMS Cluster m One Transfer Partner Exports Keys from their KMS Cluster m The other Transfer Partner Imports Keys into their KMS Cluster When
16. d Training Function URL Description Web Site http www oracle com index html General information and links Documentation Search for technical documentation m Customer http www sun com documentation Download PDF HTML documents m Employee http docs sfbay sun com Order printed documents m Partner https spe sun com spx control Login Downloads Download firmware and graphical user m Customer http www sun com download index jsp interfaces patches and features m Employee http dlrequest sfbay sun com 88 usr login Support http www sun com support Obtain and escalate support Training http www sun com training Access training resources Oracle Welcomes Your Comments Oracle is interested in improving its documentation and welcomes your comments and suggestions Submit your comments by clicking the Feedback link at http docs sun com Please include the title and part number of your document with your feedback Crypto Key Management System Disaster Recovery Reference Guide PN 31619710x viii KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 cHAPTER 1 Introduction Encryption is based on the science of cryptography and is one of the most effective ways to achieve data security today To read an encrypted file you must have access to the key that will enable you to decipher the file Disaster recovery DR is the process pol
17. ecovery Point Objective RPO The point in time to recover data as defined by a business continuity plan This is generally a definition of what the business determines is an acceptable loss in a disaster situation This could be in hours days or even weeks m Recovery Time Objective RTO The duration of time that a business process must be restored after a disaster or disruption in order to avoid unacceptable consequences associated with a break in business continuity This could be minutes when using a combined service network See FIGURE 3 2 on page 21 The Key Management System Version 2 x can span multiple geographically separated sites This highly reduces the risk of a disaster destroying the entire cluster Clustering KMAs allows for replication of database entries and workload balancing Although unlikely that an entire cluster needs to be recreated most of the key data can be recovered by recreating the KMS 2 x environment from a recent database backup When designing an encryption archive strategy one very important design element is that critical data generated at any site is replicated and vaulted at a recovery site If a site is lost this backup data may be transferred to another operational site Data units and keys associated with tape volumes will be known to the KMAs at the sister site and encrypted data required to continue business operations will be available The damaged portion of the cluster can be res
18. erations Role Based Operations The KMS manager defines and uses the following roles Completing and assigning roles is a customer task service representatives should only advise m Security Officer Full authority to view modify create and delete Sites KMAs Users and Transfer Partners m Compliance Officer Management for key policies and key groups Determines which Agents and Transfer Partners can use key groups m Operator Manages Agents Data Units and Keys m Backup Operator Performs backups m Auditor Views information about the KMS Cluster D Note Each person or user may fulfill one or more of these roles The KMA verifies that the requesting user has permission to execute an operation based on the role Unavailable operations typically indicate the wrong role There are four basic operations a user role can have Create Delete Modify and View FIGURE 1 2 shows an example of the User Detail screen FIGURE 1 2 User Roles Detail Screen User Details possi i General passphrase For the customer 1 Enter a User ID Between 1 and 64 characters User ID Description Roles Auditor Operator s S s s s si Enabled e Failed Login Attempts Compliance Officer 2 Provide a description Between 1 and 64 characters Backup Operator 3 Click the Pass phrase tab and Enter a Pass phrase twice Pass phrases mu
19. erver can be scrapped or destroyed onsite The KMA is a single field replaceable unit FRU and the entire unit must be replaced if any component of a KMA server ever fails First the KMA should be deleted from the cluster so that the remaining KMAs will no longer attempt to communicate with it If the KMA console is still accessible the option to reset the KMA may be executed The reset operation will return the unit to its factory defaults This operation offers the option to scrub the server s hard disk as an extra security precaution Disposition of the failed server is handled by the customer A replacement KMA server is configured and added to the cluster as described in the Key Management System Version 2 0 Service Manual PN 316197401 Once the new KMA is added to the cluster m The database is replicated m The KMAs in the cluster are re synchronized m The new KMA becomes an active member of the cluster 12 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Component Configuration Component Configuration TABLE 2 1 Component Configuration Account Name Security Officers Quorum Members Site Location KMA S N KMA Name KMA Firmware Level KMA IP Address Service Network IP KMS Manager IP ELOM IP NTP Yes No IP DHCP 1 Yes U No Gateway 1 Yes No IP DNS 2 Yes No IP IPv
20. he KMS backup windows or key transfer windows For this discussion we ll assume an hourly rate of key consumption has been calculated Note KMAs pre generate keys so a key creation request from an agent does not actually cause a key to be created on the KMA until the key pool maintainer runs within the server When the server is busy the key pool maintainer can be delayed in its operations The total cluster keypool size must be large enough so that KMAs can hand out pre generated keys from their key pool during the backup windows When the key pool size is too small KMAs can get drained of pregenerated keys and start returning no ready key errors Tape drives failover to other KMAs when this happens and it adds further disruption to the performance challenges of the backup key transfer window The default key pool size of 1000 keys should be sufficient for most customers unless the estimated worst case key creation rate for the backup windows exceeds this The KMS backup window should be observed periodically as it will gradually grow as the database gets larger Adjustments to the key pool size may be necessary when the backup window exceeds a threshhold The key pool size should also be adjusted if the key consumption rate grows due to changes in the overall tape workload 316197102 Revision B Chapter 3 Data Recovery 17 Shared Resources Shared Resources Shared resources can provide cost efficient elements for disaster
21. he customers KMS cluster See FIGURE 3 3 on page 23 for this scenario This customer uses a simple backup scheme that consists of m Daily incremental backups m Weekly differential backups m Monthly full backups The monthly backups are duplicated at the DR site and sent to an offsite storage facility for 90 days After the 90 day retention period the tapes are recycled Because the customer owns the equipment at the DR site this site is just an extension of the customer that strictly handles the back up and archive processes 22 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Scenario 1 Pre positioned KMAs FIGURE 3 3 Pre positioned Equipment Client OS SUSE Linux 9 Solaris 9 Solaris 10 Solaris Sparc Core Security Backup File xmi Backup File dat Backup File k k Off Site Storage Capabilities Pre Positioned Equipment at a Disaster Recovery Site 316197102 Revision B Chapter 3 Data Recovery 23 Scenario 2 Shared KMAs Scenario 2 Shared KMAs This scenario is very similar to Scenario 1 Pre positioned KMAs however the Disaster Recovery site owns the equipment and is sharing the resources with several other customers See FIGURE 3 4 on page 25 for this scenario Because this Disaster Recovery site supports other DR clients you cannot assume the site is always configured for encryption capable
22. icies and procedures that relate to and preparing for recovery or continuation of business critical information to an organization after a natural or human induced disaster Disaster recovery is a subset of a larger process known as business continuity planning BCP and should include replacing hardware re establishing networks resuming applications and restoring data A business continuity plan also includes non IT related aspects such as key personnel facilities and communications to restore the reputation and continuity of the business Oracle s StorageTek Crypto Key Management System KMS Version 2 x is a comprehensive key management platform designed to address the rapidly growing enterprise commitment to storage based data encryption Compiling with open security standards KMS 2 x provides the capacity scalability and interoperability to centrally manage encryption keys over widely distributed and heterogeneous storage infrastructures KMS 2 x is specifically designed to meet the unique challenges of storage key management including m Long term key retention Securely retains encryption keys for the full data lifecycle which can exceed a decade in length For example some sites have their key retention period set to over 50 years m Interoperability Provides the level of interoperability to support a diverse range of storage devices that can attach to both mainframe or open systems platforms under a single storage key
23. ive KMA a This KMA should not have a service network connection so it would not be burdened with tape drive key requests at any time especially during the backup or key transfer windows This KMA could also be used for KMS Manager GUI sessions thus offloading the other KMAs from handling management related requests m The faster the management network connectivity of the backup and key transfer KMA the better it will be able to keep up with the additional load during backup and key transfer windows This is true for all KMAs but especially for the KMA performing backups as it will fall behind on servicing replication requests during the backup window Having a fast network connection will help to minimize the replication backlog such as lag m Put the backup and key transfer KMA in a site that is not used by tape drives The tape drives then preference other KMAs within the site that they have been assigned and avoid using the backup and key transfer KMA m Add more KMAs to the sites containing tape drives so that load balancing of key requests will occur across more KMAs This reduces the number of key requests that the backup and key transfer KMA has to handle 16 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 Key Pool Size Determination Key Pool Size Determination KMS administrators should know the worst case number of keys they expect to be created per unit of time and the duration of t
24. lose 4 Click on the Start button When the upload completes the Key Split Quorum Authentication dialog box appears The Core Security Backup Quorum must type their user names and pass phrases to authenticate the operation 5 Click on the OK button A progress display of the restore is indicated 316197102 Revision B Chapter 3 Data Recovery 29 Backup Methodology Backup Methodology Remember each customer and each situation is different Here are some guidelines that might help Backup frequency there are two types of backups handled differently m Core Security Backup which must be secured using special tactics m Database Backup of the Key Data which needs to be protected Core Security Backup The Core Backup contains a primary component for the KMS the Root Key Material It is this key material that is generated when a Cluster is initialized The Root Key Material protects the Master Key a symmetric key that protects the Data Unit Keys stored on the KMA The Core Security backup is protected with a key split scheme that requires a quorum of users defined in the Key Split Credentials This quorum of users must provide their usernames and passphrases to unwrap the Root Key Material Methodology The Core Backup must precede the first Database Backup and then this core backup only needs to be repeated when members of the Key Split change quroum This is a security item handled and protected s
25. ly announced standards and guidelines developed by the United States Federal government Many FIPS standards are modified versions of standards used in the wider community ANSI NIST IEEE ISO etc 2 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Architecture jeuondo jeuondo JOJUOIN pueogAay SN poujejy arway VIN e uerddy jueuioBeue y Aay sdqw DOT 1e 4109 se yans spaads je juap asn ysnw sdnoj3 pod yms e au JOM osje Aew one xajdnp Iny age suog ei Oman sjebasb6y dIv1 asn 20u op Aay Ajjenuew payesaudse ase sod e NV1 QUIH r gt lt r 3IEAZUI YJOMJIU 331AJ8 e JO 9562 ui AuepunpaiJ SapiAoJd YOUMS Jausa sJnjeaj SIYL YJOMIAN BIIMIAS BY 104 ILJU 3 8uls e OU NYT pue z NV s32ejia1ur 19uJ8u13 e2ISAYA a dnjnuu 270621560 0 ajqissod s 4 T Z UOISI A YUM 930N id FIGURE 1 1 Key Management Appliance Connections and Components I I l i eee med re eS Sos unjrej ic rr I Lea I dode eAnejueseJdey 80S 1 amp L NYI YJOMJAN SINOS V0000L4 q ni SG ff toe ea ee 2 i dH RES 07861 wal FC 800001 seAuq ede sjuaby YIOMJAN 29IAJ9S WOMEN JuatuaBeue uonejs juawebeuey Aay yIOMJON juawabeuey This figure shows the connections and components to a SunFire X2200 Key Management Appliance Chapter 1 Introduction 3 316197102 Revision B Role Based Op
26. management system a High Availability Provides high availability using active N node clustering dynamic load balancing and automated failover whether the appliances are together in the same room or distributed around the world m High Capacity Manages large numbers of storage devices and even more storage keys A single clustered KMS 2 x appliance pair can provide key management services for thousands of storage devices and millions of storage keys m State of the Technology Supports StorageTek s T Series the Hewlett Packard HP and International Business Machines IBM LTO4 encryption capable tape drives This chapter provides a a high level overview of components user roles and the method for enabling and disabling encryption for recovery 316197102 Revision B 1 Architecture Architecture The architecture for the Storage Tek Key Management System encryption solution consists of Key Management Appliance KMA A security hardened dual core processor with Sun Microsystems proven Solaris 10 operating system that delivers policy based key management and key provisioning services Note The KMAs are FIPS compliant at Level 3 KMS Manager graphical user interface GUI A stand alone application that users run on their own system using either a Windows or Solaris based platform KMS cluster A full set of KMAs in the system All KMAs in a cluster are aware of the other KMAs in the system and replic
27. opies of Database m If you routinely delete keys for policy or compliance reasons the deleted keys can be recovered from prior backups m Keep redundant copies Do not create two backups Make two identical copies to protect against backup media failure This scheme also ensures another key was not issued during the backup making the two copies different 316197102 Revision B Chapter 3 Data Recovery 31 Backup Methodology 32 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 AS 4 Sun ORACLE Oracle Corporation Worldwide Headquarters 500 Oracle Parkway Redwood Shores CA 94065 U S A
28. pe Drive and Media Support Media Types Tape Drive Types Non encrypted Tapes Encrypted Tapes Standard drive m Fully compatible m Not capable non encrypted m Read write and append of reading writing to or appending to this tape m Can re write from the beginning of tape BOT Encryption m Read capability only m Fully compatible capable drive Not capable of appending to m Read with correct keys this tape m Write with current m Can re write from the write key beginning of tape BOT 6 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Tape Drive and Media Comparison LTO4 Tape Drives Notes Both HP and IBM LTO4 tape drives are m Specified to interchange with un encrypted data cartridges from other tape drives that comply to the LTO U 28 U 316 and U 416 specifications m Capable of interchanging encrypted data cartridges provided the correct encryption key is available Future compatibility In the future LTO drives will be capable of m Reading and writing tapes from the current generation m Reading and writing tapes from one earlier generation m Reading tapes from two earlier generations TABLE 1 4 LTO Media Compatibility Capability Native Capacity Length Format Write Read 800 GB WORM LTO4 Yes Yes 800 GB 820m LTO4 Yes Yes 400 GB WORM LTO3 Yes Yes 400 GB 680m LTO3 Yes Yes 200 GB 580m LTO2 100 GB 580m LTO1 50 GB
29. pecially as if it were the keys to the castle This is required to restore any backup of the KMS For that reason as a best practice keep two copies of this backup in two secure locations on a portable media of the customers choice such as CDs USB memory sticks or external hard drives When a new Core Backup is created and secured the old ones should be destroyed Database Backup Note Backup Operators are responsible for securing and storing data and their keys A Database Backup consists of two files a Backup file and a Backup Key file These filenames are automatically generated however you can edit the names Each KMA creates 1000 keys default when created This may vary during installation Each KMA controls and assigns its own keys After issuing 10 keys the KMA creates 10 keys to replenish them Keys are then replicated to all KMAs in the KMS Database Backups are encrypted with AES 256 and therefore secure 30 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B e 316197102 Backup Methodology Methodology Example One Database Backup Multiple sites in the KMS Cluster m Keys are protecting keys against corruption m Keys are being protected by replication The customer should never need a total disaster recovery of the cluster because of the geographically placed data centers Creating backups for this customer are not as critical as Example Two however create a core security b
30. processes Note The KMAs must be reset to factory settings before creating a configuration for a different customer At the DR site m The customer selects the appropriate equipment from the DR site inventory m The DR site configures the equipment and infrastructure accordingly Important The customer must provide the DR site with the three KMS back up files a Core Security backup file a xml backup file a dat backup file At the DR sites the customer m Configures an initial KMA using the QuickStart Wizard m Restores the KMA from the KMS back up files m Activate enable or switch the drives to encryption capable DR representatives m Enrolls the tape drives into the DR site KMA cluster Once the job is done the Disaster Recovery site needs to m Switch off encryption from the Agents m Remove the tape drives from the cluster or reset the drives passphrase m Reset the KMAs to factory default Disconnect the infrastructure and network 24 KMS2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 FIGURE 3 4 Shared KMAs Scenario 2 Shared KMAs T10000A T9840D T100008 SL3000 Library CSI FEY t Client O S Microsoft Windows XP Microsoft Windows 2003 Microsoft Windows Vista Red Hat Linux 3 0 and 4 0 SUSE Linux 9 2 Solaris 9 Solaris 10 Solaris Sparc Disaster Recovery Site Equipment Selections TIO000A LE EU Em u
31. recovery Companies such as m IBM Business Continuity and Recovery Services BCRS m Iron Mountain Inc m SunGard These companies specialize in records management data destruction and data continuity and recovery These companies purchase equipment that several customers can use for various reasons including backup and archive In the usage of disaster recovery the customer can use tape drives libraries and other resources of a shared resource site for short periods of time either to do a disaster recovery test or an actual recovery from a disaster There are two approaches for disaster recovery and key management m One approach is for the customer to place KMAs at the DR site and configure these into their production cluster using a WAN connection These KMAs are dedicated to the specific customer and allows the customer s keys to always be at the DR site and ready for use In this approach a recovery can begin once the customer enrolls the tape drives in the KMAs at the shared resource site and joins the KMS cluster This can be done by connecting the KMS Manger GUI to the KMAs at the DR site In a true disaster recovery scenario these may be the only remaining KMAs from the customer s cluster Drive enrollment can be completed within minutes Once the enrollment is complete and the drives have been configured tape production can begin m Another approach is to restore the backups of the customer s production KMS into K
32. rvices 316197102 Revision B 11 KMA Outage m Activating of the new software requires a reboot of the KMA server Therefore rebooting the KMAs in the cluster must be staggered so that at least one KMA is active at all times As each KMA returns to an online status any database updates done while the KMA was offline are replicated and all KMAs in the cluster are re synchronized Network Disconnect When a KMA is disconnected from the management network such as when new software is activated the remaining KMAs in the cluster continue to attempt to contact it and report communication errors in the audit event log Agents continue to communicate with other KMAs across the network Usually these are other KMAs attached to the same service network However because Agents may be attached to the management network they first attempt to work with KMAs in their own configured site but if the need be they will contact any reachable KMAs within the cluster When the KMA is reconnected to the network any database updates done while the KMA was disconnected are replicated and all KMAs in the cluster are re synchronized Hardware Failure Important There should be a label on the top cover of the KMA server that states DO NOT SERVICE WHOLE UNIT FRU KEY MANGEMENT APPLIANCE If for any reason a component in the server fails you must replace the entire server Then for security reasons give the server to the customer The s
33. ryption 8 Enrolling the T Series Tape Drives 8 Enrolling the LTO4 Tape Drives 9 2 Component Recovery 11 KMA Outage 11 Software Upgrade 11 Network Disconnect 12 Hardware Failure 12 Component Configuration 13 3 Data Recovery 15 Backup and Key Sharing Considerations 16 Key Pool Size Determination 17 Shared Resources 18 Replication from Another Site 19 Scenario 1 Pre positioned KMAs 22 Scenario 2 Shared KMAs 24 316197102 Revision B Scenario 3 Key Transfer Partners 26 Scenario 4 Restore From Backup 28 Backup Methodology 30 Core Security Backup 30 Database Backup 30 vi KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Preface This guide is intended for StorageTek representatives customers and anyone responsible for planning disaster recovery processes and procedures using Oracle s StorageTek Crypto Key Management System Version 2 x Related Information These publications contain additional information Publication Description Part Number Crypto Key Management Systems Assurance Guide 316194801 Crypto Key Management System Installation 316194901 Crypto Key Management System Administrator Guide 316195101 These documents are available at m Customer http docs sun com app docs prod stortek crypto keymgmt20 m Employee http docs sfbay sun com app docs prod stortek crypto keymgmt20 316197102 Revision B Preface vii Documentation Support an
34. s m If Site A were destroyed and Site B is still intact Then the customer would need to replace all the destroyed equipment for the infrastructure including the KMAs for the cluster and the tape drives Once the site is restored and functional Install and create the new KMAs requires a Security Officer and Quorum Join the Existing Cluster one at a time for the new KMAs Install and activate the new tape drives n n n Enroll the new tape drives now called Agents Site A would then self replicate from the surviving KMAs at the intact Site B FIGURE 3 2 is an example of a Recovery Time Objective In this example the amount time to recover business continuity is a matter of minutes m If the KMAsat Site A were destroyed and the infrastructure at Site B is still intact Then with a Wide Area Service Network that connects the tape drives between the two sites the intact KMAs from Site B are capable of continuing tape operations between both sites Once the KMAs are replaced at Site A they would then self replicate from the surviving KMAs at the intact Site B similar to the description above During the QuickStart program the customer would select 2 Join Existing Cluster one at a time for each of the new KMAs 316197102 Revision B Chapter 3 Data Recovery 19 Replication from Another Site FIGURE 3 1 Replication from Another Site Recovery Point Objective SY UOUI BYP pmo sty axis axguo ue 0
35. st be from Security Officer a 8 to 64 characters Must use m 3 of the 4 classes upper case lower case numbers and symbols s n ganc a This should not include users name 4 KMS 2 x Disaster Recovery Reference Guide April 2010 Revision B 316197102 Tape Drive and Media Comparison The following tables provide tape drive and media comparisons TABLE 1 1 Tape Drive Comparisons Tape Drive and Media Comparison Physical Specifications T10000A T10000B T9840D HP LTO4 IBM LTO4 Height 8 25 cm 8 25 cm 8 25 cm 8 25 cm 8 25 cm 3 25 in 3 25 in 3 25 in 3 25 in 3 25 in Width 14 6 cm 14 6 cm 14 6 cm 14 6 cm 14 6 cm 5 75 in 5 75 in 5 75 in 5 75 in 5 75 in Length depth 42 5 cm 42 5 cm 38 1 cm 21 38 cm 20 5 cm 16 75 in 16 75 in 15 in 8 4 in 8 09 in Weight 5 kg 11 Ib 5 kg 11 Ib 3 9 kg 8 5 Ib 2 24 kg 3 kg 4 94 Ib 6 6 Ib Performance Specifications Capacity native 500 GB 1 TB 75 GB 800 GB 800 GB Transfer rate native 2 to 4 Gb s 4 Gb s 30 MB s 4 Gb s 4 Gb s Throughput native 120 MB s 120 MB s 30 MB s 120 MB s 120 MB s Data Buffer size 256 MB 256 MB 64 MB 128 MB 128 MB Number of tracks 768 1152 576 896 896 Tape Thread amp Load 16 sec 16 sec 8 5 sec 19 sec 15 sec Access Time 46 sec 46 sec 8 sec 62 sec 48 sec Tape speed 2 0 and 2 0 3 74 and 3 4 m s 7 00 m s 4 95 m s 4 95 m s Rewind time 90 sec 90 sec 16 8 sec 124 se
36. tored easily at the same or a different location once site operations resume Many companies employ the services of a third party disaster recovery DR site to allow them to restart their business operations as quickly as possible Periodic unannounced DR tests demonstrate the company s degree of preparedness to recover from a disaster natural or human induced A number of possible scenarios exist some are discussed here Shared resources Provide cost efficient elements for disaster recovery Replication Restoration through replication from intact KMAs Scenario 1 Pre positioning KMAs Scenario 2 Sharing KMAs Scenario 3 Key Transfers Scenario 4 Restore from Backup Backup Methodology Some guidelines that might help 316197102 Revision B 15 Backup and Key Sharing Considerations Backup and Key Sharing Considerations KMS backups and key sharing import export are database intensive and reduce response time on the KMA while it is performing the backup or key transfer operation If possible reduce tape drive workloads during the KMS backup and transfer window If that is not possible then consider the following options m KMS backups and key transfers can occur on any KMA but a best practice would be to use the same KMA each time Most likely this is how cron jobs invoking the KMS backup utility will get setup anyway m If the cluster is large enough then a KMA may be dedicated as an administrat
37. y may be used to restore the original after a disaster or other event where the data has been lost These copies are typically called backups which serve to m Restore a site following a disaster disaster recovery m Restore files after they have been accidentally deleted or corrupted It is important to recognize and use a backup scheme that works for each a department group organization or business call this customer specific It is also important to have confidence that the backup process is working as expected For the Crypto Key Management System the following are available to help create and when necessary restore the Key Management System m Backup A file created during the backup process that contains all the information needed to restore a KMA This file is encrypted with a key generated specifically for the backup This key is contained in the corresponding backup key file m Backup Key File A file generated during the backup process that contains a key used to encrypt the backup file This file is encrypted using a system master key The master key is extracted from the Core Security backup file using a quorum for the key split credentials m Backup Operator A user role that is responsible for securing and storing data and keys IEY Note See Backup Methodology on page 30 for more information Backup Locations Keep in mind that the KMS backup location should be at a site that is safely loc
Download Pdf Manuals
Related Search