We’re reviewing the access levels for our various accounts trying to bring them down to least privilege.
Our current setup has the actual application server running with more access to the database than what we think is probably necessary.
Before we go trial and error to see what we can reduce it to I’m wondering if anyone can comment as to what exactly it needs.
Based on what I can tell it shouldn’t need anything more than CRUD, and execute. Can anyone confirm if anything more or less is required?
You need to separate heads down client usage versus ‘admin’ usage. Admin will deploy new views and tables (UD Table deployment). If you really want to lock down access then I would consider an alternative credentials and possibly a different app server in IIS for admins only. Deployment admins would go thru the admin credentials and admin app server if that makes sense.
I think the separate app server is probably overkill for what we really need.
Right now the user that’s running the app pool is setup with admin level access to the database.
Really we just need to get it down to a reasonable level. From what you’re staying the creation of UD tables is going to require more than CRUD and execute. All the other tasks we run through the admin console and execute as whoever is logged in.
In theory if we were to bring it down to DB owner that should be sufficient for everything?
Should be, It’s been awhile since I worked thru the admin needs but heads down entry should need minimal. The admin lock down is where I am fuzzy. I have a test and doc story on it for 10.2.200 that I am not sure is in scope or not, At the least I want to grab our best practices from our SaaS Ops folks and publish that. Not sure yet where that sits in the todo list in core dev at the moment.
Pester your local support rep for that (non-existent) security whitepaper. Customer ticket numbers attached to stories always help me sell the need in prioritization meetings
I also pitched a two part Extended Ed class for Insights - locking down infrastructure and security in the app. That looks to have some decent level of interest.
Forward looking statements, safe harbor, views are my own, etc
We’ll give that a try on our dev system and see how it checks out. If anything explodes I’ll be sure to update this thread.
I was going to skip the support route since every time we talk to them about minimum access requirements their response is usually ‘just give it admin rights’. Since you made such a compelling argument I’m going to have to pester them now.
Definitely going to keep my eye out for that. Given the customer requirements we’ve been having to address that’s something that would be an easy sell to a few people here.