Addressing Cloud Security Risks: Part 2 - Credential Theft/Leakage

In this multi-part series, I explore the top five cloud security risks that I've seen early stage startups encounter, along with common causes and mitigation best practices. In a previous post, I covered Top 5 Cloud Security Risks for Startups - today, I'll address one of the key risks - credential theft/leakage.

Single sign-on / identity federation

• Use industry standards like Security Assertion Markup Language (SAML) or OpenID Connect (OIDC) for exchanging authentication and authorisation data.
• Adopt a centralised identity management system or identity provider (IdP); unless you really know what you are doing, choose a managed option.
• Set up single sign-on (SSO) or identity federation with your chosen IdP.
• Conduct regular reviews of SSO and identity federation configurations; ensure systems have the latest security updates/patches in place.
• Log and monitor SSO activities, and detect suspicious or unauthorised access attempts and anomalous behaviour.
• Note: For some SaaS applications (see SSO Wall of Shame), SSO may be an added expense, available as part of Pro/Business/Enterprise tiers. Unless it materially impacts your bottom line, SSO should be a worthwhile investment.

Multi-factor authentication

• Implement strong authentication by adopting mandatory multi-factor authentication (MFA) for everyone, no exceptions.
• While any MFA option is better than none, legacy options like SMS/Email OTP and mobile push are quite vulnerable to phishing attempts, and should be avoided in favour of phishing-resistant security keys.
• In the least, use (multiple) FIDO2 hardware security keys for critical accounts e.g. administrators and other important personnel. Popular examples are Google Titan and Yubikey (USB-A/NFC, USB-C/NFC or USB-C/Lightning).

• You can also use your iPhone or Android phone's built-in security key on supported devices and OS versions.
• Adopt passwordless authentication mechanisms using biometrics and passkeys, a phishing-resistant password alternative.

Privileged identity management

• Implement the principle of least privilege; grant privileged access only to individuals who need it to perform their specific tasks, and for the specific duration necessary.
• Set up multiple super administrator accounts, each managed by a separate individual; don't share administrator accounts.
• Don't use these super administrator accounts for daily activities; vault the credentials, and use them only in break-glass scenarios.
• Add recovery options to administrator accounts, and test them. Generate, print and store backup codes securely in case they are needed. See these getting started guides for additional tips from Google Cloud and AWS.
• Restrict and secure access to your DNS domains and records; I've seen several instances of DNS hijacking, especially among Web3 organisations.

Workload identity

• Service accounts are non-interactive principals or identities, used by workloads such as applications and services to authenticate and access resources, or perform actions, usually without user involvement. While they are extremely useful, they are also often abused by bad actors.
• In Google Cloud specifically, service accounts are both a principal and a resource, so they can be granted access to resources, and can also be accessed and impersonated by other principals. See their best practices guide for using service accounts; I'll highlight a few key points below.
• Firstly though, use the principle of least privilege here too, and limit service account privileges to the absolute minimum required to perform the task.
• Use the following diagram to choose between authentication methods when accessing Google Cloud services:

• If your workload runs on Google Cloud Compute resources, use the attached service account as the preferred means of authentication.
• If your workload runs on Google Kubernetes Engine specifically, use Workload Identity to attach service accounts to Kubernetes pods.
• If your workload runs outside Google Cloud, but can authenticate with supported external identity providers, use workload identity federation. For example, on AWS, applications can use instance profiles, on Azure, applications can use managed identities, and in GitHub Actions, workflows can obtain ID tokens. See Google Cloud best practices guide for using workload identity federation.
• If you have absolutely no other choice, only then create and use a service account key. Keep the usage limited to necessary projects and services only, define expiration time, and regularly track usage. See Google Cloud best practices guide for managing service account keys.
• Identify and disable unused service accounts periodically; Google Cloud offers Policy Analyzer to track service account usage, and role recommendations to understand over-granted and unused permissions.

If you found this post useful, feel free to read others in this series:

• Top 5 Cloud Security Risks for Startups
• Addressing Cloud Security Risks: Part 1 - Misconfiguration
• Addressing Cloud Security Risks: Part 2 - Credential Theft/Leakage (this post)
• Addressing Cloud Security Risks: Part 3 - Unauthorised Access
• Addressing Cloud Security Risks: Part 4 - Insecure Software Development & Deployment (coming soon)
• Addressing Cloud Security Risks: Part 5 - Sensitive Data Disclosure (coming soon)