May 8, 2021 at 5:57 am
I don't see a huge security issue with a separate schema. Thus, I don't see why this would necessarily fail an audit. That seems to be an overly broad claim.
I have separate dbs that specific power owners have full read, write and ddladmin to (but no db level permissions, i.e., they can't directly backup the db, drop the db, add users, etc.), and we pass an audit every year.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
May 9, 2021 at 1:08 pm
@scottpletcher & @JeffModen:
You both are assuming an environment where there is a dev/test/uat/prod set up. Not saying the OP doesn't have that - but there are environments where that isn't the case, especially when looking at BI environments (ie data warehouse/reporting). In those environments it is typical to create a 'reporting' database where 'developers' (e.g. business analysts) write queries to support reporting requirements.
In those types of environments - I find setting up a separate database for the 'developers' where they can create what is needed to support reporting while granting read access to the 'production' data is the better option. Of course, on my systems the 'production' data is a read-only copy available either through a read-only secondary or through a backup/restore process.
In a true development environment - then I agree, developers would never have access to production and more or less open access to a development environment. And a deployment process that moves changes into a higher environment with code review and sign-off prior to approving the move.
That's fine and dandy and totally true and a couple of other nice terms but, it actually doesn't have anything to do with what I'm talking about. Even in such an environment as you speak, why do Developers or End Users need to have enough privs to grant access to others for stored procedures and the like? They don't. There still needs to be a central authority that determines the viability of the code, whether it meets requirements not, and controls when something is "released" for access and by whom .
--Jeff Moden
Change is inevitable... Change for the better is not.
May 10, 2021 at 4:00 pm
I think a separate schema(s) is a valid approach. Indeed, it has some advantages. For one, the developer-created objects are in the db to which they apply. If you create only a single db, a "developer db", with all objects, then objects in that db could point to any of the other dbs (hundreds of them, in our case). If that db then needs to move somewhere [cloud, new instance, wherever], for whatever reason, it can very difficult to find all linking objects if they're not already in the db to be moved.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
December 18, 2021 at 8:17 am
This was removed by the editor as SPAM
December 18, 2021 at 8:18 am
This was removed by the editor as SPAM
May 4, 2022 at 10:48 am
This was removed by the editor as SPAM
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply