Tag: Security

Access reviews are a strange exercise. Everybody focuses on who can get in, which is the part that is designed carefully and works. Almost nobody tests what happens when someone leaves, which is the part that is nobody’s job and fails silently.

A DAM is unusually exposed here because it has more external users than most systems. Agencies, freelancers, printers, resellers, regional partners. All of those relationships end, and most of them end without anyone telling the DAM administrator.

Short answer: get identity from the corporate directory through single sign-on, derive groups from directory groups, and make the leaver process remove access without any human in the DAM team being involved. Then make sure the audit trail records reads as well as writes, because for a media library the question is usually who downloaded it, not who changed it.

Identity first

Every access problem in a DAM traces back to how identity arrives.

Local accounts are the failure mode. If administrators create users in the DAM by hand, then the DAM’s user list is a snapshot of who worked here at various points over the last five years. Nobody removes accounts, because removal is manual, nobody owns it, and it never causes a visible problem.

Single sign-on fixes it structurally. Identity comes from the corporate directory. Someone leaves, HR terminates the record, the directory revokes, and every downstream system including the DAM loses access without anybody remembering to do anything. That is the whole value: it is not convenience, it is that deprovisioning becomes automatic.

Standards, not proprietary schemes. OpenID Connect over OAuth 2.0, with JWT tokens. SAML is still common in the enterprise and is fine. A vendor’s own authentication scheme is not fine, and it is a reliable predictor of an integration that overruns.

Groups from the directory. Roles should derive from directory group membership rather than being assigned in the DAM. Someone moves from the German team to the French team, their access follows, and no ticket is raised. If roles are assigned locally, they drift out of alignment with the org chart within a year and the access review becomes archaeology.

External users are the actual risk

Internal identity is usually solved by the time a DAM arrives, because the corporate directory already exists. External identity is not, and it is where the exposure sits.

Four practices that address most of it:

• Time-bound access by default. External accounts expire on a date and require renewal. Not a policy, a system setting. If your platform cannot expire an account, the compensating control is a monthly review, and monthly reviews decay.
• Sponsorship. Every external user has a named internal sponsor. When the sponsor leaves or changes role, the external accounts they sponsored surface for review automatically.
• Share links over accounts. For a printer who needs six files once, an expiring link is safer than an account. Accounts are forever unless somebody acts; links expire unless somebody acts. Prefer the default that fails closed.
• Separate the consumption tier. Read-only distribution to a wide partner network should not run through the same mechanism as contributor access. Different risk, different controls, usually different licensing too, which is covered from the commercial side in what enterprise DAM costs.

What the permission model can and cannot do

Be precise here, because there is a persistent gap between how DAM security is described in proposals and what products actually enforce.

In most enterprise DAM platforms, including Cloudinary, permissions are administered at the folder or collection level rather than per individual asset. Folder modes determine how assets inherit from their placement, and that inheritance is the mechanism you design around.

This covers the overwhelming majority of real requirements, and it has a practical implication worth acting on early: your folder structure is your permission structure. Design it to match your entitlement boundaries, which usually means business unit, brand, market and sensitivity, rather than to match a browsing hierarchy. Browsing is what facets are for, and that separation is the argument in designing a taxonomy people actually use.

What this model does not give you is an independently queryable permission set attached to each individual asset that an application can evaluate at request time. If your security design assumes that, validate it against the product before writing it into a control framework, because retrofitting a folder structure after migration is a project and designing it correctly at the start is a workshop.

Separately from library permissions, delivery of the asset itself needs its own control. Public URLs are public, which is correct for a marketing site and wrong for pre-release material. Access control on delivery covers restricted delivery and signed URLs, which is the mechanism that stops an unlisted address from being an open one.

The nine questions security will ask

Have written answers before the review, not during it.

1. How does identity arrive, and from where? SSO from the corporate directory, or you will spend the meeting on this one alone.
2. How is access removed? The question that fails. Answer must be automatic, via the directory.
3. How are roles assigned? From directory groups, not by hand in the DAM.
4. Who has administrative rights, and how many are there? The number should be small and you should be able to name them.
5. How do external users get access, and when does it end? Time-bound, sponsored, reviewed.
6. What is logged, and for how long? See below, this is usually where the second gap is.
7. How do integrations authenticate? Service accounts with scoped credentials, never a person’s login. And any browser-originated write path uses server-side signing so keys never reach a client.
8. Where is data stored, and does that satisfy residency requirements? Relevant under GDPR for any library containing images of identifiable people in the EU.
9. What assurance does the vendor hold? SOC 2 is the usual expectation. Ask for the report, not the badge.

Map the answers to NIST SP 800-53 control identifiers if your organisation reports against that catalogue. It takes an afternoon and it converts a bespoke evaluation into three lines in a register the security team already maintains.

The audit trail, and the part that gets missed

Most systems log writes well and reads poorly. For a media library that is backwards.

The questions that get asked after an incident are almost always about access rather than modification: who downloaded the unreleased product images, when did the agency last retrieve this file, which partner accessed material outside their territory. If your log records uploads and edits but not downloads and deliveries, none of those is answerable.

What to require:

• Reads as well as writes. Downloads, deliveries, share link access. Volume is higher, retention may be shorter, and it is the half that matters.
• Identity on every entry, including for integrations. An entry attributed to a shared service account tells you a system acted, not which user caused it, so pass through the acting user where the API allows.
• Retention that matches your obligations, not the vendor default. Ninety days is common and frequently insufficient; contract disputes surface a year later.
• Exportable. The log must leave the platform and reach your SIEM. A log you can only read in a vendor interface is a log your security team does not have.
• Immutable. Administrators should not be able to alter or remove entries. If they can, the trail is evidence of nothing.

Test the controls, once a year, deliberately

Design is not operation. The controls that fail are the ones nobody has exercised.

Four tests, half a day:

Deprovisioning. Pick a genuine recent leaver. Confirm access is gone, including any share links they created and any integration running under their credential. This test fails more often than any other.

External expiry. Confirm an expired external account cannot authenticate and that its share links no longer resolve.

Audit retrieval. Ask for every download of a specific asset in the last six months. Time how long it takes to produce. If it takes more than an hour, you do not have an audit capability, you have log storage.

Delivery restriction. Take a restricted asset and confirm its delivery URL does not resolve without authorisation. Public-by-default delivery is a common and quiet misconfiguration.

Record the results. That record is what turns your governance framework from a document into evidence, and it is what an auditor is actually asking for when they ask whether the control operates.

The rights half of the compliance picture is in rights and expiry as first-class asset data, the architectural reason deletion and takedown are executable at all is in single source of truth is an architecture, and the wider context is in what enterprise DAM actually is.