삭제 기준이 SaaS마다 달라짐
권한 기준이 제각각
법적 보존과 운영 보관이 섞임
저장량 집계가 꼬임
보안/감사 대응 시 SaaS별로 따로 증빙
나중에 공통 이전 비용 폭증
아래 항목은 향후 저장·검색 인프라에서 표준화할 설계 항목입니다.
ABAC 기반 접근 정책으로 행위 기준 제어
7단계 상태 전이로 완전한 삭제 추적
4단계 보존 클래스로 법적 요건 충족
Append-only 감사 로그로 완전한 이력
일별 사용량 버킷별 집계
통합 검색 인덱스 표준 5필드 설계 중
아래 통제 항목은 설계가 확정된 로드맵이며, 순차적으로 구현될 예정입니다.
역할이 아닌 행위 기준. subject_type, action, effect, conditions_json으로 세밀한 접근 제어.
요청 → 승인 → 삭제 대기 → Hold 검사 → 영구 삭제 예약 → 물리 삭제 → 기록 보존. 모든 전이 감사.
삭제 동결과 append-only 감사 이벤트. 정책 변경, 삭제 승인, Hold 설정/해제, Hard Delete 모두 기록.
27개 SaaS를 하나의 저장 문법으로. saas_origin, workspace_id, linked_object로 통합 관리.
아래 항목은 보유 인증이 아니라, 설계 기준과 목표를 뜻합니다.
감사 로그·접근 제어·데이터 보관 정책을 SOC 2 요구사항 기준으로 설계 중입니다. (인증 미보유)
정보보안 관리체계 수준의 통제를 목표로 준비 중입니다. (인증 미보유)
검증된 클라우드 인프라 위에서 보안 기준을 반영해 설계 중입니다.
아래 단계는 아직 구현되지 않았으며, 설계된 흐름을 미리 공유합니다.
드래그앤드롭으로 파일을 업로드하면 자동으로 버킷과 버전이 할당되도록 설계 중입니다.
보존 기한·접근 정책·삭제 규칙이 즉시 적용되도록 설계 중입니다.
모든 접근과 변경이 append-only 로그로 기록되도록 설계 중입니다.
AIDataDam이 어떤 저장·검색 인프라 구조를 준비하는지 함께 이야기합니다.