Security

Lock your computer

Make sure to always lock your computer if you leave your desk. It is not about having or not having secrets. It is a good practice which easily prevents unwanted access to your computer while you are away. You should not rely on others while away. The computer you are working on is your own responsibility to keep safe and secure.

Every operating system can be configured with hotkeys or other handy shortcuts to lock your computer. For example on Windows you can use the Windows key + L to instantly lock your machine.

Taking data home

If you want to take data home with you, that’s totally fine but make sure it is secure. Apply the following measures.

Firewall

Setup a system firewall. Here’s a practical tutorial.

Full disk encryption

It is mandatory to apply disk encryption.

Here’s a practical tutorial.

Putting code on flash drives etc. is frowned upon. There are probably no valid reasons to take the risk of using flash drives.

Automatic updates

Stay up to date with the latest security updates. Here’s a practical tutorial.

2FA

Most systems within d-centralize enforce 2FA. It’s basically an extra layer of security on top of your first security layer: the password.

There are multiple ways of using 2FA. If you have no preference yet, the easiest way to get started is by installing the Google Authenticator app. This app will generate a code that you fill in after filling in your password. This code is always different, so an attacker stealing your password is now not enough to log in to your account, they would also need access to your smartphone.

Passwords

On sharing secrets

A secret can be a password, a private key, or a set of security Q&A’s for example.

Note

Whenever you’ve got the ability to invite co-workers to a project through another form of authentication, that has preference over sharing a login.

Whenever you create a secret for a project you’re working on, that may be relevant for a co-worker, make sure to enter it in Bitwarden.

Bitwarden

We manage all secrets of companies through Bitwarden, it allows fine-grained access control. Every employee should have received their own invite to the Vaultwarden service.

Note

While the Bitwarden clients are used, the backend is a self-hosted Vaultwarden instance. It’s used in clients as documented in ChangeClient and set to https://vaultwarden.d-centralize.nl

Collections: where credentials go

Secrets are organised by company and sensitivity, so access stays least-privilege. When you create a secret, file it under the right collection:

• <Company> - Tech — non-production engineering secrets: dev/local and review-environment credentials, non-prod API keys, developer tooling. All of that company’s developers (interns included) can see it. No staging or production secrets here.
• <Company> - Prod — staging + production + infrastructure: prod/staging databases and API keys, hosting, DNS, deploy/SSH/Kubernetes keys, monitoring, live payment keys. Restricted to a few trusted engineers per company.
• <Company> - Business — finance, banking, legal/government portals, accounting, marketing/social. For the company’s business/admin people.
• General — shared, low-sensitivity credentials any employee may need.
• Design — shared design-tool accounts (Figma and the like).
• <Company> - Client: <name> — one client engagement’s credentials, visible only to the developers working on that client.

Companies are separate (Appsemble, ITSLanguage, Pro6PP, d-centralize, …); a secret belongs to the company that owns or uses it. Choosing a collection: company first, then sensitivity — non-prod Tech versus production Prod — or Business for non-engineering accounts. Collections control access: don’t use them as labels, and tie a credential to a client via its Client: <name> collection rather than a note.

Access is granted through groups (for example Pro6PP - Tech), not per-person, so a team change is a single membership update. Production access is deliberately limited to trusted engineers.

Browser plugin

It’s recommended to install a browser plugin to help you fill-in passwords for web forms.

Once installed, it’s recommended to configure the following:

Navigate to Settings -> Options -> Default URI Match detection: host.

Desktop app and SSH agent

You can also install an app for that:

curl -fsSL -o /tmp/bitwarden.deb 'https://bitwarden.com/download/?app=desktop&platform=linux&variant=deb'
sudo dpkg -i /tmp/bitwarden.deb
rm /tmp/bitwarden.deb

Use the desktop app for SSH keys. Private SSH keys should be stored as Bitwarden SSH key items, not as private key files in ~/.ssh.

Configure the desktop app:

1. Log in to https://vaultwarden.d-centralize.nl.
2. Enable Settings -> Unlock with biometrics.
3. Enable Settings -> Enable SSH agent.
4. Set Settings -> Ask for authorization when using SSH agent to Always, or Remember until vault is locked.
5. Set the vault timeout to 1 hour and the timeout action to Lock.

Configure the shell to use the Bitwarden SSH agent:

export SSH_AUTH_SOCK="$HOME/.bitwarden-ssh-agent.sock"

Only public key files should be kept in ~/.ssh to help SSH select the right vault-backed key.

CLI

Some scripts use the bw CLI tool to obtain credentials.

sudo snap install bw

A one time configuration is needed:

bw config server https://vaultwarden.d-centralize.nl
bw login
# Sync is needed everytime you need recent credentials
bw sync

Now enter your personal Vaultwarden credentials.

To prevent entering your password only once per shell session, you can persist BW_SESSION by adding the following snippet to your .bashrc.

function bwu() {
    BW_STATUS=$(bw status | jq -r .status)
    case "$BW_STATUS" in
    "unauthenticated")
        echo "Logging into BitWarden"
        export BW_SESSION=$(bw login --raw)
        ;;
    "locked")
        echo "Unlocking Vault"
        export BW_SESSION=$(bw unlock --raw)
        ;;
    "unlocked")
        echo "Vault is unlocked"
        ;;
    *)
        echo "Unknown Login Status: $BW_STATUS"
        return 1
        ;;
    esac
    bw sync
}