Skip to main content

Least‑Privilege Patterns

Use this guide to review key considerations for least-privilege access patterns in Cloudaware.

Typically, Cloudaware assigns the Cloudaware Administrator and Cloudaware User managed profiles to users who work with CMDB data. Cloudaware profiles are the baseline access layer.

Least privilege means that:

  • Minimum permissions required to do the job are granted.
  • Data visibility is limited to only what the user/team is responsible for.
  • Temporary elevation is applied via permission sets over broad default access.

To implement least privilege, follow a three-layer approach on the Salesforce platform level via Cloudaware Setup:

  • Profiles (baseline) — what a user can do at minimum. See Profiles.
  • Permission sets/groups (additive) — job/task capabilities without profile sprawl. See Permission Sets.
  • Scoping & sharing (visibility) — what data a user can see (prod vs non-prod, owner/team, account/subscription/project). See Scoping & Sharing.

Persona Patterns​

Use these defaults as a starting point, then add module-scoped permission sets as needed.

  • Administrators
    • Own: tenant/org configuration, integrations, RBAC, sensitive operations.
    • Typical baseline: Cloudaware Administrator profile + admin permission set group(s).
  • Cloud engineers
    • Own: provider onboarding, discovery schedules, tagging governance (read/write in CMDB contexts).
    • Typical baseline: minimal profile (Cloudaware User) + CMDB/tagging permission sets; scope to their accounts/projects.
  • Security/GRC
    • Own: view/triage findings, manage policies (as needed), create evidence packs.
    • Typical baseline: minimal profile (Cloudaware User) + Compliance/Evidence/Reporting permission sets; scope by environment/app ownership.
  • FinOps
    • Own: cost datasets, budgets/alerts, dashboards; manage cost integrations (where applicable).
    • Typical baseline: minimal profile (Cloudaware User) + cost views/mapping/budget permission sets; scope by business unit/cost center.
  • Executives/stakeholders
    • Own: read-only dashboards and reports.
    • Typical baseline: read-only profile (or minimal profile + reporting permission sets) and narrow scopes.

Least-Privilege Design Principles​

  • Keep profiles minimal: add incremental access via permission sets (and groups).
  • Separate personas from environments: don’t create “Prod Admin” vs “Non-prod Admin” profiles; use scopes/sharing for prod vs non-prod segmentation. See Scoping & Sharing.
  • Restrict shared artifacts:
    • Limit creation of public CMDB List Views to designated users (admin/collector-level roles or a dedicated list-view editor permission).
    • Treat shared scopes/views as operational configuration and review them periodically.
  • Service accounts are special:
    • Use dedicated integration/service profiles (for example, collector-only patterns) and scope aggressively.
    • Avoid granting interactive/admin UI access unless required.
  • Identity hardening:
    • Enforce MFA for privileged roles and keep sessions appropriate to risk; maintain and test break-glass access. See SSO & MFA.
  1. Define personas and module capabilities.
  2. Assign each user a minimal baseline profile.
  3. Add module-scoped permission sets; bundle them into persona permission set groups.
  4. Implement scopes (saved CMDB views) for prod/non-prod + ownership + account/project boundaries.
  5. Assign access via IdP groups where possible (joiner/mover/leaver). See Cloudaware Roles & Personas.
  6. Audit changes and run access reviews quarterly. See Audit & Access Reviews and History & Audit.