vania-janet/multiturn-rag-retrieval-data huggingface dataset:
Secure boot with Trusted Platform Module (TPM) for bare metal servers 

Secure boot makes sure that your server starts with trusted software by verifying the signatures for all code in the boot process. So, your images need to support secure boot with a signed boot loader. Trusted Platform Module (TPM) provides hardware-based security functions. With supporting software, TPM helps maintain platform integrity and generates cryptographic keys. Generally, TPM is used with secure boot.

Servers that you provisioned before this feature was released aren't supported.



 Supported images for secure boot 

The following images are available when you provision a server with secure boot. Keep in mind that these features are available on only the x86-64 architecture.



Table 1. Supported operating systems for secure boot

 Image Architecture 

 Red Hat Enterprise Linux 8 x86-64 
 Red Hat Enterprise Linux 8.4 for SAP x86-64 
 Red Hat Enterprise Linux 8.4 for SAP HANA x86-64 
 SUSE Linux Enterprise server (SLES) 15 SP3 x86-64 
 SUSE Linux Enterprise server (SLES) 15 SP4 x86-64 
 Ubuntu 18.04, 20.04, 22.04 x86-64 
 VMWare ESXi 7 x86-64 
 Windows 2016, 2019, 2022 x86-64 







 Limitations 

Consider the following limitations before you enable secure boot and TPM.



* Servers that you provisioned before this feature was released aren't supported.
* Secure boot requires a signed OS. If you enable secure boot without a signed OS, the server can't boot.
* Secure boot and TPM are available on only x86 servers.
* ESXi images require secure boot to use TPM.







 Enable secure boot with TPM 

When you create or update a server, you can specify whether you want to enable secure boot. You can find the secure boot and TPM selections in the Advanced options on the provisioning page.

To use secure boot or TPM on an existing supported server, you can enable them from the server details page.

To enable secure boot or TPM, the server needs to be powered off.



 Keys that are stored in BIOS firmware
Zero trust model 

IBM Cloud for VMware® Regulated Workloads is designed following the concept of a zero trust model. Wherever practical, the scope of action of any one individual administrator is strictly limited to those actions necessary and appropriate to perform their assigned roles. Overlap of duties is minimized or eliminated to prevent the need for privilege escalation. The escalation can result in undesired flows of information in or out of any layer of the IBM Cloud for VMware Regulated Workloads.

Zoom

![IBM Cloud for VMware Regulated Workloads roles](https://cloud.ibm.com/docs-content/v1/content/5bdb37c0149145723c5437e8176651928565e722/vmwaresolutions/images/vrw-boundary.svg)

Figure 1. IBM Cloud for VMware Regulated Workloads roles



 Network and security administrator roles 

The vCenter Server model employs a single network administrator role responsible for management across all network components (such as the underlay network, vSRX, and NSX-T™).

The IBM Cloud for VMware Regulated Workloads network administrator role must break out to multiple discrete administrator roles to prevent such a situation.

The following roles are suggested network and security admin roles:



* IaaS security administrator - The IaaS security administrator role is focused on protection of all platform infrastructure components from threats that can originate on the network. The scope of responsibility includes the security objects necessary to secure and control access to the management and edge layers of the IBM Cloud for VMware Regulated Workloads. These objects include the ESXi hosts that deliver compute and storage resources to the user workloads. The IaaS security administrator is also afforded necessary access to the IBM Cloud console to deploy and manage network gateway devices. The IaaS security administrator might play a role in managing NSX-T security objects if those objects impact the security of the management and edge layers of the IBM Cloud for VMware Regulated Workloads. It is recommended that consideration is given to whether enabling the IaaS security administrator access to the NSX-T platform introduces unacceptable risk.
-s, --server
: The server ID to associate with the security group.

-i, --interface
: The interface of the server to associate (public or private).





 ibmcloud sl securitygroup interface-list 

List interfaces associated with security group:

ibmcloud sl securitygroup interface-list SECURITYGROUP_ID [OPTIONS]

Command options:

--sortby
: Column to sort by. Options are: id,virtualServerId,hostname.





 ibmcloud sl securitygroup interface-remove 

Detach an interface from a security group:

ibmcloud sl securitygroup interface-remove SECURITYGROUP_ID [OPTIONS]

Command options:

-n, --network-component
: The network component to remove from the security group.

-s, --server
: The server ID to remove from the security group.

-i, --interface
: The interface of the server to remove (public or private).





 ibmcloud sl securitygroup list 

List security groups:

ibmcloud sl securitygroup list [OPTIONS]

Command options:

--sortby
: Column to sort by. Options are: id,name,description,created.





 ibmcloud sl securitygroup rule-add 

Add a security group rule to a security group:

ibmcloud sl securitygroup rule-add SECURITYGROUP_ID [OPTIONS]

Command options:

-r, --remote-ip
: The remote IP/CIDR to enforce.

-s, --remote-group
: The ID of the remote security group to enforce.

-d, --direction
: The direction of traffic to enforce (ingress or egress), required.

-e, --ether-type
: The ethertype (IPv4 or IPv6) to enforce, default is IPv4 if not specified.

-M, --port-max
: The upper port bound to enforce.

-m, --port-min
: The lower port bound to enforce.

-p, --protocol
: The protocol (icmp, tcp, udp) to enforce.
Learning about Security and Compliance Center architecture and workload isolation 

Review the following architecture for IBM Cloud® Security and Compliance Center, and learn more about different isolation levels, so that you can choose the solution that best meets the requirements of the workloads that you want to run in the cloud.



  Security and Compliance Center architecture 

Security and Compliance Center is a multi-tenant, regional service that is fully integrated with the IBM Cloud platform. The IBM-managed components of the Security and Compliance Center are organized to provide compute isolation between workloads.

Check out the following image to see how the service workloads are isolated and managed.

Zoom

![This image shows the workload isolation for the Security and Compliance Center service.](https://cloud.ibm.com/docs-content/v1/content/a6478671e8f845a84102d9cf49bf28ee7f4f3227/security-compliance/images/architecture.svg)

Figure 1. Workload isolation

IBM

Customer



Table 1. IBM-managed components of the Security and Compliance Center

 Component      Description                                                                                                                                                                                                                                   

 Control plane  The microservices that make up the individual components of the service run in the control plane, where they are isolated from the other components. Additionally, internal dependencies are run and isolated as part of the control plane.   
 Data plane    







  Security and Compliance Center workload isolation 

Each regional deployment of the Security and Compliance Center serves multiple tenants and can be accessed through public endpoints. By default, all data at rest is encrypted by IBM keys. Data in transit is encrypted by using TLS. Your data is isolated from other customer's data but does share physical resources such as CPU, memory, and I/O devices.
1. Click Security groups under Network, then click Create.
2. Enter vpc-secure-private-sg as name and select the VPC you created earlier.
3. Click Create security group.







 Create a virtual server instance 

To create a virtual server instance in the newly created subnet:



1. Click on the subnet vpc-secure-private-subnet created earlier under Subnets.
2. Click Attached resources, under Attached instances, click Create.
3. To configure the instance:



1. Enter a unique name, vpc-secure-private-vsi and resource group as earlier.
2. Select the same Location already used by the bastion virtual server.
3. Select Public type of virtual server.
4. Set the Operating System to Ubuntu Linux. You can pick any version of the image.
5. Select Compute (2 vCPUs and 4 GB RAM) as your profile. To check other available profiles, click View all profiles.
6. For SSH keys pick the SSH key you created earlier for the bastion.



4. Scroll to Networking and select the VPC your created.
5. Under Network interfaces, click on the Edit icon



* Select vpc-secure-private-subnet as the subnet.
* Uncheck the default security and group and activate vpc-secure-private-sg.
* Click Save.



6. Click Create virtual server instance.







 Add virtual server instance(s) to the maintenance security group 

For administrative work on the servers, you have to associate the specific virtual servers with the maintenance security group. In the following, you will enable maintenance, log into the private server, update the software package information, then disassociate the security group again.

Let's enable the maintenance security group for the server.



1. Navigate to Security groups and select vpc-secure-maintenance-sg security group.
2. Click on theAttached resources tab, then Edit interfaces.
3.
set security vpn ipsec site-to-site peer 169.47.243.43 local-address '50.23.177.59'
set security vpn ipsec site-to-site peer 169.47.243.43 tunnel 1 local prefix '172.16.100.1/30'
set security vpn ipsec site-to-site peer 169.47.243.43 tunnel 1 remote prefix '172.16.200.1/30'

This sets up a generic tunnel that routes 172.16.x.x traffic between the two machines. Machine B has 172.16.100.1 as a loopback address to provide an endpoint to test with, while Machine A has a virtual machine on a routed VLAN to provide source traffic across the tunnel.

You can see the results here:

[root@acs-jmat-migserver ] ping -c 5 172.16.100.1
PING 172.16.100.1 (172.16.100.1) 56(84) bytes of data.
64 bytes from 172.16.100.1: icmp_seq=1 ttl=63 time=44.5 ms
64 bytes from 172.16.100.1: icmp_seq=2 ttl=63 time=44.6 ms
64 bytes from 172.16.100.1: icmp_seq=3 ttl=63 time=44.8 ms
64 bytes from 172.16.100.1: icmp_seq=4 ttl=63 time=44.9 ms
64 bytes from 172.16.100.1: icmp_seq=5 ttl=63 time=44.6 ms
--- 172.16.100.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 44.578/44.750/44.993/0.244 ms

This illustrates bidirectional traffic across this IPsec tunnel. Next, you can apply a simple "allow all" zone policy to all interfaces on Machine A:

set security firewall name ALLOWALL default-action 'drop'
Provisioning an instance 

You can provision an instance of the IBM Cloud Security and Compliance Center Workload Protection service in IBM Cloud to add capability in your account to detect and investigate threats, prioritize risks, and help identify compliance anomalies and ongoing threats to your environments.



 Provisioning an instance from the catalog 

To provision an instance from the IBM Cloud catalog, complete the following steps:



1. [Log in to the IBM Cloud console](https://cloud.ibm.com/login).
2. Click Catalog. The list of the services that are available on IBM Cloud opens.
3. To filter the list of services that is displayed, select the Security category.
4. Click the IBM Cloud Security and Compliance Center Workload Protection tile.
5. Select Create.
6. Select the location.
7. Select a service plan.

For more information about the service plans, see [Service plans](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-pricing_planspricing_plans).
8. Enter a service name.
9. Select a resource group. By default, the Default resource group is set.
10. Optionally, you can add tags and access management tags.
11. Click Create.







 Provisioning an instance through the CLI 

To provision an instance through the command line, complete the following steps:



1. [Pre-requisite] [Installion of the IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-install-ibmcloud-cli). If the CLI is installed, continue with the next step.
2. Log in to the region in the IBM Cloud where you want to provision the instance. Run the following command: [ibmcloud login](https://cloud.ibm.com/docs/cli?topic=cli-ibmcloud_cliibmcloud_login)
3. Set the resource group where you want to provision the instance.
* Enable an inbound rule for SSH traffic to bastion server * Enable specific ports for the corresponding application of each tier. For example, if the front-end server needs HTTPs, then a security group is needed to allow for 443.

To create the security groups:



1. Go to Security groups.
2. Verify that the Regions setting is correct and if not then select the correct region, for example: Sydney
3. Click Create.
4. Create the security group bastion-sg:



1. Set the VCP to vpc-some-application
2. Select your Resource group
3. Add one Inbound rule: Set Protocol to TCP, Port Min and Max to 22, and Source Type to Any.
4. Add one Outbound rule: Set Protocol to All and Destination type to Any.
5. Click Create security group



5. Click Create.
6. Create the security group web-sg:



1. Set the VPC to vpc-some-application
2. Select your Resource group
3. Add two Inbound rules:



* Set Protocol to TCP, Port Min and Max to 22, and Source Type to Any.
* Set Protocol to TCP, Port Min and Max to 443, and Source Type to Any.



4. Add one Outbound rule: set the Protocol to All and Destination type to Any.
5. Click Create security group.



7. Create security groups for app and db. Use these guidelines:



* Allow SSH (port 22) for bastion access.
* If web access is required, then use HTTPS (port 443) for secure communication.
* Add any additional specific ports required for the respective tiers. *Avoid allowing all. Instead, create an allow list.









 Step 4: Create placement groups 

Placement groups guarantee the VSI are not created on the same hypervisor. For this example, we create placement groups with power spread. If you have more than 4 VSIs in a placement group, then you need to use hypervisor spread.
Enhance cloud security by applying context-based restrictions 

This tutorial may incur costs. Use the [Cost Estimator](https://cloud.ibm.com/estimator/review) to generate a cost estimate based on your projected usage.

This tutorial walks you through the process of implementing [context-based restrictions](https://cloud.ibm.com/docs/account?topic=account-context-restrictions-whatis) (CBRs) in your IBM Cloud account. CBRs help you to secure the cloud environment further and move towards a [zero trust security model](https://en.wikipedia.org/wiki/Zero_trust_security_model).

The tutorial discusses how to create network zones and context rules and how to verify that they work. In the tutorial, you learn how to create the CBR objects both in the browser console and as Infrastructure as Code with Terraform. You will also learn about criteria on how to define the access strategy for your cloud resources.



 Objectives 



* Learn about context-based restrictions to protect your cloud resources
* Define network zones to identify traffic sources for allowed and denied access
* Create rules that define context for access to your cloud resources
* Know how to test and monitor context rules



The following diagram shows the solution architecture as used in the tutorial [Apply end to end security to a cloud application](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-cloud-e2e-security). The additional boxes with dashed, blue lines around the Kubernetes Service cluster, Container Registry, Key Protect, and Object Storage denote context-based restrictions implemented as context rules. Note that Secrets Manager could have been protected, too, but is only an optional service and not used in this tutorial.

Zoom

![Architecture](https://cloud.ibm.com/docs-content/v1/content/f84e2238288b7f0355715a4c355609ce7ac48fb0/solution-tutorials/images/solution67-cbr-enhanced-security/architecture-e2e-security-cbr.svg)

Solution architecture
Captures 

IBM Cloud® Security and Compliance Center Workload Protection capture files contain system calls and other OS events that can be analyzed with either the open source sysdig or csysdig utilities. Files are displayed in the captures module.

IBM Cloud Security and Compliance Center Workload Protection implements Sysdig Secure functionality. Information that is provided by the Sysdig Secure documentation applies to Workload Protection as well.

For more information, see [Captures](https://docs.sysdig.com/en/docs/sysdig-secure/investigate/captures/)
AC-20 (1) - Limits On Authorized Use 



  Control requirements 

The organization permits authorized individuals to use an external information system to access the information system or to process, store, or transmit organization-controlled information only when the organization:

AC-20 (1) (a)
:   Verifies the implementation of required security controls on the external system as specified in the organization’s information security policy and security plan; or

AC-20 (1) (b)
:   Retains approved information system connection or processing agreements with the organizational entity hosting the external information system.





  NIST supplemental guidance 

This control enhancement recognizes that there are circumstances where individuals using external information systems (e.g., contractors, coalition partners) need to access organizational information systems. In those situations, organizations need confidence that the external information systems contain the necessary security safeguards (i.e., security controls), so as not to compromise, damage, or otherwise harm organizational information systems. Verification that the required security controls have been implemented can be achieved, for example, by third-party, independent assessments, attestations, or other means, depending on the confidence level required by organizations.
Firewall Allowlist 

If you use allowlists to control connections in your environment, you can use the following IP lists to allowlist Db2 on Cloud deployments. You should allowlist all of the subnet ranges for the entire region that your deployments live in.

As new clusters in a region are created, there will be additional IP ranges that will be added. If an existing Db2oC customer adds a new instance, it may be necessary to add these new IP ranges into the firewall rules.



 Dallas List 



 Subnet Location 

 52.116.179.72/29 Dal 10 
 169.47.221.160/29 Dal 10 
 169.48.136.32/29 Dal 10 
 169.61.233.8/29 Dal 10 
 52.117.144.16/29 Dal 10 
 169.46.44.40/29 Dal 10 
 169.46.55.64/29 Dal 10 
 169.47.195.32/29 Dal 10 
 52.116.221.96/29 Dal 12 
 169.59.195.128/29 Dal 12 
 169.61.143.48/29 Dal 12 
 169.61.156.232/29 Dal 12 
 52.117.238.40/29 Dal 13 
 52.117.249.176/29 Dal 13 
 169.61.51.96/29 Dal 13 
 169.62.167.128/29 Dal 13 
 52.116.3.56/29 Dal 13 
 169.48.70.200/29 Dal 13 
 169.60.146.120/29 Dal 13 
 169.60.154.184/29 Dal 13 
 169.60.164.88/29 Dal 13 







 Frankfurt List 



 Subnet Location 

 159.122.98.248/29 Fra 02 
 159.122.121.232/29 Fra 02 
 169.50.5.8/29 Fra 02 
 161.156.8.168/29 Fra 04 
 161.156.91.56/29 Fra 04 
 161.156.103.32/29 Fra 04 
 149.81.98.128/29 Fra 05 
 149.81.142.0/29 Fra 05
If you're using firewalls, you must configure rules for all communications from the IBM® CloudDriver virtual server instance (VSI) and the SDDC Manager virtual machines (VMs). These rules must allow all protocols to communicate on the IP addresses 10.0.0.0/8 and 161.26.0.0/16. Examples of such firewalls are NSX Distributed Firewalls (DFW) or vSRX gateway cluster firewalls.

Some components might attempt to connect to the public network, although they are deployed to your private network. In some cases, such as Zerto Virtual Replication or FortiGate-VM, this connection is required for licensing or to report usage. These components are configured to connect either by using the instance NAT or a proxy you provide. You might need to allow these connections in your firewall. In other cases, these connection attempts are only for diagnostic and usage data, and the connections fail since no public connectivity is available or configured.
* Using NSX with your virtual machines

During vCenter Server instance deployment, VMware NSX® is ordered, installed, licensed, and configured in your instance. Also, NSX Manager, VMware NSX Controllers™, and NSX Transport Zone are set up, and each VMware ESXi™ server is configured with the NSX components.

An VMware NSX Edge™ Services Gateway is also deployed to be used by your workload VM or VMs. For more information, see [Configuring your network to use the customer-managed NSX ESG with your VMs](https://cloud.ibm.com/docs/vmwaresolutions?topic=vmwaresolutions-vc_esg_config).
* Considerations when you change passwords for NSX-T components

 Considerations when you change passwords for NSX-T components 



* Do not change the NSX Manager admin password for NSX-T.
* You can change the NSX Manager root password. This password is not displayed in the VMware Solutions console. However, the password is the same as the one for the root user for NSX Controllers, which is displayed in the console.
* For NSX-V - vxw-dvs-17-virtualwire-1-sid-6000-Workload





Ensure that you do not select the Workload Transit switch.
2. Identify an available IP address for the VM:



* The IP address must be in the range of 192.168.10.0/24. The IP address 192.168.10.1 is reserved (see Step 3).
* When you configure the networking of the operating system that runs on the VM, use the selected IP address and the netmask 255.255.255.0.



You are responsible for managing the range of IP addresses to which you assigned your VMs.
3. Assign the default gateway of the VM as 192.168.10.1. For NSX-T, this address is the IP address of the downlink router port on the customer Tier 1 logical router. The address is connected to the same overlay logical switch as the workload VMs. For NSX-V, this address is the IP address of the NSX DLR on the same logical switch as the workload VMs.







 Enabling the SNAT rule for NSX-T 

NSX-T enables the SNAT rule by default. For more information about modifying the existing rules, see [Configure source and destination NAT on a Tier-0 logical router](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.4/administration/GUID-45949ACD-9029-4674-B29C-C2EABEB39E1D.html).





 Enabling the firewall rule for NSX-T 

NSX-T disables all traffic through the workload NSX edge rule by default. To allow VMs to use the SNAT rule described in the previous section, you must create a firewall policy and rule to define and allow the traffic.
<-- <ul> -->

* expression: A filter expression. For example, ip.src eq 93.184.216.0
* action: The rule action to perform. Valid values: log, allow, challenge, js_challenge, block, bypass.

<-- </ul> -->

* The optional fields are description, priority, paused, products.

<-- <ul> -->

* description: To briefly describe the rule.
* priority: The rule's priority. Valid values: 0 2147483647. Value 0 means to set to the default value.
* paused: Indicates if the rule is active. Valid values: on, off.Default value is off.
* products: The list of security products to be bypassed. Valid values: zoneLockdown, uaBlock, bic, hot, securityLevel, rateLimit, waf For example: --products zoneLockdown,rateLimit

<-- </ul> -->

<-- </ul> -->

Sample JSON data:
{
"expression": "ip.src eq 93.184.216.1 and http.request.uri.path "^./wp-login.php$"",
"action": "allow",
"priority": 100,
"paused": false,
"description": "do not challenge login from office"
}
-s, --json-str: Deprecated. The JSON data describing a firewall-rule.-j, --json-file: Deprecated. A file contains input JSON data.-i, --instance: Instance name or ID.