vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Assigning or changing a Default Data Protection Policy 



 Overview 

A Data Protection Policy consists of a combination of encryption modes and masking rules. Default Data Protection Policies allow you to apply default settings for encryption, Format Preserving Encryption (FPE), or Data Masking, A policy is applied to the columns of a data store associated with an application enrolled in Data Security Broker Manager and linked to a Data Security Broker Shield.

A list of Default Data Protection Policies is available in the Data Protection Library at the bottom of the left navigation bar. Click the carrot icon (\<) to expand and view the list of list Default Data Protection Policies, Encryption Modes, and Masking Modes.





 To assign or change a Default Data Protection Policy, do the following 



1. In Data Security Broker Manager, click the Application icon in the left menu bar.

Zoom

![Applications](https://cloud.ibm.com/docs-content/v1/content/57ab3ec034294d8a6de510b97bec3035d4654761/security-broker/images/add_app.svg)

Applications
2. Select an application from the list and click Encrypt.

Zoom

![Encrypt Data](https://cloud.ibm.com/docs-content/v1/content/57ab3ec034294d8a6de510b97bec3035d4654761/security-broker/images/encrypt.svg)

Encrypt Data
3. In the left navigation menu, navigate to a database and schema and select the table for which you want to assign or change a policy. The table appears on the right.
4. Click the checkbox for a column and then expand the Data Protection drop-down list. By default, CTR Policy is selected.

Zoom

!
Restricting SSH access on a public network 

SSH accessibility provides users with the ability to securely access a device though an internet connection. SSH is available on IBM Cloud® devices on both the public and private network. However, it's a good idea to restrict SSH accessibility over the public network unless it is necessary for a unique business need. By restricting SSH access on the public network, users can still access a device over the private network, but risk from unknown users accessing the device on the public network is mitigated. If SSH accessibility over the public network is necessary, you can transfer SSH to a custom port number for an added layer of security.

Use the following steps to restrict SSH access on the public network.



1.  Access the Private Network over [VPN](http://www.softlayer.com/vpn-access).
2.  Log in to the Bare Metal Server Private IP address through SSH.
3.  Run the following command to open the sshd_config file for edits:

> vi /etc/ssh/sshd_config
4.  Remove the hash (#) from one ListenAddress line to uncomment the line.
5.  Enter the Private IP address for the Bare Metal Server in the uncommented ListenAddress line.
6.  Run the :wq command to save the changes and exit the file.
7.  Restart the sshd service

> service sshd restart
8.  Test the updates to SSH accessibility by attempting to access SSH over the Bare Metal Server's public IP address.



 If a connection  Then...                                                                                                                                                       

 Can't be made    Changes that were made to SSH accessibility were successful. No further action is required.                                                                   
 Can be made      Changes that were made to SSH accessibility were unsuccessful. Repeat the previous steps to retry SSH restriction. If issues persist, [contact Support](https://cloud.ibm.com/docs/docs/get-support?topic=get-support-using-avatar).    







  Next steps 

After successfully restricting SSH access, users can't access the device through SSH if they don't connect through the private network. This action can be reversed at any time by adding the hash (#) back to the uncommented line, which returns the line to comments.
* Check whether App ID redirect URIs are not using localhost or 127.0.0.1
* Check whether Cloud Object Storage is accessible only by using private endpoints
* Check whether Virtual Private Cloud (VPC) network access control lists don't allow egress from 0.0.0.0/0 to any port







 NIST supplemental guidance 

This control enhancement applies to both inbound and outbound network communications traffic. A deny-all, permit-by-exception network communications traffic policy ensures that only those connections which are essential and approved are allowed.
* kp instance [policies](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-instance-policies) : list policies associated with an instance
* kp instance [policy-update allowed-network](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-instance-policy-update-allowed) : update the instance policy and set the "allowed network" to public-and-private or private-only
* kp instance [policy-update dual-auth-delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-instance-policy-update-dual) : update the instance policy and enable or disable the "dual authorization delete" policy







 kp key 



* kp key [cancel-delete](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-key-cancel-delete) : cancel a previously scheduled request to delete a key
* kp key [disable](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-key-disable) : disable a root key and temporarily revoke access to the key's associated data in the cloud
* kp key [enable](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-key-enable) : enable a root key that was previously disabled; this action restores the key's encrypt and decrypt operations
* kp key [restore](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-protect-cli-referencekp-key-restore) : restore a previously deleted root key, which restores access to its associated data in the cloud
Consider to use customer-managed keys, if you require the following features:



* Encryption of data at rest controlled by your own key.
* Explicit control of the lifecycle of data that is stored at rest.



Customer-managed keys are available on the Enterprise plan and only on clusters that were created after October 2019.

Deletion of the customer-managed key is unrecoverable and results in the loss of any data that is stored in your Event Streams instance.



 What is not covered by customer-managed encryption 

If customer-managed encryption feature is selected, be aware that only message payload data is covered by this encryption. Event Streams encrypts at rest other data that is related to the use of the service. However, although encrypted, non-message payload data is not encrypted with the customer-managed encryption. Examples are client metadata such as topic names, topic configuration data, schemas stored in the schema registry and metadata that is stored in relation to the configuration of the Enterprise instance.

Therefore, do not use confidential information in such client metadata.





 How customer-managed encryption works 

Event Streams uses a concept that is 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 that is 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 that is 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.
* UI
* API
* Terraform







 Securing your data in Continuous Delivery 

IBM Cloud® Continuous Delivery hosts your databases in a highly available and secure environment:



* Data is encrypted at rest (GPFS, LUKS, and built-in disk) and in transit (HTTPS and SSH) by using encryption keys that are internal to the Continuous Delivery service, or the services and infrastructure that it depends on.
* [Personal data can be encrypted only in the Professional plan](https://cloud.ibm.com/docs/ContinuousDelivery?topic=ContinuousDelivery-cd_data_securitycd_professional_plan) by using a root key within an instance of the IBM® Key Protect for IBM Cloud® service or the IBM Cloud® Hyper Protect Crypto Services service.
* Client and system credentials are stored on encrypted disks.
* Configuration data for tool integrations and Delivery Pipeline property values might include sensitive information. This data is encrypted by using encryption keys that are internal to the Continuous Delivery service because it is stored in databases that are internal to the service.
* The application and data are configured for high availability.
* Access to data is limited to only those users who require the data to support and maintain the service.





 Protecting your sensitive data in Continuous Delivery 

The Continuous Delivery service encrypts customer-owned sensitive data before it stores it in databases that are used internally by the service. Sensitive data includes third-party tool integration configuration data and Delivery Pipeline property values. Data is encrypted by using encryption keys that are internal to the Continuous Delivery service or by using encryption keys from the root key that is specified within an instance of the IBM® Key Protect for IBM Cloud® service or the IBM Cloud® Hyper Protect Crypto Services service.

DevOps processes often require various types of credentials (such as usernames and passwords, API keys, service keys, and SSH keys) to interact with other systems to build, test, and deploy applications. You are responsible for ensuring that these credentials aren't inadvertently shared outside of their intended audience. Access to these credentials by malicious actors might disrupt your IT operations, cause unexpected costs, or use your resources to start attacks. IBM is not responsible for protecting and maintaining the security of your credentials.
Securing your data in Secrets Manager 

To ensure that you can securely manage your data when you use IBM Cloud® Secrets Manager, it is important to know exactly what data is stored and encrypted and how you can delete it. Data encryption by using customer-managed keys is supported by integrations with Key Protect or Hyper Protect Crypto Services.



 How your data is stored and encrypted in Secrets Manager 

When you work with Secrets Manager, the service communicates with HashiCorp Vault to process operations on secrets of different types. By design, [Vault uses a security barrier](https://developer.hashicorp.com/vault/docs/internals/securityexternal-threat-overview) for all requests that are made to its back end. Data that leaves Vault is automatically encrypted by using a 256-bit Advanced Encryption Standard (AES) cipher in the Galois Counter Mode (GCM) with 96-bit nonces.

Secrets Manager encrypts all secrets at rest with

envelope encryption. Your encrypted secrets are stored in a dedicated Cloud Object Storage bucket that is unique to your instance. To protect secrets at rest, Secrets Manager integrates with a key management service, such as Key Protect and Hyper Protect Crypto Services. Each version of every secret is encrypted by a data encryption key (DEK) that is protected by aroot key, which is used by Secrets Manager to [seal and unseal access to Vault](https://developer.hashicorp.com/vault/docs/concepts/seal). This integration protects your secrets by using encryption keys that are rooted in FIPS-validatedhardware security modules. At no time are your credentials available in clear text while they are stored by the service.

Secrets Manager also uses the following security mechanisms to protect your data in transit.



* TLS 1.2+ for end to end communications
* mTLS for internal communications
* Web App Firewall and DDoS protection
* Ingress and Egress network rules to isolate your dedicated instance







 Protecting your sensitive data in Secrets Manager 

You can add a higher level of encryption control to your data at rest (when it is stored) by enabling integration with a key management service.
Information security 

IBM is committed to providing our clients and partners with innovative data privacy, security and governance solutions.

Notice: Clients are responsible for ensuring their own compliance with various laws and regulations, including the European Union General Data Protection Regulation (GDPR). Clients are solely responsible for obtaining advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulations that may affect the clients’ business and any actions the clients may need to take to comply with such laws and regulations.

The products, services, and other capabilities described herein are not suitable for all client situations and may have restricted availability. IBM does not provide legal, accounting or auditing advice or represent or warrant that its services or products will ensure that clients are in compliance with any law or regulation.

If you need to request GDPR support for IBM Cloud® Watson resources that are created



* In the European Union, see [Requesting support for IBM Cloud Watson resources created in the European Union](https://cloud.ibm.com/docs/watson/getting-started-gdpr-sarrequest-EU).
* Outside the European Union, see [Requesting support for resources outside the European Union](https://cloud.ibm.com/docs/watson/getting-started-gdpr-sarrequest-non-EU).





 European Union General Data Protection Regulation (GDPR) 

IBM is committed to providing our clients and partners with innovative data privacy, security and governance solutions to assist them on their journey to GDPR compliance.

Learn more about IBM's own GDPR readiness journey and our GDPR capabilities and offerings to support your compliance journey [here](http://www.ibm.com/gdpr).





 More information 

For more information about data privacy in IBM Cloud Pak for Data, see [IBM Cloud Pak for Data considerations for GDPR readiness](https://www.ibm.com/docs/en/cloud-paks/cp-data/4.0?topic=compliance-considerations-gdpr-readiness).





 Labeling and deleting data in Watson Assistant 

1.5.0 and later Support for deleting data was added when log retention and analytics support were added to the product.
You can also use private load balancing to test access, request routing, and other configurations for your app before you later expose your app to the public with public network services.

As an example, say that you create a private load balancer for your app. This private load balancer can be accessed by:



* Any pod in that same cluster.
* Any pod in any cluster in the same IBM Cloud account.
* If you're not in the IBM Cloud account but still behind the company firewall, any system through a VPN connection to the subnet that the load balancer IP is on.
* If you're in a different IBM Cloud account, any system through a VPN connection to the subnet that the load balancer IP is on.
* In classic clusters, if you have [VRF or VLAN spanning](https://cloud.ibm.com/docs/openshift?topic=openshift-subnetsbasics_segmentation) enabled, any system that is connected to any of the private VLANs in the same IBM Cloud account.
* In VPC clusters:



* If traffic is permitted between VPC subnets, any system in the same VPC.
* If traffic is permitted between VPCs, any system that has access to the VPC that the cluster is in.







 Private app networking for classic clusters 

When your worker nodes are connected to both a public and a private VLAN, you can make your app accessible from a private network only by creating private routes, NodePorts, NLBs, or setting up Ingress. Then, you can create Calico policies to block public traffic to the services.

The public network interface for worker nodes is protected by [predefined Calico network policy settings](https://cloud.ibm.com/docs/openshift?topic=openshift-network_policiesdefault_policy) that are configured on every worker node during cluster creation. By default, all outbound network traffic is allowed for all worker nodes. Inbound network traffic is blocked except for a few ports. These ports are opened so that IBM can monitor network traffic and automatically install security updates for the Kubernetes master, and so that connections can be established to NodePort, LoadBalancer, and Ingress services.
For a higher level of security and control, your business might benefit from the data isolation that a single-tenant offering provides, such as Secrets Manager or Hyper Protect Crypto Services. You might also decide that the reduced cost and scalability benefits of a multi-tenant service, such as Key Protect and Certificate Manager, are better suited to your needs. The following table lists key features for each service.



Table 2. Key features for IBM Cloud data protection services
The table compares features across Secrets Manager, Certificate Manager, Key Protect, and Hyper Protect Crypto Services. The first column lists the names of the services. The second column lists the types of secrets that are supported by each service. The third column uses checkmarks to indicate whether a service is multi-tenant. The fourth column uses checkmarks to indicate whether a service is single-tenant. The last column uses checkmarks to indicate whether a service is backed by a hardware security module (HSM).

 Service Secret types Multi-tenant<br><br>[1] Single-tenant<br><br>[2] HSM backed<br><br>[3] 

 Secrets Manager Arbitrary secrets <br>IAM credentials <br>Key-value secrets <br>SSL/TLS certificates <br>User credentials ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/checkmark-icon.svg) 
 Key Protect Symmetric encryption keys ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/checkmark-icon.svg) ![Checkmark icon](https://cloud.ibm.com/docs-content/v1/content/991f60ddbe3ab0a9aa69481a07a0a73b359fa329/icons/checkmark-icon.svg)
You can also [create an allowlist for the private cloud service endpoint](https://cloud.ibm.com/docs/containers?topic=containers-access_clusterprivate-se-allowlist) to limit access to your cluster from only the allowed subnets. For more information, see the different service architecture setups for [classic](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_classic) or [VPC](https://cloud.ibm.com/docs/containers?topic=containers-service-archarchitecture_vpc) clusters.
* Classic network: See [Network segmentation and privacy for classic clusters](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork_segmentation).
* VPC network: See [Network segmentation and privacy for VPC clusters](https://cloud.ibm.com/docs/containers?topic=containers-securitynetwork_segmentation_vpc).







 Kubernetes resources within the cluster 



* Pod-to-pod network traffic control: Consider using [Kubernetes network policies and Calico](https://cloud.ibm.com/docs/containers?topic=containers-network_policies).
* Kubernetes resources for pod-level control: See [Configuring pod security policies (PSPs)](https://cloud.ibm.com/docs/containers?topic=containers-psp).











 Understanding IAM access policies and roles 

Access policies determine the level of access that users in your IBM Cloud account have to resources across the IBM Cloud platform. A policy assigns a user one or more roles that define the scope of access to a single service or to a set of services and resources that are organized together in a resource group. Each service in IBM Cloud might require its own set of access policies.



 Pick the correct access policy and role for your users 

You must define access policies for every user that works with IBM Cloud Kubernetes Service. The scope of an access policy is based on a user's defined role or roles, which determine the actions that the user can perform.
However, trusted profiles don't require federated users to be invited to an account, and only users that are federated by an external identity provider (IdP) can apply a trusted profile.

When you're a member of multiple access groups, all policies apply at once when you access an account. As a federated user, you might have the option to apply different trusted profiles, but you select just one profile to apply when you log in. For example, if you want to complete developer-related tasks, select the Developer profile when you log in. If you want to complete an administrator-related task, you select theAdmin profile that has privileged permissions. This way, you reduce the risk of taking privileged actions by mistake.

A policy consists of a subject, target, and role. The subject in this case is the access group or trusted profile. The target is what you want the subject to access, such as a set of resources in a resource group, a service instance, all services in the account, or all instances of a service. The role defines the level of access that is granted.

The following diagram shows how an access policy works:

Zoom

![What is an access policy](https://cloud.ibm.com/docs-content/v1/content/d4595e5202a9a27767cf034e81b038cdf772e0d5/secure-enterprise/includes/account/images/Access-Policy.svg)

Figure 1. What is an Access Policy

The most commonly used roles are viewer, editor, operator, and administrator platform roles.



* The viewer role provides the least amount of access for viewing instances and resource groups in an account.
* The operator role includes actions such as the ability to view instances and manage aliases, bindings, and credentials.
* The editor role includes actions the same actions of an operator role but also actions for creating, editing, deleting, and binding service instances.
* The administrator role includes everything for working with a service instance and assigning access to others for that service or instance that the policy is for.
Provide restricted inbound access from the internet to instances or subnets. Site-to-site VPN handles customers of any size, and single or multiple locations. 
 Entire subnets share the outbound public endpoint. Provides limited access to a single private server. Restrict access inbound from internet, based on service, protocol, or port. High throughput (up to 10 Gbps) provides customers the ability to transfer large data files securely and quickly. 
 Protects instances; Cannot initiate access to instances through the public endpoint. DNAT service can be scaled up or down, based on requirements. Stateless ACLs allow for granular control of traffic. Create secure connections with industry standard encryption. 



You can create only one public gateway per zone. However, that public gateway can be attached to multiple subnets in the zone.