jperezduerto.info
Security in depth · Unit 22 · Lesson 9 of 44
Give services their own identity
Check whether separate service identities actually have separate data access.
Helpful before thisLinux privilege escalation
After this lesson you can
- Recognize a shared group grant that preserves excessive access after an identity split.
One idea. One situation. One reasoned decision.
How it works
A dedicated service identity makes it possible to assign permissions by purpose. It does not automatically create that separation. Processes with different user IDs can retain the same sensitive access through shared groups, ACLs, or application permissions.
Read the supplied record
A1 is a fictional proposal replacing one shared account with two service accounts.
| Service | New identity | Owner-approved input |
|---|---|---|
| Invoice summary | invoice-worker | Read invoices only |
| Donation summary | donation-worker | Read donations only |
Both new identities remain members of finance-data. The supplied permission review confirms that this group grants read on both datasets. Neither service needs to modify source records; each has a separate approved output area.
Assume ordinary non-root processes, current group memberships, searchable paths, and no additional rule that blocks these documented reads. Different process names and user IDs therefore do not satisfy the intended data separation.
Propose separate, purpose-scoped read grants, with the data owner confirming each dataset’s audience. Review the shared group before removal so any legitimate dependency receives an explicit replacement. Keep the necessary output permissions separate from source-data permissions.
Acceptance needs both directions: invoice-worker can read invoices but cannot read synthetic donation records; donation-worker can read donations but cannot read synthetic invoices. Confirm that each still produces its approved summary.
The evidence supports a permission-design mismatch, not proof that either worker read the wrong data. Local identities also do not establish which remote service credentials an application uses; that is a separate review item.
The key distinction: Separate names help only when the effective permissions are separated too.
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
Does A1’s proposed identity split meet the approved data-access boundary?
Show the answer
Correct answer: Not yet: both identities still receive read access to both datasets through finance-data. Different user IDs do not cancel the documented shared group grant. Its effective resource scope must also match each approved purpose.
Try it
- WriteWrite the allowed and denied data reads for each service in A1. Identify the shared grant that prevents the proposal from meeting those outcomes, and assign an owner to review it.