How to govern Security in AWS Bedrock
A step-by-step guide to governing Security in AWS Bedrock with Rencore: detect, review by owner and severity, and remediate with an audit trail.
Governing Security in AWS Bedrock means finding where it goes wrong, reviewing the findings by owner and severity, and remediating with an audit trail. Rencore covers this concern for AWS Bedrock with the pre-built controls below, so it becomes a repeatable check rather than a one-off cleanup. The steps that follow apply the same detect, review, remediate loop to Security.
Steps
-
Inventory AWS Bedrock
Connect AWS Bedrock and let Rencore build a continuous inventory of its resources, owners, and configuration, so governance starts from what exists rather than a stale export.
-
Detect with policies
Turn on the pre-built policies that cover Security in AWS Bedrock to surface oversharing, sprawl, and misconfiguration on the first scan, before writing a single custom rule.
-
Review by owner and severity
Use the AWS Bedrock reports to review findings by owner, category, and severity, and to share them with stakeholders who do not have a seat in the platform.
-
Remediate and automate
Apply automations to fix findings at scale, route sensitive changes through approvals, and keep every action reversible and logged for the audit trail.
AWS Bedrock controls for Security
Grounded in the Rencore catalog. See the full AWS Bedrock catalog on the AWS Bedrock connector page.
-
Agent can perform actions
Agents with an enabled action group can invoke external APIs, raising the likelihood of real-world impact
Severity: High -
IAM user has console access
Users with interactive console access are a more readily exploited entry point
Severity: Medium -
IAM user has active access keys
Users with active programmatic credentials are a more likely source of a credential leak
Severity: Medium -
Role assumable by Bedrock
Roles assumable by the Bedrock service have live, runtime-exercised permissions
Severity: Medium -
AWS Bedrock Agent without Guardrail
Detects agents that do not have a guardrail configured
Severity: Medium -
AWS Bedrock Agent using deprecated model
Detects agents using foundation models with LEGACY or EOL lifecycle status
Severity: High -
AWS Bedrock Custom Model without Guardrail
Detects custom models that are not protected by any guardrail
Severity: Medium -
AWS Bedrock Guardrail without content policy
Detects guardrails that do not have a content filtering policy configured
Severity: High -
AWS Bedrock Guardrail without PII detection
Detects guardrails that do not have PII detection enabled
Severity: Medium -
AWS Bedrock region without invocation logging
Detects account regions where model invocation logging is not enabled
Severity: High -
IAM user without MFA enabled
Detects IAM users that do not have multi-factor authentication enabled
Severity: High -
IAM user with console access but no MFA
Detects IAM users who have console login enabled without MFA protection
Severity: High -
IAM user with multiple active access keys
Detects IAM users with more than one active access key
Severity: Low -
IAM user with access keys older than 90 days
Detects IAM users with active access keys whose account was created more than 90 days ago, indicating keys that may need rotation
Severity: Medium -
IAM role with overly permissive Bedrock access
Detects Bedrock-related IAM roles with more than 5 attached policies, indicating potentially excessive permissions
Severity: Medium -
AWS Bedrock Guardrails by Status
Shows the distribution of guardrails by their current status
-
IAM Users by MFA Status
Shows IAM users grouped by MFA enabled/disabled status
-
IAM Users by Access Key Count
Shows IAM users grouped by number of access keys
-
IAM Users without MFA
Shows IAM users that do not have MFA enabled
-
IAM Users with Console Access
Shows IAM users that have console login enabled
