Skip to Content.
Sympa Menu

cacert-sysadm - Re: Development of infrastructure

cacert-sysadm AT lists.cacert.org

Subject: CAcert System Admins discussion list

List archive

Re: Development of infrastructure


Chronological Thread 
  • From: Ian G <iang AT cacert.org>
  • To: cacert-sysadm AT lists.cacert.org
  • Subject: Re: Development of infrastructure
  • Date: Mon, 09 Aug 2010 13:01:05 +1000
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none

Hi Mario and Wytze

Just on this question of audit and future.

On 9/08/10 1:35 AM, Wytze van der Raay wrote:
On 08/07/2010 04:06 PM, Mario Lipinski wrote:

Once there is an audit we can show that the systems are designed
independent and they can be moved out. And not having done so is just a
reason of the resources available by then.

Well, we can show that also now. It depends very much on the auditor
and his/her procedures whether that is considered sufficient or not.


Right, it's a bit of both. The difficulty I saw as once-auditor was that there was sufficient intermingling to make it hard to form a conclusion, without quite stringent testing of the controls.

Things came somewhat to a head for me personally when one access engineer was granted sysadm access to an infrastructure server. Although this is doable, and an Arbitrator OK'd it, it raises questions. It means for example that an access engineer has an ability to SSH into the hop machine, and thence into the internal network. It also means that the person concerned has a reason to be poking around in the rack and reading console messages: to reboot the infrastructure server. By himself.

This puts stress on all the other controls; they have to work, which means they all have to be tested fully. More work for the auditor, but also more stress and bureaucracy for the critical team and the access engineers.

Before hand, we had controls, *plus* no stress, in that the access engineers had no reason to access software, or access hardware without coordination with critical system team. So any access was _a priori_ wrong. These two things worked together well, and made audit "easy".



So we decided the ideal position as having the infrastructure machines outside the SP / BIT / critical team domain completely. Then, the whole above question disappears, *and* we can use our sysadm resources more economically.

Separation is the objective.

Then there is the implementation. We decided we wanted multiple sites, for several reasons:

* the ideal HR situation seems to be a small tightly-knit local team, close to the server.
  * with 2-3 sites, each can do redundancy and backup on a remote site.
* any hosting situation is a big and risky project, so we felt that going for 2-3 would give us more chance of success, with 1-2. This was based on our experiences with the AT-NL transition, that took around 2 years.
  * we want more sysadms, partly so as to feed the critical team.



On the one hand, this was a lot or mostly or entirely my analysis. A future auditor would likely make up his or her own mind. And the board might decide to adjust this.

On the other hand, I don't see the analysis as being fundamentally challenged. The implementation has hit some roadblocks, but that's distinct from the analysis and strategy.

So, options. If you think putting the infrastructure machine outside the firewall, and on the open net .. is a good idea, then I'd agree. That gets rid of all the "software/internet" access issues. It doesn't get rid of the hardware/access temptations though, so I'd also see it as an intermediate step. But an intermediate step is often better than no step.

Also, there are other options: moving the VMs off one at a time to perhaps the Sonance site; talking to HCC; reducing the number of VMs; exploring a TLS/SNI multi-hosting arrangement.



iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature




Archive powered by MHonArc 2.6.16.

Top of Page