네, 확인했습니다. 알아두겠습니다.
저희 조직에서 해당 측면을 보안 문제로 간주하여 우리를 차단할 수 있는 권한을 가진 사람들의 말을 인용하겠습니다. “이 시스템이 무단 조직의 누군가가 들어올 수 있게 할 수 있다면, 당신의 주의와 관계없이 결국 그렇게 될 것이라고 가정해야 합니다.” 실제로 정확히 그런 일이 발생했습니다. 해당 “기능”(초대 전용인 경우 "must_approve_user"가 아무런 효과가 없으므로, 기능이라기보다는 비기능이라고 할 수 있습니다)이 활성화되어 있었고, 우리는 초대하려는 대상에게 제한 없는 초대장을 발급했습니다. 당연히 그중 한 명이 해당 제한 없는 초대 링크를 다른 조직에 공유했습니다.
이로써 @tobiaseigen 님에게도 답변드립니다.
저희는 수백 명의 인원이 참석하는 회의와 컨퍼런스를 개최합니다. 이들은 포럼 가입이 허용된 승인된 조직의 구성원들입니다. 하지만 그중 일부는 (저희가 통제할 수 없는 상위 정책상의 이유로) 포럼 가입이 허용되지 않은 다른 조직에서 온 경우도 있습니다.
해당 초대 링크는 “자유롭게” 유포되었습니다. 스태프가 주의했음에도 불구하고, 그 링크를 가진 “묵시적으로 승인된” 사람들이 무엇을 할지 저희가 통제할 수 없기 때문입니다. 정의상 그 링크는 "제한 없음"이므로, 그들은 원하는 누구에게든 전달할 수 있습니다. 만약 그것이 “설계상” 그렇게 되어 있고 묵시적 승인을 의미한다면, 이 제한 없는 초대 링크는 어디든 갈 수 있으며, 결국 그렇게 될 것입니다. 이것이 저희 IT 부서 책임자가 정당한 이유를 들어 말했던 내용입니다. 저희는 그것을 알고 있었기 때문에, 그것이 본래 의도한 보안 계층으로 작용하도록 *must_approve_users"를 활성화했습니다.
이것이 기능인지 버그인지에 대한 질문이 있는 것 같습니다. 저는 전문 프로그래머가 아니므로(저는 천체물리학자입니다) 그것은 여러분이 결정할 문제입니다. 저는 그저 이 놀라운 플랫폼을 계속 사용할 수 있도록, 우리에게 심각한 "문제"를 야기한 것을 보고할 뿐입니다.
저는 옵션 3에 전적으로 찬성하며, 저희 연구소와 포럼 스태프도 마찬가지입니다. 별도 통지가 있을 때까지, 스태프에게는 제한 없는 초대를 사용하지 않도록 지시되었습니다. 이로 인해 스태프는 초대하려는 모든 사람의 개별 이메일 주소를 수동으로 추가해야 하는 추가 부담을 지게 되었습니다(컨퍼런스의 경우 수백 명의 참가자가 넘는 경우가 많습니다…). 모든 회의, 이벤트 등에서 이를 수행해야 하는 것은 우리 성장에 높은 마찰을 더할 것이며, 추가된 업무량 때문에 일부 스태프가 떠나게 될 것을 예견할 수 있습니다(대부분은 자원봉사자이며, 다른 업무로 이미 과부하 상태입니다)."