Authentication, Access and Accounts
Last updated
Was this helpful?
Last updated
Was this helpful?
Usernames and passwords should be randomly generated
Username must not be 'Administrator', 'root', 'Admin' etc unless the application forces it
Where possible, OpenID should be
Enable AutoLogon where possible
For services behind CloudFlare authentication, local auth can be disabled
Where possible,
If a server has public facing SSH (such as a VPS), use SSH keys and disable password sign in
Usernames, passwords, TOPT and backup codes to be saved in our
Internal services (eg docker containers) are to be saved in the 'Internal Services' folder, whilst external services (eg Cloudflare login, Namecheap login) are saved in the 'External Services' folder.
Credentials to be tested and confirmed working, then saved in Bitwarden before deletion
This is to ensure that accounts are hard to breach and are backed up and stored appropriately. Bitwarden has a function to notify admins of any credential breaches.
Accounts required for integrations between systems (eg Home Assistant monitoring UniFi) must first be created as read-only
Administrator access to be granted as last ditch
Do NOT create new accounts as administrators
Log in with new account and test before granting additional access
Research app online to figure out what access is required if more is required
Administrator access can be granted ONLY IF required
This is to ensure that if accounts are breached, they can't do much damage
I have 4 primary authentication policies configured in Cloudflare. We mostly use the 'Allow' and 'Bypass' rule
Explanation
User authentication. Allows access. Can be limited to country
User authentication. Allows access by requires a reason. Can be limited to country
User authentication. Allows access by requires approval from a second user. Can be limited to country
Bypasses authentication prompt. Must be applied to IP addresses, subnets or countries
Example
I need to send a WOL packet to a server
A server is off and I'm unable to send the WOL packet. This allows a second person to do that work though it is not normally within scope of their duties.
A server is off and I'm unable to send the WOL packet. This allows a second, non-technical person, to request access, be approved by myself or someone else and process this.
Allow everyone in Australia to have access to service A, but accessing outside of Australia follows one of the above rules instead
Documentation
None
Written for a technical person
Written for a non-technical person
None
If a public facing service has a login page that shouldn't be publicly accessible, you can put the authentication in front of the URL for the login page. Eg, myapp.mydomain.com/login
This enables a consistent approach and easy to understand workflow.