We take security very seriously and it's been at the core of our business from day one.
For AWS, you provide Cloudability with a read-only credential that is strictly locked down to billing and usage data and can't access any of your services. For example, the credential cannot read S3 buckets (beyond your billing data) or modify your instances.
Your sensitive data is encrypted at every step of the way; we never receive or transmit unencrypted account information. We first encrypt it in the browser then re-encrypt with an even more secure algorithm (GPG RSA 3072-bit) once it reaches our servers.
Only a specialized set of hardened servers (we call “strongboxes”) are able to read the encrypted blobs. The strongboxes accept no incoming connections of any kind so their instances must be killed and manually redeployed using strict security procedures when any changes are needed. The keys needed to decrypt the blobs never touch disk. All web connections are sent via 256-bit DigiCert High Assurance EV CA-1 SSL.
Staff members do not have the ability to decrypt encrypted account data, and we use extensive best practices to keep your sensitive information secure including stringent key management and deployment procedures.
In other words, if you put a keylogger on all our workstations for a few months, then stole our computers, our ironkeys, grabbed a snapshot of our DB, and grabbed snapshots of every server we run -- you still wouldn't have enough to compromise our encrypted data.
As far as OAuth, OAuth is a great way for sites to connect to one another in response to the request of a common user, but the way it works pretty much requires that the sites interact via your browser.
In our case, we pull data in the background on a regular schedule, via a set of hardened servers that do not service web requests for security reasons.
Since your browser isn’t involved when we’re pulling data, that makes OAuth a non-viable strategy