There are plenty of reasons to go with centralized API security by deploying an API gateway but in this blog post we are going to focus on why it’s beneficial for your development team(s). The security model in an organization can have a significant impact on a company’s technology and development team structure and size.
Organizations with a centralized API security model typically have a small group of highly skilled application security professionals that focus on reducing and eliminating security risks. In the case that there is a breach, the group is ready to take ownership and act quickly to resolve the problem. And, they can work to take steps to prevent similar breaches much quicker because it’s a lot easier to adjust configurations than it is to assess and modify coded policies.
When it comes to a decentralized API security model, policies are typically ad hoc, application developers are usually asked to code the security policies and this often requires project and product managers too.
Coding takes longer and is more difficult
Let’s look at the difficulty and time it takes to code application security policies. In the table below, there are a few example security policies organized into three categories: beginner, intermediate, and advanced. Each policy’s difficulty is represented on a scale from 1-10, with 1 being the easiest and 10 being the most difficult. The resulting coding to configuring ratio shows the difference in difficulty between the two. Note: these figures are estimates based on personal experience coding and configuring application security across a variety of industries and projects.
When working with a gateway in centralized API security, typically, no coding is required! Therefore, you will not need to dedicate development resources to the security team. Additionally, many policies can be reused when they are created through a gateway in a centralized approach. This can save a tremendous amount of time for both development and QA.
The ratios shown in the chart above can also be applied to the time it takes to code vs. configure a security policy. For this example, let’s assume we are creating security policies that fall into the beginner category (8:4) and that ratio can be applied the number of work units (hours). As shown in Sleep Better with Centralized API Security, the number of policies in a decentralized model must be represented as (number of system^2)*8 but in a centralized model with a gateway, it is represented as (number of systems *2)*4. The gateway only requires one path per service/application but a decentralized model requires a policy to be coded for every possible connection between applications and services.
As you can see, the amount of work can dramatically ramp up as the number of systems increases. This model can really help an organization justify the cost of centralized API security.