vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Cloud Object Storage 1 Used to store security and compliance center results 
 Event Notifications 1 Used to provide notifications for select Security and Compliance Center alerts 
 Trusted Profile 1 Used to authorize the central administration account to deploy the other components in this account 
 Business unit access groups n (1+ per BU) Used to authorize users from a business unit to view scan results 





 Rationale for centralizing the Security and Compliance Center 

The Security and Compliance Center is most valuable when all relevant resources are scanned with an appropriate profile. Reasoning about resource coverage can be difficult in the face of independent Security and Compliance Center instances, complex scope configuration, and complex account structures.

Centralizing the Security and Compliance Center and configuring broad scopes that cover the whole enterprise, or at least whole account groups within the enterprise, makes reasoning about resource coverage easy. This in turn, makes it easy to prove to internal and external auditors that all cloud resources within an audit scope are covered by appropriate Security and Compliance Center scans.

The Security and Compliance Center must be deployed in the root of the enterprise in order for it to be permitted to scan the entire enterprise.
With TDE, a database system encrypts data on database storage media, such as table spaces and files, and on backup media. The database system automatically and transparently encrypts and decrypts data when it is used by authorized users and applications. Database users do not need to be aware of TDE and database applications do not need to be adapted specifically for TDE.

Hyper Protect Crypto Services



* 2 hours
* 2023-02-08



[Using Hyper Protect Crypto Services with Unified Key Orchestrator to manage keys in Key Protect on Satellite](https://cloud.ibm.com/docs/hs-crypto?topic=hs-crypto-tutorial-uko-satellite)Using Hyper Protect Crypto Services with Unified Key Orchestrator to manage keys in Key Protect on Satellite

IBM Cloud Satellite provides you with flexibility and scalability to bring your own infrastructures to IBM Cloud. You can run IBM Cloud services anywhere including on your on-prem data centers and other cloud providers. With IBM Cloud Satellite, you can connect your multiple environments to implement distributed cloud solutions to help your enterprise hybrid cloud transformation. Key Protect on Satellite allows you to fully control your encryption keys by using your on-prem hardware security module (HSM). Hyper Protect Crypto Services with Unified Key Orchestrator enables you to manage keys in various key management systems, including Key Protect on Satellite, from a single pane of glass.

Hyper Protect Crypto Services Key Protect

+3

Satellite,IBM Cloud Databases,Activity Tracker hosted event search



* 2 hours
* 2023-06-27



[Encrypting images for content confidentiality](https://cloud.ibm.com/docs/Registry?topic=Registry-registry_encrypt)Encrypting images for content confidentiality

You can protect the confidentiality of your IBM Cloud® Container Registry images, and ensure that hosts that aren't trusted can't run the images.

Key Protect Container Registry



* 2 hours
* 2023-01-25
As the file is encrypted, you can pass it on to a cloud administrator (for example to provision the service instance) without exposing this information.





 2. Create the Hyper Protect Virtual Servers instance for your application. 

Use the Hyper Protect Virtual Servers BYOI feature to provision a Hyper Protect Virtual Servers instance for your application container image. To do so, you need the image tag from step 10.

Run the following command to provision the Hyper Protect Virtual Servers instance:

image_tag=s390x-v1-ad52e76
ibmcloud hpvs instance-create securewallet lite-s dal13 --rd-path sbs.enc --hostname sbs.example.com -i $image_tag

securewallet defines the name of the instance to be created, lite-s is the pricing plan, and dal13 is the location - you can use a different value for these parameters.

This command starts instance provisioning and displays the following output:

OK
Provisioning request for service instance 'crn:v1:bluemix:public:hpvs:dal13:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::' was accepted.
To check the provisioning status run:
ibmcloud hpvs instance crn:v1:bluemix:public:hpvs:dal13:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::

Use the command listed in the output to check the provisioning status of your service instance:

ibmcloud hpvs instance crn:v1:bluemix:public:hpvs:dal13:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx::

Wait until your service instance is successfully provisioned. After the Hyper Protect Virtual Servers instance is provisioned, you can view it in your IBM Cloud resource list.

The ibmcloud hpvs instance command prints detailed information about the instance that includes its public IP address.
When you create an allowed IP policy, you can access your Key Protect instance via public endpoint as long as the requesting IP address is on the list of approved IPv4 or IPv6 addresses associated with the policy. If you send a request to your instance through an unauthorized IP address, you will receive a HTTP 401 error stating that you are unauthorized to make a request to the Key Protect instance.

Only IPv4 addresses will be accepted via private endpoints. If your private network gateway has both an IPv4 and an IPv6 address, it is recommended that you include the --ipv4 flag in all of your curl requests to ensure that the requests are resolved to IPv4.

The following example shows how to utilize the --ipv4 flag in a GET keys request to a public endpoint.

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

When using the --ipv4 flag, the flag should come before the -X flag to avoid running into issues with the curl request.





 Accessing an instance via private endpoint 

When you create an allowed IP policy, Key Protect assigns a private endpoint port to your policy. Once you retrieve the port, the port value must be appended to the private service hostname in your request to your Key Protect instance via a Key Protect private service endpoint.

The private endpoint port should only be used when accessing your Key Protect instance via a private service endpoint.

Only IPv4 addresses will be accepted via private endpoints. If your private network gateway has both an IPv4 and an IPv6 address, it is recommended that you include the --ipv4 flag in all of your curl requests to ensure that the requests are resolved to IPv4.

ipWhitelist has been deprecated and replaced with allowedIP. If there isn't a query parameter specified in your GET instance policies request, you will see duplicate records when you retrieve your allowed IP policy.
PL-4 (1) - Social Media and Networking Restrictions 



  Control requirements 

PL-4 (1) - 0
:   The organization includes in the rules of behavior, explicit restrictions on the use of social media/networking sites and posting organizational information on public websites.





  Additional IBM Cloud for Financial Services specifications 



*  Restrictions on the use of social media/networking sites must include that customer data must not be processed, stored, or transmitted to open/global social spaces or collaboration sites. Any customer data discovered must be deleted and/or restricted to authorized personnel.
*  Customer data must not be processed, stored, or transmitted to social media/networking sites without explicit customer approval.







  NIST supplemental guidance 

This control enhancement addresses rules of behavior related to the use of social media/networking sites: (i) when organizational personnel are using such sites for official duties or in the conduct of official business; (ii) when organizational information is involved in social media/networking transactions; and (iii) when personnel are accessing social media/networking sites from organizational information systems. Organizations also address specific rules that prevent unauthorized entities from obtaining and/or inferring non-public organizational information (e.g., system account information, personally identifiable information) from social media/networking sites.
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/openshift?topic=openshift-securitynetwork_segmentation).
* VPC network: See [Network segmentation and privacy for VPC clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-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/openshift?topic=openshift-network_policies).
* Red Hat OpenShift resources for pod-level control: See [Configuring security context constraints (SCCs)](https://cloud.ibm.com/docs/openshift?topic=openshift-openshift_sccoc_sccs).











 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 Red Hat OpenShift on IBM Cloud.
Fields are not guaranteed to appear unless the request is successful.

The list of sensitive field values that are hidden using the [redacted] placeholder:



* service_principal_password
* secret_access_key
* access_key_id
* api_key





 Common fields 

Some common fields are available for Hyper Protect Crypto Services to use outside of the CADF event model to provide more insight into your data.



Table 12. Common fields in Activity Tracker events for Hyper Protect Crypto Services service actions

 Field Description 

 requestData.requestURI The URI of the API request that was made. 
 requestData.instanceID The unique identifier of your Hyper Protect Crypto Services service instance. 



For more information about the event fields in the Cloud Auditing Data Federation (CADF) event model, see [Event Fields](https://cloud.ibm.com/docs/activity-tracker?topic=activity-tracker-event).

While initiator.host.address is a field that is part of the Cloud Auditing Data Federation model, the host address field is not shown for requests made through private networks.





 Registration events 



 List registrations 

The following field includes extra information:



* The responseData.totalResources field includes the total number of registrations that are returned in the response.









 Trusted Key Entry events 

The following table lists the returned values that indicate a successful TKE event.



Table 13. Returned values of a successful TKE event

 Field name Returned value 

 outcome success 
 reason.reasonCode 200 
 reason.reasonType OK 



The following common fields for TKE events include extra information:



* The requestData.location field includes the specific location of the crypto unit. The location follows this format:

[region].[availability zone].[hardware security module (HSM) module index].[HSM domain index].

For example, if you provision your instance in the us-east region, the value that is returned is similar to [us-east].[AZ2-CSSTAG2].[03].[22].
Securing your connection 

To ensure that you have enhanced control and security over your data when you use IBM Cloud Monitoring, you have the option of using private routes to IBM Cloud service endpoints. Private routes are not accessible or reachable over the internet. By using the IBM Cloud private service endpoints feature, you can protect your data from threats from the public network and logically extend your private network.



* You can configure the Monitoring agent to only use private endpoints.
* You can configure the Monitoring instance to only allow API calls through the private endpoints.



The Monitoring service can be configured to send and receive data on either public-only or private-only endpoints. The web UI is available only on the public endpoint.



 Before you begin 

Some factors that you must consider when you must decide which network to choose are:



* Corporate requirements on how services and applications can access cloud-based services in your account
* Security on production workloads
* Industry compliance regulations



For example, you might have the following requirements when you are working in the IBM Cloud:



* No access to Internet to connect to IBM Cloud services
* Isolated connectivity for workloads in your account



When you have these requirements, you should move from the public network to the private network.

You can configure a Monitoring agent to connect to a Monitoring instance through the public network or through the private network. By default, the agent connects through the public network.

You can make API calls through the public network or through the private network. By default, you make them through the public network.

The type of network defines the level of isolation and security that is configured to move workloads between cloud-based resources in your account. Consider connecting the Monitoring agent over the private network.





 Setting up private service endpoints 

Private network endpoints support routing services over the IBM Cloud private network instead of the public network. A private network endpoint provides a unique IP address that is accessible to you without a VPN connection.



 Step 1: Enabling your account 

If you want to use connections over the public internet, you do not have to enable Service Endpoints on your IBM Cloud account.
Security and Compliance 



 Protection Against Unauthorized Access 

IBM Cloud® Databases for etcd use the following methods to protect data in transit or in storage.



* All Databases for etcd connections use TLS/SSL encryption for data in transit. The current supported version of this encryption is TLS 1.2.
* Access to the Account, Management Console UI, and API is secured via [Identity and Access Management (IAM)](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-iam).
* Access to the database is secured through the standard access controls provided by the database. These access controls are configured to require valid database-level credentials that are obtainable only through prior access to the database or through our Management Console UI or API.
* All Databases for etcd storage is provided on storage encrypted with LUKS using AES-256. The default keys are managed by [Key Protect](https://cloud.ibm.com/docs/key-protect?topic=key-protect-about). Bring-your-own-key (BYOK) for encryption is also available through [Key Protect Integration](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-key-protect).
* IP allowlisting - All deployments support [allowlisting IP addresses](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-allowlisting) to restrict access to the service.
* Public and Private Networking - Databases for etcd is integrated with [Service Endpoints](https://cloud.ibm.com/docs/databases-for-etcd?topic=cloud-databases-service-endpoints). You can select whether to use connections over the public network, the IBM Cloud internal network, or both.
* Dedicated Cores - Allocating dedicated cores to your deployment introduces hypervisor-level isolation to your database instance by using isolated virtual machines to ensure that your data processing remains separated from other customers. It also provides a guaranteed minimum number of CPUs to your deployment.
To protect the servers in the secure private network from being exposed on the public Internet, Source NAT is used where the source address is obfuscated and firewall rules are used to secure the out-bound application repository requests. All inbound requests are denied.



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



This tutorial can be followed without change. In the next step the NAT configuration will be used to access the required Nginx and MySQL modules.





 Step 3: Deploy scalable web app and load balancer 

A Wordpress installation on Nginx and MySQL, with an Load Balancer is used to illustrate how a scalable and resilient web application can be deployed in the secure private network

This tutorial walks you through this scenario with the creation of a IBM Cloud load balancer, two web application servers and one MySQL database server. The servers are deployed into the APP zone in the secure private network to provide firewall separation from other workloads and the public network.



* [Use Virtual Servers to build highly available and scalable web app](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-highly-available-and-scalable-web-application)



There are three changes from this tutorial:



1. The virtual servers used in this tutorial are deployed onto the VLAN and subnet protected by the APP firewall zone behind the VRA.
2. Specify the <Private VLAN ID> when ordering the virtual servers. See the [Order the first virtual server](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosuresecure-network-enclosure-order_virtualserver) instructions in the [Isolate workloads with a secure private network](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-secure-network-enclosure) tutorial for details of how to specify the <Private VLAN ID> when ordering a virtual server.
--default-trusted-profile "Profile-9fd84246-7df4-4667-94e4-8ecde51d5ac5" --default-trusted-profile-auto-link false





 Enable secure access by using the CLI 

You can enable secure access to the instance metadata service. When secure access is enabled, the metadata service is accessible only to the virtual server instance by encrypted HTTP Secure protocol (HTTPS). When secure access is disabled the metadata service is accessible only to the virtual server instance by unencrypted HTTP protocol. Secure access is disabled by default.

Certain properties might be required in the following scenarios:



* You are using the IBM Cloud CLI Virtual Server Instance for VPC compute resource identity login method. For more information, see [Logging in as a Virtual Server Instance Compute Resource Identity](https://cloud.ibm.com/docs/cli?topic=cli-vsi-cri-login).
* You are using the IBM Cloud SDK with [VPC Instance Authentication](https://github.com/IBM/ibm-cloud-sdk-commonauthentication) inside an instance with secure access to the instance metadata service enabled. For more information, see [IBM Cloud Go SDK](https://github.com/IBM/go-sdk-core/blob/main/Authentication.mdvpc-instance-authentication).





 Enable secure access when you provision an instance 

To enable secure access when you provision an instance, specify a value for the --metadata-service-protocol option when you use the instance-create command. For secure access specify https. The default setting is unencrypted http.

ibmcloud is instance-create INSTANCE_NAME VPC ZONE_NAME PROFILE_NAME SUBNET ... [--metadata-service-protocol http | https] ...

--metadata-service-protocol value : The communication protocol to use for the metadata service
endpoint. Applies only when the metadata service is enabled. One of: http, https. (default: "http")
AppArmor profiles can't be changed by the user or owner of the machine.

SSH disabled
: By default, SSH access is disabled on the worker node to protect your cluster from malicious attacks. When SSH access is disabled, access to the cluster is forced via the Kubernetes API server. The Kubernetes API server requires every request to be checked against the policies that are set in the authentication, authorization, and admission control module before the request is executed in the cluster.
: If you have a standard cluster and you want to install more features on your worker node, you can choose between the add-ons that are provided by IBM Cloud Kubernetes Service or use [Kubernetes daemon sets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) for everything that you want to run on every worker node. For any one-time action that you must execute, use [Kubernetes jobs](https://kubernetes.io/docs/concepts/workloads/controllers/job/).







 Network 

The classic approach to protect a company's network is to set up a firewall and block any unwanted network traffic to your apps. While this is still true, research shows that many malicious attacks come from insiders or authorized users who misuse their assigned permissions.



 Network segmentation and privacy for classic clusters 

To protect your network and limit the range of damage that a user can do when access to a network is granted, you must make sure that your workloads are as isolated as possible and that you limit the number of apps and worker nodes that are publicly exposed.





 What network traffic is allowed for my Classic cluster by default? 

All containers are protected by [predefined Calico network policy settings](https://cloud.ibm.com/docs/containers?topic=containers-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 with the following exceptions: