This post provides practical, actionable steps for small businesses and security teams to configure Azure Active Directory (Azure AD) and AWS Identity and Access Management (IAM) so non-privileged users cannot perform privileged operations, and so privileged activity is captured and retained to meet AC.L2-3.1.7 under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2.
What AC.L2-3.1.7 requires and implementation objectives
AC.L2-3.1.7 mandates preventing non-privileged users from executing privileged functions and capturing the events that indicate privileged access or attempts to execute privileged functions. Practical goals are: enforce least privilege, require controlled elevation for privileged operations, log role activations and privileged API calls, centralize those logs, and retain/alert on them for investigation and evidence during audits.
High-level implementation approach (Compliance Framework)
Map AC.L2-3.1.7 to these controls: (1) enforce RBAC and remove standing full-admin assignments, (2) require just-in-time (JIT) elevation and approval for privileged roles, (3) deny common privilege-escalation actions for non-privileged groups, and (4) enable comprehensive auditing (sign-ins, role activations, API calls) and forward logs to a central analytics/store solution. These activities satisfy the Compliance Framework practice of preventing unauthorized privileged activity and producing audit evidence.
Azure AD: block non-privileged execution (practical steps)
1) Move all admin role assignments from permanent to "eligible" using Azure AD Privileged Identity Management (PIM) — requires Azure AD Premium P2. In PIM, make roles "eligible" not "permanent," configure activation requirements (MFA, business justification, ticket number) and set a limited activation duration (e.g., 1 hour). 2) Use Azure RBAC on subscriptions/resource groups to avoid giving user-level Owner or Contributor rights—create Azure AD Security Groups mapped to narrowly scoped custom roles. 3) Use Conditional Access policies to require compliant device and MFA for any admin role activation or sign-in to sensitive portals. 4) Harden break-glass accounts: keep them offline, require separate credentials, and log their usage.
Azure-specific configuration details and examples
Portal steps: Azure AD > Privileged Identity Management > Azure AD roles or Azure resources > Select role > Add assignment > choose "Eligible" and set "Activation maximum duration." For Conditional Access: Azure AD > Security > Conditional Access > New policy: Assign to "Directory role = Global Administrator" and Require "Require multi-factor authentication" and "Require device to be marked as compliant." To export PIM and audit data: Azure AD > Diagnostic settings > Add diagnostic setting > select "AuditLogs" and "SignInLogs" and route to Log Analytics workspace or Event Hub or Storage Account for retention.
Azure AD: capture logs and build evidence
Enable and centralize logs: enable Azure AD Audit Logs and Sign-in logs, enable Activity Log diagnostics for subscriptions and resources, and forward all to a Log Analytics workspace or Microsoft Sentinel for query/alerting. Ensure PIM activity (role activation, approval, expiration) is routed to the same workspace. Recommended queries: detect role activations, role activation without MFA, and role activation outside business hours. Retention: set workspace retention according to policy—commonly 1 year or longer for CUI-related systems—while balancing cost.
AWS IAM: block non-privileged execution (practical steps)
1) Apply least-privilege IAM policies and use Roles for privileged operations rather than long-lived elevated user keys. 2) Create a distinction between "Privileged" and "NonPrivileged" groups and attach restrictive deny policies to the NonPrivileged group to block actions that allow privilege escalation (create roles/policies, attach policies, create users/keys). 3) Use permission boundaries and service control policies (SCPs) in Organizations to prevent privilege escalation even if a user can create policies. 4) Require MFA and approval for AssumeRole operations that grant elevated access; use role trust policies and attribute-based access controls (tags) to limit who can assume privileged roles.
AWS-specific configuration details and example IAM policy
Example deny policy to attach to a "NonPrivileged" group (scope carefully and test in a non-prod account): {"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":["iam:CreatePolicy","iam:PutRolePolicy","iam:AttachRolePolicy","iam:AttachUserPolicy","iam:CreateUser","iam:CreateAccessKey","iam:CreateRole","iam:PutUserPolicy","iam:PassRole"],"Resource":"*"}]}
Require MFA for role assumption by adding a Condition to the role's trust policy or a conditional policy: "Condition":{"Bool":{"aws:MultiFactorAuthPresent":"true"}}. Use permission boundaries for developers so even if they create a role, that role cannot grant more permissions than the boundary allows. For JIT-like elevation, use an approval workflow backed by AWS SSO or a ticketing system that triggers a short-lived role session (e.g., assume role for 1 hour).
AWS: capture logs and build evidence
Enable a multi-region AWS CloudTrail for all accounts and services: aws cloudtrail create-trail --name org-trail --s3-bucket-name audit-logs-bucket --is-multi-region-trail, then aws cloudtrail start-logging --name org-trail. Turn on CloudTrail Insights to capture anomalous API activity. Configure CloudTrail to deliver to an encrypted S3 bucket, enable log file validation, and forward to CloudWatch Logs or an analytics solution (e.g., Elastic, Splunk, or Amazon Athena for queries). For privileged activity, monitor for iam:CreateUser, iam:PutRolePolicy, sts:AssumeRole and include trails on both management and member accounts. Integrate GuardDuty and Security Hub for prioritized alerts.
Real-world scenarios and small business examples
Example 1 — Small MSP with a production tenant: Developers normally belong to a "Dev" group with a permission boundary that prevents them from creating roles/policies; production changes require opening a ticket and an admin uses PIM to activate an eligible role with justification. Logs (PIM activations, Azure AD sign-ins, activity logs) are forwarded to a Log Analytics workspace and a dedicated read-only account for the auditors. Example 2 — SMB running infrastructure in AWS: Operational staff assume a privileged role via AWS SSO after approval; assume-role events are captured by CloudTrail, shipped to a central S3 bucket, and processed nightly into Athena queries that generate weekly role-activity reports for compliance reviews.
Compliance tips, best practices and risks of not implementing AC.L2-3.1.7
Best practices: remove standing admin assignments, use PIM/JIT, enforce MFA and compliant devices for admin actions, centrally collect and protect logs, set alerting on unusual privilege activations, and test deny policies in a sandbox. Keep an auditable approval trail tied to role activations (ticket IDs in activation justification). Risks of non-implementation include silent privilege escalation, data exfiltration of CUI, failed audits and loss of contracts, regulatory penalties, and increased incident response costs.
Summary: To meet AC.L2-3.1.7 for NIST SP 800-171 / CMMC 2.0 Level 2, combine least-privilege RBAC, PIM/JIT elevation, deny policies/permission boundaries, MFA and approval controls, and centralized logging (Azure AuditLogs/SignInLogs + Log Analytics/Microsoft Sentinel; AWS CloudTrail + CloudWatch/Athena/Security Hub). For small businesses, start by removing permanent admin assignments, enabling PIM/CloudTrail, routing logs to a single secured store, and implementing simple approval workflows for elevation—then iterate toward automated alerts and longer retention as budget permits.
