Skip to main content

🛡️ 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
  • Tags:
  • Policy Type: COMPLIANCE_POLICY
  • Policy Categories: SECURITY

Logic​

Similar Policies​

Description​

Open File

Description​

It is recommended to use instance-specific SSH keys instead of common or shared project-wide SSH keys to access instances.

Rationale​

Project-wide SSH keys are stored in Compute project metadata. Project-wide SSH keys can be used to log in to all instances within a project. Using project-wide SSH keys eases SSH key management, but if compromised, it poses a security risk that can impact all instances within the project. It is recommended to use instance-specific SSH keys to limit the attack surface if SSH keys are compromised.

Impact​

Users who already have project-wide SSH key pairs and use third-party SSH clients will lose access to affected instances. For project users using gcloud or the GCP Console-based SSH option, no manual key creation and distribution is required and will be handled by GCE (Google Compute Engine). To access instances using third-party SSH clients, instance-specific SSH key pairs need to be created and distributed to the required users.

Audit​

From Google Cloud Console​

... 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​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.2.0 → 💼 4.3 Ensure "Block Project-wide SSH keys" is enabled for VM instances - Level 1 (Automated)1no data
💼 CIS GCP v1.3.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)1no data
💼 CIS GCP v2.0.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)1no data
💼 CIS GCP v3.0.0 → 💼 4.3 Ensure “Block Project-Wide SSH Keys” Is Enabled for VM Instances - Level 1 (Automated)1no data
💼 Cloudaware Framework → 💼 Secure Access53no data
💼 FedRAMP High Security Controls → 💼 AC-17 Remote Access (L)(M)(H)423no data
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)61437no data
💼 FedRAMP High Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)1825no data
💼 FedRAMP Low Security Controls → 💼 AC-17 Remote Access (L)(M)(H)1no data
💼 FedRAMP Low Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)137no data
💼 FedRAMP Low Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)125no data
💼 FedRAMP Moderate Security Controls → 💼 AC-17 Remote Access (L)(M)(H)423no data
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)437no data
💼 FedRAMP Moderate Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)125no data
💼 ISO/IEC 27001:2022 → 💼 5.14 Information transfer810no data
💼 NIST CSF v1.1 → 💼 PR.DS-2: Data-in-transit is protected1653no data
💼 NIST CSF v2.0 → 💼 PR.AA-01: Identities and credentials for authorized users, services, and hardware are managed by the organization43no data
💼 NIST CSF v2.0 → 💼 PR.AA-03: Users, services, and hardware are authenticated53no data
💼 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 duties133no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected160no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-17 Remote Access101323no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-5 Authenticator Management1821no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-8 Transmission Confidentiality and Integrity5825no data
💼 PCI DSS v3.2.1 → 💼 2.3 Encrypt all non-console administrative access using strong cryptography.310no data
💼 PCI DSS v3.2.1 → 💼 4.1 Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.1828no data
💼 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.1no data
💼 PCI DSS v3.2.1 → 💼 4.2 Never send unprotected PANs by enduser messaging technologies.4no data
💼 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.1no data
💼 PCI DSS v3.2.1 → 💼 8.2.1 Using strong cryptography, render all authentication credentials unreadable during transmission and storage on all system components.14no data
💼 PCI DSS v4.0.1 → 💼 2.2.7 All non-console administrative access is encrypted using strong cryptography.10no data
💼 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.1no data
💼 PCI DSS v4.0.1 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.228no data
💼 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.1no data
💼 PCI DSS v4.0.1 → 💼 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.4no data
💼 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.14no data
💼 PCI DSS v4.0 → 💼 2.2.7 All non-console administrative access is encrypted using strong cryptography.410no data
💼 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.1no data
💼 PCI DSS v4.0 → 💼 4.2.1 Strong cryptography and security protocols are implemented to safeguard PAN during transmission over open, public networks.2928no data
💼 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.1no data
💼 PCI DSS v4.0 → 💼 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.34no data
💼 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.614no data
💼 SOC 2 → 💼 CC6.1-3 Restricts Logical Access122no data
💼 SOC 2 → 💼 CC6.1-8 Manages Identification and Authentication1824no data
💼 SOC 2 → 💼 CC6.1-11 Protects Encryption Keys69no data
💼 SOC 2 → 💼 CC6.7-2 Uses Encryption Technologies or Secure Communication Channels to Protect Data68no data