In many startups, the developer of an application is also in charge of managing the server. Since resources are thin, this is how it has to be. Developers don’t always make the best decisions when it comes to managing security concerns on servers though. Here a few tips to you developers in charge of managing servers. Believe me, if you’re successful, you will regret not having followed security best practicies from the beginning.
- Go Role Based – Having roles helps auditing, plain and simple. If each user is given their own permissions, you have to audit every user and all their permissions. It is much easier to audit roles, and then see which users are in which roles. This can be accomplished with groups in Windows.
- Don’t share – I have said it before, and I’ll say it again, Sharing is for adolescents. Don’t share logins between multiple people. Each user or application should have different, well-named users. They should instead be sharing roles (see above).
- Give the least – Remember the time that service wasn’t working for some reason, so you changed it to run as an administrator? Don’t ever do that again. In fact, give everything the least amount of privileges possible. Adding privileges is easy, taking them away is very scary and hard.
Duh right? Well, I bet you have violated all of these at some point. If you follow them when your small, getting big is a lot easier. With size comes auditing and compliance, which shouldn’t be hard but is for all too many organizations. Follow these simple tips, and the day you get audited will be a lot easier.
Role Based security is awesome. I took my implementation a step further and add permissions to each role. For instance, I have user admins and domain admins. Our customer support reps have both, but they only have “create”, “read”, and “modify” permissions, no “delete” permissions. Our billing team also have both roles, but only “modify” and “delete” permissions.
This gives us ultimate flexibility in setting up new users, but does introduce a bit of complexity to the user interface. In order to get around that complexity, I used the concept of groups, but instead of forcing users into a particular group, use the group as a template for setting up roles and permissions. For instance, back to the customer support example…if you introduce a new role into your organization, say Customer Support manager, you can click on the “Customer Support” group, but still simply add the “delete” permissions to both user and domain admin roles.
As the number of features in your system increases, you can simply add new roles. If we add mailing lists into the mix, we can now give a subset of users the “group list admin” role with all permissions. Easy peasy.
From a coding standpoint, the initial code to manage all this can be slightly complex, but most modern frameworks have the ability to create plugins, which is an optimal place to add your security. In an MVC framework, simply adding your security checks at the top of your controller actions is ideal and can sometimes be simplified even more by doing security checks at the controller level instead of the action level, depending on the level of granularity needed by your application.
I love me some role-based security.