Limiting Replicate user's access to endpoints

[simonB2020]

I have a source end point, to a sensitive data source.
Therefore I need very tight control over who has access to consume this endpoint and where the contained data is replicated to.

Is there any way I can control which endpoints my replicate users can interact with ?

Thanks

[Shai_E · Accepted solution]

Hi,

Per endpoint? no, i don't think there is a way to control which user has access to which endpoint.

However you can decide through user permissions in replicates server tab, which user has access at all to run tasks and change endpoint settings.

But again this is for the entire replicate server not per endpoint.

You can give a specific user "Viewer" permissions only which will basically mean he cannot preform run time task operations and he cannot edit endpoint settings.

[Heinvandenheuvel]

>> Is there any way I can control which endpoints my replicate users can interact with 

Noop. Best you can do is set up multiple replicate servers and control tasks that way. This is very commonly done for dev vs qa vs prod. And given servers could use specific database authentication to scope which tables can be read perhaps, but for many endpoints the minimal replicate user requirements already allow it to look everywhere. Specifically most sources (which ones are of your concern) required the Replicate DB used to ready the change log - which has all data for all tables. Still, if there is no access to the base table then table object numbers and table descriptions required for parsing the CDC logs would not be accessible and those those table would be protected.

Still, You'll have to be able to trust (and audit) the task developers to select the allowed tables and target databases. 

Mind you, a Replicate user/operator being allow to stop/start or even define tasks does not see the bulk of the data in general. Just errors and sometimes through the highest logging level, but that's  in the task logs which will stay behind as evidence. I think the biggest risk is  replicate used defining a rogue target database where they do have data access and create a task to siphon data there.  Again: trust but verify (repsrv log, exportrepository reviews, audit trails, reptask logs downloadable, but not directly accessible by those users/operators.

Hein.

[Steve_Nguyen]

@simonB2020 any of the advise help ?

[simonB2020]

Steve,
None solve my use case unfortunately;  but they do at least help me understand that it's not possible - which saves me from chasing a dead-end 😉