[ale] OT - SED drive compatibility

[Adrya Stembridge]

NIH requires (among other things) FIPS certified encryption
on data-at-rest for any NIH funded grant/research project.  Our DC is
secure, but it would be technically possible for another admin to
potentially gain access to the rack and our server drives.   This adds
another layer of security.   Maybe overkill?  In any case, it's becoming
policy for many agencies.

On Mon, Sep 8, 2014 at 1:12 PM, Jim Kinney <jim.kinney at gmail.com> wrote:

> Added layer of physical security for HIPAA compliance led to the wholesale
> adoption. Yes, remote access and data theft would occur to a decrypted
> filesystem once it's running. But much of my work often requires encrypted
> data at rest for many system and the performance hit is essentially trivial
> compared to the rest of the system, so it's easy to to keep that as a
> default. The HPC systems have absolutely all security disabled and are
> hidden behind firewalls on private LAN, etc.
>
> It also indicates a level of unsure trust of the physical access to the
> systems. Never had an issue but don't want to be on the wrong end if
> something does happen.
>
> On Mon, Sep 8, 2014 at 12:54 PM, Beddingfield, Allen <allen at ua.edu> wrote:
>
> > I'm curious about why you would encrypt filesystems on servers, if you
> > have control of physical access?  If the server is up and online, the
> > drives would be decrypted, and the files would be accessible by any
> remote
> > exploit.  I'm sure I'm missing a good reason for it, but I haven't had
> > enough caffeine to fully get the brain cranked up today :D
> > --
> > Allen Beddingfield
> > Systems Engineer
> > The University of Alabama
> >
> > ________________________________________
> > From: ale-bounces at ale.org [ale-bounces at ale.org] on behalf of Jim Kinney
> [
> > jim.kinney at gmail.com]
> > Sent: Monday, September 08, 2014 11:46 AM
> > To: Atlanta Linux Enthusiasts
> > Subject: Re: [ale] OT - SED drive compatibility
> >
> > Using LUKS software encryption on a system with 15k RPM drives will be a
> > minimal hit on performance as long as there is adequate RAM and cores to
> do
> > the decryption. A single core is enough and the RAM needs are actually
> > small. A few blocks at a time are fed through for decrypt then passed to
> > buffers for use.
> >
> > I use LUKS on EVERY public facing (and many internal only systems)
> server.
> > The only big caveat is the need to have remote console so the password
> can
> > be entered for key decryption after a reboot.
> >
> >
> > _______________________________________________
> > Ale mailing list
> > Ale at ale.org
> > http://mail.ale.org/mailman/listinfo/ale
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > http://mail.ale.org/mailman/listinfo
> >
>
>
>
> --
> --
> James P. Kinney III
>
> Every time you stop a school, you will have to build a jail. What you gain
> at one end you lose at the other. It's like feeding a dog on his own tail.
> It won't fatten the dog.
> - Speech 11/23/1900 Mark Twain
>
>
> *http://heretothereideas.blogspot.com/
> <http://heretothereideas.blogspot.com/>*
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.ale.org/pipermail/ale/attachments/20140908/45281a05/attachment.html
> >
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20140908/f9108509/attachment.html>