📝 Google API Key is not rotated every 90 days 🟢

• Contextual name: 📝 API Key is not rotated every 90 days 🟢
• ID: /ce/ca/google/api/api-key-rotation
• Located in: 📁 Google API & Services

Flags

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

Our Metadata

• Policy Type: COMPLIANCE_POLICY
• Policy Category:
  • SECURITY

Similar Policies

• Cloud Conformity
  • Rotate Google Cloud API Keys

Logic

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

Description

Open File

Description

API Keys should only be used for services in cases where other authentication methods are unavailable. If they are in use it is recommended to rotate API keys every 90 days.

Rationale

Security risks involved in using API-Keys are listed 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

Because of these potential risks, Google recommends using the standard authentication flow instead of API Keys. However, there are limited cases where API keys are more appropriate. For example, if there is a mobile application that needs to use the Google Cloud Translation API, but doesn't otherwise need a backend server, API keys are the simplest way to authenticate to that API.

Once a key is stolen, it has no expiration, meaning it may be used indefinitely unless the project owner revokes or regenerates the key. Rotating API keys will reduce the window of opportunity for an access key that is associated with a compromised or terminated account to be used.

... see more

Remediation

Open File

Remediation

From Google Cloud Console

1. Go to APIs & Services\Credentials using https://console.cloud.google.com/apis/credentials
2. In the section API Keys, Click the API Key Name. The API Key properties display on a new page.
3. Click REGENERATE KEY to rotate API key.
4. Click Save.
5. Repeat steps 2,3,4 for every API key that has not been rotated in the last 90 days.

Note: Do not set HTTP referrers to wild-cards (* or *.[TLD] or .[TLD]/) allowing access to any/wide HTTP referrer(s). Do not set IP addresses and referrer to any host (0.0.0.0 or 0.0.0.0/0 or ::0)

From Google Cloud CLI

There is not currently a way to regenerate and API key using gcloud commands. To 'regenerate' a key you will need to create a new one, duplicate the restrictions from the key being rotated, and delete the old key.

1. List existing keys.

   gcloud services api-keys list

2. Note the UID and restrictions of the key to regenerate.

3. Run this command to create a new API key. <key_name> is the display name of the new key.

... see more

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags
💼 CIS GCP v1.2.0 → 💼 1.15 Ensure API keys are rotated every 90 days - Level 1 (Manual)			1
💼 CIS GCP v1.3.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 1 (Manual)			1
💼 CIS GCP v2.0.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 2 (Automated)			1
💼 CIS GCP v3.0.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 2 (Automated)			1
💼 Cloudaware Framework → 💼 Expiration Management			12
💼 FedRAMP High Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3
💼 FedRAMP High Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6
💼 FedRAMP Low Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3
💼 FedRAMP Low Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6
💼 FedRAMP Moderate Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)			3
💼 FedRAMP Moderate Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)			6
💼 ISO/IEC 27001:2022 → 💼 8.27 Secure system architecture and engineering principles		1	4
💼 NIST CSF v1.1 → 💼 PR.IP-2: A System Development Life Cycle to manage systems is implemented		6	9
💼 NIST CSF v2.0 → 💼 ID.AM-03: Representations of the organization's authorized network communication and internal and external network data flows are maintained			45
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles			21
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations			20
💼 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			33
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities			34
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected			108
💼 NIST CSF v2.0 → 💼 PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations			11
💼 NIST SP 800-53 Revision 5 → 💼 PL-8 Security and Privacy Architectures	2		3
💼 NIST SP 800-53 Revision 5 → 💼 SA-8 Security and Privacy Engineering Principles	33		7
💼 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		8
💼 PCI DSS v3.2.1 → 💼 6.3 Develop internal and external software applications securely.	2		3
💼 PCI DSS v4.0.1 → 💼 2.2.2 Vendor default accounts are managed.			8
💼 PCI DSS v4.0.1 → 💼 6.2.1 Bespoke and custom software are developed securely.			3
💼 PCI DSS v4.0 → 💼 2.2.2 Vendor default accounts are managed.			8
💼 PCI DSS v4.0 → 💼 6.2.1 Bespoke and custom software are developed securely.			3