Sətir səviyyəsində girişə nəzarət: Row-Level Security (RLS)

Əgər rol və cədvəl səviyyəsində hüquqlar "giriş qapısında duran mühafizəçi" kimidirsə, Row-Level Security — hər otağa ayrıca baxan fərdi mühafizəçidir, hansı ki, hər bir istifadəçiyə konkret otağa girib-girməməsini yoxlayır.

RLS kömək edir ki, istifadəçi yalnız ona icazə verilmiş cədvəl sətirləri ilə işləyə bilsin. Məsələn:

• Online mağazada menecer yalnız öz sifarişlərini görməlidir.
• CRM-platformasında əməkdaş yalnız öz komandasının müştərilərini görür.
• Bank sistemində müştəri yalnız öz hesablarına giriş əldə etməlidir.

RLS necə işləyir

RLS-in işləmə prinsipi giriş siyasətləri konsepsiyasına əsaslanır. Siyasətlər müəyyən edir ki, hansı cədvəl sətirləri rol və ya istifadəçi üçün görünəndir və hansılar dəyişiklik üçün əlçatandır (INSERT, UPDATE, DELETE).

Default olaraq RLS söndürülüb bütün cədvəllər üçün və onu əl ilə aktiv etmək lazımdır.

Cədvəl üçün RLS-i aktiv etmək

Gəlin orders adlı bir cədvəl yaradaq, burada online mağazanın sifarişləri saxlanılır:

CREATE TABLE orders (
    order_id SERIAL PRIMARY KEY,
    user_id INT NOT NULL,
    product_name TEXT NOT NULL,
    price NUMERIC NOT NULL
);

Bəzi test dataları əlavə edək:

INSERT INTO orders (user_id, product_name, price)
VALUES
    (1, 'Smartfon', 500),
    (2, 'Noutbuk', 1000),
    (1, 'Qulaqlıq', 100),
    (3, 'Klaviatura', 50);

İndi bu cədvəl üçün RLS-i aktiv edirik:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

Nə etdik? Biz RLS mexanizmini aktiv etdik, amma siyasətləri hələ təyin etməmişik. Siyasətlər yaradılmayana qədər, RLS faktiki olaraq cədvələ girişə təsir etmir.

Giriş siyasəti yaratmaq

Girişi idarə etmək üçün qaydalar əlavə etmək üçün bu komandadan istifadə olunur:

CREATE POLICY siyasət_adı
ON cədvəl
[FOR { SELECT | INSERT | UPDATE | DELETE }]
TO rol
USING (giriş_şərti)
WITH CHECK (yoxlama_şərti);

• FOR: siyasətin hansı əməliyyatlara tətbiq olunduğunu göstərir (SELECT, INSERT, UPDATE, DELETE). Bu parametr buraxılsa, siyasət bütün əməliyyatlara tətbiq olunur.
• TO: siyasətin hansı rollar üçün aktiv olduğunu göstərir. Əgər göstərilməsə, siyasət istənilən rol üçün işləyir.
• USING: istifadəçi üçün sətirlərin görünməsi üçün şərt təyin edir.
• WITH CHECK: INSERT və UPDATE əməliyyatları üçün yoxlama şərtini müəyyən edir.

Nümunə: yalnız öz sifarişlərinə giriş

İstifadəçilərə yalnız öz sifarişlərini görməyə icazə verən siyasət yaradaq. Fərz edək ki, cari istifadəçinin identifikatoru cədvəldəki user_id ilə üst-üstə düşür:

CREATE POLICY user_can_view_own_orders
ON orders
FOR SELECT
USING (user_id = current_user::INT);

Burada nə baş verir?

• Siyasətin adı user_can_view_own_orders-dir.
• O, SELECT əməliyyatına tətbiq olunur.
• Yalnız user_id cari istifadəçinin identifikatoru (current_user) ilə eyni olan sətirlər görünür.

Yəni, əgər sən sistemə user_id = 1 olan istifadəçi kimi daxil olsan, yalnız öz sifarişlərini görəcəksən.

RLS-in işləməsini yoxlamaq

İki istifadəçi yaradaq: user1 və user2.

CREATE ROLE user1 LOGIN PASSWORD 'password1';
CREATE ROLE user2 LOGIN PASSWORD 'password2';

Rollara cədvələ giriş verək:

GRANT SELECT ON orders TO user1, user2;

İndi user1 istifadəçisinə keçib sorğu icra edək:

SELECT * FROM orders;

Nəticə: yalnız user_id = 1 olan sətirləri görəcəksən.

INSERT üçün siyasətlər

Deyək ki, istifadəçilərə yalnız öz sifarişlərini əlavə etməyə icazə vermək istəyirik (yəni, user_id cari istifadəçinin identifikatoru ilə eyni olmalıdır).

INSERT üçün siyasət yaradaq:

CREATE POLICY user_can_insert_own_orders
ON orders
FOR INSERT
WITH CHECK (user_id = current_user::INT);

İndi, əgər user1 istifadəçisi user_id 1-ə bərabər olmayan sifariş əlavə etməyə çalışsa, sorğu səhvlə bitəcək.

UPDATE və DELETE üçün siyasətlər

Eyni qaydada məlumatları dəyişmək və silmək üçün siyasətlər yarada bilərik. Məsələn:

Öz datalarını yeniləmək üçün:

CREATE POLICY user_can_update_own_orders
ON orders
FOR UPDATE
USING (user_id = current_user::INT)
WITH CHECK (user_id = current_user::INT);

Öz datalarını silmək üçün:

CREATE POLICY user_can_delete_own_orders
ON orders
FOR DELETE
USING (user_id = current_user::INT);

Bircə cədvəl üçün bir neçə siyasət tətbiq etmək

Bir cədvəl üçün bir neçə siyasət yarada bilərsən. Onların hamısı eyni anda işləyəcək. Məsələn, bir rol üçün bir neçə qayda varsa, PostgreSQL onların hamısını yoxlayacaq (logical AND).

RLS-i yoxlamaq və debug etmək

Bir cədvəl üçün hansı siyasətlərin qurulduğunu yoxlamaq üçün bu komandadan istifadə et:

\di+ cədvəl_adı

Əgər RLS-i müvəqqəti söndürmək istəyirsənsə (məsələn, admin üçün), bunu icra et:

ALTER TABLE orders DISABLE ROW LEVEL SECURITY;

SUPERUSER admin rolu default olaraq RLS ilə məhdudlaşmır, ona görə bütün dataları görə bilər.

RLS-i qurarkən tipik səhvlər

Səhvlər ola bilər, əgər sən unutdunsa:

• RLS-i ALTER TABLE ... ENABLE ROW LEVEL SECURITY komandası ilə aktiv etməyi.
• Bütün əməliyyatlar üçün uyğun siyasətləri təyin etməyi (SELECT, INSERT, UPDATE, DELETE).
• USING və WITH CHECK içində şərti düzgün göstərməyi. Məsələn, user_id yoxlanmasa, təsadüfən bütün sətirlərə giriş açıq ola bilər.

Row-Level Security — PostgreSQL-də ən güclü təhlükəsizlik alətlərindən biridir. O, girişə sətir səviyyəsində dəqiqliklə nəzarət etməyə və idarəetməni avtomatlaşdırmağa imkan verir, bu da xüsusilə mürəkkəb və yüksək təhlükəsizlik tələbi olan tətbiqlər üçün vacibdir.