This post explains how to implement access control lists (ACLs) and identity and access management (IAM) policies to meet FAR 52.204-21 and CMMC 2.0 Level 1 (AC.L1-B.1.II) requirements — with practical, actionable examples for AWS, Azure, and GCP suitable for small businesses operating under federal contracts.
Understanding the requirement and objective
FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.II require that you limit system access to authorized users, processes, and devices — enforcing least privilege and reducing the attack surface. For small businesses this means implementing identity controls, resource-level policies, and network ACLs or firewall rules to ensure only the right principals perform the intended actions on the right resources at the right times, and producing evidence of that control.
Principles: ACLs vs IAM policies and how they work together
ACLs and IAM policies are complementary. IAM policies (identity- or resource-based) define what principals (users, groups, service accounts, roles) can do. ACLs and network controls (bucket ACLs, security groups, NSGs, firewall rules, subnet NACLs) constrain where and how access occurs. For compliance implement: least privilege IAM policies, resource policies to restrict access scope, network ACLs/NSGs/firewalls to limit protocol/IP ranges, and logging to prove enforcement. Prefer resource-based policies over legacy ACLs where possible and prefer role-based access (temporary roles/service accounts) rather than long-lived user credentials.
AWS: concrete controls and examples
Practical AWS steps for a small business: 1) centralize identities in IAM or AWS SSO, 2) create roles with narrowly scoped permissions, 3) attach resource policies (S3 bucket policies, KMS key policies) that further restrict access, 4) use VPC security groups and NACLs to limit network level access, and 5) enable CloudTrail and AWS Config for evidence. Example IAM policy that allows a specific role read-only access to one S3 bucket and enforces access from a corporate IP range:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadOnlyToSpecificBucketFromCorpIP",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::acme-corp-fci",
"arn:aws:s3:::acme-corp-fci/*"
],
"Condition": {
"IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
}
}
]
}
For network ACLs: prefer Security Groups for instance-level controls and use NACLs for subnet-level stateless filtering. Example AWS CLI to create a restrictive NACL rule (deny all inbound except SSH from management IP):
aws ec2 create-network-acl-entry --network-acl-id acl-12345678 --rule-number 100 --protocol tcp --port-range From=22,To=22 --egress false --rule-action allow --cidr-block 203.0.113.5/32
aws ec2 create-network-acl-entry --network-acl-id acl-12345678 --rule-number 200 --protocol -1 --egress false --rule-action deny --cidr-block 0.0.0.0/0
Azure: RBAC, NSGs and resource policies
In Azure, use Azure AD identities + RBAC assignments, Network Security Groups (NSGs) and optionally Azure Policy to enforce required settings. For a small company with a storage account storing FCI, assign the built-in role Storage Blob Data Reader at the container scope to a service principal, and use an NSG to restrict management plane access. Example Azure CLI to assign a role at container scope:
az role assignment create \
--assignee 11111111-2222-3333-4444-555555555555 \
--role "Storage Blob Data Reader" \
--scope "/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{acct}/blobServices/default/containers/{container}"
To limit network access, create an NSG rule that allows only your office IPs to reach management ports and denies everything else. Also enable Azure Monitor diagnostic settings and Activity Logs for evidence collection. For conditional access (recommended), require MFA for interactive sign-ins to Azure resources handling controlled unclassified information (CUI/FCI).
GCP: IAM bindings, service accounts, and VPC firewall rules
GCP best practices: map people to Google identities, give work to short-lived service accounts, attach narrowly-scoped IAM roles at the bucket or project level, and secure network traffic with VPC firewall rules. Example to grant a service account viewer access to a single Cloud Storage bucket using the gcloud storage command:
gcloud storage buckets add-iam-policy-binding gs://acme-fci-bucket \
--member=serviceAccount:svc-acme@appspot.gserviceaccount.com \
--role=roles/storage.objectViewer
Use VPC firewall rules to restrict ingress to application instances, e.g. allow 443 only from corporate IP ranges and deny all other ingress. Enable Audit Logs for admin and data access to provide compliance evidence. Consider IAM Conditions to add attribute-based restrictions (time-of-day, resource.name) when available.
Monitoring, evidence and operational tips
To satisfy compliance you must also show enforcement and monitoring. Turn on CloudTrail (AWS), Azure Activity Logs + Diagnostic Settings, and GCP Audit Logs. Configure alerting for suspicious permission changes (e.g., new role assignments, resource-based policy edits), and use automated policy-as-code (AWS Config rules / Azure Policy / Forseti or GCP Organization Policy) to detect drift. Maintain a simple change log: who requested access, why, approval evidence, and an expiration date for temporary access. For small businesses use tags/labels on principals and resources for mapping to roles in your POA&M and evidence packages.
Risk of not implementing these controls
Failure to limit access increases several risks: unauthorized disclosure of FCI/CUI, lateral movement by attackers, supply-chain compromise, contractual penalties, and debarment from federal work. Operational risks include credential sprawl, undetected privilege creep, and inability to produce audit evidence during assessments — all of which can lead to lost contracts and regulatory fines. Implementing the controls above materially reduces those risks.
Summary: implement least-privilege IAM policies combined with resource policies and network ACLs/NSGs/firewalls, instrument logging and automated checks, and document role-to-resource assignments. The examples for AWS, Azure, and GCP above give concrete commands and policy snippets you can adapt for a small business to meet FAR 52.204-21 and CMMC 2.0 Level 1 AC.L1-B.1.II — prioritize short-lived credentials, conditional access, and logging to both enforce and prove compliance.
