Description
Utho Object Storage is accessed programmatically through access keys: each key is an access-key / secret-key pair that authenticates S3-compatible requests to your buckets. Utho generates the pair when you create the key and shows the secret only once, and it grants a per-key permission level (Read, Write, or Read-Write) on the buckets it can touch.
This control checks that those access keys are rotated on a fixed schedule of 90 days or less — that is, a new key is created, all applications are cut over to it, and the superseded key is disabled and deleted. Utho has no built-in key expiry or auto-rotation, so rotation is an operational discipline you enforce, not a setting you toggle.
A key is 'stale' for this check when its creation date is older than 90 days and it is still active.
Long-lived storage credentials that never expire and are never revoked
Access/secret pairs leaked in Git history, CI logs, mobile apps, or a former employee's laptop that still authenticate
Absence of a rotation process for object-storage credentials
Rationale
A storage access key that never expires is a permanent skeleton key. If it leaks in a commit, a build log, a container image layer, or an ex-employee's machine, an attacker can list, read, and overwrite every object the key is permissioned for — indefinitely — because no rotation window ever cuts the leaked credential off.
Rotating every 90 days or less bounds that exposure: even an undetected leak stops working within one rotation cycle, and the act of rotating forces you to inventory exactly which applications hold which credentials.
Limits the useful lifetime of any leaked or stolen key to at most one rotation window
Forces a periodic inventory of who/what holds storage credentials
Reduces standing blast radius from a single compromised secret
Impact
Pros:
Leaked credentials become useless within the rotation window
Regular create-swap-retire practice keeps a current inventory of key consumers
Retiring old keys removes orphaned credentials from former apps and staff
Cons:
Every dependent app, backup job, and CI/CD pipeline must be updated with the new pair each cycle, risking outage if one is missed
The secret key is shown only once, so a botched copy means re-issuing again
Utho has no native auto-rotation, so the schedule must be driven by your own reminders or scripts
Default Value
Not documented by Utho; verify in your account — Utho displays each object-storage access/secret pair only once at creation and provides no built-in key expiry or auto-rotation, so keys never rotate unless you rotate them manually.
Pre-Requisite
Utho console access to the account/team that owns the Object Storage buckets
An inventory of every application, backup job, and pipeline that uses each access key (so you can cut them over)
A secure place to capture the new secret key, which Utho shows only once
For any API automation: a Utho Api Token (Authorization: Bearer) generated in the console
Remediation
Test Plan
Using the Utho Console:
Sign in to the Utho console and open Object Storage.
Select the bucket and open its Access Keys / permissions view.
For each listed access key, note the creation/issue date and whether it is still enabled.
Compare each active key's age against today.
Pass: every active access key was created within the last 90 days and no disabled/superseded keys remain that could still authenticate.
Fail: any active access key is older than 90 days, or retired keys have not been deleted.
Using the Utho API:
Utho exposes a Developer API v2 (api.utho.com/v2) that can list object storage and access keys, but the exact object-storage access-key read path could not be verified against Utho's published API reference; treat the console as authoritative and confirm the endpoint at utho.com/api-docs before scripting.
Implementation Steps
Using the Utho Console:
Open Object Storage in the Utho console and go to the bucket's access-keys / permissions section.
Create a new access key (provide a name) and securely copy the new access key and secret key — Utho displays the secret only once.
Grant the new key only the permission level it needs (Read, Write, or Read-Write) via Update Permission.
Roll the new access/secret pair into every dependent application, backup job, and CI/CD pipeline, then verify traffic succeeds on the new key.
Disable the old key and confirm nothing breaks, then delete it so the retired credential can no longer authenticate.
Record the rotation date and repeat this create-swap-retire cycle at least every 90 days (drive the reminder with your own scheduler since Utho has no auto-expiry).
Using the Utho API:
Access-key rotation is performed in the Utho console. Utho's Developer API (utho.com/api-docs) can manage object storage and access keys programmatically, but the exact create/delete access-key paths could not be confirmed against the published spec, so no commands are given here — verify the endpoints in Utho's API reference before automating.
Backout Plan:
If applications fail after cutover, re-enable the previous access key (do not delete it until the new key is proven) so traffic can fall back immediately.
Point the affected application back to the old access/secret pair and confirm service is restored.
Diagnose why the new key failed (wrong permission level, mis-copied secret, un-updated config), fix it, and retry the cutover.
Only delete the old key once every consumer is confirmed working on the new key.