Securing Drone Business with Secure AWS Cloud Hosting
In this section of the series, I’ve covered an exclusive interview with Aman Mehto, Platform Architect of Indshine. He gives the best analogies to make the technically codified cloud structure and security issues understood in the language (not so technical) spoken by most of us.
This interview was conducted keeping in mind the concerns Drone businesses generally have with cloud storage.
I started the interview by asking Aman (A) a basic question, “What does it mean to have a secure environment?”
Aman says, in terms of cloud data storage a secure environment is a trusted and compliant environment that solves the critical business challenges be it data governance, data control, and ownership of data — no matter where you store your data on cloud.
Maitri (M): Can I do without securing my data on cloud?
A: Definitely, No! It is evident that Cloud Computing has gained rapid popularity. Now is the time to bring Security and Privacy concerns about cloud computing into the light and discuss them further. Indshine has collaborated with Amazon Web Services (AWS) to provide data management and infrastructure management on cloud to its users. We understand that it is always a risk to handover your sensitive business information to a third party. Indshine has secured the system to avoid any possible breach of geospatial data that would cost its clients and their business.
Aman: Generally people have a lot of questions about the data security on cloud but are always hesitant to ask because of their inconvenience with the technical language. I won’t say that I’ve not been asked this question before but it comes from a very small section. I am extremely happy to answer your queries here.
M: How you ensure Indshine provides a secure cloud environment to its clients?
A: Before I answer this question I would like to give you an outlook of the tech understanding of the software. Every time a user interacts with the platform we consider it a transaction and categorize it as transactional behavior of the user.
Our efforts to ensure security starts from here itself. Now, To ensure these transactions are secure we’ve collaborated with Amazon Web Services (AWS) and use it as our cloud stack.
To give you a brief about AWS, it provides several services which in layman’s term could be understood as providing security, database, storage etc. Since this question is regarding the security point of view we’ll discuss that specifically.
We ensure security on three fronts:
- Ensure security on the Backend.
- Maintaining authentication and authorization on API Gateway.
- Securing binary or file level data.
M: Even before we discuss “Ensuring security on backend” please explain what is backend?
A: Good that you asked. So when we talk about any software there is a frontend which is how we see it and there is a backend which is how things work or we can also term it as the technical part of how a software works.
Case Scenario 8:(Remeber we had a deal of putting out a series, check out the previous blog)
How does Indshine ensure security on the Backend?
A: The backend is on a private VPC (Virtual Private Cloud) which suggests that it is off the grid meaning that it is not on the internet. This is a basic premise, all the code running on the backend is running on a Virtual Private Cloud which is an AWS service. VPC ensures that there is no access from the outside. Second, we use Kuberenetes for orchestration and container management. Now you may ask what is orchestration? Orchestration is the term which suggests making a dynamic architecture that continually shifts and heals itself. It basically helps us in simple data processing and maintaining our Microservice Architecture at the backend.
The question that follows is; if the backend is completely off the grid how do you communicate with it.
Case Scenario 9:
Maintaining authentication and authorization on API Gateway.
A: We communicate with the Backend through the API (Application Programming Interface) Gateway. API is that one language that everybody understands. API Gateway is the gateway to the backend, again on the backend side there are microservices running that have their own APIs and those APIs are exposed on API gateway. Now, to access those APIs a user must have proper authorization. The authentication and authorization are done on the API gateway.
M: You’ve used the terms authentication and authorization simultaneously. Can you please elaborate on the difference more?
A: I’ll explain it in reference to Indshine. In the beginning, I told you about the transactions that a user makes when he’s on the platform. Authentication and Authorization should be understood in the light of user’s transactional communication with the platform.
By authentication I mean how do we ensure that the individual is the individual he’s claiming to be. For Instance, Sam is Sam and he’s not pretending to be Sandy. We ensure it through email and password challenge and other authentication challenges like Social IdP based authentication, OTP based authentication, etc. Once we make sure that the individual is the same individual he’s claiming, he’s given a particular code or access token. This access token is considered his authority(authorization) proof on the platform.
More about Authentication Vs Authorization
Now here we must give it some time to understand the difference between Authentication and Authorization. Authentication is the third party responsibility, as in, it is somebody’s responsibility to ensure you are whom you’re portraying to be. On the other hand, authorization is accepting that the individual is whom he’s claiming on the basis of the document that supports the claim even if the individual is forging the identity.
Authentication is done once at the time of the user’s entry on Indshine, but authorization is done more often. The authorization code given to the user at the time of entry is then attached to every request they make to the API gateway.
This is pretty much like getting issued a library card where on the 1st day you are asked to bring your documents to authenticate your identity. Once you’re authenticated you’ve got the authority to surf through the books. You show your library Identity card (authorization) to issue books. On Indshine, suppose you go to your private projects you don’t find private projects instead it asks you to sign in, once you’ve signed in you’re able to see your private projects. Here you’re hitting the Private API when you’re not logged in so it asks you to authenticate and once you authenticate it gives you an authorization code to access private projects. Now you’ve been given the authorization to view all private projects of Sam. That is how we maintain authorization on the API Gateway.
The difference between library card and Indshine authority token is the expiry limitation. Indshine authority token expires in an hour and this is for the security reasons.
We use this in tandem with another AWS service “Cognito” it is our OAuth Standard. Cognito maintains and generates all the authorization tokens and evokes authentication challenges.
Now, this Authentication and Authorization is well and all but how do we maintain actual binary data security?
Scenario 10:
Securing Binary or File Level Data
A: Let me tell you what’s binary data. Binary data that I’m referring to is unstructured data, for instance, a file. For us, 90 percent of the data uploaded on Indshine is unstructured data.
M: Where do you store this data?
A: We’re using AWS S3 (storage) service particularly for storing this data. All the storage is again done using an authorization token. (Now you understand why I have given so many analogies to make you understand the difference!)
If you’ve created a project and uploading drone data to that project; we make sure you have the ownership of that project using the authorization code. Now, you’ve given Indshine an authorization code (creating project) and a file (unstructured data), first, we’ll run your authorization to see what sort of access is allowed to you (be it “can view” and “can edit.”) If there is “no access” we won’t let you upload, if you have “can view” access we won’t let you upload, but if you have “can edit” access then only you can upload. So that’s how Indshine has secured the Upload process.
Download process is a bit tricky and more frequent than the Upload process.
The download is done for two categories:
- Visualization: Download of scattered and fragmented images in order to visualize data.
- Bulk Download: Download the entire file.
The first sort of download has more usage than the second one. When the data comes down we again use authorization token(generated by Cognito)to generate a signed url and Cloudfront is used for it. CloudFront is Content Delivery Network services(CDN) that ensure the speed of the signed url that further ensures the security of data.
So that’s how we ensure our user’s data security. First, the backend is off the grid. Second, There is only one gateway to reach the backend which is secured by API gateway which is further guarded by Cognito, our OAuth Standard. Cognito maintains and generates all the authorization tokens and evokes authentication challenges. Third, securing upload and download of unstructured data. This architecture of Indshine is providing foolproof security to each user who is making use of the platform.
Wondering about the next story? It will be up the coming Wednesday. What it would be about? I’ll drop a hint like last time; it is on maintaining a repository of your projects. Follow the publication to get the notifications! Also, benefit from the shared public projects on Indshine that you don’t have to log in to see and contribute to get yourself noticed among industry people.
