Segmentation, Hardening & Operations

1👤 Service Accounts & Linux-AD Integration

Create service accounts — svc_sql_app, svc_backup, svc_web, svc_splunk — and understand why they exist: non-interactive accounts, password management, least privilege, password rotation, managed identities, and managed service accounts. Legacy organisations often have manually-managed service accounts with passwords that haven't changed in years; modern organisations increasingly prefer managed identity approaches where supported. You need to understand both realities, not just the tidy one.

As an advanced exercise, join LINUX01 to Active Directory — this introduces SSSD, Kerberos, LDAP, DNS and PAM working together, and lets you log into Linux as an AD user (e.g. alice@CORP.CYBERSECURITYCAFE.LAB). It's a small exercise that demonstrates something real companies deal with constantly: how heterogeneous Windows/Linux environments actually integrate.

2🌐 Building a DMZ, Reverse Proxy & Load Balancing

Create a new network, 10.10.40.0/24, as a DMZ, and place a web server inside it (WEB01 at 10.10.40.10). Firewall rules might allow Internet → WEB01 on TCP 443, but block Internet → Domain Controller entirely, and severely restrict WEB01 → internal network. Now it's obvious why internet-facing applications shouldn't simply sit beside Domain Controllers and databases.

Deploy Nginx as a reverse proxy (User → HTTPS → Nginx → Application) and learn frontend, backend, reverse proxy, TLS termination, headers, and load balancing as concepts, not just words. Add a second web server (WEB01, WEB02) behind the proxy, then shut down WEB01 and confirm requests still reach WEB02 — a small, concrete taste of resilience testing.

3⚖️ Legacy Technology, Hybrid Environments & Identity Sync

Real companies rarely run only the latest technology. Set aside a controlled section of the lab for older tech — Windows Server 2016, older Linux distributions, NTLM-based authentication, older SMB configurations, older application frameworks, older database versions. The goal isn't to normalise insecure legacy technology; it's to understand why companies struggle to remove it: application dependencies, unsupported vendor software, regulatory testing requirements, database compatibility, old hardware, business risk, migration cost, and 24/7 availability requirements. There's a real difference between "this technology is old" and "this technology can safely be removed" — the second claim requires actual investigation.

Add cloud services to see a modern hybrid organisation take shape: on-premises Active Directory, Windows and Linux servers and databases, connected to Microsoft Entra ID, Microsoft 365, Azure, and Sentinel in the cloud. Understand directory synchronisation, federation, SSO, MFA, and Conditional Access at the architecture level — a full production-style hybrid identity deployment isn't necessary for every student, but understanding the shape of it is genuinely valuable.

4🔌 API & Authentication Labs

Deploy a simple API inside Docker (e.g. GET /api/users) and call it with curl, PowerShell, or Postman — Client → HTTPS → API → Database. This connects Module 13's API concepts to something you actually built and can poke at.

Add authentication to the application and trace the flow: User → Login → Authentication System → Token → Application. Inspect the JWT, the Authorization header, the bearer token, expiration, and claims — this connects directly into IAM and modern application security, and it's a lot easier to reason about a token you generated yourself than one described in a diagram.

5📊 Monitoring, Backup & Snapshots

Monitoring shouldn't stop at security events — also watch CPU, memory, disk, network, service status, and application health. Simulate a disk filling up, a service stopping, CPU climbing, or an application becoming unavailable, then investigate each. This is the distinction between security monitoring and operational monitoring — both matter, and they're not the same job.

Back up important systems — databases, configuration, VMs, files — but a backup is only half the process. Test restoration: create a database, insert records, take a backup, delete the database, restore it, verify the records are back. A backup that has never been tested is not yet evidence of recoverability.

Use VM snapshots liberally before major configuration changes, security testing, software upgrades, patch testing, or vulnerability exercises (Clean Install → Domain Joined → Application Installed → Before Upgrade is a useful chain) — snapshots are what let you break things confidently in Lesson 6.

6🔧 Patch & Change Management

Apply OS updates and record before-version, patch installed, reboot required, and after-version, plus what testing you performed. Real enterprise patching involves more than clicking "Install Updates" — change request, maintenance window, backup, pre-checks, implementation, validation, rollback plan, and post-change monitoring.

Practice this with a mock change request — e.g. CHG000123, "Upgrade SQL Server," Environment: LAB, Planned Date: Saturday 22:00, Risk: Medium — including purpose, impact, pre-checks, implementation steps, validation, rollback, and stakeholders (Module 18, Lesson 5 covers this exact document type in production terms). This is what makes the lab feel like enterprise IT operations rather than a personal project.

7🛡️ Hardening the Environment

Once the environment works, secure it: disable unnecessary services, restrict firewall rules, use strong authentication, remove unused accounts, configure auditing, protect administrative accounts, apply patches, use HTTPS everywhere, separate users from administrators, limit database permissions, protect SSH keys, and review logs. Compare the environment before and after hardening — the difference should be visible, not just claimed.

Separate a normal user (alice) from a privileged account (alice-admin), used only when administration is actually necessary — this is why large enterprises commonly split standard identity, privileged identity, and service identity, and it's directly relevant to IAM and PAM. Practice least privilege concretely: start from Everyone → Full Control and replace it with proper groups (GG-Finance-Read, GG-Finance-Modify, GG-Finance-Admins).

Build a firewall matrix instead of guessing at rules:

Never blindly open ANY→ANY. Place the database in its own dedicated network so users can't reach it directly just because everything happens to sit on the same flat network (Users → Web/Application → Firewall → Database) — this is defence in depth. Finally, check time synchronisation: create two systems with significantly different clocks and compare their logs side by side. Time matters for Kerberos, certificates, logs, SIEM correlation, database transactions, and incident investigations — you'll understand exactly why accurate timestamps are critical once you've tried to correlate two logs that disagree about what time it is.