What’s your best strategy for safely giving non-technical teams access to server resources without compromising security?

welcome to scientific/research computing and HPC where this need is a #1 requirement covering many millions of dollars in petascale storage systems, huge GPU servers and tens of thousands of CPU cores! I can't honestly answer your question in an enterprise context because in research these systems are "digital laboratories" and the end-users need to be able to somewhat control and manage their "laboratory" so this requires a different infosec and ops stance than something that IT can argue is a just a basic enterprise endpoint system with defined requirements. Basically it's a requirement that end-users have more access and more freedom than on standard servers. of the many methods here are some common ones I see all the time \- MFA on all the things (logins) and a lot of monitoring over service accounts and "end-user automation" \- Log shipping away from the systems the non-technical people are on \- Users with automation accounts are never allowed to login directly as the service user. They must login as "themselves" and then sudo to the automation service account so there is an audit trail \- Training, training, training and a solid Acceptable Use Policy. First time you violate policy you get an email warning; second time the warning is CCd to your manager. 3rd violation and you lose your system access and HR/mgmt is involved until you re-train and re-sign the AUP. \- VLAN isolation and firewalls that do https intercept and content screening \- Blocking internet software repos (CRAN, PyPI, etc.) and using jfrog or nexus style caching repos where security rules can be applied to open source packages. Github destinations allowed on a destination by destination basis. \- Very good backups and 100% end-to-end provisioning and config management. If a scientists wedges or breaks a system we don't repair their hack job, we simply wipe and redeploy. This is the "social contract" part between IT and the users -- in exchange for "more freedom" they understand that IT is not gonna move mountains to fix what they broke. When explained well this system works among all stakeholders \- Biggest commonality is next-gen EDR like Crowdstrike or whatever. For systems with a lot of non-technical users you need behavior based security software, not signature based malware/AV \- custom sudo rules or on the cloud (AWS) we write custom SSM Automation Docs if needed for users to invoke