Skip to main content

🛡️ Google API Key is not rotated every 90 days🟢

Logic​

Similar Policies​

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​

SectionSub SectionsInternal RulesPoliciesFlagsCompliance
💼 CIS GCP v1.2.0 → 💼 1.15 Ensure API keys are rotated every 90 days - Level 1 (Manual)1no data
💼 CIS GCP v1.3.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 1 (Manual)1no data
💼 CIS GCP v2.0.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 2 (Automated)1no data
💼 CIS GCP v3.0.0 → 💼 1.15 Ensure API Keys Are Rotated Every 90 Days - Level 2 (Automated)1no data
💼 Cloudaware Framework → 💼 Expiration Management13no data
💼 FedRAMP High Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)3no data
💼 FedRAMP High Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)6no data
💼 FedRAMP Low Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)3no data
💼 FedRAMP Low Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)6no data
💼 FedRAMP Moderate Security Controls → 💼 PL-8 Security and Privacy Architectures (L)(M)(H)3no data
💼 FedRAMP Moderate Security Controls → 💼 SA-8 Security and Privacy Engineering Principles (L)(M)(H)6no data
💼 ISO/IEC 27001:2022 → 💼 8.27 Secure system architecture and engineering principles14no data
💼 NIST CSF v1.1 → 💼 PR.IP-2: A System Development Life Cycle to manage systems is implemented69no data
💼 NIST CSF v2.0 → 💼 ID.AM-03: Representations of the organization's authorized network communication and internal and external network data flows are maintained69no data
💼 NIST CSF v2.0 → 💼 ID.AM-08: Systems, hardware, software, services, and data are managed throughout their life cycles25no data
💼 NIST CSF v2.0 → 💼 ID.IM-01: Improvements are identified from evaluations26no 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 parties40no data
💼 NIST CSF v2.0 → 💼 ID.IM-03: Improvements are identified from execution of operational processes, procedures, and activities41no data
💼 NIST CSF v2.0 → 💼 PR.DS-10: The confidentiality, integrity, and availability of data-in-use are protected142no data
💼 NIST CSF v2.0 → 💼 PR.IR-03: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations15no data
💼 NIST SP 800-53 Revision 5 → 💼 PL-8 Security and Privacy Architectures23no data
💼 NIST SP 800-53 Revision 5 → 💼 SA-8 Security and Privacy Engineering Principles338no 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.19no data
💼 PCI DSS v3.2.1 → 💼 6.3 Develop internal and external software applications securely.24no data
💼 PCI DSS v4.0.1 → 💼 2.2.2 Vendor default accounts are managed.9no data
💼 PCI DSS v4.0.1 → 💼 6.2.1 Bespoke and custom software are developed securely.3no data
💼 PCI DSS v4.0 → 💼 2.2.2 Vendor default accounts are managed.9no data
💼 PCI DSS v4.0 → 💼 6.2.1 Bespoke and custom software are developed securely.3no data