[
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, 2:08 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 segments 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 segments, let's call them 'segment-N'.
so we back up:
segment-0
segment-1
segment-2
segment-3
These segmentes are marked immutable until day 31
[backup 15, day 16]
so we skip:
segment-0
segment-1
segment-2
segment-3
and backup:
segment-4
segment-4 is marked immutable until day 46
at this point however segment-0..segment-3 are still marked immutable until day
31
[day 31]
On this day backups segment-0..segment-3 become vulnerable and can be deleted,
etc, even though they are needed
to be able to restore from [backup 15]
The segments 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 segmentes 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 segments, let's call them 'segment-N'.
so we back up:
segment-0
segment-1
segment-2
segment-3
These segmentes are marked immutable until day 31
[backup 15, day 16]
so we skip:
segment-0
segment-1
segment-2
segment-3
and backup:
segment-4
segment-4 is marked immutable until day 46
at this point however segment-0..segment-3 are still marked immutable until day
31
[day 31]
On this day backups segment-0..segment-3 become vulnerable and can be deleted,
etc, even though they are needed
to be able to restore from [backup 15]
The segments 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: [email protected]
For additional commands, e-mail: [email protected]
