액세스 제어 설계 패턴

StackOverflow https://stackoverflow.com/questions/1921035

문제

PHP 응용 프로그램을 작업하고 있으며 일부 객체에 액세스 컨트롤을 추가하고 싶습니다. 나는이 질문을 PHP로 태그하지 않았다.

'서비스 클래스'가 있다고 말합니다. 

abstract class Service {


}

많은 서비스가 이것을베이스 클래스로 사용합니다. 한 가지 의사 예제는 다음과 같습니다.

class Companies extends Service {

  function getCompanyInfo($id) {
      //...
  }

}

나중에 도로를 따라 내려다 보면 액세스 제어를 추가하고 싶습니다. 'getCompanyInfobyid'방법은 '읽기'작업이므로 '읽기'권한이 필요합니다.

이 시점에서 나는 이것을 다음과 같이 구현할 수 있습니다.

  1. 서비스 클래스에 AccessControl을 추가하십시오. GetCompanyInfobyid와 같은 모든 방법은 작업을 완료하고 결과를 반환하기 전에 내부적으로 'Hasprivilege'방법을 호출해야합니다.
  2. 모든 서비스 객체를 내부 객체에서 메소드를 호출하기 전에 권한을 점검 할 프록시 객체에 모든 서비스 객체를 감싸십시오.
  3. 액세스 제어를 완전히 분리하고 방법을 호출하기 전에 '발신자'가 권한을 점검하도록 강제하십시오.

모든 옵션에 대한 단점 :

  1. 이를 위해서는 모든 서비스를 변경해야하며 액세스 제어를 알고 있어야합니다. 나는 이것이 우려의 분리에 반대한다고 생각한다.
  2. 이것은 다형성과 같은 OOP 기능을 깨뜨립니다. 발신자는 더 이상 서비스가 지원하는 인터페이스를 더 이상 알지 못합니다.
  3. 이것은 가장 유연하지만 큰 단점은 허가를 확인하는 것이 이제 암시 적이라는 것입니다. 개발자는 '잊어 버리거나 복잡한 코디 패스로 인해 무단 서비스를 호출 할 수 있습니다.

이것에 전적으로 접근하는 더 좋은 방법이 있습니까?

도움이 되었습니까?

해결책

다른 솔루션은 1의 약간의 변형 일 수 있습니다.

전.

class Service
{
  var $ACL = //some hash map with acl
}

class Companies extends Service
{

  function getCompanyById($id)
  {
    //real code
  }
}

class SafeCompanies extends Companies
{
//If a method must be "protected" with an ACL, you must override them in this way
  function getCompanyById($id)
  {
    $this->check('read'); //raise an exception if current user haven't READ privilege
    parent::getCompanyById($id);    
  }  
}

이런 식으로 당신은 책임을 혼합하지 않고 여전히 다형성을 사용할 수 있습니다.

내 2 센트

다른 팁

Java EE 모델은 2 라인에 있습니다. 코드는 "컨테이너"에서 실행되며, 컨테이너는 인터페이스 진입 지점 (서블릿의 URL, EJBS의 메소드)에 대해 컨테이너를 알리고 이러한 진입 지점을 사용할 수있는 역할을 정의합니다. . Adminstrator는 인증 정보 (예 : LDAP 사용자 및 그룹)를 특정 역할에 매핑하고 컨테이너는 진입 지점에 대한 액세스 권한을 부여 할 때 해당 매핑을 상담합니다.

여기서 핵심은 컨테이너가 코드에 대해 "알고있다"는 것입니다. 효과적으로 매우 영리한 대리입니다.

컨테이너가 없으면 나는 아마도 어떤 종류의 측면 지향 기술을 사용하여 프록시 접근법을보고있을 것입니다.

나는 당신이 옵션 3이 매우 부서지기 쉽고 고객 프로그래머에 대해 너무 많은 책임이라고 생각합니다.

10 년 후 ... 세계는 그 이후로 상당히 진화했으며, 특히 완전히 새로운 패러다임이 나타났습니다 : 외부화 된 승인. 공정하게 말하면, 각각의 모든 개발 프레임 워크에는 자체 버전이 있습니다 (예 : Ruby의 Cancancan 또는 Java의 Spring Security 또는 C#의 클레임 기반 승인). 외부화 된 승인은 비즈니스 로직에서 권한 부여 논리를 분리하는 것을 목표로합니다. 아이디어는 승인 요구가 비즈니스 논리와 독립적으로 발전 할 수 있다는 것입니다. 예를 들어 비즈니스 로직은 은행 계좌에 대한 액세스를 제공합니다 (보기 / 편집 / 삭제 / 전송). 기능은 안정적입니다. 가까운 시일 내에는 변하지 않습니다. 그러나 법률 (GDPR, 오픈 뱅킹 ...) 또는 다른 요구 사항 (위임, 부모-자식, VIP ...)으로 인해 승인 요구가 발전 할 수 있습니다. 이것이 귀하가 승인을 유지하려는 이유입니다. 외부.

그렇게하려면 모델이 있습니다 속성 기반 액세스 제어 () 더 잘 알려진 역할 기반 액세스 제어에 대한 진화 / 확장 (). RBAC에서 액세스 제어는 ID 중심입니다. 사용자, 역할 및 사용자가 속한 그룹을 기반으로합니다. 그것은 종종 충분하지 않습니다. ABAC에서는 사용자, 리소스, 컨텍스트 (시간) 및 조치의 속성을 사용할 수 있습니다. ABAC은 또한 표준화 된 정책 언어를 사용하여 일반 영어로 정책을 작성할 수 있습니다. 또는 또는 Rego). 클라우드 플랫폼 (AWS 및 Google)은 자체 언어 (각각 Google IAM 및 AWS IAM)를 구현했습니다.

ABAC의 이점 중 일부는 다음과 같습니다.

  • 유연성 : Apps / API를 터치하지 않고 승인 정책을 변경할 수 있습니다.
  • 재사용 성 : 동일한 정책을 데이터, API, 앱 또는 인프라에 적용 할 수 있습니다.
  • 가시성 : 논리를 하드 코딩하는 대신 정책으로 승인을 표현합니다. 즉, 정책을 쉽게 감사하고 가능한 것이 무엇인지 /하지 않는 것을 이해할 수 있습니다.
  • 감사 : ABAC를 사용하면 부여되거나 거부 된 모든 액세스의 단일 로그를 얻습니다.

자세한 내용은 Wikipedia 페이지를 확인하십시오. ABAC 그리고 알파 만큼 잘 ABAC의 NIST 페이지.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top