[jira] [Comment Edited] (SOLR-15864) Add option for Immutable backups to S3 for Ransonware and Deleteware mitigation

["Michael Joyner (Jira)" <ji...@apache.org>]

    [ 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org