> Minio is a great alternative to companies mindful of who has access to user data. Of course, AWS claims that AWS personnel doesn’t have direct access to customer data, but by being closed-source, that statement is just a function of trust.
Can't a company claim to be hosting something via open-source software but using a closed-source in-house software masquerading with the same API endpoints as the open-source version? This still requires the same kind of trust as AWS.
A company can also genuinely state that it hosts customer data on-premise to protect it from the big bad cloud, but elide the part where everyone and their brother in the local IT consulting ecosystem has domain admin credentials for them & half the town in a KeepassX on a network drive.
Don’t assume self-hosted means security-conscious. For most businesses, on-premise IT is treated like HVAC or electrical only more annoying. Anyone with a work shirt could con keys to the server room off the front desk.
The major cloud providers are serious engineering shops whose business and reputation actually depend on technical and operational competence. And the Silicon Valley community is full of current and former employees who will tell you what it's like inside.
At some level in the infrastructure this may be true, but this is not my experience working directly with the RND/Engineering teams and Infrastructure teams on a lot of the big cloud providers. They will undoubtedly have many tricks to get whatever you have on their cloud working again, but there should not be an expectation that they aren't going to just get a fast and dirty fix going. It might work, but it will be a kludge in many cases.
Same with security; quite a few of the S3 on-premises providers have backdoors that allow a person to bypass even the S3 immutable functions -- while I can understand that for specific customers who are using the S3 infra for Storage as a Service needing a way to clean up data from customers who left, such features are not advertised, and IMO, such S3 vendors should not be allowed to call their product "immutable", as it's anything but and most clients wouldn't even know about such backdoors.
The actual tech behind the providers might be pretty nice (this is arguable though...), but I would not say that this has any bearing on their trustworthiness as a provider.
Nobody wins every single time against the most sophisticated attackers in the world. Microsoft put up a very respectable fight here. When a random small-to-medium enterprise IT department gets owned, it’s for some braindead stupid low-hanging-fruit reason. Attacks like this don’t happen because they are unnecessary.
There was no respectable fight. They used the same signing key for all customers AND own corporate mail. It's a stupid rookie mistake. Exactly the type you would expect from a small-to-medium IT department.
Yeah, this particular argument makes no sense, even though it's surprisingly common. "Open source" doesn't mean a thing in SaaS. It means the vendor is sharing what they tell you is the source code running behind their service. Even if it's exactly the code - which it may not be - it's unlikely to be the only code running behind the "official" service. And you ain't gonna build your own copy and deploy on their servers. Open source really means something only when you self-host, otherwise it may just as well be proprietary, as everything depends on trust you have in the vendor (and possibly the contract you have with them).
Maybe "trust" in a purely technical sense, but we live in a society. If a vendor has a part of their contract that would put them under penalty of fraud, customers don't usually worry whether they can independently verify it's true.
For instance, if you write in your agreements that data goes into this bit of open-source code and leaves it and goes nowhere else, and you list out some processes you take to ensure this is true, and the whole thing is an outright lie, that's really bad for you in ways that are clear and enforceable. It's also hard to hide from your own employees, and people come and go. You're unlikely to make that claim unless it's true.
Yes - people here talk like vendors are inscrutable black boxes, which suggests to me they have never been through a serious vendor selection process (on either side). This is not a problem businesses are unaware of, and solutions and enforcement mechanisms exist.
SOC2 may be kind of a tedious drudge to go through, and provide limited actual security, but a third-party auditor’s SOC2 attestation for a vendor goes some way to assuring you that they have some level of access controls and processes to protect your data. It’s not nothing. And the lack of a SOC2 attestation for a vendor is a red flag for sure.
Back in my proprietary SaaS days we used to regularly undergo third party security audits, code escrow processes, and numerous standards compliance hoops, to create sufficient assurance to clients to sign a contract.
I don’t understand your comment. Isn’t it the same if Amazon falsely claims to not have access to the data and if another company falsely claims to use some specific software?
> Of course, AWS claims that AWS personnel doesn’t have direct access to customer data, but by being closed-source, that statement is just a function of trust.
I'm not sure if this is a strong enough argument. Given the state of maturity in companies, most companies should really worry about their own employees or security vulnerability than Amazon's.
Can't a company claim to be hosting something via open-source software but using a closed-source in-house software masquerading with the same API endpoints as the open-source version? This still requires the same kind of trust as AWS.