SOLVED

How to allow powershell scripts that only do read operation

Copper Contributor

Hello Community members,

 

We have a custom monitoring solution we've build to perform windows monitoring internally. On this platform, we basically allow developers to write powershell scripts to specify how the data/metrics should be collected from Servers and how to interpret them as metrics. Usually all these are only read operations.

 

Currently, we're in a security situation, where we want to restrict users/developers from creating and running powershell scripts that manipulate things on the machines, such as run a new process, create a new user and so on (the list is long). However, currently any scripts can be executed, posing a security risk to the infrastructure.

 

How can we avoid this and only allow scripts that do read only operations?

 

Thanks, in advance.

2 Replies
best response confirmed by hemant_pande (Copper Contributor)
Solution

@hemant_pande 

 

PowerShell isn't the answer here.

 

PowerShell itself can be secured to varying degrees using some native mechanics as well as leveraging other features such as AppLocker. Here's some reading you can start with:

 

 

While this discusses how to secure PowerShell itself, your question is different, since you're talking about how to secure all kinds of things external to PowerShell.

 

For example, you say you want to control who can launch processes and create users - two things which have precisely nothing to do with PowerShell - there are many ways to do both without coming anywhere near PowerShell.

 

To secure such external resources, you have to look elsewhere at methods directly related to those resources.

 

For example, if I didn't want someone creating user accounts on a server, I'd ensure they are not a member of the local Administrators group, since if they are, there's nothing you can technically do to stop them creating a user.

 

Another example might be using AppLocker to define who can run which processes.

 

The point, again, is this has nothing to do with PowerShell, and I'd wager that's true for most/all of the things on your long list.

 

When it comes to securing these external resources, PowerShell does provide a useful framework for configuring that external access, but it is far from all-encompassing as it's scoped to configuring elements of the Windows operating system. Applications/services that run on top of Windows cannot be managed in this way:

 

 

Lastly - though it's for all of the above reasons, there's no such concept of "read only" for PowerShell. "Read only" only applies to the resource you're managing, not the tool you're managing it with.

 

For example, if I need to ensure someone has "read only" access to a folder or a database, I have to configure that read only access on the folder or the database, not on PowerShell. I might use PowerShell to configure the access, but that's not reflective of where the enforcement is taking place - and I could just as easily use another GUI or command tool to perform the configuration.

 

Cheers,

Lain

@LainRobertson, thanks a lot for replying.

 

I think JEA was exactly what I was looking for. Thanks.

1 best response

Accepted Solutions
best response confirmed by hemant_pande (Copper Contributor)
Solution

@hemant_pande 

 

PowerShell isn't the answer here.

 

PowerShell itself can be secured to varying degrees using some native mechanics as well as leveraging other features such as AppLocker. Here's some reading you can start with:

 

 

While this discusses how to secure PowerShell itself, your question is different, since you're talking about how to secure all kinds of things external to PowerShell.

 

For example, you say you want to control who can launch processes and create users - two things which have precisely nothing to do with PowerShell - there are many ways to do both without coming anywhere near PowerShell.

 

To secure such external resources, you have to look elsewhere at methods directly related to those resources.

 

For example, if I didn't want someone creating user accounts on a server, I'd ensure they are not a member of the local Administrators group, since if they are, there's nothing you can technically do to stop them creating a user.

 

Another example might be using AppLocker to define who can run which processes.

 

The point, again, is this has nothing to do with PowerShell, and I'd wager that's true for most/all of the things on your long list.

 

When it comes to securing these external resources, PowerShell does provide a useful framework for configuring that external access, but it is far from all-encompassing as it's scoped to configuring elements of the Windows operating system. Applications/services that run on top of Windows cannot be managed in this way:

 

 

Lastly - though it's for all of the above reasons, there's no such concept of "read only" for PowerShell. "Read only" only applies to the resource you're managing, not the tool you're managing it with.

 

For example, if I need to ensure someone has "read only" access to a folder or a database, I have to configure that read only access on the folder or the database, not on PowerShell. I might use PowerShell to configure the access, but that's not reflective of where the enforcement is taking place - and I could just as easily use another GUI or command tool to perform the configuration.

 

Cheers,

Lain

View solution in original post