요약

  • RFC 3341은 가장 구체적으로 일치하는 owner/actor 접근 항목을 선택하므로, 정확히 일치하는 항목을 삭제하면 일부 작업을 여전히 허용하는 더 넓은 와일드카드 항목이 드러날 수 있었습니다.
  • 철회는 때때로 더 구체적인all:none항목을 유지하는 것을 요구했습니다. 삭제된 행, 성공한 변경 응답, owner에 대한 알림, 유효한 결정, 강제된 결과는 서로 다른 접수 증거였습니다.

RFC 3341은 이 예를 평이한 언어로 제시합니다. 이름이 지정된 actor에 대한 접근 항목 하나는 핵심 데이터 전달과 presence 구독 및 감시를 허용합니다. 같은 도메인의 모든 actor에 대한 다른 항목은 핵심 데이터 전달을 허용합니다. 이름이 지정된 actor의 항목이 삭제되면, 그 actor는 presence 권한을 잃지만 도메인 전체 규칙을 통해 데이터 권한은 유지합니다.

삭제는 성공했습니다. 의도된 행은 사라졌습니다. 그러나 일치하는 집합이 바뀌었기 때문에 유효한 인가 상태는 비어 있지 않습니다. 더 좁은 승자가 사라지고 더 넓은 후보가 승자가 되었습니다. 모든 권한을 제거하려면, RFC는 정확한 항목을 대신 수정하여 특별한 작업all:none을 갖도록 해야 한다고 말합니다. 부재가 폴백을 초대하기 때문에, 거부는 테이블에 남아 있어야 합니다.

정책은 선택의 결과였다

RFC 3341의 접근 항목은 owner, actor, 하나 이상의 작업, 그리고 서비스가 유지하는lastUpdate시각을 담았습니다. owner는 정책이 기술되는 엔드포인트 또는 하위 주소였습니다. actor는 그 owner의 맥락에서 권한을 받는 개체 또는 그룹을 지정했습니다. 작업은 서비스/연산 쌍이었습니다. 예를 들어core:data는 relay 메시를 사용해 owner에게 데이터를 보내는 행위를 통제했습니다.

actor는 로컬 부분과 도메인 부분 모두에서 제한된 와일드카드를 포함할 수 있었습니다. 따라서 여러 항목이 하나의 구체적인 actor와 일치할 수 있었습니다. 선택은 먼저 요청된 owner의 항목을 남기고, 그다음 actor 패턴이 일치하는 항목을 남겼습니다. 도메인 정확성이 1차 정렬 키였고, 로컬 부분의 정확성이 2차였습니다. 정확한 일치가 이겼으며, 그렇지 않으면 더 짧은 와일드카드 일치가 더 구체적인 것으로 간주되었습니다.

이 알고리즘은 권한을 한 행만으로 판독할 수 없다는 뜻입니다. 권한은 후보 집합, 우선순위 규칙, 요청된 작업의 결과입니다. 정확한 부여가 사라졌음을 보여주는 스크린샷은 데이터베이스 사실만 증명합니다. 다음 정책 평가가 그 actor를 거부할 것임을 증명하지는 않습니다.

기본값은 이 구분을 더 선명하게 만들었습니다. 각 owner에 대해 owner 자신과 같은 도메인의 APEX 서비스는 넓은 기본 접근을, 모든 도메인의 APEX 서비스는 핵심 데이터 권한을, 그 밖의 전역 actor는all:none을 받았습니다. 명시적 항목은 동일한 actor 값을 가진 기본값만 대체했습니다. 따라서 유효 상태는 저장된 행과 정의된 기본값을 모두 포함했습니다.

all:none이 존재해야 했던 이유

삭제는 접근 항목이actions속성을 생략한set연산을 보냄으로써 표현되었습니다. 접근 서비스는 해당 owner/actor 항목을 제거하고, 발신자에게 성공 응답을 반환했으며, 항목이 삭제되었음을 owner가 알 수 있도록 작업이 없는 별도의set알림을 owner에게 보냈습니다.

RFC 3341은 이어서 와일드카드 사용으로 인해 삭제가 권한을 제거하는 대신 변경할 수 있다고 경고합니다. 그 해결책은 마법적인 전역 철회 비트가 아니었습니다.all:none은 그 자체로 '어떤 연산도 하지 않음'을 뜻하는 작업 값입니다. 정확한 actor 항목은 남아 더 넓은 와일드카드를 계속 압도합니다. 바뀌는 것은 그 내용이 허용된 작업에서 명시적 거부로 바뀌는 것입니다.

이것은 저장되어야 하는 부정적 정책 사실의 간결한 예입니다. 부재는 같은 정보를 담지 못합니다. 묘비명 같은 거부는 그 actor가 이 구체성 수준에서 평가되었으며 더 넓은 권한을 상속해서는 안 된다는 것을 말합니다. 폴백을 고려하지 않고 그 명시적 기록이 나중에 가비지 컬렉션되면, 누구도 새 부여를 만들지 않았음에도 접근이 다시 나타날 수 있습니다.

버전 검사는 변경을 보호했을 뿐, 전체 결과를 보호하지 않았다

RFC 3341은 응용이 항목을 수정하기 전에 조회할 것을 요구했습니다. 성공한get은lastUpdate를 반환했고, 교체나 삭제는 그 현재 값을 함께 제공했습니다. 정확한 항목이 존재하지 않는데lastUpdate가 제공되었거나, 제공된 값이 선택된 항목의 값과 의미론적으로 동일하지 않으면 서비스는 코드 555를 반환했습니다. 그에 반해 생성은lastUpdate를 생략했습니다.

이것은 교체 전 비교 메커니즘이었습니다. 조회 이후 변경된 항목을 작성자가 몰래 덮어쓰는 것을 막았습니다. 서비스는 생성이나 업데이트 후 새 타임스탬프를 할당했으며, 그것은 교체된 값과 달라야 했습니다.

타임스탬프는 그 변경 검사 이상을 증명하지 못했습니다. 모든 relay가 정책을 관찰했는지, 알림이 owner에게 도달했는지, 이후의 질의가 의도된 후보 집합을 사용했는지는 증명하지 않았습니다. 정확한 접수 증거 체인은 다음과 같습니다. 항목과 버전 조회, 변경 제출, 서비스 수용 또는 충돌, 새 저장 항목, 알림 발행, 알림 전달, 결정 재계산, 강제 지점 갱신, 시도된 연산의 허용 또는 거부.

정책 조회 자체가 인가 대상이었다

접근 서비스는 응용이 잘 알려진 엔드포인트에 주소를 지정할 수 있다는 이유만으로 정책을 공개하지 않았습니다. 질의에 대해 서비스는 먼저 대상이 관리 도메인에 속하는지, 유효한 주소를 지정하는지 확인했습니다. 그다음 질의 발신자와 일치하는 대상의 접근 항목을 참조하여access:query토큰을 요구했습니다. 그 후에야 검사 중인 actor와 일치하는 항목을 선택하고 요청된 모든 작업이 존재하는지 판단했습니다.

여기서 두 가지 actor 역할이 만들어집니다. 결정을 검열하려는 발신자와, 권한이 검사되는 actor입니다. 두 증거는 혼동되어서는 안 됩니다. 물어볼 권한은 수행할 권한이 아닙니다. 마찬가지로allow응답은 그 서비스 평가 시점에 나열된 모든 작업이 선택된 항목에 포함되어 있었다는 것을 말할 뿐, 이후의 데이터 연산이 같은 정책 버전에 도달했거나 성공했다는 증명이 아닙니다.

RFC는 구현이 접근 항목을 영구 저장소에 보존할 것을 요구했으며, owner 주소가 현재 relay 메시에 연결되어 있든 아니든 항목을 유지했습니다. 엔드포인트의 연결 해제는 그 정책을 지우지 않았습니다. 영속성은 정책을 presence보다 오래 살게 했지만, 그 자체로 내구성, 복제, 신선도, 강제를 보증하지는 않았습니다.

역사적 지위와 오래 남는 교훈

RFC 3341은 2002년 7월에 APEX 코어, 옵션, presence RFC들과 함께 Standards Track으로 발표되었습니다. 2012년 7월 29일, IETF는 RFC 3340부터 3343까지가 Historic으로 재분류된 이유를 기록했습니다. 최선의 지식으로는 배포된 구현이 없었고, APEX 기능은 RFC 6120과 RFC 6121에 따라 널리 배포된 XMPP가 제공하고 있었다는 것입니다.

그 진술이 역사적 채택 경계입니다. 와일드카드 폴백이 배포되지 않은 원인이라고 말하지 않습니다. 접근 규칙 예를 배포된 취약점으로 만들지도 않습니다. 그 가치는 개념적이고 정확합니다. 정책 개체 하나를 제거하는 것, 유효한 권한을 철회하는 것, 거부를 강제하는 것은 세 개의 분리된 사건입니다.

어떤 계층화된 인가 시스템도 APEX를 구현한다고 가장하지 않고 같은 규율로 감사될 수 있습니다. 편집된 행만이 아니라 전체 후보 집합과 일치 알고리즘을 기록하십시오. 우선순위가 존재에 의존한다면 명시적 거부를 보존하십시오. 변경 후에는 유효 결정을 조회하고 강제 지점을 시험하십시오. 변경 접수 증거는 서비스가 무엇을 수용했는지 알려줍니다. 철회에는 actor가 더 이상 무엇을 할 수 없는지에 대한 증거가 필요합니다.

출처