Apache RocketMQ ACL 2.0 새로운 업그레이드

저자: 투 종

소개

널리 사용되는 분산 메시징 미들웨어인 RocketMQ는 다양한 대규모 분산 시스템 및 마이크로서비스에서 널리 사용되며 비동기 통신, 시스템 분리, 피크 감소 및 밸리 필링, 메시지 알림에서 중요한 역할을 합니다. 기술이 발전하고 비즈니스 규모가 확장됨에 따라 보안 관련 문제가 점점 더 두드러지고 있으며 메시징 시스템의 액세스 제어가 특히 중요해졌습니다. 그러나 RocketMQ의 기존 ACL 1.0 버전은 더 이상 향후 개발을 충족할 수 없습니다. 따라서 우리는 RocketMQ 데이터의 보안을 더욱 향상시키기 위해 RocketMQ ACL 2.0 업그레이드 버전을 출시했습니다. 이 기사에서는 RocketMQ ACL 2.0의 새로운 기능, 작동 원리, 관련 구성 및 사례를 소개합니다.

업그레이드된 배경

ACL 1.0의 문제점

RocketMQ ACL 1.0의 인증 및 권한 부여 프로세스는 위 그림에 나와 있습니다. 사용 중에 다음과 같은 문제점이 있습니다.

액세스 제어를 우회하기 위한 IP 화이트리스트 : 표준 보안 관행에서 IP 화이트리스트는 클라이언트가 특정 IP 또는 IP 범위의 리소스에만 액세스하지 못하도록 제한하는 데 종종 사용됩니다. 그러나 ACL 1.0에서는 표준 관행의 보안 의도에서 벗어나 인증 검증을 우회하는 수단으로 IP 화이트리스트를 비정상적으로 사용하고 있다. 이러한 설계 편차는 특히 여러 클라이언트가 동일한 IP를 공유하는 공용 네트워크 시나리오에서 잠재적인 보안 위험을 초래할 수 있으며 이로 인해 승인되지 않은 IP 주소가 클러스터 데이터에 대한 일반적인 액세스 제어 검사를 우회할 수 있습니다.

관리 API의 세밀한 제어 부족 : RocketMQ는 130개 이상의 관리 및 제어 API를 제공하여 클러스터 구성, 주제 및 그룹의 메타데이터 관리는 물론 메시지 쿼리 및 사이트 재설정과 같은 작업을 지원합니다. 이러한 작업에는 민감한 데이터 처리가 포함되며 시스템 안정성에 영향을 미칩니다. 따라서 다양한 사용자 역할이나 책임에 따라 액세스 가능한 API 및 데이터의 범위를 정확하게 정의하는 것이 중요해졌습니다. 그러나 ACL 1.0은 주제, 그룹 메타데이터 및 브로커 구성을 포함한 9개의 API만 지원하며 나머지 API는 공격자가 시스템을 공격하고 민감한 데이터를 훔치는 데 사용될 수 있습니다. 또한 수많은 관리 API에 대한 액세스 제어를 구현하려면 기존 설계에 대한 많은 코딩 작업이 필요하며 새 API를 추가할 때 누락될 위험이 높아집니다.

클러스터 구성 요소 간의 액세스 제어 부족 : RocketMQ 아키텍처는 NameServer, Broker 마스터-슬레이브 노드 및 프록시와 같은 여러 주요 구성 요소를 다룹니다. 현재 이러한 구성 요소 간의 상호 액세스를 위한 주요 권한 확인 메커니즘이 누락되어 있습니다. 따라서 클러스터 외부에 브로커 슬레이브 노드 또는 프록시 구성 요소를 구축하면 기존 보안 메커니즘을 우회하여 클러스터의 민감한 데이터에 액세스하고 얻을 수 있습니다. 이는 의심할 여지 없이 시스템의 데이터 보안과 안정성에 큰 영향을 미칩니다. 클러스터 위협.

특성 및 원리

ACL 2.0의 새로운 기능

RocketMQ ACL 2.0은 ACL 1.0의 문제를 해결하고 다음과 같은 6가지 주요 새 기능도 제공합니다.

정밀한 API 리소스 권한 정의 : ACL 2.0은 모든 유형의 리소스에 대해 독립적인 액세스 제어를 달성하기 위해 클러스터, 네임스페이스, 주제 및 소비자 그룹을 포함하여 RocketMQ 시스템의 모든 리소스를 정의합니다. 또한 모든 API를 권한 제어 범위에 포함시켜 메시지 송수신, 클러스터 관리, 메타데이터 등 다양한 작업을 다루므로 모든 리소스의 모든 작업에 엄격한 권한 제어가 적용되도록 보장합니다.

승인된 리소스에 대한 다중 매칭 모드 : 리소스가 많은 클러스터 환경에서 각 리소스를 하나씩 승인하면 복잡한 구성 프로세스와 관리 부담이 발생합니다. 따라서 ACL 2.0에는 정확한 일치, 접두사 일치, 와일드카드 일치라는 세 가지 유연한 일치 모드가 도입되었습니다. 이러한 모드를 사용하면 사용자는 리소스의 명명 규칙 및 구조적 특성을 기반으로 통합 설정을 신속하게 수행하고 권한 관리 작업을 단순화하며 구성 효율성을 향상시킬 수 있습니다.

클러스터 구성 요소 간 접근 제어 지원 : 접근 제어 시스템에는 모든 리소스 유형과 API 작업이 포함되어 있으므로 클러스터 내 구성 요소 간의 연결 및 접근에도 브로커 마스터와 슬레이브 간의 리더 선택, 데이터 복제 등 권한 제어가 적용됩니다. 이를 통해 잠재적인 데이터 유출 문제와 시스템 안정성에 대한 위험을 효과적으로 방지하고 전체 클러스터의 보안과 신뢰성을 향상시킬 수 있습니다.

사용자 인증과 권한 확인의 분리 : 인증과 승인이라는 두 가지 주요 모듈을 분리함으로써 시스템은 다양한 시나리오의 요구에 적응할 수 있는 "인증 없이 인증만"과 같은 유연한 옵션을 제공할 수 있습니다. 또한 두 구성요소는 독립적으로 진화, 발전할 수 있어 다양한 인증 방식과 고급 인증 방식이 탄생하게 된다.

보안과 성능 간의 균형 : ACL이 활성화되면 클라이언트의 각 요청은 완전한 인증 및 권한 부여 프로세스를 거쳐야 합니다. 이는 시스템 보안을 보장하지만 성능 오버헤드도 발생합니다. ACL 2.0에서는 상태 비저장 인증 및 권한 부여 전략과 상태 저장 인증 및 권한 부여 전략이 제공되어 극단적인 보안 요구 사항과 제어 가능하지만 성능 우선 순위라는 두 가지 보안 및 성능 요구 사항을 충족합니다.

유연하고 확장 가능한 플러그인 메커니즘 : 현재 시장에는 다양한 인증 방법 구현이 있으며 인증 방법에도 다양한 시나리오에 대한 사용자 정의 요구 사항이 있습니다. 따라서 ACL 2.0은 인증 및 권한 부여의 향후 확장을 지원하고 사용자가 자신의 비즈니스 요구에 따라 해당 솔루션을 사용자 정의하고 구현할 수 있도록 다양한 수준에서 인터페이스를 정의하고 추상화하는 플러그인 프레임워크를 설계했습니다.

액세스 제어 모델

RBAC(역할 기반 액세스 제어)와 ABAC(속성 기반 액세스 제어)는 액세스 제어 시스템의 두 가지 주요 방법입니다. RocketMQ ACL 2.0은 이 두 가지 방법을 통합하여 보다 유연하고 강력한 액세스 제어 시스템을 만듭니다.

RBAC는 역할을 통해 권한을 할당하는 역할 기반 액세스 제어 모델입니다. RocketMQ ACL 2.0은 사용자 역할을 슈퍼 사용자(Super)와 일반 사용자(Normal)로 구분합니다. 슈퍼 사용자는 가장 높은 수준의 권한을 가지며 승인 없이 리소스에 액세스할 수 있으므로 클러스터 초기화 및 일일 운영 및 유지 관리 질문 시 권한 종속이 단순화됩니다. 일반 사용자는 리소스에 액세스하기 전에 해당 권한을 부여받아야 하며 이는 비즈니스 시나리오에서 리소스에 대한 주문형 액세스에 적합합니다.

ABAC는 사용자, 자원, 환경, 운영 등 다차원 속성을 통해 접근통제 정책을 표현하는 속성 기반 접근통제 모델입니다. RocketMQ ACL 2.0은 일반 사용자를 위한 유연한 액세스 제어 메커니즘을 제공합니다. 관리자가 비즈니스 요구 사항, 사용자 책임 및 기타 요소를 기반으로 리소스에 대한 보다 정교한 액세스 제어를 구현하도록 지원합니다.

보안 시스템에서 인증과 권한 부여는 각각 다른 역할을 합니다. RocketMQ ACL 2.0은 인증과 권한 부여를 모듈로 분리합니다. 이렇게 하면 두 구성 요소가 모두 해당 임무를 수행하고 시스템의 복잡성이 줄어듭니다. 인증 서비스는 사용자 신원의 적법성을 확인하는 데 전념하는 반면, 인증 서비스는 사용자 권한 및 액세스 제어 관리에 중점을 둡니다. 이러한 분할을 통해 코드 관리, 유지 관리 및 확장이 더 쉬워질 뿐만 아니라 사용자에게 사용 유연성도 제공됩니다. 필요에 따라 사용자는 인증 또는 권한 부여 서비스를 별도로 활성화하도록 선택하거나 두 가지를 동시에 활성화하도록 선택할 수 있습니다. 이를 통해 RocketMQ ACL은 간단한 시나리오의 신속한 배포를 충족하고 복잡한 환경의 엄격한 보안 요구 사항에 적응할 수 있습니다.

입증

인증은 액세스 요청을 시작한 사람의 신뢰성을 확인하도록 설계된 보안 메커니즘입니다. 이는 합법적으로 인증된 사용자 또는 엔터티만 보호된 리소스에 액세스하거나 특정 작업을 수행할 수 있도록 하는 데 사용됩니다. 간단히 말해서 인증은 리소스나 서비스에 액세스하기 전에 "당신은 누구입니까?"라는 질문에 대답하는 것입니다.

RocketMQ ACL 2.0 버전은 ACL 1.0과 동일한 인증 메커니즘, 즉 AK/SK 기반 인증 방식을 유지합니다. 이 방법은 주로 대칭 암호화 기술을 사용하여 클라이언트의 신원을 확인하고 민감한 인증 정보(예: 비밀번호)가 네트워크에서 일반 텍스트로 전송되지 않도록 보장하여 전반적인 인증 보안을 향상시킵니다.

에이전트 모델

RocketMQ 시스템의 액세스 제어 및 권한 관리를 개선하기 위해 ACL 2.0은 주요 모델에 대해 다음과 같은 개선 및 확장을 수행했습니다.

1. 통합 주제 모델의 추상화: 서로 다른 엔터티의 액세스 제어 및 권한 관리를 실현하기 위해 시스템의 여러 인스턴스가 리소스 액세스의 주제 역할을 할 수 있도록 통합 주제 인터페이스가 설계되었습니다. 사용자는 자원에 접근하는 주체 중 하나로서 이 모델에 따라 주체의 인터페이스를 구현한다. 이는 향후 새로운 엔터티 유형에 대한 권한 적응을 위한 확장 기능을 제공합니다.

2. 역할 분류 및 권한 부여:

슈퍼유저 : 관리과정을 단순화하기 위해 별도의 설정 없이 슈퍼유저에게 모든 권한이 자동으로 부여되어 시스템 초기화 및 일상적인 운영 및 유지관리가 간편해집니다.
일반 사용자 : 일반 사용자의 권한에는 명시적인 승인이 필요합니다. ACL 2.0은 조직의 정책 및 보안 요구 사항에 따라 일반 사용자에게 적절한 권한을 부여할 수 있는 관련 권한 관리 도구를 제공합니다.

3. 사용자 상태 관리 지원: 사용자 비밀번호 유출과 같은 보안 위험에 대처하기 위해 ACL 2.0은 사용자 활성화 및 비활성화 기능을 제공합니다. 보안사고 발생 시 사용자 상태를 비활성화하여 신속하게 출혈을 멈추게 하여 불법접근을 방지할 수 있습니다.

인증과정

클라이언트 프로세스:

RPC 요청을 구성할 때 클라이언트는 사용자 이름과 비밀번호가 설정되어 있는지 확인합니다. 구성되지 않은 경우 클라이언트는 요청을 직접 보냅니다.
구성된 경우 미리 설정된 암호화 알고리즘을 사용하여 요청 매개변수를 암호화하고 해당 디지털 서명(서명)을 생성합니다.
요청에 사용자 이름과 서명을 추가하고 인증을 위해 서버로 보냅니다.

서버 프로세스:

요청을 받은 후 서버는 먼저 인증이 켜져 있는지 확인합니다. 켜져 있지 않으면 확인 없이 통과하고, 켜져 있으면 다음 단계로 이동합니다.
서버는 요청 인증과 관련된 매개변수를 구문 분석 및 조합하고 사용자 이름 및 서명을 포함한 정보를 얻습니다.
사용자 이름을 통해 로컬 데이터베이스의 사용자 관련 정보를 쿼리합니다. 사용자가 존재하지 않으면 처리가 없음으로 반환되고 다음 단계로 진행됩니다.
사용자 비밀번호를 얻고, 동일한 암호화 알고리즘을 사용하여 서명을 생성하는 요청을 암호화하고, 두 서명이 일치하면 인증이 실패합니다.

권한 부여

핵심 아이디어

권한 부여는 액세스 요청자가 특정 리소스에 대해 작업할 권한이 있는지 여부를 확인하도록 설계된 보안 메커니즘입니다. 간단히 말해서 권한 부여는 리소스에 액세스하기 전에 "누가 어떤 상황에서 어떤 리소스에 대해 어떤 작업을 수행했는지"라는 질문에 대답하는 것입니다.

RocketMQ ACL 2.0은 "ABAC(속성 기반 액세스 제어)" 모델을 기반으로 다음과 같은 일련의 핵심 개념을 다룹니다. 시스템 구현에서 다음 개념은 전체 권한 관리 및 권한 부여 메커니즘의 설계 및 구현을 완료하기 위한 지침으로 사용됩니다.

권한 모델

ABAC(속성 기반 액세스 제어) 모델의 핵심 개념인 ACL 2.0은 권한 모델을 신중하게 설계했습니다. 핵심 사항은 다음과 같습니다.

이전 버전과 호환되는 권한 정책 : 기본적으로 ACL 2.0은 사용자가 정의한 권한만 일치하고 확인합니다. 일치하는 항목이 없으면 리소스에 액세스할 수 있는 권한이 없는 것으로 간주됩니다. 그러나 ACL 1.0에는 일치하지 않는 리소스에 대해 "권한 액세스 없음"과 "권한 액세스 있음"을 기본적으로 결정할 수 있는 기본 권한 설정이 있습니다. 따라서 ACL 1.0에서 ACL 2.0으로의 원활한 마이그레이션을 보장하기 위해 기본 권한 정책과의 호환성을 구현했습니다.

유연한 리소스 일치 모드 : 리소스 유형 측면에서 ACL 2.0은 다양한 유형의 리소스에 대한 액세스를 제어하는 데 사용되는 클러스터, 네임스페이스, 주제, 소비자 그룹 및 기타 유형을 지원합니다. 리소스 이름 측면에서는 정확한 일치(LITERAL), 접두사 일치(PREFIXED), 와일드카드 일치(ANY)의 세 가지 모드를 도입하여 사용자가 리소스의 명명 사양 및 구조를 기반으로 통합 액세스 규칙을 신속하게 설정하고 권한을 단순화할 수 있도록 지원합니다. . 관리하다.

미세 자원 작업 유형 : 메시지 전송 및 소비 인터페이스 측면에서 각각 PUB 및 SUB 작업으로 정의됩니다. 클러스터 및 리소스 관리 인터페이스 측면에서 CREATE, UPDATE, DELETE, LIST 및 GET의 5가지 작업이 정의됩니다. 이러한 작업 유형의 개선을 통해 사용자는 리소스 작업 수준에서 특정 인터페이스 정의에 대해 걱정할 필요 없이 작업에 대한 이해와 구성을 단순화할 수 있습니다.

견고한 접속 환경 검증 : ACL 2.0은 접속을 요청하는 환경 측면에서 클라이언트 요청의 IP 소스에 대한 검증을 추가합니다. 이 검증은 각 리소스 수준에서 제어되며 각 리소스를 정확하게 제어할 수 있습니다. IP 소스는 특정 IP 주소 또는 IP 세그먼트가 될 수 있어 다양한 세부 수준에서 IP 액세스 제어를 충족하고 시스템 보안에 견고한 방어선을 추가할 수 있습니다.

승인 절차

클라이언트 프로세스:

클라이언트가 RPC 요청을 생성할 때 이 호출에 대한 인터페이스 입력 매개변수를 생성하고 인터페이스는 권한 뒤에 있는 작업 정의에 해당합니다.
클라이언트는 인터페이스 입력 매개변수에 이번 방문에 대한 리소스 정보를 설정한 후 사용자, 리소스 등의 매개변수를 서버에 전달합니다.

서버 프로세스:

서버는 요청을 받은 후 먼저 인증이 켜져 있는지 확인합니다. 켜져 있지 않으면 확인 없이 통과하고, 켜져 있으면 다음 단계로 진행합니다.
서버는 요청에서 권한 부여 관련 매개변수를 구문 분석하고 조합합니다. 이러한 데이터에는 사용자 정보, 액세스된 리소스, 수행된 작업 및 요청된 환경이 포함됩니다.
사용자 이름을 통해 로컬 데이터 저장소에 있는 사용자 관련 정보를 쿼리합니다. 사용자가 존재하지 않으면 오류가 반환되며 다음 단계로 이동합니다.
현재 사용자가 슈퍼유저인지 확인합니다. 슈퍼유저인 경우 권한 확인 없이 바로 요청이 전달됩니다. 일반 사용자인 경우 자세한 권한 확인을 위해 다음 단계로 이동합니다.
사용자 이름을 기준으로 해당 권한 부여 정책 목록을 얻어 이번에 요청한 리소스, 작업, 환경을 일치시키고 우선 순위에 따라 정렬합니다.
우선순위가 가장 높은 승인 정책을 기준으로 결정이 이루어집니다. 승인 정책이 작업을 허용하면 승인 성공이 반환됩니다. 작업이 거부되면 권한 없음 오류가 반환됩니다.

인증 매개변수 분석

ACL 2.0에서는 권한 관련 매개변수(리소스, 작업 등 포함)의 구문 분석이 작업 유형 및 요청 빈도에 따라 최적화됩니다.

하드 코딩된 분석

메시지 전송 및 소비와 같은 인터페이스의 경우 매개변수가 상대적으로 복잡하고 요청 빈도가 상대적으로 높습니다. 파싱의 편의성과 성능 요구 사항을 고려하여 하드 코딩을 사용하여 파싱합니다.

주석 분석

관리 및 제어 인터페이스가 많은 경우 하드 코딩 작업량이 크고 이러한 인터페이스 호출 빈도도 낮으며 성능 요구 사항도 높지 않습니다. 따라서 코딩 효율성을 높이기 위해 분석에 주석을 사용합니다.

권한 정책 우선순위

권한 정책 일치 측면에서 퍼지 리소스 일치 모드를 지원하므로 동일한 리소스가 여러 권한 정책에 해당할 수 있습니다. 따라서 최종적으로 사용되는 권한 정책 집합을 결정하려면 우선 순위 메커니즘이 필요합니다.

다음과 같은 권한 부여 정책이 구성되어 있고, 위 우선순위 자원의 매칭 상황은 다음과 같다고 가정합니다.

인증 및 권한 부여 전략

보안과 성능의 절충 및 고려 사항으로 인해 RocketMQ ACL 2.0은 인증 및 권한 부여를 위한 두 가지 전략, 즉 상태 비저장 인증 및 권한 부여 전략(Stateless)과 상태 저장 인증 및 권한 부여 전략(Stateful)을 제공합니다.

무상태 인증 및 권한 부여 전략(Stateless) : 이 전략에 따라 각 요청은 독립적인 인증 및 권한 부여 프로세스를 거치며 이전 세션 및 상태 정보에 의존하지 않습니다. 이 엄격한 정책은 더 높은 수준의 보안 보증을 보장합니다. 권한 변경 사항은 대기 시간 없이 보다 실시간으로 후속 요청에 반영될 수 있습니다. 그러나 이 전략은 시스템 CPU 사용량 증가, 요청 시간 소모 등 처리량이 많은 시나리오에서 상당한 성능 부담을 초래할 수 있습니다.

상태 기반 인증 및 권한 부여 전략(상태 기반) : 이 전략에서는 동일한 클라이언트 연결, 동일한 리소스 및 동일한 작업에서 첫 번째 요청이 완전히 인증되고 권한이 부여되며 후속 요청은 반복적으로 인증 및 권한이 부여되지 않습니다. 이 방법은 성능을 효과적으로 저하시키고 요청 시간을 줄일 수 있으며 특히 처리량이 많은 시나리오에 적합합니다. 그러나 이 전략은 보안 문제를 야기할 수 있으며 권한 변경 사항이 실시간으로 적용되지 않을 수 있습니다.

이 두 가지 전략 중 하나를 선택할 때는 시스템의 보안 요구 사항과 성능 요구 사항을 고려해야 합니다. 시스템의 보안 요구 사항이 높고 특정 성능 손실을 허용할 수 있는 경우 상태 비저장 인증 및 권한 부여 전략이 더 나은 선택일 수 있습니다. 반대로, 시스템이 많은 수의 동시 요청을 처리해야 하고 보안 요구 사항을 어느 정도 완화할 수 있는 경우 상태 저장 인증 및 권한 부여 전략이 더 적합할 수 있습니다. 실제 배포 중에는 특정 비즈니스 시나리오 및 보안 요구 사항을 기반으로 결정을 내려야 합니다.

플러그인 메커니즘

RocketMQ ACL 2.0은 향후 인증 방법의 지속적인 개발에 적응하고 특정 시나리오에 대한 사용자 맞춤형 요구 사항을 충족하기 위해 여러 측면에서 유연성과 확장성을 제공합니다.

인증 및 권한 부여 정책 확장 : 기본적으로 RocketMQ ACL 2.0은 대부분의 사용자의 보안 및 성능 요구 사항을 충족하기 위해 상태 비저장 인증 및 권한 부여 정책(Stateless)과 상태 저장 인증 및 권한 부여 정책(Stateful)을 제공합니다. 그러나 보안과 성능 간의 균형을 유지하기 위해 앞으로도 더 나은 전략을 모색할 수 있습니다.

인증 및 권한 부여 방법 확장 : 현재 시장에는 성숙한 구현이 많이 있습니다. RocketMQ는 현재 그 중 하나만 플러그인 기능을 통해 구현하고 있으며 앞으로 더 많은 기능을 쉽게 도입할 수 있습니다. 인증 메커니즘. 인증 측면에서 RocketMQ는 광범위한 사용자 요구에 적응하기 위해 ABAC 모델을 기반으로 일련의 주류 인증 방법을 구현합니다. 그러나 향후 개발에 적합한 더 많은 솔루션의 적용을 촉진하는 플러그인 기능도 제공합니다.

인증 및 권한 부여 프로세스 조정 : RocketMQ ACL 2.0은 책임 체인 디자인 패턴을 기반으로 기본 인증 및 권한 부여 프로세스를 유연하게 조정합니다. 사용자는 이러한 책임 체인 노드를 확장하거나 다시 작성하여 특정 비즈니스 시나리오에 대한 인증 및 권한 부여 논리를 사용자 정의할 수 있습니다.

사용자 및 권한 저장소 확장 : RocketMQ는 기본적으로 RocksDB를 사용하여 사용자 및 권한 데이터를 Broker 노드에 로컬로 저장합니다. 그러나 사전 정의된 인터페이스를 구현함으로써 사용자는 이 데이터를 타사 서비스 또는 스토리지 시스템으로 쉽게 마이그레이션하여 아키텍처 설계 및 운영 효율성을 최적화할 수 있습니다.

감사 로그

감사 로그는 인증 및 권한 부여와 관련된 모든 액세스 제어 작업을 기록하고 모니터링하는 데 사용됩니다. 업그레이드 로그를 통해 모든 액세스 요청을 추적하여 시스템의 안정성과 보안을 보장하는 동시에 문제 해결, 안전한 업그레이드 수행 및 규정 준수 요구 사항 충족에도 도움이 됩니다.

RocketMQ ACL 2.0은 인증 및 권한 부여와 관련된 감사 로그를 지원합니다.

인증로그

# 认证成功日志
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 认证失败日志
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

승인 로그

# 授权成功日志
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授权失败日志
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

구성 및 사용

배포 아키텍처

배포 아키텍처 측면에서 RocketMQ는 스토리지 및 컴퓨팅 통합 아키텍처와 스토리지 및 컴퓨팅 분리 아키텍처라는 두 가지 배포 형태를 제공합니다.

통합 스토리지 및 컴퓨팅 아키텍처

RocketMQ 통합 스토리지 및 컴퓨팅 아키텍처에서 Broker 구성 요소는 컴퓨팅 및 스토리지 책임을 모두 맡고 외부 서비스를 제공하며 모든 클라이언트로부터 액세스 요청을 받습니다. 따라서 브로커 구성 요소는 인증 및 권한 부여에 중요한 역할을 합니다. 또한 브로커 구성 요소는 인증 및 권한 부여와 관련된 메타데이터의 유지 관리 및 저장도 담당합니다.

저장 및 계산 분리 아키텍처

RocketMQ의 저장 및 계산 분리 아키텍처에서 저장은 Broker 구성 요소에 의해 처리되고 계산은 Proxy 구성 요소에 의해 처리됩니다. 따라서 요청의 인증 및 권한 부여는 프록시 구성 요소에 의해 수행됩니다. 브로커는 메타데이터 저장을 담당하며 프록시 구성 요소에 필요한 인증 및 권한 부여 메타데이터 쿼리와 관리 서비스를 제공합니다.

클러스터 구성

인증 구성

매개변수 목록

서버 측에서 인증 기능을 활성화하려는 경우 관련 매개 변수 및 사용 사례는 주로 다음과 같습니다.

브로커 구성

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

프록시 구성

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

승인 구성

매개변수 목록

서버 측에서 인증 기능을 활성화하려는 경우 관련 매개변수 및 사용 사례는 주로 다음을 포함합니다.

브로커 구성

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

프록시 구성

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

사용하는 방법

명령줄 사용법

사용자 관리

ACL 사용자 관리와 관련된 인터페이스 정의 및 사용 사례는 다음과 같습니다.

인터페이스 정의

사용 사례

# 创建用户
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 创建用户，指定用户类型
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新用户
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 删除用户
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户详情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查询用户列表，带过滤条件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

ACL 관리

ACL 인증 관리와 관련된 인터페이스 정의 및 사용 사례는 다음과 같습니다.

인터페이스 정의

사용 사례

# 创建授权
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授权
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 删除授权
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 删除授权，指定资源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查询授权列表，带过滤条件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权详情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

클라이언트 사용

ACL의 사용에 대해서는 ACL 2.0과 ACL 1.0이 차이 없이 동일하게 사용됩니다. 자세한 내용은 공식 사례를 참조하세요.

메시지 보내기

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

메시지 소비

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

확장 및 마이그레이션

확장

클러스터가 실행되는 동안 브로커를 확장하려면 모든 메타데이터를 새 브로커에 동기화해야 합니다. ACL 2.0은 이 작업을 지원하기 위해 해당 복사 사용자 및 복사 인증 인터페이스를 제공합니다.

인터페이스 정의

사용 사례

# 拷贝用户
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 拷贝授权
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

이주하다

이미 ACL 1.0을 사용하고 있고 ACL 2.0으로 원활하게 마이그레이션하려는 경우 해당 솔루션도 제공됩니다. 다음 구성만 수행하면 됩니다.

구성 정의

브로커의 구성 파일에서 다음 구성을 활성화합니다.

migrateAuthFromV1Enabled = true

특별 참고 사항

위 구성을 활성화하면 브로커 시작 중에 자동으로 실행이 시작됩니다. 이 마이그레이션 기능은 ACL 1.0의 사용자 권한 정보를 ACL 2.0의 해당 저장 구조에 기록합니다.

ACL 2.0에 아직 존재하지 않는 사용자 및 권한은 시스템에 의해 자동으로 추가됩니다. 마이그레이션 기능은 ACL 2.0에서 수정된 사항을 덮어쓰지 않도록 기존 사용자 및 권한을 덮어쓰지 않습니다.

ACL 1.0의 IP 화이트리스트는 액세스 제어 검사를 우회하는 데 사용되며 ACL 2.0의 동작과 일치하지 않으므로 ACL 2.0으로 마이그레이션되지 않습니다. 관련 기능을 이미 사용한 경우 마이그레이션하기 전에 변환을 완료하세요.

계획 및 요약

계획

RocketMQ ACL의 향후 계획은 다음 두 가지 측면에 반영될 수 있습니다.

풍부한 인증 및 권한 부여 확장 : 시장에는 풍부한 인증 및 권한 부여 솔루션이 있으며 기타 스토리지 또는 컴퓨팅 제품도 다양한 구현 방법을 채택합니다. RocketMQ ACL은 업계의 발전 추세를 따라잡기 위해 앞으로도 더욱 광범위하고 변화하는 고객 요구 사항을 충족하기 위해 혁신을 이루기 위해 노력할 것입니다. 동시에 우리는 보안과 성능 사이의 이상적인 균형을 달성하기 위해 계속해서 연구를 심화하고 더 나은 인증 및 권한 부여 전략을 개발할 것입니다.
시각적 사용자 권한 작업 : 현재 사용자 및 권한은 명령줄 도구를 통해서만 ACL에서 구성할 수 있으므로 사용자에게 친숙하지 않습니다. 앞으로는 RocketMQ Dashboard에서 명확하고 사용하기 쉬운 시각적 관리 인터페이스를 제공하여 구성 프로세스를 단순화하고 관리에 대한 기술적 한계를 낮출 수 있기를 바랍니다. 한편, 기존 대시보드에는 아직 ACL 접근 제어 시스템이 통합되어 있지 않으며, 이 시스템도 향후 통합되어 사용자에게 대시보드의 다양한 리소스를 조작할 수 있는 접근 권한을 제공할 예정입니다.

요약하다

RocketMQ ACL 2.0은 모델 디자인, 확장성, 보안 및 성능 측면에서 완전히 새로운 업그레이드를 거쳤습니다. 이는 권한 구성 프로세스를 단순화하면서 사용자에게 정교한 액세스 제어를 제공하도록 설계되었습니다. 누구나 새 버전을 사용해 보고 프로덕션 환경에 적용해 볼 수 있습니다. RocketMQ 커뮤니티의 성장과 기술 발전을 공동으로 촉진하기 위해 커뮤니티 내 모든 사람의 피드백, 토론 및 참여를 기대합니다. Apache RocketMQ 중국 개발자 DingTalk 그룹에 가입하신 것을 환영합니다. (그룹번호: 21982288)

관련된 링크들:

[1] RocketMQ 중국어 학습 사이트 ttps://rocketmq-learning.com

[2] 클라우드 메시지 큐 RocketMQ https://www.aliyun.com/product/rocketmq