Ensure EventBridge Schema Registries Do Not Allow Unknown Cross-Account Access
Overview
This check verifies that your AWS EventBridge schema registries do not grant access to unknown or unauthorized AWS accounts. Schema registries store event schemas that describe the structure of your events, and unrestricted cross-account access can expose sensitive information about your application architecture.
Risk
If your schema registry allows unknown cross-account access:
- Data exposure: External parties can view your event schemas, revealing your data models and application structure
- Unauthorized modifications: Bad actors could alter or delete schemas, breaking applications that depend on them
- Reconnaissance: Attackers can study your event structures to plan more sophisticated attacks
Severity: High
Remediation Steps
Prerequisites
You need permission to modify EventBridge schema registry policies. This typically requires the schemas:PutResourcePolicy permission.
AWS CLI setup (optional)
If you prefer using the command line, ensure you have:
- AWS CLI installed and configured
- Appropriate IAM credentials with
schemas:*permissions
AWS Console Method
-
Open the Amazon EventBridge console
-
In the left navigation pane, under Schemas, choose Registries
-
Select the registry that was flagged by Prowler
-
Choose the Resource policy tab
-
Review the current policy and identify any statements that grant access to:
"Principal": "*"(public access)- Unknown AWS account IDs
- AWS accounts outside your organization
-
Choose Edit to modify the policy
-
Update the policy to restrict access to only trusted accounts:
- Replace
"Principal": "*"with specific account ARNs - Remove any unknown account IDs
- Use your organization ID if you need to share across your AWS Organization
- Replace
-
Choose Save to apply the changes
AWS CLI (optional)
List all registries to identify which need remediation:
aws schemas list-registries \
--region us-east-1 \
--scope Local
Check the current policy on a registry:
aws schemas get-resource-policy \
--registry-name <your-registry-name> \
--region us-east-1
Apply a restrictive policy that only allows access from a trusted account:
aws schemas put-resource-policy \
--registry-name <your-registry-name> \
--region us-east-1 \
--policy '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowTrustedAccountAccess",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<trusted-account-id>:root"
},
"Action": "schemas:*",
"Resource": "*"
}
]
}'
For organization-wide access, use a condition:
aws schemas put-resource-policy \
--registry-name <your-registry-name> \
--region us-east-1 \
--policy '{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOrganizationAccess",
"Effect": "Allow",
"Principal": "*",
"Action": [
"schemas:DescribeSchema",
"schemas:GetDiscoveredSchema",
"schemas:SearchSchemas",
"schemas:ListSchemas"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "<your-organization-id>"
}
}
}
]
}'
To remove the resource policy entirely (deny all cross-account access):
aws schemas delete-resource-policy \
--registry-name <your-registry-name> \
--region us-east-1
CloudFormation (optional)
AWSTemplateFormatVersion: '2010-09-09'
Description: EventBridge Schema Registry with restricted access policy
Parameters:
RegistryName:
Type: String
Description: Name of the schema registry
Default: my-registry
TrustedAccountId:
Type: String
Description: AWS Account ID to grant access
AllowedPattern: '[0-9]{12}'
Resources:
SchemaRegistry:
Type: AWS::EventSchemas::Registry
Properties:
RegistryName: !Ref RegistryName
Description: Schema registry with restricted access policy
SchemaRegistryPolicy:
Type: AWS::EventSchemas::RegistryPolicy
Properties:
RegistryName: !Ref SchemaRegistry
Policy:
Version: '2012-10-17'
Statement:
- Sid: AllowTrustedAccountAccess
Effect: Allow
Principal:
AWS: !Sub 'arn:aws:iam::${TrustedAccountId}:root'
Action:
- schemas:*
Resource: '*'
Outputs:
RegistryArn:
Description: ARN of the schema registry
Value: !GetAtt SchemaRegistry.RegistryArn
Terraform (optional)
resource "aws_schemas_registry" "example" {
name = "my-registry"
description = "Schema registry with restricted access policy"
}
resource "aws_schemas_registry_policy" "example" {
registry_name = aws_schemas_registry.example.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "AllowTrustedAccountAccess"
Effect = "Allow"
Principal = { AWS = "arn:aws:iam::123456789012:root" }
Action = "schemas:*"
Resource = "*"
}]
})
}
For organization-wide read-only access:
resource "aws_schemas_registry_policy" "org_readonly" {
registry_name = aws_schemas_registry.example.name
policy = jsonencode({
Version = "2012-10-17"
Statement = [{
Sid = "AllowOrganizationReadAccess"
Effect = "Allow"
Principal = "*"
Action = [
"schemas:DescribeSchema",
"schemas:GetDiscoveredSchema",
"schemas:SearchSchemas",
"schemas:ListSchemas"
]
Resource = "*"
Condition = {
StringEquals = {
"aws:PrincipalOrgID" = "o-xxxxxxxxxx"
}
}
}]
})
}
Verification
After making changes, verify the remediation was successful:
- Return to the EventBridge console and check the Resource policy tab for your registry
- Confirm that only trusted account ARNs or your organization ID appear in the policy
- Re-run the Prowler check to confirm it passes
CLI verification commands
# View the updated policy
aws schemas get-resource-policy \
--registry-name <your-registry-name> \
--region us-east-1
# Re-run Prowler check for this specific control
prowler aws --checks eventbridge_schema_registry_cross_account_access
Additional Resources
- AWS EventBridge Schemas documentation
- Resource-based policies for EventBridge Schemas
- AWS cross-account EventBridge schema sharing
Notes
- Legitimate cross-account sharing: Some organizations intentionally share schemas across accounts for integration purposes. Before removing access, verify with your team whether cross-account access is required.
- Least privilege: Even when cross-account access is needed, consider granting read-only permissions (
schemas:Describe*,schemas:Get*,schemas:List*,schemas:Search*) rather than fullschemas:*access. - AWS-managed registries: AWS provides built-in registries (like
aws.events) that have their own policies. This check focuses on custom registries you create. - Policy versioning: When updating policies, the
revision-idparameter can be used to prevent concurrent modification conflicts.