Skip to main content

Protecting Services & Exempting Identities

One-Click Least Privilege. Zero Disruption.



© 2025 Sonrai Security. All rights reserved.

Overview​

Restricting access to privileged permissions reduces risk in regards to convenient lateral movement methods.

tip

Before you read on for information on implementing service protections & exempting identities' access to privileged permissions, we recommend you first review the Services page to understand key terms/concepts

Take a look at our demo scenario to run through the motions of protecting a service!

warning

Before deploying service protections, please ensure you exempt at least one break glass account!

Focus Org-wide

Keeping your scope set to the top-level Org-wide view allows you to make changes most efficiently as said changes will propagate down to the child OUs/Accounts.

tip

If your Org is fairly large, it likely makes more sense to review the next tab on scoping to singular OU(s)/Account(s).

Sort by Status​

Now you have a clear view of what Services are in use in context of either a specific account or your entire organization, with the unused Services listing at the bottom.

Implement Service Protections [Privileged Service Access Controls]​

When privileged permissions for a service remain enabled, but unused, it provides an avenue for lateral movement in the case of a breach.

Scenario

"Our developers use EC2 extensively and we do have some machine identities, but our Sales staff don't need those privileged permissions."

Action

This scenario is a little more complicated than a straightforward service block... You can't disable this service across the board, but you have defined the requirements above and can leverage the button to implement least privilege controls.

In this scenario, lets say we have separate AWS Accounts configured for development and sales. We need to protect the EC2 service for the development account, making identitiy exemptions as needed.

On the Services page, on the right-hand side of the table row, click .

Clicking produces a slide-in panel from the right, detailing:

  • a concise problem statement ("EC2 contains X privileged permissions") including a linked pop out modal listing the associated privileged permissions in question
  • if applicable, a linked list of identities previously/presently exempted at this scope
  • a list of accounts within scope in which the service should be either disabled or protected
    • our recommendations for each account where "Sensitive Access Required" (i.e. the identities we think you should deem as acceptable use for these privileged permissions)

Restrict a Service for Account(s) Within Scope​

Within the development account row of the slide-in panel table, click to limit access to this service to only those identities that are currently using the permissions within the past 90 days (i.e. our "Sensitive Access Required" pre-populated list).

info

These types of protections do not remove previously created elements of your cloud, simply the ability for identities to make more.

For example, the privileged permissions involved with the EC2 service could be controlled and removed from most [or perhaps all] users in a particular part of your cloud hierarchy. Removing this permission from your cloud identities, however, does not remove any existing internet gateways!

Exempting an Identity (at an Account Level)​

Exemptions are used to override a specific service protection for a particular identity. Sometimes there are exceptions to the list and identities that lie outside of our "Sensitive Access Required" recommendations that you may like to exempt such as break-glass identities or identities for newly onboarded employees.

caution

Even exempted identities are subject to abide by service blocks, meaning they too will be blocked from using any permissions afforded to them for that particular disabled service! If an identity requires the service's privileged permissions, you will need to protect the service instead and remove permissions from identities which have no need.

Reference: See here for more information on exemption-worthy personas.


Scenario

"We enabled the EC2 service protection in the past for the developers account, but our new hire Robin still can't use any of those privileged permissions for the EC2 service"

We need to exempt the identity!

Action

Because it's a new identity, it hasn't had the chance to use the service within the past 90 days and so it's not included within the baselined service protection grouping already. We need to explicitly allow this identity to use the EC2 service and leverage the permissions you've assigned within your cloud.

To add an exemption, click , choose the applicable menu option and paste in the identity's AWS ARN to add it to the list of identities where "Sensitive Access Required" for the account in scope.

warning

Granular control of identities via SSO is currently limited to integrations through AWS Identity Center. Third-party integrations such as Ping or Okta direct into accounts are not currently supported.



Single Sign-On (SSO) Exemption format

tip

If necessary, hover over an identity in the "Sensitive Access Required" column then click the 'X' to remove a recommendation from the list.

Please note: Removing an identity from the "Sensitive Access Required" list will remove them forever (i.e. they will not reappear within that list, you will need to manually add the exemption by the button using its ARN [if exemption is required at a later date])

info

You can also more broadly exempt an identity to use privileged service permissions across a larger scope. See here for more information on scoped identity exemptions.

Review Your Changes​

Now that you've scoped your view and chosen to protect a service and/or exempt an identity's access to service(s), click on the confirmation modal to transfer the changes to the "Pending Changes" page for review.

Reference: See here for more information on the "Pending Changes" page.

Last updated on