2 ms·
Starting from a place of "I want to start providing this to my employees yesterday"... I can't see how to adopt this at an info-sec minded financial services f
by Terretta 3y ago
Starting from a place of "I want to start providing this to my employees yesterday"...
I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it.
For example, the docs show the product wants static creds for a Postgres database or signed URL for S3 bucket instead of leveraging best-practice service-to-service identity and access management.
Maybe you support what I want, and I didn't find it at first glance.
This either ...
(a) needs to support modern dynamic or token-based authentication (e.g. Oauth2.0 client credentials grant, JWT, or for enterprises ideally CSP native IAM in Azure/GCP/AWS such as share S3 by cross account bucket permissions policy instead of signed URL, etc.), or ...
(b) allow firms to operate this themselves so the spreadsheet is run in the firm's security context, no creds are shared and data never leaves.
As you are running in AWS, providing this to run in AWS IAM context could solve it, but it's likely worth your time collaborating closely with FS firms that have solved cloud-native infosec at scale for the world's most demanding regulatory environments such as GSIFIs/GSIBs, since if you can do that, it's secure for anyone. Similar for HIPAA or FedRAMP.
If your customers can be fully best practice compliant within these regulatory regimes without having to lower their standards or get exceptions to use you, then it's above the bar for pretty much everyone.
// Full disclosure: Although using all 3 of AWS, Azure, and GCP, I was an AWS CAB member for half a decade (as principal engineers you likely know what this means), with a native-AWS preference.
- fakedang 3y agoHonestly, is it possible to decouple AWS from the app? >I can't see how to adopt this at an info-sec minded financial services firm that would otherwise love to pay you for it. Else this applies for us too.
- breckognize 3y agoFor S3 specifically, we support IAM-based role assumption. If you go to Data > Import from Amazon S3 > Add S3 Bucket, you can grant our AWS account permissions to read an S3 bucket in your account. We also have dedicated hosting options for our Enterprise tier. If there's a specific data source you'd like us to support OAuth integration for, let me know, and we'll add it.
- glitchc 3y ago> you can grant our AWS account permissions to read an S3 bucket in your account. That seems like a huge privacy hole. It sounds like you're offering spreadsheet-as-a-service, where you scale up AWS spot instances based on query size.
- Terretta 3y agoGreat to hear you can do the policy. Are you able to be “NSL-proof”? This means, if you are served a national security letter with a gag order saying to turn over my data without telling me, can you? If you are not NSL proof, are you able to demonstrate who from your firm can, and cannot, by technical guarantee not by policy in the “signed agreement” sense, see my data, and can I see in an audit log any time and every time any of those people do see my data?
- dmurray 3y agoIf you need protection from the US security apparatus, you're not the target market.
- Terretta 3y agoOn the contrary, that scenario (as well as, "what if your SaaS provider or CSP is hostile?"), are great "clarifying" questions to understand the security architecture of a product that is very likely to see some incredibly sensitive data. It is possible for the answer to be that a service is NSL proof -- with asterisks, and the asterisks are very interesting to discuss. And no, it's not about the US security apparatus for most firms, although if you take a look at AWS's security teams, you'll see there is a lot of experience exchanged, and AWS does secure the US security apparatus' data. They're quite good at it.
- fragmede 3y ago> AWS does secure the US security apparatus' data. with the exception of red teams, AWS isn't securing AWS from US security apparatus attack though.