주요 명확화 사항 및 더 잘 다듬어진 제안 기준을 추가하여, 이 기능 개선의 이점을 커뮤니티 구성원들이 더 잘 이해할 수 있도록 수정했습니다.
이메일 편집 가능(Email Editable) 설정을 업데이트하여, 이메일 주소를 누가 편집할 수 있는지에 대한 추가 옵션을 제공해야 합니다. 해당 설정은 예를 들어 다음과 같이 구성됩니다.
모든 사용자(All Users)
사용자만(Users Only) [일반 관리자나 모더레이터는 Rails 콘솔을 사용하거나 설정을 변경하지 않는 한 편집할 수 없습니다.]
스태프만(Staff Only)
관리자만(Admins Only)
설정이 켜져(on) 있는 경우(기본값), 해당 작업을 관리자로 수행하기 위한 Sudo-Mode 가드레일을 도입해야 합니다 [편집 대상 계정에 속한 사용자가 아닌 경우]. 이를 통해 아래에서 언급된 몇 가지 핵심 사항을 원치 않는 변경으로부터 보호하면서 이 설정을 도입할 수 있습니다.
이유/이 작업이 필요한 이유
설정 변경에 대한 통제를 원하거나(예: 변경 요청을 받아야 하거나, 보안 관행상 필요하거나, 기타 이유), 또는 다른 이유로 설정을 꺼(off) 두었으나, 어떤 이유로든 이메일을 편집해야 하는 경우가 있습니다. 이 설정이 꺼져 있으면 관리자조차 이메일을 편집할 수 없습니다.
여기서 새로운 문제가 발생합니다. 하나 이상의 사용 사례가 해당되는 경우입니다.
현재 사용자의 이메일을 편집하려면, 1) 다른 탭에서 설정을 켜고 빠르게 이메일을 편집하거나, 2) Rails 콘솔을 열어 이메일을 수동으로 변경해야 합니다.
*대부분의 일상적인 운영 관리자에게 있어, 설정이 존재함에도 불구하고 모든 작업을 Rails 콘솔에만 의존하는 것은 원치 않는 기술적 어려움으로 이어질 수 있습니다.
왜 추가적인 가드레일이 이 기능을 현실로 만들 수 있는지:
기술적 영향으로 인해 설정이 켜져 있는 경우, 해킹된 사용자의 이메일이 변경될 수 있습니다.
관리자가 실수하거나 권한 없는 변경을 할 수 있습니다.
사용자는 해당 접근 권한을 가진 사람들이 악의적인 변경으로부터 보호받고 있다고 느낄 것입니다.
이 주제는 마지막으로 2015년에 논의되었습니다. 이메일을 편집할 수는 있지만, 관리자 뷰에서는 편집할 수 없으며, 사용자 설정 뷰로 이동하라는 메시지가 표시됩니다. 저는 그렇게 하기도 하지만, 이 설정의 제약 사항으로 인해 관리자로서도 편집할 수 없습니다.
네, 이 부분에는 매우 강하게 반대합니다. 당신의 구체적인 사용 사례가 당신에게는 충분히 단순해 보일 수 있지만, 이를 위해 UI에 간단한 오버라이드를 구현하는 것은 매우 미미한 편의성 향상 대비 상당한 보안 위험을 초래합니다.
마찰은 보안 기능입니다!
따라서 Rails 콘솔을 사용하거나 사이트 전체 설정을 변경해야 하는 불편함은 사실 중요한 보안 기능입니다. 이는 ‘보안 브레이크’ 역할을 하여 매우 민감한 작업에 대해 관리자가 의도적이고 마찰이 큰 과정을 거치도록 강제하기 때문입니다.
사용자의 이메일 주소를 변경하는 것은 해당 계정의 열쇠를 넘겨주는 것과 동일합니다. 새로운 이메일 주소는 비밀번호 재설정을 트리거하는 데 사용될 수 있기 때문에, 이는 원래 사용자를 계정에서 잠금 상태로 만들고 새로운 이메일 소유자에게 완전한 제어권을 부여하는 효과를 냅니다.
이러한 마찰이 방지하는 주요 공격 벡터:
관리자 계정 탈취! - 이것이 가장 중요한 위험입니다. 공격자가 관리자 계정에 접근하게 되면 (피싱, 비밀번호 재사용 등), 단순한 UI 버튼이나 토글만으로도 다른 사용자(다른 스태프 포함)의 계정을 조용하고 쉽게 탈취할 수 있습니다. Rails 콘솔을 통한 셸 접근 요구는 강력한 보안 계층을 제공합니다.
사회공학 기법! - 이는 사회공학 기법의 가능성을 열어줍니다. 악의적인 사용자는 합법적인 사용자를 사칭하여 관리자에게 이메일 주소 변경을 설득할 수 있습니다. 다시 한번 말하지만, 현재 높은 마찰을 수반하는 과정은 관리자가 요청의 진위를 확인하거나 고려할 가능성을 훨씬 높입니다.
내부자 위협 - 악의적인 관리자가 이 기능을 악용하여 계정을 탈취할 수 있습니다.
이러한 종류의 드물고 고위험한 관리 작업에 대해, Rails 콘솔은 작업을 수행하는 사람이 손상된 세션이 아닌 서버 접근 권한을 가지고 있음을 보장하므로 적절합니다. 또한 이 작업은 의도적이며 특정 기술적 지식을 필요로 하며(셸 히스토리에 기록됩니다).
걱정해 주신 마음은 감사하지만, 전체적인 상황을 오해하고 계신 것 같습니다. "보안"에 대한 주장에도 심각한 허점이 포함되어 있거든요.
이 설정이 켜져 있는 경우 이미 이메일을 수정할 수 있습니다. 그리고 기본적으로 켜져 있는 상태입니다.
관리자 계정 탈취! - 이것이 가장 중요한 위험입니다. 공격자가 관리자 계정에 접근하게 되면(피싱, 비밀번호 재사용 등), 단순한 UI 버튼이나 토글을 통해 다른 사용자(다른 직원 포함)의 계정을 조용하고 쉽게 탈취할 수 있습니다. rails 콘솔을 통한 셸 접근이 요구되는 것은 강력한 보안 계층을 제공합니다.
관리자 계정이 탈취되면, 침입자는 이미 현재 존재하는 설정을 켜서 언급하신 일들을 수행할 수 있습니다.
사용자의 이메일 주소를 변경하는 것은 해당 계정의 열쇠를 넘겨주는 것과 같습니다. 새로운 이메일 주소를 사용하면 비밀번호 재설정을 트리거할 수 있어, 원래 사용자는 계정에서 잠겨 나오게 되고 새로운 이메일 소유자가 완전한 제어를 하게 됩니다.
이러한 드물지만 고위험인 관리 작업의 경우, rails 콘솔이 적절합니다. 작업을 수행하는 사람이 손상된 세션이 아닌 서버 접근 권한을 가지고 있음을 보장하기 때문입니다. 또한 이 작업은 의도적으로 수행되며 특정 기술 지식이 필요하고(셸 히스토리에 기록됩니다).
항상 그런 것은 아니며, 처음 게시물에서 말했듯이 설정을 켜고 끄기만 하면 편집 기능을 활성화할 수 있습니다. 유일한 문제는, 기본적으로 켜져 있어야 할 설정을 토글하는 것이 관리자가 아닌 사용자의 이메일 편집 기능을 도입한다는 점입니다. 반면, 단순한 편집 작업이 이루어지는 상황에서는 그렇지 않습니다.
더 생각해 보니, 해당 설정이 편집 창에서 "보안상 위험"한데다 모든 관리자가 rails 콘솔에 접근할 수 있는 것은 아니기(예를 들어 호스팅 사이트의 경우) 때문에, sudo와 유사한 고마찰 UI 방식이 최선의 해결책일 것 같습니다.
예를 들어 관리자가 새 이메일을 저장하려고 할 때, 모달 다이얼로그가 나타나서 해당 작업을 확인하기 위해 본인 비밀번호를 다시 입력하도록 강제하는 방식(활성화된 경우 2FA 챌린지 포함)이 어떨까요? 당연히 이 작업은 스태프 로그에 상세히 기록되어야 합니다. 계정 탈취를 보고할 수 있는 합법적인 사용자에게 기회를 주기 위해, 어쨌든 사용자의 필수 인증이 필요하다고 생각합니다. 또한 변경 사항을 확인하기 위해 새 이메일 주소에도 알림을 보내는 것이 좋을까요?
관리자가 사용자의 요청만으로 이메일 주소를 변경할 수 있다는 아이디어에는 매우 반대합니다. 인증을 위한 어떤 형태의 마찰이나 복잡성이 반드시 필요합니다.
이 기능이 언제 변경되었는지 궁금합니다. 지난 몇 년간 저는 관리자 권한으로 이메일 주소를 변경하여 회원 계정을 수정해 왔습니다. 이는 부주의하거나 실수로 회원의 익명성을 처리한 경우 계정을 복구하는 데 유용합니다.
따라서 이 문제를 app.yml에서 수정하여 UI에서 관리자 접근 권한을 복원할 수 있을까요? 관리자가 주의 깊게 관리한다면 관리자 계정은 적절하게 보호되어야 합니다.
그럼에도 불구하고, Discourse는 관리자 기능에 대해 더 세밀한 제어를 위해 관리자 계층 구조(Admin Tiering)를 허용해야 합니다. (기존 토론). 최고 관리자 계정은 완전한 권한/통제를 갖는 것이 이상적입니다. 반면, 일부 관리자는 테마 설정에 대한 접근 권한만 필요할 수 있습니다.
이것은 Impersonate 기능이 발견될 때 제기된 우려 사항이었습니다. 물론 사용자 문제를 해결하는 데 도움이 될 수 있다는 점을 논할 수 있습니다. 또는 일반 사용자로서 기능을 테스트하기 위해 테스트 계정으로 전환하는 것도 가능합니다. 하지만 탭/창을 사용하여 테스트 사용자로 로그인하는 것은 매우 간단합니다.
이제 단순하지만 지능적인 해결책은 Linux와 유사한 가드레일을 추가하여 특정 기능을 관리자로서 사용하려면 추가적인 사이트 비밀번호를 요구하는 것입니다. 예를 들어 사용자 이메일 주소를 변경하는 경우입니다.
방금 확인해 보았습니다. 제 사이트에서는 모두 관리자도 편집할 수 없도록 되어 있습니다. 따라서 업데이트로 인해 이 동작이 변경된 것 같습니다. 일반 사용자는 이메일 주소를 변경할 수 없었지만, 과거에는 제가 관리자로서 분실된 이메일 계정에 대해 이 작업을 수행한 적이 있습니다. 또한, 반대하는 사람들을 익명화하던 문제적인 모더레이터가 있었을 때에도(그 문제는 해당 모더레이터가 다른 회사로 이직하면서 해결되었습니다) 제가 이메일 주소를 변경한 적이 있습니다.
관리자의 이메일 주소 변경 기능은 모든 사용자에게 활성화하는 것과 별개의 설정으로 분리되어야 합니다. 필요하다면, 관리자에게만 이 기능을 활성화하기 위해 초기에 콘솔에서 변경해야 할 수도 있습니다.
참고:
방금 사이트 설정을 확인해 보니 '켜기’로 설정되어 있으며, 편집 옵션을 '환경설정’으로 이동시켜 편집하도록 했습니다. 과거에는 관리자 사용자 페이지에서 직접 편집할 수 있었는데, 지금은 관리자를 사용자 환경설정 페이지로 안내하는 안내문이 없습니다.
전체적으로 훨씬 좋아질 거라고 생각합니다.