📝 Google GCE Instance Block Project-Wide SSH Keys is not enabled 🟢

• Contextual name: 📝 Instance Block Project-Wide SSH Keys is not enabled 🟢
• ID: /ce/ca/google/compute-engine/instance-project-wide-ssh-key
• Located in: 📁 Google GCE

Flags

• 🟢 Policy with categories
• 🟢 Policy with type
• 🟢 Production policy

Our Metadata

• Policy Type: COMPLIANCE_POLICY
• Policy Category:
  • SECURITY

Similar Policies

• Cloud Conformity
  • Enable 'Block Project-Wide SSH Keys' Security Feature

Logic

• 🧠 prod.logic.yaml 🟢
  • 📗 Google GCE Instance
  • 🔌 Google GCE Instance - object.extracts.yaml
  • 🧪 test-data.json

Description

Open File

Description

It is recommended to use Instance specific SSH key(s) instead of using common/shared project-wide SSH key(s) to access Instances.

Rationale

Project-wide SSH keys are stored in Compute/Project-meta-data. Project wide SSH keys can be used to login into all the instances within project. Using project-wide SSH keys eases the SSH key management but if compromised, poses the security risk which can impact all the instances within project. It is recommended to use Instance specific SSH keys which can limit the attack surface if the SSH keys are compromised.

Impact

Users already having Project-wide ssh key pairs and using third party SSH clients will lose access to the impacted Instances. For Project users using gcloud or GCP Console based SSH option, no manual key creation and distribution is required and will be handled by GCE (Google Compute Engine) itself. To access Instance using third party SSH clients Instance specific SSH key pairs need to be created and distributed to the required users.

Audit

... see more

Remediation

Open File

Remediation

From Google Cloud Console

1. Go to the VM instances page by visiting: https://console.cloud.google.com/compute/instances. It will list all the instances in your project.
2. Click on the name of the Impacted instance
3. Click Edit in the toolbar
4. Under SSH Keys, go to the Block project-wide SSH keys checkbox
5. To block users with project-wide SSH keys from connecting to this instance, select Block project-wide SSH keys
6. Click Save at the bottom of the page
7. Repeat steps for every impacted Instance

From Google Cloud CLI

To block project-wide public SSH keys, set the metadata value to TRUE:

        gcloud compute instances add-metadata <INSTANCE_NAME> --metadata block-project-ssh-keys=TRUE

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags
💼 CIS GCP v1.2.0 → 💼 4.3 Ensure "Block Project-wide SSH keys" is enabled for VM instances - Level 1 (Automated)			1
💼 CIS GCP v1.3.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)			1
💼 CIS GCP v2.0.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)			1
💼 CIS GCP v3.0.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)			1
💼 Cloudaware Framework → 💼 Secure Access			53
💼 FedRAMP High Security Controls → 💼 AC-17 Remote Access (L)(M)(H)	4		19
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	6	14	32
💼 FedRAMP High Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)	1	8	17
💼 FedRAMP Low Security Controls → 💼 AC-17 Remote Access (L)(M)(H)			1
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	1		32
💼 FedRAMP Low Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)	1		17
💼 FedRAMP Moderate Security Controls → 💼 AC-17 Remote Access (L)(M)(H)	4		19
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)	4		32
💼 FedRAMP Moderate Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)	1		17
💼 ISO/IEC 27001:2022 → 💼 5.14 Information transfer		8	10
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected		16	31
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization			38
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated			32
💼 NIST CSF v2.0 → 💼 PR.AA-05: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties			88
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected			94
💼 NIST SP 800-53 Revision 5 → 💼 AC-17 Remote Access	10	13	19
💼 NIST SP 800-53 Revision 5 → 💼 IA-5 Authenticator Management	18		16
💼 NIST SP 800-53 Revision 5 → 💼 SC-8 Transmission Confidentiality and Integrity	5	8	16
💼 PCI DSS v3.2.1 → 💼 2.3 Encrypt all non-console administrative access using strong cryptography.		3	8
💼 PCI DSS v3.2.1 → 💼 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.	1	8	21
💼 PCI DSS v3.2.1 → 💼 4.1.1 Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission.			1
💼 PCI DSS v3.2.1 → 💼 4.2 Never send unprotected PANs by enduser messaging technologies.			4
💼 PCI DSS v3.2.1 → 💼 4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties.			1
💼 PCI DSS v3.2.1 → 💼 8.2.1 Using strong cryptography, render all authentication credentials unreadable during transmission and storage on all system components.			14
💼 PCI DSS v4.0.1 → 💼 2.2.7 All non-console administrative access is encrypted using strong cryptography.			8
💼 PCI DSS v4.0.1 → 💼 4.1.1 All security policies and operational procedures identified in Requirement 4 are documented, kept up to date, in use, and known to all affected parties.			1
💼 PCI DSS v4.0.1 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.	2		21
💼 PCI DSS v4.0.1 → 💼 4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.			1
💼 PCI DSS v4.0.1 → 💼 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.			4
💼 PCI DSS v4.0.1 → 💼 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.			14
💼 PCI DSS v4.0 → 💼 2.2.7 All non-console administrative access is encrypted using strong cryptography.		4	8
💼 PCI DSS v4.0 → 💼 4.1.1 All security policies and operational procedures identified in Requirement 4 are documented, kept up to date, in use, and known to all affected parties.			1
💼 PCI DSS v4.0 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.	2	9	21
💼 PCI DSS v4.0 → 💼 4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission.			1
💼 PCI DSS v4.0 → 💼 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.		3	4
💼 PCI DSS v4.0 → 💼 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.		6	14
💼 SOC 2 → 💼 CC6.1-3 Restricts Logical Access		1	21
💼 SOC 2 → 💼 CC6.1-8 Manages Identification and Authentication		18	24
💼 SOC 2 → 💼 CC6.1-11 Protects Encryption Keys		6	9
💼 SOC 2 → 💼 CC6.7-2 Uses Encryption Technologies or Secure Communication Channels to Protect Data		6	8