Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Admins and developers: Two teams separated by a common language

InfoWorld | Nov. 24, 2014
The admins and developers agree on a plan for a security fix, but in the ensuing fiasco, realise they weren't on the same page at all.

Two tech teams are better than one, right? Only if they communicate well. For all their shared knowledge and experience, a company's system admins and developers can't prevent a security fix from derailing when both groups heard only what they wanted from the other at the outset.

At one of my previous jobs, I worked at a midsize e-commerce company where I was responsible for maintaining a small .Net batch processing application. Every evening, this .Net application would process the orders that had come in during that day. The next morning, our users would run reports off the processed data and send the reports wherever they needed to go: other departments, outside vendors, and so on.

Throughout the years, the previous developers had done an excellent job at securing this application. It was integrated with the company's Active Directory installation, and each user had access to only the needed areas within the application based on their role within the company.

Each user was also tied to a very specific role in the database, so they could only access specific information on the database level. Any changes to data was logged in a central location, and we could easily tell what user made what change to what data at a very fine-grained level.

For running the batch processing in the evenings, we created a user, Mr_Roboto, and added him to Active Directory and to the database. Through an automated process, Mr_Roboto was responsible for running the batch jobs at night, and all the logging for those batch jobs were done under his name. We gave Mr_Roboto as little access as needed, and "he" did his job as expected with few problems for years.

Oh, that security hole
In the same company there was a very bad security practice that needed to be remedied. On numerous servers, the same user name and password was used for the System Admin account. If anyone compromised that account on one server, then that person would have administrative access to pretty much any server within the domain. It was a bad setup and needed to be fixed by the system admins, but the issue persisted for reasons unknown to the development team.

Thus, when one of the admins pulled me aside on a Friday and told me that for security reasons they were going to be restricting users on the servers, I couldn't have been happier. The system admin said they were going to rename accounts and change passwords so that the same user would not have identical access to different servers across the company.

He then asked if this would be an issue for our .Net application. I told him it wouldn't because we didn't use the system admin accounts for our application -- change away!


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.