[
https://issues.apache.org/jira/browse/SOLR-15864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463816#comment-17463816
]
Michael Joyner edited comment on SOLR-15864 at 12/22/21, 1:54 PM:
------------------------------------------------------------------
Yes, I'm in the situation where we operate on a minimal budget and only have a
cluster at a single zone.
Yes, it is impractical to try and recreate the indexes should the worst happen.
We would be looking at maybe a week, possibly longer.
The problem I see with our current approach is as follows:
[backup 0, day 1]
Backup all indexes, let's call them 'index-N'.
so we back up:
index-0
index-1
index-2
index-3
These indexes are marked immutable until day 31
[backup 15, day 16]
so we skip:
index-0
index-1
index-2
index-3
and backup:
index-4
index-4 is marked immutable until day 46
at this point however index-0..index-3 are still marked immutable until day 31
[day 31]
On this day backups index-0..index-3 become vulnerable and can be deleted, etc,
even though they are needed
to be able to restore from [backup 15]
The indexes which are part of a backup, even if they are already there from a
previous backup, would need to have their immutable date "reset" further out to
prevent this vulnerability.
was (Author: michael-newsrx):
Yes, I'm in the situation where we operate on a minimal budget and only have a
cluster at a single zone.
Yes, it is impractical to try and recreate the indexes should the worst happen.
We would be looking at maybe a week, possibly longer.
The problem I see with our current approach is as follows:
[backup 0, day 1]
Backups up all indexes, let's call them 'index-N'.
so we back up:
index-0
index-1
index-2
index-3
These indexes are marked immutable until day 31
[backup 15, day 16]
so we skip:
index-0
index-1
index-2
index-3
and backup:
index-4
index-4 is marked immutable until day 46
at this point however index-0..index-3 are still marked immutable until day 31
[day 31]
On this day backups index-0..index-3 become vulnerable and can be deleted, etc,
even though they are needed
to be able to restore from [backup 15]
The indexes which are part of a backup, even if they are already there from a
previous backup, would need to have their immutable date "reset" further out to
prevent this vulnerability.
> Add option for Immutable backups to S3 for Ransonware and Deleteware
> mitigation
> -------------------------------------------------------------------------------
>
> Key: SOLR-15864
> URL: https://issues.apache.org/jira/browse/SOLR-15864
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Michael Joyner
> Priority: Major
>
> It would be an extremely useful feature to add to the S3 backup repository
> (and possibly others, if supported) an option to be able to mark all uploaded
> objects as immutable for a defined period of time.
> If an file in the current backup already exists in the repository, simply
> extend its immutable until time.
> While I'm thinking of basic Ransomware and Deleteware mitigation, this also
> could be used for Compliance mode.
> Currently I'm backing up to a bucket with automatic locking, but this doesn't
> handle the situation where an already existing uploaded index file immutable
> until time ends earlier - leaving a timestamp gap and eventual immutable
> state no longer being active on some index files as compared to others for a
> particular backup opening up an avenue for attack.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
