{
  "title": "How to Configure AWS IAM and Groups to Limit Information System Access to Allowed Transactions and Functions (Practical Guide) — FAR 52.204-21 / CMMC 2.0 Level 1 - Control - AC.L1-B.1.II",
  "date": "2026-04-03",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/how-to-configure-aws-iam-and-groups-to-limit-information-system-access-to-allowed-transactions-and-functions-practical-guide-far-52204-21-cmmc-20-level-1-control-acl1-b1ii.jpg",
  "content": {
    "full_html": "<p>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.</p>\n\n<h2>Why this control matters and the risk of not implementing it</h2>\n<p>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.</p>\n\n<h2>Key AWS IAM constructs to meet the control</h2>\n<p>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.</p>\n\n<h2>Step-by-step implementation</h2>\n\n<h3>1) Design your role/group matrix (people -> group -> permissions)</h3>\n<p>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.</p>\n\n<h3>2) Create least-privilege policies (concrete examples)</h3>\n<p>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:</p>\n\n<pre><code class=\"language-json\">{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowListAndGetOnDevBuckets\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:ListBucket\",\n        \"s3:GetObject\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::acme-dev-bucket\",\n        \"arn:aws:s3:::acme-dev-bucket/*\"\n      ]\n    }\n  ]\n}\n</code></pre>\n\n<p>Example: allow Ops to Start/Stop only EC2 instances tagged Environment=prod and Owner=ops-team:</p>\n\n<pre><code class=\"language-json\">{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowStartStopTaggedEC2\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"ec2:StartInstances\",\n        \"ec2:StopInstances\"\n      ],\n      \"Resource\": \"arn:aws:ec2:*:*:instance/*\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"ec2:ResourceTag/Environment\": \"prod\",\n          \"ec2:ResourceTag/Owner\": \"ops-team\"\n        }\n      }\n    }\n  ]\n}\n</code></pre>\n\n<p>Make policies explicit — prefer Deny statements for critical guardrails (e.g., Deny Delete of S3 buckets holding CUI) and avoid broad wildcards like \"*\".</p>\n\n<h3>3) Create IAM groups and attach policies (console & CLI)</h3>\n<p>Console: IAM -> Groups -> Create group -> attach your custom policies. CLI example:</p>\n\n<pre><code class=\"languagebash\"># Create a group\naws iam create-group --group-name OpsGroup\n\n# Attach a policy to the group\naws iam attach-group-policy --group-name OpsGroup --policy-arn arn:aws:iam::123456789012:policy/EC2StartStopProdOnly\n\n# Add user to group\naws iam add-user-to-group --user-name alice --group-name OpsGroup\n</code></pre>\n\n<p>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.</p>\n\n<h3>4) Constrain delegated admins with permission boundaries and SCPs</h3>\n<p>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:</p>\n\n<pre><code class=\"language-json\">{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"DenyCreateAdminIAM\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\",\n        \"iam:AttachUserPolicy\",\n        \"iam:PutUserPolicy\",\n        \"iam:CreateAccessKey\"\n      ],\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"ForAnyValue:StringLike\": {\n          \"iam:PolicyARN\": \"arn:aws:iam::*:policy/AdministratorAccess\"\n        }\n      }\n    }\n  ]\n}\n</code></pre>\n\n<h2>Monitoring, auditing, and evidence for compliance</h2>\n<p>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.</p>\n\n<h2>Practical tips, small-business scenarios, and best practices</h2>\n<p>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.</p>\n\n<h2>Conclusion</h2>\n<p>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.</p>",
    "plain_text": "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.\n\nWhy this control matters and the risk of not implementing it\nAC.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.\n\nKey AWS IAM constructs to meet the control\nUse 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.\n\nStep-by-step implementation\n\n1) Design your role/group matrix (people -> group -> permissions)\nStart 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.\n\n2) Create least-privilege policies (concrete examples)\nAuthor 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:\n\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowListAndGetOnDevBuckets\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"s3:ListBucket\",\n        \"s3:GetObject\"\n      ],\n      \"Resource\": [\n        \"arn:aws:s3:::acme-dev-bucket\",\n        \"arn:aws:s3:::acme-dev-bucket/*\"\n      ]\n    }\n  ]\n}\n\n\nExample: allow Ops to Start/Stop only EC2 instances tagged Environment=prod and Owner=ops-team:\n\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"AllowStartStopTaggedEC2\",\n      \"Effect\": \"Allow\",\n      \"Action\": [\n        \"ec2:StartInstances\",\n        \"ec2:StopInstances\"\n      ],\n      \"Resource\": \"arn:aws:ec2:*:*:instance/*\",\n      \"Condition\": {\n        \"StringEquals\": {\n          \"ec2:ResourceTag/Environment\": \"prod\",\n          \"ec2:ResourceTag/Owner\": \"ops-team\"\n        }\n      }\n    }\n  ]\n}\n\n\nMake policies explicit — prefer Deny statements for critical guardrails (e.g., Deny Delete of S3 buckets holding CUI) and avoid broad wildcards like \"*\".\n\n3) Create IAM groups and attach policies (console & CLI)\nConsole: IAM -> Groups -> Create group -> attach your custom policies. CLI example:\n\n# Create a group\naws iam create-group --group-name OpsGroup\n\n# Attach a policy to the group\naws iam attach-group-policy --group-name OpsGroup --policy-arn arn:aws:iam::123456789012:policy/EC2StartStopProdOnly\n\n# Add user to group\naws iam add-user-to-group --user-name alice --group-name OpsGroup\n\n\nAlways 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.\n\n4) Constrain delegated admins with permission boundaries and SCPs\nIf 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:\n\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"DenyCreateAdminIAM\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"iam:CreateUser\",\n        \"iam:AttachUserPolicy\",\n        \"iam:PutUserPolicy\",\n        \"iam:CreateAccessKey\"\n      ],\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"ForAnyValue:StringLike\": {\n          \"iam:PolicyARN\": \"arn:aws:iam::*:policy/AdministratorAccess\"\n        }\n      }\n    }\n  ]\n}\n\n\nMonitoring, auditing, and evidence for compliance\nEnable 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.\n\nPractical tips, small-business scenarios, and best practices\nSmall-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.\n\nConclusion\nImplementing 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."
  },
  "metadata": {
    "description": "Practical, step-by-step guidance to implement FAR 52.204-21 / CMMC 2.0 AC.L1-B.1.II in AWS using IAM groups, roles, least privilege policies, permission boundaries, and monitoring to limit access to allowed transactions and functions.",
    "permalink": "/how-to-configure-aws-iam-and-groups-to-limit-information-system-access-to-allowed-transactions-and-functions-practical-guide-far-52204-21-cmmc-20-level-1-control-acl1-b1ii.json",
    "categories": [],
    "tags": []
  }
}