Skip to content
Unmesha Technologies, security assessments

Replacing a stored cloud key

An app in Azure reads one storage bucket in Google Cloud. Today it uses a stored key that works for anyone who copies it. Here’s how we’d swap the key for an identity only that app can use.

Request a scoping call

Free 30-minute scoping call. A fictional design example.

Today: the app signs in to the bucket in Google Cloud with a stored key, and so can anyone holding a copy.

  1. Today: a key anyone can copy

    The app signs in to Google Cloud with a key kept in a file on its server. The key is long-lived, and anyone with a copy can use it from anywhere: from that file, a server image or a backup.

  2. The change: an identity only the app can use

    1. An identity for one app

      The app’s server in Azure gets its own identity, so no key is stored. Only code on that server can use it.

    2. A check in Google Cloud

      Google Cloud accepts that identity only from the approved Azure tenant and app, and turns every other sign-in away.

    3. One storage bucket, nothing else

      The identity can read one storage bucket. Writing, deleting and opening another bucket are refused.

    For your engineer

    The app’s settings file, /etc/reporting-app/env

    Today: a key anyone holding a copy can use

    GOOGLE_APPLICATION_CREDENTIALS=/etc/reporting-app/sa-key.json

    Fixed: the server’s identity, swapped for a short-lived token

    GOOGLE_APPLICATION_CREDENTIALS=/etc/reporting-app/federation.json

    The new file names where to exchange the server’s identity for a token. It holds no secret.

Risks that remain

Two things decide how much an attacker could get: how locked down the server is, and what the identity can really reach. We check both.

  • The old key is copied

    What could happen
    Someone copies the key from a config file, a server image or a backup and uses it from somewhere else.
    What the design does
    Disable the key, check nothing still uses it, then delete it. Until then, any copy still works.

  • The app’s server is taken over

    What could happen
    An attacker on the server uses the app’s identity to ask for access.
    What the design does
    Keep the server for this app alone and limit what runs on it. The check can’t tell the app from malware on the same machine.

  • The trust is too broad

    What could happen
    Another identity in the same Azure tenant is accepted as well.
    What the design does
    Allow only the approved app and identity, and test that any other one is refused before release.

  • The data access is too broad

    What could happen
    The identity reaches another bucket, or a permission it inherits lets it write.
    What the design does
    Give the dataset its own bucket and test what the identity can really do: writing, deleting and a second bucket.

  • Removing access is slow

    What could happen
    Access is removed on paper, but a credential issued earlier still works for a while.
    What the design does
    Remove access to the bucket and stop new credentials being issued, then confirm the bucket refuses the request.

Checks before release

Make sure the app works with its new sign-in, and find everything that still uses the old key.

  • The app can read its bucket.
  • Other identities and other buckets are refused.
  • Writing and deleting are refused.
  • The old key is revoked and no longer works.

This design is fictional. We haven’t built it for a client or measured it. The checks above are the ones we’d run before release.

Planning a similar cloud access change?

We can check the identities, keys and permissions involved before they reach production.

Request a scoping callOr try the customer data mini assessment