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

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 Access57no data
💼 FedRAMP High Security Controls → 💼 AC-17 Remote Access (L)(M)(H)419no data
💼 FedRAMP High Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)61432no data
💼 FedRAMP High Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)1817no 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)132no data
💼 FedRAMP Low Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)117no data
💼 FedRAMP Moderate Security Controls → 💼 AC-17 Remote Access (L)(M)(H)419no data
💼 FedRAMP Moderate Security Controls → 💼 IA-5 Authenticator Management (L)(M)(H)432no data
💼 FedRAMP Moderate Security Controls → 💼 SC-8 Transmission Confidentiality and Integrity (L)(M)(H)117no 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 organization42no 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 duties116no data
💼 NIST CSF v2.0 → 💼 PR.DS-02: The confidentiality, integrity, and availability of data-in-transit are protected125no data
💼 NIST SP 800-53 Revision 5 → 💼 AC-17 Remote Access101319no data
💼 NIST SP 800-53 Revision 5 → 💼 IA-5 Authenticator Management1816no data
💼 NIST SP 800-53 Revision 5 → 💼 SC-8 Transmission Confidentiality and Integrity5816no data
💼 PCI DSS v3.2.1 → 💼 2.3 Encrypt all non-console administrative access using strong cryptography.39no 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.1822no 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.9no 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.222no 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.49no 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.2922no 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