This post explains how to implement the Compliance Framework control AC.L1-B.1.II (limit information system access to allowed transactions and functions) in AWS using IAM groups, policies, roles, and monitoring — with step-by-step actions, concrete policy examples, CLI commands, and small-business scenarios to make the guidance actionable and auditable for FAR 52.204-21 and CMMC 2.0 Level 1 compliance.
Why this control matters and the risk of not implementing it
AC.L1-B.1.II requires you to ensure users and processes can only perform allowed transactions and functions; failure to enforce this leads to over-privileged accounts, accidental or malicious data exposure, unauthorized configuration changes, and loss of contracts or penalties under FAR/CMMC. For a small business contracting with the federal government, even a single excessive IAM permission can expose Controlled Unclassified Information (CUI) and trigger a compliance finding or contract termination.
Key AWS IAM constructs to meet the control
Use IAM groups to represent job functions (e.g., Developer, Ops, Finance), attach least-privilege policies to those groups, and use IAM roles for cross-account or machine access. Complement groups/policies with permission boundaries for delegated admins, Service Control Policies (SCPs) in AWS Organizations for top-level restrictions, and attribute-based access control (ABAC) or resource tags to constrain actions to allowed resources. Enable CloudTrail, AWS Config, and IAM Access Analyzer for auditing and evidence.
Step-by-step implementation
1) Design your role/group matrix (people -> group -> permissions)
Start by listing job functions and the exact transactions they must perform. Example small-business matrix: Developer (deploy Lambda, read S3 dev buckets), Ops (start/stop EC2 in prod-ops-tagged resources), Finance (read-only billing). Map each function to an IAM group — do not attach policies to individual users. Document this matrix (who, why, scope) to produce audit evidence for FAR/CMMC.
2) Create least-privilege policies (concrete examples)
Author customer-managed policies that scope actions to the minimum required API calls and resources. Use resource ARNs and conditions (tags, aws:RequestTag, aws:PrincipalTag, aws:RequestedRegion) to restrict where operations can run. Example: S3 read-only for specific buckets:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowListAndGetOnDevBuckets",
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::acme-dev-bucket",
"arn:aws:s3:::acme-dev-bucket/*"
]
}
]
}
Example: allow Ops to Start/Stop only EC2 instances tagged Environment=prod and Owner=ops-team:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowStartStopTaggedEC2",
"Effect": "Allow",
"Action": [
"ec2:StartInstances",
"ec2:StopInstances"
],
"Resource": "arn:aws:ec2:*:*:instance/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Environment": "prod",
"ec2:ResourceTag/Owner": "ops-team"
}
}
}
]
}
Make policies explicit — prefer Deny statements for critical guardrails (e.g., Deny Delete of S3 buckets holding CUI) and avoid broad wildcards like "*".
3) Create IAM groups and attach policies (console & CLI)
Console: IAM -> Groups -> Create group -> attach your custom policies. CLI example:
# Create a group
aws iam create-group --group-name OpsGroup
# Attach a policy to the group
aws iam attach-group-policy --group-name OpsGroup --policy-arn arn:aws:iam::123456789012:policy/EC2StartStopProdOnly
# Add user to group
aws iam add-user-to-group --user-name alice --group-name OpsGroup
Always manage permissions through groups; avoid attaching inline policies to users. Use group naming conventions like GOV-Role-Env (e.g., GOV-Ops-Prod) and tag groups with project identifiers.
4) Constrain delegated admins with permission boundaries and SCPs
If you delegate IAM administration, apply permission boundaries to any principals allowed to create policies/roles so they cannot escalate beyond approved actions. If you use AWS Organizations, apply SCPs at the OU/account level to centrally prohibit disallowed actions (e.g., ec2:TerminateInstances across prod accounts). Example permission boundary that prevents creating IAM users with AdministratorAccess:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCreateAdminIAM",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:AttachUserPolicy",
"iam:PutUserPolicy",
"iam:CreateAccessKey"
],
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"iam:PolicyARN": "arn:aws:iam::*:policy/AdministratorAccess"
}
}
}
]
}
Monitoring, auditing, and evidence for compliance
Enable CloudTrail across all accounts and aggregate logs to a central, immutable S3 bucket with Object Lock where feasible. Use AWS Config rules (e.g., iam-user-no-policies-check, iam-password-policy) and IAM Access Analyzer to detect overly permissive policies. Generate IAM credential reports and record group membership snapshots monthly. For CMMC/FAR evidence, retain policy versions, group membership exports, and change control records showing policy reviews and approvals.
Practical tips, small-business scenarios, and best practices
Small-business example: A 12-person contractor should create three groups (Dev, Ops, Finance), one cross-account Role for CI/CD with tightly-scoped S3/CodeBuild permissions, and require MFA for console access. Use IAM roles for any automation (no long-lived keys on CI servers), and rotate any service account keys quarterly. Enforce least privilege from Day 1: default deny, then grant explicit APIs and resources. Regularly run iam-policy-simulate and Access Advisor to refine policies. Keep a change log (Jira/Ticket) tied to policy updates for audit trails.
Conclusion
Implementing AC.L1-B.1.II in AWS is practical and auditable: define job functions, build group-based least-privilege policies with resource and condition scoping, use permission boundaries and SCPs to prevent privilege escalation, and instrument monitoring for continuous assurance. For FAR 52.204-21 and CMMC Level 1 evidence, document your design, retain policy/version history, export group membership and credential reports, and schedule regular reviews — these steps reduce risk and demonstrate that only allowed transactions and functions are permitted.
