Snap Creator does not have to run as root, it can run as either root or in case of DB2, the DB2 user.
In addition with the scServer/scAgent you have the ability to further add security, since the scServer communicates with storage and the scAgent DB2.
The SC 3.5 GUI could also help since it offers RBAC (note CLI offers no RBAC just GUI, but you could limit folks to no CLI access), however when SC communicates to storage it require a username/password and this would have certain permissions which apply to all resources, you cant limit user to aggregate or volume like storeacl.
Another thing is DFM proxy. SC doesn't even need to talk to NetApp storage you can do everything through a DFM proxy using the DFM user, and communications go through it, this could also be an option. This is also in 3.5.
I think there are a lot of things that you can explore
As for Best Practices for security, I would recommend following:
1. Dont give folks root access to anything, OS or Storage
2. Use vFiler as you are doing
3. Use the DFM proxy, and manage security through it, you have more flexibility and it is more secure than creating data ontap users
4. For shared SC environments, use SC 3.5 and RBAC within SC so that users can work in their own space.
5. Use scServer and scAgent
6. Use global configuration files. This allows you to define ONTAP or DFM users and users of SC must re-use that info. They never get an ONTAP or DFM user/password or see password, they simply import a global config or they cant do anything.
Here was a video done maybe 4-5 months ago on some of the 3.5 features, like RBAC and DFM proxy which could help:
https://communities.netapp.com/videos/1999
I have opened a request to research this and see if we can do what storeacl did, but I have no commitment yet from engineering on when / how that could be done.
Regards,
Keith