Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not encrypting at rest seems like a huge oversight, given that your service most likely uses AWS S3 and it is dead simple to turn on encryption. I'm not sure anyone will trust you to store their log data without at least encrypting data at rest.


> I'm not sure anyone will trust you to store their log data without at least encrypting data at rest.

I know something of logs.

Speaking for requirements inside other's logging use cases is pointless given privacy needs vary from use case to use case. While your statement may be factual for some use cases, claiming it's "a huge oversight" is blanket blaming statement across all use cases and thus becomes worthless.

Besides, if you want search for things in the logs, things have to be kept hot and moving unencrypted. That means no at rest encrypted storage for near realtime search use cases.

I wish I had a stick I could hit people with to get them to stop creating double bind arguments. If you really want privacy for your logs, deal with them yourself on your own equipment. If you absolutely have no time to deal with your logs yourself, then get comfortable with privacy issues.


Hmmm, we're using EC2 mainly, not S3. I've seen an option to encrypt disk but haven't researched it fully.


Thanks for the response. You can also encrypt EBS volumes using Amazon's KMS, so I'd research that. It will be an important feature for your potential enterprise customers.


http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncrypti...

It's literally setting a policy on a bucket and a flag on object PUTs if you're not managing the keys yourself.


Yes we do plan to be doing this for S3 archives.


No worries, just pointing it out. Honestly this should be on by default on the AWS side.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: