In this guide 6 sections
Harden servers in six passes. List who holds root and console logins. Move every login to keys or single sign on with a second factor. Close ports nobody can explain, patch on a set day, keep databases private and ship logs off the box. Name one owner per line.
Start with who can log in as root
Open the cloud console and list every user, every access key and every shared mailbox tied to the account. Most small companies find a former contractor, an old CI token and one login the whole team shares. Remove them first. Do it today.
Then check the root user of the cloud account itself. It should have a hardware key or authenticator app, a mailbox that belongs to a role rather than a person, and no access keys at all. Daily work happens under named users with limited policies.
Do the same on each server. Same rules apply. Disable direct root login over SSH, give each admin a named account and use sudo so the log shows who ran what.
- Cloud root user: second factor, no access keys
- One named IAM or Entra user per admin
- Contractor accounts with an end date
- Break glass login sealed in a password manager vault
- Quarterly review of the user list, owned by the CTO
Keys, passwords and secrets
Password logins over SSH should be switched off in sshd_config. Use key pairs, one per person, stored on a laptop with disk encryption. When someone leaves, deleting their public key from authorized_keys ends their access.
Application secrets are the quiet risk. Database passwords sitting in a .env file inside a Git repository get copied to every laptop. Move them to a secrets manager or at least an encrypted file outside the repository, and rotate any that were ever committed.
Keep a short register of secrets. Note what each opens, where it lives, who rotates it and when. Nothing more.
- PasswordAuthentication set to no
- Separate keys for each person and each automated job
- Secrets manager entry for every database and API credential
- Rotation date recorded next to each secret
Which ports are really open?
Run a port scan against your own public addresses, or read the security group rules line by line. Anything listening that nobody can explain is a finding. Common culprits are a database on 5432 or 3306, a Redis instance, a forgotten admin panel and RDP on a Windows host.
Only ports 80 and 443 should face the internet. Both should end at a load balancer or reverse proxy. Reach SSH through a VPN or a bastion host with an allowed address list.
Write each open port in the checklist with its purpose and owner. A port without an owner gets closed on the next change day.
Patching, networks and logs
Pick a patch day. Stick to it. Apply operating system updates to staging first, then production a few days later, and record kernel and package versions afterwards. Turn on unattended security updates for packages where a surprise reboot is tolerable.
Put databases and internal services in a private subnet. Give them no public address. The web tier talks to them through security groups, not through the open internet.
Send auth logs, sudo history and web server logs to a separate store the server cannot overwrite. If a machine is compromised, the attacker should not be able to wipe the evidence. Set an alert for failed logins and new users.
- Monthly patch day with a named person
- Private subnet for databases and queues
- Auth and sudo logs shipped off the host
- Alert on root login and new key added
Assign owners and review on a schedule
A checklist nobody owns decays fast. Within a quarter it is fiction. Put a name against each line, not a team. For a company without a security team, that is usually the CTO, one senior developer and the person who pays the cloud bill.
Book a review every quarter and after any staff departure. Put it in the calendar. Walk the list top to bottom, tick what holds and write what changed. Attach the previous copy so drift is visible.
Start this week with the first section only. Export the user list, remove what you cannot justify and send the cleaned list to the owner for sign off.
Server access and hardening sheet
Five columns across a single sheet: control, system, current state, owner and next review date. Rows cover cloud root user, named admin accounts, SSH settings, secrets register, open ports, patch day, private subnets and log shipping. A last block records the date of the review and who signed it.
Open a blank worksheet to printQuestions owners ask
How often should we review who has server access?
Every quarter, and the same week anyone leaves or changes role. Compare the cloud user list with the current staff list and remove the difference.
Is a VPN needed to reach SSH?
It is the simpler route for a small team. A bastion host with an allowed address list also works. What matters is that port 22 is not open to the whole internet.
Do we need a security team to do this?
No. These checks need an afternoon and a named owner per line. A security team becomes useful later, for monitoring and incident handling.
Where should logs be kept?
On a separate account or storage bucket that servers can write to but not delete from. That way a compromised host cannot erase its own trail.