PostgreSQL 행 수준 보안을 설정하여 각 사용자가 자신의 데이터만 볼 수 있도록 합니다(Supabase 포함).

사용자 계정, 유료 플랜 또는 여러 팀이 하나의 데이터베이스에 있는 모든 앱은 누가 어떤 행을 볼 수 있는지 결정해야 합니다. 해당 규칙이 앱 코드에만 존재하면 다른 방법으로 데이터에 접근하는 순간 실패합니다. 누군가 보호하는 것을 잊은 새 엔드포인트, 동일한 데이터베이스의 두 번째 앱 또는 Supabase가 테이블에 대해 생성하는 API와 같은 경우입니다. 행 수준 보안은 데이터가 있는 곳에 규칙을 배치합니다.

저는 NDA에 따라 구독 제품에 이 작업을 수행했습니다. 테이블에 대한 행 수준 보안 정책과 각 구독 계층에 대한 별도의 데이터베이스 역할을 사용하여 플랜에 포함된 내용이 누군가 잊을 수 있는 확인이 아니라 PostgreSQL에 의해 강제 적용되도록 했습니다.

Starter에서는 최대 5개 테이블이 가지고 있거나 부족한 정책을 검토하고, 각 간격을 보여주는 예시 쿼리와 함께 서면 목록을 보냅니다. Standard는 최대 10개 테이블에 대한 정책을 작성하거나 수정하고, 앱에 필요한 역할을 설정하고, 마이그레이션 파일로 제공하며, 사용자 A가 사용자 B의 행을 읽고 변경하려고 시도했지만 실패하는 테스트를 추가합니다. Advanced는 최대 25개 테이블을 다루고, 데이터베이스에서 강제 적용되는 플랜 또는 계층 제한을 추가하며, CI에서 테스트를 실행합니다.

Supabase에서는 auth.uid() 및 정책 내에서 사용되는 JWT 클레임과 동일한 PostgreSQL 기능이 적용됩니다. 일반 PostgreSQL에서는 정책이 백엔드가 각 요청에 대해 설정하는 세션 설정에서 현재 사용자를 읽습니다.

통화는 없습니다. 모든 패키지는 누가 무엇을 볼 수 있는지에 대한 일반 언어 메모로 끝납니다. Standard 및 Advanced에서는 정책도 테스트와 함께 리포지토리에 마이그레이션으로 제공됩니다. 배송 후 14일 동안 합의한 대로 작동하지 않는 모든 것을 무료로 수정해 드립니다.

프로젝트 완료 단계
1. 데이터 매핑 - 테이블, 각 행의 소유자, 누가 읽거나 변경해야 하는지(소유자, 팀원, 관리자, 각 플랜)를 나열합니다.
2. 기존 내용 검토 - 현재 정책, 권한 및 역할이 해당 맵과 비교되고, 모든 간격은 이를 보여주는 쿼리와 함께 기록됩니다.
3. 정책 및 역할 - 정책은 테이블별, 작업별로 작성되며, 플랜 또는 팀에 대한 역할과 함께 검토할 수 있는 마이그레이션 파일로 제공됩니다.
4. 증명 - 테스트는 다른 사용자로 로그인하여 서로의 데이터를 읽고 변경하려고 시도합니다. 모든 금지된 작업은 실패해야 하며, 모든 허용된 작업은 작동해야 합니다.
5. 인계 - 누가 무엇을 볼 수 있는지, 마이그레이션, 새 테이블이 나타날 때 정책을 추가하는 방법에 대한 간략한 일반 언어 메모.