A service account is a user account created for the sole purpose of running an application. For example, an online banking web site may have a single service account under which the code runs.
Service accounts, like any other accounts, have passwords. They differ from end user accounts' passwords in two important ways:
- The passwords are generated by us (and they are big and random)
- The passwords are stored by Windows so that it can start the services when needed without human interaction.
I am trying to figure out what sort of password management process we need to stand up around these accounts.
PCI-DSS guidance sets the following general guidance for passwords:
- Assign all users a unique ID before allowing them to access system components or cardholder data.
- Control addition, deletion, and modification of user IDs, credentials, and other identifier objects.
- Immediately revoke access for any terminated users.
- Remove/disable inactive user accounts within 90 days.
- Limit repeated access attempts by locking out the user ID after not more than six attempts.
- Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID.
- If a session has been idle for more than 15 minutes, require the user to reauthenticate to re-activate the terminal or session.
- Change user passwords/passphrases at least once every 90 days
But some of these rules do not make any sense for a service account. For example, maybe it doesn't make sense to enforce lockout. And it could be a real pain in the neck to change the password every 90 days, if the same identity is used for a series of microservices, for example.
Do any of these rules apply to service accounts, or only to end user accounts? If the rules are just for end user accounts, what rules exist (if any) for service accounts?
(By "apply" I mean "are considered during a PCI audit")