Firebird 3의 와이어 암호화와 VPN은 서로 다른 두 경계

VPN이 연결되고 클라이언트가 세션을 열면 모두가 데이터베이스 연결이 보호된다고 가정합니다. 방금 서로 다른 세 가지가 뒤섞였습니다. 리스너에 애초에 도달할 수 있는지, 서버가 사용자를 받아들였는지, Firebird가 와이어 암호화를 협상했는지는 각각 별개의 메커니즘이고 증거도 별개입니다. 터널은 첫 번째에만 답하며 그것도 허용한 소스에 대해서만 답합니다.

두 경계는 겹치지 않습니다

VPN 경계는 클라이언트와 게이트웨이 사이의 패킷을 보호합니다. Firebird의 와이어 암호화는 클라이언트 라이브러리와 서버 프로세스 사이의 데이터베이스 프로토콜을 보호합니다. 둘 다 존재할 수 있으며 어느 것도 다른 하나를 대신하지 않습니다.

터널이 데이터베이스 호스트 앞에서 끝난다면 그 너머의 트래픽은 데이터베이스 세션이 협상한 것만으로 보호됩니다. 검토가 보통 뜻밖의 문제를 발견하는 곳이 바로 이 틈입니다. 터널 다이어그램은 게이트웨이에서 끝나고, 쿼리를 나르는 연결은 그 너머로 계속됩니다. 나중에 그 다이어그램을 읽는 사람은 이 가정을 물려받습니다.

첫 번째 경계: 누가 리스너를 열 수 있는가

실제 서버 주소와 구성된 포트(변경되지 않았다면 3050)를 확인한 다음 호스트와 네트워크 방화벽에서 승인된 VPN 소스만 허용하세요. VPN 게이트웨이에서의 주소 변환도 고려하고, 게이트웨이가 별도라면 데이터베이스 호스트에 클라이언트 풀 쪽으로 돌아가는 경로를 주세요.

그다음 부정을 증명하세요. 거부되어야 할 외부 경로는 터널을 여는 것만으로는 Firebird 리스너가 제한되지 않으므로 계속 거부되어야 합니다.

두 번째 경계: Firebird가 협상하는 것

Firebird 3은 비활성화, 활성화, 필수로 설정할 수 있는 서버 정책과 함께 와이어 암호화 프레임워크를 도입했습니다. 정책이 하한을 정합니다. 실제 세션은 여전히 애플리케이션이 로드하는 클라이언트 라이브러리와 양쪽이 지원하는 플러그인에 달려 있습니다.

Firebird 3 릴리스 노트에서는 Arc4를 해당 릴리스의 기본 와이어 암호화 플러그인으로 나열합니다. Arc4는 역사적인 기본값이며 현대 암호에 대한 권장이 아니고, 바깥쪽 VPN 보호와 같은 것이 아닙니다.

인증은 같은 협상에서 세 번째 변수입니다. 서버는 인증 플러그인 집합을 받아들이고, 클라이언트 라이브러리는 그 일부를 제시하며, 둘은 겹쳐야 합니다.

Legacy_Auth의 함정

Legacy_Auth를 지원하려면 서버의 기본 필수 암호화 정책을 완화해야 합니다. 그것이 문서화된 호환성 비용이며, 연결 오류를 잠재우려고 정책을 낮추는 것은 수정이 아니라 보안 변경인 이유입니다.

서버 업그레이드 후 클라이언트가 갑자기 실패하면 무엇이든 약화시키기 전에 플러그인 목록을 비교하세요. 실패는 보통 협상 불일치이며, 답은 양쪽에서 지원되는 플러그인입니다.

중요한 연결을 확인하세요

컨텍스트 변수를 제공하는 빌드에서는 이 쿼리가 현재 연결의 암호화 상태를 보고합니다:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

같은 서버의 관리자 세션이 아니라 애플리케이션 자체의 연결로 실행하세요. 암호화된 관리자 연결은 다른 클라이언트 라이브러리의 세션에 대해 아무것도 말해 주지 않으며, 그 변수를 지원하지 않는 오래된 빌드는 암호화가 꺼져 있다는 증거가 아닙니다.

어느 하나만으로는 읽을 수 없으므로 클라이언트 라이브러리 버전, 서버 빌드, 결과를 함께 기록하세요.

권한과 업그레이드 경로

소스를 제한하고 전송을 암호화하는 것은 인증이나 최소 권한 부여를 대신하지 않습니다. 일반 데이터베이스 사용자가 실제로 건드리는 객체에 대한 권한을 확인하세요.

마지막으로 오래 쓰는 배포를 유지 보수 문제로 다루세요. 터널은 낡은 클라이언트 라이브러리를 무기한 안전하게 만들지 않으며, 지원되는 업그레이드 경로가 필요한 플러그인이 제거되었다는 사실을 나중에 발견하는 것보다 쌉니다.