카우치베이스 서버 내 TLS 이해
In 1부 그리고 파트 2 에서 TLS의 역사, 관련 구성 요소 및 작동 방식에 대해 설명했습니다. 이 가이드의 마지막 3부에서는 이 모든 것을 종합하여 Couchbase Server에서 TLS가 어떻게 작동하는지 알아봅니다.
카우치베이스 클러스터 인증서
Couchbase Server에서 클러스터 인증서는 모든 것을 하나 이상의 신뢰할 수 있는 CA(인증 기관)에 연결하며, 데이터베이스 암호화를 직접 처리하지 않습니다. 대신, 클러스터 내의 노드별 인증서에 대한 신뢰 체인을 설정합니다.
Couchbase Server 배포의 모든 신뢰 당사자는 클러스터 인증서를 설치 및 신뢰해야 합니다. 웹 브라우저에 신뢰할 수 있는 루트 CA가 있는 이전 예와 마찬가지로, Couchbase 배포에서 각 Couchbase Server 노드 및 SDK 중 하나를 사용하는 연결 애플리케이션은 클러스터 인증서를 신뢰해야 합니다. 또한 클러스터 간 데이터를 안전하게 복제하기 위해 데이터 센터 간 복제(XDCR) 기능을 사용하는 추가 Couchbase Server 클러스터로 가져옵니다.
서비스형 데이터베이스(DBaaS) 제품인 Couchbase Capella에서는 모든 클러스터가 실제로 동일한 인증 기관을 사용하므로 모두 동일한 클러스터 인증서를 사용합니다. 그리고 2022년 초부터 이후 출시되는 모든 공식 Couchbase SDK에는 기본적으로 Capella 클러스터 인증서를 자동으로 신뢰하는 기능이 포함되어 있습니다.
네트워크 암호화를 위한 노드 인증서
노드 인증서와 노드별 개인 키는 Couchbase Server에서 네트워크 암호화를 담당하는 기본 구성 요소입니다. 노드 인증서는 신뢰할 수 있는 인증 기관(CA)에서 생성하며 CA의 개인 키(일명 클러스터 공개 키/인증서와 연결된 개인 키)로 서명됩니다.
다음은 Couchbase 노드 인증서를 만드는 과정입니다.
-
- CSR(인증서 서명 요청)은 내장된 노드의 공개 키를 사용하여 인증 기관에 요청합니다.
- 내장된 노드 공개 키를 포함하여 노드 인증서가 생성되며, 이는 CA 시스템 자체의 클러스터 개인 키를 사용하여 서명됩니다.
- 그런 다음 노드 인증서가 요청자에게 다시 제공됩니다.
이러한 인증서는 Couchbase 서버 노드 간의 보안 통신을 용이하게 하고 SDK에서 개별 Couchbase 서버 노드와의 암호화된 연결을 가능하게 합니다. 노드 인증서와 관련된 주요 사항은 다음과 같습니다:
노드 간 암호화: 노드 인증서는 Couchbase 서버 노드 간의 통신 채널을 보호하여 클러스터 내에서 데이터가 이동할 때 데이터를 보호합니다.
SDK 연결: SDK가 개별 Couchbase 서버 노드에 연결할 때 노드 인증서는 통신이 암호화되어 데이터 기밀성을 유지하도록 보장합니다.
HTTPS를 통한 관리자 GUI 액세스: 관리자는 노드 인증서를 활용하여 HTTPS를 통해 Couchbase 서버의 그래픽 사용자 인터페이스(GUI)에 안전하게 액세스할 수 있습니다.
SDK가 Couchbase Server 노드에 암호화된 연결을 만드는 방법의 예를 보면 다양한 구성 요소가 작동하는 것을 볼 수 있습니다. 다소 간단하게 설명하기 위해 일부 세부 사항은 일부러 생략했습니다.
SDK는 TLS 연결을 설정하는 클러스터의 각 Couchbase 서버 노드에 대해 이러한 단계를 수행합니다.
카우치베이스 서버에서 TLS 설정 예시
이 섹션에서는 Linux 호스트에서 버전 7.2.0을 실행하는 3노드 카우치베이스 서버 클러스터에서 TLS 네트워크 암호화를 설정합니다. 또한 인증 기관으로 사용되는 네 번째 Linux 호스트도 있습니다.
클러스터 개인 키 + 인증서
인증 기관 호스트에 로그인하면 여기에서 클러스터 인증서를 만들 것입니다.
이 호스트는 최신 버전의 OpenSSL이 설치된 Linux 호스트입니다.
먼저 나중에 노드별 인증서에 사용할 Couchbase 템플릿 파일을 만들겠습니다.
| 명령(출력 없음) |
|
|
cat > cbserver.내선 <<EOF 기본 제약 조건=CA:FALSE subjectKeyIdentifier = 해시 권한키 식별자 = keyid,발행자:항상 확장키 사용=serverAuth keyUsage = 디지털 서명,키 인코딩 EOF |
|
다음 단계는 암호화된 클러스터 개인 키를 생성하는 것입니다. cluster_private.key.
다음 명령을 실행하면 이 키를 암호화하기 위한 암호를 입력하라는 메시지가 표시됩니다.
개인 키는 PKCS8(PKCS #8) 형식이며 매우 안전한 265비트로 암호화됩니다. 고급 암호화 표준 (AES).
| 명령 |
|
|
openssl genpkey -알고리즘 RSA -pkeyopt rsa_keygen_bits:2048 -aes256 -out 클러스터_개인.키 |
|
| 출력 |
|
|
.................................................+++++ ....+++++ 입력 PEM 통과 문구: 확인 - 입력 PEM 통과 문구: |
|
파일의 시작 부분을 확인하여 암호화된 개인 키인지 확인할 수 있습니다.
| 명령 |
|
|
| 출력 |
|
|
-----시작 암호화된 비공개 KEY----- MIIFLTBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQI7V+8dCGg42oCAggA MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBAvcj4Z3cB/j2gIudgzhRgSBIIE 0HFbApMtub0oadBYkx7RHPxd4jpILoTJ2nwqYtn79r/fCf1KwwwcWAd6vXOC0EeH 0acalU4ZfMF756CafORL7mfnB7VIw2ht5ObsUpCiYu9cIh8tHK2bipIELKMKfCT3 ljxjOn/AEZIqWy6RmwV375Ri3RONBT+czGIs4FXUA8TY/ZHlOw46yYxpxPefkRLU H9bfcg8RLqPKfeAOprisHNhmoch0MuU0gS6U0Lt+KvNDWNylIQba94q36FQIE3YW OVlHkgB2/YCx9BR/ZnWlIK6I/ZrN6Z4u/n9hFY/oYrxj4RIorvJyjeSq52XzVrPd 1bTeZob/MJomNhyeW0SYbUsRV/40N11wzx5tkSftuP8zs9MzP36qspDq56rl3W5H grKM7c9Dn+BLQbHz4158Wxaxz2CzTsn5IT5Q6BP27StrTGMYeHSAX32D+s313kPw |
|
이제 PEM x.509 형식으로 클러스터 인증서를 만들겠습니다. 이 경우 인증서는 자체 서명을 위한 것으로, 다른 기관에서 보증하지 않습니다. 즉, 기존 개인 키를 기반으로 직접 만들 수 있습니다. ca.key를 클릭합니다.
3650일(10년) 동안 유효한 클러스터 인증서를 만들면 인증서에 클러스터 공개 키가 포함됩니다. 클러스터_개인.키 를 만들었습니다. 이제 이 명령의 개인 키를 해독하려면 이전에 입력한 암호 구문을 제공해야 합니다.
| 명령 |
|
|
openssl req -new -x509 -일수 3650 -sha256 -키 클러스터_개인.키 -out 클러스터_인증.pem -subj "/CN=Couchbase Root CA" |
|
| 출력 |
|
|
이제 새 인증서 파일의 내용을 인쇄할 수 있습니다(공개 키도 볼 수 있습니다).
| 명령 |
|
|
openssl x509 -텍스트 -noout -in ./클러스터_인증.pem |
|
| 출력 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
인증서: 데이터: 버전: 3 (0x2) 시리얼 번호: 7e:a6:19:80:11:8c:b2:12:cc:86:91:bd:9b:df:f1:2f:75:ef:50:07 서명 알고리즘: sha256WithRSAEncryption 발행자: CN = 카우치베이스 루트 CA 유효성 Not 이전: 7월 26 12:26:06 2023 GMT Not 이후 : 7월 23 12:26:06 2033 GMT 제목: CN = 카우치베이스 루트 CA 제목 공개 키 정보: 공개 키 알고리즘: rsa암호화 RSA 공개-키: (2048 bit) 모듈러스: 00:a6:51:f9:d5:6f:40:06:b3:b5:5b:55:b5:a0:82: 2a:73:7a:0d:a8:02:1f:82:24:ed:c7:99:51:0a:d9: f8:09:08:0e:24:e0:34:fe:ef:0f:53:dd:27:19:af: a1:0d:78:14:03:3e:26:2e:c0:44:35:fb:c7:84:57: 광고:66:be:95:d4:53:71:8c:24:30:26:46:6e:03:b9: b9:e9:b1:a1:fa:f9:7f:bd:88:f8:03:3e:20:dc:3a: 29:dd:0d:2c:a3:0b:8e:22:46:49:ca:56:dc:b7:17: f9:87:12:d2:df:80:b8:35:df:19:4f:0d:f4:b2:9d: 02:9e:2c:59:e4:25:98:05:85:cd:e8:64:04:43:1f: 79:35:fb:ae:8b:e8:cd:16:24:68:90:9f:32:d5:d3: 5f:b0:11:82:3f:a3:7a:83:d8:e2:c5:92:a5:ef:8f: e2:4e:b2:8f:c1:27:04:92:3c:6d:50:88:82:5b:73: e8:17:7b:03:c7:f3:98:71:dd:99:ed:84:f9:37:3a: 67:79:d3:fa:6a:a4:2e:69:25:a1:2c:79:39:40:e5: 51:2c:57:02:be:c0:d6:43:7f:d5:ce:c9:cb:ee:68: a6:광고:13:17:22:d1:16:8b:08:17:ba:25:80:ce:9a: e8:a5:fc:e9:93:47:c5:a4:70:95:eb:3b:80:39:e7: 94:af 지수: 65537 (0x10001) X509v3 확장 프로그램: X509v3 제목 키 식별자: 18:D1:3E:58:0C:99:3D:6D:D4:EB:1A:D5:2F:43:69:89:8C:C0:A3:87 X509v3 권한 키 식별자: keyid:18:D1:3E:58:0C:99:3D:6D:D4:EB:1A:D5:2F:43:69:89:8C:C0:A3:87 X509v3 기본 제약 조건: 중요 CA:TRUE 서명 알고리즘: sha256WithRSAEncryption 3f:af:bb:c9:b9:89:82:78:fe:99:e6:49:fe:7b:8d:c4:67:f4: 62:ff:f7:6d:46:9f:75:17:9e:56:8c:c4:06:71:95:a1:6c:cd: d6:ae:06:dd:3f:28:ce:3b:ea:bb:1b:4b:21:26:6b:85:48:5b: 43:c8:9c:10:ac:3d:4c:e2:62:69:8d:45:9a:5d:f0:d5:14:b7: 21:9e:00:9a:53:50:22:42:c7:1f:광고:80:68:dd:f3:69:89:9d: 68:3e:37:62:69:c1:28:62:5a:08:91:98:96:49:64:8b:cc:01: 4c:7a:참조:c3:ff:참조:04:86:85:fb:2b:참조:ed:89:6c:15:ba:f7: 8f:03:cb:af:50:f7:10:35:93:3d:29:09:bf:a5:e3:0b:d2:18: a2:7b:84:db:40:8a:b7:42:82:1b:ac:c8:8c:f0:d7:4f:45:de: b8:76:80:04:66:9b:3f:ed:e9:23:d5:52:51:9a:f8:cc:광고:1a: 67:8f:a9:d7:45:3f:2a:07:89:5c:7b:fa:b5:73:f5:b0:4d:8d: d2:32:66:20:18:30:2e:d1:3e:cb:02:b3:4b:26:6e:25:20:83: f6:5b:a9:e8:fd:e2:d5:90:bc:16:65:6d:f9:de:9c:c0:e4:07: 00:cb:e9:4b:9c:b4:fa:4c:79:c3:2f:3a:e7:e8:43:75:fc:b7: 51:a5:16:ce |
|
이제 클러스터 인증서(cluster_cert.pem), 이 파일을 클러스터의 모든 Couchbase Server 노드에 복사해야 합니다. 또한 관리자의 노트북과 같이 관리자가 UI에 액세스하는 모든 호스트뿐만 아니라 SDK가 작동하는 모든 애플리케이션에도 이 파일을 추가해야 합니다. 이 파일은 민감한 파일이 아니며 공개 정보만 포함합니다.
노드 개인 키 + CSR
이 섹션의 단계는 각 카우치베이스 서버 노드에 대해 반복해야 합니다:
-
- 카우치베이스 서버 노드에 로그인합니다.
- 시스템의 다른 사용자가 액세스할 수 없는 임시 디렉터리에서 다음 명령을 실행합니다.
먼저 노드 개인 키인 node1을 PKCS1(PKCS #1) 형식으로 생성해 보겠습니다.
| 명령 |
|
|
openssl genpkey -알고리즘 RSA -pkeyopt rsa_keygen_bits:2048 -out cbnode1_private.키 |
|
| 출력 |
|
|
...................................................................................+++++ ....+++++ |
|
다음으로 Node1에 대한 CSR(인증서 서명 요청)을 생성해 보겠습니다. node1 개인 키를 입력합니다. CSR에 공개 키가 포함된다는 것을 기억하세요.
| 명령(출력 없음) |
|
|
openssl req -new -키 cbnode1_private.키 -out cbnode1.CSR -subj "/CN=Couchbase Server" |
이제 이 CSR과 내장된 공개 키를 보고 확인할 수 있습니다. |
| 명령 |
|
|
openssl req -텍스트 -noout -확인 -in ./cbnode1.CSR |
|
| 출력 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
확인 확인 인증서 요청: 데이터: 버전: 1 (0x0) 제목: CN = 카우치베이스 서버 제목 공개 키 정보: 공개 키 알고리즘: rsa암호화 RSA 공개-키: (2048 bit) 모듈러스: 00:c6:a3:bd:7e:84:eb:8b:00:47:74:61:f6:68:3f: d7:65:e8:90:7b:cd:ee:47:dd:d0:c4:26:5e:52:10: 8c:9e:55:68:dc:c7:01:06:f5:27:82:9a:40:2d:0a: 2a:a0:ef:d1:9d:ba:ee:cd:cc:1c:3b:b0:52:ab:bd: 03:98:eb:70:9c:53:02:8f:93:05:d9:79:3b:ee:광고: 86:dc:49:e2:8d:88:70:d4:80:광고:16:f2:ca:9e:20: 82:5c:52:51:7a:6b:e5:82:85:a9:d3:55:4b:61:70: 46:34:30:2c:72:8a:49:3f:a5:2e:59:37:58:49:45: ca:63:99:61:c5:14:ff:9b:83:86:45:37:95:54:46: 66:68:f3:cc:55:ac:2e:49:17:7d:f8:2f:4d:df:ea: f5:76:f5:b6:72:d6:93:광고:73:6c:64:da:6a:30:5c: 8b:c0:d8:94:df:fc:4e:e8:광고:8c:34:40:e9:87:93: 99:97:ed:3b:b5:e8:85:19:29:3c:20:d6:3a:0a:46: 6e:b4:c3:4b:ca:80:82:05:2b:59:62:6b:99:c9:93: 5f:11:f5:96:e1:1c:8c:c3:cd:3c:60:31:0b:40:fc: a6:2f:fc:40:15:71:d7:e5:c6:b0:5c:3c:4b:64:4e: 3d:b7:48:e9:59:31:6d:b3:1e:9f:07:9b:5a:bc:bb: cd:df 지수: 65537 (0x10001) 속성: a0:00 서명 알고리즘: sha256WithRSAEncryption 5d:70:22:cd:a9:1b:dc:97:d3:1f:49:e7:d5:ef:4c:c9:f8:5b: 8e:65:b3:a1:ac:b4:19:cb:ff:3a:39:bc:b8:d2:21:a9:ac:2d: b3:78:83:fa:26:8d:b3:26:20:83:12:a6:fd:93:23:dc:4f:ee: 59:2f:64:bd:03:03:51:92:28:e5:55:7d:63:a4:4a:48:80:05: 01:90:5b:ac:8d:37:d0:7a:80:a5:49:5b:63:b0:44:fd:5d:aa: fc:9e:1c:16:78:2b:79:bb:a9:a3:a4:f8:8d:02:db:27:e0:40: 95:61:fd:2f:f5:e2:67:f5:19:4c:75:77:38:28:ab:c5:70:06: c0:14:7c:82:e1:6a:cd:72:bb:f1:98:a5:79:1e:81:94:ca:3d: 74:62:ef:48:85:d6:79:c9:26:0c:39:a8:50:7a:f0:40:1c:b4: 5a:c6:2b:06:11:c8:63:7e:a8:0f:0b:0f:92:e3:35:6d:ab:44: 37:08:b8:7e:4b:4e:f0:14:12:5c:f0:b3:c3:a5:c0:bd:72:dd: 2e:43:ff:0b:7d:12:f9:46:40:87:16:06:14:00:d6:c4:1f:ae: d8:94:ff:참조:06:dc:72:20:ef:8f:5a:b2:0b:a6:참조:69:87:48: 33:ac:b3:06:a2:5b:d0:16:9f:a0:3b:1d:dc:89:2a:0b:fa:1f: fa:3c:22:ed |
|
이제 CSR 파일을 복사합니다, cbnode1.csr를 통해 CA 시스템으로 전송합니다. 여기에는 공개 정보만 포함되며 민감하지 않습니다.
노드 인증서 만들기
CA 시스템에 로그인하면 이제 CA 시스템에 위치한 클러스터의 각 Couchbase 서버 노드에 대한 CSR 파일이 있어야 합니다, cbnode1.csr, cbnode2.csr, 등
각 카우치베이스 서버 노드에 대해 템플릿 파일을 만들어야 합니다. 템플릿 파일은 앞서 만든 템플릿 파일입니다, cbserver.ext는 각 노드에 맞게 사용자 정의됩니다. 각 Couchbase 서버 노드에 대해 이 명령을 실행하여 필요에 따라 Couchbase 서버 노드의 DNS 호스트 이름과 파일 이름을 바꿉니다. 이렇게 하면 SAN(주체 대체 이름)이 Couchbase 서버 노드의 이름과 일치하도록 설정됩니다.
카우치베이스 서버에 호스트 이름을 사용하는 경우 이 명령을 실행합니다:
| 명령(출력 없음) |
|
|
cp cbserver.내선 cbnode1.내선 && echo "subjectAltName = DNS:node1.cb.acme.com" >> cbnode1.내선 |
|
또는 카우치베이스 서버에 호스트 이름 없이 IP 주소를 사용하는 경우 이 옵션을 실행하세요:
| 명령(출력 없음) |
|
|
cp cbserver.내선 cbnode1.내선 && echo "subjectAltName = IP:172.17.0.2" >> cbnode1.내선 |
이제 클러스터의 각 Couchbase Server 노드에 대한 템플릿 파일이 있어야 합니다, cbnode1.ext, cbnode2.ext, cbnode3.ext, 등... |
이제 각 카우치베이스 서버 노드에 대해 3개월 동안 유효한 인증서를 생성합니다. 인증서는 PEM x.509 형식이 될 것입니다. 각 노드에 대해 이 명령을 실행하여 파일 이름을 변경합니다. 이 명령을 실행할 때마다 암호화하는 데 사용되는 CA 암호 구문을 입력하라는 메시지가 표시됩니다. 클러스터_개인.키 이전에는
| 명령 |
|
|
openssl x509 -CA 클러스터_인증.pem -CAkey 클러스터_개인.키 -CAcreateserial -일수 90 -req -in cbnode1.CSR -out node1_cert.pem -extfile cbnode1.내선 |
|
| 출력 |
|
|
서명 확인 subject=CN = 카우치베이스 서버 얻기 CA 비공개 키 입력 통과 문구 에 대한 클러스터_개인.키: |
|
각 인증서 파일을 인증 기관에서 해당 인증서 파일이 속한 각 Couchbase 서버 노드로 복사합니다. 예를 들어, 다음을 복사합니다. node1_cert.pem 를 카우치베이스 서버 노드 1에 연결하고 node2_cert.pem 를 카우치베이스 서버 노드 2에 추가합니다.
카우치베이스 서버에 인증서를 로드합니다.
이 단계는 각 카우치베이스 서버 노드에서 수행해야 합니다.
카우치베이스 서버 노드에 로그인하면 3개의 파일이 있는 폴더가 있어야 합니다.
-
- 클러스터 인증서, cluster_cert.pem
- 노드의 (공개) 인증서, node1_cert.pem
- 노드의 개인 키, cbnode1_private.key
이전에 생성한 CSR 파일은 더 이상 필요하지 않습니다.
이제 Couchbase Server의 올바른 명명 규칙을 사용하여 파일을 올바른 위치로 이동해야 합니다. 각 Couchbase Server 노드에서 동일한 대상 파일 이름이 사용되지만 각 노드에는 chain.pem 그리고 pkey.key.
| 명령 |
|
|
mkdir /opt/카우치베이스/var/lib/카우치베이스/받은 편지함 mkdir /opt/카우치베이스/var/lib/카우치베이스/받은 편지함/CA mv 클러스터_인증.pem /opt/카우치베이스/var/lib/카우치베이스/받은 편지함/CA/ca.pem mv node1_cert.pem /opt/카우치베이스/var/lib/카우치베이스/받은 편지함/체인.pem mv cbnode1_private.키 /opt/카우치베이스/var/lib/카우치베이스/받은 편지함/pkey.키 chown 카우치베이스:카우치베이스 /opt/카우치베이스/var/lib/카우치베이스/받은 편지함/pkey.키 |
|
이제 모든 올바른 파일을 Couchbase Server 구성으로 가져올 준비가 되었습니다.
클러스터 인증서를 로드하여 시작하세요:
| 명령 |
|
|
curl -X POST https://localhost:8091/node/controller/loadTrustedCAs -u Administrator:password |
|
| 출력 |
|
|
[{"id":1,"loadTimestamp":"2023-07-26T15:51:33.000Z","subject":"CN=카우치베이스 루트 CA","notBefore":"2023-07-26T12:26:06.000Z","notAfter":"2033-07-23T12:26:06.000Z","type":"업로드됨","pem":"-----begin certificate-----\nMIIDGTCCAgGgAwIBAgIUfqYZgBGMshLMhpG9m9/xL3XvUAcwDQYJKoZIhvcNAQEL\nBQAwHDEaMBgGA1UEAwwRQ291Y2hiYXNlIFJvb3QgQ0EwHhcNMjMwNzI2MTIyNjA2\nWhcNMzMwNzIzMTIyNjA2WjAcMRowGAYDVQQDDBFDb3VjaGJhc2UgUm9vdCBDQTCC\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKZR+dVvQAaztVtVtaCCKnN6\nDagCH4Ik7ceZUQrZ+AkIDiTgNP7vD1PdJxmvoQ14FAM+Ji7ARDX7x4RXrWa+ldRT\ncYwkMCZGbgO5uemxofr5f72I+AM+INw6Kd0NLKMLjiJGScpW3LcX+YcS0t+AuDXf\nGU8N9LKdAp4sWeQlmAWFzehkBEMfeTX7rovozRYkaJCfMtXTX7ARgj+jeoPY4sWS\npe+P4k6yj8EnBJI8bVCIgltz6Bd7A8fzmHHdme2E+Tc6Z3nT+mqkLmkloSx5OUDl\nUSxXAr7A1kN/1c7Jy+5opq0TFyLRFosIF7olgM6a6KX86ZNHxaRwles7gDnnlK8C\nAwEAAaNTMFEwHQYDVR0OBBYEFBjRPlgMmT1t1Osa1S9DaYmMwKOHMB8GA1UdIwQY\nMBaAFBjRPlgMmT1t1Osa1S9DaYmMwKOHMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZI\nhvcNAQELBQADggEBAD+vu8m5iYJ4/pnmSf57jcRn9GL/921Gn3UXnlaMxAZxlaFs\nzdauBt0/KM476rsbSyEma4VIW0PInBCsPUziYmmNRZpd8NUUtyGeAJpTUCJCxx+t\ngGjd82mJnWg+N2JpwShiWgiRmJZJZIvMAUx6z8P/zwSGhfsrz+2JbBW6948Dy69Q\n9xA1kz0pCb+l4wvSGKJ7hNtAirdCghusyIzw109F3rh2gARmmz/t6SPVUlGa+Myt\nGmePqddFPyoHiVx7+rVz9bBNjdIyZiAY----END CERTIFICATE-----\n\n","loadHost":"127.0.0.1","loadFile":"/opt/카우치베이스/va |
|
다음으로 노드 인증서와 개인 키를 로드하고 경고가 인쇄되지 않는지 확인합니다:
| 명령 |
|
|
curl -X POST https://localhost:8091/node/controller/reloadCertificate -u 관리자:비밀번호 |
|
| 출력 |
|
|
이제 카우치베이스 서버 클러스터에 TLS 연결을 사용할 수 있습니다.
클러스터 인증서 신뢰하기
관리자 노트북
관리자의 노트북에 로그인합니다. 이 경우에는 Mac을 사용하지만 Windows 및 Linux 컴퓨터에서도 비슷한 단계를 수행할 수 있습니다.
| MacOS의 명령(출력 없음) |
|
|
sudo 보안 추가-신뢰-cert -d -r trustRoot -k "/도서관/키체인/시스템.키체인" "/tmp/cluster_cert.pem" |
|
애플리케이션 SDK
이 예에서는 Java 애플리케이션을 사용하여 Couchbase Server에 연결하며, 애플리케이션이 클러스터 인증서를 가리키도록 하겠습니다. 또 다른 옵션은 SDK에서 정의된 모든 CA를 자동으로 신뢰하므로 JVM의 cacerts 신뢰 저장소를 사용하는 것입니다. 각 프로그래밍 언어에는 CA 인증서를 신뢰하는 데 선호하는 고유한 방법이 있습니다.
|
|
문자열 연결 문자열 = "couchbases://example.com" + "?security.trustCertificate=/path/to/cluster_cert.pem"; 클러스터 클러스터 = 클러스터.연결(연결 문자열, 사용자 이름, 비밀번호); |
관리자 노트북에서 노드의 호스트 이름 중 하나에 대한 기본 암호화된 UI 주소를 로드합니다. 경고 없이 로드됩니다: https://node1.cb.acme.com:18091/
마찬가지로 애플리케이션에서 데이터베이스로 TLS 암호화된 연결을 만들 수 있습니다.
90일 만료 전에 다음 단계를 다시 수행하여 새 노드별 키/인증서를 생성하고 배포하는 것을 잊지 마세요.
고급 TLS 주제
지금까지 제공된 단계는 대부분의 애플리케이션에 적합하지만, 더 복잡한 요구 사항을 충족하기 위해 Couchbase Server에서 제공하는 몇 가지 추가 기능이 있습니다. 이러한 기능은 다음 블로그에서 다룹니다. 암호화된 개인 키 및 Multi-CA, Couchbase Server 7.1의 엔터프라이즈 보안 강화 기능
카우치베이스 서버의 여러 인증 기관
단일 인증서를 클러스터 인증서로 포함하는 대신(cluster_cert.pem / ca.pem)를 사용하면 여러 인증서를 파일에 함께 연결할 수 있습니다. 이 옵션은 인증 기관을 중복하거나 다운타임 없이 한 인증 기관에서 다른 인증 기관으로 마이그레이션을 수행할 수 있는 좋은 옵션입니다.
암호화된 노드 개인 키
클러스터 개인 키에서 수행한 것과 마찬가지로 개인 키(pkey.key) 또한 선택적으로 암호로 암호화하여 올바른 권한이 있는 사람과 시스템만 읽을 수 있도록 할 수 있습니다.
결론
TLS 인증서와 적절한 구성은 Couchbase Server에서 보안 통신을 구축하는 데 기본이 됩니다. 클러스터 인증서의 역할, 노드 인증서의 중요성, CA(인증 기관)의 관여를 이해하면 관리자는 강력한 보안 조치를 구현할 수 있습니다. 또한 SAN(주체 대체 이름)을 숙지하면 여러 도메인 또는 하위 도메인에서 인증서를 배포할 때 유연성이 향상됩니다. 이 가이드에 제시된 지침을 따르면 관리자는 Couchbase 배포의 보안을 강화하고 무단 액세스로부터 중요한 데이터를 보호할 수 있습니다.
이 시리즈를 따라가 주셔서 감사드리며, 가이드 투어가 즐거우셨기를 바랍니다.
