Overview
The AWS integration reads security and configuration data from your AWS account to provide evidence for infrastructure controls. It uses a read-only IAM role — Matproof never modifies your AWS environment. Evidence collected automatically:- IAM users, roles, and policy assignments
- Root account MFA status
- CloudTrail logging enabled and configured
- S3 bucket encryption and public access settings
- Security groups with overly permissive rules (0.0.0.0/0 ingress)
- KMS key rotation status
- Password policy strength settings
- Unused IAM credentials (access keys not used in 90+ days)
- AWS Config enabled status
- GuardDuty enabled status
Prerequisites
- AWS account with permission to create IAM roles
- Matproof Admin or Owner role
- Ability to run a CloudFormation template or create IAM resources manually
Connecting AWS
Matproof uses a cross-account IAM role with read-only permissions. This is the AWS-recommended pattern for third-party integrations.Option A — CloudFormation (recommended)
- Go to Settings → Integrations → AWS → Connect
- Click Deploy CloudFormation Stack
- You will be redirected to your AWS Console with the CloudFormation template pre-loaded
- Review the template — it creates a single IAM role with the
ReadOnlyAccessmanaged policy - Click Create stack
- Once the stack is created, copy the Role ARN from the Outputs tab
- Paste the Role ARN back in Matproof and click Verify connection
Option B — Manual IAM role
- In AWS IAM, create a new role with Another AWS account as the trusted entity
- Enter Matproof’s AWS account ID (shown in the integration setup screen)
- Attach the
ReadOnlyAccessmanaged policy - Add a condition:
sts:ExternalId= the external ID shown in Matproof (prevents confused deputy attacks) - Copy the Role ARN and paste it in Matproof
Matproof only ever calls
sts:AssumeRole to assume your read-only role. It cannot elevate privileges or access resources outside the ReadOnlyAccess scope.Multi-Account Setup
If you use AWS Organizations with multiple accounts, you can connect each account separately. For large organizations, Matproof supports an Organizations-level connection that scans all member accounts using a delegated admin role. Contact support to set this up.What Gets Mapped to Which Controls
| Evidence Collected | Control Examples |
|---|---|
| Root account MFA enabled | Privileged access controls (SOC 2 CC6, ISO 27001 A.5.16) |
| CloudTrail enabled in all regions | Logging and monitoring controls (DORA Art. 10) |
| No S3 buckets with public read/write | Data protection controls |
| IAM password policy meets requirements | Access control policy controls |
| No access keys unused for 90+ days | Account lifecycle controls |
| KMS key rotation enabled | Cryptography controls (ISO 27001 A.8.24) |
| GuardDuty enabled | Threat detection controls |
| Security groups — no 0.0.0.0/0 on port 22/3389 | Network security controls |
Interpreting Failed Checks
Go to Integrations → AWS → Evidence to see all checks with pass/fail status. Failed checks appear as gaps on the relevant control. Click any failed check to see:- Which specific resource is failing (e.g., bucket name, security group ID)
- What the expected configuration is
- A direct link to the AWS Console to fix it
Common Issues
”Connection verification failed — invalid role ARN”
Check that:- The external ID in Matproof matches what you configured in the IAM role trust policy
- The role ARN is copied exactly (including the account ID)
- The Matproof AWS account ID is correctly listed as a trusted principal in the role