vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Encrypting data with your own keys 

IBM Cloud® encrypts all data in transit and at rest. Additionally, you can configure IBM Cloud services to encrypt your data at rest with your own keys, and then monitor the events around the lifecycle of the encryption keys with IBM Cloud® Activity Tracker.

IBM Cloud supports multiple encryption options, whether you're looking for a solution that supports the bring your own key (BYOK) or keep your own key (KYOK) functionality. For an in-depth look at the options to secure your data depending on your organization's needs, see [Data security](https://www.ibm.com/cloud/architecture/architectures/data-security-arch).



 Bring your own keys 

Many IBM Cloud services support data encryption by using customer-managed keys, also known as bring your own key (BYOK). The most common use case for BYOK is using IBM® Key Protect to [bring your encryption keys to the cloud](https://cloud.ibm.com/docs/key-protect?topic=key-protect-importing-keys). Key Protect is a multi-tenant service using FIPS 140-2 Level 3 HSM. For a list of services that can be integrated with Key Protect, see [Integrating services](https://cloud.ibm.com/docs/key-protect?topic=key-protect-integrate-services).





 Keep your own keys 

IBM Cloud also provides IBM Cloud Hyper Protect Crypto Services, which is a dedicated key management service and hardware security module (HSM). Hyper Protect Crypto Services features keep your own key (KYOK) encryption capabilities backed by FIPS 140-2 Level 4 certification. With this option, it makes the IBM public cloud the industry's most secure and open public cloud for business. For a list of services that can be integrated with Hyper Protect Crypto Services, see [Integrating IBM Cloud services with Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-integrate-services).





 Auditing the lifecycle of your keys 

You can use Activity Tracker to monitor the activity of your keys.
All three should be reviewed before commencing:



* [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosure)
* [Configure NAT for Internet access from a secure network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-nat-config-private)
* [Use Virtual Servers to build highly available and scalable web app](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-highly-available-and-scalable-web-application)







 Step 1: Configure secure private network 

Isolated and secure private network environments are central to the IaaS application security model on public cloud. Firewalls, VLANs, routing, and VPNs are all necessary components in the creation of isolated private environments. The first step is to create the secure private network enclosure within which the web app will be deployed.



* [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosure)



This tutorial can be followed without change. In a later step three virtual machines will be deployed in the APP zone as Nginx web servers and a MySQL database.





 Step 2: Configure NAT for secure application deployment 

Installation of open-source applications requires secure access to the Internet to access the source repositories. To protect the servers in the secure private network from being exposed on the public Internet, Source NAT is used where the source address is obfuscated and firewall rules are used to secure the out-bound application repository requests. All inbound requests are denied.



* [Configure NAT for Internet access from a secure network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-nat-config-private)



This tutorial can be followed without change.
An answer or annotation that is actually incorrect and is predicted to be incorrect.





 true positive 

An answer or annotation that is actually correct and is predicted to be correct.





 trusted profile 

A grouping of federated users, compute resources, or both, that are granted the same IAM access. When an identity applies a trusted profile, temporary security credentials are provided for the duration of a session. All identities that are allowed to apply a single profile inherit the same access.





 trusted root 

A certificate signed by a trusted certificate authority (CA). See also [intermediate certificate](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx3753781), [certificate authority](https://cloud.ibm.com/docs/overview?topic=overview-glossaryx2016383).





 type system 

The set of objects that may be discovered by a text analysis engine in a document. The type system defines all possible feature structures in terms of types and features. Any number of different types can be defined in a type system. A type system is domain and application specific.







 U 



 Uniform Resource Identifier (URI) 

A unique address that is used to identify content on the web. The most common form of URI is the web page address, which is a particular form or subset of URI called a Uniform Resource Locator (URL). A URI typically describes how to access the resource, the computer that contains the resource, and the location of the resource on that computer.





 Uniform Resource Locator (URL) 

The unique address of an information resource that is accessible in a network such as the Internet. The URL includes the abbreviated name of the protocol used to access the information resource and the information used by the protocol to locate the information resource.
Some APIs exist for setting individual objects to a public-read status, but this is discouraged in favor of [using IAM to allow unauthenticated access to an entire bucket](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-iam-public-access), and using these buckets to serve any open data.





 Data deletion 

IBM Cloud Object Storage data is erasure coded and distributed to multiple individual storage devices in multiple data centers. When data is deleted, various mechanisms exist which prevent recovery or reconstruction of the deleted objects. Deletion of an object undergoes various stages. First, the metadata is marked to indicate the object is deleted, then, the data is removed. Eventually, deleted metadata is overwritten by a process of compaction and the deleted data blocks are overwritten with new data in the course of normal operations. As soon as the metadata is marked deleted, it is not possible to read an object remotely. IBM's provider-managed encryption and erasure coding prevents data (both before and after deletion) from being accessible from within individual data centers.

Cross regional and regional resiliency buckets distribute information across multiple data centers. For single site resiliency, data is dispersed to the same number of storage devices but they are all located in the same data center.

Data can be made more secure by using one of several available methods to protect the encryption keys including SSE-C, Key Protect or Hyper Protect Crypto Services. Please visit the [manage encryption](https://cloud.ibm.com/docs/services/cloud-object-storage/basics?topic=cloud-object-storage-encryption) topic to learn more about the encryption methods.





 Tenant isolation 

IBM Cloud Object Storage is a multi-tenant Object Storage product. If your workload requires dedicated or isolated storage, see [IBM Cloud®](https://www.ibm.com/cloud/object-storage) for more information.
This high consumption of resources might affect other containers on the worker node that don't have enough resources to properly start or run, and puts your worker node at risk for denial-of-service attacks.







 Storing personal information 

You are responsible for ensuring the security of your personal information in Kubernetes resources and container images. Personal information includes your name, address, phone number, email address, or other information that might identify, contact, or locate you, your customers, or anyone else.

Use a Kubernetes secret to store personal information
: Store personal information only in Kubernetes resources that are designed to hold personal information. For example, don't use your name in the name of a Red Hat OpenShift project, deployment, service, or config map. For proper protection and encryption, store personal information in [secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead.
: For centralized management of all your secrets across clusters and injection at application runtime, try [IBM Cloud Secrets Manager](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-tutorial-kubernetes-secrets).

Use a Kubernetes imagePullSecret to store image registry credentials
: Do not store personal information in container images or registry namespaces. For proper protection and encryption, store registry credentials in [Kubernetes imagePullSecrets](https://cloud.ibm.com/docs/openshift?topic=openshift-registryother) and other personal information in [secrets](https://kubernetes.io/docs/concepts/configuration/secret/) instead. Remember that if personal information is stored in a previous layer of an image, deleting an image might not be sufficient to delete this personal information.





 Kubernetes security bulletins 

If vulnerabilities are found in Kubernetes, Kubernetes releases CVEs in security bulletins to inform users and to describe the actions that users must take to remediate the vulnerability.
Message data is encrypted for transmission between Event Streams and clients as a result of TLS. Event Streams stores message data at rest and message logs on encrypted disks.

Topic names and consumer groups are encrypted for transmission between Event Streams and clients as a result of TLS. However, Event Streams does not encrypt these values at rest. Therefore, do not use confidential information in your topic names.

On the Satellite plan, all encryption is determined by the options that you specify on your chosen storage provider.

For information about compliance on each of the Event Streams plans, see [What's supported by the Lite, Standard, Enterprise, and Satellite plans](https://cloud.ibm.com/docs/EventStreams?topic=EventStreams-plan_choosewhat_is_supported).





 Data isolation model 

Event Streams's data isolation model varies according to which plan you use.



 Enterprise plan 

The Enterprise plan provides a tenant-specific service in the IBM Service domain. The Enterprise plan creates a single tenant instance on a Dedicated Kubernetes cluster on Shared Hardware (VSI isolation). By default, the Enterprise plan provides Public endpoints, but it also supports Cloud Service Endpoints to enable Private Endpoints for further network isolation on request. The Enterprise plan creates single tenant Block Storage for each new instance.





 Satellite plan 

The Satellite plan provides a tenant-specific service in the IBM Service domain and is based on the Enterprise plan. The Satellite plan creates a single tenant instance on a Dedicated Kubernetes cluster by using hosts (physical and virtual) that you provided and attached to your Satellite location. The Satellite plan creates single tenant Block Storage for each new instance by using the Block Storage configuration that you specified for your storage provider.





 Standard plan 

The Standard plan provides a Public Service with Public endpoints. The Standard plan creates a tenant instance on a Shared Kubernetes cluster on shared hardware (VSI isolation). The Standard plan provides Public endpoints only.

The Standard plan uses Shared Block Storage and achieves tenant isolation through separation of files and access controls.







 Data retention and reclamation 

On all plans, except for Satellite, when a service instance is deleted, the data is not deleted immediately.
* Encryption of data at-rest controlled by your own key.
* Explicit control of the lifecycle of data stored at rest.



Customer-managed keys is available on the Standard plan only.

Deletion of the customer-managed key is non-recoverable and will result in the loss of any data stored in your Event Notifications instance.



 What is not covered by customer-managed encryption 

If customer-managed encryption feature is selected, the user should be aware that only customer data is covered by this encryption. Event Notifications encrypts at-rest other data related to the use of the service.

You are not recommended to use confidential information in client metadata.





 How customer-managed encryption works 

Event Notifications uses a concept called envelope encryption to implement customer-managed keys.

Envelope encryption is the practice of encrypting one encryption key with another encryption key. The key used to encrypt the actual data is known as a data encryption key (DEK). The DEK itself is never stored, but instead is wrapped by a second key known as the key encryption key (KEK) to create a wrapped DEK.

To decrypt data, the wrapped DEK must first be unwrapped to get the DEK. This process is possible only by accessing the KEK, which in this case is your root key stored in either [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-overview).

You own the KEK, which you create as a root key in the Hyper Protect Crypto Services or Key Protect service. The Event Notifications service never sees the root (KEK) key. Its storage, management, and use to wrap and unwrap the DEK is performed entirely within the key management service. If you disable or delete the key, the data can no longer be decrypted.





 Enabling a customer-managed key for Event Notifications 

Complete the following steps to provision your Event Notifications instance to use a customer-managed key:



1.
* Check whether Application Load Balancer for VPC has public access disabled
* Check whether OpenShift clusters are accessible only by using private endpoints
* Check whether Cloud Object Storage quota enforcement is off for buckets that are configured to use Activity Tracker Event Routing
* Check whether Virtual Private Cloud (VPC) security groups have inbound ports that are open only to permitted IP addresses
* Check whether Hyper Protect DBaaS for MongoDB is accessible only using private endpoints
* Check whether Event Streams is accessible only by using private endpoints
* Check whether Hyper Protect DBaaS for PostgreSQL is accessible only using private endpoints
* Check whether Virtual Private Cloud (VPC) has no public gateways attached
* Check whether Virtual Private Cloud (VPC) network access control lists don't allow ingress from 0.0.0.0/0 to any port
* Check whether all virtual server instances have at least one Virtual Private Cloud (VPC) security group attached
* Check whether Virtual Private Cloud (VPC) has no public gateways attached at the time of provisioning
* Check whether App ID redirect URIs are not using wildcards (*)
* Check whether at least # Virtual Private Cloud (VPC)s have been created
* Check whether Virtual Servers for VPC instance has all interfaces with IP-spoofing disabled
* Check whether at least # instances of Transit Gateway have been created
* Check whether Cloud Object Storage network access is restricted to a specific IP range
* Check whether account has at least one VPN or Direct Link configured
* Check whether Virtual Private Cloud (VPC) classic access is disabled
* Check whether Virtual Private Cloud (VPC) has no rules in the default security group
* Check whether all network interfaces of a virtual server instance have at least one Virtual Private Cloud (VPC) security group attached
* Check whether Container Registry image pushes and pulls take place only over private endpoints
* Check whether Virtual Servers for VPC instance has the minimum # interfaces
* Check whether Virtual Private Cloud (VPC) has no subnet with public gateway attached
* Check whether Hyper Protect Crypto Services is accessible only through private endpoints
* Check whether Virtual Private Cloud (VPC) security groups have outbound ports that are open only to permitted IP addresses
* Encryption of data at-rest controlled by your own key.
* Explicit control of the lifecycle of data stored at rest.



Customer-managed keys is available on the Enterprise plan only.

Deletion of the customer-managed key is non-recoverable and will result in the loss of any data stored in your App Configuration instance.



 What is not covered by customer-managed encryption 

If customer-managed encryption feature is selected, the user should be aware that only segment data is covered by this encryption. App Configuration encrypts at-rest other data related to the use of the service.

You are not recommended to use confidential information in client metadata.





 How customer-managed encryption works 

App Configuration uses a concept called envelope encryption to implement customer-managed keys.

Envelope encryption is the practice of encrypting one encryption key with another encryption key. The key used to encrypt the actual data is known as a data encryption key (DEK). The DEK itself is never stored, but instead is wrapped by a second key known as the key encryption key (KEK) to create a wrapped DEK.

To decrypt data, the wrapped DEK must first be unwrapped to get the DEK. This process is possible only by accessing the KEK, which in this case is your root key stored in either [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about) or [Hyper Protect Crypto Services](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-overview).

You own the KEK, which you create as a root key in the Hyper Protect Crypto Services or Key Protect service. The App Configuration service never sees the root (KEK) key. Its storage, management, and use to wrap and unwrap the DEK is performed entirely within the key management service. If you disable or delete the key, the data can no longer be decrypted.





 Enabling a customer-managed key for App Configuration 

Complete the following steps to provision your App Configuration instance to use a customer-managed key:



1.
In Key Protect, you can provision highly secure root keys, which serve as primary keys that you control in the service. When you create a bucket, you can configure envelope encryption for the bucket at its creation. This added protection wraps (or encrypts) the DEKs associated with the bucket by using a root key that you manage in Key Protect. The practice, called key wrapping, uses multiple AES algorithms to protect the privacy and the integrity of your DEKs, so only you control access to their associated data.

Hyper Protect Crypto Services is a single-tenant, dedicated HSM that is controlled by you. The service is built on FIPS 140-2 Level 4-certified hardware, the highest offered by any cloud provider in the industry.



If you need to use your own key to encrypt the data at-rest in a bucket, use the following table to help you identify the features that you should consider when you create a bucket:



Table 8. Use your own encryption key

 Requirement Storage class: Standard Storage class: Vault Storage class: Cold Vault Storage class: Flex 

 Type of workload Continuous access Data isn't accessed frequently Accessed every 90 days or less Dynamic workloads where access patterns are difficult to predict 
 Data resiliency Regional Regional Regional Regional 
 Retention policy [15] NO NO NO NO 
 Expiration policy ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/6f3c07c34058f637b1c86044ca4f9b24214330a7/activity-tracker/images/checkmark-icon.svg) !
By default, CKA_TOKEN is set to FALSE, which means the key object is stored in an in-memory keystore within the process address space of the PKCS #11 application.
* The CKA_PRIVATE attribute value decides whether a key that is generated by normal users is to be stored in a public or private keystore.

By default, if a user is logged in as a normal user, generated keys are stored in the private keystores, except for the case where CKA_PRIVATE is set to FALSE. If a user is logged in as an SO user or is not logged in (known as an anonymous user), then generated keys are always stored in the public keystores. If an SO user or an anonymous user specifies CKA_PRIVATE to TRUE in the key generation templates, an error is returned from the server.

For an asymmetric key pair, you need to set the CKA_PRIVATE attribute separately for both the public and private keys, which means the key pairs can be stored in different keystores.



Refer to the following table for detailed explanations of the relationship between user types, key attributes, and keystores, and how keys are stored.



Table 1. Cases of storing EP11 keys in different keystores

 User type CKA_TOKEN CKA_PRIVATE Keystore for keys Private or public? 

 SO user FALSE N/A In-memory keystore Public 
 SO user TRUE N/A Database-backed keystore Public 
 Anonymous user FALSE N/A In-memory keystore Public 
 Anonymous user TRUE N/A Database-backed keystore Public 
 Normal user FALSE FALSE In-memory keystore Public 
 Normal user FALSE TRUE In-memory keystore Private 
 Normal user TRUE FALSE Database-backed keystore Public 
 Normal user TRUE TRUE Database-backed keystore Private 









 Post-quantum cryptography support 

With the PKCS #11 API, you can also perform [post-quantum cryptographic](https://en.wikipedia.org/wiki/Post-quantum_cryptography) operations. Traditional cryptography relies on complicated mathematical problems that are difficult for classical computers to solve. However, with the computing capabilities, quantum computers can solve these problems. Post-quantum cryptography is considered to be resistant to cryptanalytic attacks from quantum computers.
Your IBM Cloud access token. Include the full contents of the IAM token, including the Bearer value, in the curl request. <br> <br>For more information, see [Retrieving an access token](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token). 
 instance_ID Required. The unique identifier that is assigned to your Key Protect service instance. <br> <br>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 



A successful GET api/v2/instance/allowed_ip_port response returns the private endpoint port that was assigned to your Key Protect instance upon creation of its associated allowed IP policy in the private_endpoint_port field. If the instance doesn't have an enabled allowed IP policy, no information will be returned.





 Sending traffic to your Key Protect instance through a private endpoint port 

When you retrieve the private endpoint port associated with your allowed IP policy, you should append it to the host name of the private service endpoint. For example, if the private endpoint port associated with your allowed IP policy is 8888, the endpoint that you will make a request through to list the keys in your Key Protect instance is https://private.us-south.kms.cloud.ibm.com:8888/api/v2/keys.

When making a request through a private network, the allowed IP policy will only consider the private network's gateway address, and not the IP address of the requester. Therefore, it is important that you add the IPv4 address associated with the private network gateway to your Key Protect instance's allowed IP policy.

You can use the following example request to retrieve a list of keys for your Key Protect instance via a private endpoint.