<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Tape Encryption Best Practices</title>
	<atom:link href="http://www.standalone-sysadmin.com/blog/2009/10/tape-encryption-best-practices/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.standalone-sysadmin.com/blog/2009/10/tape-encryption-best-practices/</link>
	<description>A blog for IT Admins who do everything by an IT Admin who does everything</description>
	<lastBuildDate>Tue, 07 Sep 2010 20:41:25 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Preston de Guise</title>
		<link>http://www.standalone-sysadmin.com/blog/2009/10/tape-encryption-best-practices/comment-page-1/#comment-3406</link>
		<dc:creator>Preston de Guise</dc:creator>
		<pubDate>Tue, 06 Oct 2009 09:44:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.standalone-sysadmin.com/blog/?p=949#comment-3406</guid>
		<description>Each enterprise product offers different levels of support for hardware tape encryption.

NetWorker for instance doesn&#039;t currently support key management for hardware tape encryption. However, so long as the key management is run outside of it (e.g., via the library or the OS), it will work without issue - i.e., the encryption is invisible to it and can be used. I have multiple customers already taking advantage of this.

There are other encryption options - e.g., (formerly Neoscale) &lt;a HREF=&quot;http://www.nu.co.za/node/262&quot; rel=&quot;nofollow&quot;&gt;Thales nCipher&lt;/A&gt; provides black box (or more precisely red box) level encryption at the fibre-channel layer itself. The nCipher device for instance is able to cooperate with many enterprise backup products to allow multiple keys, allows per-volume encryption controls, etc.</description>
		<content:encoded><![CDATA[<p>Each enterprise product offers different levels of support for hardware tape encryption.</p>
<p>NetWorker for instance doesn&#8217;t currently support key management for hardware tape encryption. However, so long as the key management is run outside of it (e.g., via the library or the OS), it will work without issue &#8211; i.e., the encryption is invisible to it and can be used. I have multiple customers already taking advantage of this.</p>
<p>There are other encryption options &#8211; e.g., (formerly Neoscale) <a HREF="http://www.nu.co.za/node/262" rel="nofollow">Thales nCipher</a> provides black box (or more precisely red box) level encryption at the fibre-channel layer itself. The nCipher device for instance is able to cooperate with many enterprise backup products to allow multiple keys, allows per-volume encryption controls, etc.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: pb</title>
		<link>http://www.standalone-sysadmin.com/blog/2009/10/tape-encryption-best-practices/comment-page-1/#comment-3404</link>
		<dc:creator>pb</dc:creator>
		<pubDate>Mon, 05 Oct 2009 12:41:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.standalone-sysadmin.com/blog/?p=949#comment-3404</guid>
		<description>I&#039;ve been watching the same question on ServerFault, and I have pretty much the same opinion.  I think it comes down to this:  tape-level encryption just isn&#039;t a fantastic idea due to key management and potential recovery issues.  

I think that if critical *data* is encrypted, that&#039;s fine.  But encrypt it before it hits the tape.  Besides, you really need to keep tight physical controls on the tape in the first place that should be enough.

Note:  I&#039;ve not read the HP paper, but will take a quick peek. Thanks for the link.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve been watching the same question on ServerFault, and I have pretty much the same opinion.  I think it comes down to this:  tape-level encryption just isn&#8217;t a fantastic idea due to key management and potential recovery issues.  </p>
<p>I think that if critical *data* is encrypted, that&#8217;s fine.  But encrypt it before it hits the tape.  Besides, you really need to keep tight physical controls on the tape in the first place that should be enough.</p>
<p>Note:  I&#8217;ve not read the HP paper, but will take a quick peek. Thanks for the link.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
