Date: Thu, 29 Dec 2011 10:05:42 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@freebsd.org Subject: Re: OT: Root access policy Message-ID: <4EFC3B76.4060005@infracaninophile.co.uk> In-Reply-To: <CA%2BNe_iJfFK43CE%2BL2LHcqNSmv7AmRDYyAu4pXGFpd3QB%2By3p2w@mail.gmail.com> References: <CA%2BNe_iJfFK43CE%2BL2LHcqNSmv7AmRDYyAu4pXGFpd3QB%2By3p2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3B0B9C45C30F92431F34F2A7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 29/12/2011 09:01, Irk Ed wrote:
> For the first time, a customer is asking me for root access to said
> customer's servers.
>=20
> Obviously, I must comply. At the same time, I cannot continue be
> accountable for those servers.
>=20
> Is this that simple and clear cut?
>=20
> Assuming that I'll be asked to continue administering said servers, I g=
uess
> I should at least enable accounting...
>=20
> I'd appreciate comments/experience/advice from the wise...
Where I used to work, customers were given root level access to their
servers by default. We did insist on a secure access method using SSH
keys and we also insisted that root level access was allowed only to
specific named people each using their own SSH key (so you always had to
login as an unprivileged user before getting root access). This allowed
a good level of audit trail and the ability to identify exactly who had
done what.
On the whole, this worked well. Most customers are after all motivated
to keep their servers running well and securely and would very rarely
use their root level access, since we would provide all the routine
management functions as part of the service. Occasionally there would
be customers that we pretty much as capable as we were, and for those we
were happy to let them do their own thing so long as they conformed to
our security standards. Occasionally there were the odd customers who
thought they were much more capable than they were. Generally there
would be a cock-up, which we would then sort out at the customers
expense, after which things tended much more towards the customer
leaving it all to us. (Usually this would happen during the system
setup or testing phase so no embarrassing service outages.)
On the other hand, we tended not to give customers any access to
firewalls or network switches or other network infrastructure, nor
indeed to monitoring or backup or other adjunct services.
The important thing, especially if you have stringent service level
guarantees in your contracts, is to disclaim any liabilities due to
outages or other problems caused by customer action. Which implies that
it is vital to have good audit data that can identify the individual
responsible for any action. You're also justified in raising your
prices to cover yourself against potential losses (reputational or
otherwise) due to customer actions.
Your mileage may vary -- the clients at that job were mostly finance or
similar companies and tended to have quite formal change-management
regimes in any case. Other sectors may be a lot more gung-ho...
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matthew@infracaninophile.co.uk Kent, CT11 9PW
--------------enig3B0B9C45C30F92431F34F2A7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk78O30ACgkQ8Mjk52CukIxNlACePEv+j27T6dVklZxr+5XtvBnp
5/IAn3A9wOUY59+bcyoE79YNLhuSVcb7
=HNbk
-----END PGP SIGNATURE-----
--------------enig3B0B9C45C30F92431F34F2A7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EFC3B76.4060005>