Now that we’ve explored the familiar form of SaaS file sharing, let’s compare it to the very different ways that storage objects in IaaS/PaaS clouds are shared (e.g., Amazon S3 buckets, Azure blobs, Google Cloud storage). All of these objects begin with a much more controlled default. Only the owner of the object has access—the opposite of the starting point for SaaS.

As organizations deploy more and more cloud native workloads, the ability to protect them in a secure and cost-effective manner is becoming increasingly important. Data access is also more widely spread, making it even more critical to meet this protection need with a secure, logically air-gapped copy of that data.

If you’re reading this article, you’re probably either running a Kubernetes cluster or planning to run one. Whatever the case may be, you will most likely need to have a look at data—how to store it and how to secure it. There are different types of stored data in Kubernetes: In this article, we will review how to deal with each of these data types in a Kubernetes cluster.

Best practices for securing an AWS environment have been well-documented and generally accepted, such as AWS’s guidance. However, organizations may still find it challenging on how to begin applying this guidance to their specific environments. In this blog series, we’ll analyze anonymized data from Netskope customers that include security settings of 650,000 entities from 1,143 AWS accounts across several hundred organizations.

It’s time to update the list of security incidents caused by misconfiguration of cloud storage resources since the last couple of weeks have unfortunately been quite prolific. The shared responsibility model continues to be overlooked, or simply misunderstood by too many organizations, and as a consequence tons of sensitive data is leaked from the cloud on a daily basis, putting thousands of individuals (and dozens of municipalities) at risk of fraud, identity theft, and phishing campaigns.

In the last several years, companies have accelerated their cloud adoption and have invested time and resources to lift and shift their content, development and applications to public and private clouds. The onset of the global health crisis has further accelerated even the more traditional brick-and-mortar companies to invest in cloud technologies. Yet, we still see customers hosting content on on-premises repositories in spite of inexpensive per-GB cloud storage. Why is that?

Misconfigurations remain one of the most common risks in the technology world. Simply telling organisations to “fix” this problem, however, is not as easy as it might first seem because there’s a myriad of technologies at play in modern infrastructure deployments. All of this results in a complicated mix of hardening approaches for each system. What is key, then, is to identify where hardening is required and then consider the methodology for each area.

Cloud storage has become mainstream. It is one of the fastest-growing segments of IT spending and an indispensable tool for many modern businesses. However, not enough is being done to secure data residing in the cloud. According to Gartner, 90% of organizations that fail to control public cloud use will share information inadvertently or inappropriately through 2025. Almost all cloud security failures will be due to the cloud customer, not the service provider.

Amazon S3, one of the leading cloud storage solutions, is used by companies all over the world to power their IT operations. Over four years, UpGuard has detected thousands of S3-related data breaches caused by the incorrect configuration of S3 security settings. Jeff Barr, Chief Evangelist for Amazon Web Services recently announced public access settings for S3 buckets, a new feature designed to help AWS customers stop the epidemic of data breaches caused by incorrect S3 security settings.