Discourse에서 PII 저장 이해하기

문서 사이트 관리
1

:bookmark: 이 가이드는 Discourse가 기본적으로 저장하는 개인 식별 정보(PII)의 내용, 저장 위치, 접근 가능한 대상, 그리고 DiscourseConnect를 사용하여 PII 수집을 최소화하는 방법에 대해 설명합니다.

:person_raising_hand: 필요한 사용자 권한: 관리자

Discourse는 moderating(모더레이션), 계정 관리, 사용자 인증과 같은 핵심 기능을 지원하기 위해 특정 개인 식별 정보(PII)를 저장합니다. 수집되는 데이터의 종류와 저장 방식을 이해하면 개인정보 보호 및 규정 준수에 대한 현명한 결정을 내리는 데 도움이 됩니다.

요약

Discourse는 IP 주소, 이메일 주소, 소셜 로그인 자격 증명 등 여러 유형의 PII를 저장합니다. 이 정보는 주로 모더레이션, 중복 계정 탐지, 사용자 인증에 사용됩니다. 사이트 관리자는 DiscourseConnect(SSO)를 구현하여 Discourse로 전달되는 정보를 제어함으로써 PII 저장을 최소화할 수 있습니다.

Discourse가 저장하는 PII는 무엇인가요?

IP 주소

Discourse는 각 사용자의 중복 계정 탐지를 돕기 위해 모더레이션 팀을 위해 다음 IP 주소를 저장합니다:

  • 가입 시 IP 주소 - 계정이 생성될 때 사용된 IP 주소
  • 마지막 사용 IP 주소 - 사용자가 사이트를 접근한 가장 최근의 IP 주소

예를 들어, 오전 11시에 모바일 기기로 사이트를 방문하고 오후 12시에 태블릿으로 방문했다면, “마지막 사용” IP 주소로 저장되는 것은 태블릿의 IP 주소뿐입니다.

IP 주소에 접근할 수 있는 대상

  • 관리자 - 모든 IP 정보에 대한 전체 접근 권한
  • 모더레이터 - 기본적으로 IP 주소를 볼 수 있음 (moderators_view_ips 사이트 설정으로 비활성화 가능)
  • 시스템 - 스팸 탐지 및 중복 계정 식별을 위해 내부적으로 IP 주소를 사용

이메일 주소

이메일 주소는 데이터베이스에 평문으로 저장되며, 데이터베이스에 접근 권한이 있는 누구나 볼 수 있습니다. 여기에는 다음이 포함됩니다:

이메일 주소에 접근할 수 있는 대상

  • 관리자 - 모든 이메일 주소에 대한 전체 접근 권한
  • 모더레이터 - 기본적으로 이메일 주소를 볼 수 없음 (moderators_view_emails 사이트 설정으로 활성화 가능)
  • 데이터베이스 관리자 - 데이터베이스에 직접 접근 권한이 있는 누구나

전체 이름 (실명)

Discourse는 사용자의 전체 이름(또는 "실명"이라고도 함)을 수집하고 저장할 수 있으며, 이는 사용자 이름(username)과 구별됩니다. 전체 이름은 데이터베이스에 다른 사용자 정보와 함께 평문으로 저장됩니다.

전체 이름 수집 방법

전체 이름은 여러 방식으로 제공될 수 있습니다:

  • 가입 시 - 가입 과정에서 사용자가 전체 이름을 입력할 수 있음 (설정 사항에 따라 다름)
  • SSO/DiscourseConnect를 통해 - 외부 인증 제공자는 사용자 생성 또는 업데이트 시 전체 이름(name 필드)을 전달할 수 있으며, 설정에 따라 로컬 이름을 덮어쓸 수 있습니다.
  • 프로필 편집을 통해 - 사용자는 프로필 설정에서 전체 이름을 추가하거나 업데이트할 수 있습니다
  • 소셜 로그인을 통해 - 사용자가 소셜 제공자를 통해 인증할 때, 표시 이름이 전체 이름으로 사용되는 경우가 많습니다

전체 이름에 접근할 수 있는 대상

전체 이름은 데이터베이스의 users 테이블의 name 컬럼에 평문으로 저장되며, 다음 대상이 접근할 수 있습니다:

  • 관리자 - 모든 전체 이름에 대한 전체 접근 권한
  • 모더레이터 - 기본적으로 전체 이름을 볼 수 있음 (이메일 접근 권한과 동일한 권한으로 제어됨)
  • 데이터베이스 관리자 - 데이터베이스에 직접 접근 권한이 있는 누구나.
  • 일반 사용자 - enable_names 및 관련 표시 설정에 따라 전체 이름을 볼 수 있음

설정 옵션

관리자는 다음 사이트 설정을 사용하여 전체 이름의 수집 및 표시 방식을 제어할 수 있습니다:

  • full_name_requirement - 가입 시 전체 이름 필드가 표시되는지와 필수 필드인지를 제어

  • auth_overrides_name - 활성화 시, 외부 인증 제공자(SSO/DiscourseConnect 및 소셜 로그인 포함)에서 받은 이름은 사용자가 변경할 수 없습니다

    • 시스템 간 일관된 신원 유지에 유용

  • use_name_for_username_suggestions - 활성화 시, Discourse는 가입 시 사용자 이름 추천에 전체 이름을 사용합니다

  • enable_names - 사용자의 프로필, 사용자 카드, 이메일에서 전체 이름을 표시하는 마스터 스위치. 비활성화하면 모든 곳에서 전체 이름이 숨겨집니다

    • 기본값: 활성화됨

:information_source: 다음 표시 설정은 enable_names가 활성화된 경우에만 적용됩니다:

  • display_name_on_posts - 사용자의 게시글에서 @username 외에도 전체 이름을 표시
  • prioritize_username_in_ux - 인터페이스에서 사용자 이름과 전체 이름 중 어느 쪽이 더 두드러지게 표시되는지를 제어
    • 기본값: 활성화됨 (사용자 이름이 우선)
  • display_name_on_email_from - 활성화 시, 이메일 알림의 “보낸 사람” 필드에 전체 이름을 사용

:information_source: Discourse에는 지능형 중복 제거 기능이 있습니다. 사용자의 전체 이름과 사용자 이름이 매우 유사한 경우(공백, 밑줄, 대소문자 무시), 중복을 피하기 위해 하나만 표시됩니다. 이 동작은 Remove Name Suppression on Posts 테마 구성 요소를 사용하여 비활성화할 수 있으며, 이를 통해 게시글에 항상 전체 이름과 사용자 이름이 모두 표시되도록 강제할 수 있습니다.

연동된 소셜 로그인 정보

사용자가 소셜 로그인 제공자(Google, Facebook, GitHub 등)를 통해 인증할 때, Discourse는 다양한 정보를 저장합니다:

  • 이메일
  • 제공자 계정 ID
  • 이름
  • 아바타
  • [이 목록은 제공자나 시간에 따라 변경될 수 있음]

저장되는 구체적인 데이터는 제공자와 그들이 공유하는 정보에 따라 달라집니다.

예시: Google OAuth2

사용자가 Google로 로그인하면, Discourse는 데이터베이스에 다음 정보를 유지합니다:

image
image690×228 22.8 KB

provider_name: "google_oauth2",
provider_uid: "11791234567812345",
info: {
  "name"=>"Bilbo Baggins",
  "email"=>"bilbo.baggins@gmail.com",
  "image"=>"https://lh3.googleusercontent.com/a/ACg8ocJD5vR-JuZZ16mGf51uYH0KyKGoKXF36U3inbh4Bzne0CpuTlH23g=s96-c",
  "last_name"=>"Baggins",
  "first_name"=>"Bilbo",
  "email_verified"=>true,
  "unverified_email"=>"bilbo.baggins@gmail.com"
}

예시: Facebook OAuth

Facebook 로그인을 위한 편집된 예시는 다음과 같습니다:

provider_name: "facebook",
provider_uid: "123456789",
info: {
  "name"=>"Bilbo Baggins",
  "email"=>"bbaggins@shire.net",
  "image"=>"https://graph.facebook.com/v5.0/123456789/picture?access_token=swordfish&width=480&height=480",
  "last_name"=>"Baggins",
  "first_name"=>"Bilbo"
}

:information_source: 저장되는 특정 필드는 인증 프로토콜이 진화함에 따라 제공자나 시간에 따라 변경될 수 있습니다.

소셜 로그인 정보에 접근할 수 있는 대상

  • 관리자 - 관리자 패널 및 데이터베이스를 통해 관련 계정 정보에 대한 전체 접근 권한
  • 모더레이터 - 사이트 설정에 따라 제한된 접근 권한을 가질 수 있음
  • 개별 사용자 - 사용자 설정에서 자신의 관련 계정을 보고 관리할 수 있음

DiscourseConnect를 통한 PII 저장 최소화

Discourse에 특정 개인 식별 정보를 저장하지 않으려면, DiscourseConnect를 사용하여 사용자의 로그인 프로세스를 완전히 처리할 수 있습니다.

DiscourseConnect가 PII 노출을 줄이는 방법

DiscourseConnect를 사용하면 Discourse로 반환되는 사용자 정보를 완전히 제어할 수 있습니다. 구현을 관리하는 주체이므로, 전통적인 식별자를 위한 개인정보 보호 중심의 대안을 만들 수 있습니다.

예시 접근법: 사용자의 실제 이메일 주소를 Discourse에 제공하기 대신, 고유하지만 PII가 없는 이메일 주소를 생성할 수 있습니다.

예를 들어, 사용자의 내부 고유 ID가 U123456이라면, 다음과 같은 이메일 주소를 전달할 수 있습니다:

user-U123456@example.com

추가적인 개인정보 보호 이점

DiscourseConnect를 사용하면 연동된 소셜 로그인과의 연결을 Discourse에서 숨길 수도 있습니다. Discourse의 관점에서, 사용자가 사용하는 로그인 유형(소셜, 모바일 등)은 중요하지 않으며, 이는 사용자 측에서 처리되기 때문입니다. Discourse는 로그인 제공자가 알려주는 것만 알 수 있습니다.

MFA 및 외부 인증

외부 인증 위에 MFA를 강제할 수 있나요?

:warning: 이 조합은 현재 예상된 방식으로 지원되지 않습니다.

Discourse에는 enforce_second_factor_on_external_auth 사이트 설정이 있으며, 이는 MFA가 활성화된 사용자가 소셜 로그인과 같은 외부 인증 방법을 사용하는 것을 방지합니다. 활성화되면, 2단계 인증이 활성화된 사용자는 외부 인증 방법으로 로그인하는 것이 방지됩니다.

이 설정은 사용자로 하여금 다음 중 하나를 선택하도록 효과적으로 만듭니다:

  • Discourse에서 2FA 없이 외부 인증(소셜 로그인) 사용
  • Discourse에서 2FA 와 함께 사용자 이름/비밀번호 로그인 사용

:information_source: SSO의 가장 안전한 설정을 위해, Discourse 내부가 아닌 아이덴티티 제공자에서 MFA를 구현하세요.

추가 자료

5개의 좋아요
Where in Discourse can users publicly share PII?