“사용자는 관리자인지 여부를 결정해서는 안됩니다. 권한 또는 보안 시스템이 필요합니다.”

이 질문에 사용 된 예제는 최소한의 데이터를 함수에 전달 하여 사용자가 관리자인지 아닌지를 결정하는 가장 좋은 방법을 제공합니다. 일반적인 대답은 다음과 같습니다.

user.isAdmin()

이로 인해 여러 차례 반복되고 많은 투표가있었습니다.

사용자가 관리자인지 여부를 결정해서는 안됩니다. 권한 또는 보안 시스템이 있어야합니다. 클래스에 밀접하게 연결된다고해서 해당 클래스의 일부로 만드는 것이 좋은 생각은 아닙니다.

나는 대답했다.

사용자가 아무것도 결정하지 않습니다. User 객체 / 테이블은 각 사용자에 대한 데이터를 저장합니다. 실제 사용자는 자신에 대한 모든 것을 변경할 수 없습니다.

그러나 이것은 생산적이지 않았습니다. 분명히 의사 소통을 어렵게하는 근본적인 관점의 차이가 있습니다. 누군가 user.isAdmin ()이 왜 나쁜지 설명하고 "올바른"것에 대한 간단한 스케치를 그릴 수 있습니까?

실제로 보안이 보호되는 시스템에서 보안을 분리하는 이점을 보지 못했습니다. 모든 보안 텍스트는 보안이 처음부터 시스템에 설계되어야하며 개발, 배포, 유지 관리 및 수명 종료의 모든 단계에서 고려되어야한다고 말합니다. 측면에 볼트로 고정 할 수있는 것은 아닙니다. 그러나이 의견에 대해 지금까지 17 건의 투표가 중요한 것을 놓치고 있다고 말합니다.

사용자를 키로, 권한을 값으로 생각하십시오.

상황에 따라 사용자마다 권한이 다를 수 있습니다. 권한은 상황에 따라 다르므로 각 상황에 따라 사용자를 변경해야합니다. 따라서 해당 논리를 다른 곳에 (예 : 컨텍스트 클래스) 배치하고 필요한 경우 권한을 찾는 것이 좋습니다.

부작용은 시스템을 더 안전하게 만들 수 있다는 것입니다. 관련이없는 장소에 대해서는 관리자 플래그를 지우는 것을 잊을 수 없기 때문입니다.

그 의견은 잘못 표현되었습니다.

요점은 사용자 개체는 관리자, 시험 사용자, 수퍼 유저 또는인지 "결정"여부입니다 무엇이든 또는 일반의 아웃. 분명히 그것은 당신이 구현 한대로 소프트웨어 시스템이 큰 것을 결정하지 않습니다. 요점은 "사용자"여부 클래스가 해야 표현 의 객체가 나타내는 주체의 역할을, 또는이 있는지 다른 클래스의 책임입니다.

나는 원래의 의견을 그 말대로 표현하기로 선택하지 않았지만 잠재적으로 합법적 인 문제를 식별합니다 .

특히 분리를 보증하는 문제는 인증 대 권한 입니다.

인증 은 로그인하고 신원을 얻는 과정을 말합니다. 시스템이 당신이 누구 인지 알고 개인화, 객체 소유권 등과 같은 것들에 사용되는 방식입니다.

승인 은 귀하가 할 수있는 일을 말하며 , (일반적으로) 귀하가 누구 인지에 따라 결정 되지 는 않습니다 . 대신 역할이나 권한과 같은 일부 보안 정책에 의해 결정되며 이름이나 전자 메일 주소와 같은 것을 신경 쓰지 않습니다.

이 두 가지는 서로 직교로 변할 수 있습니다. 예를 들어 OpenID / OpenAuth 공급자를 추가하여 인증 모델을 변경할 수 있습니다. 새 역할을 추가하거나 RBAC에서 ABAC로 변경하여 보안 정책을 변경할 수 있습니다.

이 모든 것이 하나의 클래스 또는 추상화로 들어가면 위험 완화를 위한 가장 중요한 도구 중 하나 인 보안 코드 가 아이러니하게도 위험에 처하게됩니다.

인증 및 권한 부여가 너무 밀접하게 결합 된 시스템에서 작업했습니다. 한 시스템에는 각각 한 유형의 "역할"에 대해 두 개의 병렬 사용자 데이터베이스가있었습니다. 이를 설계 한 개인 또는 팀은 단일 물리적 사용자가 두 역할에 모두 있거나 여러 역할에 공통적 인 특정 조치가 있거나 사용자 ID 충돌에 문제가있을 수 있다고 생각하지 않았습니다. 이것은 분명히 극단적 인 예이지만, 함께 일하는 것은 엄청나게 고통 스러웠습니다.

Microsoft 및 Sun / Oracle (Java)은 전체 인증 및 권한 부여 정보를 보안 주체라고 합니다. 완벽하지는 않지만 합리적으로 잘 작동합니다. 예를 들어, .NET에서는 전자 IPrincipal를 캡슐화 하고 IIdentity, 전자는 정책 (권한) 객체이고 후자는 신원 (인증)입니다. 당신은 합리적으로 하나를 넣어하기로 결정 의문을 제기 할 수 내부에 다른의를하지만, 중요한 것은이 때문이다 대부분의 코드는 추상화의 한위한 것 쓰기 가 테스트하고 리팩터링하기 쉬운 것을 의미한다.

A를 아무 문제 없습니다 User.IsAdmin필드 ... 하지 않는 한 또한이 User.Name필드. 이것은 "사용자"개념 이 제대로 정의되지 않았 음을 의미하며 , 안타깝게도 보안과 관련하여 귀에 약간 젖어있는 개발자들 사이에서 매우 흔한 실수입니다. 일반적으로 ID 및 정책 으로 공유해야하는 유일한 것은 사용자 ID이며, 이는 우연히 Windows 및 * nix 보안 모델 모두에서 구현되는 방식입니다.

아이덴티티와 정책을 모두 캡슐화하는 래퍼 객체를 생성하는 것은 완전히 허용됩니다. 예를 들어, 현재 사용자가 액세스 할 수있는 다양한 위젯 또는 링크 외에 "hello"메시지를 표시해야하는 대시 보드 화면을 쉽게 만들 수 있습니다. 이 랩퍼 는 ID 및 정책 정보를 랩핑 하고 해당 정보를 소유한다고 주장하지 않는 한. 즉, 집계 루트 로 표시되지 않는 한 .

YAGNI 등으로 인해 새로운 애플리케이션을 처음 설계 할 때 단순한 보안 모델은 항상 좋은 생각처럼 보이지만 , 놀랍게도 새로운 기능이 추가되기 때문에 나중에 다시 물어 뜯는 경우가 거의 있습니다!

따라서 자신에게 가장 적합한 것을 알고 있으면 인증 및 권한 부여 정보를 별도로 유지하게됩니다. 지금 "권한 부여"가 "IsAdmin"플래그만큼 단순하더라도 인증 정보와 동일한 클래스 또는 테이블의 일부가 아닌 경우 보안 정책이 필요한 경우 이미 잘 작동하는 인증 시스템에서 재구성 수술을 수행 할 필요가 없습니다.

글쎄, 최소한 단일 책임 원칙을 위반 하는 것 입니다. 변경이있을 경우 (여러 관리자 수준, 훨씬 더 다른 역할?) 이런 종류의 디자인은 상당히 지저분하고 유지하기가 끔찍할 것입니다.

보안 시스템을 사용자 클래스와 분리하여 두 가지 역할을 모두 정의 할 수있는 이점을 고려하십시오. 더 깨끗하고 유지 관리하기 쉬운 디자인으로 마무리합니다.

어쩌면 잘못 표현 된 문제는 User수업 에 너무 많은 비중을 두는 것 입니다. 아니요, User.isAdmin()해당 의견에서 제안한 것처럼 방법을 사용하는 데 보안 문제가 없습니다 . 결국, 핵심 클래스 중 하나에 악의적 인 코드를 삽입하기에 충분한 코드를 가진 사람이 있다면 심각한 문제가 있습니다. 반면 User에 모든 컨텍스트의 관리자인지 여부를 결정하는 것은 이치에 맞지 않습니다 . 포럼의 중재자, 첫 페이지에 게시물을 게시 할 수있는 편집자, 편집자가 게시 할 내용을 쓸 수있는 작성자 등 다른 역할을 추가한다고 상상해보십시오. User객체 에 배치하는 방법 User을 사용하면 클래스와 직접 관련이없는 너무 많은 메소드와 너무 많은 논리 가 생길 수 있습니다.

대신 다른 유형의 권한 열거 형과 PermissionsManager클래스를 사용할 수 있습니다 . 아마도 PermissionsManager.userHasPermission(User, Permission)부울 값을 반환하는 것과 같은 메소드를 가질 수 있습니다 . 실제로는 (Java에서) 다음과 같이 보일 수 있습니다.

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

이는 실제로 Rails 방법과 동일 before_filter하며, 실제 환경에서 이러한 유형의 권한 검사 예를 제공합니다.

Object.isX ()는 객체와 X 사이의 명확한 관계를 나타내는 데 사용되며 부울 결과로 표시 될 수 있습니다. 예를 들면 다음과 같습니다.

Water.isBoiling ()

Circuit.isOpen ()

User.isAdmin ()은 시스템의 모든 컨텍스트 내에서 '관리자'라는 단일 의미를 가정 합니다. 사용자는 시스템의 모든 부분에서 관리자입니다.

간단하게 들리지만 실제 프로그램은이 모델에 맞지 않을 것입니다. 사용자가 [X] 리소스를 관리해야하지만 [Y]는 아니고보다 뚜렷한 유형의 관리자 ([프로젝트])가 있어야합니다. ] 관리자 대 [시스템] 관리자).

이 상황에서는 일반적으로 요구 사항을 조사해야합니다. 클라이언트가 User.isAdmin ()이 실제로 나타내는 관계를 원하는 경우는 거의 없으므로 설명없이 그러한 솔루션을 구현하는 것을 망설이지 않습니다.

포스터는 단순히 다르고 복잡한 디자인을 염두에 두었습니다. 제 생각 User.isAdmin()에는 괜찮습니다 . 나중에 복잡한 권한 모델을 소개하더라도 움직일 이유가 거의 없습니다 User.isAdmin(). 나중에 User 클래스를 로그인 한 사용자를 나타내는 객체와 사용자에 대한 데이터를 나타내는 정적 객체로 분할 할 수 있습니다. 그렇지 않을 수도 있습니다. 내일을 위해 내일을 구하십시오.

실제로 문제는 아닙니다 ...

에 문제가 없습니다 User.isAdmin(). 나는 PermissionManager.userHasPermission(user, permissions.ADMIN)SRP라는 거룩한 이름으로 코드를 덜 명확하게 만들고 가치있는 것을 추가하지 않는 것과 같은 것을 선호합니다 .

나는 SRP가 문자 그대로 조금 해석되고 있다고 생각합니다. 클래스가 풍부한 인터페이스를 갖는 것이 좋습니다. SRP는 개체가 단일 책임에 속하지 않는 모든 것을 공동 작업자에게 위임해야 함을 의미합니다. 사용자의 관리자 역할이 부울 필드보다 관련이있는 경우 사용자 개체가 PermissionsManager에 위임하는 것이 좋습니다. 그러나 이것이 사용자가 isAdmin방법 을 유지하는 것이 좋지 않다는 것을 의미하지는 않습니다 . 실제로 이는 응용 프로그램이 단순에서 복합으로 졸업 할 때 User 개체를 사용하는 코드를 변경해야 함을 의미합니다. IOW는 고객이 관리자인지 여부에 대한 질문에 답변하기 위해 실제로 필요한 것이 무엇인지 알 필요가 없습니다.

...하지만 왜 정말로 알고 싶습니까?

즉, 위젯 업데이트와 같이 사용자가 특정 작업을 수행 할 수 있는지 여부와 같은 다른 질문에 대답 할 수있는 것을 제외하고는 사용자가 관리자인지 알 필요가 거의없는 것 같습니다. 이 경우 위젯에 다음과 같은 메소드를 사용하는 것이 좋습니다 isUpdatableBy(User user).

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

이렇게하면 위젯이 사용자가 업데이트하기 위해 충족해야하는 기준을 알 수 있으며, 관리자인지는 사용자가 알아야합니다. 이 디자인은 의도에 대해 명확하게 전달하며,시기와시기에보다 복잡한 비즈니스 로직으로 쉽게 졸업 할 수 있습니다.

[편집하다]

의 문제 되지 가지고 User.isAdmin()및 사용PermissionManager.userHasPermission(...)

사용자가 관리자 (또는 관리자 역할)인지 알고 싶다면 PermissionManager 객체에서 메소드를 호출하는 것보다 User 객체에서 메소드를 호출하는 것을 선호하는 이유를 설명하기 위해 내 대답에 추가 할 것이라고 생각했습니다.

이 사용자가 관리자 라는 질문을 할 때마다 항상 User 클래스에 의존한다고 가정하는 것이 공정하다고 생각합니다 . 그것은 당신이 제거 할 수없는 의존성입니다. 그러나 질문을하기 위해 사용자를 다른 개체로 전달해야하는 경우 사용자에게 이미있는 개체 위에 해당 개체에 대한 새로운 종속성을 만듭니다. 질문이 많으면 추가 종속성을 만드는 곳이 많으며 종속성 중 하나가 필요로 할 경우 변경해야 할 곳이 많습니다.

의존성을 User 클래스로 옮기는 것과 이것을 비교하십시오. 이제 갑자기 클라이언트 코드 (질문을 요구 해야하는 코드 는이 사용자는 admin ) 가이 질문에 대한 답변의 구현과 관련이없는 시스템이 있습니다. 권한 시스템을 자유롭게 변경할 수 있으며 한 클래스에서 하나의 메소드 만 업데이트하면됩니다. 모든 클라이언트 코드는 동일하게 유지됩니다.

isAdmin권한 하위 시스템에 대한 User 클래스의 종속성을 생성하는 것에 대한 두려움에 대해 사용자에 대한 메소드가 없다는 것을 주장하는 것은 1 달러를 벌기 위해 달러를 소비하는 것과 비슷합니다. 물론 User 클래스에서 하나의 종속성을 피할 수는 있지만 질문을해야하는 모든 위치에서 하나를 작성해야합니다. 좋은 거래는 아닙니다.

이 토론은 Eric Lippert의 블로그 게시물을 상기시켜 주었으며 클래스 디자인, 보안 및 정확성에 대한 비슷한 토론에서 주목을 받았습니다.

왜 많은 프레임 워크 클래스가 봉인되어 있습니까?

특히 Eric은 다음과 같이 지적합니다.

4) 안전합니다. 다형성의 요점은 동물처럼 보이지만 실제로 기린 인 물체를 전달할 수 있다는 것입니다. 여기에는 잠재적 인 보안 문제가 있습니다.

봉인되지 않은 유형의 인스턴스를 취하는 메소드를 구현할 때마다 해당 유형의 적대적 인스턴스에 직면 할 때 해당 메소드를 강력하게 작성해야합니다. 적대적인 웹 페이지가 구현의 서브 클래스를 생성하고, 가상 메소드를 재정 의하여 논리를 어지럽히고 전달하는 작업을 수행 할 수 있기 때문에 구현에 대해 사실을 알고있는 불변에 의존 할 수 없습니다. 클래스를 봉인 할 때마다 , 나는 그 클래스가하는 일을 알고 있다는 확신을 가지고 그 클래스를 사용하는 메소드를 작성할 수 있습니다.

이것은 접선처럼 보이지만 다른 포스터가 SOLID 단일 책임 원칙에 대해 제기 한 점과 관련이 있다고 생각합니다 . User.IsAdmin메서드 나 속성 을 구현하지 않는 이유로 다음 악성 클래스를 고려하십시오 .

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

물론, 그것은 약간의 확장입니다. 아직 IsAmdmin가상 방법을 제안하지는 않았지만 사용자 / 역할 아키텍처가 매우 복잡해지면 일어날 수 있습니다. (혹은 그렇지 않을 public class Admin : User { ... }수도 있습니다 . 고려해보십시오 . 그러한 클래스에는 위의 코드가 정확히있을 수 있습니다.) 악성 바이너리를 제자리에 배치하는 것은 일반적인 공격 경로가 아니며 모호한 사용자 라이브러리보다 혼란을 일으킬 가능성이 훨씬 높습니다. 실제 shenanigans의 문을 여는 Privilege Escalation 버그 일 수 있습니다 . 마지막으로 악의적 인 바이너리 또는 개체 인스턴스가 런타임에 들어간 경우 "Privilege 또는 Security System"이 비슷한 방식으로 대체되는 것은 그리 쉬운 일이 아닙니다.

그러나 Eric을 염두에두고 사용자 코드를 특정 유형의 취약한 시스템에 넣으면 게임을 잃어 버릴 수 있습니다.

아, 그리고 기록을 정확하게하기 위해, 나는 질문에 대한 가정에 동의합니다.“사용자는 그것이 관리자인지 아닌지를 결정해서는 안됩니다. 권한 또는 보안 시스템이 필요합니다.”시스템 User.IsAdmin에서 코드를 실행하는 경우 코드를 100 % 제어하지 않는 방법은 좋지 않습니다 Permissions.IsAdmin(User user). 대신 수행해야합니다 .

여기서 문제는 다음과 같습니다.

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

권한이있는 메소드가 호출자에게 충분한 권한이 있는지 확인해야하는 경우 보안을 올바르게 설정했는지 확인하십시오.이 경우 점검이 불필요한 것입니다. 또는 보안에 대한 자체 결정을 내릴 수있는 권한이없는 클래스를 가지고 있지 않거나 신뢰하지 않습니다.