vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Planning ahead for importing key material 

Keep the following considerations in mind when you're ready to import root key material to the service.



 Review your options for creating key material 

Explore your options for creating 256-bit symmetric encryption keys based on your security needs.

For example, you can use your internal key management system, backed by a FIPS-validated, on-premises hardware security module (HSM), to generate key material before you bring keys to the cloud.

If you're building a proof of concept, you can also use a cryptography toolkit such as [OpenSSL](https://www.openssl.org/) to generate key material that you can import into Key Protect for your testing needs.





 Choose an option for importing key material into Key Protect 

Choose from two options for importing root keys based on the level of security that's required for your environment or workload.

By default, Key Protect encrypts your key material while it's in transit by using supported ciphers of the Transport Layer Security (TLS) 1.2 and 1.3 protocols. For more information about those ciphers, check out [Data encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-security-and-compliancedata-security).

If you're building a proof of concept or trying out the service for the first time, you can import root key material into Key Protect by using this default option.

If your workload requires a security mechanism beyond TLS, you can also [use an import token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keysusing-import-tokens) to encrypt and import root key material into the service.





 Plan ahead for encrypting your key material 

If you choose to encrypt your key material by using an import token, determine a method for running RSA encryption on the key material. You must use the RSAES_OAEP_SHA_256 encryption scheme as specified by the

[PKCS #1 v2.1 standard for RSA encryption](https://tools.ietf.org/html/rfc3447).
* Where are you going to store smart cards when they are not in use?
* Who needs to know the smart card PINs?



Some organizations store their smart cards in a safe, and keep a log of when the smart cards are used for administrative actions and who used them.





 Considerations for defining the file security policy 

If you decide to use key part files and signature key files, you also need to consider the following aspects:



* Where are you going to save backup copies of the files?
* Who needs to know the file passwords?



Many security standards require dual control for administrative actions. Dual control means that more than one person must cooperate in order to perform the action. Dual control can be accomplished by setting the signature threshold to 2 or more, and having different people own each smart card and PIN or having different people know the file passwords. Dual control when loading the master key register from smart cards can be accomplished by placing the master key parts on different smart cards and having different people own each smart card and PIN.
About Key Protect 

IBM® Key Protect for IBM Cloud® is a full-service encryption solution that allows data to be secured and stored in IBM Cloud using the latest envelope encryption techniques that leverage FIPS 140-2 Level 3 certified cloud-based hardware security modules.

Sensitive data should not be stored on any cloud provider unencrypted (as "plaintext", in other words). But just as with any method of encryption, going back to the earliest known ciphertexts created thousands of years ago, the trick is not just to encrypt information so that it cannot be decoded easily but to protect the ciphers used to encrypt and decrypt it (since having a cipher is as good as having the data).

While it is possible to set up a hardware security module (HSM) on premises to manage your data, this kind of system can be very expensive to establish and manage. Cloud-based storage, where encrypted data must be accessible at scale and at speed from a variety of permissioned actors, is less expensive, but has its own difficulties. How can you be sure that the data is secure when the key used to encrypt it (what's known as a "data encryption key") could exist on dozens if not hundreds of computers spread all over the world? In that scenario, your data is only as secure as the computers and connections of those with the data encryption key.

The solution is a key management system like Key Protect, which keeps data secure by encrypting the data encryption keys (DEKs) that encrypt your plaintext data with root keys managed by IBM via an impenetrable HSM. In this kind of a system, known as "envelope encryption", the process of decrypting the data means first "unwrapping" the encrypted DEK (opening its envelope, in other words) and then using the DEK to decrypt the data.

For more information about envelope encryption works, check out [Protecting data with envelope encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption).



 What Key Protect offers
For more information, check out [Pricing for Key Protect on Satellite](https://cloud.ibm.com/docs/key-protect?topic=key-protect-pricing-plan-satellite). If you do not see the key quota section, the service plan, or the HSM fields, check with your service representative to make sure you have been added to the allowlist.
7. In the Configure your resource section:



* Give the service a Name. While not necessary, it is a best practice to choose a name relevant to the usage you plan for the service.
* Select a Resource group. By default the Default resource group will be chosen.
* (Optional) Give the service a Tag (for example, test) or an Access management tag, which can help categorize the service.



8. Configure the HSMs the service will connect to. Note that you must configure two HSMs. To configure these HSMs, provide the HSM information you should have gathered [before you begin](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-ui-deploysatellite-ui-deploy-before-begin).
9. After you have checked and double checked your HSM configuration information, click Create to provision Key Protect. Note that the process of creating the database for the service can take more than an hour.







 Using the Key Protect service 

Now that Key Protect on Satellite has been successfully deployed, you're ready to use Key Protect to encrypt your data at rest, which you can do using the the Key Protect endpoint through the APIs.



* For information about how envelope encryption works, check out [Protecting data with envelope encryption](https://cloud.ibm.com/docs/key-protect?topic=key-protect-envelope-encryption).
* To learn how to create root keys, check out [Creating root keys](https://cloud.ibm.com/docs/key-protect?topic=key-protect-create-root-keys).
(https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-security) Secure your workloads and data. Integrate tools into your toolchains that satisfy your security and compliance requirements. To learn more about securing your cloud apps, see [Security to safeguard and monitor your cloud apps](https://www.ibm.com/cloud/garage/architectures/securityArchitecture). To learn more about securing your data while you are using the Continuous Delivery service, see [Securing your data](https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-cd_data_security). To learn more about regulatory compliance with the Continuous Delivery service, see [Understanding tool integrations with IBM Cloud for Financial Services](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-integrations). 







 Disaster recovery 

Disaster recovery includes tasks such as providing dependencies on disaster recovery sites, provision disaster recovery environments, data and configuration backup, replicating data and configuration to the disaster recovery environment, and failover on disaster events.

IBM is responsible for maintaining backups and high availability of the Continuous Delivery service in each supported region. However, because Continuous Delivery toolchains are region-dependent, automated global failover is not supported. If a regional disaster occurs, the recovery time for toolchains depends on the recovery time for the region. You can implement manual failover to another region by creating and maintaining copies of your toolchains and Git repos that have idle pipelines, in another IBM Cloud region.



Table 5. Responsibilities for disaster recovery

 Task IBM responsibilities Your responsibilities 

 Back up toolchain data. Maintain regular backups of toolchain and pipeline definitions, Git repos, and any other toolchain integration data that is stored and managed by IBM. To support global failover, create and maintain alternative toolchain and pipeline definitions, including tool integration data and your Git repos, in another IBM region. 
 Restore toolchain data. Restore all toolchain and Git repos to the original IBM Cloud region, when that region is available.
* Recovery functions, if used, can be accessed only by authorized personnel.





 Setting up Hyper Protect Crypto Services 



* Provision and configure an instance of Hyper Protect Crypto Services. See [Getting started with Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started) for specific instructions.



For the highest level of security, you should use smart cards when initializing Hyper Protect Crypto Services. See [Initializing service instances by using smart cards and the Management Utilities](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-initialize-hsm-management-utilities) for more details.

For more background information and considerations, see:



* [Components and concepts](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-understand-concepts)
* [Bringing your encryption keys to the cloud](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-importing-keys)
* [Master key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-master-key-rotation-intro)
* [Root key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-root-key-rotation-intro)









 Data encryption at rest in Satellite location 

You are responsible for providing the underlying virtual and physical storage that will be accessed by Satellite storage in your on-premises Satellite location. You should ensure your underlying physical storage is encrypted using keys managed by an on-premises FIPS 140-2 level 2 or higher hardware security module (HSM).





 Integrating Hyper Protect Crypto Services with other IBM Cloud services 

You must integrate Hyper Protect Crypto Services with the IBM Cloud services that are part of your reference architecture deployments. Block Storage for VPC and Object Storage can be the most obvious services that need to have data encrypted at rest. But, other services have data that needs to be encrypted as well.
You must also have deployed [a IBM Cloud Databases (ICD) that uses PostgreSQL](https://cloud.ibm.com/docs/cloud-databases?topic=cloud-databases-satellite-on-prem) service in your Satellite location, which is used by Key Protect to manage your keys. After your ICD for PostgreSQL instance has deployed, you need to share [several values about your ICD instance](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-before-begin-postgresql) with your service representative.

The best practice is for Key Protect to be deployed into an infrastructure containing at least three nodes with 8 vCPU and 32Gi of memory per node. These VM capacity numbers represent the aggregate capacity of all the micro-services that Key Protect requires to run on your infrastructure. This aggregate capacity does not include what is needed for the two HSMs that you will manage. Additionally, [two HSMs will need to be deployed and accessible](https://cloud.ibm.com/docs/key-protect?topic=key-protect-satellite-aboutsatellite-about-HSM). This infrastructure must be ready and accessible by Satellite before Key Protect can be provisioned. This infrastructure continue to be the responsibility of the account owner, including the continuous management and maintenance of this infrastructure.

After you have created a Satellite location, an IBM Cloud Activity Tracker instance (in IBM Cloud) and have installed PostgreSQL ICD in your Satellite location, and have deployed the rest of the prerequisite infrastructure (including your HSMs), you are ready to create Key Protect in your Satellite location.



 Limitations and scope 

The first release of the Key Protect on Satellite provides the basic functions to allow for secure handling of the encryption keys for the key services available in Satellite, such as IBM Cloud Public (ROKS) and Cloud Object Storage (COS).



* At present, the only locations supported in this offering are in user-owned on-prem Satellite locations associated with the IBM Cloud us-east host Multi-Zone Region (MZR), though eventually it will be available in Satellite locations associated with all IBM Cloud MZRs that Satellite supports.
Securing your data in Block Storage for Classic 

To ensure that you can securely manage your data when you use Block Storage for Classic, it's important to know exactly what data is stored and encrypted and how you can delete personal data.



 How your data is stored and encrypted in Block Storage for Classic 

IBM Cloud® Block Storage for Classic that is provisioned with either Endurance or Performance option is secured with provider-managed encryption, at no extra cost and no impact to performance.

The provider-managed encryption-at-rest feature uses the following industry standard protocols:



* Industry-Standard AES-256 encryption.
* Keys are managed in-house with industry standard Key Management Interoperability Protocol (KMIP).
* Storage is validated for US Federal Information Processing Standard (FIPS) Publication 140-2, Federal Information Security Management Act (FISMA), Health Insurance Portability and Accountability Act (HIPAA). Storage is also validated for Payment Card Industry (PCI), Basel II, California Security Breach Information Act (SB 1386), and EU General Data Protection Regulation (GDPR) compliance.







 Securing your snapshots or replicated storage 

All snapshots and replicas of encrypted file storage are also encrypted by default. This feature can’t be turned off on a volume basis. All cluster-to-cluster traffic is encrypted with TLS.





 Provisioning Storage with Encryption 

The provider-managed encryption-at-rest feature is available for Block Storage for Classic in all IBM Cloud® [data centers](https://cloud.ibm.com/docs/BlockStorage?topic=BlockStorage-selectDC).

When you order Block Storage for Classic, select a data center noted with an asterisk (). You can see a lock icon to the right of the LUN/Volume Name field that indicates that the volume is encrypted.

Zoom

![Figure 1. Example of the lock icon that indicates that the LUN is encrypted.]
* Message Integrity: Enables authentication of inbound traffic on a per-message basis, as well as strict restrictions on which queues those messages can be sent to and which recipients can receive them.
* Message Privacy: Based on the protection policy set on the target queue, AMS encrypts the message even before it is placed on the queue, thus ensuring that its contents are never exposed.



Demonstration of end to end message security involves demonstrating message integrity and message privacy. We start by demonstrating message integrity, where we can see that non-authorized users are not allowed to access the protected queue. We then check if the authorized users, from our example, alice and bob can send and receive messages on protected queue. We conclude by demonstrating that messages while at rest in the protected queue are encrypted and not readable.



 Message Integrity Check 

To demonstrate that message integrity is protected, any attempt to access the protected queue without complying to the signing or encryption policy shall fail. To test this, we run the sender program without setting the environment variable MQS_KEYSTORE_CONF. By doing so, AMS will fail to find the keystore and certificate to use for signing.
You can observe that alice is able to establish connection with the queue manager, but an attempt to open the protected queue will fail as this is the point where the AMS interceptor would check the identity for user alice.



1. Create the following environment variables in alice's command shell.

On Mac:
export MQSAMP_USER_ID=alice
export MQSERVER="CLOUD.ADMIN.SVRCONN/TCP/<HOSTNAME>(<PORT>)"

On Linux:
export MQSAMP_USER_ID=alice
export MQSERVER="CLOUD.ADMIN.SVRCONN/TCP/<HOSTNAME>(<PORT>)"

On Windows:
set MQSAMP_USER_ID=alice
set MQSERVER=CLOUD.ADMIN.SVRCONN/TCP/<HOSTNAME>(<PORT>)



* <HOSTNAME> - this is 'hostname' in the file connection_info.txt
PL-1 - Security Planning Policy and Procedures 



  Control requirements 

The organization:

PL-1 (a)
:   Develops, documents, and disseminates to [Assignment: organization-defined personnel or roles]:



1.  A security planning policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2.  Procedures to facilitate the implementation of the security planning policy and associated security planning controls; and



PL-1 (b)
:   Reviews and updates the current:



1.  Security planning policy [IBM Assignment: at least annually]; and
2.  Security planning procedures [IBM Assignment: at least annually].







  NIST supplemental guidance 

This control addresses the establishment of policy and procedures for the effective implementation of selected security controls and control enhancements in the PL family. Policy and procedures reflect applicable federal laws, Executive Orders, directives, regulations, policies, standards, and guidance. Security program policies and procedures at the organization level may make the need for system-specific policies and procedures unnecessary. The policy can be included as part of the general information security policy for organizations or conversely, can be represented by multiple policies reflecting the complex nature of certain organizations. The procedures can be established for the security program in general and for particular information systems, if needed. The organizational risk management strategy is a key factor in establishing policy and procedures.
As you plan and develop your app, consider the following options to maintain a secure image, ensure that sensitive information is encrypted, encrypt traffic between app microservices, and control traffic between your app pods and other pods and services in the cluster.

Image security
: To protect your app, you must protect the image and establish checks to ensure the image's integrity. Review the [image and registry security topic](https://cloud.ibm.com/docs/containers?topic=containers-securityimages_registry) for steps that you can take to ensure secure container images. For example, you might use Vulnerability Advisor to check the security status of container images. When you add an image to your organization's IBM Cloud Container Registry namespace, the image is automatically scanned by Vulnerability Advisor to detect security issues and potential vulnerabilities. If security issues are found, instructions are provided to help fix the reported vulnerability. To get started, see [Managing image security with Vulnerability Advisor](https://cloud.ibm.com/docs/Registry?topic=Registry-va_index).

Kubernetes secrets
: When you deploy your app, don't store confidential information, such as credentials or keys, in the YAML configuration file, configmaps, or scripts. Instead, use [Kubernetes secrets](https://cloud.ibm.com/docs/containers?topic=containers-securitypi), such as an image pull secret for registry credentials. You can then reference these secrets in your deployment YAML file.

Secret encryption
: You can encrypt the Kubernetes secrets that you create in your cluster by using a key management service (KMS) provider. To get started, see [Encrypt secrets by using a KMS provider](https://cloud.ibm.com/docs/containers?topic=containers-encryptionkeyprotect) and [Verify that secrets are encrypted](https://cloud.ibm.com/docs/containers?topic=containers-encryptionverify_kms).

Microservice traffic encryption
If you plan to use teaming to increase the availability of your network access to the storage array, you must turn off port security on the switch for the two ports on which the virtual IP address is shared. The purpose of this port security setting is to prevent spoofing of IP addresses. Thus, many network administrators enable this setting. If you do not change it, the port security setting prevents failover of the virtual IP from one switch port to another, and teaming cannot fail over from one path to another. For most LAN switches, the port security is enabled on a port level and thus can be set on or off for each port.
Intel Software Guard Extension 

Intel® Software Guard Extension (SGX) is an architecture extension that is designed to increase security by using protected areas in memory that runs your sensitive code and data. For more information, see [Intel® Software Guard Extensions](https://software.intel.com/en-us/sgx).

To provision a bare metal server with Intel SGX, see [Provisioning a bare metal server with Intel SGX](https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-server-provision-sgxbm-server-provision-sgx).
[Securing your data](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitydata-security)



* [What information is stored with IBM when using Satellite?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-sensitive-data)



* [Stored information when you create a Satellite location](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-sensitive-data-default)
* [Stored information from resources that you create in Satellite](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-sensitive-data-user-added)



* [How is my information stored, backed up, and encrypted when using Satellite?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-data-encryption)
* [Where can I find information about the data that my managed services store?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitymanaged-services-data)
* [Which IBM Cloud region is my information stored in?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat_data-location)
* [How can I remove my information?](https://cloud.ibm.com/docs/satellite?topic=satellite-data-securitysat-data-removal)









 API reference 

[API reference](https://containers.cloud.ibm.com/global/swagger-global-api//satellite-cluster)





 CLI plug-in reference 

[IBM Cloud Satellite CLI map](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map)



* [ibmcloud sat cluster](https://cloud.ibm.com/docs/satellite?topic=satellite-icsat_mapicsat_map_cluster)