Authentication, Access and Accounts
Management of accounts
Creating Accounts
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 configured using the AGG / XFGN OAuth Client
Enable AutoLogon where possible
For services behind CloudFlare authentication, local auth can be disabled
Where possible, use SSH keys
If a server has public facing SSH (such as a VPS), use SSH keys and disable password sign in
Storage of account details
Usernames, passwords, TOPT and backup codes to be saved in our Password Vault
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.
Deletion of Accounts
Credentials to be tested and confirmed working, then saved in Bitwarden before deletion
Why?
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.
User Permissions
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
Why?
This is to ensure that if accounts are breached, they can't do much damage
Cloudflare Authentication
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
Authentication in front of Logon pages
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
Why?
This enables a consistent approach and easy to understand workflow.
Last updated