InfoGrab Docs

인증 코드 리뷰 가이드라인

인증 코드 리뷰 가이드라인에 대해 설명합니다.

이 페이지는 정책 변경, 권한 정의 및 인증 로직과 관련된 머지 요청을 리뷰를 위해 준비하는 방법에 대한 Govern:Authorization 팀 의 지침을 제공합니다. 역할 YAML 파일이 진실의 원천입니다 # 역할 정의 YAML 파일 ( config/authz/roles/*.yml )은 각 역할이 가지는 권한에 대한 단일 진실의 원천입니다. 정책 파일에는 역할 조건에 기반하여 권한을 부여하는 enable 규칙이 포함되어서는 안 됩니다. 대신, 권한을 적절한 역할 YAML 파일에 추가하고 기능 또는 설정이 사용 불가능할 때 액세스를 제한하기 위해 정책에서 prevent 규칙을 사용하십시오. # 나쁜 예 - 정책 파일에서 역할에 대한 권한 활성화 rule { developer & model_registry_enabled }.policy do enable :write_model_registry end # 좋은 예 - 권한이 developer 역할 YAML에 있음 # (config/authz/roles/developer.yml) # raw_permissions: # - write_model_registry # # 정책은 기능이 사용 불가능할 때만 제한: rule { ~model_registry_enabled }.prevent :write_model_registry 이 패턴은 역할 권한을 다음과 같이 만듭니다: 기계 판독 가능 : GATE와 같은 외부 시스템이 정책 로직을 평가하지 않고도 역할의 권한을 결정할 수 있습니다. 열거 가능 : 하나의 YAML 파일을 읽어서 역할이 가지는 모든 권한을 볼 수 있습니다. 예측 가능 : 역할은 항상 전체 권한 집합으로 시작합니다. 조건은 액세스를 제거하기만 하며, 확장하지 않습니다. 파일 구성 # 동일한 조건에 대한 모든 prevent 규칙은 하나의 .policy 블록에 있어야 하며, 파일 전체에 분산되어서는 안 됩니다. # 나쁜 예 - 동일한 조건에 대한 prevent가 파일 전체에 분산됨 rule { ~security_dashboard_enabled }.prevent :read_vulnerability rule { ~security_dashboard_enabled }.prevent :admin_vulnerability # 좋은 예 - 동일한 조건에 대한 모든 prevent가 함께 그룹화됨 rule { ~security_dashboard_enabled }.policy do prevent :admin_vulnerability prevent :read_vulnerability end 안티패턴 # 기본 정책에서 권한을 활성화하지 마십시오 # BasePolicy 는 모든 다른 정책에 의해 상속되므로, 여기서 활성화된 모든 권한은 시스템의 모든 개체에서 암묵적으로 사용 가능합니다. 권한이 어떤 리소스에 대해 인증되는지에 대한 제약이 없으므로 이는 모호성과 보안 위험을 만듭니다. 동적 권한 정의 피하기 # 동적으로 정의된 권한은 코드베이스에서 추적하기 어렵습니다. 명시적으로 선언되지 않고 런타임에 생성된