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)

• Insider Threat - Employees/Contractors abusing privileges and spying on user activity (See TikTok and Twitter)

• 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:

Create Roles

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:

• Admin

  • 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.

• Privileged User

  • 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. 

• Standard User

  • 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.

Strong Authentication

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.

• Strong passwords

  • 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)

• Username

• 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):

• IP Restrictions

• User-Agent Restrictions

• 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😎).