Add operational hygiene layer: password enforcement, rate limiting, log rotation

[Copilot]

Implements production-readiness controls for MiniFW-AI gateway: mandatory password change on first login, login rate limiting, and audit log rotation. Does not modify existing detection-to-enforcement binding.

Password Change Enforcement (P0)

New users must change their generated password before accessing dashboard:

• Login flow checks must_change_password flag post-authentication
• Middleware blocks protected routes until flag cleared
• create_user() defaults flag to True for new accounts
• Applies to both standard and 2FA flows

# app/middleware/auth_middleware.py
if user.must_change_password:
    if not request.url.path.startswith("/auth/change-password"):
        raise HTTPException(status_code=403, detail="Password change required")

Login Rate Limiting (P1)

Token Bucket algorithm limits login attempts to 5/minute per source IP:

• New rate_limiter.py module with thread-safe bucket implementation
• Applied as dependency to POST /auth/login
• Returns HTTP 429 with Retry-After header on limit exceeded
• Automatic cleanup of stale entries (>1 hour)

# app/web/routers/auth.py
@router.post("/login", dependencies=[Depends(check_rate_limit)])
def login(request: Request, username: str = Form(...), ...):
    # Rate limiter enforces 5 attempts/min before this executes

Audit Log Rotation (P2)

Standard logrotate configuration for /opt/minifw_ai/logs/audit.jsonl:

• Daily rotation, 30-day retention
• Compress with delaycompress, preserve permissions (640 minifw adm)
• Installed automatically by install_systemd.sh

# config/minifw-audit.logrotate
/opt/minifw_ai/logs/audit.jsonl {
    daily
    rotate 30
    compress
    create 640 minifw adm
}

CI/CD Protection

Marked TestDetectionEnforcementBinding in verify_sprint.py as CRITICAL CI/CD COMPONENT to prevent accidental removal of audit binding tests.

Security Properties

• Fail-closed: rate limiter blocks on error, middleware blocks on flag check failure
• Thread-safe: rate limiter uses threading.Lock for atomic operations
• Audit trail: password changes logged with PASSWORD_CHANGED action
• In-memory: rate limiter does not persist across restarts (consider Redis for multi-instance)

Original prompt

Role

Act as a Senior DevOps & Security Engineer. We have just completed a "Governance Audit" sprint for the MiniFW-AI (RitAPI V-Sentinel) project. The core audit binding logic is complete.

Objective

Your goal is to implement the "Operational Hygiene" layer to make the system production-ready. You must implement three specific security controls and ensure our testing pipeline is robust.

Context & Constraints

• Project Type: Python/FastAPI backend with a lightweight frontend.
• Environment: Systemd-managed service on a Linux gateway.
• Strict Requirement: Do not break existing "Detection-to-Enforcement" UUID binding logic.
• Fail-Closed: Security controls must fail securely (e.g., if rate limiting fails, block the request).

---

Tasks to Execute

Task 1: Enforce Password Change on First Login (P0 Hygiene)

Goal: Force users/admins to change their generated password immediately after their first successful login.

1. Database/Model Update: Modify the User model (likely in app/models.py or app/auth.py) to add a boolean field must_change_password (default: True for new users).
2. Middleware Logic: In app/web/routers/auth.py (or the login endpoint), check this flag after credential verification.
3. Frontend Handling:
   • If must_change_password is True, redirect the user to a new /auth/change-password page instead of the dashboard.
   • Block access to all other dashboard routes until the password is updated.
4. Endpoint: Create the POST /auth/change-password endpoint that updates the password and sets must_change_password = False.

Task 2: Implement Login Rate Limiting (P1)

Goal: Prevent brute-force attacks on the web dashboard.

1. Implementation: Implement a lightweight, in-memory rate limiter (Token Bucket or Fixed Window) or use slowapi if compatible with our dependencies.
2. Target: Apply this strictly to the POST /token (login) endpoint.
3. Policy: Limit to 5 failed attempts per minute per IP address.
4. Response: Return HTTP 429 "Too Many Requests" with a Retry-After header.

Task 3: Audit Log Rotation (P2)

Goal: Prevent audit.jsonl from consuming all disk space while preserving evidence.

1. Configuration: Create a standard Linux logrotate configuration file at config/minifw-audit.logrotate.
2. Rules:
   • Rotate daily.
   • Retain 30 days of logs.
   • Compress old logs (compress).
   • ensure permissions are preserved (create 640 minifw adm).
3. Installer Script: Update scripts/install_systemd.sh (or create a new scripts/setup_logrotate.sh) to symlink/copy this config to /etc/logrotate.d/minifw-audit.

Task 4: CI/CD Discipline

Goal: Ensure we don't regress on the audit binding we just finished.

1. Verification: Check scripts/verify_sprint.py. Confirm that TestDetectionEnforcementBinding is present.
2. Action: If it is missing or commented out, restore it. If it exists, add a comment explicitly marking it as "CRITICAL CI/CD COMPONENT - DO NOT REMOVE."

---

Deliverables

1. Code changes for Password Enforcement (Models, API, Frontend).
2. Code changes for Rate Limiting (Middleware/Decorators).
3. New logrotate configuration file.
4. A brief verification_ops.sh script (or instructions) that I can run to prove:
   • Login gets 429 after 6 attempts.
   • New users are redirected to change-password.
   • Logrotate config is valid (dry-run).

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.