요약

  • 키의 값을 감추는 것과 그 키의 테스트를 승인하는 것은 별개의 결정이다. 호출자는 해당 작업을 식별하는 상위 데이터 노드에 대한 읽기 권한과 유효한 실행 권한이 필요하다. NACM의 표준 실행 폴백은permit이지만, 적용 가능한 규칙과 세션 컨텍스트가 여전히 접근을 결정한다. 이는 보편적인 사용 가능성이나 배치 결함을 뜻하지 않는다.RFC 9647, §2.3,RFC 8341, §§3.1.3, 3.4.5, 5.1

  • 위임된 테스트는 운영자가 비밀을 받지 않고도 프로비저닝을 점검하게 해줄 수 있다. 그 결과는 신뢰할 수 있는 기댓값과 귀속 가능한 요청에 의존하는 로컬 비교다. 키 교체 기간에는 기존 트래픽이 여전히 이전 키에 의존할 수 있으므로, 성공한 테스트만으로는 그 의존성 제거를 정당화할 수 없다.RFC 9046, §3.8,RFC 8967, §§4–5

운영자가 비밀에 대해 묻는 질문

구성된 Babel MAC 키를 점검하려는 가상의 운영자를 생각해 보자. 관리 시스템은 키 객체를 식별할 만한 충분한 정보를 노출하지만, 운영자는 그 값을 읽을 수 없다. 객체의test작업을 실행하도록 유효하게 승인되었다면, 운영자는 테스트 문자열과 후보 MAC이라는 두 이진 입력을 제출할 수 있다. 장비는 로컬에서 계산하고 자신의 결과가 후보와 일치하는지만 반환한다.

운영자는 검사할 수 없는 비밀을 장비가 사용하도록 요청한 것이다. 이 배열에 결함이 있다고 가정할 필요는 없다. 이는 비밀 자료를 공급하는 책임자와 구성 단계를 점검하는 책임자 사이의 의도된 분담을 정확히 표현할 수 있다.

설명이 필요한 것은 요청 뒤에 있는 권한이다. 유지보수 작업을 맡았다는 사실 자체가 실행 권한을 확립하지는 않는다. 마찬가지로 성공한 응답을 받았다는 사실이 조직이 그 호출자에게 그 권한을 주려 의도했다는 증거도 아니다.

이것은 서로 다른 두 가지 판단이다. 관리 서비스가 요청을 받아들이는지, 그리고 받아들여진 요청이 운영자의 책임 범위에 부합하는지. 누군가 그 응답을 변경 승인에 사용할 때 세 번째 판단이 뒤따른다.

거버넌스 질문은 세 가지 모두를 관통한다. 누가 이 계산을 수행하게 할 수 있고, 그 위임에 누가 책임지며, 좁은 결과가 어떤 결정을 합리적으로 지지할 수 있는가?

출력이 의도적으로 제한된 계산

RFC 9647은 이 테스트를mac-key-set/keys의 개별 항목 안에 둔다. 그 항목은 키의name,use-send,use-verify,algorithm,value를 모델링한다.value리프는nacm:default-deny-all을 갖는다. 이 작업은 호출자가 제공하는test-string과mac입력(둘 다 이진)을 받아, 구성된 키와 알고리즘으로 제공된 문자열 위의 MAC을 계산한다. 그 불리언indication은 일치 또는 불일치를 보고한다. 키 바이트도, 로컬 계산된 MAC도 반환되지 않는다.RFC 9647, §2.3

이 출력 제한은 중요하다. 호출자는 비교에 후보를 직접 가져와야 한다. 이 인터페이스는 호출자가 가져갈 수 있도록 새로 계산된 인증 코드를 제공하지 않는다. 이를 무제한 MAC 생성이라고 부르는 것은 명세된 능력을 과장한 것이다.

그러나 응답은 여전히 제출된 데이터와 설치된 비밀 사이의 관계에 관한 무언가를 전달한다. 따라서 그 응답을 얻을 권한은 출력이 작아도 의미가 있다.

RFC 9046이 정보 모델의 기반을 제공한다. 그 §3.8은 키 값을 읽을 수 없도록 요구하고, 이름의 식별 역할을 설명하며, 선택적 기댓값 테스트를 기술한다. RFC 9647은 그 관리 개념을 YANG 표현으로 옮긴다. 정보 모델의 비밀성 요구, YANG 리프 보호, 작업에 적용되는 접근 정책은 서로 관련된 주장이지만 서로 바꿔 쓸 수 있는 것은 아니다.RFC 9046, §3.8

일치 결과만으로는 호출자가 그 후보를 어떻게 얻었는지 아무것도 말해주지 않는다. 운영자는 키를 소유하지 않고도 승인된 테스트 쌍을 받을 수 있다. 따라서 이 인터페이스를 성공적으로 사용했다는 것이 호출자가 비밀을 안다는 증거는 아니다. 이 구분이 인터페이스의 정당한 운영 가치의 핵심이다.

승인은 비밀 리프 밖에서 결정된다

보호되는value리프는 이 작업의 형제(sibling)이다. 그 접근 제한이 자동으로 옆으로 확장되어test의 실행을 결정하지는 않는다.

RFC 8341 §3.1.3에 따르면, 작업 호출에는 해당 작업을 식별하는 모든 상위 데이터 노드 인스턴스에 대한 읽기 권한과 작업 자체에 대한exec권한이 필요하다. 비밀 값 형제는 그 상위 체인 밖에 있다. 식별 계층을 읽는다고 해서 그 안의 모든 하위 노드를 읽는 것은 아니다.RFC 8341, §3.1.3,RFC 9647, §2.3

NACM이 활성화된 일반 세션에서는 적용 가능한 규칙이 순서대로 평가된다. 일치하는 규칙은 요청을 허용하거나 거부할 수 있다. 적용 가능한 실행 규칙이 일치하지 않을 때만exec-default가 결정한다. 그 표준 기본값은permit이다. 명시적 허용은 폴백에 도달하지 않고 실행을 확정하며, 유효한 거부도 마찬가지다.RFC 8341, §§3.4.5, 5.1

실용적 결론은 조건적이다. 필요한 상위 접근 권한을 가진 호출자는, 다른 규칙이 먼저 결정하지 않으면 실행 폴백을 통해 받아들여질 수 있다. 다른 구성 기본값이나 유효한 제한 규칙은 다른 결과를 만들 수 있다. 실행 권한은 상위 접근의 결여를 보완할 수 없다.

평가는 세션 신원과 관련 그룹 소속도 따라야 한다. NACM은 로컬 그룹과 활성화된 전송 계층 제공 그룹을 반영할 수 있다. 중첩된 작업은 데이터 노드 경로로 매칭되며, 더 넓은 규칙이 그 하위를 포괄할 수 있다.RFC 8341, §§3.4.5–3.5.2

이 때문에 역할 라벨은 접근 평가의 대체물이 될 수 없다. "관찰자"라 불리는 역할은 구성 변경은 금지하면서 일부 작업은 허용할 수 있다. "관리자"라 불리는 역할도 특정 대상에 대해서는 제한될 수 있다. 관련 증거는 그 세션, 해당 작업, 그 키 인스턴스에 대한 결정이다.

구성 어딘가에 제한 규칙이 있다는 발견이 그 규칙이 요청을 통제한다는 뜻도 아니다. 적용 범위와 위치가 중요하다. 검토는 실제로 결정하는 규칙, 또는 평가 후 도달한 폴백을 설명해야 한다.

표준은 그 결정 절차를 확립한다. 그러나 특정 배치가 어떤 계정을 받아들이는지, 또는 받아들여진 계정이 의도된 책임을 넘어서는지는 확립하지 않는다.

키의 이름이 관리자를 임명하지는 않는다

관리 식별자는 사람과 소프트웨어가 비밀 값을 접근할 수 없는 객체를 참조하는 방법을 준다. 조직적 소유권을 할당하지는 않는다.

따라서 의미 있는 참조는 주변 컨텍스트가 필요하다. 장비, Babel 인스턴스, 키 세트, 개별 키 항목. 로컬 운영자에게 편리한 이름은 여러 장비의 결과가 담긴 중앙 변경 기록에서는 불충분할 수 있다.

이 구분은 또한 인벤토리 책임과 비밀 사용 권한을 분리한다. 누군가 비교를 제출할 필요 없이 이름과 수명 주기 기록을 관리할 수 있다. 또 다른 사람은 프로비저닝을 통제하지 않고 특정 진단을 실행하도록 승인받을 수 있다. 조직이 그 관계를 명시해야 하며, 모델의 라벨이 조직을 대신해 결정할 수는 없다.

패킷 사용 플래그에는 각자 정의된 목적이 있다.use-send는 발신 Babel 패킷에 포함되는 MAC의 계산을 다루고,use-verify는 수신 MAC 비교에 이 키를 사용하는 것을 다룬다. 어느 쪽도 관리 작업의 승인 스위치로 명세되지 않는다. 테스트가 어느 플래그의 참을 요구한다는 명시도 없다.RFC 9647, §2.3

이로 인해 패킷 사용이 시작되기 전에 구성 점검이 유용할 수 있는 자리를 갖는다. 또한 패킷 사용을 끝내는 것이 그 플래그만으로는 테스트 접근을 철회하지 않는다는 뜻이기도 하다.

조직은 패킷 역할을 변경한 뒤에도 진단을 위해 객체를 잠시 유지하는 것이 합리적일 수 있다. 중요한 점은 그 결정을 객체에 대한 모든 권한의 은퇴와 구별하는 것이다. "발신에 더 이상 사용하지 않음"은 "어떤 운영자도 장비에 테스트를 요청할 수 없음"보다 좁은 진술이다.

위임은 키를 다루는 사람 수를 줄일 수 있다

가능한 프로비저닝 절차 하나는, 승인된 메커니즘으로 비밀을 설치하고 유지보수 운영자에게 테스트 문자열, 기대 MAC, 모호하지 않은 대상 참조를 제공하는 것이다. 운영자는 기저 키를 받지 않고 설치된 객체를 점검할 수 있다.

그 테스트는 정의된 수용 질문을 지지한다. 이 객체가 구성된 알고리즘으로 이 바이트에 대해 기대되는 응답을 산출하는가? 이는 Babel 모델이 기술하는 기댓값 작업의 실용적 적용이며, 그 모델이 명령하는 워크플로우는 아니다.RFC 9046, §3.8

점검이 더해주는 신뢰의 크기는 기댓값의 독립성에 달려 있다. 절차가 의도치 않은 자료를 설치하고 같은 의도치 않은 자료에서 기대 결과를 계산했다면 비교는 성공할 수 있다. 그것은 그 절차의 두 출력 사이의 일관성을 보여줄 뿐, 최초의 선택 오류는 해결하지 않는다.

그렇다고 테스트가 무가치해지는 것은 아니다. 테스트가 답한 질문이 정의된다. 별도의 승인이 그 값이 의도된 값인지 확립하는 경우에도, 프로비저닝이 선택된 값을 올바르게 전송했다는 증거는 유용할 수 있다.

운영자는 입력의 의미를 통제할 필요도 있다. 잘못된 객체 선택, 다른 이진 데이터 사용, 기대값을 다른 알고리즘에 연결, 잘못된 후보 제공으로 불일치가 생길 수 있다. 이 가능성들을 해결하기 전에 비밀 자료를 교체하면 최초의 불일치를 진단하지 않은 채 새 변경을 유입할 수 있다.

권한 실패와 비교 실패는 서로 분리되어야 한다. 서비스가 거부한 요청은 작업의 불리언false를 산출하지 않았다. 관리 오류 역시 후보가 일치하지 않았다는 증거로 조용히 해석될 수 없다.

이 구분에는 즉각적인 운영 결과가 있다. 자동화 래퍼가 모든 실패한 요청을 "키 무효" 상태로 변환한다면, 접근 권한의 변화가 프로비저닝 조사를 촉발할 수 있다. 엔지니어들은 보고 시스템이 권한과 계산 사이의 구분을 잃었기 때문에 올바른 구성을 바꾸라는 압박을 받을 수 있다.

잘 정의된 위임은 운영자에게 보이는 인터페이스와 다음 의사결정자에게 전달되는 기록 양쪽에서 그 구분을 유지해야 한다.

넓은 접근과 좁은 접근의 비용은 다른 팀이 부담한다

넓은 테스트 접근은 구성 질문을 조사하는 데 필요한 조정을 줄인다. 엔지니어는 전문가를 찾거나 다른 계정을 마련하지 않고도 응답을 얻을 수 있다. 이 편의는 촉박한 키 교체 일정 동안 가치 있을 수 있다.

그 비용은 설치된 비밀을 비교 대상으로 선택할 수 있는 사람이나 프로세스의 집합이 커진다는 것이다. 관련 범위는 어떤 키 객체에 도달할 수 있는지, 그리고 제출하는 입력에 대해 얼마나 통제할 수 있는지를 포함한다. 값을 읽을 수 없다는 사실이 그 선택을 무관하게 만들지는 않는다.

더 좁은 접근은 그 재량을 줄이지만 작업을 더 작은 집단으로 옮길 수 있다. 승인된 집단이 부재하면 단순한 진단이 일정 조정 의존성이 된다. 지연은 그때 더 넓은 자격 증명 요청을 부추기거나 계획된 변경이 준비되었는지에 대한 불확실성을 늘릴 수 있다.

이들은 가능한 유인이지, 보고된 행동이 아니다. 출처들은 어떤 운영자도 이 작업의 정책 때문에 자격 증명을 공유하거나, 키를 내보내거나, 교체를 미뤘다고 확립하지 않는다.

그럼에도 그 결정은 이런 압박을 고려해야 한다. 직접 테스트 접근을 강력히 제한하면서 승인된 유지보수에는 신뢰할 수 있는 경로를 제공하는 설계는, 무분별한 접근이나 비현실적 제한 어느 쪽보다도 책임 분리를 더 잘 달성할 수 있다.

유용한 비교는 완전한 운영 배열 사이의 비교다. 얼마나 많은 계정에 실행 권한이 있는지 세는 것은, 그 중 하나가 중개자를 통해 큰 인구집단을 대상으로 서비스한다면 이야기의 일부만 보여준다.

상수 시간 비교와 접근 통제는 서로 다른 책임을 다룬다

RFC 9647의 보안 장은 민감한 작업에 대한 접근 통제를 요구하고, 응답 시간이 정보를 간접적으로 드러낼 수 있음을 경고한다. 그리고 구현은 제공된 MAC과 로컬 생성된 MAC을 상수 시간에 비교해야 한다(SHOULD)고 명시한다. 이는 비교에 관한 권고이지, 모든 완전한 관리 요청이 동일한 소요 시간을 갖는다는 약속이 아니다.RFC 9647, §4

구현 질문은 비교가 적절히 동작하는가이다. 거버넌스 질문은 호출자가 그것을 요청할 수 있어야 하는가이다. 하나를 지지하는 증거가 다른 하나를 해결하지 않는다.

견고한 비교 루틴은 진단 계정이 유지된 모든 키에 대한 권한이 왜 필요했는지 설명해주지 않는다. 좁게 한정된 역할은 적절한 비교 동작의 필요를 없애지 않는다.

이 경고에는 증거적 경계도 있다. 그것은 어떤 구현에서 누출이 있었음을 보여주지 않고, 누구든 이 인터페이스를 통해 MAC을 복구할 수 있음을 확립하지 않으며, 측정된 공격을 기술하지도 않는다. 그런 결론은 네 개의 표준 너머의 증거를 필요로 한다.

조직은 호출량 제한이나 자동화된 사용에 대한 추가 통제를 고려할 수 있다. 이들은 의도된 작업 부하에 맞춰야 하는 배치 선택이다. 조정된 변경 중 정당한 점검을 가로막는 제한은 또 다른 운영 문제를 만들 수 있다.

키 교체는 성공한 응답의 의미를 시험한다

키 교체는 권한 질문을 중대한 결정과 접촉시킨다. 언제 이전 키를 제거할 수 있는가?

RFC 8967은 이전 키와 새 키가 공존하는 중첩 기간을 기술한다. 패킷은 적용 가능한 키로 계산된 MAC을 실으며, 수용된 키 아래의 일치하는 MAC은 MAC 검사를 통과할 수 있다. 전송되는 값은 MAC이지 비밀 키 바이트가 아니다.RFC 8967, §§4–5

따라서 새 객체의 로컬 테스트가 성공하는 동안에도 패킷 수용은 여전히 이전 자료에 의존할 수 있다. 이 두 관찰은 변경의 서로 다른 부분을 다룬다. 두 가지의 공존이 이전 키 제거가 운영을 유지할 것임을 확립하지 않는다.

기술적 구분은 구체적이다. RFC 8967은 패킷 MAC을 주소·포트 의사 헤더에 Babel 헤더와 본문을 더하고 트레일러를 제외한 대상 위에 계산한다. 수신에는 패킷 카운터, 인덱스, 챌린지 관련 검사도 관여한다. 관리 테스트는 호출자가 제공한 이진 문자열 위에서 비교를 수행한다.RFC 8967, §§4.1–4.3

실제 패킷 계산에 해당하는 바이트를 사용한 테스트조차 피어가 그 패킷을 수신했거나 수용했다는 것을 확립하지 않는다. 이후의 경로 상태나 네트워크 건전성을 확립하지도 않는다.

관리 키 이름이 이 간극을 메우지 않는다. MAC TLV에는 대응하는 키 이름 필드가 없으므로, 관찰자는 패킷을 읽고 어느 관리 객체가 책임있는지를 명명하는 영수증으로 삼을 수 없다.RFC 8967, §6.1

전환을 승인하는 사람은 따라서 남은 의존성을 겨냥한 증거가 필요하다. 이용 가능한 계측과 유지보수 설계에 따라, 교체 구성에 연관된 수신 측 관찰이나 이전 자료가 여전히 필요한지 검사하는 통제된 전환 등이 그에 해당할 수 있다. 표준은 하나의 보편적 증거 패키지를 정하지 않는다.

바로 여기서 테스트 권한은 제거 승인 권한과 구별되어야 한다. 운영자는 로컬 점검을 실행할 완전한 자격과 정확한 일치 보고를 갖고 있으면서, 더 넓은 결정에 필요한 증거를 갖고 있지 않을 수 있다.

그 구분을 보존하는 변경 기록은 네트워크 결정과 운영자의 책임성을 모두 보호한다. 좁고 정확히 보고된 관찰이 승인 체계를 통과하면서 더 강한 의미를 획득하는 것을 막는다.

요청에는 귀속 가능한 이력이 필요하다

유효 권한을 평가하려면 조직은 구성된 권한 목록만으로는 부족하다. 관련 신원과 세션 컨텍스트를 대상과 적용되는 결정에 연결해야 한다. 결과가 계속 유용하려면 그 연결이 운영 기록 속에서도 살아남아야 한다.

적절한 기록은 착수 주체, 장비, 키 객체 컨텍스트, 승인된 테스트 참조, 정책 컨텍스트, 시각, 결과를 식별할 수 있다. 거부된 요청과 완료된 불일치 또는 일치를 구별할 수 있다. 이들은 제안된 감사 속성이지, 테스트 작업이 강제하는 기록 형식이 아니다.

서비스 계정은 이 구분을 특히 중요하게 만든다. 장비 입장에서 겉보기 호출자는 자동화 신원일 수 있다. 그 뒤의 인간 능력은 그 자동화 서비스가 허용하는 범위에 달려 있다.

어떤 서비스 설계는 유지보수 작업에 할당된 객체에 대해 승인된 테스트 쌍만 실행할 수 있다. 또 다른 설계는 임의의 객체 선택, 테스트 문자열, 후보 MAC을 전달할 수 있다. 양쪽 모두 같은 장비 자격 증명을 쓰면서도 사용자에게 실질적으로 다른 재량을 배분할 수 있다.

서비스 계정 이름을 적은 장비 로그는 그 차이를 설명하지 않는다. 위임을 평가하려면 중개자의 통제를 검사하고, 장비 대면 호출과 그를 착수한 사람 또는 승인된 작업 사이의 연관을 보존해야 한다.

기댓값 참조에도 이해 가능성을 유지하기에 충분한 수명 주기 컨텍스트가 필요하다. 객체가 제거되고 이후 객체가 같은 이름을 받으면, 그 이름만으로 기록된 과거의 일치는 모호해질 수 있다. 관련 구성이나 객체 세대 관계를 보존하면, 익숙한 라벨을 동일한 자료의 영구적 증거로 취급하는 일을 피할 수 있다.

모든 원시 입력을 보존하는 것이 자동으로 필요한 것은 아니다. 통제된 참조는 승인된 테스트의 의미를, 그 내용을 모든 운영 로그에 배포하지 않고도 보존할 수 있다. 선택은 검토자가 무엇을 재구성해야 하는지를 따라야 하며, 그 결과 기록에 대한 적절한 보호를 함께 해야 한다.

감사 궤적은 성공한 계산을 축하하기만 하는 것이 아니라 최초의 결정을 설명해야 한다. 왜 이 호출자가 이 객체를 사용할 수 있었고, 왜 그 관찰이 다음 승인 단계에 충분했는지를 알아낼 수 있어야 한다.

표준은 시스템 운영자에게 결정을 남긴다

네 개의 RFC는 유용한 분리를 확립한다. 키는 읽을 수 없는 채 유지되면서, 승인된 관리 작업이 그 키를 사용해 제공된 기댓값을 점검할 수 있다. 이 분리는 절차적 유지보수를 지지하고 비밀 자료의 배포 필요를 줄일 수 있다.

또한 관리 환경을 운영하는 자에게 특정 책임을 남긴다. 테스트를 호출할 권한은 그 자체의 조건으로 평가되어야 하며, 서비스 계정 뒤의 사람들과 그들이 선택할 수 있는 객체 및 입력의 범위가 포함된다.

여기서 어떤 증거도 취약한 배치나 보편적 권한을 식별하지 않는다. 방어 가능한 공개 결론은 더 좁다. 값의 보호는 실행을 확정하지 않고, 성공한 실행은 그 뒤의 운영 변경을 확정하지 않는다.

성숙한 결정 절차는 두 권한 모두를 설명할 수 있다. 누가 비교를 요청할 수 있고, 누가 그 결과를 명시된 목적에 따라 신뢰할 수 있는지를 식별할 수 있다. 키의 비밀성이 그 설명을 더욱 필요하게 만든다. 값을 검사하는 것이 대체 수단으로 의도적으로 사용 불가능하기 때문이다.

출처