إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
إدارة الوصول إلى موارد الخوادم المرنة في قاعدة بيانات Azure لـ PostgreSQL هي جزء مهم من الحفاظ على الأمان والامتثال. تشرح هذه المقالة كيفية استخدام أدوار PostgreSQL وميزات Azure للتحكم في الأذونات وتنفيذ أفضل الممارسات لإدارة الوصول.
إدارة الأدوار
أفضل طريقة لإدارة أذونات الوصول المرنة إلى الخوادم في قاعدة بيانات Azure لـ PostgreSQL على نطاق واسع هي باستخدام مفهوم الأدوار. يمكن أن يكون الدور إما مستخدم قاعدة بيانات أو مجموعة من مستخدمي قاعدة البيانات. يمكن للأدوار امتلاك كائنات قاعدة البيانات وتعيين امتيازات على هذه الكائنات لأدوار أخرى للتحكم في من يمكنه الوصول إلى الكائنات. يمكنك منح عضوية في دور إلى دور آخر، مما يسمح لدور العضو باستخدام الامتيازات المعينة لدور آخر. خادم قاعدة بيانات Azure لـ PostgreSQL المرن يتيح لك منح الأذونات مباشرة لمستخدمي قاعدة البيانات. كممارسة أمنية جيدة، قم بإنشاء أدوار بمجموعات محددة من الأذونات استنادا إلى الحد الأدنى من متطلبات التطبيق والوصول. قم بتعيين الأدوار المناسبة لكل مستخدم. استخدم الأدوار لفرض نموذج أقل امتياز للوصول إلى كائنات قاعدة البيانات.
بالإضافة إلى الأدوار المضمنة التي ينشئها PostgreSQL، يتضمن الخادم المرن قاعدة بيانات Azure لـ PostgreSQL ثلاثة أدوار افتراضية. يمكنك رؤية هذه الأدوار عن طريق تشغيل الأمر التالي:
SELECT rolname FROM pg_roles;
الأدوار هي:
azure_pg_adminazuresu- دور المسؤول
عند إنشاء خادم مرن قاعدة بيانات Azure لـ PostgreSQL، فإنك توفر بيانات اعتماد لدور مسؤول. استخدم دور المسؤول هذا لإنشاء المزيد من أدوار PostgreSQL.
على سبيل المثال، يمكنك إنشاء مستخدم أو دور باسم demouser.
CREATE USER demouser PASSWORD password123;
لا تستخدم دور المسؤول للتطبيق.
في بيئات PaaS المستندة إلى السحابة، يقتصر الوصول إلى قاعدة بيانات Azure لحساب المستخدم المتميز PostgreSQL على التحكم في عمليات المستوى فقط من قبل مشغلي السحابة. لذلك ، يوجد الحساب azure_pg_admin كحساب مستخدم متميز زائف. دور المشرف هو عضو في الدور azure_pg_admin .
ومع ذلك، لا يعد حساب مسؤول الخادم جزءا من الدور azuresu ، الذي يتمتع بامتيازات المستخدم المتميز ويستخدم لتنفيذ عمليات وحدة التحكم. نظرا لأن هذه الخدمة هي خدمة PaaS مدارة، فإن Microsoft فقط هي جزء من دور المستخدم المتميز.
يمكنك تدقيق قائمة الأدوار في الخادم بشكل دوري.
على سبيل المثال، يمكنك الاتصال باستخدام psql العميل والاستعلام عن الجدول pg_roles ، الذي يسرد جميع الأدوار جنبا إلى جنب مع الامتيازات مثل إنشاء أدوار أخرى وإنشاء قواعد بيانات والنسخ المتماثل والمزيد.
select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname | demouser
rolsuper | f
rolinherit | t
rolcreaterole | f
rolcreatedb | f
rolcanlogin | f
rolreplication | f
rolconnlimit | -1
rolpassword | ********
rolvaliduntil |
rolbypassrls | f
rolconfig |
oid | 24827
Important
مؤخرا، مكنت قاعدة بيانات Azure ل PostgreSQL القدرة على إنشاء أوامر CAST. لتشغيل CREATE عبارة CAST، يجب أن يكون المستخدم عضوا في مجموعة azure_pg_admin . في الوقت الحالي، لا يمكنك إسقاط CAST بعد إنشائه.
تدعم قاعدة بيانات Azure ل PostgreSQL أوامر CAST التي تستخدم WITH FUNCTION الخيارات و WITH INOUT . الخيار WITHOUT FUNCTION غير مدعوم.
يتوفر تسجيل التدقيق في قاعدة بيانات Azure ل PostgreSQL أيضا مع قاعدة بيانات Azure ل PostgreSQL لتعقب النشاط في قواعد البيانات الخاصة بك.
التحكم في الوصول إلى المخطط
تتضمن قواعد البيانات التي تم إنشاؤها حديثا في قاعدة بيانات Azure ل PostgreSQL مجموعة افتراضية من الامتيازات في المخطط العام لقاعدة البيانات التي تمنح جميع مستخدمي قاعدة البيانات والأدوار القدرة على إنشاء كائنات. للحد بشكل أفضل من وصول مستخدم التطبيق إلى قواعد البيانات التي تقوم بإنشائها على خادم مرن قاعدة بيانات Azure لـ PostgreSQL، ضع في اعتبارك إبطال هذه الامتيازات العامة الافتراضية. بعد إلغاء هذه الامتيازات ، امنح امتيازات محددة لمستخدمي قاعدة البيانات على أساس أكثر دقة. على سبيل المثال:
إبطال امتيازات إنشاء المخطط
publicمن الدورpublicلمنع مستخدمي قاعدة بيانات التطبيق من إنشاء كائنات في المخطط العام.REVOKE CREATE ON SCHEMA public FROM PUBLIC;إنشاء قاعدة بيانات جديدة.
CREATE DATABASE Test_db;قم بإبطال جميع الامتيازات من مخطط PUBLIC في قاعدة البيانات الجديدة هذه.
REVOKE ALL ON DATABASE Test_db FROM PUBLIC;إنشاء دور مخصص لمستخدمي قاعدة بيانات التطبيق.
CREATE ROLE Test_db_user;امنح مستخدمي قاعدة البيانات الذين لديهم هذا الدور القدرة على الاتصال بقاعدة البيانات.
GRANT CONNECT ON DATABASE Test_db TO Test_db_user; GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;إنشاء مستخدم قاعدة بيانات.
CREATE USER user1 PASSWORD 'Password_to_change'قم بتعيين الدور ، مع امتيازات الاتصال والتحديد الخاصة به ، للمستخدم.
GRANT Test_db_user TO user1;
في هذا المثال، يمكن للمستخدم user1 الاتصال ولديه جميع الامتيازات في Test_db قاعدة بيانات الاختبار، ولكن ليس أي قاعدة بيانات أخرى على الخادم. بدلا من منح هذا المستخدم أو الدور جميع الامتيازات على قاعدة البيانات هذه وكائناتها، ضع في اعتبارك توفير أذونات أكثر انتقائية، مثل SELECT، INSERT، EXECUTE، وغيرها. لمزيد من المعلومات حول الامتيازات في قواعد بيانات PostgreSQL، راجع الأمرين GRANTوREVOKE في مستندات PostgreSQL.
تغييرات ملكية المخطط العام في قاعدة بيانات Azure ل PostgreSQL
في PostgreSQL 15 والإصدارات الأحدث، تغيرت ملكية المخطط العام إلى الدور الجديد pg_database_owner ، والذي يسمح لمالكي قواعد البيانات بالتحكم فيه. لمزيد من المعلومات، راجع ملاحظات إصدار PostgreSQL.
ومع ذلك، في قاعدة بيانات Azure ل PostgreSQL، لا ينطبق هذا التغيير. المخطط العام مملوك للدور azure_pg_admin عبر جميع إصدارات PostgreSQL المدعومة. يوفر سلوك الخدمة المدارة هذا الأمان والاتساق.
تغييرات PostgreSQL 16 مع الأمان المستند إلى الدور
في PostgreSQL، يمكن أن يحتوي دور قاعدة البيانات على العديد من السمات التي تحدد امتيازاته. إحدى هذه السمات هي السمة CREATEROLE ، وهي مهمة لإدارة قاعدة بيانات PostgreSQL للمستخدمين والأدوار. في PostgreSQL 16 ، تم إدخال تغييرات كبيرة على هذه السمة.
في PostgreSQL 16 ، لم يعد لدى المستخدمين الذين لديهم سمة CREATEROLE القدرة على توزيع العضوية في أي دور لأي شخص. بدلا من ذلك ، مثل المستخدمين الآخرين الذين ليس لديهم هذه السمة ، يمكنهم فقط توزيع العضويات في الأدوار التي يمتلكونها ADMIN OPTION. أيضا، في PostgreSQL 16، لا تزال السمة CREATEROLE تسمح لغير المستخدم المتميز بالقدرة على توفير مستخدمين جدد. ومع ذلك ، يمكنهم فقط إسقاط المستخدمين الذين أنشأوهم بأنفسهم. تؤدي محاولات إسقاط المستخدمين إلى حدوث خطأ عندما لا يتم إنشاء المستخدم بواسطة مستخدم باستخدام السمة CREATEROLE .
يقدم PostgreSQL 16 أيضا دورا مدمجا جديدا ومحسنا. يسمح دور pg_create_subscription للمستخدمين المتميزين بإنشاء اشتراكات.
في قاعدة بيانات Azure لـ PostgreSQL الخادم المرن، دور azure_pg_admin هو دور مدار من قبل النظام ومقيد ولا يمكن للمستخدمين تعديله. تؤدي محاولات تغييره، مثل منح دور آخر له، إلى حدوث خطأ مثل:
GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"
هذا الخطأ هو حماية مضمنة لمنع التغييرات في الأدوار الإدارية الهامة. إذا كنت بحاجة إلى تعيين امتيازات أو أدوار، ففكر في إنشاء دور مخصص بدلا من ذلك ومنح الأذونات اللازمة لهذا الدور.
تحكم محسن في azure_pg_admin
في PostgreSQL 16، يتم تنفيذ بنية تدرج هرمي صارمة للأدوار للمستخدمين الذين لديهم امتياز CREATEROLE ، وتحديدا فيما يتعلق بأدوار المنح. لتحسين المرونة الإدارية ومعالجة القيود المقدمة في PostgreSQL 16، تعمل قاعدة بيانات Azure ل PostgreSQL على تحسين إمكانات دور azure_pg_admin عبر جميع إصدارات PostgreSQL. باستخدام هذا التحديث، يمكن لأعضاء دور azure_pg_admin إدارة الأدوار والوصول إلى الكائنات المملوكة لأي دور غير مقيد، حتى إذا كانت هذه الأدوار أيضا أعضاء في azure_pg_admin. يضمن هذا التحسين أن يحتفظ المستخدمون الإداريون بتحكم متسق وشامل في إدارة الأدوار والأذونات، مما يوفر تجربة سلسة وموثوقة دون الحاجة إلى وصول المستخدم المتميز.
الأمان على مستوى الصف
الأمان على مستوى الصف (RLS) هو ميزة أمان قاعدة بيانات Azure ل PostgreSQL تمكن مسؤولي قاعدة البيانات من تحديد النهج التي تتحكم في كيفية عرض صفوف معينة من البيانات وتشغيلها لدور واحد أو أكثر. يضيف الأمان على مستوى الصف عامل تصفية إضافي إلى قاعدة بيانات Azure لجدول قاعدة بيانات PostgreSQL. عندما يحاول مستخدم تنفيذ إجراء على جدول، يتم تطبيق عامل التصفية هذا قبل معايير الاستعلام أو التصفية الأخرى، ويتم تضييق نطاق البيانات أو رفضها وفقا لنهج الأمان الخاص بك. يمكنك إنشاء نهج أمان على مستوى الصف لأوامر معينة مثل SELECT، INSERTو ، UPDATEو DELETE، أو تحديدها لكافة الأوامر. تتضمن حالات الاستخدام للأمان على مستوى الصف التطبيقات المتوافقة مع PCI والبيئات المصنفة والاستضافة المشتركة أو التطبيقات متعددة المستأجرين.
يمكن للمستخدمين الذين لديهم SET ROW SECURITY حقوق فقط تطبيق حقوق أمان الصف على جدول. يمكن لمالك الجدول تعيين أمان الصف على جدول. مثل OVERRIDE ROW SECURITY، هذا الحق هو حاليا حق ضمني. لا يتجاوز الأمان على مستوى الصف الأذونات الموجودة GRANT . يضيف مستوى أدق من التحكم. على سبيل المثال، لا يمنح الإعداد ROW SECURITY FOR SELECT للسماح لمستخدم معين بالوصول إلى الصفوف حق الوصول إلى هذا المستخدم إلا إذا كان لدى SELECT المستخدم أيضا امتيازات في العمود أو الجدول المعني.
يوضح المثال التالي كيفية إنشاء نهج يضمن فقط لأعضاء دورالمدير الذي تم إنشاؤه خصيصا الوصول إلى صفوف حساب معين فقط. تتم مشاركة التعليمات البرمجية في المثال التالي في وثائق PostgreSQL.
CREATE TABLE accounts (manager text, company text, contact_email text);
ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;
CREATE POLICY account_managers ON accounts TO managers
USING (manager = current_user);
تضيف العبارة USING ضمنيا جملة WITH CHECK ، مما يضمن أن أعضاء دور المدير لا يمكنهم تنفيذ SELECT، DELETEأو UPDATE العمليات على الصفوف التي تنتمي إلى مديرين آخرين، ولا يمكنهم إنشاء INSERT صفوف جديدة تنتمي إلى مدير آخر.
يمكنك إسقاط نهج أمان صف باستخدام DROP POLICY الأمر، كما هو موضح في هذا المثال:
DROP POLICY account_managers ON accounts;
على الرغم من أنك قد تسقط النهج، إلا أن مدير الدور لا يزال غير قادر على عرض أي بيانات تنتمي إلى أي مدير آخر. يوجد هذا التقييد لأن نهج الأمان على مستوى الصف لا يزال ممكنا في جدول الحسابات. إذا تم تمكين الأمان على مستوى الصف بشكل افتراضي، يستخدم PostgreSQL نهج رفض افتراضي.
يمكنك تعطيل الأمان على مستوى الصف، كما هو موضح في المثال التالي:
ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;
تجاوز الأمان على مستوى الصف
لدى PostgreSQL أذونات BYPASSRLS و NOBYPASSRLS ، والتي يمكنك تعيينها لدور. يتم تعيين NOBYPASSRLS افتراضيا. باستخدام الخوادم المتوفرة حديثا في قاعدة بيانات Azure ل PostgreSQL، يتم تنفيذ تجاوز امتياز الأمان على مستوى الصف (BYPASSRLS) على النحو التالي:
بالنسبة إلى Postgres 16 والخوادم التي تم إصدارها أحدثا ، فإننا نتبع سلوك PostgreSQL 16 القياسي. يسمح لك المستخدمون غير الإداريين الذين تم إنشاؤهم بواسطة دور المسؤول azure_pg_admin بإنشاء أدوار باستخدام سمة أو امتياز BYPASSRLS حسب الضرورة.
بالنسبة لخوادم Postgres 15 والخوادم السابقة، يمكنك استخدام مستخدم azure_pg_admin لتنفيذ المهام الإدارية التي تتطلب امتياز BYPASSRLS. ومع ذلك، لا يمكنك إنشاء مستخدمين غير إداريين بامتياز BypassRLS، نظرا لأن دور المسؤول لا يحتوي على امتيازات مستخدم متميز، كما هو شائع في خدمات PaaS PostgreSQL المستندة إلى مجموعة النظراء.