Cedar를 사용한 정책 평가

이 페이지에서는 다자간 계산 (MPC) 정책 엔진이 Cedar 정책 언어로 작성된 트랜잭션 정책을 평가하고, 크로스체인 시나리오를 처리하고, 선택적 또는 생략된 메타데이터 필드를 해결하는 방법을 설명합니다.

핵심 평가 원칙

정책 엔진은 Cedar 정책 언어를 사용하여 암호화 서명 작업을 승인합니다. 엔진은 세 가지 기본 공리를 사용하여 정책을 결정론적으로 평가합니다.

  1. 기본 거부: 모든 작업이 암시적으로 거부됩니다. 작업이 허용되려면 활성 permit 정책이 하나 이상 일치해야 합니다. 일치하는 permit 정책이 없으면 최종 결정은 DENY입니다.
  2. 명시적 금지: forbid 정책은 절대적인 재정의 역할을 합니다. 작업이 활성 forbid 정책과 일치하면 작업을 허용하는 일치하는 permit 정책과 관계없이 결정이 즉시 DENY로 확인됩니다.
  3. 누락된 필드는 '일치하지 않음'을 의미함(건너뛰기): 규칙이 트랜잭션 페이로드에 없는 필드 (예: 누락된 선택적 필드)를 찾는 경우 Cedar는 비정상 종료되지 않습니다. 해당 규칙을 '일치하지 않음' (false로 평가)으로 처리하고 다음 규칙으로 이동합니다.

논리적 평가 매트릭스

다음 표는 정책 엔진이 규칙 조합을 평가하는 방법을 보여줍니다.

모든 시나리오에서 다음을 가정합니다.

  • 트랜잭션 호출자 (Cedar 정책에서 주 구성원으로 표시됨)는 Alice (User::"alice")입니다. 다자간 계산에서 주 구성원은 암호화 서명 작업에 대한 승인을 요청하는 페르소나 또는 ID를 나타냅니다 (예: 서명자, 자동화된 서비스 클라이언트, 백엔드 시스템 계정).
  • 트랜잭션은 정확히 1 ETH (context.transaction.spend_amount_scaled에서 1,000,000,000 확장 나노코인 단위로 표시됨)를 전송합니다.
시나리오 활성 정책 결과 이유
시나리오 1: 빈 상태 활성 정책이 없습니다. DENY 기본적으로 일치하는 permit 정책에 의해 명시적으로 허용되지 않는 한 모든 작업이 차단됩니다.
시나리오 2: 단일 허가 일치 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 10000000000
};

최대 10 ETH 허용

 PERMIT 트랜잭션 매개변수가 정책 조건을 충족합니다. 충돌하는 forbid 정책이 없으므로 요청이 허용됩니다.
시나리오 3: 단일 허가 불일치 
permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

최대 0.5ETH 허용

 DENY 이체 금액 (1 ETH)이 정책 한도를 초과합니다. 일치하는 permit 규칙이 없으므로 기본 거부 규칙이 트랜잭션을 차단합니다.
시나리오 4: 여러 허용 정책

정책 A:

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 500000000
};

최대 0.5ETH 허용

정책 B:

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

최대 5 ETH 허용

 PERMIT 정책 A는 일치하지 않지만 정책 B는 일치합니다. 트랜잭션을 허용하려면 일치하는 permit 정책이 하나만 있으면 됩니다.
시나리오 5: 허용 및 금지 충돌

정책 A (허용):

permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled < 5000000000
};

최대 5 ETH 허용

정책 B (금지):

forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.recipient == "0xBlockedAddress"
};

도착 페이지가 0xBlockedAddress라고 가정

 DENY 이전이 0xBlockedAddress로 전송됩니다. 정책 A에서 거래 금액을 허용하더라도 대상이 정책 B의 기준과 일치합니다. 명시적 forbid 규칙이 정책 A보다 우선 적용되어 트랜잭션을 차단합니다.
시나리오 6: 일치하지 않는 금지 정책

이전 시나리오와 동일한 정책

 PERMIT 전송이 안전한 주소 (예: 0xSafeAddress)로 전송됩니다. 정책 A는 일치하지만 정책 B는 대상이 0xBlockedAddress가 아니므로 일치하지 않습니다. 일치하는 금지 규칙이 없으면 허용 규칙이 적용됩니다.

다중 체인 및 선택적 필드 시나리오

위의 매트릭스는 허용된 규칙과 금지된 규칙의 핵심 논리적 우선순위를 보여주지만, 다음 시나리오는 정책 엔진이 멀티체인 환경에서 규칙을 평가하는 방법을 보여줍니다. 특히 옵션 필드 또는 다른 블록체인 네트워크 스키마에 대해 실행할 때 그렇습니다.

참고: 0 값 데이터 정규화 예기치 않은 평가 오류를 방지하고 정책 예측 가능성을 보장하기 위해 정책 엔진의 파싱 레이어는 평가 컨텍스트에서 채워지지 않은 문자열 및 바이트 필드를 생략하는 대신 유형별 0 값 (예: 빈 문자열 "" 또는 빈 바이트 배열)으로 정규화합니다.

이 동작을 사용하면 Cedar 평가 오류의 위험 없이 채워지지 않은 필드를 타겟팅하는 명시적 정책의 초안을 작성할 수 있습니다. 하지만 블록체인 스키마에서 완전히 정의되지 않은 필드 (예: 비트코인 트랜잭션의 EVM 전용 gas_limit 또는 EVM 트랜잭션의 비트코인 전용 outputs)에 액세스하면 해당 정책에 대한 Cedar 평가 오류가 발생하여 false (일치하지 않음)로 평가되고 안전하게 실패합니다.

시나리오 7: 교차 체인 정책 평가 및 매핑되지 않은 스키마 속성

  • 컨텍스트: 발신자가 비트코인 거래를 제출합니다. 하지만 활성 정책 세트에는 이더리움 관련 정책이 포함되어 있습니다.

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.schema == "ethereum.transaction.v2" &&
  context.transaction.gas_limit < 100000
};

  • 결과: DENY

  • 이유: 범용 의도 속성 (예: spend_amount_scaled, recipient, max_fee_atomic)은 이더리움 및 비트코인 거래 모두에서 일관되게 평가됩니다. 정책이 제출된 트랜잭션의 스키마에 존재하지 않는 체인별 속성 (예: 비트코인 트랜잭션의 gas_limit)을 참조하는 경우 Cedar는 일치하지 않는 속성을 평가 실패로 처리하여 엔진을 중지하지 않고 해당 특정 정책을 false (일치하지 않음)로 해결합니다. 비트코인 트랜잭션과 일치하는 다른 활성 permit 정책이 없으므로 작업은 기본적으로 거부됩니다.

시나리오 8: permit 정책에 선택적 필드가 누락됨

  • 컨텍스트: 발신자가 스마트 계약을 사용하지 않는 표준 ETH 전송을 제출합니다. 활성 정책 세트에는 계약 상호작용을 확인하는 규칙이 포함되어 있습니다.

    permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0x1111111111111111111111111111111111111111"
};

  • 결과: DENY

  • 이유: 표준 ETH 전송의 경우 선택사항인 asset_contract_address가 채워지지 않습니다. 파서는 이를 평가 컨텍스트에서 값이 0인 빈 문자열 ""로 정규화합니다. 비교 "" == "0x1111..."를 평가하면 오류가 발생하지 않고 false (일치하지 않음)가 반환됩니다. 전송을 허용하는 다른 정책이 없으므로 기본적으로 작업이 거부됩니다.

시나리오 9: forbid 정책에 선택사항 필드가 누락됨

  • 컨텍스트: 발신자가 10ETH의 표준 ETH 전송을 제출합니다. 정책 세트는 다음으로 구성됩니다.

    • 정책 A (허용):

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 100000000000
};

    • 정책 B (금지):

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == "0xBannedContract"
};

  • 결과: PERMIT

  • 이유: 10 ETH는 한도 미만이므로 정책 A가 일치합니다. 정책 B는 계약 주소가 금지된 주소와 일치하는지 확인합니다. 0 값 정규화로 인해 채워지지 않은 계약 주소가 ""로 확인됩니다. "" == "0xBannedContract" 비교를 평가하면 false가 반환됩니다. 금지 정책은 일치하지 않고 허용 정책은 일치하므로 트랜잭션이 허용됩니다.

시나리오 10: 비어 있거나 누락된 필드 명시적 확인

  • 컨텍스트: 호출자가 표준 ETH 전송을 제출합니다 (스마트 계약으로 전송되지 않음). 정책 세트는 다음으로 구성됩니다.

    • 정책 A (허용):

      permit(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.spend_amount_scaled <= 1000000000000
};

    • 정책 B (금지):

      forbid(
  principal == User::"alice",
  action,
  resource
)
when {
  context.transaction.asset_contract_address == ""
};

  • 결과: DENY

  • 이유: 파서 정규화로 인해 누락된 asset_contract_address가 평가 컨텍스트에 빈 문자열 ""로 표시됩니다. 정책 B를 평가하면 조건이 true ("" == "")로 확인됩니다. forbid 정책이 일치하고 트랜잭션이 거부됩니다.

평가 전 검증 (빠른 실패 게이트)

정책 엔진은 엄격한 데이터 검증을 시행합니다. 정책 평가를 위해 페이로드가 Cedar로 전달되기 전에 기본 파서가 트랜잭션 구조, RLP 인코딩, 암호화 무결성을 검증합니다.

시나리오 11: 잘못된 형식의 유효하지 않은 거래 페이로드

  • 상황: 클라이언트가 잘못된 형식의 바이트 시퀀스, 잘못된 구조의 페이로드 또는 필수 암호화 필드가 누락된 트랜잭션 (예: 잘못된 RLP 구조 또는 누락된 가스 매개변수가 있는 EVM 트랜잭션)을 제출합니다.
  • 결과: gRPC InvalidArgument
  • 이유: 내부 트랜잭션 파서가 API Gateway 레이어에서 잘못된 입력을 감지합니다. 작업이 즉시 실패하고 클라이언트에 gRPC InvalidArgument 오류를 반환하며 Cedar 정책 엔진의 평가는 완전히 우회됩니다.