Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 232 posts at DZone. You can read more from them at their website. View Full User Profile

Both Sides of the Story

02.14.2011
| 3494 views |
  • submit to reddit

Amazing thing this week! Imagine this case: developers need to access production application servers logs. These are inaccessible for now because application servers machines are production level. So they are placed in a different network zone. Between the AS zone and the DEV zone, there’s a firewall configured to disallow access from developers machines. In order to solve this, a meeting is scheduled and soon, the room is filled by system engineers and software architects, all buzzing ideas.

The most pragmatic idea, update firewall rules so that developers can access application servers machines is killed outright: security is security and our security team will never let us put holes in the firewall.

At the end, two solutions are still around:

  • develop a web application that will display logs and which will be deployed on every AS
  • configure  the AS so they can serve the logs filesystem as a static webapp

What amazes me to no end is that the first idea was backed by the system engineers while the second by the software architects (including myself). I know full well the cons of developing a custom proprietary web applications: development costs (of course), maintenance costs, organization costs (who will be the product owner, who will asks for features, …) and so on. But it seems that our esteemed colleagues don’t know: they know nothing about our craft.

Now, since they are reluctant to “just update configuration”, and they not being less smart than us, they also mus have very really valid reasons to propose a custom development: these reasons we are blissfully ignorant because we, architects, in turn don’t know about their work.

We haven’t resolved the issue yet, and I think it will takes some time (read: some management decision). But this little story makes me think more and more about team organization: is it right to have architects on one side, and systems on the other (not counting developers, security, QA, etc. all neatly separated)? This experience is just another argument in favor of small project-dedicated teams including each profile and responsible as a team.

 

From http://blog.frankel.ch/both-sides-of-the-story

Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Wujek Srujek replied on Mon, 2011/02/14 - 5:49am

Can you have another machine that will have a network share where:

a. AS zone / servers will mount the share and put the logs there

b. it will be accessible from the DEV zone

cowwoc replied on Mon, 2011/02/14 - 11:10am

Simple solution: push don't pull.

 

Have the firewalled machine proactively connect and post updated logs on an unprotected machine.

Edwin Quita replied on Mon, 2011/02/14 - 11:05pm

we did the option a. develop a web application that will display logs and which will be deployed on every AS. option b. is least of a priority for system engineers most probably because of the dirty works in server security configurations

Christian Schli... replied on Tue, 2011/02/15 - 2:04am

Typical example of ignorance between teams. I bet introducing any of the proposed solutions would only introduce new security holes, but the security team may be happy just to say "the firewall is safe". :-(

Nicolas Bousquet replied on Tue, 2011/02/15 - 8:16am

Simple :

Make every developper (or people) that will have access to production sign a paper where it is stated that they will use production data only to do their job. Provide them with approprial accounts/password and rights using the network protocol of your choice. Be it HTTP/FTP/SSH/NFS or whatever is just detail. And configure the damn firewall so that it let pass the trafic.

But please, don't do any CUSTOM application for that. It is a nonsence.

The developpers can put arbitrary code in any application they work on anyway. So They have the same rights as the account that run the application. Trying to give them less rights for the sake of "security" is funny, because a motivated developper will be able to use theses rights anyway.

Opening a port (be it port 80 or 443) on a firewall allows any traffic to transit anyway, so what count is that the software is properly configured and is secure than the number of open/closed ports.

Jon Strayer replied on Tue, 2011/02/15 - 10:24am

No, seperating teams according to function (dbas, architects, developers, etc.) is a bad idea.  Sure, you get higher individual utilization, but at the cost of lower overall productivity.  It really matters if the SA working on your servers knows what your aplication load looks like, etc.

 One of the best (smoothest operating, most productive) team I've ever been on was integrated.  One effect of that was that since everyone worked for the same boss it was much easier to allign priorities.  

 For example, the developer's choice made more work for the SAs while the SAs choice made more work for the developers.  Since the SAs don't have a problem with the status quo I doubt you will be able to convince them to spend their budgit to fix the problem even if that's the lowest cost solution for the company as a whole.

Claude Lalyre replied on Tue, 2011/02/15 - 6:16pm

Just create a SSH tunnel via port 80 to bypass the firewall...

 

 

Nicolas Frankel replied on Wed, 2011/02/16 - 2:53pm in response to: Nicolas Bousquet

This makes sense so I guess it has the least chance to finally be chosen... -- grumble --

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.