vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information, see [Enabling HIPAA support for your account](https://cloud.ibm.com/docs/account?topic=account-enabling-hipaa).

To learn more about service terms and data security, read the following information:



* [Service terms](https://www-03.ibm.com/software/sla/sladb.nsf/sla/saas?OpenDocument) (Search for the Watson Assistant offering)
* [Data Processing and Protection Datasheet](https://www.ibm.com/software/reports/compatibility/clarity-reports/report/html/softwareReqsForProduct?deliverableId=DF7F84500FA711E69DCADF455C6AF151)
* [Information security](https://cloud.ibm.com/docs/assistant?topic=assistant-information-security)
* [IBM Cloud Data security and privacy](https://www.ibm.com/software/sla/sladb.nsf/sla/csdsp?OpenDocument)







 Next steps 



* [Get started](https://cloud.ibm.com/docs/assistant?topic=assistant-getting-started) with the product.



Have questions? Contact [IBM Sales](https://www.ibm.com/account/reg/us-en/signup?formid=urx-20970).
A unique, human-readable name for easy identification of your key.<br><br>Important: To protect your privacy, do not store your personal data as metadata for your key. 
 alias_list Optional. One or more unique, human-readable aliases assigned to your key.<br><br>Important: To protect your privacy, do not store your personal data as metadata for your key.<br><br>Each alias must be alphanumeric, case-sensitive, and cannot contain spaces or special characters other than dashes (-) or underscores (_). The alias cannot be a version 4 UUID and must not be a Hyper Protect Crypto Services reserved name: allowed_ip, key, keys, metadata, policy, policies, registration, registrations, ring, rings, rotate, wrap, unwrap, rewrap, version, versions. Alias size can be 2 - 90 characters (inclusive). 
 key_description Optional: An extended description of your key.<br><br>Important: To protect your privacy, do not store your personal data as metadata for your key. 
 YYYY-MM-DD<br><br>HH:MM:SS.SS Optional: The date and time that the key expires in the system, in RFC 3339 format. If the expirationDate attribute is omitted, the key does not expire. 
 key_type A boolean value that determines whether the key material can leave the service.<br><br>When you set the extractable attribute to false, the service creates a root key that you can use for wrap or unwrap operations. 



To protect the confidentiality of your personal data, avoid entering personally identifiable information (PII), such as your name or location, when you add keys to the service. For more examples of PII, see section 2.2 of the [NIST Special Publication 800-122](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-122.pdf).

If you set the expirationDate in your request, the key is moved to the deactivated state within 1 hour past the key's expiration date.
1. [Log in to the IBM Cloud console](https://cloud.ibm.com/).
2. Go to Menu > Resource list to view a list of your resources.
3. From your IBM Cloud resource list, select your provisioned instance of Hyper Protect Crypto Services.
4. In the UI of the selected service instance, select the Instance policies tab in the side menu.
5. In the Dual authorization deletion section, check the box for Require two users to approve key deletions, and click Save policy.







 Enabling dual authorization for your service instance with the API 

As an instance manager, enable a dual authorization policy for a Hyper Protect Crypto Services instance by making a PUT call to the following endpoint.

https://api.<region>.hs-crypto.cloud.ibm.com:<port>/api/v2/instance/policies?policy=dualAuthDelete



1. [Retrieve your authentication credentials to work with the API](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-up-kms-api).

To enable and disable dual authorization policy, you must be assigned a Manager access policy for your service instance. To learn how IAM roles map to Hyper Protect Crypto Services service actions, check out [Service access roles](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-manage-accessservice-access-roles).
2. Enable a dual authorization policy for your service instance by running the following cURL command.
For more information about service ID keys, see [Managing service ID API keys](https://cloud.ibm.com/docs/account?topic=account-serviceidapikeys).







 API key best practices 

Keep your API keys secure to reduce the chance of publicly exposing credentials that compromise your account and applications. To help keep your API keys secure, follow these guidelines.



* Assign the most restrictive service role that works for the level of access you need.

For example, assign the Reader service role for calls from your application to GET API methods. This role has only read-only access, so can't create or edit resources.
* Don't embed the API key directly in code.

API keys that are embedded in code might be exposed to your users. Instead of embedding the API keys in code, store them either in environment variables or in files outside your source code control system.
* Don't store an API key in files inside your application's source code control system.

If you store API keys in files, keep the files outside of your application's source code. This practice is important if you use a public source code management system such as GitHub.
* Regenerate or rotate your API keys.

Create new keys periodically, or rotate your keys. And don't forget to delete keys that you no longer use.







 Next steps 



* Read an overview of [IBM Cloud IAM](https://cloud.ibm.com/docs/account?topic=account-iamoverview)
* Learn about [managing access](https://cloud.ibm.com/docs/account?topic=account-cloudaccess) in IBM Cloud
* Dive into [policies, user roles, and permissions](https://cloud.ibm.com/docs/account?topic=account-userroles)
* See how to [pass API keys and tokens](https://cloud.ibm.com/docs/account?topic=account-iamapikeysforservices)
For more information, see [Connect to a Datastore in Data Security Broker Manager](https://cloud.ibm.com/docs/security-broker?topic=security-broker-sb_add_db).
3. Enroll an Application in Data Security Broker Manager. For more information, see [Enrolling an application in Data Security Broker Manager](https://cloud.ibm.com/docs/security-broker?topic=security-broker-sb_enroll_app).
4. Assign and customize a Default Data Protection Policy. For more information, see [Create, assign, and Customize Data Protection Policy in Data Security Broker Manager](https://cloud.ibm.com/docs/security-broker?topic=security-broker-sb_assign_policy).
5. Encrypt and Decrypt Data. For more information, see [Encrypting the data with Data Security Broker on an IBM Cloud PostgreSQL Database](https://cloud.ibm.com/docs/security-broker?topic=security-broker-sb_encrypt_data).
Assign a floating IP address to the Hyper Protect Virtual Server for VPC instance and click Save.
9. To open the PayNow website, copy and paste the floating IP address and use your browser to open the PayNow website under the URL https://<floatingip>:8443/index.html.



Now, by using Confidential Computing with IBM Cloud Hyper Protect Virtual Server for VPC, you can ensure that you have a level of data security that is unmatched in the industry.







 Next steps 

Check out the [demo video](https://mediacenter.ibm.com/media/IBM+Cloud+Show+Me-+Hyper+Protect+Services+for+Confidential+Computing+Demo/1_f7e970ig) that demonstrates the data protection that is provided by Confidential Computing by comparision between two servers:



* One without Confidential Computing, where a malicious root user can dump contents of the server memory that's not protected to steal PII and credit card data.
* One with Confidential Computing, where even the root user can’t access the server memory as it's protected by the Hyper Protect platform.
The HIPAA Enabled label on a service can apply to all available plans or be limited to specific plans or configurations. You as the client are solely responsible for limiting PHI to HIPAA Enabled product plans and architecting in accordance with HIPAA and HITECH.



1. In the IBM Cloud console, go to Manage > Account, and select Account setting in the console.
2. For the HIPAA Supported option, click On.
3. Read the information about enabling this setting.

You can't disable the setting after you enable it.
4. Select Accept, and click Submit.



After you enable the HIPAA Supported setting, you can use the HIPAA Enabled filter to find products that are HIPAA enabled. In the IBM Cloud catalog, expand the Compliance section and select HIPAA Enabled.
: You can set a key creation and importation policy, in the [user interface (UI)](https://cloud.ibm.com/login/), to restrict how keys are created and imported into your Key Protect service instance. See the updated "Instance policies" pane in the Key Protect UI.







 September 2020 



 17 September 2020 

Key Protect adds access policy API support
: You can set a key creation and importation policy, using the [API](https://cloud.ibm.com/apidocs/key-protect), to restrict how keys are created and imported into your Key Protect service instance. To find out more, see [Managing a key create and import access policy](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-keyCreateImportAccess).





 22 September 2020 

Updates to the Key Protect UI
: The Key Protect UI now has support for the following feature:



* List keys by key state: You can now use the Key Protect UI to filter and retrieve keys that are in a specified state. For more information, see [Viewing keys in the console](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keysfilter-key-state-gui).
* If you have Manager access permissions, you can filter for keys in the Destroyed state and restore an imported root key via the ⋯ icon on the Keys table. Note: you must include the original Key Material to restore the key.







 09 September 2020 

Announcing Key Protect CLI plug-in v.0.5.2
: The Key Protect CLI plug-in version 0.5.2 was updated with these changes:



* Commands that specify JSON outout (--output json) now return an empty JSON structure if there is no output. The [CLI changelog](https://cloud.ibm.com/docs/key-protect?topic=key-protect-cli-changelog) has all CLI updates.









 July 2020 



 21 July 2020 

Announcing Key Protect CLI plug-in v.0.5.1
To avoid assigning access policies to individual users, consider creating [IAM access groups](https://cloud.ibm.com/docs/account?topic=account-groups).







 How can you protect the access to actions and its data? 

As the account owner or an authorized account administrator, you can assign IAM service access roles to your users. The IAM service access roles determine the actions that you can set on an IBM Cloud Schematics resource, such as a workspace or an action. To avoid assigning access policies to individual users, consider creating [IAM access groups](https://cloud.ibm.com/docs/account?topic=account-groups).

Your workspaces and actions data store depends on the location where you create your workspace or an action. For more information, see [securing your data in Schematics](https://cloud.ibm.com/docs/schematics?topic=schematics-secure-data).





 How does Schematics protect the action data through input credentials state file, or log files? 

Follow these practices to protect your workspace data through input credentials state file, or log files.



* Use Cloud Identity and Access Management to control access to a Schematics action.
* Secure the source repository of your Terraform template, including access control, security settings, collaboration, and version control.
* Use the provided tools of your IBM Cloud resources to apply security fixes, access controls, and encryption to your resources.
* You need to specify the right [roles and permissions](https://cloud.ibm.com/docs/schematics?topic=schematics-accessaccess-setup) to a user who controls the state file. For more information about Schematics service access roles and permissions for
* [Action permissions](https://cloud.ibm.com/docs/schematics?topic=schematics-accessaction-permissions)
* [KMS permissions](https://cloud.ibm.com/docs/schematics?topic=schematics-accesskms-permissions)









 Protecting data of Schematics
Use OpenSSL to create a private key, where <user> is the name for your key's identity:

openssl genrsa --out <user>Private.pem
3. Create a public key:

openssl rsa -in <user>Private.pem -pubout -out <user>Pub.pem

To use the private key in production, you must safely store and protect the private key in a suitable store. You might also want to manage the public key in the same way. For more information, see [Storing keys](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_encryptregistry_encrypt_keys).
4. List the keys to ensure that they are created:

ls -l
5. To use this key pair to encrypt images, display the public key by running the following cat command:

cat <user>Pub.pem

You get a response similar to the following output:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv8Ny7dCWQ8Pdq1ddYSwk
QOCB3lUEZVEyj9StX3jnISF/rxIsUZzJfbOrQN0fGkm+1sCCtltgQdztTjito8Fh
DGflqQBSmV40XP3iZnNUJDrHuAol463Z/BuxxFXL3ry6rTosLGfrRwdQjxp8RSsn
WyIIO2rmcqXZYe4SCtiMjMejLlTIDWLIMdYL3d6hA4DpgDLoh6EPmhKMVVwRt5b0
ew5eMLcDuq6ButOM5yv4zYVHNrajY41NK+abSlFb6wzMg2AUDiC/MxV1LRq6mpyZ
<br><br> * Configure streaming of IBM Cloud Activity Tracker (optional)<br><br><br> You can stream data from an IBM Cloud Activity Tracker instance to another IBM Cloud Activity Tracker instance across regions or to other corporate tools such as Security Information and Event Management (SIEM) tools. Learn more about [streaming data](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-streaming). 
 <br><br> * Secure your resources with context-based restrictions<br><br><br> Context-based restrictions give account owners and administrators the ability to define and enforce access restrictions for IBM Cloud resources based on the network location of access requests. These restrictions work with traditional IAM policies, which are based on identity, to provide an extra layer of protection. Since both IAM access and context-based restrictions enforce access, context-based restrictions offer protection even in the face of compromised or mismanaged credentials.<br><br>Learn more about [what context-based restrictions are](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis) and follow the guide to [secure your resources using context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-tutorial). 
 <br><br> * Encrypt and protect your data<br><br><br> You can choose from various secrets management and data protection products that help you to protect your sensitive data and centralize your secrets. Review [Which data protection service is best for me?](https://cloud.ibm.com/docs/secrets-manager?topic=secrets-manager-manage-secrets-ibm-cloudwhich-data-protection-service) to better understand the different offerings that you can use with IBM Cloud to protect your application secrets.
4. Click Add.
5. Make note of the credentials. You will need them in a later step.



3. Click Endpoints from the menu:



1. Set Resiliency to Regional and set the Location to the target location:
2. For Classic infrastructure: Copy the Private service endpoint. It will be used later in the configuration of the application.
3. For VPC infrastructure: Copy the Direct service endpoint. It will be used later in the configuration of the application.





Before creating the bucket, you will grant the Object Storage service instance access to the root key stored in the Key Protect service instance.



1. Go to [Manage > Access (IAM) > Authorizations](https://cloud.ibm.com/iam/authorizations) in the IBM Cloud console.
2. Click the Create button.
3. In the Source service menu, select Cloud Object Storage.
4. Switch to Resources based on selected attributes, check Source service instance and select the Object Storage service instance previously created.
5. In the Target service menu, select Key Protect.
6. Switch to Resources based on selected attributes, check Instance ID, select the Key Protect service instance created earlier.
7. Enable the Reader role.
8. Click the Authorize button.



Finally create the bucket.



1. Access the Object Storage service instance from the [Resource List](https://cloud.ibm.com/resources) Under Storage.
2. Click Create bucket and then Customize your bucket.



1. Set the name to a unique value, such as <your-initials>-secure-file-upload.
2. Set Resiliency to Regional.
3. Set Location to the same location where you created the Key Protect service instance.
4. Set Storage class to Standard



3. Under Service integrations (optional) / Encryption, enable Key management



1. Select the Key Protect service instance created earlier by clicking on Use existing instance
2.
[Decide if you want to store the Key Protect root key CRN in a customized storage class or in a Kubernetes secret](https://cloud.ibm.com/docs/containers?topic=containers-vpc-blockvpc-customize-default). Then, follow the steps to create a customized storage class or a Kubernetes secret.

Example customized storage class.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: <storage_class_name> Enter a name for your storage class.
provisioner: vpc.block.csi.ibm.io
parameters:
profile: "5iops-tier"
csi.storage.k8s.io/fstype: "ext4"
billingType: "hourly"
encrypted: "true"
encryptionKey: "<encryption_key>"
resourceGroup: ""
zone: ""
tags: ""
generation: "gc"
classVersion: "1"
reclaimPolicy: "Delete"
Show more

encrypted
: In the parameters, enter true to create a storage class that sets up encryption for your Block Storage for Classic volumes. If you set this option to true, you must provide the root key CRN of your Key Protect service instance that you want to use in parameters.encryptionKey.

encryptionKey
: In the parameters, enter the root key CRN that you retrieved earlier.

Example Kubernetes secret.

apiVersion: v1
kind: Secret
type: vpc.block.csi.ibm.io
metadata:
name: <secret_name>
namespace: <namespace_name>
stringData:
encrypted: <true_or_false>
data
encryptionKey: <encryption_key>

name
: Enter a name for your secret.

namespace
: Enter the namespace where you want to create your secret.

encrypted
: In the parameters, enter true to set up encryption for your Block Storage for Classic volumes.

encryptionKey
To protect your app, you must protect the image and establish checks to ensure the image's integrity.

Should I use a public or a private registry to store my images?
: Public registries, such as Docker Hub, can be used to get started with Docker images and Kubernetes to create your first containerized app in a cluster. But when it comes to enterprise applications, avoid registries that you don't know or don't trust to protect your cluster from malicious images. Keep your images in a private registry, like the one provided in IBM Cloud Container Registry or the [internal registry](https://docs.openshift.com/container-platform/4.11/registry/index.html) that is automatically set up in your Red Hat OpenShift cluster, and make sure to control access to the registry and the image content that can be pushed.

Why is it important to check images against vulnerabilities?
: Research shows that most malicious attacks leverage known software vulnerabilities and weak system configurations. When you deploy a container from an image, the container spins up with the OS and extra binaries that you described in the image. Just like you protect your virtual or physical machine, you must eliminate known vulnerabilities in the OS and binaries that you use inside the container to protect your app from being accessed by unauthorized users.

To protect your apps, consider to address the following areas:



1. Automate the build process and limit permissions: Automate the process to build your container image from your source code to eliminate source code variations and defects. By integrating the build process into your CI/CD pipeline, you can ensure that your image is scanned and built only if the image passes the security checks that you specified. To avoid that developers apply hot fixes to sensitive images, limit the number of people in your organization who have access to the build process.
2. Scan images before they deploy into production: Make sure to scan every image before you deploy a container from it. For example, if you use IBM Cloud Container Registry, all images are automatically scanned for vulnerabilities when you push the image to your namespace. If vulnerabilities are found, consider eliminating the vulnerabilities or block deployment for those images.
However, you can use Calico policies to block incoming traffic to your services based on traffic source or destination.

Default Kubernetes and Calico policies are difficult to apply to protect Kubernetes NodePort and LoadBalancer services due to the DNAT Iptables rules generated for these services. However, pre-DNAT policies prevent specified traffic from reaching your apps because they generate and apply Iptables rules before Kubernetes uses regular DNAT to forward traffic to pods.

Some common uses for Calico pre-DNAT network policies:



* Block traffic to public node ports of a private network load balancer (NLB) service: An NLB service makes your app available over the NLB IP address and port and makes your app available over the service's node ports. Node ports are accessible on every IP address (public and private) for every node within the cluster.
* Block traffic to public node ports on clusters that are running [edge worker nodes](https://cloud.ibm.com/docs/containers?topic=containers-edgeedge): Blocking node ports ensures that the edge worker nodes are the only worker nodes that handle incoming traffic.
* Block traffic from certain source IP addresses or CIDRs
* Allow traffic from only certain source IP addresses or CIDRs, and block all other traffic



To see how to allow or block source IP addresses, try the [Using Calico network policies to block traffic tutorial](https://cloud.ibm.com/docs/containers?topic=containers-policy_tutorialpolicy_tutorial).





 Example Calico policies to restrict public or private network traffic 

We provide a set of example [Calico public network policies](https://github.com/IBM-Cloud/kube-samples/tree/master/calico-policies/public-network-isolation) that further restrict public/private network traffic on cluster workers. These policies allow the traffic that is necessary for the cluster to function, and block certain other traffic.

These policies are not meant to block everything, nor do they necessarily meet any compliance requirements on their own. They are intended as a starting point and must be edited to meet your unique use cases.