BandwidthX Blog

Combatting Cloud Security Concerns via the Principle of Least Privilege

Randy Salo


Last summer, there was some big news in the cloud-computing space when it was reported that Capital One was hacked. They apprehended the perpetrator, a Seattle-based engineer. The hacker had gained access to approximately 140,000 Social Security numbers and 80,000 bank account numbers, affecting over 100 million people. Perhaps one of the most disconcerting aspects is that the hacker was a former Amazon Web Services employee. Capital One is an Amazon Web Services customer.

This sent ripples through the industry, with a lot of speculation as to how secure cloud systems really are, not just from the Internet at large but also from within the cloud services providers. Overall the number of cybersecurity breaches has grown significantly over the last few years as can be seen from the Audit Analytics graph. The vulnerability exploited in the Capital One hack is susceptibility to a well know method called a "Server Side Request Forgery" (SSRF) attack. This was at the time the most serious vulnerability facing organizations that use public clouds, as well as private data centers. While this specific vulnerability has now been addressed, it demonstrates that we all must increase our vigilance in assuring security for our data and services from all possible bad actors.

As an important part of our security practices at BandwidthX, we subscribe to the Principle of Least Privilege (POLP), which is an important concept in computer security. It is the practice of limiting access rights for users down to the bare minimum permissions they will need in order to perform their work. Under POLP, our users, applications, services, and processes, are granted permissions to read, write, or execute only the files and resources they need to in order to perform their jobs.

With our adoption of POLP, a number of related best practices have emerged:

  • Application Authentication/Authorization - Each application has a unique secret that is used for identification and permissions. These secrets are typically quite long and are only used for application-level identification.
  • Virtual Machine Authentication/Authorization - Each virtual machine has a unique secret, which will grant access to services only when combined with a valid application secret. Each virtual machine is designated as only being able to perform a specific function (or application) to prevent misuse, or unauthorized use, of that virtual machine. In addition, a (?) Vault audits access to any and all secrets.
  • System level Role-Based Access Control (RBAC) - RBAC provides a standardized mechanism for establishing which fine-grained permissions a given Role possesses. A set of credentials (whether user or system) may have zero or more Roles applied to them.
  • Multi-Factor Authentication - Multi-factor authentication is an authentication method in which a computer user or service is granted access to a system only after successfully presenting two or more pieces of evidence to an authentication mechanism.
  • Vault-Based Secret Management – A vault like the one available from Hashicorp tightly controls access to secrets and encryption keys by authenticating against trusted sources of identity. Such a vault enables fine grained authorization of which users and applications are permitted access to secrets and keys, such as database credentials.
  • At Rest Data Encryption - Encrypting data while at rest, which is any data stored on a physical medium (such as a hard disk or SSD), is a minimum requirement for all data. This will prevent someone from taking a physical disk from a datacenter and gaining access to the data on the disk.
  • Ephemeral Database Credentials – Ideally the vault's database secrets engine enables time limited credential management. It allows you to create credentials on the fly using SQL. You can insert SQL to say, “For this particular role, provision these credentials, and then when the TTL (time-to-live) expires, revoke it with this SQL.”
  • Client Certificates for Authorization/Authentication (and in transit data encryption) - Client certificates provide a well understood method of identification, but also provide a mechanism for encrypting data in transit - this protects data if communications are intercepted while data moves between your site/server and the cloud provider, or between two services.
While the features listed above form the backbone of our data security approach, there are many other elements that complete BandwidthX’s solution. Our systems and software have been architected employing the above strategies in order to secure our data and protect our customers’ interests.

Back to all posts  

Find Us

BandwidthX, Inc.
5796 Armada Drive, Suite 375
Carlsbad, CA 92008

Office: 760-203-4955
Fax: 760-557-2333

This website uses cookies so that we can give you the best possible experience. By continuing to use this website you are consenting to cookies being used. For more information on cookies and how you can disable them, visit our terms of use and privacy policy. OK