Supabase RLS: 수동 감사와 자동 스캔 비교

행 수준 보안은 데이터를 보호하는 Supabase 프로젝트와 조용히 공개하는 프로젝트 사이의 경계선입니다. RLS가 제대로 구성되면 데이터베이스는 RLS가 적용되는 역할에 대해 행 수준에서 액세스 규칙을 적용합니다. 서비스 역할을 포함한 권한 있는 역할은 이러한 규칙을 우회할 수 있습니다. 잘못 구성되면 정책이 의도한 것보다 더 많은 것을 허용하는 동안 테이블은 보호된 것처럼 보입니다.

이 문서에서는 Supabase RLS 보안 검사를 실행하는 두 가지 방법, 즉 직접 정책을 확인하는 방법과 자동화된 RLS 감사를 실행하는 방법을 비교합니다. 둘 다 자리가 있어요. 각각의 문제가 발생하는 위치를 아는 것이 데이터베이스 액세스 정책이 의도한 대로 작동하는지 확인하는 방법입니다.

RLS는 Supabase가 테이블별로 노출하는 Postgres 기능입니다. 활성화되면 정책에서 허용하지 않는 한 테이블은 RLS가 적용되는 역할에 대한 행 액세스를 거부합니다. 우회 권한이 있는 테이블 소유자 및 역할은 예외입니다. 정책은 현재 사용자, 해당 클레임 및 실행 중인 쿼리를 기준으로 평가됩니다. 는 auth.uid() 함수는 일반적으로 앵커입니다. 다음과 같은 정책은 using (auth.uid() = user_id) 로그인한 사용자 자신의 데이터베이스 행에 대한 액세스를 제한합니다.

모델이 깨끗해요. 실패는 실패처럼 보이지 않기 때문에 실패는 그렇지 않습니다.

대부분의 RLS 문제는 몇 가지 패턴으로 설명됩니다.

• RLS는 전체가 아닌 일부 테이블에서만 활성화됩니다. 출시 후 추가된 새 테이블 또는 마이그레이션을 통해 생성된 테이블은 RLS가 꺼진 상태로 배송될 수 있습니다. 그러면 테이블 액세스 권한이 있는 모든 역할이 모든 행을 읽을 수 있습니다.

• 읽는 것보다 더 광범위한 정책입니다. using (true) 선택 정책은 모든 행이 표시됨을 의미합니다. 디버깅을 위해 개발 중에 추가하고 제거하는 것을 잊어버리기 쉽습니다.

• 서비스 역할은 모든 곳에서 가정됩니다. 서비스 역할 키를 사용하는 서버 측 코드는 RLS를 완전히 우회합니다. 사용자 대상 요청이 해당 키를 통해 실행되는 경우 정책이 적용되지 않습니다.

• 잘못된 열을 확인하는 정책. auth.uid() = id 어느 테이블에 id 소유자가 아닌 행의 기본 키는 의도와 일치하지 않습니다. 정책이 존재하고 오류 또는 빈 세트를 반환하며 표면은 여전히 ​​작동합니다.

• 적절한 액세스 제어 없이 데이터베이스 업데이트 및 삭제. 개발자는 선택을 철저히 보호하고 쓰기 정책을 느슨하게 두는 경우가 많습니다. 읽기 확인을 통과해도 다음에 누가 행을 수정할 수 있는지에 대해서는 아무 것도 알려주지 않습니다.

이들 중 어느 것도 스스로를 발표하지 않습니다. 각각은 앱이 계속 작동하도록 유지하며, 이것이 바로 프로덕션 환경에서 살아남는 이유입니다.

수동 감사는 직접적이며 새로운 도구가 필요하지 않습니다. 정책 자체를 테이블별로 진행합니다.

모든 테이블을 나열하고 각 테이블에서 RLS가 활성화되어 있는지 확인하는 것부터 시작하세요. 그런 다음 각 테이블에 대해 정책을 열거하고 이를 의도된 액세스(읽어야 하는 사람, 써야 하는 사람, 절대 만져서는 안 되는 사람)에 매핑합니다. 비교하는 열에 대해 각 정책 표현식을 읽습니다. 선택, 삽입, 업데이트 및 삭제 각각에 의도한 역할과 일치하는 정책이 있는지 확인합니다.

다음으로 코드 경로를 확인하세요. 애플리케이션이 사용자 대상 요청에 실제로 사용하는 키와 해당 키가 서비스 역할을 통해 실행되는지 여부를 결정합니다. 그런 다음 다른 사용자로 테스트 쿼리를 작성하고 결과가 예상과 일치하는지 확인합니다. 사용자는 자신의 행을 읽어야 하고 다른 사람의 행은 읽어서는 안 되며 자신이 소유하지 않은 행을 업데이트할 수 없어야 합니다.

수동 검토는 수행할 가치가 있으며 많은 내용을 파악합니다. 예측 가능한 사각지대도 있습니다.

• 테스트해야 할 것을 기억하는 것을 테스트합니다. 두 번째 사용자로서 삭제를 시도하지 않으려면 지나치게 광범위한 삭제 정책을 놓칠 수 있습니다. RLS가 활성화되면 적용 가능한 삭제 정책이 없으면 삭제가 거부된다는 의미입니다.

• 나이가 든다. 기능이 추가되면 정책이 달라집니다. 지난 분기에 철저하게 검토한 결과 지난주에 추가한 테이블에 대해서는 아무 것도 알려주지 않습니다.

• 정책을 구성한 사람에 따라 다릅니다. 정책을 작성한 건축업자는 자신의 가정을 발견할 가능성이 가장 적습니다.

• 기록된 증거가 필요합니다. "검토했는데 맞는 것 같았어요"라고 하면 아무 것도 남지 않습니다. 증거도 없고 범위도 없고 나중에 다시 스캔할 수 있는 인공물도 없습니다.

수동 감사는 "이것이 시스템의 정신 모델과 일치합니까?"라는 질문에 답합니다. 데이터베이스가 실제로 반환할 내용을 자체적으로 증명하지는 않습니다.

자동화된 Supabase RLS 보안 검사는 다른 방향에서 작동합니다. 이는 공격자나 잘못 구성된 클라이언트가 하는 방식으로 프로젝트를 실행하고 데이터 계층이 실제로 허용하는 것을 보고합니다.

이러한 변화는 세 가지 이유로 중요합니다. 첫째, 과거 메모리를 확장합니다. 스캔은 구성된 범위 내에서 사용 가능한 테이블과 엔드포인트 전체에 걸쳐 검사를 반복합니다. 적절한 액세스가 없으면 외부 검색으로 모든 정책을 검사할 수 없습니다. 둘째, 조치를 취할 수 있는 증거를 생성합니다. 결과는 테이블, 정책 상태 및 테이블에 도달할 수 있게 만든 조건의 이름을 지정하므로 변경해야 할 사항과 이유를 알 수 있습니다. 셋째, 반복 가능하다. 다시 실행할 수 있는 확인을 통해 일회성 검토가 지속적인 확인으로 전환됩니다.

VICE는 웹 애플리케이션과 Supabase/RLS 구성을 스캔한 다음 그 뒤에 있는 증거와 작업 시 수정 지침과 함께 결과를 보고합니다. 수정 사항을 표시하고 재검사를 요청할 수 있지만 유사한 재검사를 통해서만 문제가 해결되었음을 확인할 수 있습니다. 수정 사항은 편집에서 가정되지 않고 동일한 범위에 대해 확인됩니다. 예약된 검색 및 경고는 지속적인 모니터링을 지원하므로 다음 달에 추가된 표에서는 격차가 조용히 다시 발생하지 않습니다.

노동분업은 간단하다. 자동화된 검사를 실행하여 수동 검토에서 놓친 부분을 찾은 다음 수동 통과를 사용하여 검사에서 플래그를 지정한 각 정책 뒤에 숨은 의도를 확인합니다. 자동화는 데이터베이스가 허용하는 것을 알려줍니다. 해당 허가가 고의적인 것인지 여부는 귀하가 결정합니다.

모든 스캔의 점수는 테스트된 범위를 설명하지만 프로젝트가 완전히 안전하다는 보장은 아닙니다. 인증서가 아니라 어디를 봐야 하는지 알려주는 신호로 취급하세요.

Supabase로 구축된 제품을 배포하고 정책을 감사한 적이 없다면 정직한 대답은 둘 다입니다. 자동화된 RLS 검사로 시작하여 테이블이 허용하는 내용에 대한 증거를 뒷받침하는 최신 그림을 확보하세요. 그런 다음 결과를 직접 살펴보고 각 정책의 의도를 확인하고 표류된 정책을 수정합니다. 새 테이블과 새 정책이 원래 테이블과 동일한 조사를 받을 수 있도록 일정에 따라 자동 확인을 실행하세요.

두 가지 접근 방식 중 하나를 건너뛰면 데이터를 보호하는 것처럼 보이지만 여전히 무단 액세스를 허용하는 데이터베이스 액세스 정책이 남을 수 있습니다.

무료 스캔 시작 가입하기 전에 Vice-platform.com에서 공개 웹사이트를 확인하세요. 특수 Supabase 스캔에는 확인된 도메인과 유료 구독 또는 구매한 크레딧이 필요합니다. 해당 적용 범위는 구성된 액세스에 따라 다릅니다.