답변.

SQL 서버는 역할, 사용자 권한 (GRANT/REVOKE) 및 스키마를 통해 다계층 접근 권한 시스템을 지원합니다. 주요 원칙:

역할 할당 = 사용자가 나중에 가질 일련의 권한.
최소한의 권한만 부여하십시오 (최소 권한 원칙).
데이터베이스, 테이블, 뷰 및 프로시저의 권한을 분리하십시오.
특히 중요한 작업의 경우, 테이블에 대한 직접 접근이 아닌 저장 프로시저 또는 뷰를 통해서만 사용하십시오.

역할 생성 및 권한 할당 예:

-- 분석가를 위한 역할 생성
CREATE ROLE Analyst;
-- 필요한 테이블에 대해 SELECT 권한만 부여
GRANT SELECT ON Sales TO Analyst;
-- 데이터 수정 금지
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- 사용자에게 역할 할당
GRANT Analyst TO user_ivan;

읽기 전용(role), 수정, 관리 및 특정 작업을 위한 역할을 자주 구분합니다.

함정 질문.

함정: "VIEW에만 접근할 수 있는 사용자가 그것을 통해 기본 테이블을 수정할 수 있습니까? 예를 들어 보세요."

답변: 예, VIEW가 집계/그룹화 없이 읽기 전용이 아닌 경우 (WITH CHECK OPTION), VIEW에 대해 INSERT/UPDATE/DELETE를 수행할 수 있으며, 권한이 허용되면 변경 사항이 기본 테이블에 반영됩니다.

-- 불필요한 열을 제거하는 VIEW
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- 허용되면 사용자가 다음과 같이 변경할 수 있습니다:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- 이는 id=42에 대한 Sales.total에 영향을 미칩니다.

해결책: 오직 읽기 전용 VIEW만 사용하거나 VIEW를 통한 데이터 수정 권한을 금지하십시오.

주제에 대한 세부 사항을 잘 알지 못해서 발생한 실제 오류 예.

이야기

프로젝트: HR 포털, 직원 개인 정보.

오류: 운영자가 UPDATE 제한 없이 VIEW를 통해 기본 테이블에 접근할 수 있었고, 서로의 급여를 우연히 수정했습니다. VIEW는 처음에 "보고서 전용"으로 설계되었습니다.

이야기

프로젝트: 회계, 외부 통합.

오류: 외부 시스템에 전체 DB에 대한 INSERT 및 SELECT 권한을 부여 했고 필요한 테이블에 대한 INSERT만 허용했습니다. 결과: 전체 DB를 읽을 수 있는 취약성 및 GDPR 법률 위반 가능성.

이야기

프로젝트: SaaS 플랫폼, 다중 사용자 보고서.

오류: 모든 클라이언트가 공통 권한을 가진 동일한 스키마에서 작업했고, 우연히 다른 데이터에 대한 접근 및 수정이 가능했습니다. 해결책: 스키마를 분할하고, 개별 역할 및 행 수준 보안 (RLS)에서 자체 제한을 설정하는 것입니다.

데이터를 SQL에서 우연한 또는 악의적인 변경으로부터 보호하는 방법은 무엇입니까? 접근 권한의 수준은 어떻게 다르고 다계층 보안 정책을 어떻게 올바르게 구현할 수 있습니까?

답변.

함정 질문.

주제에 대한 세부 사항을 잘 알지 못해서 발생한 실제 오류 예.