Authentication Hardening & Conditional Access

With stolen credentials causing 36% of cloud incidents, strong authentication is your first line of defense. MFA adoption has reached 53% in enterprises (2024), but implementation quality varies significantly.

Multi-Factor Authentication (MFA)

MFA Types and Strength

Type	Security Level	Use Case
Hardware security key (FIDO2)	Highest	Root accounts, admins
Hardware TOTP token	High	Regulated environments
Authenticator app (TOTP)	Medium	General users
SMS/Email codes	Low (avoid)	Legacy only, being phased out
Push notification	Medium	Convenience balance

AWS MFA Configuration

Root account (mandatory):

# Hardware MFA for root is critical - CIS Benchmark 1.5
aws iam create-virtual-mfa-device --virtual-mfa-device-name root-mfa

# Enable for root user
aws iam enable-mfa-device \
    --user-name root \
    --serial-number arn:aws:iam::123456789012:mfa/root-mfa \
    --authentication-code-1 123456 \
    --authentication-code-2 654321

IAM users with policy enforcement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllExceptListedIfNoMFA",
      "Effect": "Deny",
      "NotAction": [
        "iam:CreateVirtualMFADevice",
        "iam:EnableMFADevice",
        "iam:GetUser",
        "iam:ListMFADevices",
        "iam:ListVirtualMFADevices",
        "iam:ResyncMFADevice",
        "sts:GetSessionToken"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Azure Conditional Access

Azure provides sophisticated access control beyond simple MFA:

Basic MFA policy:

{
  "displayName": "Require MFA for All Users",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "applications": {
      "includeApplications": ["All"]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["mfa"]
  }
}

Risk-based conditional access:

{
  "displayName": "Block High Risk Sign-ins",
  "state": "enabled",
  "conditions": {
    "users": {
      "includeUsers": ["All"]
    },
    "signInRiskLevels": ["high", "medium"]
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": ["block"]
  }
}

Location-based restrictions:

{
  "displayName": "Admin Access from Named Locations Only",
  "conditions": {
    "users": {
      "includeRoles": [
        "62e90394-69f5-4237-9190-012177145e10"
      ]
    },
    "locations": {
      "includeLocations": ["All"],
      "excludeLocations": ["TrustedOfficeLocations"]
    }
  },
  "grantControls": {
    "builtInControls": ["block"]
  }
}

GCP Context-Aware Access

# Access level requiring device compliance
accessLevels:
  - name: "accessPolicies/123/accessLevels/corporate_devices"
    basic:
      conditions:
        - devicePolicy:
            requireCorpOwned: true
            osConstraints:
              - osType: DESKTOP_CHROME_OS
                minimumVersion: "100"
        - ipSubnetworks:
            - "10.0.0.0/8"

Session Security

Session Duration Limits

Provider	Default	Recommended
AWS IAM	12 hours	1-4 hours for admins
Azure	Configurable	1 hour for sensitive ops
GCP	12 hours	Short sessions, frequent re-auth

AWS: Limit role session duration:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:user/dev"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "NumericLessThan": {
        "sts:MaxSessionDuration": "3600"
      }
    }
  }]
}

Just-in-Time (JIT) Access

Azure Privileged Identity Management (PIM):

• Users request elevated access
• Approval workflow triggers
• Access granted for limited time
• Full audit trail

# Activate PIM role (Azure CLI)
az rest --method POST \
    --uri "https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests" \
    --body '{
        "principalId": "user-guid",
        "roleDefinitionId": "admin-role-guid",
        "directoryScopeId": "/",
        "action": "SelfActivate",
        "scheduleInfo": {
            "expiration": {
                "type": "afterDuration",
                "duration": "PT4H"
            }
        }
    }'

Zero Trust Implementation

The Zero Trust model: "Never trust, always verify."

Core Principles

Principle	Implementation
Verify explicitly	MFA, device compliance, location
Least privilege	Just-in-time, just-enough access
Assume breach	Micro-segmentation, monitoring

Zero Trust Architecture

┌─────────────────────────────────────────────────────────┐
│                    Access Decision                       │
├─────────────────────────────────────────────────────────┤
│  User Identity → Device Health → Location → Context     │
│       ↓              ↓             ↓          ↓         │
│  Strong Auth    Compliance     Geofence   Time/Risk    │
│       ↓              ↓             ↓          ↓         │
│  ──────────────── Policy Engine ────────────────       │
│                        ↓                                │
│              Allow / Deny / Step-up Auth                │
└─────────────────────────────────────────────────────────┘

Authentication Audit Checklist

Control	Status	Priority
Root/admin accounts have hardware MFA	☐	Critical
All users require MFA	☐	High
Conditional access policies deployed	☐	High
Session timeouts configured	☐	Medium
Impossible travel detection enabled	☐	Medium
JIT access for privileged roles	☐	Medium
Device compliance required	☐	Medium
Legacy authentication blocked	☐	High

Next module: We'll secure cloud storage services—the most common source of data exposure. :::