# 사용자 사칭에 대한 의견
**URL:** https://meta.discourse.org/t/thoughts-about-impersonate-user/258795
**Category:** Community Building
**Tags:** impersonate
**Created:** [3월 20, 2023, 7:54오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795 "2023-03-20T19:54:52Z")
**Posts on this page:** 20
**Page:** 2
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 12:18오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/25 "2023-03-21T12:18:15Z")
> [@kynic](#):
>
> 그러면 Google, Facebook, Microsoft 등 그 밖의 모든 서비스도 그렇게 하므로 그것들도 사용하지 마세요. 그들은 자신들이 당신을 “사칭”할 수 있다고 공개적으로 말하지는 않습니다.
WhatsApp 같은 그 기능이 없는 서비스들이 있잖아요. 그런 서비스들도 정말로 할 수 있다고 확신하나요, 아니면 당신이 사용하는 다른 앱에서 할 수 있다고 해서 그들도 할 수 있다고 짐작하고 있는 건가요?
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [3월 21, 2023, 12:28오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/26 "2023-03-21T12:28:29Z")
친근한 동네 관리자로서 정중한 알림입니다. 토론을 문명적이고, 일반적으로 차분하고 침착하게 유지해 주세요. 🙏 Discourse의 기능에 대해 논쟁하는 것은 스트레스가 많은 경험이 되어서는 안 됩니다. 🙂
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [3월 21, 2023, 1:01오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/27 "2023-03-21T13:01:18Z")
> [@kynic](#):
>
> ‘대리 impersonate’ 기능의 진짜 문제는 무엇인가요?
솔직히 말하자면, 이 버그/기능에 대해 처음부터 알았다면 제가 만든 커뮤니티의 기반 플랫폼으로 Discourse를 선택하지는 않았을 것입니다.
개인적으로 생각하기에, 이것이 기본적으로 활성화되어 있고 클릭이나 탭 한 번의 거리로 사용할 수 있다는 것은 어떤 관점에서든 용인할 수 없는 일입니다.
요즘 인터넷에서 진정으로 중요한 것은 자유와 사생활 보호입니다. 저는 Discourse 내부의 신뢰를 깨뜨리기 위해 이 기능이 활성화된 것이 아니라, 좋은 사용 사례를 위해 활성화된 것임을 알고 있으므로, 핵심 팀이 워크플로우를 재검토해주기를 바랍니다.
Jammy가 말했듯이, 이 스레드는 좋은 논의를 지향하는 것이며, 무례하게 대하거나 다른 의견을 개인적인 문제로 받아들이는 것이 아닙니다. 🙏
> [@kynic](#):
>
> 그렇다면 구글, 페이스북, 마이크로소프트를 쓰지 마세요.
저는 쓰지 않습니다. 맥(Mac)은 음악 재생이나 사소한 용도로만 사용하고 있습니다.
---
### Author:  [@Jagster](https://meta.discourse.org/u/Jagster)
#### Post date: [3월 21, 2023, 1:07오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/29 "2023-03-21T13:07:31Z")
참고로, 꽤 큰 LMS 플랫폼인 무들(Moodle)을 아시나요? 네, 위장(impersonating)이 그중 하나의 도구입니다. 아무도 불평하지 않습니다. 저는 워드프레스에서 고객들을 대신해 작업을 수행할 수 있습니다.
그러니… 위장 기능이 치명적인 단점이라면, 선택지는 그리 많지 않습니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [3월 21, 2023, 1:32오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/30 "2023-03-21T13:32:12Z")
> [@satonotdead](#):
>
> 솔직히 말씀드리면, 이 버그/기능에 대해 알았다면 처음에 제가 창립한 커뮤니티의 기반을 Discourse로 선택하지 않았을 것입니다.
여러분은 아직 “게시물 소유권 변경” 기능조차 발견하지 못했습니다! 🎉
농담을 제쳐두고 말하겠습니다. 칼로 사람을 죽일 수 있다는 이유로 모든 가정에 칼을 금지하는 것과 같습니다. 문제는 도구가 아니라 그 도구가 어떻게 사용되는지입니다. 커뮤니티의 일원이라면, 수많은 이유 때문에 관리자를 신뢰해야 합니다. 만약 신뢰할 수 없다면, 커뮤니티를 떠나는 것이 좋습니다. 잔인하게 들릴 수 있지만, 사실은 그 정도로 단순합니다.
Discourse 소스 코드 한 줄만 변경하면 관리자가 모든 입력된 비밀번호를 조용히 수집할 수 있습니다. 어떻게 생각하시나요? 기능을 아무리 제거해도 서버에서 실행 중인 코드를 검증할 방법은 없습니다. 이 문제를 해결할 유일한 해법은 신뢰입니다.
클라이언트와 그들의 사용자를 대신해 많은 트러블슈팅을 수행하는 사람으로서 말씀드리면, "테스트 계정"만으로는 부족합니다. 중요한 옵션과 설정이 너무 많아 종종 임페르소네이션(대리 로그인)이 유일한 방법입니다. 그렇더라도, 우리는 이러한 기능을 오용하지 않도록 금지하는 _개인정보 처리 계약_을 체결해 두었습니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 1:41오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/31 "2023-03-21T13:41:23Z")
그러니까 말씀하신 대로, 이 기능이 실제로 사용되고 있다는 것은 이미 알려진 사실이고, 이 플랫폼을 선택하는 것은 이에 동의하는 것과 같습니다.
사실 이 주제는 상당한 타당성이 있습니다. 루트 서버 접근을 통해 명령줄로 이 기능을 비활성화할 수 있는 방법을 제공하는 것은 매우 합리적입니다. 이 기능을 사용하려는 사람은 개별 용도에 맞게 사용할 수 있고, 기능을 활성화하고 싶지 않은 사람은 끌 수 있습니다. 사이트에서 루트 접근 권한을 가진 관리자는 매우 제한적인 경우가 많으므로, 이 방식은 잘 작동할 수 있습니다.
기억이 맞다면, 스크립트를 사용하는 사용자 지정 배지 생성을 활성화하려면 명령줄을 사용해야 했던 것과 매우 유사합니다.
이것은 모든 사람의 관점(기능에 대한 찬성과 반대)을 모두 만족시킬 수 있는 매우 단순한 해결책입니다. 개방형 포럼 플랫폼에 대한 훌륭한 타협안입니다. 기본적으로 꺼져 있도록 하고, 활성화하는 방법에 대한 명확한 지침을 제공하거나, 설치 과정에서 활성화 여부를 묻고 루트를 통한 활성화/비활성화 방법에 대한 세부 정보를 제공하는 것도 좋습니다.
🖖😎👍
---
### Author:  [@kynic](https://meta.discourse.org/u/kynic)
#### Post date: [3월 21, 2023, 1:42오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/32 "2023-03-21T13:42:44Z")
구글, 페이스북, 애플, 그리고 다른 회사들이 이런 일을 하지 않는다고 믿는 사람이 있다면, 나는 더 이상 할 말이 없습니다.. 🫡
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 2:22오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/33 "2023-03-21T14:22:23Z")
> [@RGJ](#):
>
> 클라이언트와 그 사용자들을 대신해 많은 트러블슈팅을 해온 사람으로서 말씀드리면, '테스트 계정’만으로는 부족합니다. 중요한 옵션과 설정이 너무 많아 impersonation(가명 로그인)이 유일한 해결책인 경우가 많습니다. 그렇긴 하지만, 이러한 기능을 오용하지 않도록 하는 _데이터 처리 계약서_를 보유하고 있습니다.
그렇다면 그 경우를 위해 API 키를 사용할 수 있겠네요. 기억이 정확하지는 않지만, 디자이너들이 완전한 관리자 권한을 가지지 않도록 API를 사용하는 솔루션에 대해 언급하신 적이 있는 것 같습니다. 하지만 그 부분에 대해 좋은 논의가 있었습니다.
소유권 변경(Change Ownership) 기능을 사용할 수는 있겠지만, 예를 들어 새 채팅(New Chat) 기능에서는 해당 기능이 작동하지 않습니다.
사과와 주먹도리를 비교하는 식의 논리는 정말 피해야 합니다. 칼은 법적 보관 요건이 없지만, 총과 탄약은 그렇지 않죠. 총과 칼 자체가 사람을 죽이는 것이 아니라, 그것을 그 목적으로 사용하는 사람이 죽이는 것입니다.
어떤 도구가든 남용될 수 있으며, 선택적인 안전 장치를 두는 데에는 아무런 해가 없습니다.
---
### Author:  [@MikeNolan](https://meta.discourse.org/u/MikeNolan)
#### Post date: [3월 21, 2023, 2:24오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/34 "2023-03-21T14:24:27Z")
어떤 시스템이든, 타인의 동의나 인지 없이 그들을 사칭할 수 있는 충분한 접근 권한과 지식을 가진 사람들의 그룹이 항상 존재합니다.
결국 이는 신뢰와 책임의 문제입니다. 시니어 관리자 팀이나 개발자들이 책임감 있게 행동할 것이라고 신뢰해야 합니다.
제 관할 하의 시스템에서는 ‘사용자 사칭’ 기능(매우 유용하다고 동의합니다)이 있지만, 직원 운영 절차상 해당 기능을 사용하려면 반드시 사용자에게 그 사실을 알리고 동의를 얻어야 한다고 명시되어 있습니다. 이를 어길 경우 해고 사유로 간주됩니다. 이 기능은 거의 항상 문제를 해결하기 위해 사용되므로, 동의를 거부한 사용자는 매우 드뭅니다.
때때로 사용자가 개인 메시지의 경우에도 모더레이터나 시스템 관리자가 읽을 수 있는지에 대해 질문을 던지기도 합니다. 이에 대한 우리의 조언은, 어떤 시스템도 침해되거나 해킹될 수 있으므로 공개되고 싶지 않은 내용은 개인 메시지에 입력하지 말라는 것입니다.
참고로, 법률 자문가들은 법적 증거 확보 절차가 이루어지는 경우 모든 것이 요청될 수 있다고 알려줍니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 2:25오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/35 "2023-03-21T14:25:09Z")
> [@kynic](#):
>
> 구글, 페이스북, 애플 그리고 다른 모든 회사들이 이런 일을 하지 않는다고 믿는 사람이 있다면, 뭐라고 말해야 할지 모르겠네요… 🫡
그렇습니다. 그들은 왓스앱처럼 그렇게 할 수 있을 것입니다. 이는 클로즈드 소스 소프트웨어의 명백한 문제입니다. 클로즈드 소스는 사용자가 개발자의 주장을 신뢰할 수밖에 없으며, 오픈 소스에서 할 수 있듯이 이를 검증할 방법이 없기 때문입니다.
리너스의 아버지는 백도어가 없는지 코드를 감사할 방법이 없다는 문제에 대해 마이크로소프트를 강하게 추궁했습니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [3월 21, 2023, 2:28오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/36 "2023-03-21T14:28:25Z")
> [@Heliosurge](#):
>
> 오픈소스에서 할 수 있는 것처럼 검증할 방법이 없습니다.
이미 설명했듯이, 어떤 것이 오픈소스라고 해서 서버에서 실행 중인 코드를 검증할 수 있는 방법은 없습니다.
> [@Heliosurge](#):
>
> 그러므로 그런 경우에는 API 키를 사용할 수 있습니다.
그것이 어떻게 작동할 것으로 예상하시나요? 사용자가 보거나 보지 못하는 문제를 해결하는 데 API 키가 어떻게 도움이 될지 이해할 수 없습니다.
"사용자 위장(impersonate user)
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [3월 21, 2023, 2:40오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/37 "2023-03-21T14:40:06Z")
> [@RGJ](#):
>
> 칼로 사람을 죽일 수 있으니 모든 가정에 칼을 금지하고 싶다는 거군요
아니요, 죄송하지만 제가 원하는 건 그게 아닙니다(그리고 저는 아무것도 원하지 않습니다).
> **[Appeal to ridicule](https://en.wikipedia.org/wiki/Appeal_to_ridicule)**
>
> Appeal to ridicule (also called appeal to mockery, or the horse laugh) is an informal fallacy which presents an opponent's argument as absurd, ridiculous, or humorous, and therefore not worthy of serious consideration. Appeal to ridicule is often found in the form of comparing a multi-layered circumstance or argument to a laughably commonplace event or to another irrelevant thing based on comedic timing, or wordplay. This is a rhetorical tactic that mocks an opponent's argument or position, attem...
부탁드립니다, 논의를 이어가 주세요.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [3월 21, 2023, 2:42오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/38 "2023-03-21T14:42:45Z")
나는 아무것도 조롱한 적이 없습니다. 비교할 대상을 찾고 있었는데, 칼에서 그 예를 찾았습니다. 칼은 매우 유용하면서도 매우 쉽게 잘못 사용할 수 있지만, 누구나 칼이 어디에나 존재하는 것을 받아들이고 있습니다.
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 2:43오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/39 "2023-03-21T14:43:11Z")
> [@RGJ](#):
>
> 이미 설명했듯이, 오픈소스라고 해서 서버에서 실행 중인 코드가 무엇인지 확인할 수 있는 방법은 없습니다.
사용 전에 코드를 수정할 수 있으므로 맞는 말입니다.
> [@RGJ](#):
>
> 그것이 어떻게 가능하다고 상상하나요? 사용자가 보거나 보지 못하는 문제를 해결하는 데 API 키가 어떻게 도움이 되는지 이해할 수 없습니다.
>
> “사용자 임의(impersonate)” 기능이 없거나 접근하기 어렵다면 어떤 일이 일어나는지 아나요? 지원 담당자가 다시 사용자에게 비밀번호를 요구하기 시작할 것입니다. 당신은 아기를 목욕물과 함께 버린 것입니다.
완전한 제거를 말한 적은 없습니다. 필요한 경우, 필요한 사람들에게 해당 옵션을 일시적으로 부여하기 위해 API 키를 사용할 수 있습니다.
앞서 언급했듯이, 커맨드 라인의 루트 접근을 통해 이를 비활성화하는 옵션을 제공하는 것은 이 기능이 공개된 상태로 존재하기를 원하지 않는 사람들에게 쉬운 해결책입니다. 심지어 커맨드 라인을 통해 임의 기능을 설정하여, 예를 들어 1명의 관리자만 사용할 수 있도록 제한하는 옵션으로 만들 수도 있습니다.
단순히 기능을 제한하거나 비활성화하는 옵션을 선택할 수 있게 해달라는 데 대해这么大的 저항을 보이는 것이 놀랍습니다. 예를 들어, 호스팅 서비스를 제공하는 당신의 경우, 당신의 필요에 따라 이를 의도적으로 비활성화하거나 제한하지 않을 것입니다.
만약 직접적인 옵션도 원한다면, 시스템이 x 관리자에게 임의로 처리되었음을 사용자에게 이메일로 알리면 됩니다. 2단계 인증(2FA)처럼 이 기능이 사용되었음을 보여주는 투명성의 층위를 만들 것입니다. 임의로 처리된 사용자는 이미 문제가 해결될 때 이 기능이 사용될 것임을 알고 있었습니다.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [3월 21, 2023, 2:45오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/40 "2023-03-21T14:45:14Z")
저의 "반대"에는 두 가지 이유가 있습니다:
- 기능을 제거하거나 접근을 어렵게 하면 오히려 잘못된 안도감을 줍니다.
- 이러한 기능이 접근하기 어렵(게) 해지면, 지원 인원은 우회로를 찾게 되며, 비밀번호 공유는 훨씬 더 위험합니다. 이는 기록되지 않을 뿐만 아니라, 비밀번호가 장기간 보관될 수 있고, 다른 서비스에서도 유효할 수 있기 때문입니다.
충분한 접근 권한을 가진 사람은 해당 이메일이 발송되지 않도록 막을 수도 있습니다.
그리고 모든 이메일은 공격 벡터가 될 수 있습니다(관리자에게 가짜 “백업 생성” 알림을 보내어 탈취된 디스커스 포럼의 구체적인 사례를 알고 있습니다).
따라서 이 기능을 잠금 해제하려면 API 키를 사용해야 합니다. 이제 관리자는 전체 접근 권한을 부여하는 API 키를 생성할 수 있으며, 다른 관리자가 왜 API 키를 생성/사용했는지 물으면 문제 해결을 위한 것이었다고 주장할 수 있게 됩니다.
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [3월 21, 2023, 2:47오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/41 "2023-03-21T14:47:01Z")
> [@kynic](#):
>
> 구글, 페이스북, 애플 그리고 다른 회사들이 이런 일을 하지 않는다고 믿는 사람이 있다면, 저는 더 이상 할 말이 없습니다… 🫡
우리가 이야기하는 것은 구글, 페이스북, 애플이 아닙니다. 오픈소스이며 셀프 호스팅을 허용하는 디스코urses에 대해 이야기하는 것입니다.
그것은 정반대여야 할 것인데 말이죠.
> [@MikeNolan](#):
>
> 어떤 시스템이든 타인의 지식이나 동의 없이 그들을 사칭할 수 있는 충분한 접근 권한과 지식을 가진 그룹이 항상 존재합니다.
저는 그것을 완전히 이해합니다.
하지만 질문은 **왜 한 번의 클릭 거리** 인지입니다. 신뢰 수준 제목을 변경하는 것은 쿼리 탐색기를 사용하거나 데이터베이스를 수동으로 관리해야 함을 의미하는데 말이죠.
_ **편집:** 두 개의 게시물을 통합했습니다._
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [3월 21, 2023, 2:48오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/43 "2023-03-21T14:48:20Z")
> [@RGJ](#):
>
> 나의 ‘저항’은 이중적입니다:
>
> - 기능을 제거하거나 접근을 어렵게 하는 것은 잘못된 안도감을 줍니다.
> - 이러한 기능이 접근하기 어렵(거나 더 어렵)게 되면, 지원 인력이 우회로를 찾아내게 되며, 비밀번호 공유는 훨씬 더 나쁜 상황입니다. 이는 로그에 남지 않고, 비밀번호가 보관될 수 있으며, 다른 서비스에도 유효할 수 있기 때문입니다.
이것은 낙하 방지 장치와 같은 안전 보호 장비에도 적용됩니다. 그렇다면 사용 시 완전한 안전이라는 잘못된 인식을 주기 때문에 PPE(개인 보호 장비)를 포기해야 하는 걸까요?
옵션은 절대적인 것이 아닙니다. 무엇이든 우회될 수 있더라도, 마음의 평화를 위한 단순한 선택 사항일 뿐입니다. Sam은 쉽게 수행할 수 없더라도, 암호화 플러그인도 모든 암호화 방식과 마찬가지로 해독될 수 있음을 공개적으로 언급했습니다.
---
### Author:  [@satonotdead](https://meta.discourse.org/u/satonotdead)
#### Post date: [3월 21, 2023, 2:50오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/44 "2023-03-21T14:50:20Z")
> [@RGJ](#):
>
> 이미 설명했듯이, 오픈소스라고 해서 서버에서 실행 중인 코드를 확인할 수 있는 방법은 없습니다.
글의 본론은 그 부분이 아니지만, 원하시면 새 글을 작성해 보세요 🙂
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [3월 21, 2023, 2:51오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/45 "2023-03-21T14:51:17Z")
개인적으로 이 주제의 핵심은 다음과 같습니다: 내가 참여하는 커뮤니티의 관리자를 신뢰할 수 있고, 또 신뢰해야 하는가?
---
### Author:  [@awesomerobot](https://meta.discourse.org/u/awesomerobot)
#### Post date: [3월 21, 2023, 3:02오후 UTC](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795/46 "2023-03-21T15:02:13Z")
지금 시점에서 이 대화에서 새로운 내용이 나올 것 같지는 않습니다… 악의적인 관리자는 이 행동을 위해 사용자 사칭 기능이 필요하지 않습니다. 게시글을 작성하고 소유권을 변경하는 것만으로 가능합니다. 관리자는 사용자를 사칭하지 않고도 기존 게시글을 편집하거나 설정을 변경할 수 있습니다. 또한 다른 비관리자 사용자에게 이 사실을 숨기기 위해 편집 이력을 삭제할 수도 있습니다. 관리자가 사용자의 계정이 수행하는 모든 내용을 확인하려면 사용자를 사칭할 필요가 없으며, 이를 위해 콘솔 접근 권한도 필요하지 않습니다.
사칭 버튼을 제거한다고 해서 계정이 더 안전해지지 않습니다. 사칭 기능이 제공하는 모든 기능을 관리자는 사칭 기능 없이도 수행할 수 있습니다.
관리자가 개인 메시지를 읽거나 게시 내용을 악의적으로 변경할까 봐 두려워 관리자를 신뢰할 수 없다면, 이 사이트를 사용하지 않는 것이 좋습니다.
[Previous page](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795.md?page=1)
[Next page](https://meta.discourse.org/t/thoughts-about-impersonate-user/258795.md?page=3)