Data Security in the Cloud: The Benefits of a Microservice Architecture
With more and more applications moving to the cloud, all eyes have turned to data security. Exposing data sources to the Internet has an inherent risk of breach and requires careful thought and architectural planning to avoid exposing any data that should be protected.
Creating layers of security
At T3, our service-based approach and focus on real-time data aggregation, transformation, and interaction allows our applications to be constructed in a manner that adds layers of security. It prevents access to data for our own systems and provides an additional level of security to the ecosystems with which we interact.
Let’s take a closer look at our process
For the purpose of discussion, let’s envision a project where we are integrating multiple consumer interfaces with a loyalty system, multiple CRM systems, on-premise customer/consumer data stores, and additional complementary data stores. The role that our applications play is essentially a data “traffic cop.”
The consumers of our exposed microservices can run the full gamut of the Internet of Things. From websites and native mobile apps to home devices and commerce systems, we provide an interface for retrieving, augmenting, and enhancing data in any of those systems. Our service consumers do not interact directly with any of the previously mentioned systems, but instead request what they need from the service architecture.
What security benefits does this provide?
- Back-end data stores do not need to be directly exposed to the Internet. Our infrastructure maintains control of all traffic between our application and the data. No connection between the sensitive data sets and the public consumers exists.
- All data is encrypted in-transit and at rest at every point in our application.
- The real-time nature of our approach does not require our applications to store the most sensitive data locally and we never have to tie it directly to an individual. We only require non-identifiable pointers to get the data we need.
- Credentials for back-end systems are managed in a way that keeps them encrypted and inaccessible to parties other than the application that requires them. They are not stored on disk at any time, nor are they in the code repository. Our API authentication is maintained centrally for more robust monitoring, alerting, and management.
- In most cases, an additional layer of an API management system will provide the interface for consumers, so our API service consumers will not be hitting our applications directly. This allows further control of the network traffic that can access the application. Consumer authentication and authentication to our applications’ servers directly are kept separate.
- Microservices can be specialized and decoupled from their counterparts. They only have access to the platforms and data they need to perform their jobs. Individual services can call other services as well, so duplication of functionality is not necessary.
By decoupling sensitive data stores and access to the systems that house them from the application, a service-based architecture can provide a higher level of security through access control and a separation of concerns. The security state of any application has more to do with HOW it is deployed and architected and less about the platforms it utilizes. Real-time data access, aggregation, and transformation removes the need to store sensitive data in accessible places, which eliminates the possibility of unauthorized access.