Data breaches continue to be one of the most costly security incidents for organizations running cloud infrastructure. The majority of breaches stem from preventable misconfigurations, weak access controls, unpatched systems, and inadequate monitoring. This checklist walks hosting and cloud teams through the specific hardening steps that address the most common breach vectors.
Understanding Common Breach Vectors
Before diving into prevention measures, understand where attackers typically gain entry:
- Compromised credentials: Stolen or weak passwords, exposed API keys, and leaked access tokens remain the leading cause of unauthorized access
- Unpatched vulnerabilities: Systems running outdated software with known security flaws
- Misconfigured storage: Publicly accessible S3 buckets, database instances without authentication, and open file shares
- Insider threats: Excessive permissions granted to users, contractors, or automated systems
- Supply chain attacks: Compromised dependencies, malicious packages, or vulnerable third-party integrations
- Inadequate network segmentation: Flat networks where a single compromised system provides access to sensitive data
Identity and Access Management
Enforce Strong Authentication
Weak authentication is the easiest path for attackers. Implement these controls immediately:
Enable multi-factor authentication on all administrative accounts. For SSH access, use key-based authentication and disable password login:
# Edit SSH daemon config
sudo nano /etc/ssh/sshd_config
# Set these directives
PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes
# Restart SSH service
sudo systemctl restart sshd
Implement password policies that require minimum length, complexity, and regular rotation for service accounts. Use a password manager for team credential storage rather than shared documents or chat messages.
Deploy API key rotation schedules. Treat API keys with the same sensitivity as passwords:
# Example: Rotate AWS access keys
aws iam create-access-key --user-name service-account
aws iam delete-access-key --user-name service-account --access-key-id OLD_KEY_ID
Apply Principle of Least Privilege
Every account should have only the minimum permissions required to perform its function.
Audit existing permissions quarterly. List all users, service accounts, and their current access levels:
# Linux: Review sudo privileges
sudo cat /etc/sudoers
sudo ls -la /etc/sudoers.d/
# Check user groups
getent group sudo
getent group wheel
Remove unused accounts immediately. Departing team members, decommissioned services, and old test accounts are all potential entry points:
# Disable a user account
sudo usermod -L username
sudo usermod --expiredate 1 username
# List accounts that haven't logged in recently
sudo lastlog | grep "Never"
Implement role-based access control (RBAC) rather than granting individual permissions. Create roles like "developer," "operator," and "auditor" with predefined permission sets.
Secure Service Accounts
Automated processes often run with excessive privileges.
Create dedicated service accounts for each application or service. Never run production services as root:
# Create a restricted service account
sudo useradd -r -s /bin/false -d /var/lib/myapp myapp-service
# Set ownership for application files
sudo chown -R myapp-service:myapp-service /var/lib/myapp
Restrict service account capabilities using Linux capabilities instead of full root access:
# Grant only the capability to bind to privileged ports
sudo setcap 'cap_net_bind_service=+ep' /usr/bin/myapp
Data Encryption
Encrypt Data at Rest
Unencrypted storage is a compliance violation waiting to happen.
Enable full-disk encryption on all servers using LUKS:
# Check if encryption is active
lsblk -f
# Encrypt a new volume
sudo cryptsetup luksFormat /dev/sdX
sudo cryptsetup luksOpen /dev/sdX encrypted-volume
Encrypt database files using built-in encryption features. Most modern database systems support transparent data encryption (TDE) or encrypted tablespaces.
Encrypt backup files before storing them. Use GPG for file-level encryption:
# Encrypt a backup file
gpg --symmetric --cipher-algo AES256 backup-2025-07-04.tar.gz
# Decrypt when needed
gpg --decrypt backup-2025-07-04.tar.gz.gpg > backup-2025-07-04.tar.gz
Encrypt Data in Transit
Enforce TLS 1.2 or higher for all network communications. Disable older protocols in your web server configuration:
# Nginx SSL configuration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
ssl_prefer_server_ciphers on;
Use VPNs or SSH tunnels for administrative access. Never expose database ports directly to the internet:
# Create an SSH tunnel to access remote MySQL
ssh -L 3306:localhost:3306 user@remote-server
# Now connect to localhost:3306 locally
mysql -h 127.0.0.1 -P 3306 -u dbuser -p
Implement mutual TLS (mTLS) for service-to-service communication in microservices architectures.
Network Security
Configure Firewalls Properly
Default deny all traffic and explicitly allow only required ports:
# UFW (Ubuntu/Debian)
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp # SSH
sudo ufw allow 443/tcp # HTTPS
sudo ufw enable
# Firewalld (RHEL/CentOS)
sudo firewall-cmd --set-default-zone=drop
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
Restrict SSH access to specific IP ranges:
# UFW: Allow SSH only from office network
sudo ufw allow from 203.0.113.0/24 to any port 22
Implement Network Segmentation
Separate environments (production, staging, development) into different network segments or VPCs. A compromised development server should not have access to production data.
Create security zones based on data sensitivity: - Public zone: Web servers, load balancers - Application zone: Application servers - Data zone: Databases, file storage - Management zone: Bastion hosts, monitoring systems
Use jump servers (bastion hosts) as the only entry point into private networks:
# SSH through bastion to reach internal server
ssh -J [email protected] app-user@internal-server
System Hardening
Keep Systems Patched
Enable automatic security updates on all systems:
# Ubuntu/Debian: Install unattended-upgrades
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# RHEL/CentOS: Enable automatic updates
sudo yum install yum-cron
sudo systemctl enable --now yum-cron
Create a patch management schedule: - Critical security patches: Apply within 24-48 hours - Important updates: Apply within one week - Regular updates: Apply monthly during maintenance windows
Test patches in non-production environments first, but do not delay critical security fixes.
Disable Unnecessary Services
Audit running services and disable anything not required:
# List all running services
systemctl list-units --type=service --state=running
# Disable an unnecessary service
sudo systemctl stop service-name
sudo systemctl disable service-name
Remove unused packages to reduce attack surface:
# Debian/Ubuntu
sudo apt autoremove
sudo apt purge package-name
# RHEL/CentOS
sudo yum autoremove
sudo yum remove package-name
Harden File Permissions
Secure sensitive configuration files:
# Make config files readable only by owner
sudo chmod 600 /etc/myapp/config.yml
sudo chmod 600 ~/.ssh/id_rsa
# Secure database credential files
sudo chmod 600 /etc/mysql/debian.cnf
Implement file integrity monitoring to detect unauthorized changes:
# Install and configure AIDE
sudo apt install aide
sudo aideinit
# Create baseline
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db
# Run daily checks
sudo aide --check
Logging and Monitoring
Centralize Log Collection
Ship logs to a central location that attackers cannot easily tamper with. Use syslog forwarding:
# Configure rsyslog to forward to remote server
sudo nano /etc/rsyslog.d/50-remote.conf
# Add this line
*.* @@logserver.example.com:514
# Restart rsyslog
sudo systemctl restart rsyslog
Retain logs for an adequate period. Many compliance frameworks require 90 days minimum; consider one year for critical systems.
Monitor for Anomalies
Set up alerts for suspicious activity: - Multiple failed login attempts - Privilege escalation events - Off-hours administrative access - Unusual data transfer volumes - New user account creation - Firewall rule changes
Monitor file access patterns:
# Install and configure auditd
sudo apt install auditd
# Watch sensitive directories
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
sudo auditctl -w /etc/shadow -p wa -k shadow_changes
# View audit logs
sudo ausearch -k passwd_changes
Review logs regularly. Automated alerting is essential, but manual log reviews often catch subtle anomalies.
Backup and Recovery
Implement the 3-2-1 Rule
Maintain three copies of critical data on two different media types with one copy offsite.
Automate backups:
#!/bin/bash
# Simple backup script example
BACKUP_DIR="/backup/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"
# Database backup
mysqldump -u backup -p"$DB_PASSWORD" --all-databases > "$BACKUP_DIR/databases.sql"
# Application files
tar -czf "$BACKUP_DIR/app-files.tar.gz" /var/www/html
# Encrypt and upload to remote storage
gpg --encrypt --recipient [email protected] "$BACKUP_DIR/databases.sql"
rclone copy "$BACKUP_DIR" remote:backups/
Test restore procedures quarterly. Backups are useless if you cannot restore from them quickly.
Protect Backups
Encrypt all backups before storage. Use different encryption keys for backups than for production systems.
Store backups offline or in immutable storage to protect against ransomware. Some cloud providers offer object lock features that prevent deletion for a specified retention period.
Restrict backup access to dedicated backup accounts with read-only access to production systems.
Application Security
Secure Dependencies
Audit third-party packages for known vulnerabilities:
# Node.js
npm audit
npm audit fix
# Python
pip install safety
safety check
# Ruby
gem install bundler-audit
bundle audit
Pin dependency versions in production and review updates before deploying them.
Use private package repositories for internal code rather than relying solely on public registries.
Input Validation and Sanitization
Validate all user input at application boundaries. Never trust data from users, APIs, or databases.
Use parameterized queries to prevent SQL injection:
# BAD - vulnerable to SQL injection
cursor.execute(f"SELECT * FROM users WHERE username = '{username}'")
# GOOD - parameterized query
cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
Implement rate limiting to prevent brute force attacks and denial-of-service attempts.
Incident Response Planning
Prepare Before Incidents Occur
Document your response procedure: 1. Detection and identification 2. Containment (isolate affected systems) 3. Eradication (remove the threat) 4. Recovery (restore normal operations) 5. Lessons learned (post-incident review)
Maintain an incident response team with clearly defined roles. Ensure team members have emergency contact information and access credentials stored securely.
Conduct tabletop exercises to practice response procedures. Simulate scenarios like ransomware, data exfiltration, or compromised administrator accounts.
Create Evidence Preservation Procedures
Know how to capture forensic images:
# Create a disk image for forensic analysis
sudo dd if=/dev/sda of=/mnt/external/forensic-image.dd bs=4M status=progress
# Calculate hash for integrity verification
sudo sha256sum /mnt/external/forensic-image.dd > /mnt/external/forensic-image.dd.sha256
Preserve logs immediately when an incident is detected. Copy logs to immutable storage before attackers can alter them.
Compliance and Auditing
Regular Security Audits
Conduct internal audits monthly. Review user accounts, firewall rules, patch status, and access logs.
Perform external penetration testing annually or after significant infrastructure changes.
Run vulnerability scans weekly using tools like OpenVAS, Nessus, or cloud-provider scanning services.
Documentation
Maintain current architecture diagrams showing network topology, data flows, and trust boundaries.
Document security configurations and the rationale behind them. Future administrators need to understand why certain restrictions exist.
Keep a change log of all security-related configuration changes with dates, who made the change, and why.
Conclusion
Data breach prevention requires defense in depth: multiple layers of security controls that work together to protect your infrastructure. No single measure will stop all attacks, but implementing these hardening steps systematically reduces your attack surface and makes breaches significantly more difficult.
Start with the highest-impact items: enable MFA, patch critical vulnerabilities, encrypt sensitive data, and set up centralized logging. Build from there by working through each section of this checklist, adapting the specific commands and configurations to your environment.
Security is not a one-time project but an ongoing process. Schedule regular audits, stay informed about emerging threats, and continuously improve your defenses. The effort you invest in prevention today is far less costly than responding to a breach tomorrow.