دسترسی فقط‌خواندنی

اوبا برای پاسخ دادن فقط به خواندن داده نیاز دارد. بنابراین اتصال را با یک کاربر اختصاصی بسازید که فقط اجازهٔ خواندن جدول‌های لازم را دارد، نه با حساب مدیر اصلی پایگاه‌داده. این صفحه برای مدیر پایگاه‌داده (DBA) نوشته شده است و نمونه دستورهای لازم را دارد.

اوبا چگونه از نوشتن جلوگیری می‌کند؟

حفاظت در چند لایه انجام می‌شود:

1. بررسی پیش از اجرا در همهٔ منابع. هر پرس‌وجو، پیش از آنکه به پایگاه‌داده فرستاده شود، بررسی می‌شود و هر دستوری که خواندن نباشد رد می‌شود. این بررسی خاموش‌شدنی نیست. اگر پرس‌وجو تابعی از پایگاه‌داده را صدا بزند، متن آن تابع هم بررسی می‌شود (توابع منتظر تأیید).
2. حالت فقط‌خواندنیِ خود پایگاه‌داده، در جایی که وجود دارد. در PostgreSQL و موتورهای سازگار با آن، MySQL، MariaDB، Oracle و Redshift، همهٔ پرس‌وجوها در حالت فقط‌خواندنیِ خود پایگاه‌داده اجرا می‌شوند. در ClickHouse تنظیم فقط‌خواندنیِ سمت سرور به کار می‌رود و فایل‌ها (SQLite، DuckDB، فایل صفحه‌گسترده) فقط برای خواندن باز می‌شوند.
3. مجوزهای کاربر پایگاه‌داده. این لایهٔ قطعی است و در اختیار شماست. در SQL Server، Db2، Snowflake و BigQuery خود پایگاه‌داده حالت فقط‌خواندنی جداگانه‌ای برای اتصال ندارد؛ پس در این منابع، کاربر فقط‌خواندنی تنها مانع سمت پایگاه‌داده است.

احتیاط

لایه‌های ۱ و ۲ جای کاربر فقط‌خواندنی را نمی‌گیرند. جدول‌های حساس را با ندادن مجوز به همین کاربر از دسترس خارج کنید؛ کنار گذاشتن یک جدول در مستندات جدول‌ها، مانع خواندن آن نیست.

نمونه دستورها برای ساخت کاربر

مقادیر داخل < > را با مقدار واقعی جایگزین کنید و پیش از اجرا، دستورها را با سیاست‌های امنیتی سازمان خود تطبیق دهید.

PostgreSQL (و موتورهای سازگار):

CREATE ROLE ooba_reader LOGIN PASSWORD '<STRONG_PASSWORD>';
GRANT CONNECT ON DATABASE <DATABASE> TO ooba_reader;
GRANT USAGE ON SCHEMA <SCHEMA> TO ooba_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA <SCHEMA> TO ooba_reader;
-- جدول‌هایی که بعداً ساخته می‌شوند:
ALTER DEFAULT PRIVILEGES IN SCHEMA <SCHEMA> GRANT SELECT ON TABLES TO ooba_reader;
-- اجازهٔ ساخت جدول در شِمای public را از همه پس بگیرید:
REVOKE CREATE ON SCHEMA public FROM PUBLIC;

MySQL و MariaDB (کاربر را به IP سرور اوبا محدود کنید):

CREATE USER 'ooba_reader'@'<OOBA_IP>' IDENTIFIED BY '<STRONG_PASSWORD>';
GRANT SELECT, SHOW VIEW ON `<DATABASE>`.* TO 'ooba_reader'@'<OOBA_IP>';

Microsoft SQL Server:

CREATE LOGIN ooba_reader WITH PASSWORD = '<STRONG_PASSWORD>';
USE <DATABASE>;
CREATE USER ooba_reader FOR LOGIN ooba_reader;
ALTER ROLE db_datareader ADD MEMBER ooba_reader;
GRANT SHOWPLAN TO ooba_reader;

مجوز SHOWPLAN فقط اجازهٔ دیدن طرح اجرای پرس‌وجو را می‌دهد و دسترسی خواندن یا نوشتن تازه‌ای اضافه نمی‌کند. اوبا با آن، پیش از اجرا تشخیص می‌دهد که آیا یک پرس‌وجو کل یک جدول بزرگ را می‌خواند. بدون این مجوز، پس از آزمایش اتصال هشدار «محافظ «اسکن کامل جدول‌های بزرگ» برای این اتصال خاموش است» نمایش داده می‌شود و دستور لازم برای رفع آن آمادهٔ کپی است.

Oracle:

CREATE USER ooba_reader IDENTIFIED BY "<STRONG_PASSWORD>";
GRANT CREATE SESSION TO ooba_reader;
GRANT SELECT ON <OWNER>.<TABLE> TO ooba_reader;  -- برای هر جدول یا نمای لازم

IBM Db2: کاربری بسازید که فقط مجوز CONNECT روی پایگاه‌داده و SELECT روی جدول‌های لازم را داشته باشد.

Snowflake: نقشی بسازید که فقط USAGE روی پایگاه‌داده و شِما و SELECT روی جدول‌ها داشته باشد و آن را نقش این کاربر کنید. BigQuery: حساب سرویس جداگانه‌ای فقط با نقش‌های BigQuery Data Viewer و BigQuery Job User بسازید. MongoDB: کاربری با نقش read روی همان پایگاه‌داده.

نکته

اگر فقط بخشی از ستون‌ها برای تحلیل لازم است (مثلاً بدون نام و کد ملی مشتری)، یک نما (view) با ستون‌های مجاز بسازید و فقط به آن مجوز SELECT بدهید.

نتیجهٔ بررسی دسترسی نوشتن را بخوانید

هر بار که «آزمایش اتصال» موفق باشد، اوبا مجوزهای کاربر اتصال را هم بررسی می‌کند و نتیجه را در بخش «ایمنی» زبانهٔ «وضعیت» همان اتصال نشان می‌دهد (زبانهٔ وضعیت). این بررسی فقط اطلاع‌رسانی است و چیزی را مسدود نمی‌کند:

نشان	معنا	اقدام
«فقط‌خواندنی (تأییدشده)»	کاربر نمی‌تواند داده یا ساختار پایگاه‌داده را تغییر دهد.	کاری لازم نیست.
«اجازهٔ نوشتن دارد»	کاربر می‌تواند داده را تغییر دهد، ساختار را عوض کند یا دسترسی مدیریتی دارد؛ فهرست دقیق زیر همین کادر می‌آید.	کاربر جداگانهٔ فقط‌خواندنی بسازید و نام کاربری و گذرواژهٔ اتصال را عوض کنید.
«فقط‌خواندنی بودن تأیید نشد»	بررسی کامل نشد یا برای این نوع منبع روش بررسی قطعی وجود ندارد.	مجوزهای کاربر را خودتان کنترل کنید.

اگر کاری برای مدیر پایگاه‌داده مانده باشد، همان بخش «ایمنی» یک «متن آماده برای مدیر پایگاه‌داده» دارد که همهٔ درخواست‌ها و دستورهای لازم را در یک متن جمع می‌کند؛ با «کپی متن» آن را برای مدیر پایگاه‌داده بفرستید (متن آماده برای مدیر پایگاه‌داده).

مثال

در شرکت فرضی «پخش البرز»، مدیر پایگاه‌داده برای SQL Server کاربر ooba_reader را با نقش db_datareader و مجوز SHOWPLAN می‌سازد. جدول حقوق کارکنان در پایگاه‌دادهٔ جداگانه‌ای است که این کاربر به آن دسترسی ندارد. پس از «آزمایش اتصال»، بخش «ایمنی» زبانهٔ «وضعیت» نشان «فقط‌خواندنی (تأییدشده)» را نشان می‌دهد و هشدار SHOWPLAN ظاهر نمی‌شود.

گام بعدی

• اجازهٔ دسترسی شبکه و فایروال
• افزودن اتصال پایگاه‌داده
• امنیت و نگهداری داده‌ها