From owner-freebsd-questions@FreeBSD.ORG Thu Dec 29 10:05:59 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CC81065672 for ; Thu, 29 Dec 2011 10:05:59 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id 06C458FC13 for ; Thu, 29 Dec 2011 10:05:58 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [IPv6:2001:8b0:151:1:fa1e:dfff:feda:c0bb]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.5/8.14.5) with ESMTP id pBTA5off084753 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 29 Dec 2011 10:05:50 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: OpenDKIM Filter v2.4.1 smtp.infracaninophile.co.uk pBTA5off084753 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infracaninophile.co.uk; s=201001-infracaninophile; t=1325153150; bh=g14PjJvdUJluYXRPDQQq0zXQQvbsbxP0taX4ceaSGck=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Cc; b=Ta+RQ8d8ruSCmgDBXhcGGG07ESukJTfeRBF6n9wzo3WA/R4XWT8laGTelDhGXXqb7 etyja/Rz5s0oEWDFkOraD/p3NJv0+Kpw0ez0Ygr5YI5y3jLTtLQx4Fv74KmlUfRx9A 2E6m2LLG79EBs5A/di+aeYXDZxusZhru9PXQ64t0= Message-ID: <4EFC3B76.4060005@infracaninophile.co.uk> Date: Thu, 29 Dec 2011 10:05:42 +0000 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: id=60AE908C Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3B0B9C45C30F92431F34F2A7" X-Virus-Scanned: clamav-milter 0.97.3 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED, AWL, DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk Subject: Re: OT: Root access policy X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 10:05:59 -0000 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--