TLS, 네트워크 진입, SQL 권한은 서로 다른 질문에 답한다
연결을 암호화하고, 출처를 허용하고, 테이블을 부여하는 것은 세 가지 결정이다. TLS가 VPN을 대체할 수 있는지 묻기 전에 이 순서로 검토하라.
누군가는 고객에게 PostgreSQL 로그인을 주면 경비 청구가 처음부터 끝까지 암호화되어 흐른다고 제안한다. 데이터베이스 관리자는 진짜 SQL 세션이 필요하고, 다른 누군가는 대신 웹 폼을 제안한다. 두 제안 모두 고객이 실제로 수행하는 작업에서 시작하지 않았기 때문에 잘못된 문제를 푼다. 세 가지 결정을 순서대로 짚으면 TLS가 VPN을 대체할 수 있는지라는 질문은 스스로 답이 나온다.
고객에게 필요한 작업에서 시작하라
고객이 무엇을 이루어야 하는지 적어라. 청구를 제출하고, 보고서의 한 행을 읽고, 즉석 질의를 실행하는 것은 위험 프로필이 서로 다른 세 가지 작업이다.
그다음 누가 요청하는지 적어라. 고객, 지원 담당자, 관리자는 같은 테이블을 다루더라도 서로 대체할 수 없다. 그 차이가 고객이 질의 언어를 어디까지 보아야 하는지를 결정한다.
두 답의 조합이 인터페이스를 결정한다. 그 뒤의 모든 것은 구현이며, 암호화에 관한 논쟁의 대부분은 사실 어떤 인터페이스를 골랐는지에 관한 논쟁이다.
세 가지 통제, 세 가지 결정
인증된 TLS는 연결을 보호하고 어떤 TLS 신원을 받아들일지 결정한다. 네트워크 진입은 어떤 출처가 리스너에 닿을 수 있는지 결정한다. 데이터베이스 권한 부여는 역할이 어떤 객체와 동작을 쓸 수 있는지 결정한다.
셋 중 어느 것도 다른 것을 대체하지 않으며, 표가 이를 분명히 보여 준다.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
다른 행을 지우기 전에 의존하는 행을 읽어라. 이런 설계 대부분은 통제를 구성하지 않고 가정했기 때문에 실패한다.
직접 SQL은 데이터베이스 정책을 책임자로 둔다
승인된 직접 연결에서는 서비스 신원 검증과 의도한 접근 정책을 모두 유지하라. TLS를 켜면 암호화된 연결이 가능해질 뿐이며, 접근 구성이 hostssl 항목으로 요구하지 않는 한 암호화되지 않은 연결을 거부하지 않는다.
그 차이는 템플릿이 아니라 실행 중인 구성에서 확인할 가치가 있다. TLS를 제공하고 평문도 받아들이는 서버는 대부분이 배포했다고 생각하는 설계가 아니다. 접근 규칙을 읽고 어떤 항목이 실제로 그것을 요구하는지 보라. 그 한 번의 확인이 암호화 가능한 서버와 암호화 전용 서버를 가른다.
업무에 필요한 권한만 가진 역할을 쓰고, 소유권과 상속된 멤버십, 넓게 부여된 권한을 검토하라. PostgreSQL 권한 모델이 데이터베이스 객체에 대한 권한의 경계다.
VPN은 데이터베이스 인증이 일어나기 전에 어떤 기기가 서비스에 닿을지 제한할 수 있고, 접근 게이트웨이도 비슷한 일을 할 수 있다. 둘 다 노출된 구성 요소를 유지하고 자격 증명을 관리하고 자원 사용을 제한해야 할 필요를 없애지 않는다.
클라이언트 인증서는 자격 증명이지 ACL이 아니다
클라이언트 인증서는 연결 시점에 요구 사항을 더할 수 있다. clientcert 설정은 신뢰된 인증서를 요구할 수 있고, 더 엄격한 모드에서는 인증서 이름과 데이터베이스 사용자 사이의 관계를 요구할 수 있다.
그것은 더 강한 자격 증명이다. 연결을 받아들이는 구성 요소가 여전히 네트워크 트래픽과 핸드셰이크를 처리하기 때문에 권한 부여 목록이 아니며 서버를 보이지 않게 만들지도 않는다. 인증서를 접근 목록으로 다루어도 실제 권한은 그대로 남는다. 또한 인증서 배포를 넓히는 경향이 있으며, 그것이 다음 문제를 만든다.
과도한 권한의 역할에 붙은 강한 인증서는 잘 인증된 관리자를 만든다. 인증서를 축하하기 전에 역할을 확인하라.
맞을 때는 더 좁은 인터페이스를 골라라
경비 청구에서는 청구를 받아들이고 업무 규칙을 적용하며 그 사용자에게 허용된 결과를 돌려주는 애플리케이션 엔드포인트가 일반 SQL 계정보다 그 작업을 더 잘 표현한다.
그다음 애플리케이션은 자체적으로 제한된 데이터베이스 신원을 쓰고, 고객은 질의 언어를 기능으로 받지 않는다. 더 작은 표면이며 틀릴 방법도 적다.
이것은 설계 선택이지 애플리케이션 코드가 자동으로 더 안전하다는 주장이 아니다. 그 코드는 호출자를 인증하고 각 동작을 권한 부여하고 입력을 검증해야 하며, 자체 데이터베이스 권한도 여전히 중요하다.
직접 SQL은 승인된 업무가 그것을 요구하는 사람과 도구에게 여전히 옳다. 그 설계는 역할과 네트워크 범위와 운영 한계로 조건을 붙이고, 다른 고객에게는 더 좁은 인터페이스를 유지하게 하라. 두 집단을 한 역할에 섞는 것이 논쟁이 시작되는 지점이다.