엔터프라이즈 IAM (Nevis)

Revka는 인증 및 권한 부여를 Nevis Security Suite 인스턴스에 위임할 수 있습니다. 이를 통해 에이전트 접근은 로컬 페어링 토큰만이 아닌 기존 엔터프라이즈 ID 공급자에 의해 제어됩니다. Nevis IAM이 활성화되면 Revka는 수신된 OAuth2/OIDC 토큰을 검증하고, 호출자의 신원과 역할을 확인하며, MFA를 적용하고, 각 Nevis 역할을 Revka 도구 권한 및 워크스페이스 접근 권한 집합에 정확하게 매핑합니다. 이 모든 과정은 기본 거부(deny-by-default) 방식으로 동작합니다.

SSO 기반 접근 제어, FIDO2/패스키 MFA, 다중 팀 또는 다중 테넌트 Revka 배포에서의 역할 기반 도구 게이팅이 필요한 경우 이 페이지를 참조하십시오. 로컬 전용 인증 모델은 시크릿, 페어링 & 디바이스 인증을 참조하고, 이러한 검사가 전반적인 보안 스택에서 어떻게 적용되는지는 보안 모델을 참조하십시오.

엔터프라이즈 기능

Nevis IAM은 이미 Nevis Security Suite 인스턴스를 운영 중인 배포 환경을 위한 엔터프라이즈 통합 기능입니다. 기본적으로 비활성화(enabled = false)되어 있으며, Revka의 정책 엔진 및 디바이스 페어링 위에 추가 계층으로 동작합니다. 이를 대체하지는 않습니다.

동작 방식

Nevis IAM은 두 가지 협력 구성 요소로 이루어져 있습니다.

• NevisAuthProvider — 베어러 토큰(또는 세션 토큰)을 Nevis 인스턴스에서 검증하고, NevisIdentity(사용자 ID, 역할, OAuth2 스코프, MFA 상태, 세션 만료)를 확인합니다. MFA가 필요하지만 충족되지 않은 경우, 또는 세션이 만료된 경우 요청을 거부합니다.
• IamPolicy — 확인된 신원을 받아, 요청별로 호출자의 Nevis 역할 중 하나라도 요청한 도구와 워크스페이스에 대한 접근 권한을 부여하는지 평가합니다. 일치하는 역할 매핑이 없으면 접근이 거부됩니다.

두 구성 요소 모두 모든 결정(ALLOW/DENY)을 추적 로그에 기록하며, 사용자 ID는 로그에서 익명 처리됩니다.

설정

모든 설정은 [security.nevis] 섹션에 위치합니다. enabled = true로 설정해야 통합이 활성화됩니다.

[security.nevis]
enabled = true
instance_url = "https://nevis.corp.example.com"
realm = "production"
client_id = "revka-agent"
client_secret = "enc2:<hex>"        # encrypted at rest (see note below)
token_validation = "remote"          # local | remote
jwks_url = "https://nevis.corp.example.com/.well-known/jwks.json"
require_mfa = true
session_timeout_secs = 3600

[[security.nevis.role_mapping]]
nevis_role = "agent-operator"
revka_permissions = ["file_read", "file_write", "shell"]
workspace_access = ["production"]

[[security.nevis.role_mapping]]
nevis_role = "agent-admin"
revka_permissions = ["all"]
workspace_access = ["all"]

설정 참조

키	타입	기본값	설명
enabled	bool	false	Nevis IAM을 활성화합니다. false이면 다른 모든 키는 무시됩니다.
instance_url	string	""	Nevis 인스턴스의 기본 URL. 활성화 시 필수.
realm	string	"master"	인증할 Nevis 렐름. 활성화 시 필수.
client_id	string	""	Nevis에 등록된 OAuth2 클라이언트 ID. 활성화 시 필수.
client_secret	string	(없음)	OAuth2 클라이언트 시크릿. enc2:<hex>로 암호화되어 저장됩니다. 퍼블릭 클라이언트의 경우 선택 사항.
token_validation	string	"local"	"local" (JWKS) 또는 "remote" (인트로스펙션). 토큰 검증 모드 참조.
jwks_url	string	(없음)	로컬 검증을 위한 JWKS 엔드포인트. token_validation = "local" 시 필수.
require_mfa	bool	false	MFA가 완료되지 않은 세션을 거부합니다. MFA 적용 참조.
session_timeout_secs	u64	3600	세션 유효 시간(초). 0보다 커야 합니다.
role_mapping	array	[]	Nevis 역할당 하나의 [[security.nevis.role_mapping]] 블록. 역할 매핑 참조.

참고

client_secret은 저장 시 ChaCha20-Poly1305로 암호화되며, 설정 파일에는 enc2:<hex> 형태로 표시됩니다. 일반 텍스트 시크릿을 파일에 직접 붙여넣어도 그대로 유지되지 않습니다. 시크릿 저장소의 동작 방식과 ~/.revka/.secret_key 백업의 필요성에 대해서는 암호화된 시크릿을 참조하십시오.

시작 시 검증

enabled = true일 때 Revka는 로드 시점에 설정을 검증하며, 오류를 첫 번째 요청까지 미루지 않고 즉시 실패합니다. 다음 경우 시작이 거부됩니다.

• instance_url, client_id, 또는 realm이 비어 있는 경우.
• token_validation이 "local" 또는 "remote" 이외의 값인 경우.
• token_validation = "local"이지만 jwks_url이 설정되지 않은 경우.
• session_timeout_secs가 0인 경우.

토큰 검증 모드

token_validation은 NevisAuthProvider가 수신 토큰을 검사하는 방식을 선택합니다.

remote (introspection)

Revka는 모든 토큰에 대해 Nevis OAuth2 인트로스펙션 엔드포인트를 호출합니다. Nevis에서 토큰이 해지되면 다음 요청이 즉시 거부되므로 항상 최신 상태를 유지할 수 있습니다. 단, 검증마다 네트워크 왕복 비용이 발생합니다.

POST {instance_url}/auth/realms/{realm}/protocol/openid-connect/token/introspect
Content-Type: application/x-www-form-urlencoded

token=<bearer-token>&client_id=<client_id>&client_secret=<client_secret>

응답은 active: true를 반환해야 하며, Revka는 sub(사용자 ID), realm_access.roles(정렬 및 중복 제거된 역할), scope, exp(세션 만료), MFA 신호인 acr / amr을 읽습니다. sub 클레임이 없거나 비어 있는 경우, 또는 active: false인 경우 거부됩니다.

[security.nevis]
token_validation = "remote"
# jwks_url not required

local (JWKS)

로컬 모드는 캐시된 JWKS 키를 사용해 오프라인으로 JWT 서명을 검증하여 요청당 네트워크 호출을 피하기 위한 것입니다. jwks_url이 설정되어 있어야 합니다(그렇지 않으면 시작이 실패합니다).

[security.nevis]
token_validation = "local"
jwks_url = "https://nevis.corp.example.com/.well-known/jwks.json"

로컬 JWKS 검증은 아직 구현되지 않았습니다

현재 빌드에서 token_validation = "local"은 JWT 구조 검사 후 검증 대신 명시적인 오류를 반환합니다. 이는 의도적인 동작입니다. 설정 오류를 숨기기 위해 원격 인트로스펙션으로 자동 폴백하는 것을 방지합니다. 현재는 token_validation = "remote"를 사용하십시오. 오류 메시지에도 동일한 안내가 포함되어 있습니다.

세션(쿠키 기반) 토큰은 token_validation 설정과 무관하게 Nevis userinfo 엔드포인트에서 별도로 검증되며, 결과 세션은 session_timeout_secs 이후 만료됩니다.

MFA 적용

require_mfa = true로 설정하면 다단계 인증을 완료하지 않은 신원의 요청을 거부합니다. Revka는 다음 중 하나가 충족될 때 세션을 MFA 인증됨으로 처리합니다.

• 토큰의 acr(Authentication Context Class Reference) 클레임이 "mfa"와 일치하거나, 또는
• 토큰의 amr(Authentication Methods References) 클레임에 fido2, passkey, otp, webauthn 중 하나가 포함된 경우.

require_mfa = true이고 두 신호 모두 없으면 MFA 필요 오류로 검증이 실패합니다(사용자 ID는 메시지에서 익명 처리됩니다). Nevis에서 수행된 FIDO2 및 패스키 인증은 Revka의 MFA 게이트를 자동으로 통과합니다. Revka 측에서 별도로 등록할 필요가 없습니다.

참고

이 MFA 게이트는 업스트림 Nevis IdP에 의해 적용됩니다. Revka는 로컬 액션 수준 챌린지를 위한 자체 TOTP/OTP 게이팅과, 게이트웨이용으로 별도로 컴파일되는 선택적 WebAuthn/FIDO2 하드웨어 키 경로도 제공합니다. 세 가지는 상호 보완적입니다.

역할-권한 매핑

각 [[security.nevis.role_mapping]] 블록은 하나의 Nevis 역할을 사용 가능한 Revka 도구와 워크스페이스에 매핑합니다.

[[security.nevis.role_mapping]]
nevis_role = "agent-operator"
revka_permissions = ["file_read", "file_write", "shell"]
workspace_access = ["production"]

필드	타입	설명
nevis_role	string	Nevis 역할 이름. 대소문자를 구분하지 않고 매핑됩니다(공백 제거 및 소문자 변환).
revka_permissions	list	이 역할이 호출할 수 있는 도구 이름. ["all"]은 모든 도구를 허용합니다.
workspace_access	list	이 역할이 접근할 수 있는 워크스페이스. ["all"]은 모든 워크스페이스를 허용합니다. 선택 사항(기본값: 없음).

평가 방식:

• 요청별 두 가지 검사. 도구 접근과 워크스페이스 접근이 독립적으로 평가됩니다. 도구 이름과 워크스페이스 이름 모두 대소문자를 구분하지 않고 매핑됩니다.
• 역할 간 합집합. 호출자가 여러 Nevis 역할을 보유한 경우 권한이 합산됩니다. 어떤 보유 역할이든 해당 접근을 허용하면 접근이 승인됩니다.
• "all"은 와일드카드. revka_permissions = ["all"]은 모든 도구를 허용하며, workspace_access = ["all"]은 모든 워크스페이스를 허용합니다.

세 가지 역할을 사용한 예시:

[[security.nevis.role_mapping]]
nevis_role = "admin"
revka_permissions = ["all"]
workspace_access = ["all"]

[[security.nevis.role_mapping]]
nevis_role = "operator"
revka_permissions = ["shell", "file_read", "file_write"]
workspace_access = ["production", "staging"]

[[security.nevis.role_mapping]]
nevis_role = "viewer"
revka_permissions = ["file_read"]
workspace_access = ["staging"]

이 설정에서: admin은 모든 워크스페이스에서 모든 도구를 사용할 수 있습니다. operator는 production 또는 staging에서 shell을 실행할 수 있지만 browser는 거부됩니다. viewer는 staging에서 파일을 읽을 수 있지만 shell과 file_write는 거부됩니다.

`all`은 매우 광범위합니다

revka_permissions = ["all"]은 위험도 높은 도구를 포함한 모든 도구에 대한 접근을 허용하며, workspace_access = ["all"]은 워크스페이스 범위 제한을 완전히 제거합니다. 진정한 관리자 역할에만 사용하고, 운영자/뷰어 역할에는 명시적이고 최소한의 도구 목록을 유지하십시오.

기본 거부(Deny-by-default)

IAM 정책은 명시적으로 허용하지 않은 모든 요청을 거부합니다.

• 알 수 없는 역할(일치하는 nevis_role 매핑 없음)은 거부됩니다.
• 역할이 없는 신원은 거부됩니다.
• 빈 도구 이름 또는 워크스페이스 이름은 거부됩니다.
• role_mapping 목록이 비어 있으면 모든 것이 거부됩니다. Nevis 역할이 admin인 사용자라도 해당 역할을 부여하는 매핑이 없으면 접근이 불가능합니다.

즉, role_mapping 블록 없이 Nevis를 활성화하면 매핑을 추가할 때까지 에이전트가 완전히 잠깁니다. 각 역할에 필요한 최소 권한부터 시작하고 의도적으로 확장하십시오.

중복 역할 보호

역할 이름은 색인화 전에 정규화(공백 제거 및 소문자 변환)됩니다. 두 매핑이 동일한 정규화 키로 축소되는 경우(예: "admin"과 " ADMIN ") Revka는 마지막 값이 자동으로 적용되도록 두지 않고 시작 시 duplicate role mapping 오류로 설정을 거부합니다. 마지막 값이 자동으로 적용되면 접근 권한이 의도치 않게 확대되거나 취소될 수 있으므로, 이는 엄격한 실패 조건입니다. 공백만 있는 빈 역할 이름은 중복으로 처리되지 않고 건너뜁니다.

게이트웨이 측 WebAuthn / FIDO2

Nevis와 별개로, 게이트웨이는 [security.webauthn] 섹션을 통해 FIDO2 하드웨어 토큰 및 플랫폼 인증기(YubiKey, SoloKey, Touch ID, Windows Hello)를 허용할 수 있습니다. 이 경로는 Revka가 webauthn cargo 기능과 함께 빌드된 경우에만 포함됩니다.

cargo build --release --features webauthn

전체 Nevis 배포 없이(또는 함께) 하드웨어 키 게이트웨이 인증이 필요한 경우 사용하십시오. 게이트웨이 엔드포인트 및 등록 흐름에 대해서는 TLS, 속도 제한, WebAuthn & 정적 서빙 및 Cargo 기능 플래그 & ADR을 참조하십시오.

배포 체크리스트

1. Nevis에 클라이언트를 등록합니다. OAuth2/OIDC 클라이언트(client_id, 선택적 client_secret)를 생성하고 instance_url과 realm을 기록합니다.

2. [security.nevis]를 설정합니다. enabled = true로 설정하고 instance_url, realm, client_id를 입력하며, 현재는 token_validation = "remote"로 설정합니다. client_secret을 추가합니다. 저장 시 enc2:<hex>로 암호화됩니다.

3. 역할 매핑을 추가합니다. Nevis 역할당 하나의 [[security.nevis.role_mapping]] 블록을 정의하고 revka_permissions와 workspace_access를 명시합니다. 매핑이 없으면 접근도 없습니다.

4. MFA를 활성화합니다. require_mfa = true로 설정하여 모든 인증된 요청에 Nevis에서의 FIDO2/패스키/OTP 완료를 요구합니다.

5. 시작 시 검증합니다. 게이트웨이를 재시작하고 정상적으로 로드되는지 확인합니다. 설정 오류(필수 필드 누락, 잘못된 token_validation)는 시작 시 즉시 실패합니다.

6. 감사 로그에서 확인합니다. 허용/거부 결정이 로그에 기록됩니다. 감사 로그에서 확인하십시오.

관련 페이지

보안 모델 Nevis IAM이 Revka의 심층 방어 계층에서 어떻게 통합되는지 설명합니다.

정책, 명령 & 샌드박싱 자율성 수준, 명령 허용 목록, 그리고 IAM이 그 위에 적용되는 정책 엔진.

시크릿, 페어링 & 디바이스 인증 베어러 토큰 페어링과 client_secret에 사용되는 암호화된 시크릿 저장소.

OTP 게이팅 & 긴급 정지 로컬 TOTP 챌린지와 긴급 정지 스위치.

감사 로그 IAM 허용/거부 결정이 기록되는 위치.

TLS, 속도 제한 & WebAuthn 게이트웨이 측 WebAuthn/FIDO2 엔드포인트 및 서빙 설정.