0

I am getting a presentation together for a topic I am not SUPER knowledgeable in.

I am an admin within a nameless system, and of the opinion that a service account should be created for each individual integration(rather than sharing an integration account across multiple integration points).

Let's say, for example, certain data is getting updated by an integration account. I would be able to tell exactly which integration is causing the unintended update.

Am I correct in having the unique service account per integration stance? In my mind, this boils down to PAM, and properly managing privileged accounts.

There is some reference in NIST 800-53 AC-2 Account Management, I was just hoping someone could provide some real world practice.

Jeroen
  • 5,783
  • 2
  • 18
  • 26
TestMcTesterson
  • 103
  • 2
  • At the person that wanted to close this topic with the reason that it is primarily opinion based: This is not an opinion, this is considered part of a larger standard. – Jeroen Sep 04 '19 at 21:23
  • @Jeroen I'm not the flagger, but I agree with the flag. "Should I" is inherently a matter of weighing one's own cost/benefit ratio. The fact that there may or may not be a standard doesn't really have anything to do with it - a standard is not a legally binding document, and whether or not someone should follow a standard is in-and-of-itself matter of opinion. – Conor Mancone Sep 04 '19 at 21:43
  • Principle of least privilege should be applied all the time, I think your thinking so far works well – LTPCGO Sep 04 '19 at 21:54
  • @ConorMancone I see your point! – Jeroen Sep 04 '19 at 22:04

3 Answers3

1

Am I correct in having the unique service account per integration stance?

This is something I always recommend doing because you can set permissions per account. The least privilege principle should always be applied.

As you mentioned yourself, it is easier to perform audits when having separated accounts.

Additionally, service account should not be able to be used in order to login to a system and either get a shell or remote desktop connection (depending on the environment).

Jeroen
  • 5,783
  • 2
  • 18
  • 26
1

You would not necessarily be wrong to assign 1-to-1 Service Account to Service, to answer your question. Properly managed accounts in indeed to the key.

I took the below Service Account definition direct from Microsoft and should frame things a little better. Service accounts allow the creator to dictate the security context, and thus whatever security controls would apply to that security context normally, should also apply to the Service Account in question. They are considered a type of privileged account in the CISSP CBK along with Root/Built-In Admins, Administrator Accounts, and Power Users1; and principle of least privilege and need to know would apply.

"A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service's ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.2"

An example of an application that uses multiple Service Accounts is Oracle.3

1 CISSP CBK 4th Ed. - pg 818

2 https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts

3 https://docs.oracle.com/cd/B28359_01/server.111/b28337/tdpsg_user_accounts.htm#TDPSG20030

Justin
  • 702
  • 5
  • 9
0

There is no correct answer. In fact, in matters of security there is rarely only one answer. The level of security needed for a service where you anonymously vote on cat pictures is completely different than the service that you use to order a nuclear site. You use case likely falls somewhere in the middle.

Creating one service account per integration has clear benefits that you have already mentioned. It also has costs - it takes a bit more effort to create and manage more service accounts, and you might want to work on clear "procedures" for creating service accounts and updating your application (since this is a time period when they are more "vulnerable" to theft). Only your team can decide if the benefits outweigh the increased costs.

Personally, I think that having a separate service account for each Integration is the best way to go, and that is how I do it. However, that doesn't make it the correct choice for your team.

Conor Mancone
  • 29,899
  • 13
  • 91
  • 96
  • 1
    Whilst your argument about cost-benefit makes sense for some cases, certain things come at a bare minimum. You wouldn't run every program as root just because it makes things a little easier, things like 2fa are relatively simple to implement, and you should hash passwords. Running separate service accounts is I think one of those things that's so important it should be used all the time, and should always be the default correct choice. The cat example may start trivial, but if the system eventually evolves to a full cat social site having the right mindset from the outset makes life easier – LTPCGO Sep 04 '19 at 21:58
  • @LTPCGO generally true, but still not 100% correct. Given the number of people who come here asking "Is this secure?" I think it is always worth stopping to explain that "secure" is not an absolute thing. In this case in particular it isn't a simple yes/no answer. – Conor Mancone Sep 04 '19 at 22:25
  • 1
    For instance, many companies would put credentials like this in source code, despite the fact that employees are generally the most likely to be responsible for stolen/lost credentials. If the service account credentials are put in the git repository and accessible to everyone, then it really doesn't matter whether there is one service account or many, because the people most likely to create a security incident have full access to all credentials. So yes, there certainly are "best practices", but it isn't always (or even usually) a yes/no answer. – Conor Mancone Sep 04 '19 at 22:26