General discussion


3rd Party access to Servers

By mark.parker ·

We administer/manage servers for a customer who has recently changed web developer, and has requested that the new developers be granted sufficient access to the servers to update the website.

The access level required includes the ability to stop/start and reconfigure Apache,the Application server and SQL server on a Linux box. As well as publish new code.

1) What would you consider to be the main risks involved in granting these third party developers this level of access.

2) Does anyone have a good idea or advice on the best way to grant them only the level of access they developers access to do these tasks, and still ensure that at the OS level things are secure.

I hope you can help me out.

Many Thanks

Mark Parker

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Security basics and business roles

by stress junkie In reply to 3rd Party access to Serve ...

First, there are a lot of web sites that offer excellent
articles on implementing security, including Tech
Republic. As a system administrator you should choose
a small group of these to check weekly and read the
excellent instructive articles that they offer. Over time
you will develop a greater sense of auditing and
implementing security than most of our peers.

Next, the business relationships are not clear. It seems
that the following situations are most likely based on
your choice of words. It seems that neither you nor the
web developer are direct employees of the customer so
the customer has outsourced both functions. You could
be a temp/contractor/consultant working on site
exclusively for this customer or you might work for a
multi-employee service business. The same is true for
the web developer. These details are important to
determine how you communicate with the customer.
Additionally, these details play a HUGE part in
determining the answers to your questions.

Note: I won't provide a lot of details. When I do I will
refer to concepts in Unix. If your customer is using a
Microsnot OS then I'll leave the translation into
Microspeak to you.

I'll describe the way that I would want things set up if I
were your customer and if I knew what I were doing.

The customer should have a production web server and
a test/development web server. These need to be as
close to identical as is possible; identical hardware,
identical software in both version and configuration.

The production web server is, of course, on the
business production LAN. The test/development web
server should be on a LAN that is physically separate
from the production LAN. This is not difficult or
expensive to implement.

If the web developer is a multi-employee business with
its own offices then they should do all of their
developemnt on their own machines at their own
office. They should configure their web server software
exactly as your customer has configured their web
server software.

The web developer will NEVER dictate configuration of
your customer's web server or of the web server
software. If they want to make a proposal for some
configuration change then you will research the
security implications of that change and you will have
the final approval. The web developer will accept your
decision and make their project work within the
environment that your customer provides.

The user account that the web server software uses to
run its service is an extremely limited account. In Unix
you would create a chroot jail. The account is in a
nonprivileged user group ( group number > 100 ) that
is dedicated to the web service. The web developers
have an account on the test/development system that
is in the same web service user group. You might also
use a restricted shell such as rbash for their interactive
login work. The developers' login directory is in the web
server's chroot jail. The restricted shell will prevent
them from changing directories or shells.

The web software development and deployment model
is as follows: the web developers, as stated above, use
their own machines in their own office to do their daily
work. They can FTP new and replacement files to the
test/development web server for final testing before
deployment to production. The web developers have
NO access to the production web server. Deployment of
new code to the production web server is ONLY done by
the system administrator.

Your job as system administrator is to communicate
the benefits of restricting the web developers' access to
your mutual customer's computers. They can do their
work in the environment that I described. There is no
business need to provide any more access or privileges
than they require. One principle in security is to
provide the least access to anyone that is required for
them to perform their work. That is most easily and
effectively done by creating the most restrictive
environment possible and then enabling individual
permissions as they become DEMONSTRABLY required
by an individual or group.

Over the years I've supported many environments that
included software developers. They always think that
they need total access to everything. I've usually been
able to strip developers' system rights to the bone then
enable individual permissions. They usually cry and
whine at first but when their chronic system problems
go away, such as a server crashing three times a week,
then even the developers thank me. You can be
friendly with people while still being firm and frank.
Always show respect for people that you deal with and
make it clear that you are only trying to serve the best
interests of the business. Justify your decisions. That
should be easy if you are making decisions based on
sound reasons. Lastly, if someone overrides your
decisions and the business suffers some calamity
resulting from that don't be shy about approaching the
manager and saying 'I told you so.' emphasising your
concern for the business, not your bruised ego.

Believe me when I say that most of my customers,
whether I was a temp/consultant or a direct employee,
eventually came to highly regard my technical sckills
and judgement. I've developed these guidelines over
the course of a twenty year career. You don't want to
appear to be a facist dictator but you don't want to
appear to be obsequious either. Rather you want your
customer to perceive you as a part of their team,
working with them instead of against them, but still
having the courage to stick up for what you believe.
Being friendly but firm and frank is the best course.
Also, be your own cheerleader. Point out to your
customer when your decisions improved some
situation. Take responsibility when your decisions
turned out badly. You gain your customer's respect
that way which leads to increasing your credibility.
Naturally it helps if you know what you're talking
about. :)

Related Discussions

Related Forums