Accounts and Access¶

Objective¶

This page offers a shared way to care for the accounts and access paths that sustain Cafh's digital work. It covers systems, vendor portals, official email accounts, social channels, and the member database.

Why this matters¶

Many digital problems begin quietly, in a reused password, an old admin account, or a recovery path that nobody reviewed. In a volunteer organization, small gaps in account care can grow into larger risks. Thoughtful access rules protect continuity, trust, and the ability to recover. They also protect the website, member area, cloud services, email, and social channels that support daily work.

Risks this page helps reduce¶

• Account takeover
• Loss of admin control
• Active access for former volunteers or former vendors
• Broken recovery after a login problem
• Misuse of official channels
• Service outage tied to one person

Core rules¶

These rules set the minimum line that no volunteer, vendor, or admin should cross. They keep legal ownership, daily control, and recovery power with Cafh. That foundation matters most during role change, vendor exit, or account recovery.

• Cafh must own critical accounts.
• Personal accounts must not own critical services.
• Every critical service must use multi-factor authentication.
• Shared credentials must live in the Cafh password manager.

Critical services¶

A critical service is not defined by price or technical complexity alone. It is critical if it carries trust, identity, continuity, or recovery for the rest of the environment. In Cafh, even a small service may be critical if it controls the next link in the chain.

A service is critical when loss, outage, or misuse can:

• Take down the public site or member area
• Lock Cafh out of a main account
• Expose member data or internal records
• Break account recovery for other systems
• Interrupt renewals, billing, or security alerts
• Damage the public image of Cafh

Critical services include:

• DigitalOcean
• Domain registrar accounts
• DNS and SSL services
• Website admin accounts
• Member database systems
• Official email accounts and shared mailboxes
• Social media admin accounts
• Password manager admin accounts
• Backup, monitoring, and alerting services

Why Cafh must control the main accounts¶

The main accounts must stay in Cafh's hands. They must be opened in Cafh's name and tied to Cafh-controlled email addresses. Cafh must keep at least two trusted admins and one current recovery path. Vendors may receive delegated access for defined work. They must not be the legal, billing, or technical owner of the core accounts.

This rule matters most for:

• Domain registrar accounts
• DNS hosting accounts
• Official email administration
• Certificate management
• Cloud root or billing accounts
• Password manager admin accounts

If a third party owns those accounts, Cafh can lose the right to change DNS, renew the domain, recover email, renew certificates, read billing notices, or remove a former vendor. That risk affects continuity, security, and the public image of the organization.

Domain, email, and certificate dependency map¶

This diagram shows why one account can affect many other services.

flowchart TD
  A["Registrar account"] --> B["DNS control"]
  B --> C["Public website"]
  B --> D["Official email delivery"]
  B --> E["Domain verification records"]
  D --> F["Password resets and security alerts"]
  F --> G["Cloud, social, and vendor accounts"]
  B --> H["Certificate issue and renewal"]

Why domain and DNS control are high risk¶

The registrar account controls renewal, transfer, and nameserver settings. DNS control decides where the website, email, and many verification records point. One bad change can take the site offline, stop email, or send users to a hostile service.

If an attacker or a former vendor controls the registrar or DNS account, they may:

• Move nameservers
• Change website destination records
• Change email routing
• Break SPF, DKIM, or DMARC records
• Block domain renewal
• Transfer the domain away from Cafh

That is why the registrar and DNS accounts need strong MFA, current recovery data, transfer lock where available, and regular review by Cafh.

Why email administration is a root function¶

Official email is not only a communication tool. It is part of the control plane for the whole organization. Many services send password resets, security alerts, invoices, user invites, and certificate notices to official email.

If Cafh loses control of the main email administration account or key shared mailboxes, it may lose the ability to recover:

• Cloud and hosting accounts
• Domain and DNS accounts
• Social media accounts
• Vendor portals
• Billing and renewal notices

That is why Cafh must directly control the primary mail tenant, admin mailboxes, and recovery inboxes.

Why certificates need direct oversight¶

Certificates protect encrypted access to the website and member services. Expired certificates trigger browser warnings and can stop trust at once. Broken renewal can cause outages without any system change on the website itself.

Certificate control needs clear ownership for:

• Who issues the certificate
• Where renewal runs
• Which domain names it covers
• Which mailbox gets expiry alerts
• Who can replace or revoke it

If DNS is changed by an attacker, that attacker may even support a false site with a valid certificate. That risk makes domain, DNS, and certificate control part of one chain.

Tracked accounts¶

The record matters as much as the password. Many organizations lose control through missing names, unclear owners, or stale recovery data. A current register lets the committee see who can act, who can recover, and who must be removed.

The committee must keep a current record for:

• Official email accounts
• Shared mailboxes
• Social media admin accounts
• Social media publishing accounts
• Recovery email accounts
• Recovery phone numbers linked to critical services

Each record must show:

• Account name
• Purpose
• Owner
• Current admins
• Platform
• Linked recovery path
• Multi-factor status
• Last review date

Sample critical service register¶

Use one row for each high-impact service or admin account.

Sample domain and email control register¶

Use this table to track the full chain from domain control to email delivery.

Sample certificate register¶

Use this table to track website certificates and renewal paths.

Password manager¶

The password manager is the operational memory of shared access. Without it, work drifts into private notebooks, chats, and personal browsers. That creates silent risk and makes offboarding harder.

• Use one organization-owned password manager.
• Store shared credentials, recovery codes, and service notes there.
• Keep at least two committee members with admin rights.
• Review vault access every 3 months.

Rotation rules¶

Rotation is not a ritual. It cuts old access paths and limits the life of exposed credentials. Cafh should keep a calm schedule, then move faster after change or suspicion.

• Rotate critical passwords every 12 months.
• Rotate passwords at once after a role change.
• Rotate passwords at once after vendor change.
• Rotate passwords at once after any suspected exposure.
• Rotate keys and tokens on the same rule.

DigitalOcean access¶

DigitalOcean access deserves special care. A few accounts can change servers, networking, snapshots, billing, and recovery. That power should stay with a very small named group inside Cafh.

• Keep the number of direct DigitalOcean admins small.
• Name each admin in the committee records.
• Review DigitalOcean access every 3 months.
• Use separate named accounts for each person.

Offboarding¶

Offboarding must be fast and recorded. Delay leaves old paths open and creates confusion about who still represents Cafh. This checklist should start on the same day a role ends.

• Remove service access
• Remove official email access
• Rotate shared credentials
• Remove password manager access
• Remove social media admin access
• Record the date and owner of the change