데이터 유출 처리(Data Spillage Handling)는 우발적인 데이터 유출을 방지하고 협업을 방해하지 않으면서 잠재적인 유출에 신속히 대응할 수 있도록 시스템 관리자를 지원합니다. 이 기능을 활성화하면 Mattermost 사용자가 민감하거나 규제되거나 부적절한 정보가 포함될 수 있는 메시지를 신고할 수 있으며, 지정된 콘텐츠 검토자가 격리된 메시지를 평가하고 제거하거나 기각하는 적절한 조치를 취할 수 있습니다.

모든 팀원이 민감 데이터 노출에 대한 첫 번째 방어선이 됨으로써 데이터 유출 처리는 미션 크리티컬하고 안전한 배포를 강화하고 조직 및 규제 데이터 처리 기준 준수를 지원합니다.

시작하기 전에#

Mattermost에서 시스템 관리자여야 합니다. 격리된 메시지의 콘텐츠 검토자가 될 사람을 식별하고, 검토 중인 격리된 메시지를 Mattermost에서 사용자에게 숨길지 결정해야 합니다.

활성화#

데이터 유출 처리는 기본적으로 활성화되어 있지 않습니다. 데이터 유출 처리를 활성화하려면:

1. System Console > Site Configuration > Data Spillage Handling 으로 이동합니다.
2. Enable Data Spillage Handling 을 True 로 설정합니다.

또는 config.json 파일이나 환경 변수 를 통해 데이터 유출 처리를 설정할 수 있습니다.

설정#

1. Content Reviewers 아래에서 격리된 콘텐츠를 검토할 사람을 정의합니다:
• Same reviewers for all teams: True 로 설정하면 모든 팀에 하나의 전역 검토자 목록을 적용하고, False 로 설정하면 팀별로 검토자를 설정합니다.
• Reviewers: 검색하려면 입력하여 콘텐츠 검토자로 지정할 사용자를 찾습니다.
Important
검토자를 신중하게 선택하세요. 검토자 역할을 할당하면 잠재적으로 민감한 정보에 대한 접근 권한이 부여되며 비공개 채널의 데이터가 노출될 수 있습니다.
• 전역 검토자는 자신이 멤버가 아닌 비공개 채널을 포함한 모든 팀과 채널의 격리된 메시지를 볼 수 있습니다.
• 팀별 검토자는 자신이 멤버가 아닌 해당 팀 내 비공개 채널을 포함하여 배정된 팀의 격리된 메시지를 볼 수 있습니다.
• Additional reviewers: 선택적으로 포함:
• System Administrators: 시스템 관리자는 자신이 속한 모든 팀의 격리된 메시지를 받습니다.
• Team Administrators: 팀 관리자는 각자의 팀에 대한 격리된 메시지를 받습니다.
2. Notification Settings 아래에서 콘텐츠가 격리되거나 검토될 때 격리 워크플로의 각 단계에서 누가 업데이트를 받을지 지정합니다:
• 콘텐츠가 격리될 때 알림: 검토자, 작성자.
• 검토자가 지정될 때 알림: 검토자.
• 콘텐츠가 제거될 때 알림: 검토자, 작성자, 신고자.
• 기각 시 알림: 검토자, 작성자, 신고자.

모든 알림은 Data Spillage Bot 을 통해 다이렉트 메시지로 전송됩니다.

3. Additional Settings 아래에서 격리 워크플로의 동작 방식을 설정합니다:
• Reasons for quarantine: 사용자를 위한 격리 대화 상자에 표시될 사전 설정 카테고리를 정의합니다(예: 분류 불일치, 알 필요 없음 위반, 개인 식별 정보(PII) 노출, 작전 보안(OPSEC) 우려, 비밀해제 정보(CUI) 위반).
• Require reporters to add comment: True 로 설정하면 사용자가 메시지를 격리할 때 짧은 설명을 추가해야 합니다.
• Require reviewers to add comment: True 로 설정하면 검토자가 격리를 해제할 때 코멘트를 추가해야 합니다.
• Hide message from channel while it is being reviewed: True 로 설정하면 검토가 완료될 때까지 격리된 메시지를 채널에서 자동으로 숨깁니다. 루트 게시물이 격리되면 전체 스레드가 숨겨집니다.

격리된 메시지 모니터링#

사용자가 메시지를 격리하면, Data Spillage Bot 이 모든 콘텐츠 검토자에게 다이렉트 메시지를 보냅니다.

Data Spillage Bot 의 다이렉트 메시지는 중앙 집중식 관리 큐로, 검토자가 Mattermost를 벗어나지 않고도 격리된 메시지를 보고, 배정하고, 조치를 취할 수 있습니다. 검토자는 이를 사용하여 잠재적인 데이터 유출을 모니터링하고, 대응을 조율하며, 검토 활동의 감사 가능한 기록을 유지할 수 있습니다.

각 격리된 메시지는 다음을 포함하는 카드 형식의 메시지로 표시됩니다:

• Quarantined by: 메시지를 신고한 사용자.
• Status: 검토의 현재 상태. 모든 격리된 콘텐츠는 Pending 상태로 시작됩니다.
• Reason: 신고자가 선택한 이유(예: 분류 불일치, 알 필요 없음 위반).
• Message preview: 작성자, 타임스탬프, 원래 채널을 포함한 격리된 메시지의 스니펫.
• Reviewer: 현재 메시지 검토를 배정받은 사용자(초기에는 Unassigned).
• Channel: 메시지가 원래 게시된 채널 이름.
• Team: 격리된 메시지의 팀 컨텍스트.
• Comment: 신고자가 제공한 컨텍스트.
• Post ID: 감사 목적을 위한 원본 메시지의 시스템 식별자.

검토자는 View details 를 선택하여 다음 조치를 취할 수 있습니다:

• 격리된 메시지를 검토할 검토자 를 배정합니다.
• Remove message: 모든 사용자를 위해 원래 채널에서 격리된 메시지를 영구적으로 삭제합니다. 격리된 메시지의 상태가 Removed 로 변경됩니다.
• Keep message: 격리를 기각하고 숨겨진 경우 메시지를 복원합니다. 격리된 메시지의 상태가 Retained 로 변경됩니다.
• Add a comment: 필요한 경우 결정 이유를 기록합니다.
• Generate a report: 기록 보관 또는 인시던트 대응을 위해 격리된 메시지와 검토 활동에 대한 보고서를 다운로드합니다. 자세한 내용은 administration-guide/manage/admin/content-flagging:generate a quarantined message report 을 참조하세요.

조치가 취해지면 Status 필드가 자동으로 업데이트됩니다. Data Spillage Bot 은 데이터 유출 처리가 설정된 방식에 따라 신고자, 작성자, 다른 검토자에게 후속 알림을 보냅니다.

격리된 메시지 보고서 생성#

검토자는 격리된 메시지의 전체 컨텍스트와 관련 검토 활동을 포함하는 다운로드 가능한 보고서를 생성할 수 있습니다. 보고서는 기록 보관, 인시던트 대응, 메시지가 영구적으로 제거되기 전에 증거를 보존하는 데 유용합니다.

보고서는 다음 진입점 중 어느 곳에서든 생성할 수 있습니다:

• 격리된 메시지 세부 정보에서: 메시지 세부 정보 패널에서 Download report 를 선택합니다. 이 옵션은 Pending, Reviewer Assigned, Removed, Retained 등 격리 상태와 관계없이 사용할 수 있습니다.
• Remove message 흐름에서: Remove message 를 선택하면 확인 대화 상자에 기본적으로 선택된 Download quarantined message report 체크박스가 표시됩니다. 체크박스가 선택된 상태에서는 메시지를 영구적으로 제거하기 전에 Mattermost가 보고서를 생성하고 다운로드합니다. 이 안전장치는 메시지 콘텐츠가 삭제되기 전에 기록이 사용자 디바이스에 보존되도록 보장합니다.
• Keep message 흐름에서: Keep message 를 선택하면 확인 대화 상자에 동일한 체크박스가 표시됩니다. 체크박스가 선택된 상태에서는 유지 작업이 완료되는 동안 Mattermost가 백그라운드에서 보고서를 생성하고 다운로드합니다.

Remove message 또는 Keep message 흐름에서 보고서 다운로드를 건너뛰기로 선택하면, Mattermost는 보고서 없이 진행할 것인지 확인을 요청합니다. 건너뛰기 결정은 감사 로그에 기록됩니다.

보고서 생성이 실패하면(예: 네트워크 중단이나 세션 시간 초과로 인해), 대화 상자에 오류가 표시되고 재시도 옵션이 제공됩니다. 보고서를 건너뛰고 작업을 진행하거나, 취소하고 나중에 메시지 세부 정보에서 보고서를 다운로드할 수도 있습니다.

검토자가 보고서를 생성할 때마다 Data Spillage Bot 이 모든 콘텐츠 검토자에게 알림을 보내, 유출 가능성이 있는 데이터의 사본을 확보할 때마다 감사 가능한 기록이 남도록 합니다.

보고서 내용 및 형식#

각 보고서는 YAML 메타데이터 파일과 원본 파일 첨부를 포함하는 ZIP 아카이브입니다. YAML은 사람이 읽을 수 있으면서도 기계가 파싱할 수 있기 때문에 사용되며, 이는 수동 검토뿐 아니라 후속 컴플라이언스 또는 인시던트 대응 도구에서의 처리에도 보고서를 적합하게 만듭니다.

아카이브는 다음과 같은 구조를 갖습니다:

/
├── report_metadata.yaml
├── content_review.yaml
├── post/
│   ├── post.yaml
│   └── attachments/
│       └── <original attachment files>
└── edit_history/
    └── <edit_post_id>/
        ├── post.yaml
        └── attachments/
            └── <original attachment files>

• report_metadata.yaml: 보고서를 생성한 검토자의 사용자 ID와 사용자 이름, 생성 타임스탬프, 보고서 형식 버전(향후 릴리즈에서 보고서 형식이 변경될 경우 하위 호환성을 위해 사용됨)을 포함하여 보고서 자체를 식별합니다.
• content_review.yaml: 신고자의 사용자 ID, 사용자 이름, 선택한 사유, 코멘트, 신고 타임스탬프, 검토 중 메시지가 숨겨졌는지 여부, 그리고 격리가 해결된 후에는 검토자의 사용자 ID, 사용자 이름, 코멘트, 조치 타임스탬프를 포함하여 데이터 유출 이벤트를 기록합니다. 미해결 격리의 경우 검토자 필드는 생략됩니다.
• post/post.yaml: 게시물 ID, 작성자 ID, 작성자 이름, 작성자 이메일, 메시지 콘텐츠, 채널 ID, 채널 표시 이름, 팀 ID, 팀 표시 이름, 생성 및 업데이트 타임스탬프, 고정 상태, 루트 ID, 게시물 속성, 게시물 메타데이터, 답글 수(루트 게시물의 경우), 수정 기록 게시물 ID의 정렬된 목록을 포함하여 격리된 메시지를 설명합니다.
• post/attachments/: 격리된 메시지에 첨부된 원본 파일이 그대로 포함됩니다.
• edit_history//: 메시지의 이전 버전마다 하나의 하위 디렉터리가 있으며, 각 디렉터리에는 기본 게시물 디렉터리와 동일한 형식으로 post.yaml 과 attachments/ 디렉터리가 포함됩니다.

중복을 방지하기 위해 첨부 파일은 파일 ID를 기준으로 전체 아카이브에서 중복 제거됩니다. 각 고유한 첨부 파일은 정확히 한 번만 나타납니다 — 메시지의 현재 버전에 존재하는 경우 기본 게시물 아래에, 그렇지 않으면 해당 파일을 참조한 가장 이른 수정 기록 항목 아래에 나타납니다.

삭제된 메시지#

검토자가 격리된 메시지를 영구적으로 제거하면, 메시지와 관련된 모든 데이터가 데이터베이스와 파일 시스템에서 삭제되며 복구할 수 없습니다. 삭제 대상은 다음과 같습니다:

• 게시물 레코드: 메시지의 텍스트와 관련된 게시물 속성. 콘텐츠는 게시물이 삭제되기 전에 먼저 삭제 처리됩니다.
• 파일 첨부: Mattermost의 파일 스토리지(로컬, S3 등)에 저장된 파일.
• 파일 첨부 레코드: 파일 이름, ID, 스토리지 링크를 포함하여 메시지에 대한 파일 정보 데이터베이스 행.
• 수정 기록: 각 리비전의 파일 메타데이터를 포함한 메시지의 모든 이전 리비전.
• 우선순위 메타데이터: 메시지 우선순위 또는 중요도 설정.
• 지속 알림: 메시지에 첨부된 반복 알림.
• 확인: 메시지를 확인한 사용자 기록.
• 리마인더: 메시지에 대해 생성된 리마인더.
• 스레드, 답글, 반응: 메시지와 연관된 스레드 레코드, 답글, 반응 데이터(있는 경우).

게시물 삭제 보고서#

검토자가 Remove message 를 선택하면, Data Spillage Bot 이 해당 격리된 메시지에 대한 검토자의 콘텐츠 검토 스레드에 Post Deletion Report 를 게시합니다. 이 보고서는 원래 격리 알림을 받은 모든 검토자에게 전달되며, 각 검토자의 언어로 현지화됩니다. 각 게시물에는 인라인으로 렌더링된 간략한 요약과 deletion_report_<post_id>.md 라는 이름의 Markdown 파일로 첨부된 전체 보고서가 포함됩니다.

이 보고서는 메시지와 관련 데이터에 대해 수행된 모든 정리 단계를 기록합니다. 이 단계들은 administration-guide/manage/admin/content-flagging:deleted messages 에 나열된 데이터 범위와 직접 대응됩니다:

• File attachments: 파일 스토리지에서 제거된 파일.
• File attachment records: 메시지에 대한 파일 정보 데이터베이스 행.
• Edit history: 메시지의 모든 이전 리비전. 각 리비전은 개별 하위 단계로 보고되어 검토자가 정확히 어떤 리비전이 정리되었는지 확인할 수 있습니다.
• Priority metadata: 메시지 우선순위 및 중요도 설정.
• Persistent notifications: 메시지에 첨부된 반복 알림.
• Acknowledgements: 메시지를 확인한 사용자 기록.
• Reminders: 메시지에 설정된 리마인더.
• Thread, replies, and reactions: 메시지와 연관된 스레드 레코드, 답글, 반응 데이터.
• Post record: 게시물 자체. 게시물이 삭제되기 전에 콘텐츠가 삭제 처리됩니다.

각 단계에는 다음 상태 중 하나가 지정됩니다:

• Removed ✅: 데이터가 성공적으로 삭제되었습니다.
• Not applicable ➖: 삭제할 이 유형의 데이터가 없었습니다.
• Partial ⚠️: 이 유형의 일부 항목은 삭제되었지만 적어도 하나는 실패했습니다. 이 상태는 하나의 리비전을 삭제할 수 없는 경우 Edit history 아래에서 가장 자주 나타납니다.
• Failed ❌: 단계가 완료되지 않았습니다. 보고서에는 검토자와 시스템 관리자가 무엇이 잘못되었는지 확인할 수 있도록 오류 로그가 포함됩니다.

모든 단계가 Removed 또는 Not applicable 인 경우 추가 조치가 필요하지 않습니다. 이 보고서는 삭제에 대한 감사 가능한 기록으로 사용됩니다.

어느 단계라도 Partial 또는 Failed 로 보고되면, 보고서에 incomplete 경고가 표시됩니다. 검토자는 시스템 관리자에게 에스컬레이션해야 하며, 시스템 관리자는 단계별 전체 오류 로그가 포함된 첨부 deletion_report_<postId>.md 파일을 사용하여 수동 복구를 수행하고 데이터가 완전히 제거되었는지 확인할 수 있습니다.

모범 사례 권고#

데이터 유출 처리를 조직 전체에 롤아웃하기 전에, 이 기능이 우발적인 데이터 유출로부터 사용자와 조직 모두를 보호한다는 점을 알리는 것을 권장합니다. 파일럿 팀으로 시작하여 검토자 알림과 워크플로를 검증하고, 기존 데이터 처리 또는 인시던트 대응 플레이북과 프로세스를 통합하며, 모든 결정이 투명하고 감사 가능하도록 신고자 및 검토자 코멘트를 필수화하세요.