IT professionals can create security and access models that transform APIs from unwieldy legacy apps to self-defending services.
Many successful application programming interface initiatives start with the goal of unlocking data that is protected by traditional Web or perimeter-based access controls. Although those back-end applications were designed to address a business problem, over the years they have evolved into monolithic, complex and unmanageable applications.
The majority were designed in two- or three-tier models for the Web. A typical three-tier application uses a tightly coupled component architecture that involves the database, back-end application, user agent and users, and it relies heavily on business logic to protect the data delivered to end users.
In that pre-API world, the app was monolithic, and any change to the business logic necessitated rigorous and laborious quality and change control. Hence, delivery of applications and services took months or years. Furthermore, data security in the pre-API world was enforced by coarse and siloed access controls that used an application facade to manage identities and permissions, and in some cases, they were isolated by network-level access controls such as virtual private networks.
One of the major shortcomings of tightly coupled architecture is that it doesn’t easily support emerging channels such as mobile platforms or the Internet of Things — not to mention the cost of security changes and threat models that must be vetted before being released to customers.
An API-first strategy, in contrast, allows data and application owners to provide consistent, secure access to data, independent of the digital channels through which the users’ interactions take place. A successful API strategy for government organizations would allow developers to be more agile within their trust boundaries and collaborate with partners.
So how can federal IT security professionals enable their agencies to deliver APIs that are secure and flexible? A successful API strategy should:
- Protect data delivered via API from end to end, starting with the user and ending at the application.
- Enforce consistent security policies irrespective of the channel by which the user interacts with the back-end application.
- Not make any assumptions about data protection controls that might or might not be incorporated in the digital supply chain. For example, instead of relying on app developers’ security features, API services must secure the data using appropriate authentication and authorization mechanisms supported by APIs.
- Incorporate a security model that supports fine granular access control and allows apps to create, read, update and delete at the data-cell level with appropriate authorization privileges. That enables developers to innovate based on user experience without being constrained by rigid data access scopes.
- Use version management to oversee the life cycle of security models. For example, a new authentication scheme could be associated with a new version of an API while maintaining compatibility with the existing API.
- Log every API interaction with user identities to facilitate robust auditing and investigations.
- Use industry-standard authentication and authorization protocols such as OpenID, OpenID Connect and OAuth to deliver consistent access control across digital channels.
- Create consistency and hide complexity of security by embedding policies into every API interaction. An API gateway will provide this capability out of the box.
In short, a successful API strategy demands that IT professionals understand user interactions across digital channels. Every step of the way, data should be protected in transit and at rest. A secure API strategy will provide seamless protection without adding security controls that might interfere with the user experience and service availability.
NEXT STORY: Finding nukes faster