🛡️ Google Project has API Keys🟢

• Contextual name: 🛡️ Google Project has API Keys🟢
• ID: /ce/ca/google/project/api-keys-for-active-services
• Tags:
  • 🟢 Policy with categories
  • 🟢 Policy with type
  • 🟢 Production policy
• Policy Type: COMPLIANCE_POLICY
• Policy Categories: SECURITY

Logic

• 🧠 prod.logic.yaml🟠🟢
  • 📗 Google Project
  • 🧪 test-data.json

Similar Policies

• Cloud Conformity: API Keys Should Only Exist for Active Services

Description

Open File

Description

API Keys should only be used for services in cases where other authentication methods are unavailable. Unused keys with their permissions in tact may still exist within a project. Keys are insecure because they can be viewed publicly, such as from within a browser, or they can be accessed on a device where the key resides. It is recommended to use standard authentication flow instead.

Rationale

To avoid the security risk in using API keys, it is recommended to use standard authentication flow instead. Security risks involved in using API-Keys appear below:

• API keys are simple encrypted strings
• API keys do not identify the user or the application making the API request
• API keys are typically accessible to clients, making it easy to discover and steal an API key

Impact

Deleting an API key will break dependent applications (if any).

Audit

From Console

1. From within the Project you wish to audit Go to APIs & Services\Credentials.
2. In the section API Keys, no API key should be listed.

... see more

Remediation

Open File

Remediation

From Console

1. Go to APIs & Services\Credentials
2. In the section API Keys, to delete API Keys: Click the Delete Bin Icon in front of every API Key Name.

From Google Cloud Command Line

1. Run the following from within the project you wish to audit

   gcloud services api-keys list --filter

2. Pipe the results into

   gcloud alpha services api-keys delete

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags	Compliance
💼 CIS GCP v2.0.0 → 💼 1.12 Ensure API Keys Only Exist for Active Services - Level 2 (Automated)			1		no data
💼 CIS GCP v3.0.0 → 💼 1.12 Ensure API Keys Only Exist for Active Services - Level 2 (Automated)			1		no data
💼 Cloudaware Framework → 💼 Cryptographic Configuration			8		no data
💼 FedRAMP High Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP High Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 FedRAMP Low Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP Low Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 FedRAMP Moderate Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3		no data
💼 FedRAMP Moderate Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6		no data
💼 ISO/IEC 27001:2022 → 💼 8.27 Secure system architecture and engineering principles		1	4		no data
💼 NIST CSF v1.1 → 💼 PR.IP-2: A System Development Life Cycle to manage systems is implemented		6	9		no data
💼 NIST CSF v2.0 → 💼 ID.AM-03: Representations of the organization's authorized network communication and internal and external network data flows are maintained			69		no data
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles			25		no data
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations			26		no data
💼 NIST CSF v2.0 → 💼 ID.IM-02: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties			40		no data
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities			41		no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected			142		no data
💼 NIST CSF v2.0 → 💼 PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations			15		no data
💼 NIST SP 800-53 Revision 5 → 💼 PL-8 Security and Privacy Architectures	2		3		no data
💼 NIST SP 800-53 Revision 5 → 💼 SA-8 Security and Privacy Engineering Principles	33		8		no data
💼 PCI DSS v3.2.1 → 💼 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.	1		9		no data
💼 PCI DSS v3.2.1 → 💼 6.3 Develop internal and external software applications securely.	2		4		no data
💼 PCI DSS v4.0.1 → 💼 2.2.2 Vendor default accounts are managed.			9		no data
💼 PCI DSS v4.0.1 → 💼 6.2.1 Bespoke and custom software are developed securely.			3		no data
💼 PCI DSS v4.0 → 💼 2.2.2 Vendor default accounts are managed.			9		no data
💼 PCI DSS v4.0 → 💼 6.2.1 Bespoke and custom software are developed securely.			3		no data