Hi everyone. I've been tasked with setting up a way for our internal audit team to view our Trend Micro Cloud One environment, but without any ability to make changes. I'm relatively new to the platform's admin side, so I want to be sure I get this right.
From what I've seen in the console, there are user roles and IAM policies, but the distinction between a "read-only" role and a custom policy is a bit unclear to me. Our audit team needs to see compliance reports, alert logs, and the overall security posture across all accounts/projects we have connected. They should not be able to modify policies, deploy agents, or change any settings.
Has anyone set up something similar? Specifically:
- Is there a built-in "Auditor" or "View Only" role I should be using, or is a custom IAM policy the only way?
- If custom, are there any sample policies or best practices to follow to ensure they see everything they need but can't take action?
- Are there any pitfalls, like certain reports or dashboards that might be hidden with a view-only permission set?
I want to make their access as seamless as possible without introducing any risk. Any guidance or lessons from your own setups would be really helpful.
—em
The built-in "Security Auditor" role is the obvious starting point, but I'd treat it with a healthy dose of skepticism. It's rarely as simple as it seems on the vendor's datasheet.
You'll likely need to pair it with a custom IAM policy anyway, because that "overall security posture across all accounts/projects" requirement is the tricky bit. Default roles often have scope limitations you won't discover until audit asks why they can't see the new subsidiary's data. The pitfall isn't hidden reports, it's hidden *resources*.
Do a PoC and have someone *from the audit team* test it before you call it done. Their definition of "see everything" is probably more exhaustive than yours.
cg
Yeah, the "hidden resources" point is spot on and the main reason I'd skip the built-in role entirely. In a past setup, the default auditor role could only list resources in a specific region, which completely broke the compliance report view for global teams.
Building a custom policy from scratch, while tedious, forces you to map their actual required read actions to your exact resource ARNs. It's the difference between "can view" and "can view *everything we have*." Definitely agree on getting the audit team in early, they'll ask for a report you didn't even know existed.
editor is my home
Oh, great question! I'm also new to setting this stuff up. The built-in role might seem easier at first, but I got stuck because it didn't include permissions for the newer dashboard views in our setup.
If you go custom, start with the built-in policy's JSON as a base template. Then, you can add the specific API actions for reports and logs you know they'll need. Just make sure you explicitly deny any "write" or "delete" actions in that same policy document.
One pitfall I almost missed - double-check the resource scope. For "all accounts/projects," you might need to use a wildcard (*) in the resource ARN section, not just list the ones you have now. Did you find any good examples of that for Trend Micro?