TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Protect your data from ransomware with S3 Object Lock

58 点作者 abuggia将近 3 年前

10 条评论

jis将近 3 年前
A less permanent solution is to use versioned buckets with MFA Delete turned on. You can then cleanup versions if you need to by disabling MFA delete, which requires the MFA to do. So as long as your MFA device is not on-line, then if someone compromises your servers, they cannot disable MFA delete and cannot remove versioned objects.
评论 #32041347 未加载
prirun将近 3 年前
Object Lock may be useful to protect backups from deletion, but ransomware is now relying on the threat of data exposure more, where Object Lock makes no difference:<p><a href="https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;06&#x2F;25&#x2F;ransomware_gangs_extortion_feature&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;06&#x2F;25&#x2F;ransomware_gangs_exto...</a><p>&quot;Increasingly, however, cybercrime rings still tracked as ransomware operators are turning toward primarily data theft and extortion – and skipping the encryption step altogether. Rather than scramble files and demand payment for the decryption keys, and all the faff in between in facilitating that, simply exfiltrating the data and demanding a fee to not leak it all is just as effective. This shift has been ongoing for many months, and is now virtually unavoidable.&quot;<p><a href="https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;06&#x2F;03&#x2F;fbi_cisa_warn_karakurt_extortion&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.com&#x2F;2022&#x2F;06&#x2F;03&#x2F;fbi_cisa_warn_karakur...</a>
评论 #32044646 未加载
josephcsible将近 3 年前
&gt; No one, including AWS can shorten the retention period<p>I don&#x27;t think this is true. Isn&#x27;t it more like you can&#x27;t, and AWS can but promises that they won&#x27;t?
评论 #32041257 未加载
neilv将近 3 年前
I made this a part of the backup schemes at a startup. Everything (GitLab, PostgreSQL, the biz people&#x27;s document&amp;storage SaaSes, etc.) got backed up multiple ways, including to S3 objects with long retention periods.<p>So long as the data wasn&#x27;t corrupted before it hit one of the designated S3 buckets, the risks of the retention periods seemed minor for that startup at the time: basically, having data there that we wanted to delete, but couldn&#x27;t.<p>(For an example risk of not being able to delete, the most likely scenario might be accidentally copying a gazillabytes of objects to the magic bucket that can&#x27;t be emptied for X months, so having to pay for that storage. For a different scenario, the nature of our business, together with our security assurances and practices, meant that we never handled data that would be improper to store there, such that we urgently needed to delete it. In a highly unlikely scenario of an attack putting very evil data there, we&#x27;d have to report the incident to government authorities in any case, and we could effectively cut off our own access to it, while AWS preserves gov&#x27;t access to it.)
ineedasername将近 3 年前
I use backblaze which will backup any modified file and has copies back 30 days, longer if desired. It would be great if there was some way (is there?) To flag if a file was recently encrypted to detect potential ransomware early before backups are corrupted also. Seems like a changed file being backed up could be compared to the previous unencrypted file for this purpose.<p>Of course this would be more complicated if the files were user-encrypted in the first place, but good tools to detect these things asap would have a good market above &amp; beyond antivirus that is more focused on detection of the virus and not a complete packaged of file recovery as well.
评论 #32041231 未加载
tgsovlerkhgsel将近 3 年前
From my understanding, you can&#x27;t delete a bucket that has objects and I assume you can&#x27;t empty a bucket that has locked objects, but what happens if you close the entire account?<p>AWS recommends to use accounts for segmentation, and has APIs to manage accounts (<a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;wellarchitected&#x2F;latest&#x2F;security-pillar&#x2F;aws-account-management-and-separation.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;wellarchitected&#x2F;latest&#x2F;security-...</a>, <a href="https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;cli&#x2F;latest&#x2F;reference&#x2F;organizations&#x2F;close-account.html" rel="nofollow">https:&#x2F;&#x2F;docs.aws.amazon.com&#x2F;cli&#x2F;latest&#x2F;reference&#x2F;organizatio...</a>).<p>There is a 90 day recovery period, but I can think edge cases where this isn&#x27;t enough. There is some data that companies need exactly once a year for financial reporting&#x2F;audits etc. but losing it is seriously expensive. Imagine the person managing that data being disgruntled and closing the account holding the data (and just that data, so the deletion isn&#x27;t noticed) 6 months before the next audit.<p>Can you close an account with locked data in it? If yes, is the data actually deleted, or could the org recover it?<p>Another interesting scenario that could test how reliable the lock is would be a griefer (i.e. an actor that wants to cause damage without profiting from it) who gets access to an organization&#x27;s account, uploads a large amount of data, and locks it. Will Amazon simply keep the data and waive the cost, or will support unlock the data, or will the organization be forced to pay up? The latter two both have interesting implications (compromised support agents and social engineering in the first case, extortion in the second case - think &quot;we have taken over your AWS account and created several paths of access, send XX bitcoin or we&#x27;ll lock this exabyte of data and you&#x27;ll pay $XXXXXXXX in AWS fees, if you start taking away our access or deleting the data we&#x27;ll see before you finish and use one of the remaining accounts to lock the data&quot;).
评论 #32043764 未加载
gregwebs将近 3 年前
One thing missing from this great introduction is how to enforce object lock for new objects. This can be done by setting a default retention mode and period on the bucket and having a bucket policy for s3:PutObject(Retention). It looks like I should do a writeup on this. I am working on tooling to make using Object Lock (to prevent ransomware) more convenient.
m1keil将近 3 年前
Just FYI, you can only enable object lock at bucket&#x27;s creation time. You cannot enable it later on.
评论 #32052727 未加载
mastax将近 3 年前
What happens if you lock objects then stop paying your bill?
评论 #32041262 未加载
djbusby将近 3 年前
Can&#x27;t ZFS do these kinds of things with snapshot?
评论 #32042485 未加载