PostgreSQL ನಲ್ಲಿ ರೋ ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದರ ಕುರಿತು ಒಂದು ಅಧ್ಯಯನ

ಪೂರಕವಾಗಿ PostgreSQL ಸಂಗ್ರಹಿಸಿದ ಕಾರ್ಯಗಳ ಮಟ್ಟದಲ್ಲಿ ವ್ಯವಹಾರ ತರ್ಕವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಅಧ್ಯಯನ и ಮುಖ್ಯವಾಗಿ ವಿವರವಾದ ಉತ್ತರಕ್ಕಾಗಿ ಮೇಲೆ ವ್ಯಾಖ್ಯಾನ.

ದಾಖಲಾತಿಯಲ್ಲಿ ಸೈದ್ಧಾಂತಿಕ ಭಾಗವನ್ನು ಚೆನ್ನಾಗಿ ವಿವರಿಸಲಾಗಿದೆ PostgreSQL - ಸಾಲು ರಕ್ಷಣೆ ನೀತಿಗಳು. ಕೆಳಗೆ ಒಂದು ಸಣ್ಣ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನವಾಗಿದೆ ನಿರ್ದಿಷ್ಟ ವ್ಯವಹಾರ ಕಾರ್ಯ - ಅಳಿಸಿದ ಡೇಟಾವನ್ನು ಮರೆಮಾಡುವುದು. ಅನುಷ್ಠಾನಕ್ಕೆ ಮೀಸಲಾಗಿರುವ ಸ್ಕೆಚ್ RLS ಬಳಸಿಕೊಂಡು ರೋಲ್ ಮಾಡೆಲಿಂಗ್ ಪ್ರತ್ಯೇಕವಾಗಿ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ.

PostgreSQL ನಲ್ಲಿ ರೋ ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದರ ಕುರಿತು ಒಂದು ಅಧ್ಯಯನ

ಲೇಖನದಲ್ಲಿ ಹೊಸದೇನೂ ಇಲ್ಲ, ಗುಪ್ತ ಅರ್ಥ ಅಥವಾ ರಹಸ್ಯ ಜ್ಞಾನವಿಲ್ಲ. ಸೈದ್ಧಾಂತಿಕ ಕಲ್ಪನೆಯ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನದ ಬಗ್ಗೆ ಕೇವಲ ಒಂದು ಸ್ಕೆಚ್. ಯಾರಾದರೂ ಆಸಕ್ತಿ ಇದ್ದರೆ, ಅದನ್ನು ಓದಿ. ನಿಮಗೆ ಆಸಕ್ತಿ ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಸಮಯವನ್ನು ವ್ಯರ್ಥ ಮಾಡಬೇಡಿ.

ಸಮಸ್ಯೆ ಹೇಳಿಕೆ

ವಿಷಯದ ಪ್ರದೇಶಕ್ಕೆ ಆಳವಾಗಿ ಧುಮುಕದೆ, ಸಂಕ್ಷಿಪ್ತವಾಗಿ, ಸಮಸ್ಯೆಯನ್ನು ಈ ಕೆಳಗಿನಂತೆ ರೂಪಿಸಬಹುದು: ನಿರ್ದಿಷ್ಟ ವ್ಯಾಪಾರ ಘಟಕವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಟೇಬಲ್ ಇದೆ. ಕೋಷ್ಟಕದಲ್ಲಿನ ಸಾಲುಗಳನ್ನು ಅಳಿಸಬಹುದು, ಆದರೆ ಸಾಲುಗಳನ್ನು ಭೌತಿಕವಾಗಿ ಅಳಿಸಲಾಗುವುದಿಲ್ಲ; ಅವುಗಳನ್ನು ಮರೆಮಾಡಬೇಕು.

ಇದನ್ನು ಹೇಳಲಾಗಿದೆ: “ಯಾವುದನ್ನೂ ಅಳಿಸಬೇಡಿ, ಅದನ್ನು ಮರುಹೆಸರಿಸಿ. ಇಂಟರ್ನೆಟ್ ಎಲ್ಲವನ್ನೂ ಸಂಗ್ರಹಿಸುತ್ತದೆ"

ದಾರಿಯುದ್ದಕ್ಕೂ, ಈ ಘಟಕದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಂಗ್ರಹಿಸಲಾದ ಕಾರ್ಯಗಳನ್ನು ಪುನಃ ಬರೆಯದಿರುವುದು ಸೂಕ್ತವಾಗಿದೆ.

ಈ ಪರಿಕಲ್ಪನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ಟೇಬಲ್ ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿದೆ ಅಳಿಸಲಾಗಿದೆ. ನಂತರ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ - ಕ್ಲೈಂಟ್ ಗುಣಲಕ್ಷಣವನ್ನು ಹೊಂದಿರುವ ಸಾಲುಗಳನ್ನು ಮಾತ್ರ ನೋಡಬಹುದು ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು ಅಳಿಸಲಾಗಿದೆ ಸುಳ್ಳು ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಯಾವುದಕ್ಕಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ? ಸಾಲು ಮಟ್ಟದ ಭದ್ರತೆ.

Реализация

ಪ್ರತ್ಯೇಕ ಪಾತ್ರ ಮತ್ತು ಸ್ಕೀಮಾವನ್ನು ರಚಿಸಿ

CREATE ROLE repos;
CREATE SCHEMA repos;

ಗುರಿ ಕೋಷ್ಟಕವನ್ನು ರಚಿಸಿ

CREATE TABLE repos.file
(
...
is_del BOOLEAN DEFAULT FALSE
);
CREATE SCHEMA repos

ಆನ್ ಮಾಡಿ ಸಾಲು ಮಟ್ಟದ ಭದ್ರತೆ

ALTER TABLE repos.file  ENABLE ROW LEVEL SECURITY ;
CREATE POLICY file_invisible_deleted  ON repos.file FOR ALL TO dba_role USING ( NOT is_deleted );
GRANT ALL ON TABLE repos.file to dba_role ;
GRANT USAGE ON SCHEMA repos TO dba_role ;

ಸೇವಾ ಕಾರ್ಯ - ಕೋಷ್ಟಕದಲ್ಲಿನ ಸಾಲನ್ನು ಅಳಿಸುವುದು

CREATE OR REPLACE repos.delete( curr_id repos.file.id%TYPE)
RETURNS integer AS $$
BEGIN
...
UPDATE repos.file
SET is_del = TRUE 
WHERE id = curr_id ; 
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

ವ್ಯಾಪಾರ ಕಾರ್ಯ - ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಅಳಿಸುವುದು

CREATE OR REPLACE business_functions.deleteDoc( doc_for_delete JSON )
RETURNS JSON AS $$
BEGIN
...
PERFORM  repos.delete( doc_id ) ;
...
END
$$ LANGUAGE plpgsql SECURITY DEFINER;

ರೆಸೆಲ್ಯೂಟ್ಸ್

ಕ್ಲೈಂಟ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಅಳಿಸುತ್ತದೆ

SELECT business_functions.delCFile( (SELECT json_build_object( 'CId', 3 )) );

ಅಳಿಸಿದ ನಂತರ, ಕ್ಲೈಂಟ್ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ

SELECT business_functions.getCFile"( (SELECT json_build_object( 'CId', 3 )) ) ;
-----------------
(0 rows)

ಆದರೆ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಡಾಕ್ಯುಮೆಂಟ್ ಅನ್ನು ಅಳಿಸಲಾಗಿಲ್ಲ, ಗುಣಲಕ್ಷಣವನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ is_del

psql -d my_db
SELECT  id, name , is_del FROM repos.file ;
id |  name  | is_del
--+---------+------------
 1 |  test_1 | t
(1 row)

ಸಮಸ್ಯೆ ಹೇಳಿಕೆಯಲ್ಲಿ ಏನು ಅಗತ್ಯವಿದೆ.

ಫಲಿತಾಂಶ

ವಿಷಯವು ಆಸಕ್ತಿದಾಯಕವಾಗಿದ್ದರೆ, ಮುಂದಿನ ಅಧ್ಯಯನದಲ್ಲಿ ನೀವು ರೋ ಲೆವೆಲ್ ಸೆಕ್ಯುರಿಟಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಡೇಟಾ ಪ್ರವೇಶವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ರೋಲ್-ಆಧಾರಿತ ಮಾದರಿಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಉದಾಹರಣೆಯನ್ನು ತೋರಿಸಬಹುದು.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ