vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more details, see [the Key Protect documentation](https://cloud.ibm.com/docs/key-protect?topic=key-protect-key-states).



 Rotating Keys 

Key rotation is an important part of mitigating the risk of a data breach. Periodically changing keys reduces the potential data loss if the key is lost or compromised. The frequency of key rotations varies by organization and depends on a number of variables, such as the environment, the amount of encrypted data, classification of the data, and compliance laws. The [National Institute of Standards and Technology (NIST)](https://www.nist.gov/topics/cryptography) provides definitions of appropriate key lengths and provides guidelines for how long keys should be used.

For more information, see the documentation for rotating keys in [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-rotation-policy).





 Disabling and re-enabling keys 

As an admin, you might need to [temporarily disable a root key](https://cloud.ibm.com/docs/key-protect?topic=key-protect-disable-keys) if you suspect a possible security exposure, compromise, or breach with your data. When you disable a root key, you suspend its encrypt and decrypt operations. After confirming that a security risk is no longer active, you can reestablish access to your data by enabling the disabled root key.

If a key is disabled, and then re-enabled quickly, requests made to that bucket may be rejected for up to an hour before cached key information is refreshed.





 Deleting keys and cryptographic erasure 

It isn't possible to delete a root key associated with a bucket that has a [retention policy](https://cloud.ibm.com/docs/cloud-object-storage/basics?topic=cloud-object-storage-immutable) in place. The bucket must be first emptied and destroyed before the root key can be deleted.
The following JSON object shows an example response.

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.policy+json",
"collectionTotal": 1
},
"resources": [
{
"id": "2291e4ae-a14c-4af9-88f0-27c0cb2739e2",
"crn": "crn:v1:bluemix:public:kms:us-south:a/f047b55a3362ac06afad8a3f2f5586ea:30372f20-d9f1-40b3-b486-a709e1932c9c:key:2291e4ae-a14c-4af9-88f0-27c0cb2739e2",
"dualAuthDelete": {
"enabled": true
},
"createdBy": "...",
"creationDate": "2020-03-10T20:41:27Z",
"updatedBy": "...",
"lastUpdateDate": "2020-03-16T20:41:27Z"
}
]
}

The key now requires an authorization from two users before it can be deleted.

For more information, see [Deleting keys using dual authorization](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-dual-auth-keys).
To learn how to delete a key that has a dual authorization policy, see [Deleting keys using dual authorization](https://cloud.ibm.com/docs/key-protect?topic=key-protect-delete-dual-auth-keys).



 Viewing a dual authorization policy for a key 

For a high-level view, you can retrieve the dual authorization policy for a single key by making a GET call to the following endpoint.

https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/policies?policy=dualAuthDelete



1. [Retrieve your authentication credentials to work with keys in the service](https://cloud.ibm.com/docs/key-protect?topic=key-protect-set-up-api).

To work with dual authorization policies, you must be assigned a Manager access policy for the instance or key. To learn how IAM roles map to Key Protect service actions, check out [Service access roles](https://cloud.ibm.com/docs/key-protect?topic=key-protect-manage-accessmanage-access-roles).
2. Retrieve the dual authorization policy for a specified key by running the following curl command.

$ curl -X GET "https://<region>.kms.cloud.ibm.com/api/v2/keys/<keyID_or_alias>/policies?policy=dualAuthDelete" -H "accept: application/vnd.ibm.kms.policy+json" -H "authorization: Bearer <IAM_token>" -H "bluemix-instance: <instance_ID>"

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





Table 1. Describes the variables that are needed to view a dual authorization policy for a key with the Key Protect API.

 Variable Description 

 keyID_or_alias Required. The unique identifier or alias for the key that has an existing rotation policy. 
 region Required. The region abbreviation, such as us-south or eu-gb, that represents the geographic area where your Key Protect instance resides.
For more information about safely removing service authorization, see [Removing service authorization to a root key](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-encryption-managinginstance-byok-inaccessible-data).





 What can I do if my root key is compromised? 

Independently back up your data. Then, delete the compromised root key and power down the instance with volumes that are encrypted with that key.

Also, consider setting up a key rotation policy that automatically rotates your keys based on a schedule. For more information, see [Key rotation for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation).





 What is key rotation? 

For IBM Cloud VPC resources such as Block Storage for VPC volumes that are protected by your customer root key (CRK), you can rotate the root keys for extra security. When you rotate a root key by a schedule or on demand, the original key material is replaced. The old key remains active to decrypt existing volumes but can't be used to encrypt new volumes. For more information, see [Key rotation for VPC resources](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-key-rotation).





 How does key rotation work? 

Customer-managed encrypted resources such as Block Storage for VPC volumes use your root key (CRK) as the root-of-trust key that encrypts a LUKS passphrase that encrypts a master key that's protecting the volume. You can import your CRK to a key management service (KMS) instance or instruct the KMS to generate one for you. Root keys are rotated in your KMS instance.

When you rotate a root key, a new version of the key is created by generating or importing new cryptographic key material. The old root key is retired, which means its key material remains available for decrypting existing volumes, but not available for encrypting new ones. New resources are protected by the latest key.
These events are particular to Key Protect, but similar events are generated for Hyper Protect Crypto Services.



* When you disable a key (key state changes from active to suspended), a kms.secrets.disable event is generated.
* When you enable a disabled key (key state changes from suspended to active), a kms.secrets.enable event is generated.
* When you delete a key (key state changes to destroyed), a kms.secrets.delete event is generated.
* When you restore a deleted key (key state changes from destroyed to active), a kms.secrets.restore event is generated.



For more information, see all [Activity Tracker key events](https://cloud.ibm.com/docs/key-protect?topic=key-protect-at-eventskey-actions).







 Next Steps 



* [Create volumes that use customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-block-storage-vpc-encryption).
* [Create an instance with volumes that use customer-managed encryption](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-instances-byok).
"profile": {
"name": "tier-5iops"
},
"resource_group": {
"id": "678523bcbe2b4eada913d32640909956"
},
"size": 200,
"zone": {
"name": "us-south-2"
}
}'
Show more

In the response, the CRN of the encryption key is from Account A that owns the key, while the file share is created in Account B.

{
"created_at": "2022-08-09T23:28:45Z",
"crn": "crn:v1:staging:public:is:us-south-1:a/b5c782a8f47a2d1527257e3465f21568::share:r134-fe7219eb-c9a9-4aab-8636-9a57141f0cee",
"encryption": "user_managed",
"encryption_key": {
"crn": "crn:v1:staging:public:kms:us-south:a/df0564dd126042ebb03e0224728ce939:4957299d-0ba0-487f-a1a0-c724a729b8b4:key:0cb88b98-9261-4d07-8329-8f594b6641b5"
},
"href": "https://us-south-stage01.iaasdev.cloud.ibm.com/v1/shares/r134-fe7219eb-c9a9-4aab-8636-9a57141f0cee",
"id": "r134-fe7219eb-c9a9-4aab-8636-9a57141f0cee",
"initial_owner": {
"gid": 0,
Last Updated 2020-08-13T22:33:50Z
Updated By IBMid-...<redacted>...
Enabled true

 step 3 - list the policies (verify dual authorization is enabled)
$ ibmcloud kp key policies $KEY_ID -i $KP_INSTANCE_ID --output json

[
{
"createdBy": "IBMid-...<redacted>...",
"creationDate": "2020-08-13T22:33:50Z",
"crn": "crn:v1:bluemix:public:kms:us-south:a/ea998d3389c3473aa0987652b46fb146:a192d603-0b8d-452f-aac3-f9e1f95e7411:policy:0b93cd65-8359-4891-9289-8701f4c6ad9c",
"lastUpdateDate": "2020-08-13T22:33:50Z",
"updatedBy": "IBMid-...<redacted>...",
"dualAuthDelete": {
"enabled": true
}
}
]

 step 4 - fails because not enough authorizations are met to delete the key
$ curl -X DELETE "https://us-south.kms.cloud.ibm.com/api/v2/keys/$KEY_ID" -H "authorization: Bearer $ACCESS_TOKEN" -H "bluemix-instance: $KP_INSTANCE_ID" -H "content-type: application/vnd.ibm.kms.key+json"
Show more



 JSON response 

{
"metadata": {
"collectionType": "application/vnd.ibm.kms.error+json",
"collectionTotal": 1
},
"resources": [
{
Describes the variables that are needed to delete a key alias with the Key Protect API

 Variable Description 

 region Required. The region abbreviation, such as us-southor 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). 
 keyID_or_alias Required. The identifier or alias for the key that you retrieved in [step 1](https://cloud.ibm.com/docs/key-protect?topic=key-protect-view-keysretrieve-keys-api). 
 key_alias Required. The unique, human-readable name that identifies your key. 
 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). 
 correlation_ID Optional.The unique identifier that is used to track and correlate transactions. 



A successful DELETE api/v2/keys/<keyID_or_alias>/aliases/<key_alias> request returns an HTTP 204 No Content response, which indicates that the alias associated with your key was deleted.

It takes up to five minutes for an alias to be completely deleted from the service.





 Key Alias FAQ 

Below are additional details about key aliases:



* An alias is independent from a key. An alias is it's own resource and any actions taken on it will not affect the associated key.
"target": "blue-us-south",
"resource_group": "5g9f447903254bb58972a2f3f5a4c711",
"resource_plan_id": "databases-for-x-standard",
"disk_encryption_key_crn": "crn:v1:<...>:key:<id>"
}'

If you provision a deployment through the CLI or API, the HPCS key needs to be identified by its full CRN, not just its ID. An HPCS CRN is in the format crn:v1:<...>:key:<id>.





 Key Rotation 

HPCS offers manual and automatic [key rotation](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-set-rotation-policy) and key rotation is supported by Cloud Databases deployments. When you rotate a key, the process initiates a Syncing KMS state task, and your deployment is reencrypted with the new key. The task is displayed on the Tasks panel on your deployment's Overview and the associated HPCS and Cloud Databases events are sent to Activity Tracker.





 Deleting the Deployment 

If you delete a deployment that is protected with an HPCS key, the deployment remains registered against the key during the soft-deletion period (up to 7 days). If you need to delete the key in the soft-deletion period, you must [force delete](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-delete-keys) the key. After the soft-deletion period, the key can be deleted without the force. You can check the [association between the key and your deployment](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-view-key-details) to determine when you can delete the key.





 Cryptoshredding 

Cryptoshredding is a destructive action. When the key is deleted, your data is unrecoverable.
An administrator sets an expiration timeout for sessions action:iam-identity.accountsettings.update AND requestData.request_body.old_session_expiration_in_seconds:NOT_SET AND requestData.request_body.new_session_invalidation_in_seconds:<SECONDS> 
 An administrator sets the default expiration timeout for sessions action:iam-identity.accountsettings.update AND requestData.request_body.old_session_invalidation_in_seconds:<SECONDS> AND requestData.request_body.new_session_invalidation_in_seconds:NOT_SET 
 An administrator restricts user list visibility in the account action:iam-identity.accountsettings.update AND requestData.team_directory_enabled:true 
 An administrator allows users to see the list of users in the account action:iam-identity.accountsettings.update AND requestData.team_directory_enabled:false 
 An administrator restricts access to resources in the account action:iam-identity.accountsettings.update AND requestData.public_access_enabled:true 
 An administrator allows public access to resources in the account action:iam-identity.accountsettings.update AND requestData.public_access_enabled:false 
 An administrator changes the MFA setting in the account. Valid MFA setting values are: NONE, TOTP, TOTP4ALL, LEVEL1, LEVEL2, LEVEL3 action:iam-identity.accountsettings.update AND new_mfa_traits:<MFA_SETTING>
Select from the actions listed, and specify the timeout period. In this case, the timeout refers to the ban period that the action takes place. A 60 second timeout means the action is applied for 60 seconds.



Table 1. Actions for rate limiting

 Action Description 

 Block Issues a 429 error when the threshold is exceeded 
 Challenge User must pass a Google reCaptcha Challenge before proceeding. If successful, we accept the request. Otherwise, the request gets blocked. 
 JS Challenge User must pass a Javascript Challenge before proceeding. If successful, we accept the request. Otherwise, the request gets blocked. 
 Simulate You can use this option to test your rule before applying any of the other options in your live environment. 



In the Advanced response section, specify the response type when a rule's threshold is exceeded.





 Bypassing URLs 

Bypass lets you create the equivalent of a allowlist or exception for a set of URLs. No actions trigger for those URLs, even if the Rate Limiting rule is matched.







 Protecting login 

Protect login creates a standard rule that protects login pages against brute-force attacks. Clients attempting to log in more than 5 times in 5 minutes are blocked for 15 minutes.

Enter a name for the rule, and the login URL.
Password expiration Specifies when a user password expires. 
 Created on Specifies when the user was created. 
 Authentication type Specifies the authentication type. 







 User actions 

In the users list view, there is an overflow menu that lists the actions that can be taken on the user.



Table 1. The table lists user actions and their definitions.

 Value Description 

 Assign owner Set the owner of the user account. 
 Change password Change the password for the system user. 
 Account expiration Set a date that the system user account will be valid until. 
 Password expiration Set a number of days until the password for the user account expires. 
 Rename Change the username of the user account. 
 Admin privileges View and grant admin privileges. 
 Object privileges View and grant object privileges. 
 Remove Delete the user account from the system. 







 Granting admin privileges to users 

User privileges dictate what actions can be taken by a particular user account. When new users are created, they have no privileges, so in most cases privileges need to be added.



1. Go to Users and groups > Users.
2. Select the user for which you want to grant admin privileges and select Admin privileges from the overflow menu.
In this view, you can see different admin privileges, which are already granted or that can be granted to the selected user.
Granting these privileges allows the user to do the actions that the privileges correspond to. Granting privileges on global database and global schema unlocks all the privileges to the user equivalent to an admin.
3. Click Edit.
4. Update, grant, or revoke object privileges by putting ticks in corresponding boxes.
5. Click Save.







 Granting object privileges to users 

User privileges dictate what actions can be taken by a particular user account. When new users are created, they have no privileges, so in most cases privileges need to be added.



1. Go to Users and groups > Users.
2. Select the user for which you want to grant object privileges and select Object privileges from the overflow menu.
3. Select a database.
You can choose between the Global database and a specific database.
AC-7 (b) <br><br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * IBMid automatically locks an account for 30 minutes after 5 consecutive unsuccessful sign in attempts<br> * Check whether App ID avoid password reuse policy is enabled<br> * Check whether App ID lockout policy after a maximum specified time is set to # minute(s)<br><br><br> 







 NIST supplemental guidance 

This control applies regardless of whether the logon occurs via a local or network connection. Due to the potential for denial of service, automatic lockouts initiated by information systems are usually temporary and automatically release after a predetermined time period established by organizations. If a delay algorithm is selected, organizations may choose to employ different algorithms for different information system components based on the capabilities of those components. Responses to unsuccessful logon attempts may be implemented at both the operating system and the application levels.
However, its recepient-usage period will continue until the key is deleted.

If no expiration date is set on a key (and it is not manually suspended, deactivated, or destroyed), the originator-usage period, recipient-usage period, and cryptoperiod of the key are the same.







 Monitoring for lifecycle changes 

After you add a key to the service, use the Key Protect dashboard or the Key Protect REST APIs to view the last time the key was transitioned.

For audit purposes, you can also monitor the activity trail for a key by integrating Key Protect with [IBM Cloud Activity Tracker](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-getting-started). After both services are provisioned and running, activity events are generated and automatically collected in a IBM Cloud Activity Tracker log when you perform actions on keys in Key Protect.
Action terminates after one minute 

  What’s happening 

You are invoking an action that returns after one min with an http code 202 and the result is only showing the activation ID.

  Why it’s happening 

When invoking an action, there are two modes possible: blocking or non-blocking. The default for regular action invocations is non-blocking and for web actions, it is blocking. Blocking invocations use a request-response style and wait for the activation result to be available. The wait period is the lesser of 60 seconds or the action's timeout limit. At the end of the wait period (for example, after 60 sec), all invocations switch to non-blocking and instead of the result, these actions return the activation ID.

The following example shows possible output.

{
"activationId": "27eca80056d54f93aca80056d5cf93b9"
}

If an invocation of a web action reaches the end of wait period, the response shows both the activation ID and the transaction ID as well as an indication that the request is returned, but the action continues to run.

The following example shows possible output.

{
"activationId": "d13cfd3ce4b14f7cbcfd3ce4b11f7cce",
"code": "42c15dc7f450df1e9a01104de158d489",
"error": "Response not yet ready."
}

  How to fix it 

With the activation ID, you can poll for the completion of the action and the result. For more information, see [CLI](https://cloud.ibm.com/docs/openwhisk?topic=cloud-functions-cli-plugin-functions-clicli_activation).

For more information about blocking actions, see [Testing blocking actions](https://cloud.ibm.com/docs/openwhisk?topic=openwhisk-testtest-block).
AC-7 - Unsuccessful Logon Attempts 



 Control requirements 

The information system:

AC-7 (a)
: Enforces a limit of [IBM Assignment: not more than five (5)] consecutive invalid logon attempts by a user during a [IBM Assignment: fifteen (15) minutes]; and

AC-7 (b)
: Automatically [IBM Assignment: locks the account/node for a thirty (30) minutes] when the maximum number of unsuccessful attempts is exceeded.





 Additional IBM Cloud for Financial Services specifications 



* Internal privileged accounts must remain locked until released by an administrator.







 IBM Cloud for Financial Services profile 

The rules related to this control that follow are part of the IBM Cloud for Financial Services v1.2.0 profile in [IBM Cloud® Security and Compliance Center](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-getting-started).



Rules for AC-7 in IBM Cloud for Financial Services v1.2.0 profile

 Requirement ID Rules 

 AC-7 (a) <br><br> * IBMid enforces a limit of 5 consecutive unsuccessful sign in attempts<br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * Check whether App ID avoid password reuse policy is enabled<br><br><br> 
 AC-7 (b) <br><br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * Check whether App ID lockout policy after failed # of sign-in attempts is enabled<br> * IBMid automatically locks an account for 30 minutes after 5 consecutive unsuccessful sign in attempts<br> * Check whether App ID avoid password reuse policy is enabled<br> * Check whether App ID lockout policy after a maximum specified time is set to # minute(s)<br><br><br> 







 NIST supplemental guidance 

This control applies regardless of whether the logon occurs via a local or network connection.
If the server has expired, you can remove the entry from the resource list and either:



* Wait for the target time to trigger deletion for you, or
* Manually trigger the deletion from the resource reclamations.



If an expired server is restored, only the entry within the resource list is restored, not the server itself.





 Restoring servers that belong to paid plans 

Servers that belong to a paid plans do not expire, and that's why they can be restored during the reclamation period. If a server is restored, the timeframe for which the server was within the resource reclamations is billed to your account.

After the server is deleted, only metadata, which isn't considered to be personal data is kept for 6 months. Make sure you back up important data for future use because you can't recover data after the virtual server has been deleted.