There’s no denying that solutions that optimise data capture business success today. Platforms as a service that handle many aspects of an enterprise’s customer-facing data have revolutionised the way large companies interact with their customers, driving increased personalisation, better service, and higher value interactions.

This flexibility of PaaS solutions such as Salesforce has enabled an amazing 360-degree customer experience and tremendous growth in value. It has also enabled citizen developers to take governance into their own hands, often without the appropriate understanding or controls required to minimise the threat of bad actors, internal or external to the enterprise.

Most PaaS solutions are outfitted with a proactive security framework to enable success, but many CISOs, CIOs, and IT leaders lack the full understanding of the shared responsibility required to ensure ongoing compliance.

There are some common scenarios we’ve all heard of, such as the pharmaceutical rep who brings his book of business with him to a competitor. And then there are more surprising scenarios, like the healthcare organisations that unknowingly expose protected health information to all their customer service reps, or the wealth management companies whose summer interns have access to all the Social Security numbers of their high net-worth customers.

These are vulnerabilities created, more often unintentionally, by admins and developers trying to support the business the best they know how. They are also preventable with the right governance framework and internal controls to limit access.

The robust security capabilities offered by the PaaS often get purchased and “turned on” but don’t actually do anything to provide insights into risks or prevent the actions of bad actors. As with many security capabilities, enterprises unfortunately buy and “turn on” these premium features without an understanding of what their responsibility actually is nor how to create the appropriate governance model based on the real threats.

Why PaaS can be a vulnerability

Platforms as a service offer tremendous security capabilities but can be implemented in an insecure way when data governance is an afterthought. The tremendous flexibility to support the line of business tends to be the driver, with governance and compliance relegated to a last-minute scramble.

Vulnerabilities happen when the wrong people — or maybe worse, everyone within an organisation — receives unfettered access to the data housed within a platform. Granting systemwide administrative access to anyone on the payroll is a recipe for disaster. Why do part-time interns need access to sensitive information like Social Security numbers, loan origination data, and credit card specifics? You guessed it: They don’t. In cases such as these, ignorance is not bliss. It’s dangerous.

The first step in correcting this common mistake is learning exactly what data lives in your enterprise’s PaaS. You need a clear, objective data-governance plan, so everything from compliance needs to shareholder obligations need to be accounted for.

Some questions that can guide your data audit include:

• What information actually sits in your instance?
• Where is information being stored?
• Who has access to the information?
• Are you meeting compliance requirements?
• How do we value the data?

How to achieve proper security

It may sound odd, but thinking like a hacker can help shore up your platform’s security. Find the holes and cracks, and work to spackle them shut. Once that’s accomplished, resolve to continuously assess risks and perform mitigation. Staying up-to-date on your security posture requires constant effort, and eating the elephant is easier one bite at a time. Start with figuring out your why and informing an aligned road map forward.

To shore up your platform’s security and protect your data — the lifeblood of your enterprise, implement a few basic steps:

1. Figure out who cares: Determine who in the organisation has expertise, knowledge, and accountability to your PaaS data. If you can’t find owners who care, you should assume your problem is larger than you realise.

2. Start somewhere: Data inventory and classification can be scary, but if you don’t know the data you have, it’s difficult to determine how you feel about it. Start with a simple exercise to learn what is collected and stored in your system. From there, you have context for how you value this data and what are the appropriate controls to put in place.

3. Ask who sees what: Start with some hypothetical scenarios and see what answers come back. Do the right people have access to the right information? Have you applied a privileged access management approach to the data?

Once you’ve started with these basics, you have the knowledge to create an actionable strategy to get where you want to go. Remember, proper security is not a checklist; it’s an evolving journey without a final destination. Your governance journey evolves as your PaaS evolves, one agile sprint at a time.

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.

Keumars Afifi-Sabet

Container orchestration platforms exist to make container use a whole lot easier. Running any application on a container will make it portable. However, when the time comes to scale or add services, you’re going to run into problems without a platform to manage and stitch it all together, and it will quickly become too difficult to handle.

When it comes to AWS, there are three main options – each with pros and cons. The choice you make will ultimately come down to your business needs and ongoing maintenance capabilities.

To help you decide, here are the pros and cons of each managed service:

ECS: the native choice

Elastic Container Service (ECS) was AWS’ first offering for managed container orchestration. For many, this is the easiest option, and it certainly has the least amount of components to get familiar with.

As a heavily integrated orchestration platform, it’s a great choice for anyone happy with the AWS ecosystem and who wants the benefits and familiarity of AWS services and support. It’s also cost-effective, as you don’t have to pay for the control plane and can use the built-in AWS code tools as well as enjoy fine-grained identity and access management (IAM) for Services and Tasks.

When your business wants to deploy an application onto ECS, the operations can be defined for each application individually, dictating for example which containers have access to S3 and which don’t.

When is ECS not the best choice?

As a proprietary AWS solution, cloning your applications to a different cloud vendor won’t be a simple task if you go with ECS. In addition, the orchestration platform has limited support for routing, currently supporting only path-based routing, and not host-based or header-based routing. Another factor to consider is that ECS is slower to respond to state changes than the others in the Big Three, so if you’re looking to a highly performant solution – it’s not going to be the right fit.

Who is ECS good for?

If you are looking for simplicity with good value for your investment, and these factors aren’t deal breakers for you, ECS is a great beginners option, and perfect for any business without experienced DevOps to operate their orchestration. I recommend it if you have a limited amount of services (<10) to deploy on the cloud. Without the bells and whistles which make the solution more complex, you might find ECS to be preferable for your company.

EKS: the Kubernetes choice

EKS is AWS’ offering of Kubernetes, the open-source container orchestration platform that has become popular. As EKS is a managed service by Amazon, this eliminates a lot of the hassle that comes with the initial installation and maintenance of Kubernetes going forward. Amazon EKS runs upstream Kubernetes. It’s not a different flavor, so you get the same functionality as if you created your own Kubernetes cluster, which makes the platform easy to clone if you want to run multi-cloud in the future.

As an open-source platform, EKS has the benefit of thousands of developers that are working on its technology constantly, actively contributing to functionality and new features. Unique selling points worth mentioning include namespace isolation, where you can split your cluster with logical boundaries, for example limiting developers to using a specific amount of resources of the cluster. Moreover, it provides the ability to run cron jobs and stateful workloads.

EKS offers a much faster deployment time than ECS, with results in a few seconds, allowing you to deploy several times a day and feedback fast for changes. Everything can be declared using the kubectl command line tool, and there are plenty of integrations. These include service-to-service communications and native scaling of both Pods and Worker Nodes, enabling your developers to focus on their business logic and deliver new features. I’d also highlight Helm, a package manager that provides the ability to bundle together several applications or business logic for deploying and updating a whole unit in one piece.

What should you watch out for with EKS?

It’s important to realize that Kubernetes isn’t the right choice for everyone. Your business will have the added cost of the control plane each month, and there is a much steeper learning curve than you would experience with ECS, and currently fewer integrations with AWS overall. Unlike ECS, the IAM to AWS is not built-in, so your developers or DevOps will need to install additional tools for this functionality.

The other serious limitation is pod density, a unique issue to EKS. Every container (pod) is bound to a certain private IP in your VPC, and if your application utilizes many replicas or microservices your cluster will scale but not due to the fact that your instance ran out of CPU or memory, rather that your instance ran out of IPs to allocate to the worker nodes.

This results in additional costs, and can be limiting as your developers will have limited IPs for smaller size instances used by the worker nodes. If your microservices scale quickly and by high volume, this is an important factor to consider.

Who is EKS right for?

The critical question here is, once the installation is complete, who is going to be responsible for taking ownership of it? Managing and maintaining EKS needs dedicated specialists, and if you don’t have the manpower, another option might be a better fit.

Fargate: The container on-demand choice

With Fargate, it’s a whole new game. You don’t have to create your own control plane or instances, there are no clusters needed, no need for infrastructure upgrades or maintenance. Instead, you specify how many resources you want to use, and pay as you go. This gives you the opportunity to focus on the design and build of your applications, rather than spending time worrying about the underlying infrastructure.

The best thing about Fargate is rapid horizontal scaling, the ability to scale on demand. Developers simply create containers and deploy to the Fargate service. Easy set-up, no learning curve.

Fargate is not suitable for stateful workloads, requiring your application to be stateless, which is one of the main reasons why some companies wouldn’t choose Fargate. Additionally, although the ability to scale to tens of thousands in no time is exciting, in reality not many businesses need this functionality, making the cost harder to justify.

Who would be a good fit for Fargate?

Only you can know if your budget suits choosing Fargate rather than investing in a DevOps team, and if the benefits of scaling on demand are worth the higher cost. This is most likely if you have just a handful of services.

For many, Fargate works well as a hybrid solution, allowing your applications to scale where necessary for on-demand tasks rather than using it 24/7. Another consideration is to isolate those workloads with sharp surges in resource usage and run them on Fargate to minimize the impact on the performance of your ECS or EKS clusters.

In closing, EKS is an increasingly popular choice for container orchestration, but that doesn’t mean it’s the right solution for your business needs. Remember, the more features and functionality there are, the more complexity it introduces, and the more resources you will need to manage your ecosystem. It’s in your best interest to make sure that you actually need the bells and whistles before choosing the shiny new thing.

Read more: AWS, Azure or Google: Do the differences between cloud providers really matter?

Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.