Mainīt koplietotās paroles un atslēgas

Kad izmantot

The scheduled quarterly rotation of credentials that more than one person can use. Not for a suspected compromise — that is an emergency, use tech.phishing-report (if it arrived by mail) or tech.lost-device (if a device with saved credentials is gone), and rotate the affected credential immediately, off-cycle. Not for individual staff passwords — those follow people.onboard-employee and people.offboard-employee.

Pirms sāc

• The vault is reachable and its history works; if the vault itself is down, stop and fix that first.
• Nobody is mid-onboarding or mid-offboarding in a way that a rotation would break.
• The owner has been told the run is starting (a scheduled run, but S3 still needs a named approval).

Ko izpilde pieprasa3

Ceļš8 soļi

1. S1

   Inventoryaģents

   List every shared credential in the vault: name, what it opens, last rotation date, who used it in the last 90 days. Walk the integrations list (hosting, payment, mail, analytics, backup) and add anything used that is not in the vault.

   Izdarīts, kad the inventory table covers every credential with a last-rotation date or "never".

2. S2

   Rank and planaģents

   Mark each row: rotate now / rotate with owner approval / exempt (per-person credential, hardware key, or a provider that forbids routine rotation — note why). Order the "rotate now" rows so that customer-facing integrations go last, after their replacement is tested.

   Izdarīts, kad every row has a decision and a reason.

3. S3

   Approve the scopeīpašnieksvajag apstiprinājumu · īpašnieks

   Apstiprinājums · S3 · īpašnieks — izpilde apstājas, līdz nosaukts cilvēks ieraksta lēmumu

   Present the plan: what rotates, what is exempt and why, which live integrations will be touched, and the order.

   Izdarīts, kad the owner has approved the list, in writing (a message or a task comment is enough).

4. S4

   Rotate passwordsaģentsneatgriezenisks

   Neatgriezenisks solis · S4 — aģents to nekad nenoslēdz viens

   For each approved password: generate a new one in the vault, change it at the service from the company's own session (not a personal browser profile), write the new secret back to the vault immediately, and log out other sessions where the service offers it.

   Izdarīts, kad the vault shows the new secret and the change date for every password on the approved list.

   ⛔ Never change the password at the service before the vault entry is ready to receive the new one — a password that exists only in your clipboard is a lockout waiting to happen.

5. S5

   Rotate keys and tokensaģentsneatgriezenisks

   Neatgriezenisks solis · S5 — aģents to nekad nenoslēdz viens

   For each approved API key or token: create the new key at the provider, switch the integration to it, confirm the integration works, then revoke the old key.

   Izdarīts, kad the old key returns "unauthorized" and the integration works on the new one.

   ⛔ Create-then-revoke, never revoke-then-create — a revoked key with no replacement takes the webshop or backups down until a human notices.

6. S6

   Sweep for straysaģents

   Search shared inboxes, chat history and the shared drive for the old passwords (the vault name of each credential, plus the domain where sensible: bc mail search). Delete or archive what is found and note where it was.

   Izdarīts, kad the search is run for every rotated credential and every hit is cleaned or listed.

7. S7

   Verify accessaģents

   For each rotated credential, sign in or call the integration once and confirm it works; for shared mailboxes, confirm from a second person's session too.

   Izdarīts, kad every rotated credential has a successful access check by someone other than the person who rotated it.

8. S8

   Record and reportaģents

   Add the next quarterly task (bc tasks add), and send the owner a report: rotated / exempt / failed, with the vault history as evidence.

   Izdarīts, kad the next quarter's task exists with a due date and the report is sent.

Pārbaudes — kā zinām, ka izdevās

• Vault history shows a change entry for every credential on the approved list, dated this run.
• The old password and old keys are dead: an attempt with them fails (checked for at least one per system).
• Every rotated credential was successfully used after rotation, by a person other than the rotator.
• A search for old secrets in mail and drive returns nothing new after S6.

Ja noiet greizi

Ko atstāj katrs solis

1. S1the inventory table covers every credential with a last-rotation date or "never".
2. S2every row has a decision and a reason.
3. S3the owner has approved the list, in writing (a message or a task comment is enough).
4. S4the vault shows the new secret and the change date for every password on the approved list.
5. S5the old key returns "unauthorized" and the integration works on the new one.
6. S6the search is run for every rotated credential and every hit is cleaned or listed.
7. S7every rotated credential has a successful access check by someone other than the person who rotated it.
8. S8the next quarter's task exists with a due date and the report is sent.

Ko saglabāt

The inventory table from S1 · the owner's approval in S3 (who, when, what scope) · vault history entries · the old-key "unauthorized" proof for each token · S7 access checks with who checked · the S8 report.

Kā šī procedūra uzlabojas

After every 4 runs ask: how many credentials were found outside the vault, and where did they leak from? Did any integration break, and was it in the "customer-facing goes last" group or did the ordering fail? How long did the longest single rotation take, and is it a candidate for the exempt list? A new version changes the step that caused the leak, the break, or the wait, and says so in its change note.