Audit report export fails to cloud storage with insufficient permissions after IAM policy update

QMS Qualio
, , , , , , , ,
1

Our audit report exports to AWS S3 suddenly started failing after our IT team updated IAM policies last week. The error mentions “Access Denied” but our SSO identity mapping looks correct in Qualio settings. We’re running qual-2022.2 and the integration worked fine for 6 months until this policy change.

The error we’re seeing:


ERROR: S3 PutObject failed - Access Denied (403)
Identity: arn:aws:sts::123456789:assumed-role/QualioExportRole
Bucket: company-audit-reports

Our SSO users can generate reports in Qualio, but the cloud storage write fails. We also have Azure Blob configured as backup but haven’t tested if it has the same issue. This is blocking our monthly compliance audit exports and we need reports for an FDA inspection next week. Has anyone dealt with IAM policy updates breaking existing cloud storage integrations?

2

I’ll walk you through fixing all three integration points - SSO identity mapping, IAM policy, and cloud storage configuration.

Step 1: SSO Identity Mapping Verify Qualio is passing the correct identity attributes during role assumption. In Qualio Admin > Integrations > Cloud Storage, check that the “SSO Role Mapping” field matches your IAM role ARN exactly: arn:aws:iam::123456789:role/QualioExportRole. The identity mapping must include session tags that your trust policy expects.

Step 2: IAM Policy Update Your trust policy needs to allow Qualio’s service principal while maintaining security. Update the trust relationship:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::QUALIO-ACCOUNT:role/ExportService"},
  "Action": "sts:AssumeRole",
  "Condition": {"StringEquals": {"sts:ExternalId": "your-unique-external-id"}}
}

Remove any IP-based conditions (aws:SourceIp) as these break SaaS integrations. The ExternalId provides security without IP restrictions. Get your unique ExternalId from Qualio Support.

For the role’s permission policy, ensure it has:

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:PutObjectAcl"],
  "Resource": "arn:aws:s3:::company-audit-reports/*"
}

Step 3: Cloud Storage Integration In Qualio, update the integration configuration:

  • Navigate to Admin > Integrations > Cloud Storage
  • For AWS S3: Enter the ExternalId in the “External ID” field
  • Test connection using “Verify Configuration” button
  • If verification passes, the role assumption is working

Step 4: Validate the Full Chain Test with a small audit report export:

  1. The SSO user’s identity is mapped to the IAM role
  2. Qualio assumes the role using ExternalId for security
  3. The assumed role session has permissions to write to S3
  4. The S3 bucket policy (if present) allows the role’s writes

Common gotcha: If you have a bucket policy, it might also need updating to allow the role. Check the bucket policy for any Deny statements that could override the role permissions.

Azure Blob Backup: While fixing AWS, configure Azure as your backup. The integration is simpler - just needs a SAS token with write permissions to your blob container. No complex trust policies required. This gives you redundancy and a working path for your FDA inspection.

The key insight: IAM policy updates often add conditions that break the session tag propagation from SSO through role assumption to S3 access. The ExternalId approach sidesteps this by providing security at the trust policy level without complex conditions that can interfere with identity mapping.

3

Qualio’s cloud services typically use dynamic IPs since they run on managed infrastructure. IP-based trust policies are problematic for SaaS integrations. Instead, use ExternalId in your trust policy for secure cross-account access without IP restrictions. This is AWS’s recommended approach for third-party service integrations. You’ll need to configure the ExternalId in both your IAM trust policy and in Qualio’s cloud storage integration settings. This provides security without the IP whitelist headache.

4

Check if the IAM policy update changed the trust relationship for the assumed role. The error shows it’s using an assumed role (QualioExportRole) which means there’s likely a trust policy that allows Qualio to assume that role. If IT updated policies, they might have inadvertently removed or modified the trust relationship. Also verify the bucket policy itself hasn’t changed - sometimes policy updates affect multiple resources.

5

We had this exact issue last year. The problem is usually a combination of trust policy conditions and the SSO identity mapping not propagating correctly to the assumed role. When you update IAM policies, sometimes the session tags that Qualio passes during role assumption get blocked by new condition keys. Check if your updated policy has StringEquals conditions on aws:RequestedRegion or aws:PrincipalTag that might be too restrictive.

6

Good point. I checked with IT and they did update trust policies across several roles. The QualioExportRole still exists but they tightened the conditions. They added a requirement for specific source IP addresses in the trust policy, which might be blocking Qualio’s cloud service IPs. Would Qualio’s export service use dynamic IPs or should I whitelist specific ranges?

7

Before changing trust policies, test your Azure Blob backup configuration. If that works, it confirms the issue is AWS-specific and not a general cloud storage problem in Qualio. This will also give you a working export path for your FDA inspection while you fix the AWS integration. You can switch the primary export target in Qualio’s cloud deployment settings temporarily.