✳ The reference desk / In practice

SSPM

Configuration and access review for software-as-a-service tenants such as email or identity portals.

SaaS security posture management

What it means

SSPM examines the security configuration and access posture of software-as-a-service applications. The cloud provider runs the service, while the customer still chooses many tenant settings, identities, integrations, and sharing policies. Relevant checks can include administrator access, sign-in requirements, external sharing, and application permissions. Coverage depends on each service’s APIs and the assessment tool’s access. A finding should connect a specific setting to an organizational policy and an owner. The presence of a check does not mean the tool can enforce it or assess every tenant activity.

The idea at a glance / Cloud

A restricted default can leave an old share open.

Keep a SaaS setting, existing grant, independent reads and unfinished removal together.

Synthetic DocSpace tenant T171 disables creation of new public links. Its documented exercise behavior leaves existing L171 active for draft D171. A read-only collector checks the supported default and existing grants. Owner Sam records removal task Q171 for Nora, but it has not been applied. No student information or real SaaS tenant is used.

SSPM: Keep a SaaS setting, existing grant, independent reads and unfinished removal together. The explanation below describes the relationships.DocSpace · tenant T171 postureNew-link setting ≠ existing grantsT171 · supported defaultNew public links disabledAPI collector is read-onlyExisting L171 → draft D171Old public-link grant stays activeOriginal draft remainsIndependent selected checksNew link 403 · old read 200Maya’s permitted read → 200Sam’s removal task · Q171Nora has not removed L171Application / verification openDEFAULT PASSES · OLD SHARE OPEN

READ THE PICTURE

Default beside effective access

New public-link creation is refused, but existing L171 still returns D171 anonymously. Maya’s permitted draft read also works; Sam’s removal task remains unapplied.

Keep in mindThe create-versus-existing-link behavior is explicit for fictional DocSpace; vendors and settings differ. T171 is a selected API snapshot, not every tenant setting, app grant or session. Collector identity and API coverage are assumed. L171 is a correlation label, not the actual bearer URL. Provider hosting or a passing default check does not remove the retained grant.

Read the complete example
  1. Default beside effective access. New public-link creation is refused, but existing L171 still returns D171 anonymously. Maya’s permitted draft read also works; Sam’s removal task remains unapplied. T171’s supported default check passes because new public-link creation is disabled. In this service’s specified behavior, that setting does not revoke existing grants. The isolated HTTP/SQL check refuses a new public link with 403, yet a held actual L171 bearer value returns the unchanged synthetic D171 with 200. Separately authenticated Maya can read her draft with 200; an unrelated account cannot. Sam’s Q171 names removal of L171 for Nora, with applied=false and verified=false. The collector has read-only configuration/grant access. The original draft and snapshot remain; broader integrations, tenants and past copies are not assessed.

The create-versus-existing-link behavior is explicit for fictional DocSpace; vendors and settings differ. T171 is a selected API snapshot, not every tenant setting, app grant or session. Collector identity and API coverage are assumed. L171 is a correlation label, not the actual bearer URL. Provider hosting or a passing default check does not remove the retained grant.

Diagram references: Microsoft: connector-scoped SaaS posture assessments · CISA: configuration collection, policy comparison and reporting · NIST SP 800-210: cloud data-owner access control

AN ILLUSTRATIVE SCENARIO

A good default beside a surviving link

DocSpace T171 refuses new public links but leaves existing L171 active under its stated exercise behavior. The collector can read supported settings and grants. An anonymous held-link read still returns draft D171, while Vera’s legitimate read works. Sloane’s removal Q171 is unapplied; a passing default check has not removed old access.

Put it to work

  1. Inventory important SaaS tenants, administrators, and connected applications. Establish who owns configuration decisions and which organizational policies apply to each service.
  2. Use documented assessment permissions and relevant baselines. Confirm what the connector can inspect, how current its results are, and which checks require manual review.
  3. Pilot changes with representative users, monitor their impact, and document exceptions. Recheck after application updates, new integrations, and major changes in access or sharing.

How to check your work

Test a known tenant setting and a representative sharing workflow. Confirm that the assessment notices drift, the intended audience can still collaborate, and an unauthorized recipient cannot use the prohibited sharing path.

Connect the ideas

  • Shared responsibility

    The split of security duties between a cloud or SaaS provider and the customer, which varies by service.

  • IAM

    The capability for creating identities, authenticating them, authorizing actions, and managing their lifecycle.

  • IGA

    Processes and tools for reviewing who should have which access and removing what is no longer justified.

  • CSPM

    Checks of cloud configuration against policy, such as public storage or open security groups.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.