Skip to main content

Deals You Can't Miss

1 Year Subscription

Securing Microservices in the Cloud

Securing Micro-services is a tall order objective. Like any other thing in the realm of software development, there are a lot of tings to be taken into consideration on the approach to be taken in securing micro-services. There is no panacea for all threats. And assuming even if one exists, attempting to secure every service with highest levels using a single mechanism is simply over-doing the task that dampens other non-functional requirements (performance and scale).

So what are some of the things to take into account for security? The answer to that would be to ask yourself the following questions:
  • Who are the direct consumers to that service? Or is your service external-facing exposed to the internet or just an internal service?
    • API Gateway Pattern is a very popular pattern for securing edge-services by handling authentication and service discovery. Each external request is signed, which provides additional layer of authentication. 
    • For internal services, isn't the firewall and OS layer security good enough? In the case of containerized applications, aren't your minimalist base-images of container good enough to cut fat and have just enough processes/programs enabled to keep things secure apart from your network firewall? The alpine editions of the linux operating systems for instance wouldn't even have CURL program removing the possibility to remotely curl a service from terminal.
    • It is important to keep in mind that with microservices architecture, there are often more attack paths than in a monolithic architecture. Play the devil's advocate.
  • What data does the service expose? Open or Closed.
    • How sensitive or confidential is your data? What do you get to loose if this data leaks? 
    • Do you really want to secure your service that for instance say is serving weather data of a location, catalog of your products, traffic data of a location, etc? 
  • What is the tolerance to data staleness? Or how fresh or real-time you want the data to be?
    • How real-time a data you are look for?
    • At what rate the change of data happens?
    • What is the volume of these requests?
  • How frequently is your service accessed and at what volume? 
    • Put other-way what is the performance requirement for your service in terms of latency (the time it takes to process a request), throughput (the number of requests handled per second)?
  • What kind of attack are you preparing your defenses for? Eavesdropping, Man-in-the-middle (MITM), SQL-Injection, Cross-Site Request Forgery (CSRF), Denial-of-Service (DoS) etc.
    • The medicine depends on the illness. What security measures are to be taken depends on what threats we are attempting to thwart.
All the above questions together has its effect on what and how you secure your service. You should identify any risk boundaries first. Then you can create security boundaries that match. Each boundary can then be secured by whatever method is best. Some might only need to be restricted by what addresses are allowed through (firewall), others might need additional token or certificate based security.

Classifying systems and data is so damn boring but then it is very vital thing to do, to get your overall systems right. 


References

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t