During the course of the development and management of your product, you will have people come and go from the project. You need to make sure you have control over the key components and products that power your business. Here are a couple of reasons you might be in this situation:

• You outsource aspects of the project to third-party developers
• You collaborate with experts on marketing campaigns
• An employee leaves the company, or a new one joins

Before we dive into how you can accomplish this, keep these principles in mind.

Balance security with productivity

The best security would be to turn everything off and allow access to no one. In that case, nothing is accomplished. Effective security with maximized productivity is a trade-off. Don’t be so restrictive with security access that someone can’t do their job effectively. They will end up spending a large amount of time working around the security barrier. In a high-risk system, this trade-off may be acceptable.

Don’t be so restrictive with security access that someone can’t do their job effectively. They will end up spending a large amount of time working around the security barrier. In a high-risk system, this trade-off may be acceptable.

Separation of duties

With a team of one or two, this is largely irrelevant. As your organization grows you’ll want some checks and balances to minimize your risk.

Can one person destroy all or a large part of your company?

In these instances you can set up a process that naturally fits into the flow which requires multiple checks or approvals to allow risky behavior to occur.

An common example of this would be making new features or changes available to users of your product. With a larger team, when a developer is ready to “push” new code, it will be checked by a peer or senior person who then gives their approval. With that approval, commonly, the new code is automatically activated or “deployed”.

Least privilege

Only give someone as much access or permission as they need to effectively do their job and no more. This not only protects you and your organization but protects them.

Consider a service which allows the addition, management, and removal of an asset. Some services will allow very fine-grained control of permissions for users.

If the person working with this service would never have reason to delete an asset, then don’t assign to them the permission to delete assets. This restriction protects you from either malicious or accidental activity. It also removes the chance that the other person is going to delete an asset accidentally.

Types of Assets

We’ve talked about the general principles of security to keep in mind when securing your assets. Let’s look at some of the high level categories or larger assets that you should be looking at.

Source Code

One of the most important assets for a SaaS product is the source code, the text of the programming language which drives the program that powers your product.

The best way to manage your source code which happens to lend itself to being a secure way to manage this code is by using a source control repository. One of the most popular hosted services is Github.

The proper way to use Github is to add each developer’s Github account as a collaborator on your project. This feature gives you the ability to not only control access for each developer to the source code but gives you an auditable trail for code changes.

Data

Another critical asset to your organization is the data that your users are entrusting you with that either powers your product or allows them to get the expected value from it. Access to production data is one of the more tricky things to manage and do well.

If access to live data is needed, read-only access should be the default permissions. Write access to live data should be tightly controlled.

Systems

Low-level access to the systems that support your application can be complicated. Often it will require a technical person to set the access and permissions for someone else. In these cases, follow the guidelines above, particularly, the principle of least privilege. Also, make sure the process for granting access is fully documented. Having a process or checklist means that when a person’s tenure with your project ends, you can be more confident you’re covering all the bases.

Third-Party Products

In the current age of SaaS, operating a product often means leveraging and integrating with a number of third-party service providers.

How to protect

Team Accounts

The most common way of managing access to these products is with a team account. An organization or team account typically means there is one user who is the account owner. That user can invite or add other users to the account and give them predefined roles to enable features of that product.

Here are some common third-party services used by SaaS products along with instructions to manage their team features.

Shared Login

If a service does not offer team management, it may be necessary to share a common login. In this situation, a password manager can be helpful. Password managers like LastPass and 1Password have team features which allow you to add users to your team and then share a login with the team.

When someone joins your team, you can share a specific login with them, and they will be able to retrieve the username and password. When they leave your team, you can remove the shared item, and they will no longer be able to access it.

As a precaution, should they have copied the login, you can change the password and update your password manager. The password is updated for the remaining team members, and they will continue to have access.

API Keys

If a developer is tasked with the integration of your product with a third-party provider, they may not always need a user account to log in to the product. It will be highly dependent on the product.

Usually the way a system integrates with an external system is through the use of an API key. This key is embedded in the program and passed to the provider along with the request which indicates to the third-party that the request comes from a valid user.

It may be sufficient to create an API key in your account and communicate it to the developer. For instance, Amazon Web Services allows you to create an account without a password but with an API key. In this scenario, the person does not have access to login to the system through a browser but can use the API key to write code that interacts with AWS services.

Conclusion

As mentioned, security is often a trade-off. You may not have an elaborate security apparatus and audit capabilities. Maybe the best you can do right now is a shared account that has direct access to live data. If that’s where you are with your business, then manage that credential in the most responsible way you can.