VPN을 통한 Cassandra: 클라이언트와 노드에 별도 접근 권한 부여

Cassandra 배포에는 하나의 보편적인 데이터베이스 네트워크가 없습니다. 애플리케이션은 클라이언트 서비스와 대화하고, 클러스터 구성원은 서로 대화하며, 운영자는 관리 인터페이스를 사용합니다. 이 세 이용자는 서로의 도달 범위를 물려받아서는 안 됩니다. VPN 같은 전용 경로는 좋은 출발점이지만, 그것은 데이터베이스의 사용자 신원이 아니며 암호화 정책도 아닙니다. 연결성 결정과 권한 부여 결정을 두 개의 별도 검토로 다루십시오.

세 이용자는 각기 다른 답을 가지며, 아래 절들은 노출 순서대로 그것들을 다룹니다.

세 이용자, 세 가지 결정

규칙을 건드리기 전에 각 그룹에 실제로 무엇이 필요한지 파악하십시오. 클라이언트에는 클라이언트 리스너와, 배정받을 수 있는 모든 노드에 도달할 만큼의 정보가 필요합니다. 피어 노드에는 노드 간 포트에서 서로가 필요합니다. 운영자에게는 런북이 실제로 요구하는 일을 위한 관리 인터페이스가 필요합니다. 세 개의 목록, 세 이용자, 세 단계의 신뢰입니다.

흔한 실수는 하나의 평평한 전용 세그먼트를 만들고 VPN 경계가 나머지를 해 주리라 가정하는 것입니다. 그 안에서는 클라이언트 포트에 닿는 애플리케이션이 대개 노드 간 포트에도 닿고, 운영자의 관리 도구는 애플리케이션과 같은 점프 호스트에 앉아 있는 경우가 많습니다. 이것들을 한데 평평하게 만들면 침해된 애플리케이션 신원이 이미 자기 쿼리보다 넓은 도달 범위를 갖게 됩니다. 설계 문서에 세 이용자를 세 개의 행으로 그리고 각 행에 그것을 허용하는 규칙을 적으면, 누군가 그것을 만들기 전에 빈틈이 보이게 됩니다.

클라이언트에 필요한 것, 그 이상은 아님

배포된 버전에 대해 의도된 애플리케이션 소스만 클라이언트 엔드포인트에 닿도록 허용하고, 무관한 클러스터 및 관리 서비스는 그 도달 범위 밖에 두십시오. 그다음 드라이버가 노드를 어떻게 찾는지 확인하십시오. 닿을 수 있는 최초 접점은 그 뒤에 드라이버가 고르는 모든 노드 주소가 그 클라이언트 맥락에서 닿을 수 있음을 보장하지 않습니다. 드라이버는 클러스터에 피어를 묻고 나서 클러스터가 광고하는 주소로 접속하기 때문입니다.

그래서 전용 주소의 불일치 하나가 익숙한 양상을 만듭니다. 처음 연결은 성공하고 그 뒤로 시간 초과가 이어지는 것입니다. 광고하는 주소와 클라이언트 경로를 의도적으로 설정하십시오. 불일치 하나를 고치려고 클러스터 전체를 인터넷에 공개하는 것은 경로 버그를 되돌릴 수 없는 노출과 맞바꾸는 일입니다.

애플리케이션의 데이터베이스 인증과 역할 권한도 그대로 두십시오. 공유된 변환 VPN 주소는 많은 사용자나 서비스를 대표할 수 있으므로, 서로 다른 데이터베이스 신원을 대신하지는 못합니다.

클라이언트 대 노드와 노드 간 암호화를 따로 하십시오

Apache의 보안 문서 는 클라이언트 대 노드와 노드 간 암호화를 별개 설정으로 다루며, 하나를 켠다고 다른 하나가 켜지지 않습니다. 그 구분은 VPN 안에서도 적용됩니다. 터널은 자기 세그먼트를 보호할 뿐, 애플리케이션 프로세스에서 데이터베이스 프로세스로, 또는 클러스터 구성원의 모든 쌍 사이로 자동으로 확장되지 않기 때문입니다.

템플릿 기본값을 물려받는 대신 둘 다 명시적으로 켜는 설정은 대략 다음과 같습니다.

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

클라이언트 암호화를 선택적으로 허용하는 서버 설정에서는 TLS 수용이 암호화되지 않은 연결 수용과 공존할 수 있으므로, 의도가 아니라 실제 적용되는 정책을 읽으십시오. 인증서 이름, 신뢰 배포, 갱신을 각 클라이언트가 실제로 접속하는 엔드포인트에 맞춰 계획하십시오. 호스트 이름을 IP 주소로 바꾸면 경로만이 아니라 클라이언트의 신원 확인도 달라집니다.

관리는 전용 경로에 두십시오

노드 간 트래픽에는 허용된 피어 집합과 자체 보호 정책이 필요합니다. 사용되는 곳에서 JMX를 포함한 관리 접근에는 별도 이용자와 자체 인증이 필요합니다. 일반 쿼리를 내보낼 수 있는 애플리케이션이 그렇다고 모든 관리 기능을 필요로 하지는 않으며, 반대의 경우가 더 나쁩니다. 애플리케이션 세그먼트에 열린 관리 경로는 버그에서 재구축으로 가는 가장 짧은 길입니다. 이 두 이용자를 따로 적고 각각의 소유자를 지명하십시오. 대개는 규칙이 우연히 합쳐진 서로 다른 팀이기 때문입니다.

실제 적용되는 클라우드 규칙, 호스트 규칙, 리스너 설정을 서로 맞추십시오. 전용 리스너도 의도치 않은 변환이나 프록시를 통해 열려 있을 수 있고, 넓은 공개 규칙이 좁은 VPN 규칙 옆에 조용히 자리할 수 있습니다. 누군가 둘을 한꺼번에 점검하기 전까지는요.

운영자에게 정말 관리 경로가 필요하다면, 이름이 붙은 소유자와 애플리케이션보다 짧은 자격 증명 수명을 주십시오. 그래야 다음 사람이 클러스터를 물려받을 때 위임이 보이게 됩니다.

설계가 약속하는 것

세 가지 약속을 연결 테스트만이 아니라 실제 역할로 검증하십시오. 승인된 애플리케이션은 허용된 작업만 마쳐야 하고, 제외된 소스는 클라이언트 입구에서 실패해야 하며, 애플리케이션 신원은 예약된 관리 경로에서 거부되어야 합니다. 클라이언트 재연결과 노드 선택도 같은 배포 테스트에 넣으십시오. 발견의 실수는 바로 거기서 드러납니다.

설계 문서에서 세 문장으로 마무리하십시오. 어떤 클라이언트가 질의할 수 있는지, 어떤 노드가 통신할 수 있는지, 어떤 운영자가 관리할 수 있는지. VPN 뒤에 있다는 것은 유용한 토폴로지 정보이지만, 그 세 질문 중 어느 것의 답도 아닙니다.