Service Accounts and YOU!
These days you may hear a lot about 'service accounts' out in the world. They are ubiquitous among databases and SaaS systems alike. But what exactly IS a service account...and how does it differ from a normal user account? Why would you want to use one?
In the Quickbase universe, a service account doesn't differ from a user account except for in their intended/practical use. A service account must be tied to a real email address, just like a normal user, and provisioned just as any regular user would be. However, service accounts are generally used to drive system processes like API calls. Specifically, for Quickbase, they can be very helpful for Pipelines!
If you've never had to transition an app from one admin to the next...consider yourself lucky! Service accounts can help streamline shifts in ownership to make things easier on everyone.
When I was a Quickbase client - our realm grew organically in the initial years. Lots of builders who all owned different things from apps to email notifications. But as we grew as a company, we quickly realized we needed to apply some future-proofing governance in the event key people moved on to other opportunities.
Our first order of business was: how would we manage a service account? Who would have access to the credentials? How would we monitor how this account was utilized?
We began with laying the ground rules for our service account:
- 4 people would have access to the credentials:
- CTO (they were not a Quickbase builder)
- VP of Business Systems (they were not a Quickbase builder)
- Manager of Business Systems (overall owner of Quickbase at the company)
- Most senior CRM Administrator (one of the main Quickbase builders)
- This service account would be the owner of any and all applications in the realm.
- It would also be one of our Quickbase Super User accounts in the case for whatever reason ownership of an application was not transferred.
- This service account would be used for any Quickbase - to - Quickbase integrations.
- Server-side scripting
- (Were I still employed there, we would also use it to build pipelines.)
- If any of the 4 people with access left the company, the password and any usertokens they had access to would be changed within 24hrs of their departure.
- Anyone accessing a Quickbase application through the UI with the service account credentials would log that action in a specified table.
- This was cross-referenced with audit logs as a SOC II audit control to prove access.
- Any access had to be tied to an active work request ticket in our system.
- Any integration work would need to be requested via the ticketing system, and performed by one of the builders with access to service account credentials.
- These rules were documented as part of our larger governance documents and stored in a central location.
You may be thinking 'that's a lot of rules'. The good news is that this post is not intended to be prescriptive as much as it is to clear the cloud of uncertainty around service accounts and their use. Our implementation was based on many different deciding factors: risk management, compliance with security controls, and any number of other considerations. That being said, your mileage may vary. Governance of service accounts may already be defined by your IT department. Good communication between security-managing departments is key!
Interested in more? Our Customer Success team regularly partners with Quickbase clients to help distinguish which governance path is right for them. Talk to your account team for more information!