vania-janet/multiturn-rag-retrieval-data huggingface dataset:
If you suspect that your public IP address is blocked or restricted, access your customer portal and review the tickets.





 Filtered protection 

Unlike null routing, filtered protection does not block or restrict your IP address from being reachable by the public internet. Protection devices analyze the traffic and use internal logic to determine if there is malicious traffic to filter. When triggered, filtered protection eliminates any suspicious traffic and allows legitimate traffic to flow to your host.

This protection remains in place until the traffic drops to appropriate levels within the threshold.

During periods of filtered protection, a ticket is generated with the subject “NETWORK ALERT: Automated Managed Network Alert”. See the ticket for more details about why your traffic is being diverted.

The internal logic used to filter malicious traffic might also filter legitimate traffic. If you find that legitimate traffic is filtered, contact IBM Support with the auto-generated ticket you received, and request further investigation.





 Raising the threshold limit 

Most customer traffic flow per IP address is less than 1 Gb/s. This includes customers that have ordered hosts with 10G and 25G interfaces. However, if you require inbound rates to be greater than this per IP address, and if your hosts on the account have 10G or 25G interfaces, you can reach out to IBM Support to discuss changing the network protection setting for an IP address to avoid triggering our network protection against your legitimate traffic.
This control also addresses the use of external information systems for the processing, storage, or transmission of organizational information, including, for example, accessing cloud services (e.g., infrastructure as a service, platform as a service, or software as a service) from organizational information systems. For some external information systems (i.e., information systems operated by other federal agencies, including organizations subordinate to those agencies), the trust relationships that have been established between those organizations and the originating organization may be such, that no explicit terms and conditions are required. Information systems within these organizations would not be considered external. These situations occur when, for example, there are pre-existing sharing/trust agreements (either implicit or explicit) established between federal agencies or organizations subordinate to those agencies, or when such trust agreements are specified by applicable laws, Executive Orders, directives, or policies. Authorized individuals include, for example, organizational personnel, contractors, or other individuals with authorized access to organizational information systems and over which organizations have the authority to impose rules of behavior with regard to system access. Restrictions that organizations impose on authorized individuals need not be uniform, as those restrictions may vary depending upon the trust relationships between organizations. Therefore, organizations may choose to impose different security restrictions on contractors than on state, local, or tribal governments. This control does not apply to the use of external information systems to access public interfaces to organizational information systems (e.g., individuals accessing federal information through www.usa.gov). Organizations establish terms and conditions for the use of external information systems in accordance with organizational security policies and procedures. Terms and conditions address as a minimum: types of applications that can be accessed on organizational information systems from external information systems; and the highest security category of information that can be processed, stored, or transmitted on external information systems. If terms and conditions with the owners of external information systems cannot be established, organizations may impose restrictions on organizational personnel using those external systems.
"allowed_network": "<access_type>"
}
}
}
]
}'
Show more



Replace the variables in the example request according to the following table.



Table 1. Describes the variables that are needed to set a network access policy at the instance level.

 Variable Description 

 region Required. The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protect instance resides. <br> <br>For more information, see [Regional service endpoints](https://cloud.ibm.com/docs/key-protect?topic=key-protect-regionsservice-endpoints). 
 IAM_token Required. 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>For more information, see [Retrieving an instance ID](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-instance-ID). 
 enabled Required. Set to true to enable a network access policy. Set to false to remove the network access policy, that is, the policy is not enforced. 
 access_type Required. The network access policy to apply to your Key Protect instance. Acceptable values are public-and-private or private-only. 



A successful request returns an HTTP 204 No Content response, which indicates that your Key Protect instance now enforces a network access policy. API requests to the service are restricted to the policy you set.

This policy applies to Key Protect instances only. The network access policy does not apply to specific keys.

Optional: Verify that the network access policy was created by browsing the policies that are available for your Key Protect instance.
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](https://www.ibm.com/data-responsibility/gdpr/).





 Health Insurance Portability and Accountability Act (HIPAA) 

US Health Insurance Portability and Accountability Act (HIPAA) support is available for Enterprise plans that are hosted in the Washington, DC or Dallas locations. For more information, see [Enabling HIPAA support for your account](https://cloud.ibm.com/docs/account?topic=account-enabling-hipaa).

Do not add personal health information (PHI) to the training data (entities and intents, including user examples) that you create. In particular, be sure to remove any PHI from files that contain real user utterances that you upload to mine for intent or intent user example recommendations.





 Opting out of log data use 

IBM uses log data, Enterprise plan data excluded, to continually learn from and improve the Watson Assistant product. The logged data is not shared or made public.

To prevent IBM from using your log data for general service improvements, complete one of the following tasks:



* If you are using a custom application, for each API /message request, set the X-Watson-Learning-Opt-Out header parameter to true.

For more information, see [Data collection](https://cloud.ibm.com/apidocs/assistant/assistant-v2data-collection).
* If you are using the web chat integration, add the learningOptOut parameter to the script that you embed in your web page, and set it to true.

For more information, see [Configuration](https://integrations.us-south.assistant.watson.cloud.ibm.com/web/developer-documentation/api-configuration).







 Labeling and deleting data in Watson Assistant 

Do not add personal data to the training data (actions and steps, including user examples) that you create.
Securing your data 

The data volume that you attach to your Hyper Protect Virtual Server for VPC instance is protected by a Linux Unified Key Setup (LUKS) encryption passphrase derived from seeds provided during deployment. You can add a higher level of encryption protection and control to your data at rest by using your own key from Hyper Protect Crypto Services.



 How your data volume is encrypted 

Without your own key, the data volume that you attach to your instance is encrypted automatically with two seeds that are provided in the workload - volumes and env - volumes sections of the contract. The seeds are internally converted to UTF8 sequences and then concatenated. The hash (SHA256) of the concatenated sequence is computed as a hexdigest, which is used as the LUKS passphrase to encrypt the data volume. For more information, see [About contract](https://cloud.ibm.com/docs/vpc?topic=vpc-about-contract_sehpcr_contract_volumes).





 Protecting your sensitive data with your own key 

Starting from ibm-hyper-protect-container-runtime-1-0-s390x-11, Hyper Protect Virtual Servers for VPC support integration with the key management service (KMS) Hyper Protect Crypto Services. Hyper Protect Crypto Services generates a random value as the third seed and wraps it with the CRK (customer root key). The wrapped seed is stored in the metadata partition of your data volume. The LUKS passphrase is generated by using three seeds - the seed in the metadata partition (unwrapped first) and the two seeds from the contract.

Background knowledge: From the HPCR image version ibm-hyper-protect-container-runtime-1-0-s390x-9, for new Hyper Protect Virtual Servers for VPC instances, the data volume is partitioned into two parts. The first partition (100 Mib) is reserved for internal metadata only (not to be accessed by a workload); the second partition remains as the data volume for workload. Only new volumes are partitioned.

Zoom

!
In Figure 2, Org B and Org D have joined channel Y. The peers of Org B and Org D now store a copy of ledger Y, in addition to ledger X. Because the same ordering service was used to create channel X and channel Y, the ordering service now has a copy of the blockchain portion of both channel ledgers. In both Figure 1 and Figure 2, data being created by applications in Germany is stored in the United States, which is undesirable if data residency is required.

We can use the previous example to explore the options that organizations can use to achieve data residency. Assume that a regulation in Germany requires some of the data that is created by Org C and Org D to remain within the country. The organizations in Germany can use all four of the following options to prevent data from being stored in the United States.





 Option one: Private data collections on a shared channel 

Org C and Org D can use the [private data feature](https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data/private-data.htmlwhat-is-a-private-data-collection) of Hyperledger Fabric to prevent data from being distributed to all organizations on the channel. Private data collections allow organizations to share state data peer-to-peer (via a [gossip data dissemination protocol](https://hyperledger-fabric.readthedocs.io/en/release-2.2/gossip.html)) with other organizations that are authorized to read the collection. The data is stored in a private, separate database on the peer. The ordering service is not involved and does not see the private data. Only a hash of the data in the collection is added to the channel ledger and is stored on the peers of other channel members and the ordering service. This allows organizations to verify private data if they want to make the transaction details public. To learn more, visit the [Private Data](https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data/private-data.htmlprivate-data) concept article in the Fabric documentation.

Zoom

!
However, customer-managed keys are not supported for instance storage. For sensitive data, it is strongly recommended that users utilize software-based file system encryption such as LUKS for Linux® or BitLocker for Windows®. This technology allows end users to encrypt entirely within the instance, and can provide additional protection for sensitive data in-transit between the instances and the physical drive media. Some operating systems also provide FIPS certified encryption algorithms that may also be used. See [Encrypting block devices using LUKS](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening) for an example of how to encrypt on Red Hat Enterprise Linux® however, refer to the Operating System documentation or specific information on how to encrypt each device.





 Isolation 

The instance storage disk, or disks attached to the virtual server instance, cannot be shared with any other virtual servers and cannot be accessed by any other virtual servers in the future. They are one-time use, single-attach, for the virtual server that requested the instance storage. There is also isolation from negative performance effects of different virtual servers doing I/O to different portions of the same physical device (as described in the next section).





 Performance 

Instance storage is rate-limited. If the instance storage allocated to the virtual server instance is smaller than the entire physical Solid State Disk (SSD), then I/O bandwidth and IOPS limits are put in place proportional to the size of the attached disk. This limitation is in place to prevent a busy instance from consuming more than their fair share of the bandwidth of the device (noisy neighbor).





 Multiple instance storage disks 

When there are multiple instance disks on your virtual server instance, each disk is provisioned from a separate underlying physical device. This allows for better independent performance as well as software high-availability solutions to be implemented like software-based RAID.





 Billing 

You are billed for instance storage only while the virtual server instance is running.





 Restrictions 

Using instance storage comes with some restrictions. Keep the following in mind when you are considering instance storage:
PE&O insurance provides coverage for actual or alleged breach of duty, neglect, error, misstatement, misleading statements or omission, solely for acts or omissions committed by IBM in providing professional services to our client(s). Coverage includes network security, unauthorized access, unauthorized use, receipt or transmission of a malicious code, denial of service attack, unauthorized disclosure or misappropriation of private information, privacy liability, notification costs, credit card monitoring, and fine & penalties incurred by the customer.

The PE&O Policy itself is IBM Confidential information. Further details on this subject can be accessed (IBMers only) here:

[!https://w3-connections.ibm.com/wikis/home?lang=en-us#/wiki/Wc0a20474fb23_478a_8f6d_1c6dfd3d680f/page/IBM cyber insurance details](https://w3-connections.ibm.com/wikis/home?lang=en-us!/wiki/Wc0a20474fb23_478a_8f6d_1c6dfd3d680f/page/IBM%20cyber%20insurance%20details)





 Regulated Content 

IBM Maximo Application Suite offerings are not intended to host government regulated content. Please see the Cloud Services Agreement (link below) Section 2c for details.





 Clock synchronization 

All customer MAS-Dedicated environments leverage IBM Cloud's internal NTP service as single reference time source for information system processing clocks and security domains.

Customers are responsible or synchronizing their local environments (workstations, on premise servers) with an authoritative time source.





 Terms of Use 

General Terms of Use for IBM Cloud Offerings: [https://www.ibm.com/software/sla/sladb.nsf/sla/tou-gen-terms](https://www.ibm.com/software/sla/sladb.nsf/sla/tou-gen-terms)





 Cloud Service Agreement
Sensitive information <br><br> * The TLS certificate and secret that is used for the assigned Ingress subdomain.<br> * The certificate authority that is used for the TLS certificate.<br> * The certificate authority, private keys, and TLS certificates for the Red Hat OpenShift master components, including the Red Hat OpenShift API server, etcd data store, and VPN.<br> * A customer root key in IBM Key Protect for each IBM Cloud account that is used to encrypt personal and sensitive information.<br><br><br> 







 How is my information stored and encrypted? 

All information is stored in an etcd database and backed up every 8 hours to IBM Cloud Object Storage. The etcd database and Object Storage service instance are owned and managed by the IBM Cloud SRE team. For each IBM Cloud account, a customer root key in IBM Key Protect is created that is managed by the Red Hat OpenShift on IBM Cloud service team. This root key is used to encrypt all personal and sensitive information in etcd and in Object Storage.





 Where is my information stored? 

The location where your information is stored depends on the location your cluster is in. By default, your data is stored in the Red Hat OpenShift on IBM Cloud multizone metro area that is closest to your cluster. However, Red Hat OpenShift on IBM Cloud might decide to store your data in a different multizone metro area to optimize the utilization of available compute resources. If you create your cluster in a non-multizone metro area, your data is still stored in the closest multizone metro area. This location might be in a different country than the one where you created your cluster. Make sure that your information can reside in a different country before you create your cluster in a non-multizone metro area.

The data that you create and own is always stored in the same location as the cluster. For more information about what data you can create in your cluster, how this data is encrypted, and how you can protect this data, see [Protecting sensitive information in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-encryption).





 How can I remove my information?
IBM Cloud relies on Standard Contractual Clauses (as the primary data transfer mechanism) in the client contracts. IBM Cloud also relies on numerous supplementary measures to help clients ensure an adequate level of protection when they transfer personal data outside of the EU/EEA. For more information, see EU Standard Contractual Clauses that are signed by all [IBM Cloud Data Importers](https://www.ibm.com/support/customer/csol/terms/?id=SW-EUSSC), if applicable.

For IBM Cloud's position on trust and transparency, in relation to client data, see [Trust principles](https://www.ibm.com/policy/trust-transparency-new/).

If more questions that are associated with IBM Cloud's data privacy policies arise, email DPA.Help.project@uk.ibm.com.
Provisioning a HIPAA compliance instance 

Across every industry, organizations require tighter controls and visibility into where their data is stored and processed in the IBM Cloud®. To manage logs for HIPAA resources by using the IBM Log Analysis service, consider the following information:

HIPAA compliance is a shared responsibility. IBM only provides the security and the tools to ensure its cloud platform can be used without violating HIPAA rules. It is the responsibility of HIPAA-covered entities to ensure that cloud-based infrastructure and applications are not misconfigured, and that stored files are appropriately secured.



 Step 1. Enable the HIPAA supported settings in your account 

If you're the account owner, you can enable your IBM Cloud® account to be HIPAA supported. You might choose to enable the HIPAA Supported setting if you plan to include Protected Health Information (PHI) in HIPAA-enabled services.

The US Health Insurance Portability and Accountability Act (HIPAA) and the Health Information Technology for Economic and Clinical Health (HITECH) Act define standards for handling electronic healthcare transactions and information. If you or your company is a covered entity as defined by HIPAA, you must enable the HIPAA Supported setting if you run sensitive workloads that are regulated under HIPAA and the HITECH Act. Learn more about IBM Cloud compliance in [Compliance on the IBM Cloud.](https://www.ibm.com/cloud/compliance)

Enabling this setting has the following effects:



* Enables you to filter on HIPAA Enabled services in the catalog
* Indicates to IBM that your account stores protected health information (PHI)
* Digitally accepts the IBM Business Associate Addendum (BAA) for covered entities



Enable this setting only if you or your company is a covered entity as defined by HIPAA. If you or your company is a business associate of a covered entity, [contact IBM Cloud Sales](https://www.ibm.com/account/reg/us-en/signup?formid=MAIL-wcp) to accept the applicable BAA. For more information about HIPAA definitions of covered entities and business associates, see the [US Department of Health & Human Services](https://www.hhs.gov/hipaa/for-professionals/covered-entities/index.html) website.
Managing encryption 

By default, customer data in Event Notifications are encrypted at-rest using a randomly generated key. Although this default encryption model provides at-rest security, you might need a higher level of control. For these use cases, Event Notifications supports customer-managed encryption with the following IBM Cloud® Key Management Services:



* IBM® Key Protect for IBM Cloud® (Bring Your Own Key - BYOK) helps you provision encrypted keys for apps across IBM Cloud services. As you manage the lifecycle of your keys, you can benefit from knowing that your keys are secured by FIPS 140-2 Level 3 certified cloud-based hardware security modules (HSMs) that protect against the theft of information. You can find out more about using Key Protect in the [Getting Started tutorial](https://cloud.ibm.com/docs/key-protect?topic=key-protect-getting-started-tutorial).
* Hyper Protect Crypto Services (Keep Your Own Key - KYOK) 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. You can find out more about using Hyper Protect Crypto Services in the [Getting Started tutorial](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-get-started).



These services allow the use of a customer-provided key to control encryption. By disabling or deleting this key, you can prevent any further access to the data stored by the service, because it is no longer possible to decrypt it.

Consider using 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 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.