📝 Google API Key is not restricted for unused APIs 🟢

• Contextual name: 📝 API Key is not restricted for unused APIs 🟢
• ID: /ce/ca/google/api/api-key-for-application
• 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
  • Check for API Key Application Restrictions

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. API keys are always at risk 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 restrict API keys to use (call) only APIs required by an application.

Rationale

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

In light 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.

... see more

Remediation

Open File

Remediation

From 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. In the Key restrictions section go to API restrictions.
4. Click the Select API drop-down to choose an API.
5. Click Save.
6. Repeat steps 2,3,4,5 for every unrestricted API key

Note: Do not set API restrictions to Google Cloud APIs, as this option allows access to all services offered by Google cloud.

From Google Cloud CLI

1. List all API keys.

   gcloud services api-keys list

2. Note the UID of the key to add restrictions to.

3. Run the update command with the appropriate flags to add the required restrictions.

   gcloud alpha services api-keys update <UID> <restriction_flags>

Note: Flags can be found by running

gcloud alpha services api-keys update --help

or in this documentation https://cloud.google.com/sdk/gcloud/reference/alpha/services/api-keys/update

policy.yaml

Open File

Linked Framework Sections

Section	Sub Sections	Internal Rules	Policies	Flags
💼 CIS GCP v1.2.0 → 💼 1.14 Ensure API keys are restricted to only APIs that application needs access - Level 1 (Manual)			1
💼 CIS GCP v1.3.0 → 💼 1.14 Ensure API Keys Are Restricted to Only APIs That Application Needs Access - Level 1 (Manual)			1
💼 CIS GCP v2.0.0 → 💼 1.14 Ensure API Keys Are Restricted to Only APIs That Application Needs Access - Level 2 (Automated)			1
💼 CIS GCP v3.0.0 → 💼 1.14 Ensure API Keys Are Restricted to Only APIs That Application Needs Access - Level 2 (Automated)			1
💼 Cloudaware Framework → 💼 Cryptographic Configuration			8
💼 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			20
💼 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			104
💼 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