VPN을 통한 MySQL: 암호화만이 아니라 서버를 검증하세요

잘못된 호스트로의 암호화도 잘못입니다. ssl-mode 값을 비교한 다음, 의도한 서버를 지목하고 이를 증명하는 연결을 실행하세요.

연결 대상을 10.20.4.15 로 저장했는데 VPN이 끊겨도 클라이언트는 계속 연결됩니다. 좋은 소식이 아닙니다. 사설 주소는 자신이 처한 라우팅 컨텍스트 안의 한 위치일 뿐이며, 많은 네트워크가 같은 대역을 사용합니다. 클라이언트는 MySQL 서버에 도달했지만, 아마 당신의 서버는 아닐 것입니다.

해결책은 두 부분이며, 네트워크에 관한 것은 그중 하나뿐입니다. 연결을 의도한 경로에 유지하고, 클라이언트가 대화 상대 서버를 인증하도록 하세요. 첫 부분은 VPN이 도움이 되는 곳이고, 두 번째 부분은 구성해야 합니다.

정확히 무엇에 대해 암호화되었나요?

TLS는 대화를 중간의 누구로부터도 보호하지만, 클라이언트가 확인하지 않는 한 엔드포인트가 자신이 누구라고 주장하는지에 대해서는 아무것도 말하지 않습니다. 신뢰할 수 있는 기관에 대해 검증되는 인증서는 그 인증서가 해당 기관에서 발급되었음을 증명합니다. 도달하려던 호스트 이름으로 발급되었음을 증명하지는 않으며, 이는 다른 질문입니다.

이것은 이론적 틈이 아닙니다. 캡티브 포털, 잘못된 VRF 오류, 겹치는 주소 계획은 모두 당신과 TLS 협상을 기꺼이 할 서버를 만들어냅니다. 클라이언트가 암호화만 요구한다면 세션은 사적이지만 잘못된 데이터베이스를 향합니다.

따라서 관련 질문은 연결이 암호화되었는지가 아니라, 의도한 정체성으로 암호화되었는지입니다. MySQL 클라이언트에서 그 구분은 전적으로 ssl-mode 설정에 있습니다.

실무에서의 다섯 가지 ssl-mode 값

다섯 가지 값이 있으며, 이 안내서의 질문에 답하는 것은 그중 하나뿐입니다. 표는 이름이 암시하는 것이 아니라 각 값이 실제로 무엇을 보장하는지 나열합니다.

ModeWhat it guarantees
DISABLEDNo TLS at all; everything on the wire is readable
PREFERREDTries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement
REQUIREDRefuses to connect without TLS, and does not validate the certificate
VERIFY_CAValidates the server certificate against the configured CA and does not check the hostname
VERIFY_IDENTITYValidates the CA and checks that the certificate names the host the client used

이 글의 질문에 답하는 것은 마지막 행뿐입니다. PREFERRED 는 그 자체로 주목할 만합니다. 조용히 평문으로 떨어지는 클라이언트는 거부하는 클라이언트보다 나쁘고, 암호화가 있다고 믿는데 패킷 캡처는 그렇지 않다고 말합니다.

오늘 실행할 수 있는 연결

아래 명령이 사용해야 할 형태이며, 두 개의 자리 표시자가 있습니다. 승인된 데이터베이스 이름과 승인된 채널로 얻은 CA 파일입니다. 둘 다 서버가 첫 접촉에서 제안하는 것에서 가져와서는 안 됩니다.

mysql --host=db.corp.example --user=app_reader \
  --ssl-mode=VERIFY_IDENTITY \
  --ssl-ca=/approved/path/ca.pem --password

--password 값이 없으면 입력을 요청하므로, 비밀이 프로세스 목록과 셸 기록 밖에 남습니다. 공유 점프 호스트에서는 명령줄이 다른 사용자에게 보이기 때문에, 이는 작은 습관이지만 큰 효과가 있습니다.

이것이 실패할 때, 오류 텍스트는 직관보다 사례를 더 잘 구분합니다. CA 실패는 체인이 검증되지 않음을 의미하며 서버 인증서에 서명한 CA가 무엇인지 봐야 합니다. 호스트 이름 실패는 체인이 정상이고 이름이 일치하지 않음을 의미하며, 보통 잘못된 서버가 아니라 올바른 서버에 잘못된 이름으로 연결했다는 뜻입니다.

프롬프트가 나타난 것이 비밀번호가 이미 전송되었다는 증거는 아니며, 실패한 연결이 클라이언트에서 아무것도 나가지 않았다는 것을 증명하지도 않습니다. 과거 사건을 재구성한다면 클라이언트, 그 구성, 인증 플러그인, 실패한 단계를 식별하세요. 마지막 오류 메시지에서 노출을 추정하는 것은 추측입니다.

이름이 터널에서 올 때

로컬 포트 포워딩은 사람들을 놀라게 하는 방식으로 신원 확인을 깨뜨립니다. 로컬 포트를 데이터베이스로 포워딩하고 localhost 에 연결하면, 클라이언트는 인증서를 localhost 에 대해 검증하지만 그 이름으로 발급된 인증서는 없습니다. 연결은 완전히 안전할 수 있고 검증은 여전히 실패할 것입니다. 이는 검증이 의도대로 작동하는 것입니다.

정직한 답은 두 가지입니다. 포워딩된 엔드포인트에 루프백 주소로 해석되고 서버 인증서에 나타나는 이름을 주거나, 호스트 이름을 끝에서 끝까지 사용해 클라이언트가 실제 정체성을 검증하게 하세요. 전자는 개발자에게 편리하고 인증서 작업이 필요합니다. 후자는 생각하기 쉽고 자동화에 종종 올바른 기본값입니다. 포워딩을 작동시키기 위해 검증을 끄는 것은 추가하려던 속성을 버리는 것입니다.

수용은 세 가지 조건

수용 테스트를 세 개의 별도 진술로 작성하세요. 연결이 의도한 경로를 사용했고, 암호화가 선호가 아니라 요구되었고, 서버 정체성이 신뢰할 수 있는 자료에 대해 검증되었습니다. 초록색 VPN 아이콘은 그중 어느 것도 확립하지 않습니다.

GUI 클라이언트와 MariaDB의 경우, 플래그 철자가 그대로 이어진다고 가정하지 말고 공급업체 자체 문서를 확인하세요. MySQL 암호화 연결 문서 는 모드 간 차이와 CA 배포 요구 사항을 다루며, 프로덕션 연결 문자열을 변경하기 전에 확인해야 할 참조입니다.

관련 글