- Last Week As A vCISO
- Complete Guide To Securing Internal SaaS Admin Tools
Complete Guide To Securing Internal SaaS Admin Tools
If you are a SaaS company with thousands of customers, you probably have some sort of internal admin tool. I have personally come across many of these admin tools over the years, and they all follow the same evolution.
Evolution Of Internal SaaS Admin Tools
The evolution of admin tools typically goes like this…
Direct database access and updates
Custom scripts for CS folks (still with direct DB access)
Homegrown web app with full DB permissions
First no login
Then it might be password protected, but it’s one shared password for everyone to use
Multiple passwords or user logins
Homegrown app with 2 roles (Admin and CS)
Homegrown app with multiple roles
Homegrown app + SSO
Common Problems With Internal SaaS Admin Tools
Here are all the problems that come with above scenarios:
Accidents with customer data (deletion, modifications, errors)
Poor onboarding / offboarding - People have access for months/years after leaving the company
Lack of tracking of activity (Who, did What, When?
More users susceptible to social engineering attacks by malicious users (See Twitter Hack)
Overall, the above scenarios increase your security threat landscape, and provide more opportunities for things to go wrong.
Recommendations For Securing Internal Admin Tools For SaaS Apps
Here are my complete recommendations for anyone building or using an internal admin tool:
RBAC (Role Based Access Controls) is a fundamental part of access security where you place users into various “buckets”.
For example, I like to have a minimum of 4 default personas in an application:
This user has full permissions. It should be limited to a select group of folks, 3-5 people for example at a 200-500 person startup. At least one always being a manager.
Specific context and permissions will depend on your application and environment, but typically it’s a step below Admin where less damage can occur. I typically allow all the above permissions except deleting/modifying roles and users and major deletion of data.
The minimum permissions needed for 80% of Customer Support/Success folks to do their jobs.
Audit - Read Only
Read only access for the security team or anyone else that does not need to modify data.
You are welcome, and encouraged, to add more roles as your company grows to allow for the concept of Least Privilege (the minimum set of permissions required to do a job) to thrive.
Ensuring that users are who they say they are is of utmost importance when it comes to privileged access management. That being said, here are some guidelines:
2FA for ALL users
This is a minimum is today’s everywhere access environment.
I’m not going to go into detail here, but the minimum is 14 character limit
No shared passwords under any circumstances.
See here on why
If it’s a service account, then it should not have interactive login, should be stored in a vault, and stored in a place where it can’t be accessed in cleartext
Enable/Integrate with SSO
All of the above can be solved much more easily if you integrate with your existing SSO solution (ie Okta / Onelogin). Save yourself some trouble and engineering time.
Enable Audit Logging
Every action performed within the tool should be logged somewhere and stored for 12-18 months. If an incident happens (sometimes we don’t know until months later), we need to have logs to understand what happened exactly.
Log the following information:
Physical context and metadata (IP Address, User-agent, Browser, etc)
Login attempts into the system
2FA issuance and access
ps. Please do not under any circumstances (including debug) log passwords
Remove From The Web or Build Zero Trust Access
If your admin tool is available on the web, then you've just increased your risk profile 10x (that's being conservative, I could easily say 100x and prob still be within margins).
Things that don’t work (I’ve seen them all):
Just username / password access
Given that, everything above is super important (especially roles), but even with all that your app is now subject to all the Web Application Ilk of the web (see Owasp Top Ten).
5-10 years ago I might have told you to put it behind a VPN, and that's still totally fine. However today the modern term for VPN is Zero Trust access. I know it sounds fancy and ominous, but it's not. It's often times just a fancy identity proxy.
Make sure your VPN or Zero-Trust Model requires 2FA access.
Secure Those Apps
As you can see, SaaS Admin Apps are those unnoticed applications in your environment that can cause a lot of damage without realizing. Hopefully this article helped paint a path forward towards securing your admin app.
If you found this helpful, feel free to forward or share this with friends (or your boss😎).