CompTIA Security+ PAM and Just-in-Time, JIT, Access - Zero-Fluff, Hands-On Guide

CompTIA Security+ PAM & Just-in-Time (JIT) Access: Zero-Fluff, Hands-On Guide

1. What This Is & Why It Matters

Privileged Access Management (PAM) is the set of tools and processes that control, monitor, and audit accounts with elevated permissions (e.g., admins, service accounts, root users). Just-in-Time (JIT) Access is a PAM strategy where privileges are granted only when needed and revoked immediately after use—like a temporary keycard for a server room.

Why This Matters in Production

• Attackers love privileged accounts. 80% of breaches involve compromised admin credentials (Verizon DBIR).
• Compliance demands it. PCI DSS, HIPAA, and SOC 2 require strict control over privileged access.
• Human error is inevitable. A misconfigured chmod 777 or accidental rm -rf / can destroy a system. JIT limits exposure.

Real-world scenario: You’re a sysadmin at a healthcare company. A developer needs root access to a production database to debug a critical outage. Without PAM/JIT, you’d either:
1. Give them permanent admin rights-Risk of misuse or credential theft.
2. Manually SSH in and run commands for them-Bottleneck, slow response.
3. Use JIT-Grant temporary, audited access that auto-revokes after 30 minutes.

This guide will show you how to implement PAM/JIT today—with real commands, configs, and best practices.

2. Core Concepts & Components

3. Step-by-Step: Implementing JIT Access in AWS (Hands-On)

Prerequisites

• AWS account with IAM admin permissions.
• Basic familiarity with AWS CLI (aws configure).
• A test IAM user (e.g., dev-user) with no admin rights.

Goal

Grant dev-user temporary admin access to an EC2 instance only when needed, with auto-revocation.

Step 1: Create a JIT IAM Policy

This policy allows dev-user to assume a role with admin rights only when approved.

# Create a JSON policy file (jit-admin-policy.json)
cat > jit-admin-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::YOUR_ACCOUNT_ID:role/JIT-Admin-Role",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        },
        "NumericLessThanEquals": {
          "aws:MultiFactorAuthAge": "3600"  # Require MFA within last hour
        }
      }
    }
  ]
}
EOF

Apply the policy:

aws iam create-policy --policy-name JIT-Admin-Policy --policy-document file://jit-admin-policy.json

Step 2: Create the JIT Admin Role

This role has admin permissions but can only be assumed via the JIT policy.

# Create a trust policy (trust-policy.json)
cat > trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::YOUR_ACCOUNT_ID:user/dev-user"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}
EOF

# Create the role
aws iam create-role --role-name JIT-Admin-Role --assume-role-policy-document file://trust-policy.json

# Attach admin permissions to the role
aws iam attach-role-policy --role-name JIT-Admin-Role --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Step 3: Grant dev-user Permission to Assume the Role

aws iam attach-user-policy --user-name dev-user --policy-arn arn:aws:iam::YOUR_ACCOUNT_ID:policy/JIT-Admin-Policy

Step 4: Test JIT Access

As dev-user, request temporary credentials:

# Get temporary credentials (valid for 1 hour)
aws sts assume-role \
  --role-arn arn:aws:iam::YOUR_ACCOUNT_ID:role/JIT-Admin-Role \
  --role-session-name "JIT-Admin-Session" \
  --duration-seconds 3600

Output:

{
  "Credentials": {
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "SessionToken": "...",
    "Expiration": "2024-01-01T12:00:00Z"
  }
}

Export credentials and test access:

export AWS_ACCESS_KEY_ID="ASIA..."
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

# Verify admin access (e.g., list EC2 instances)
aws ec2 describe-instances

After 1 hour, the credentials expire automatically.

Step 5: Automate Revocation (Optional)

Use AWS Lambda + CloudWatch Events to auto-revoke sessions after a set time.

# Create a Lambda function (Python) to revoke sessions
cat > revoke-session.py << 'EOF'
import boto3

def lambda_handler(event, context):
    client = boto3.client('iam')
    response = client.list_users()
    for user in response['Users']:
        if 'dev-user' in user['UserName']:
            client.delete_access_key(UserName=user['UserName'], AccessKeyId=event['AccessKeyId'])
    return {'statusCode': 200}
EOF

Trigger the Lambda via CloudWatch after 1 hour.

4.-Production-Ready Best Practices

Security

• Enforce MFA for all JIT requests. No MFA = no access.
• Restrict JIT roles to specific regions/IPs. Example: Only allow us-east-1 and corporate VPN IPs.
• Log everything. Use AWS CloudTrail + SIEM (e.g., Splunk, Datadog) to monitor JIT sessions.
• Rotate credentials automatically. Use AWS Secrets Manager or HashiCorp Vault for ephemeral credentials.

Cost Optimization

• Use AWS STS for JIT instead of long-lived IAM users. STS tokens are free; IAM users cost $0.05/month.
• Set short session durations. Default to 1 hour; extend only if needed.

Reliability & Maintainability

• Tag JIT roles. Example: Purpose=JIT-Admin, Owner=DevOps.
• Document approval workflows. Example: "To request JIT access, Slack #devops with a Jira ticket."
• Test revocation. Simulate a compromised session and verify auto-revocation works.

Observability

• Monitor:
• AssumeRole events in CloudTrail.
• Failed JIT requests (possible brute-force attacks).
• Session duration (long sessions = risk).
• Alert on:
• JIT access outside business hours.
• Multiple failed JIT requests from the same IP.

5. Common Mistakes & Traps

6.-Exam/Certification Focus (CompTIA Security+)

Key Concepts for the Exam

• PAM vs. IAM:
• IAM = Identity and Access Management (who can do what).
• PAM = Subset of IAM focused on privileged accounts.
• JIT vs. Standing Privilege:
• Standing privilege = Permanent admin rights (bad).
• JIT = Temporary access (good).
• Session Monitoring:
• Required for compliance (e.g., PCI DSS, HIPAA).
• Tools: AWS Session Manager, CyberArk, BeyondTrust.

Common Question Patterns

1. "Which is the most secure way to grant admin access?"
2. ? JIT with MFA and session logging.

3. Permanent admin rights.

4. "What’s the risk of not using PAM?"

5. ? Credential theft, insider threats, compliance violations.

6. "It’s fine, we trust our team."

7. "Which tool is used for session monitoring?"

8. ? AWS Session Manager, CyberArk, BeyondTrust.
9. ? "SSH logs are enough."

Trap Distinctions

• PAM-Password Rotation:
• PAM = Controlling who has access.
• Password rotation = Changing how access is authenticated.
• JIT-Break-Glass:
• JIT = Temporary, approved access.
• Break-glass = Emergency, unapproved access (last resort).

7.-Hands-On Challenge

Challenge: You’re a DevOps engineer. A developer needs temporary sudo access on a Linux server to debug a production issue. Implement JIT access using sudo and pam_time.

Solution:
1. Edit /etc/sudoers to allow dev-user to run sudo only during business hours (9 AM–5 PM): bash dev-user ALL=(ALL) ALL, !authenticate, TIMES=0900-1700
2. Restrict sudo to specific commands (e.g., only systemctl restart nginx): bash dev-user ALL=(root) /bin/systemctl restart nginx
3. Test: bash sudo -l # Check allowed commands sudo systemctl restart nginx # Works sudo bash # Fails (not allowed)

Why it works: - pam_time enforces time-based restrictions. - sudoers limits commands to least privilege.

8.-Rapid-Reference Crib Sheet

9.-Where to Go Next

1. AWS IAM Best Practices – Official guide to least privilege.
2. HashiCorp Vault Tutorial – Learn to manage secrets securely.
3. CyberArk PAM Documentation – Enterprise-grade PAM solutions.
4. CompTIA Security+ Study Guide (PAM Section) – Official exam prep.

Final Thought

PAM and JIT aren’t just "nice-to-haves"—they’re non-negotiable in modern security. Start small:
1. Audit your privileged accounts (who has sudo, AWS admin, DB sa?).
2. Implement JIT for one high-risk system (e.g., production DB).
3. Enforce MFA and session logging for all JIT requests.

Do this today, and you’ll sleep better knowing attackers can’t move laterally with stolen admin creds. ?