Hacker News Reader

Comment by satrday | Hacker News Reader

> “My team is frustrated by the permissive nature of the platform,” Carbee said.

As someone who implements Salesforce projects for companies like this, I place the blame solely on whoever setup that Vermont org. Salesforce's permissions are very, very powerful and flexible, which also makes them complex. Salesforce recommends and works best with a "least privilege" security model.

It is frustrating to me how often I see colleagues (and some clients) push for a "wide open" permissions structure, where every internal user can see everything unless otherwise specified. It's just laziness towards doing it the right way. During a brand-new Salesforce implementation for a multi-thousand user company, the stakeholders pushed me hard for an open policy. "We trust our employees". Ugh.

View on HN

> It's just laziness towards doing it the right way.

Just because "least privilege" is "the right way" from a (some?) technical perspective, doesn't mean that it's the right way from a business perspective. There is a real, and significant, business cost to needing to wait for access and not being able to discover data (and thus not even knowing that you need to ask for access).

Definitely worth keeping in mind the business needs. I'm not going after "well designed security that meets the business needs". I'm calling out lazy security that cuts corners because doing it well takes time and effort.

That being said, there is also a real, significant business cost to leaking sensitive information. If users are frequently waiting for access or unable to discover data, that's a failure in understanding the users needs and/or failing to test those needs in UAT during implementation. Convenience should never trump security, in this context.

I'm calling out lazy security that cuts corners because doing it well takes time and effort.

Time and effort cost money. It's possible that the value gained is less than the cost, and so therefore isn't worth it. Of course, it's also possible they don't understand the value gained until there's a scandal.

Knowledge workers aren't usually hired to be process-following automatons confined strictly to requirements known in advance by their superiors, but rather to creatively design, optimize, and troubleshoot the processes around them. Which requires visibility into how they are actually operating in production, and not just in the imagination of some other designer.

That doesn't excuse exposing things publicly, or to employees who have no plausible business purpose, but relatively permissive structures internally are good.

Salesforce's worst design principle is hiding things people don't have access to.

And it cuts to the heart of the agility you're describing -- if I can't know what I'm NOT seeing, then how can I discover I need to request it?

From this perspective, Salesforce is absolutely engineered for top down "Identify the process, create a set of permissions that allows it, then apply those permissions to the appropriate set of people" design.

As opposed to bottom-up discoverability (e.g. I can see that I don't have access to this thing, somewhere) + RBAC requests for a permission set I learn I need.

>if I can't know what I'm NOT seeing, then how can I discover I need to request it?

This is so true. I feel that most of our closed source scripts are duplicates because you can't search for existing internal projects in our system. If you know it's there you can ask for it, but you usually don't, so you build your own.

One company I worked at had default org-wide GitHub visibility.

It made me realize everyone else was using source control completely wrong. Game changer to be able to look at or copy the source for {anything}.

Most places I’ve worked default to letting everyone read any source. Is that not the norm? Agree that it’s a game changer for those willing to use it, but I find that last qualifier to be surprisingly rare.

I think it varies according to industry culture. It's anathema to some industries to have that level of openness be the default.

Someone here said: “Be permissive for people, least privilege for servers.”

A great example of the "CIA Triangle," and how it's not always easy to balance the legs of confidentiality, integrity, and availability.

If people keep making those mistakes, the blame should lie with the design of Salesforce itself.

The truth is that Salesforce implementation partners vary incredibly widely in standards, and the platform has grown to be so large in part because of its customization opportunities. Salesforce has provided the tools to make the platform secure, but it is up to the implementation partners to use them. The finger needs to point to the partners doing this work.

These aren't mistakes, this is truly people cutting corners to either get a project across the line or to do it cheaply.

The product is essentially something like a very slow, "low-code" programming framework/UI builder. You get a huge variety of quality in Salesforce implementations, ranging from bad to extremely terrible.

This feels like a “well they should have already been experts” answer, which isn’t really an answer.

If a Salesforce project started with zero permissions and made you add them in, and didn’t have any big blanket “*” permissions, I’d eyeball the implementers a wee bit more.

For a project that has real world consequences in regards to private data, yes, they should have already been experts. There are about a million opportunities between the start and end of a project to evaluate and address data concerns and get the sharing and visibility model right. The permission model in Salesforce is not as black and white as zero permissions or big blanket * permissions. With a few exceptions for system administrators, Salesforce makes you make the decision of what to share with who whenever new objects and fields are created.

Yep. I was pretty confused because I worked on a COVID scheduling app hosted on a Salesforce "Site" (guest user, public site, whatever terminology use for it nowadays). Salesforce recently then had pushed a guest user security update that restricted object permissions to read. The only way you could let an anonymous/guest user write/modify was to write explicit Apex (backend Java-like language for Salesforce) to do that logic.

Albeit, we had many Salesforce developers, but we were VERY focused on security. I was pretty happy with how it turned out, because other COVID vaccine providers in the area that were using Salesforce were struggling -- https://www.austinchronicle.com/news/2021-06-11/hellsite-aus...

If anyone is curious, the scheduler I worked on is https://vaccine.heb.com/scheduler . Don't work there anymore, but I love that team!

> Salesforce's permissions are very, very powerful and flexible, which also makes them complex

Otherwise known as the "Jira Problem".

https://registry.terraform.io/providers/hashicorp/salesforce...

Reply on news.ycombinator.com