Drive와 파일 저장

AI agent가 삭제할 수 없는 격리 백업

작성자: Alexey Bulygin
작업 쪽 손잡이 없이 파일만 들어가는 단방향 투입구

코딩 agent는 실제 machine의 shell에 접근해 migration, 정리, reset, 삭제를 수행합니다. agent가 접근 가능한 사본은 지시된 작업 중에도 파괴할 수 있으므로 별도 백업 패턴이 필요합니다.

이는 이론적 위험이 아닙니다. 이 글은 작동하는 패턴과 보호하지 못하는 범위를 설명합니다.

기존 백업이 AI agent 백업이 아닌 이유

기존 threat model은 hardware 장애, 사람 실수, ransomware를 가정합니다. Agent는 사용자 권한으로 빠르게, 그럴듯한 이유를 갖고 행동합니다.

사용자에게 mount된 network drive, sync folder, 읽을 수 있는 key가 있는 object storage는 agent도 볼 수 있습니다. agent가 디렉터리를 불필요하다고 판단하면 sync가 삭제를 사본에 반영합니다.

핵심 차이는 cloud와 local이 아니라 agent 환경에서 사본에 접근 가능한지입니다.

AI agent 백업 패턴: push만 하고 sync하지 않기

이 구분이 핵심입니다.

Sync는 삭제를 반영하므로 작업 파일에는 유용하지만 archive를 파괴할 수 있습니다. CISA 안내도 보호 대상에서 사본을 격리하라고 권고합니다.

백업은 새 자료를 upload하고 제거를 mirror하지 않습니다. 날짜별 destination은 실행마다 추가합니다. 데이터 크기와 요금에 따라 다르지만 database dump의 일일 사본 서른 개는 복구 실패보다 저렴할 수 있습니다.

인증 정보 분리가 전부입니다

작업 환경이 보유하지 않는 credential로 push-only 경로를 만드세요.

Drive는 device별로 취소 가능한 app password를 지원합니다. 전용 backup credential은 push machine이나 scheduled job에만 두고 project directory나 agent가 읽는 env file에는 두지 마세요. 권한도 최소화하세요.

같은 machine에서 실행하면 project tree 밖에 OS 권한과 함께 보관하고, 별도 runner를 쓰면 더 분리됩니다. agent가 destination에 인증할 경로가 없어야 합니다.

보호하는 것과 보호하지 않는 것

안심시키는 말보다 정확성이 중요합니다.

보호 대상은 작업 환경의 삭제와 덮어쓰기, directory 정리 script, 실수로 한 repository reset, 사람 실수, 의도하지 않은 sync 삭제입니다. 단 upload와 격리가 실제로 작동해야 합니다.

보호하지 못하는 것은 dashboard login과 이중 인증을 가진 공격자, 의도적 archive 삭제, backup scope 밖의 데이터입니다. version control도 대체하지 않습니다.

백업은 한 계층이지 전체 security program이 아닙니다.

Push할 항목의 짧은 목록

작업 디렉터리의 많은 항목은 재생성할 수 있어 목록은 짧습니다.

  • Database dump. 야간, 날짜별, plan과 policy에 맞게 보관하고 완전성을 검증합니다.
  • 환경 및 설정 파일. 작지만 재구성이 어렵습니다. 민감한 내용은 암호화하고 접근을 제한합니다.
  • 사용자 upload content. version control에 없고 재생성할 수 없습니다.
  • 중요한 생성 artefact. 변경된 process가 만든 report와 export입니다.

Source code에는 remote git repository가 더 적합합니다. 이 계층은 재생성 불가 데이터용입니다.

야간 job의 형태

짧은 구현은 유지와 검증이 쉽습니다.

Scheduled task가 임시 database dump를 만들고 날짜 이름과 경로로 upload한 뒤 local 임시본을 지웁니다. 설정과 upload도 같습니다. Job은 자체 credential을 쓰고 remote delete logic을 갖지 않습니다.

두 가지가 중요합니다. 날짜 path는 매번 새 사본을 만들고 고정 filename은 마지막 하나만 남깁니다. 실패는 즉시 알리고 monitor해야 합니다. 여섯 주 동안 조용히 실패한 job은 신뢰할 수 없습니다.

Restore 테스트

복원해 보지 않은 백업은 가설입니다.

분기마다 disposable environment에 복원해 integrity, 완전성, 적용 가능성, 절차를 확인하세요. 다운로드 성공만으로 복구 가능성이 증명되지는 않습니다.

Credential의 유효성과 rotation 반영도 확인하세요. Push-only의 upload 쪽 실패를 별도로 monitor해야 합니다.

보관 기간

Retention은 기술뿐 아니라 storage, 법률, privacy policy의 문제입니다.

손상은 몇 주 뒤 발견될 수 있습니다. 일일 사본 서른 개는 한 달 기록을 주지만 적절한 기간은 탐지 시간, 크기, 규정에 따릅니다. 실제 비용을 계산하세요.

한 달간 매일 보관하고 이후 일 년간 매월 하나를 남길 수 있습니다. 별도의 최소 권한 job으로 의도적으로 prune하세요. Uploader가 삭제도 가능하면 위험이 다시 커집니다.

저장 위치

Drive는 mail과 같은 account에 연결됩니다. 설명된 add-on은 250 GB부터 월 $3.20이며 slider로 100 TB까지입니다. 현재 plan, retention, encryption, egress charge를 확인하세요.

Storage는 account 전체 pool 또는 mailbox별로 나눌 수 있습니다. WebDAV나 API upload는 부여된 권한을 따릅니다. WebDAV 안내를 참고하세요. 다른 account와 folder를 공유해 credential 없이 복원하게 할 수 있으며 역할과 취소는 공유 링크 작동 방식에서 확인하세요.

핵심은 날짜별 folder, 작업 환경에 없는 credential, 추가만 하는 job입니다. 격리 사본의 완전성과 복원 가능성을 정기적으로 검증하세요.

이 글 공유하기

TrekMail 운영과 보호에 필요한 기술을 사용합니다. 확인하면 쿠키 정책에 설명된 제한적인 분석 및 광고 측정도 허용됩니다.

TrekMail 로그인

대시보드, 메일함, DNS에 액세스하세요.

또는

12자 비밀번호 일치

또는

재설정 이메일 전송됨

이 이메일로 등록된 계정이 있으면 비밀번호 재설정 안내를 보내드렸습니다.

계속 진행하면 TrekMail의 이용약관개인정보 처리방침에 동의하게 됩니다.