Restic: 비대칭 백업 지원

이전 토론의 간략한 요약:

• 이러한 서버가 손상된 경우 이메일 서버의 백업 또는 로그 데이터의 원격 백업에 유용합니다. 서버에서 파쇄된 민감한 데이터가 백업에 있을 수 있으며 이러한 기록 데이터에 대한 공격자의 액세스를 거부할 수 있는 것이 유용할 수 있습니다. 추가 전용/읽기 전용/읽기-쓰기 액세스를 적절하게 구성할 수 있는 기능 시스템을 갖춘 "블롭 네트워크 서버"를 갖는 것이 유용할 수 있다는 것과 동시에 논의되었습니다. 비대칭 암호화를 사용하면 기능을 발행하기 위한 _또 다른_ 세트의 대칭 키가 필요하지 않으며 기능 시스템의 구현도 단순화할 수 있습니다.
• 여러 머신이 있는 설정에서 _one_ 백업 키를 사용하여 다수의 대칭 키를 관리하지 않고도 여러 백업 데이터 세트에 액세스할 수 있습니다. Daniel Bernstein의 Curve25519와 같은 암호 시스템을 사용하는 경우 이러한 키는 암호에서 파생될 수 있습니다. 즉, 하나의 마스터 암호를 사용하여 (잠재적으로 많은) 여러 보안 도메인에서 생성된 백업을 관리할 수 있습니다. 물론 n 대칭 키와 암호화된 키 저장소로 비슷한 것을 얻을 수 있습니다.

@heipei 참고로 이 호를 구독하고 싶을 수도 있습니다.

가장 분명하고 시급한 사용 사례는 프로덕션 시스템(백업 클라이언트)에 침입하여 그곳에서 restic을 사용하는 방법을 알고 있는 공격자가 백업을 지우지 않는 것입니다.

비대칭 암호화를 사용하는 것만으로는 거의 불가능합니다. 여기서 요점은 서버에 침입한 공격자가 오래된 백업 콘텐츠(메타데이터일 필요는 없음)를 사용할 수 없어야 한다는 것입니다.

데이터 기밀성 ( write-only )은 비대칭 암호화를 구현하여 이러한 시나리오에서 달성할 수 있습니다.

데이터 무결성 은 약간 다른 짐승입니다.
비대칭 암호화(및 일회성 서명 체계)를 사용하여 주어진 데이터 세트가 변경되지 않았음을 증명할 수 있지만 완전한 제거 또는 교체를 막을 수는 없습니다. 이는 append-only (일부 부품의 경우 read-only 인 스토리지 시스템이 필요한 문제입니다.
ssh와 같은 백엔드를 사용하여 *nix에서 구현하기가 비교적 간단한 임의 액세스 제어 덕분에( chmod , chown , chattr +i , chattr +a 액세스 정책을 구성합니다). append-only 백업은 공격자가 읽지 못하도록 암호화할 필요조차 없지만(예를 들어 rsyslog 가 수행하는 작업의 일부임) 이는 갑자기 백업 서버를 흥미로운 대상으로 만들고, 민감한 데이터를 더 많은 장치에 복제한다고 해서 데이터 기밀 을 유지할 가능성이 정확히 높아지지는 않습니다.

비대칭 암호화를 구현하면 사람들이 멍청하고 신뢰할 수 없는 시스템에서 이러한 종류의 백업을 수행할 수 있습니다. restic 의 핵심 중 하나인(개선된 중복 제거 및 기타 모든 좋은 기능은 제외) 이 설명이 내 요점을 조금 더 명확하게 해주기를 바랍니다.

이것은 https://github.com/restic/restic/issues/187#issuecomment -101974306에 설명된 두 가지 경우에 대해 관심이 있습니다. 이 스레드를 구독하고 있습니다.

데이터 무결성 관련: AFAIK, IAM 자격 증명에 PutObject 및 GetObject 권한 DeleteObject 는 보류하여 Amazon S3에서 append-only 동작을 달성할 수 있습니다 PutObject 허가.

데이터 기밀성 과 관련하여 대칭 암호화를 사용하여 활성화된 공격 시나리오를 언급하고 싶었습니다.
피해자가 restic 를 사용하여 백업을 수행하는 시점에서 공격자가 피해자의 사용자 계정을 제어할 수 있는 경우 그는 다음을 수행할 수 있습니다.

• 피해자의 restic 키 훔치기
• 피해자의 IAM 자격 증명/sftp 로그인/...

그런 다음 공격자는 피해자의 시스템에서 공격의 흔적을 즉시 지워 탐지 가능성을 낮출 수 있습니다. 그가 원격 스토리지 시스템에 대한 레스트릭 키와 자격 증명을 훔쳤기 때문에 피해자는 (백업된) 향후 데이터를 그에게 편리하게 전달할 것입니다. 공격자는 원격 스토리지 시스템에서 때때로 새로운 백업을 다운로드하고 해독하기만 하면 됩니다. 시각.

비대칭 암호화는 피해자가 백업을 오프라인으로 복원하기 위한 키를 저장할 수 있도록 하여 이를 방지하는 데 도움이 될 수 있습니다.

데이터 무결성: AFAIK와 관련하여 IAM 자격 증명에 PutObject 및 GetObject 권한만 부여하고 DeleteObject 권한은 보류하여 Amazon S3에서 추가 전용 동작을 달성할 수 있습니다.

불행히도 PutObject 는 이전에 업로드한 파일을 덮어쓸 수 있는 권한도 제공합니다. 그렇다면 완전한 데이터 무결성이 아닐 수 있습니까?

비대칭 암호화는 yubikey와 같은 OpenPGP 키의 사용도 허용합니다.

오늘 나는 restic에서 비대칭 암호화에 대한 지원을 원하지 않지만 저장소에 키를 저장하지 않도록 지원한다는 것을 깨달았습니다. 비대칭 암호화를 효율적으로 사용한다는 것은 restic이 리포지토리를 읽을 수 있는 능력 없이 새 백업을 업로드할 수 있다는 것을 의미한다는 것을 이해합니다. 이는 매우 까다롭습니다.

따라서 저에게는 대칭 키를 제한 없이 처리할 수 있고 복잡한 KDF를 사용하더라도 저장소에 어떤 방식으로든 업로드되지 않으면 괜찮을 것입니다.

제 사용 사례는 여러 서버의 시스템 관리자입니다.

비대칭 백업은 공격자가 모든 데이터(백업 포함)를 악의적으로 파괴(또는 랜섬웨어 암호화)하는 서버 손상 시나리오에서 백업을 보호하는 유일한 방법입니다.

이것은 rdiff-backup에 --restrict-update-only 옵션이 있는 것과 유사한 추가 전용 스토리지 계층 또는 서버 데몬을 통한 서버 측 지원이 필요합니다. 현재 저는 백업 서버(sftp를 통해 액세스)에 있는 백업 리포지토리의 읽기 전용 스냅샷을 사용하여 이 문제를 해결하고 있습니다.

(아마도 관련) : 추가 전용하여 통해 리눅스에 달성 할 수 append-only 와 함께 디렉토리 (비활성화 링크 해제)에 플래그 immutable 파일에 플래그. 이러한 플래그를 설정하는 명령은 각각 chattr +a /path/to/directory 및 chattr +i /path/to/directory/myfile01 입니다.

제 사용 사례는 #533 - 무인 백업입니다. 거기에 언급된 바와 같이 비대칭 암호화는 이를 수행하는 방법 중 하나일 뿐이지만 문제에 대한 첫 번째 명백한 해결책처럼 보입니다.

repo가 ​​원격 서버에 있는 시나리오에서 repo의 로컬 명령만 잊어버리거나 정리할 수 있어야 합니다.

나머지 백업은 복원/백업 권한만 있는 해당 시스템의 고유 키로 연결해야 합니다.

repo가 ​​원격 서버에 있는 시나리오에서 repo의 로컬 명령만 잊어버리거나 정리할 수 있어야 합니다.

이것은 repo 수준에서 파일 삭제/수정에 대한 액세스를 제한하여 수행해야 합니다. 나는 restic이 이러한 권한을 관리하는 것이 범위를 벗어났다고 생각합니다(안전하지도 않습니다). 결국 누군가는 repo 또는 심지어 키까지 삭제할 수 있으며, 나머지 클라이언트가 해당 작업을 허용했는지 여부에 관계없이 전체 repo를 쓸모없게 만들 수 있습니다.

서버를 해킹하는 누군가에 의해 백업 데이터가 파괴되는 것을 방지하는 것과 관련하여: rest-server는 최근에 정확히 이것을 방지하는 PR https://github.com/restic/rest-server/pull/28 을 통해 "추가 전용 모드"를 얻었습니다.

제 사용 사례는 많은 시스템을 동일한 리포지토리에 백업하여 모든 시스템에서 중복 제거의 이점을 얻지만 공격자가 다른 시스템의 백업을 읽을 수 없도록 하는 한 시스템(및 백업 스크립트)의 절충안입니다.

내가 찾고 있는 기능은 시스템이 쓰기(백업) 및 읽기(복원)를 가능하게 하지만 어떤 관리도 할 수 없는 "백업" 키를 갖는 것입니다(예: 정리, 키 추가 또는 다른 키, (사용자) 또는 $backup_key 와 연결되지 않은 스냅샷. (백업 시간을 비교해서 부채널 공격이 가능할 수도 있겠지만, 데이터의 존재를 알 수 있다면 나에게는 상관없지만, 내 데이터를 랜섬웨어하거나 다른 사용자를 볼 수 없다는 것뿐입니다.) 예상합니다. 자신의 암호를 롤포워드할 수 있는 백업(전용) 키 보유자. 따라서 michbsd의 요청과 달리 권한 있는 키가 있는 로컬이 아닌 컴퓨터에서 관리할 수 있습니다. (SELinux를 몇 년 동안 사용해 온 저는 이제 MAC의 세분화된 기능을 좋아합니다.) 읽어주셔서 감사합니다. (자체 문제가 있는 경우 죄송합니다.) 이 기능을 사용하면 #RasticKillsRansomware

이 기능으로 #RasticKills랜섬웨어

일반적으로 풀 지향 백업(푸시 지향 백업과 반대)은 랜섬웨어를 해결합니다. 맞나요? :)

가능하지만 원격 액세스를 제공하고 또 다른 공격 벡터를 추가합니다. 내가 설계한 방법 백업 서버는 데이터를 보존하기 위한 것이며 내 프로덕션 환경에 액세스해서는 안 됩니다. 기능 영역의 명확한 경계.

Restic은 백업 저장소에서 직접 작동하도록 설계되었기 때문에 Restic이 솔루션이 아니라고 생각합니다.

아마도 당신은 일종의 중개자 서버로 뭔가를 할 수 있을 것입니다. 프로덕션 머신에서 tarball을 서버에 업로드하도록 한 다음 다른 시스템에서 tarball을 다운로드하고 추출한 다음 콘텐츠를 로컬로 백업하도록 합니다. 양쪽은 중간 서버에만 액세스할 수 있습니다. Restic을 수정하지 않고도 매우 간단하게 수행할 수 있습니다. 수신 전용 Restic 모드의 버그로 인해 백업이 손상된 백업 클라이언트에 취약해질 수 있으므로 아마도 더 안전하고 강력할 것입니다.

내가 찾고 있는 기능은 시스템이 쓰기(백업) 및 읽기(복원)를 가능하게 하지만 어떤 관리도 할 수 없는 "백업" 키를 갖는 것입니다(예: 정리, 키 추가 또는 다른 키, (사용자) 또는 $backup_key 와 연결되지 않은 스냅샷. (백업 시간을 비교해서 부채널 공격이 가능할 수도 있겠지만, 데이터의 존재를 알 수 있다면 나에게는 상관없지만, 내 데이터를 랜섬웨어하거나 다른 사용자를 볼 수 없다는 것뿐입니다.) 예상합니다. 자신의 암호를 롤포워드할 수 있는 백업(전용) 키 보유자. 따라서 michbsd의 요청과 달리 권한 있는 키를 사용하여 로컬이 아닌 컴퓨터에서 관리할 수 있습니다. (SELinux를 몇 년 동안 사용해 온 저는 이제 MAC의 세분화된 기능을 좋아합니다.) 읽어주셔서 감사합니다. (자체 문제가 있는 경우 죄송합니다.) 이 기능을 사용하면 #RasticKillsRansomware

이것이 당신이 원하는 것이 아닐 수도 있지만 rest-server 를 살펴볼 수 있습니다. 기존 백업의 삭제 및 수정을 방지하는 추가 전용 모드가 있습니다.

이것이 당신이 원하는 것이 아닐 수도 있지만 rest-server를 살펴볼 수 있습니다. 기존 백업의 삭제 및 수정을 방지하는 추가 전용 모드가 있습니다.

그런게 있는지도 몰랐습니다. NS:

여기에 버리고 싶은 두 가지 구조적 요소(및 약간 다른 공격자 모델)가 있습니다.

현재 restic은 (대부분) "멍청한" 저장소(local, s3, b2, gcs, azure, REST 서버 --append-only 제외)와 상호 작용합니다. 백엔드에서 데이터를 저장, 나열, 가져오기 및 삭제할 수 있습니다. 이는 백업에 필요하므로 백엔드에 액세스하는 데 필요한 자격 증명이 있어야 합니다. 반면, restic은 거의 모든 스토리지를 사용할 수 있으며 제한 사항이 거의 없습니다. 단점은 공격자가 서버에 액세스할 수 있게 되면 백엔드 액세스를 위한 자격 증명과 나머지 암호를 쉽게 추출하여 모든 가능성을 제공할 수 있다는 것입니다. 리포지토리에서 기록 데이터 해독, 데이터 수정, 전체 리포지토리 삭제.

비대칭 암호화를 추가할 때 이러한 상황에서 공격자의 유일한 차이점은 저장소에서 기록 데이터를 해독할 수 없다는 것입니다. 다른 모든 것, 특히 모든 데이터 삭제는 여전히 가능합니다. 따라서 "비대칭 암호를 추가하는 것"이 ​​전부는 아닙니다.

다른 아이디어는 "멍청한" 저장소에 직접 액세스하지 않고 사용자 지정 서버 구현을 통해 간접적으로 액세스하는 것입니다. 우리는 이 아이디어를 가지고 놀았고 REST 서버에 대한 --append-only 옵션을 추가했습니다. 이 옵션은 로컬 하드 디스크의 "멍청한" 저장소에 액세스하기 위한 "어댑터"로 볼 수 있습니다. REST 서버가 반드시 필요한 것은 아니지만 아이디어를 개선하는 방법에 대한 몇 가지 아이디어가 있습니다.

예를 들어, 한 쌍의 파일 디스크립터(예: stdin/stdout)를 통해 말하는 백엔드에 대한 프로토콜을 정의하고 싶습니다. 그런 다음 sftp 백엔드에서 하는 것처럼 원격 시스템에서 SSH를 통해 실행되는 프로그램에서 이를 구현할 수 있습니다. 그런 다음 서버 구현은 데이터를 저장할 위치(로컬, s3, b2 등)와 적용되는 제한 사항(예: "오래된 데이터 읽기만 추가 또는 새 데이터 추가"만 추가)을 결정할 수 있으며, 잠금 파일 외에는 삭제할 수 없습니다. 예를 들어 특정 사용자 계정 또는 SSH 키를 사용하여 SSH를 통해 로그인할 때 ForceCommand 를 통해 시작할 수 있습니다.

"멍청하지 않은" 저장소만 있으면 공격자가 저장소에서 데이터를 읽는 데 도움이 되지 않지만(적어도 저장소 형식을 변경하지 않고는 아님) 저장소의 모든 데이터를 삭제하는 것은 방지할 수 있습니다.

따라서 결론적으로 백업을 위해 restic을 사용하는 서버를 인수하는 공격자로부터 가장 잘 방어하려면 두 가지(비덤 스토리지 및 비대칭 암호화)를 모두 구현해야 한다고 생각합니다. 장기적인 목표입니다 :)

찾기 쉽도록 이 텍스트를 이 호의 첫 번째 댓글에 복사하겠습니다.

예, 이에 대해 더 생각해 보면 비대칭 암호화가 인수를 방어하는 데 그다지 유용하지 않다는 데 동의합니다. 무인 백업(#533)에 더 유용합니다.

기본 통신 프로토콜을 사용하는 것이 유용할 수 있지만 현재 REST 서버를 통해 얻을 수 있는 것이 무엇인지 잘 모르겠습니다. 확장할 수 있습니까? 클라이언트 - 서버 "독점"(에서와 같이, 보 전용) 프로토콜이있다 그리고 고객을위한 몇 가지 제한을 구현할 수 : 다락방 / 보그 그런 식으로 갔다. 그리고 예, 이것은 ForceCommand 및 "borg serve" 제한 플래그에 의존 합니다. borg 문서에는 이에 대한 몇 가지

물론 손상된 클라이언트로부터 백업을 보호하는 가장 자연스러운 방법은 클라이언트가 자체적으로 백업을 수행하도록 허용하지 않고 대신 서버가 백업에서 파일을 가져오도록 하는 것입니다. 밤에 당신의 컴퓨터에서 본질을 빨아들입니다", 그 유명한 문구를 기억하는 사람들을 위해). borg에서도 이를 수행하는 잘 문서화되거나 우아한 방법이 없는 것 같습니다. FAQ 는 주제에 대한 토론으로 https://github.com/borgbackup/borg/issues/900 을 가리킵니다. 여기에서 이것은 #299에서 추적되며 아직 여기에 언급되지 않았습니다.

간단히 말해서 비대칭 암호화 지원의 초점을 단순하게 유지하겠습니다. 즉, 오프사이트 키 저장 및 자동화된 백업을 더 쉽게 만들 수 있습니다. 손상된 클라이언트를 보호하는 다른 방법이 있으며 풀 지원이 가장 흥미로운 방법이라고 생각합니다. 사실, 내 최적의 백업 솔루션에서는 모든 클라이언트가 백업을 중앙 서버로 푸시한 다음 주 백업 서버에서 오프사이트 서버 를 가져옵니다. 이 방법:

1. 백업 서버는 모든 머신에 대한 루트 액세스가 필요하지 않습니다.
2. 그러나 백업을 엉망으로 만들 수 있는 경우에도 머신의 손상은 여전히 ​​복구할 수 있습니다.

나는 실제로 이 문제가 "클라이언트 인수로부터 보호하고 싶습니다"로 바뀌었다는 것이 이상하다는 것을 알게 되었습니다. 아마도 우리는 여기서 문제와 솔루션을 혼동하고 있는 것 같습니다. :)

안녕하세요,

이 문제는 비대칭 암호화 백업에 관한 것이 아니라 다양한 공격 벡터에 관한 것 같습니다.
코드를 읽지 않았기 때문에 정말 순진한 질문이 있지만 제 사용 사례는 대부분 비밀 키를 공개하지 않고 데이터를 백업할 수 있는 것입니다(백업 소유자의 오프라인 개인 키의 공개 키를 사용하여). 해당 사용 사례의 경우 구현하기 쉽습니까?

주제에 대한 나의 이해는 현재 모든 blob이 동일한 키로 암호화되고 훌륭하게 작동한다는 것입니다.
OpenPGP가 작동하는 방식으로 비대칭 암호화를 사용하는 경우 만들어진 각 스냅샷은 공개 키로 암호화된 대칭 키를 생성하고 저장소에 추가합니다. 그러나 문제는 중복 제거 대상과 백업 대상을 찾을 수 있으려면 먼저 정보를 읽을 수 있어야 하므로 개인 키도 필요하다는 것입니다. 맞나요?
그렇다면 지식이 전혀 없는 증거가 그러한 맥락에서 도움이 될 수 있습니까?

@dolanor 이 문제에 새로운 사용 사례나 질문을 추가하지 마세요. 질문은 포럼 을 사용하세요. 또한 구현 세부 사항에 대해 이야기하기에는 너무 이르다.

첫 번째 게시물의 요약을 업데이트했습니다. 그 동안 rclone 백엔드가 추가되었으며 이는 위에서 설명한 "어댑터"로 사용할 수 있으며 SSH를 통해 액세스할 수 있습니다.

단점은 공격자가 서버에 액세스하면 백엔드 액세스를 위한 자격 증명과 나머지 암호를 쉽게 추출할 수 있다는 것입니다.

이것이 오타이기를 바랍니다. 여기 암호화된 키 파일 자료가 있습니다. 그렇지 않습니까? 서버에 액세스하는 공격자가 일반 텍스트 암호에 액세스할 수 없기를 바랍니다. 그들이 할 수 있는 최악은 저장소에 대한 마스터 암호화 및 인증 키를 해독하는 데 사용되는 "사용자 암호"를 무차별 대입하거나 추측하는 것입니다.

그것이 맞다면 요약을 다시 변경하여 명확히 할 것을 강력히 권장합니다. 그렇게 언급하면 ​​확실히 나빠 보이기 때문입니다. :)

서버에 액세스하는 공격자가 일반 텍스트 암호에 액세스할 수 없기를 바랍니다. 그들이 할 수 있는 최악은 저장소에 대한 마스터 암호화 및 인증 키를 해독하는 데 사용되는 "사용자 암호"를 무차별 대입하거나 추측하는 것입니다.

정확한 시나리오에 따라 다릅니다. 수동으로 비밀번호를 입력하는 경우 맞습니다. 반면에 예약된 자동 백업을 수행하는 경우 "사용자 암호"는 서버의 어딘가에 저장되어야 합니다.

그리고 물론 공격자는 입력된 암호를 유출하는 것으로 Restic 바이너리를 교체하고 사용자가 암호를 입력할 때까지 기다릴 수 있습니다. 손상된 시스템을 신뢰할 수 없습니다.

"사용자 암호"는 서버의 어딘가에 저장되어야 합니다.

"서버"란 "데이터를 저장하기 위해 실행 중인 시스템" 또는 "백업에서 데이터를 수신/저장하는 시스템"을 의미합니까?

다소 모호하고 내 우려의 원인: 백업 클라이언트 (우리가 백업 중인 시스템 중 일반 실행 중임)가 일반 텍스트로 된 암호를 갖고 있다는 사실은 개의치 않습니다. 어쨌든 전체 데이터 세트가 있으므로 손상되면 데이터는 어쨌든 타협. 하지만 백업 서버 가 일반 텍스트에 액세스할 수 없기를 바랍니다!

"서버"란 "데이터를 저장하기 위해 실행 중인 시스템" 또는 "백업에서 데이터를 수신/저장하는 시스템"을 의미합니까?

우리가 실행 중인 시스템은 데이터를 저장하는 데만 사용됩니다.

나는 당신의 요점을 알았습니다. 당신 말이 맞아요, 그것은 모호합니다. 내가 Restic의 모델에 대해 알고 있는 모든 것에서 얻은 나의 이해는 당신의 것과 동일합니다. 나는 그것에 대해 확신하지만 당신이 원하는 확실한 확인을 드릴 수는 없습니다.

요약에는 REST 서버에 대한 --append-only 옵션이 언급되어 있습니다. 아마도 이것이 유일하게 공식적으로 권장되는 추가 전용 백업 방법으로 남아 있어야 하지만 다른 접근 방식을 설정하는 방법을 파악하는 데 도움이 되도록 일반 작업을 위해 쓰기 가능해야 하는 나머지 파일을 문서화하는 것이 좋습니다.

나는 믿습니다 restic backup 일하는 것이 괜찮 경우 data , index , keys 및 snapshots 허용 파일 생성하지만 수정 또는 삭제 ( config 도 보호됨). 그러나 locks 저장소가 영구적으로 잠기지 않도록 삭제를 허용해야 한다고 생각합니다. 또한 일부 추가 전용 구현(ext4 및 xfs 파일 시스템의 속성과 같은)은 재귀적이지 않으므로 data 의 256자 하위 디렉터리를 먼저 미리 생성한 다음 속성을 다음과 같이 지정해야 합니다. 그들에 설정됩니다.

S3와 같은 일부 백엔드는 추가 전용을 지원하지 않지만 동일한 효과를 얻을 수 있는 객체 버전 관리를 지원합니다. 그러나 이를 위해서는 액세스 제어 모델을 주의 깊게 확인해야 합니다. 예를 들어 B2에는 객체 버전 관리를 허용하는 수명 주기 규칙이 있지만 B2에 백업하는 데 필요한 API 키는 수명 주기 규칙을 수정할 수 있는 기능이 있습니다(B2에는 아직 많은 권한 시스템이 없습니다).

제쳐두고: 내가 놓친 것이 있을 수 있지만 비대칭 암호화가 클라이언트를 손상시킨 공격자로부터 기록 데이터를 보호하는 것이라면 우선 순위가 낮은 것처럼 보입니다. 있으면 좋겠지만 대부분의 경우 현재 데이터가 이전 버전보다 더 가치가 있습니다(가끔 중요한 것이 실수로 백업, 삭제되지만 제거되지는 않지만).

@willsALMANJ 좋은 관찰입니다. S3의 경우 주어진 스냅샷을 복원하는 데 필요한 Blob의 일관된 보기를 가져올 수 있도록 이의제기 버전을 기록할 수 있는지 궁금합니다.

Re: 마지막 단락:

• 비대칭 암호화의 주요 이점은 언급한 "이력 내용 암호 해독" 시나리오 외에 개별 키를 프로비저닝할 필요 없이 동일한 백업 저장소에 여러 독립 머신의 백업을 저장할 수 있다는 것입니다(이를 위해서는 매번 백업 키를 어딘가에 저장해야 합니다). 새 클라이언트 시스템을 설치하십시오). 공유 키를 사용하면 client1이 client2의 데이터를 읽을 수 있는 성가신 위협 시나리오가 발생합니다. 이는 이상적이지 않습니다.

@ fd0 파생된 공유 비밀로 HMAC 주소 지정을 사용하는 비대칭 암호화에 대한 적절한 체계가 있다고 생각합니다. 또한 데이터 누출이 없는 서버 측 가비지 수집에 대한 몇 가지 아이디어가 있습니다. 관심이 있는지 확실하지 않지만 관심이 있다면 그것에 대해 이야기하고 싶습니다.

여기에서 누락된 것이 있는지 모르겠지만 S3 스토리지에서 이 정책 설정으로 restic을 성공적으로 실행하고 있습니다. 공격자가 데이터를 읽는 것을 막지는 못하지만 삭제하는 것은 막습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

그런 다음 prune/forget 명령은 쓰기 권한이 있는 신뢰할 수 있는 장치에서 실행됩니다. 또한 모든 restic 저장소에 두 개의 키를 만듭니다. 하나는 서버용이고 다른 하나는 신뢰할 수 있는 장치용이므로 신뢰할 수 있는 장치가 공격자를 잠글 수 있습니다(그러나 공격자는 키/*에서 삭제할 수 없기 때문에 잠글 수 없습니다).

편집: 죄송합니다. 이 문제가 이미 논의되었음을 간과했습니다. 이 스레드를 가로채고 싶지 않았습니다.
PutObject는 실제로 개체를 덮어쓸 수 있으므로 백업을 보호하는 솔루션이 아닙니다 .

@freswa 저는 S3 전문가가 아니므로 이것이 정확하다고 확신할 수 없지만 이 토론에서 위에서 언급한 요점은 PutObject 권한을 사용하여 데이터를 덮어쓸 수 있다는 것입니다. 삭제하면서. 위의 내 게시물에서 개체 버전 관리를 사용하여 이 문제를 해결할 수 있다고 언급했습니다(백업 시스템에 버전 삭제 액세스 권한을 부여하지 않음).

@andrewchambers 저는 다른 것들로 인해 약간 휩쓸렸습니다. 일단 이것을 실제로 구현하게 되면 여러분의 아이디어에 대해 이야기해 봅시다! 예, 관심이 있습니다 ;)

따라서 이 문제는 백엔드 스토리지에 대한 액세스 구성이 아니라 (결국) 비대칭 백업을 구현하는 것에 관한 것입니다. 감사 해요! :)

@fd0 이것이 내가 의미하는 바를 설명하기를 바랍니다. https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : 아직 쓰기 전용 문제가 발생하지 않은 경우(사이트에서 언급) https://github.com/ncw/rclone/issues/2499입니다.

@andrewchambers 적어 주셔서 감사합니다. 실제 구현이 어떻게 보이는지 매우 궁금합니다. 블로그 게시물에서 흥미로운 부분이 공개되었습니다. :)

나는 무료 소프트웨어 백업 프로그램의 영역에 또 다른 경쟁자가 있다는 것을 좋아합니다. 사용자에게 더 많은 옵션을 제공하는 것은 항상 좋습니다!

따라서 두 가지 git 저장소 암호화 메커니즘을 사용하여 흥미로운 병렬 작업을 수행할 수 있습니다.

한쪽에는 git-crypt가 있습니다 . 이것은 git smudge/clean 필터 를 사용하여 blob 저장소와 체크아웃된 복사본 사이의 파일을 (각각) 암호화/복호화합니다. 이것은 잘 작동하고 상당히 최적이지만 한 가지 눈에 띄는 구멍이 있습니다. git 커밋 자체는 암호화되지 않고 Blob의 내용만 암호화됩니다. 즉, 파일 이름, 커밋 로그, 작성자, 날짜 및 기타 메타데이터가 모두 일반에 저장됩니다. 이는 많은 사용 사례에 적용되지 않으며 일부 비트(전부는 아님)를 암호화하려는 공용 저장소가 있는 경우에만 효과적입니다.

다른 쪽에는 git-remote-gcrypt가 있습니다 . git 원격 도우미 프로토콜 을 사용하여 서버에서 전송되는 모든 것을 암호화합니다. 그러나 특수 원격이 작동하는 방식으로 인해 전체 저장소가 실행할 때마다 다시 암호화되기 때문에 매우 비효율적입니다.

자, 이것들은 git 특정 구현 문제이지만 여기에서 얻을 수 있는 문제에 잘 매핑되어 있다고 생각합니다. 어쩌면 나는 여기에서 내 깊이를 완전히 벗어 났고이 평행선은 관련이 없지만 여기에서 관심이있을 수 있다고 생각했습니다 ...

제쳐두고, 현재 (아마도) 다소 쉽게 구현할 수 있는 중간 지점이 있습니다. 키가 저장소 외부에 저장되도록 허용합니다.

해결되는 공격 벡터 중 하나는 공격자가 키 암호를 손에 넣은 다음(키가 저장소에 저장되기 때문에) 키를 쉽게 해독할 수 있다는 것입니다.

키 파일이 저장되는 별도의 키 디렉토리 지정을 허용하면 어떻게 될까요? 이 디렉토리는 백업을 수행해야 하는 각 시스템에 로컬로 저장될 수 있으며, 자체적으로 다른 클라우드 제공자 또는 콜드 오프라인 저장을 위한 QR 코드(~500바이트는 QR 인코딩하기에 충분히 작음)에 백업될 수 있습니다. 예를 들어 안전 금고에서.

암호화된 키가 클라우드 공급자와 접촉하지 않으면 공격 벡터가 완전히 사라집니다. 예를 들어 키는 물리적 구내에서 손상되거나 맬웨어로 유출되어야 합니다.

이것은 _Restic에서 이미 수행할 수 있습니다_ 리포지토리의 로컬 복사본이 유지되는 경우 -- rclone을 실행할 때 신뢰할 수 없는 원격으로 동기화되는 키 디렉토리를 제외하기만 하면 됩니다. 이것은 로컬 복사본이 없고 restic이 신뢰할 수 없는 원격 장치와 직접 상호 작용하는 경우 수행할 수 _없습니다.

단일 책임 원칙을 적용하고 2가지 작업으로 분류해야 한다고 생각합니다.

1. 암호 해독으로부터 데이터를 안전하게 보호하십시오.
2. 무단 삭제 작업으로부터 데이터를 안전하게 보호합니다.

데이터 안전의 두 가지 측면입니다. 기술적으로 그들은 서로 의존할 필요가 없습니다.

(1)의 경우 "단순히 비대칭 암호화 지원을 추가"할 수 있습니다. (2)의 경우 가능한 솔루션이 많이 있다고 생각합니다(예: 위에서 언급한 것처럼 추가 전용 S3 설정).