Intro: Services
© 2026 Sonrai Security. All rights reserved.
Overview
Unused [enabled] Services - a useful attack vector for threat actors to leverage!
Maybe you forgot to turn off AWS S3 when you were done testing storage solutions, or perhaps one of your overprivileged developers took the initative to test that out for you (unintentionally bypassing your change management process...)
Sonrai's Cloud Permissions Firewall immediately notifies you whether you have any unused but enabled services and/or privileged permissions access to review.
Scope
Initially, you may be wondering "What am I looking at?..", but a better question is "What do I want to look at first?", which is answered by the top left-hand dropdown providing the scope of the Service-related data in view.
From here you can select a:
- cloud type to narrow down the table results
- logical grouping (the entire Organization, an Organizational Unit (OU), Accounts [nested under an OU])
| Cloud Type | Path |
|---|---|
| AWS | aws/<organization>/<organizational unit*>, aws/<organization>/<organizational unit*>/<account> |
| GCP | gcp/<gcp-organization>/<folder*>/<project> |
Your selected scope carries through to each action you take within the Services page (i.e. protections will only populate possibilities for the accounts/identities in the chosen scope)
Protecting Services at Scope
Cloud Permissions Firewall allows you to protect and disable services across a range of accounts by selecting a higher level scope.
When applying service protections to your AWS root scope, those protections are applied globally for that service.
However, if an OU is selected in your scope picker then CPF allows you to apply service protections for lower-level accounts in one of two ways:
- Protect new accounts in this OU by inheriting this protection
- Only apply the protect to individual accounts that already exist in this OU
| Option | Effect | When Should I Choose This? |
|---|---|---|
| Protect the service | Attaches a single SCP at the current scope, blocking access to sensitive permissions. All accounts in that scope — including future accounts — are controlled by that single SCP, and if you unprotect accounts at a lower level then those account are added as exceptions in the SCP. | Use this option to guarantee consistent coverage across accounts and conserve SCP space. |
| Do nothing | Attaches SCPs to every account that exists in the selected scope. Future accounts are not affected. More SCP space is required, and you will need to manually update controls for future accounts. | Use this option to manage services account-by-account, without applying the same controls to all accounts. |
How can I tell if protections are inherited from a higher-level scope?
When protections for a service have been inherited from a higher-level OU, you will see an inherited icon beside the status. Click the icon to see which OU the protection is inherited from, or click on the OU name to change your current scope so that you can modify or remove that control.
Note that you can also apply controls at scope the same when disabling services.
With the current architecture of Cloud Permissions Firewall, when you select a folder from the dropdown scope menu and then protect or disable a service at that scope, it will create a restrict policy for each individual GCP resource nested underneath the selected scope.
Cloud Permissions Firewall does not currently support GCP projects inheriting controls at scope from a higher level GCP folder.
Scoped Identity Exemptions
Scoped exemptions can be especially useful for situations where a break glass account or super admin is concerned.
Much like granular account-based identity exemptions for a specific service, these overarching scope-based identity exemptions allow you to manage privileged permissions access, but for a broader scope within your Organization. This method provides you the much more efficient way of exempting an identity for a wider set of privileged permissions across accounts.
The entries with lock icons are system required exemptions.
To maintain full Organizational access for root accounts, create a global exemption for *:root at the top of the Organization tree.
Hero Cards
Once your scope is adjusted, the hero cards (along with the services table) will adjust to reflect the drilldown number of:
- One Click Protection
- IAM users and roles with excessive privilege
- Zombies
- Unused services
The hero cards provide a preview of the identities/services/etc. involved in Sonrai's recommended changes for these categories and a convenient single-click to action!
IAM Users and Roles With Excessive Privilege
Unused privileged service access is a latent attack surface that enables attackers to gain footholds and move laterally within your organization.
Examples involving privileged service permissions:
- creating a new EC2 VPC
- updating the function code of a lambda
- executing an ECS command
Reference: See here for information on IAM users and roles with excessive privilege.
Zombies
A Zombie is considered to be any identity (user, role, etc.) that has been unused for at least 90 days.
Inactive but enabled Zombie identities provide the capability for threat actors to escalate privileges, move laterally, gain access to sensitive data, and more.
Rather than deleting Zombie identities entirely, we opt to help you quarantine them so they remain present within your cloud but can no longer be used. Sometimes Zombies reanimate after some time, but are subject to requesting privileged service access through Permissions on Demand (PoD).
Reference: See here for information on zombie identities.
Unused Services
Service blocks remove the ability for identities within your cloud to use any of the permissions associated with the service.
Disabling service(s) can be regarded as a quick and simple method of reducing attack surface to lower the overall level of service-related risk(s) for your cloud.
Reference: See here for information on unused services.
Threat Vectors
A threat vector is the method an attacker uses to exploit weaknesses in cloud identities, configurations, workloads, or trust relationships.
Understand at a glance which identities in your cloud have access to critical access paths, so that you can take action to reduce risks before a breach occurs.
Reference: See here for information on unused services.
Service Status
Key terms and concepts for each possible status you may encounter in the Services table:
All accounts [in scope] allow this service to be used without protection
(i.e. you have not implemented any blocks/protections through Sonrai's Cloud Permissions Firewall yet)
Some accounts [in scope] fully allow this service without protections
(*some accounts may be blocked from using the service and some may use the service with protections in place)
All accounts [in scope] are restricted with one or more cloud controls enabled
(*all accounts have at least one cloud control in place (i.e. some accounts may be blocked from using the service and some may use the service with protections in place))
This service is disabled in all accounts
(i.e the service cannot be used at all)
Any status with "(pending)" indicates there are entries within the Pending Changes page to review/action
Service Controls
Service Controls are one or more protections that can be applied to the cloud to restrict or prevent actions or activities through cloud-native frameworks like AWS Config.
These active controls dictate:
- what can and cannot be done to and by the service within your cloud estate
- who and what can access the service, specifically in a sensitive manner
Common Controls
The number of Service Controls that apply to any given service will vary based on the nature of the service, but the most common controls you'll see are:
The first step to achieving an effective Least Privilege footprint in a cloud estate; limiting all permission(s) related to that service from use by any identity
The second step in achieving effective Least Privilege; enabling only those identities that have a proven need for this level of privileged permissions access for the service
These types of blocks/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 identities, however, does not remove any existing internet gateways!
Service Actions
There are several options as per how you take action for each service, depending on your use case:
Disable the service entirely so that no accounts within your organization can use it (i.e. all permissions related to this service are blocked for all identities within the selected account(s) [in scope])
The service is being moved into a protected state. Users can elect which cloud controls are to be enabled for the service.
[*If no cloud controls are turned on, the service stays as "Unprotected" status]
The entire service will be unlocked for use by all identities that have grants to the service (zero cloud controls will be enabled in this state)
When we talk about a Service like AWS EC2 being "protected", we mean those that have one or more Service Control(s) applied. These would be services for which you clicked the "Disable"/"Protect" action at a given scope
Service FAQs
-
Services with a lock are considered integral to core to cloud provider functionality and cannot be disabled, only protected.
-
Services with account usage "Coming soon" values are those which we are currently unable to validate as legitimately "in use" because they have:
- no create/update/delete activity in audit logs
- no cost explorer usage
- When you completely disable the Access Analyzer service in AWS, expect to see this error when attempting to edit a bucket policy:
You need permissions
User:arn:aws:123456789123:assumed-role/AWSReservedSSO_AdministratorAccess_y7dsefy79ertyf7re7f8reggf7eir/myUser@example.com is not authorized to perform access-analyzer:ValidatePolicy on resource: arn:aws:access-analyzer:us-east-1:123456789123:* with an explicit deny
This is just a visual notification of an error, it does not affect your capability to edit the bucket policy.
Check out our series of how-to pages next!
- How-to: Exempt Identities
- How-to: Disable Services
- How-to: Protect Services