- Bare Metal
- Bare Metal Cloud
- Big Data Benchmarks
- Big Data Experts Interviews
- Big Data Technologies
- Big Data Use Cases
- Big Data Week
- Data Lake as a Service
- Dedicated Servers
- Disaster Recovery
- Industry Standards
- Online Retail
- People of Bigstep
- Performance for Big Data Apps
- Press Corner
- Tech Trends
- What is Big Data
"I Thought You Would Secure That S3 Bucket"
As a Romanian Real Estate company recently found out the hard way, diving head first into the cloud can have some devastating consequences, at least from a security perspective, leaving your company much more exposed than it was in a self-managed environment.
This is because security was typically done at the perimeter of your stack, by (internal or external) sysadmins/DevOps, whereas cloud-native solutions security needs to be done at the component level by - or at least in conjunction with - developers.
The difference is important as developers that suddenly find themselves moving into an unfamiliar territory don’t spend enough (any?) time understanding the security characteristics of the component they are using since that was not their job and most likely have more pressing deadlines to meet.
"Oops, I forgot to secure that S3 bucket."
At the same time, cloud-native applications are more complex by their very nature. It’s what makes them scalable and fast, but this also means that no single person knows the whole thing anymore, and things fall through the cracks between job descriptions.
This is different from before, when a team-lead or more experienced dev would judge security-related aspects and veto riskier solutions.
"I thought you would secure that S3 bucket."
There are many solutions to this problem but, of course, it means the company needs to sit down and think about the risks and then try to mitigate them. Security by design as a principle needs to grow in awareness in the development community as the world relies more and more on devs and cloud native applications.
Devs need the training and the constant reminder that they are now the first line of defense against attacks. On the other side, we don’t have script kiddies anymore, we have merciless, sophisticated state actors that will not forgive any mistake. Just look at the Microsoft Exchange hack.
Kubernetes brings back separation of concerns
One final topic that I might like to add is that Kubernetes should be considered instead of working with the cloud provider’s services directly. For example, one could use Kubernetes services instead of AWS ELB, Kubernetes volumes instead of S3, and so on.
This allows the developer to use an abstract, pre-authenticated service just like S3 or ELB, but moves the responsibility for configuring them clearly to the DevOps team.
This separation of concerns will be crucial in eliminating the confusion regarding who does what in relation to platform security and has the added benefit that you can take your toys and migrate to another service provider (such as Bigstep) if you want to, for added performance, security, data locality, better support, to name a few.