Couchbase의 N1QL 쿼리 서비스에 대한 인증 및 권한 부여는 여러 가지 방법으로 작동합니다.
- rest 요청을 통해 자격 증명 전달 - curl https://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces" -u Admin:pwd
- creds named 매개변수 및/또는 쿼리 매개변수를 사용하여 자격 증명 전달하기 - curl https://localhost:8093/query/service?pretty=true -d "statement=select * from system:keyspaces&creds=[{사용자:"관리자","비밀번호":"pass"}]"
- 요청에 기본 인증 사용
- 1,2와 유사하게 -u -p -creds 옵션과 \SET 명령을 사용하여 cbq에서 요청합니다.
- TLS용 X.509 인증서
- 노드 간 암호화
RBAC가 추가되면서 크레딧 쿼리 매개변수가 중복되었지만 이전 버전과의 호환성을 위해 계속 지원됩니다.
X509 인증서 지원 추가의 목표는 인증 기관에서 신뢰하는 인증서를 사용하여 클라이언트-서버 암호화를 강화하는 것입니다.
X.509 인증서는 클라이언트-서버 통신을 위한 서버 인증 및 암호화를 가능하게 합니다. Couchbase는 X509 인증서를 사용하여 서버 및 클라이언트 인증을 모두 지원하며 인증서를 관리하려면 전체 관리자 또는 보안 관리자 권한이 있어야 합니다. 이 문서에서는 Couchbase에서 인증을 위한 서버 측 X.509 인증서 지원에 대해 설명합니다. 클라이언트도 Couchbase Server의 신원을 확인할 수 있지만 이에 대해서는 다른 문서에서 설명합니다.
X509 인증서가 사용되는 가장 일반적인 시나리오는 클라이언트가 인터넷을 통과해야 하는 경우입니다, 애플리케이션과 카우치베이스 서버 간 또는 데이터 센터 간 유선으로 민감한 데이터를 전송할 때 또는 규정 준수 규정에 의해 요구되는 경우(XDCR).
X.509 인증서란 무엇인가요?
서버의 신원을 확인하는 신뢰할 수 있는 인증 기관이 서명한 공개 키를 배포하는 데 사용되는 공개 키 인증서입니다. 이 인증서를 사용하면 클라이언트는 요청이 알 수 없는 서버로 전송되지 않는다는 것을 확신할 수 있습니다. 이 인증서는 인증 기관이라고도 하는 제3자가 서명합니다. CA는 디지털 인증서를 발급하는 기관입니다. CA는 실제로 CA 계층 구조라고 하는 일련의 CA로 구성됩니다. 이 CA 계층 구조는 모든 노드 또는 최종 엔터티 인증서가 의존하는 신뢰 체인을 구성합니다. 이 체인에는 루트 CA 공개 키가 포함되어 있지 않습니다.
계층적 공개 키 인프라(PKI)에는 일반적으로 3가지 종류의 계층이 있습니다. 1티어, 2티어 및 N티어입니다. 이 계층 구조의 최상위에 있는 CA를 Root-CA라고 합니다. 그 이후의 모든 CA를 중간 CA라고 하며, n번째(마지막) CA를 노드 CA라고 합니다.
주의해야 할 중요한 사항은 다음과 같습니다. 보안 연결을 설정하는 데 사용되는 인증서를 신뢰하려면 연결 중인 디바이스의 신뢰할 수 있는 저장소에 포함된 CA에서 발급한 인증서여야 합니다.
1티어/단일티어 CA 권한
단일 CA로 구성되는 것은 가장 단순한 형태의 CA 계층 구조이지만 일반적으로 프로덕션 환경에서는 이 루트 CA가 손상되면 전체 PKI가 손상됩니다. 여기서 루트 CA는 발급 CA이기도 합니다. 루트 인증서 바로 아래에 있는 모든 인증서는 그 신뢰성을 상속받습니다.
2계층 CA 권한
이는 루트 CA가 중간 CA로 알려진 한 하위 CA에 대한 인증서를 발급한 것으로 구성됩니다. 여기서 차이점은 발급된 인증서는 중간 CA를 통해 신뢰할 수 있는 기관에서 발급한 것이므로 신뢰할 수 있다는 것입니다.
루트 CA 서명-> 중간 CA 징후 -> CA 발급/클러스터 CA
N-티어 CA 권한
대부분의 프로덕션 배포에서 계층 구조에는 여러 개의 CA가 있습니다. 루트 CA는 중간 CA에 인증서를 발급하고 중간 CA는 다음 인증서를 생성합니다. 중급 인증서클러스터 인증서와 같은 클라이언트 인증서에 서명하는 데 사용됩니다:
- 신뢰할 수 있는 루트 CA > 중간 CA > 클러스터 인증서
- 신뢰할 수 있는 루트 CA > 중간 CA 1 > 중간 CA 2.... > 중간 CA n > 클러스터 인증서
2계층 계층은 N계층 계층의 하위 유형입니다.
위의 모든 경우에 인증서 체인은 루트 CA까지 확인해야 합니다. 신뢰 체인에는 모든 중간 인증서와 연결된 인증서가 포함되어 있습니다.
참고 사항 - 여기 모든 중간 인증서를 서버에 설치해야 합니다. 그렇지 않으면 일부 클라이언트는 연결이 안전하지 않은 것으로 간주합니다. 이 경우 '신뢰할 수 없음' 경고가 표시됩니다.
카우치베이스 클러스터에서 X.509 설정하기
인증서를 설정하기 전에 몇 가지 전제 조건 - 다음과 같이 하세요.
- 인증서는 유효한 .pem 형식의 RSA 키 인증서여야 합니다.
- 인증서가 유효하지 않아야 합니다 - 현재 시간은 다음 사이에 속해야 합니다. 부터 유효 그리고 유효한 대상 인증서에 설정된 대로
- 2048비트 이상의 RSA 키 길이를 사용합니다. (컴퓨팅 성능이 향상됨에 따라 RSA 키 길이가 길수록 보안이 강화됩니다.)
- 단일 노드 클러스터를 사용하면 노드 인증서에 해당하는 디렉터리가 1개가 됩니다. 멀티 노드 클러스터에서는 클러스터의 각 노드에 해당하는 여러 디렉터리를 만듭니다(예: node1, node2 등).
- 중간 CA가 여러 개인 경우, 인증서 체인에서 올바른 순서로 스택을 쌓아야 합니다.
- 프라이빗 노드 키와 체인을 입력해야 합니다.var/lib/couchbase/inbox 서비스/클러스터 엑스가 배포된 위치의 OS 빈 디렉터리를 기준으로 합니다.
이름 지정 규칙
ca.pem - 루트 CA의 공개 키
int1.pem - 중간 CA의 공개 키(1번. 중간 CA가 여러 개 있는 경우 적절한 이름을 지정하여 올바른 순서로 체인에 추가합니다. 이렇게 하면 노드에 가장 가까운 중간 CA가 표시됩니다.)
node1.pem - 노드 1 CA의 공개 키 (node2.pem - 노드 2 CA의 공개 키 등)
node1.key - 노드 1 CA의 개인 키
chain.pem - 노드 공개 키와 노드 공개 키에 서명한 중간 공개 키가 포함된 인증서 체인입니다.
저희는 openssl 도구를 사용하여 인증서를 만듭니다. 명령어 자체에 대한 자세한 내용은 해당 설명서를 참조하세요.
X.509 인증서를 설정하는 단계
1단계 - 루트 개인 키 만들기
openssl genrsa -out ca.key 2048 2>/dev/null
라는 RSA 개인 키를 생성합니다. ca.key (-아웃 파일 이름), 즉 2048비트입니다.
키를 생성할 때 . 또는 + 기호가 표시됩니다. 이는 키 생성의 진행 상황을 나타냅니다. 는 테스트를 통과한 각 숫자를 나타내며 +는 숫자가 밀러-라빈 소수성 테스트의 한 라운드를 통과했음을 의미합니다. 줄 바꿈이 표시되면 키가 성공적으로 생성되었으며 해당 숫자(소수 2개)가 모든 소수 테스트를 통과했음을 의미합니다. 자세한 내용은 openssl-genrsa 문서를 참조하세요.
2단계 - 클러스터 CA로 사용되는 루트 공개 키를 생성합니다.
openssl req -신규 -x509 -days 365 -sha256 -key ca.key -out ca.pem -subj '/C=US/O=Couchbase/CN=Couchbase Root CA' 2>/dev/null
1년(-일 단위로 365일) 동안 유효한 sha256 서명(-sha256. 더 높은 보안을 의미)으로 새 자체 서명된 루트 인증서(-x509 옵션) 요청을 생성합니다. 공개 키 ca.pem(-out)은 개인 키를 지정하는 -key 옵션을 사용하여 개인 키에서 파생됩니다.
X.509 인증서에는 주체 DN(고유 이름) 필드가 있으며 주체 대체 이름 확장에 여러 이름을 가질 수도 있습니다. 이는 상대 DN으로 만들어집니다.
CN = 일반 이름, O = 조직, C = 국가 이름
인증서 발급자는 Couchbase 루트 CA의 CN(일반 이름)을 갖도록 지정되어 있습니다: 이 이름에서 알 수 있듯이 인증서는 Couchbase의 루트 인증서가 됩니다.
3단계 - 중간 개인 키 생성(또는 위에서 설명한 대로 N 계층 구조를 사용하는 경우 키)
openssl genrsa -out int1.key 2048 2>/dev/null
4단계 - 중간 인증서 서명 요청 생성
openssl req -new -key int1.key -out int1.csr -subj '/C=US/O=Couchbase/CN=Couchbase Intermediate CA' 2>/dev/null
CSR 또는 인증서 서명 요청은 신청자가 인증서를 신청하기 위해 CA에 보내는 요청입니다. 사용자 지정: 확장 파일을 사용하여 X.509 인증서의 기능을 추가하거나 제한할 수 있습니다. 이 정보는 클러스터의 모든 노드에서 사용됩니다. 예를 들면 다음과 같습니다.
cat > v3.ext <<EOF
기본 제약 조건 = CA:FALSE
subjectKeyIdentifier = 해시
권한키 식별자 = keyid,발급자:항상
EOF
모든 표준 확장자의 광범위한 목록은 X509 PKI 및 CRL 프로필에 대한 RFC 5280의 4.2절을 참조하세요. - https://tools.ietf.org/html/rfc5280
5단계 - 중간 인증서 만들기
openssl x509 -req -in int1.csr -CA ca.pem -CAkey ca.key -CAcreateserial -CAserial rootCA.srl -extfile v3.ext -out int1.pem -days 365 2>/dev/null
csr 파일을 읽고 루트 CA 키를 다음 주소로 전달합니다. 루트 인증서의 기관을 설정합니다. 루트 CA 암호화된 키는 중간 CSR을 서명하는 데 사용됩니다. 서명하기 전에 루트 CA에 대한 일련 번호 파일을 설정해야 합니다. 이는 각 인증서가 고유한 일련 번호를 가질 수 있도록 하기 위해서입니다. 이 작업은 -CAcreateserial -CAserial 옵션을 사용하여 수행합니다. rootCA.srl은 일련 번호 파일입니다. 이 파일은 ASCII 번호가 있는 간단한 텍스트 파일입니다. 인증서는 앞서 정의한 확장자를 사용하여 사용자 지정되며 1년 동안 유효합니다. 언제 인증서에 대한 암호를 묻는 메시지가 나타납니다. 메시지에 따라 적절한 문구를 입력합니다. 이 문구를 기억하세요.
마지막으로 루트 및 중간 CA 인증서를 얻었습니다. 이제 노드 인증서를 설정하고 루트 CA 및 중간 키로 서명할 차례입니다.
6단계 - 노드 키 및 CSR 설정
openssl genrsa -out node1.key 2048 2>/dev/null
노드에 대한 암호화된 키가 생성되면 노드 csr을 설정합니다.
openssl 요청 -새 -key node1.key -out node1.csr -subj "/C=US/O=Couchbase/CN=server1_linux" 2>/dev/null
여기서 인증서 주체에 정의된 일반 이름은 /etc/hosts에 정의 및 매핑된 노드 이름입니다.
노드 csr을 설정할 때 노드 이름(선호), IP 주소 또는 SAN(주체 대체 이름) 인증서가 있는 URI를 사용합니다.
인증서 ID를 지정하는 일반적인 방법은 인증서의 주체 DN에 있는 CN(일반 이름)을 사용하는 것입니다. 멀티홈 호스트에 인증서를 배포하는 경우, 대체 ID를 사용하여 인증서를 정의해야 합니다. subjectAltName 인증서 확장.
"subjectAltName = IP:172.23.99.49"
7단계 - 적절한 확장자를 사용하여 노드 인증서를 생성합니다.
openssl x509 -req -in node1.csr -CA int1.pem -CAkey int1.key -CAcreateserial \.
-CAserial intermediateCA.srl -out node1.pem -days 365
이는 위의 중간 인증서를 생성하는 단계와 유사합니다.
8단계 – 인증서 체인 생성
cat node1.pem int1.pem > chain.pem
모든 중간 및 노드 인증서를 올바른 순서로 연결합니다. 루트 인증서는 체인에 포함되지 않습니다. 이 체인을 통해 클라이언트는 루트 인증서에 대해 중간 인증서를 확인할 수 있습니다.
9단계 - 인증서 배포
- 노드 암호화된 인증서와 체인 인증서를 받은 편지함 폴더에 복사합니다. ../var/lib/couchbase/inbox 바이너리가 실행되는 위치에 따라 OS에 맞게 설정하고 chmod a+x를 사용하여 적절한 권한을 부여합니다.
- node1.key 및 chain.pem이 ../inbox에 복사됩니다.
- chmod a+x node1.key
- chmod a+x chain.pem
- 서버에 업로드
- curl -X POST -data-binary ca.pem https://Administrator:password@172.23.99.49:8091/controller/uploadClusterCA
- curl -X POST https://Administrator:password@172.23.99.49:8091/node/controller/reloadCertificate
클러스터 인증서를 Couchbase에 로드하면 먼저 유효한 X.509 인증서인지 확인합니다. 다음으로 노드별 인증서가 클러스터 인증서에 의해 서명되지 않은 경우, 구성하는 동안 각 노드에 대해 경고가 표시됩니다. 노드별 인증서가 업데이트되어 클러스터 인증서에 의해 서명되면 각 노드에 대한 경고는 사라집니다.
N1QL CURL() 쿼리 또는 cbq 셸에서 인증서 사용
제3자가 서명한 인증서를 확인하기 위해 라이브러리는 로컬 컴퓨터에 저장된 인증서를 사용합니다. Couchbase 클러스터의 각 쿼리 노드에 대해 ..//var/lib/couchbase/n1qlcerts 폴더에는 CURL()에 필요한 certs가 포함되어 있습니다. 이 폴더에서 certs를 찾을 수 없으면 오류가 발생합니다. cacert 옵션은 함수에 인증서 이름을 전달하는 데 사용됩니다. 경로를 전달하면 오류가 발생합니다.
select CURL("https://127.0.0.1:18091/pools",{"요청":"GET","user":"Bucketuser:password","cacert":"ca.pem"})
셸을 사용하여 연결하려면 cacert, cert 및 키 옵션을 사용합니다.
./cbq -cacert ca.pem -cert chain.pem -key node1.key -engine https://172.23.99.49:18091
이 문서를 통해 서버에서 X509 인증서를 설정하고 N1QL 쿼리 및 CBQ 셸과 함께 사용하는 방법을 배웠습니다. 다음 글에서는 클라이언트 측 인증서에 대해 자세히 살펴보겠습니다.
