Encryption *can* be solved with S3 ... (but you cant run journaling on S3). I have never used a disk encryption solution but key management is key ... sorry the pun. There are many products (free and paid) that can encrypt an entire disk or filesystem and thats probably the way you need to go ... as ML doesnt have at rest encryption built in.
Now if its just a "checkbox" then you needn't really worry about key management because its all BS, just burn the key into your custom AMI in /README.key :). But if you really want security along with that checkbox you need key management that works with a headless system (you cant hire a Amazon worker to run over to the machine and plug in a USB stick). AWS does provide a solution for this .. http://aws.amazon.com/cloudhsm/ There are other providers including Volmetric which also does filessystem encryption I belive http://www.vormetric.com/ THey also have an AWS appliance offering http://www.vormetric.com/advanced-data-security-running-on-aws/resource-center I am not endorsing these - I have never used them, just happen to know someone who works there. From: [email protected] [mailto:[email protected]] On Behalf Of Marc Young Sent: Friday, March 14, 2014 6:44 PM To: MarkLogic Developer Discussion Subject: Re: [MarkLogic Dev General] Data redundancy and encryption at AWS I'm not sure about ephemeral, S3 was attractive, although I've read that the overhead/performance degredations are not worth it. As for encryption, it's a must, our BAA requires HIPAA compliance, so data must be encrypted during transmission and at rest. On Fri, Mar 14, 2014 at 5:29 PM, Michael Blakeley <[email protected]<mailto:[email protected]>> wrote: I've done a fair amount of work with AWS, including failover, but none with disk encryption. As I see it the main scenario in which to guard against host (EC2 instance) failure is when using ephemeral storage. That can be attractive sometimes, and in that case forests should be replicated within a cluster of at least three hosts. In some cases each forest might have two replicas, each on a different instance. With EBS there's less of a case for guarding against host failure. It's fairly straightforward to replace a failed instance without losing the volumes, and the MarkLogic CloudFormation templates should make it automatic. Guarding against host and disk failure is mostly about high availability. If disaster recovery is also important, consider database replication to a different cluster in a different AWS data center - or off AWS, to another cloud provider or to private hardware. In the past, AWS outages have sometimes affected infrastructure that is shared between multiple data centers. If data security is a concern, I would prioritize ordinary hygiene: firewall configuration, cluster communications, and communication with users. Encrypting the disk seems like overkill to me, and is likely to work against any HA strategy because you wouldn't want to store the key in AWS too. Of course you might face an obligation to use disk encryption whether it makes sense or not.... -- Mike On 13 Mar 2014, at 08:22 , Marc Young <[email protected]<mailto:[email protected]>> wrote: > I'm curious what implementations others have made for data redundancy > (failover) for cloud implementations. I understand forest duplication and > failover in the ML engine, but has anyone used this at AWS? We're using > MarkLogic on a single node and the data is stored to a LUKS encrypted mounted > partition. I'm curious if there are any other implementations that are > elegant, such as encrypted GlusterFS, HBase, etc as the filesystem store. I > know this is open ended, I'd just like to know who's done this in production > and what they like about it, or what pointers they'd like to give someone new > to this area. > _______________________________________________ > General mailing list > [email protected]<mailto:[email protected]> > http://developer.marklogic.com/mailman/listinfo/general _______________________________________________ General mailing list [email protected]<mailto:[email protected]> http://developer.marklogic.com/mailman/listinfo/general
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
