여기 있는 다른 분들처럼, 특정 기능(전체가 아님)에 대해 staff와 admin이 접근할 수 있는 것을 명시하는 RBAC(역할 기반 접근 제어)의 추가 계층으로 접근 제어 모델이 개선될 것이라고 동의합니다.
예를 들어, 사이트는 더 많은 관리자(admin)를 추가하고 싶을 수 있지만, 더 작은 범위의 관리자 RBAC 권한을 부여하는 것을 선호할 수 있습니다. 예를 들어, 사이트 전체 백업을 다운로드할 수 있는 권한을 부여하거나 부여하지 않거나, 특정 직원(staff) 작업 로그 파일에 접근할 수 있는 권한을 부여하는 등의 경우입니다. 또한, 사이트는 일부 직원이 관리자나 개발자의 직원 작업을 볼 수 있는 RBAC 권한을 갖지 않도록 보장하고 싶을 수 있으며, 이는 특히 더 “개인적인” 것으로 간주되는 특정 작업에 해당합니다.
모든 사이버 보안 전문가들은 (직접적인 경험을 통해 알고 있듯이) 어떤 조직에 대한 가장 큰 위협이 외부 해커나 공격자가 아니라 "불만족스러운 내부자(disgruntled insider)"라는 것을 배우고 있습니다. 이 기본적인 IT 보안 위험에 대해 의심의 여지가 없으며, 훈련을 받거나 풍부한 현장 경험을 가진 IT 보안 전문가들에게는 잘 확립된 지식입니다. 따라서 "단순히 관리자를 신뢰하라"거나 "직원을 신뢰해야 한다"는 식으로 내부자 위협을 무시하는 것은 IT 전문가들에게 기술적인 해결책이 아닙니다. 아무리 신뢰할 수 있고 오랜 기간 충성해 온 직원이라 해도, 그들의 삶을 변화시켜 "불만족스러운 직원"으로 변하게 할 수 있는 개인적인 문제에 직면할 수 있습니다. 또한, 가장 많은 권한을 가진 직원이 가장 많은 실수를 하는 경향이 있으며, 일반적으로 선의의 직원/관리자 실수는 어떤 해커보다 더 많은 다운타임을 유발한다는 것을 우리는 잘 알고 있습니다.
얼마 전, 저는 우리 사이트를 위해 Discourse의 class Guardian을 수정하는 것을 고려해 보았지만, 해당 클래스를 더 자세히 살펴본 후, Discourse의 RBAC를 강화하기 위한 최소한의 양의 몽키 패치(monkey patch) 코드를 작성할 수 있는 "간단한 해결책"이 있는지 명확하지 않았습니다. 본성이 게으르고 가능한 한 간단한 솔루션을 만드는 것을 선호하는 저로서는, 이 아이디어를 보류하고 다른 “잘 지불되는 고객” 프로젝트로 넘어갔습니다.
그 후, 저는 코드 수준을 한 단계 낮추어 staff와 admin의 일부 기능을 developer로 이전하는 것을 고려해 보았지만, 이 접근법은 너무 많은 몽키 패치를 필요로 하여 당시에는 좋은 아이디어가 아니라고 생각했습니다. 결국, 10개의 패치 대신 1개의 패치로 무언가를 달성할 수 있다면, 당연히 1개의 패치가 더 좋습니다.
아직까지 이 Discourse 코어 부분을 더 깊이 살펴보고 “상대적으로 간단한” 플러그인을 통해 작성할 수 있는 “쉬운” RBAC 플러그인 강화가 있는지 확인할 시간이나 "급한 요구사항"이 없었습니다.
솔직히 말해서, 저는 아직 최고의 Ruby 전문가가 아니고, 대부분 자신을 “Ruby 코더 지망생” 정도로 생각합니다. (LOL) 아마도 이미 간단한 RBAC 플러그인 솔루션이 존재할 가능성이 높다고 확신하지만, 개인적으로는 아직 찾지 못했으며, 훨씬 더 경험 많은 Ruby 개발자가 코드를 빠르게 살펴보고 어떻게 접근해야 하는지 볼 수 있을 것입니다.
제 아이디어는 역할에 기반하여 특정 RBAC 권한을 제한하거나 부여하는 새로운 불리언 사이트 설정을 추가하고, 그런 다음 플러그인 내의 몽키 패치를 통해 해당 불리언 값을 코드의 적절한 부분에 추가하는 것이었습니다. 그러나 앞서 언급했듯이, 저는 "여러 개