Implementing security in small org
I'm working with a small org that is moving their servers to linux. They have 2 developers that will cover their development dba, and deployment issues and now in addition, they will perform some of the sysAdmin responsiblities.
Mgt. wants separate userids setup for each role. A user would sign on to the system with the appropriate userid for the task to be performed.
The problem with this approach is that with only a couple of people involved, both
people will end up assigned with the sysadmin role or the backup sysadmin role.
SysAdmins have root access and thus can do anything they want to do. So, what's the value of separate userids for each role?
My questions: How have other small organizations managed this problem? What other techniques could be used to manage this problem? For example, could the server log all activity so there would be an audit trail of who did what? How would you suggest we do this? Any other ideas?
Virtual Machine + OpenVPN + Configuration Repository
Management is looking for traceability and this is key for not only the development process but for the integrity of the system.
Before you follow Irithori's excellent SUDO advice, let's setup a little bit of an infrastructure first.
Use a virtualization platform like Vserver in conjunction with OpenVPN to develop a stable network environment(for a small business)
Change Management is only effective if you have a known configuration to start with, and a systematic register of changes. For development there are common tools like CVS that help you automate some of these changes. And a simple spreadsheet register of planned changes and some approval forms will go a long way. The objective is traceability in relation to change. If a service goes down, pull up the changelog first! (Sanity is surprisingly illusive when you don't know that you're crazy:confused:.)
You're developing an infrastructure and I realize that you have a small organization(starting with likely a somewhat unrealistic budget), However all will be for naught if you don't get this right.
COMPONENT 1 - CoreOS
This is a standardized OS Build that you use to seed a virtual environment. Pick a platform to develop a CoreOS. Whatever you're comfortable with, but something that is relatively higher on the stability curve like CentOS or Debian. Use it to setup a very essential base configuration that you can easily copy or automate the build from. Your CoreOS should include the VM host and basic access to the network devices and file systems. Using either a VPN or separate VLAN's you can setup your CoreOS to provide services ONLY to the Guest VM's and then create NAT rules(iptables) to provision access to the services running on the Guest. You provision all your keys and SUDO access rights very conservatively on the CoreOS for your developers on a private SERVICE network(see below). Create a manual update script that you can run securely from the CoreOS to update these local rights(separate from the main build)
COMPONENT 2 - VPN / VLAN Setup
I use OpenVPN because I like the central routing and static DHCP capabilities. It's not necessary to encrypt all the traffic on the LAN, but it is necessary to segment your network into 2-3 Zones i.e. STORAGE, PRIVATE, SERVICE. The key here is that combining Virtualization with a managed network layer can give you "god" power when it comes to things like allowing SUDO access. Everything in a VM Guest can be logged by the host. Check out VSERVER.org for tips on securing a guest OS.
COMPONENT 3 - Central repository for libraries and configuration
This is where you have to get organized. Use a CVS like subversion to capture active development.(The developers will tell you what they want, but don't let them camp out on their own boxes). You should keep a central repository for your OS build and another one for your configuration build scripts. Research git and "git good" at automating the installation scripts. What this gives you is known configuration state, a controlled build process, and an ability to progress forward without having to throw the baby out with the bath water!
NOTE: Vserver for example can support pretty much any flavour of Linux as a Guest, so for Ubuntu or Redhat junkies you don't have to dispute the merits of one or the other!
COMPONENT 4 - Common sense
Don't get sucked into more than what you need. For example you may need a VPN and it would be excellent for remote deployment etc.., but it may be too much of a learning curve to start with. On the other hand if your management is policy driven and is hyper concerned about security your on the right track. If it ain't broke don't fix it, just virtualize it!
NOTE: I don't recommend VM environment for databases. The issues that I have found both with Linux/Windows is that the I/O is too intensive for VMware/Vserver. In this case, just provision the CoreOS and skip the VM server for databases. OR install the database on the CoreOS and setup iptables to provision access to applications hosted in the guest OS.
Hope that helps bring some perspective to the situation,
Mainstream Networks Ltd.
Maple Ridge, BC