PostgreSQL

چک لیست امنیتی محافظت از پایگاه داده PostgreSQL

هنگامی که فرایند نصب سرور پایگاه داده PostgreSQL را به پایان رسانده اید لازم است قبل از شروع به کار، از آن حفاظت کنید در این سند که چک لیست امنیتی محافظت از پایگاه داده است نشان خواهیم داد که چگونه امنیت در اطراف پایگاه داده خود را سخت تر کنید تا اطلاعات خود را امن و مطمئن نگه دارید.

  1. Client Authentication Control
  2. Server Configuration
  3. User and Role Management
  4. Super User Management
  5. (Data Encryption (on connection ssl
  6. (Data Encryption at Rest (pg_crypto
  7. Logging
  8. Auditing
  9. Patching
  10. (Know Your Workload (pg_stats_statement

1. تأیید هویت مشتری در چک لیست امنیتی پایگاه داده

هنگام نصب PostgreSQL یک فایل به نام pg_hba.conf در دایرکتوری داده های خوشه ای ایجاد شده است. این فایل کنترل احراز هویت مشتری است.

از اسناد رسمی postgresql می توانیم فایل pg_hba.conf را به صورت مجموعه ای از پرونده ها تعریف کنیم، در هر خط، هر رکورد نوع اتصال را تعیین می کند، محدوده IP آدرس مشتری (اگر مربوط به نوع اتصال)، نام پایگاه داده، نام کاربر و روش تأیید هویت برای اتصالات مربوط به این پارامترها استفاده می شود.

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

بنابراین فرمت عمومی چیزی شبیه به این خواهد بود:

# TYPE  DATABASE        USER        ADDRESS            METHOD

مثال پیکربندی می تواند به شرح زیر باشد:

1

2

3

4

5

6

7

8

9

10

# Allow any user from any host with IP address 192.168.93.x to connect

# to database "postgres" as the same user name that ident reports for

# the connection (typically the operating system user name).

#

# TYPE  DATABASE        USER            ADDRESS                 METHOD

 host     postgres              all             192.168.93.0/24         ident

# Reject any user from any host with IP address 192.168.94.x to connect

# to database "postgres

# TYPE  DATABASE        USER            ADDRESS                 METHOD

 host     postgres              all             192.168.94.0/24         reject

ترکیبات زیادی وجود دارد که می توانید برای اصلاح قوانین انجام دهید (اسناد رسمی هر گزینه را در جزئیات توضیح می دهد و برخی از آن نمونه های بسیار خوبی دارد) ، اما به خاطر داشته باشید که از قوانینی که بیش از حد قابل قبول هستند اجتناب کنید، مانند دسترسی به خطوط با استفاده از DATABASE ALL یا ADDRESS 0.0.0.0/0.

برای اطمینان از امنیت، حتی اگر فراموش کنید که یک قانون را اضافه کنید، می توانید ردیف زیر را در پایین اضافه   کنید

1

2

 # TYPE  DATABASE        USER            ADDRESS                 METHOD

 host     all              all             0.0.0.0/0         reject

بنابراین فایل از بالا به پایین خوانده می شود تا قوانین تطبیق پیدا کند .

2. پیکربندی سرور در چک لیست امنیتی پایگاه داده

برخی از پارامترهای postgresql.conf وجود دارد که ما می توانیم آن را برای افزایش امنیت تغییر دهیم.

شما می توانید از پارامتر call_address برای کنترل ips های مجاز به اتصال به سرور استفاده کنید. یک عمل خوب برای اجازه اتصال فقط از ips های شناخته شده یا شبکه شما است و از مقادیر کلی مانند “*”، “0.0.0.0:0” یا “::” جلوگیری می کند، که PostgreSQL را قادر می سازد تا اتصال را از هر IP دریافت کند.

تغییر پورتی که postgresql گوش می دهد (به طور پیش فرض 5432) نیز یک گزینه است که می توانید این کار را با تغییر مقدار پارامتر پورت انجام دهید.

پارامترهایی مانند work_mem، maintenance_work_mem، temp_buffer، max_prepared_transactions، temp_file_limit برای جلوگیری از حمله منع سرویس مهم هستند. این ها پارامترهای بیانیه و جلسه می باشندکه می توانند در سطوح مختلف (db، user، session) تنظیم شوند، بنابراین مدیریت عاقلانه آنها می تواند به شما برای به حداقل رساندن تاثیر حمله کمک کند.

3. کاربر و مدیریت نقش در چک لیست امنیتی پایگاه داده

قانون طلایی برای امنیت در رابطه با مدیریت کاربر این است که به کاربران حداقل دسترسی لازم را اعطا کند.

مدیریت این امر همیشه آسان نیست و اگر واقعا از ابتدا به خوبی انجام نشود، می تواند واقعا خراب شود.

روش خوب برای حفظ امتیازات تحت کنترل این است که از نقش، گروه و استراتژی کاربر استفاده کنید.

در postgresql همه چیز به عنوان یک نقش در نظر گرفته می شود، اما ما قصد داریم برخی از تغییرات را به این صورت بگیریم.

در این استراتژی شما سه نوع یا نقش مختلف ایجاد می کنید :

  • role role (با پیشوند r_ شناسایی شده است)

  • group role (با پیشوند g_ شناسایی شده است)

  • user role (معمولا نام شخصی یا برنامه)

نقش های (r_ roles) کسانی هستند که دارای امتیازات بر روی اشیا هستند. نقش های گروه (نقش های _g) با نقش های _r اعطا می شوند، بنابراین آنها مجموعه ای از r_ roles هستند. و در نهایت، نقش های کاربر با یک یا چند نقش گروه اعطا می شود  که دارای امتیاز ورود به سیستم هستند.

 نمونه ای از این را نشان می دهیم . ما یک گروه خواندنی فقط برای مثال schema_ ایجاد می کنیم و سپس آن را به یک کاربر ارائه می دهیم:

فقط نقش خواندن را ایجاد می کنیم و امتیازات شی را به آن اعطا می کنیم

1

2

3

4

CREATE ROLE r_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;

GRANT USAGE ON SCHEMA example to r_example_ro;

GRANT SELECT ON ALL TABLES IN SCHEMA example to r_example_ro;

ALTER DEFAULT PRIVILEGES IN SCHEMA example GRANT SELECT ON TABLES TO r_example_ro;

فقط گروه خواندنی را ایجاد می کنیم و نقش آن را به آن گروه می دهیم

1

2

 CREATE ROLE g_example_ro NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION';

GRANT r_example_ro to g_example_ro;

نقش app_user را ایجاد می کنیم و آن را “وارد” گروه فقط خواندنی می کنیم

1

2

3

4

CREATE ROLE app_user WITH LOGIN ;

ALTER ROLE app_user WITH PASSWORD 'somePassword' ;

ALTER ROLE app_user VALID UNTIL 'infinity' ;

GRANT g_example_ro TO app_user;

با استفاده از این روش می توانید اطلاعات دقیقی از امتیازات را مدیریت کنید و به راحتی می توانید گروه هایی از دسترسی را به کاربران را اعطا کنید و یا آنها را لغو کنید. به یاد داشته باشید فقط اعطاء امتیازات به نقش ها به جای انجام آن به طور مستقیم برای کاربران می باشد و اعطای دسترسی مجوز فقط به کاربران است.

این یک عمل خوب است که به صراحت امتیازات عمومی در مورد اشیا را لغو می کند، مانند لغو دسترسی عمومی به یک پایگاه داده خاص که تنها از طریق یک نقش آن را اعطا می کند.

REVOKE CONNECT ON my_database FROM PUBLIC;

GRANT CONNECT ON my_database TO r_example_ro;

محدود کردن دسترسی SUPERUSER و اجازه اتصال سوپر کاربران تنها از دامنه localhost / unix.

استفاده از کاربران خاص برای مقاصد مختلف، مانند برنامه های کاربردی خاص یا کاربران پشتیبان، و محدود کردن اتصالات آن کاربر تنها از ips مورد نیاز.

4. مدیریت سوپر کاربر در چک لیست امنیتی پایگاه داده

سیاست رمز عبور قوی برای حفظ پایگاه داده ها جهت امن بودن و جلوگیری از کلمات عبور ضعیف ضروری است. برای استفاده از سیاست قوی، به ترتیب کاراکترهای خاص، اعداد، کاراکترهای بزرگ و کوچک و حداقل 10 کاراکتر استفاده کنید .

5. رمزگذاری داده (در اتصال TLS) در چک لیست امنیتی پایگاه داده

رمزگذاری داده ها در انتقال برای سرورهای وب و سرورهای ایمیل بسیار حائز اهمیت است. بنابراین باید از  TLS در سرورهای پایگاه داده PostgreSQL استفاده کنید. این باعث می شود که یک سرور SQL در اینترنت کمی امن تر شود.

تنظیمات فایل

/var/lib/pgsql/data/postgresql.conf

ssl = 'on'

ssl_ciphers = 'ECDHE-RSA-AES256-SHA384:AES256-SHA256:HIGH:!RC4:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL'

رمز نگاری ها

ssl_ciphers = 'ECDHE-RSA-AES256-SHA384:AES256-SHA256:HIGH:RC4:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL'

فایل کلید ها

کلید باید در فایل قرار داده شود

/var/lib/pgsql/data/server.key

کلید باید فقط توسط مالک user postgres قابل خواندن باشد

فایل گواهی

گواهی باید در فایل قرار داده شود

/var/lib/pgsql/data/server.crt

6. رمزگذاری داده ها در حالت (Rest (pg_crypto در چک لیست امنیتی پایگاه داده

دو نوع اساسی رمزگذاری، one way  و  two way وجود دارد. اکثرا در مورد رمزگشایی داده ها به شکل قابل خواندن مراقبت نمی کنند  و فقط می خواهند مطمئن شوند که کاربر کد مخفی پایه را می داند .

این متد به طور معمول برای کلمات عبور استفاده می شود. در رمزنگاری دوطرفه، می خواهید توانایی رمزگذاری داده ها را داشته باشید و همچنین اجازه دهید که کاربران مجاز رمزگشایی آن را به فرم معنی دار تبدیل کنند. داده هایی مانند کارت های اعتباری و SSN ها در این دسته قرار دارند.

برای رمزنگاری one way ، تابع رمزنگاری که در pgcrypto بسته بندی شده است، سطح امنیت بالاتری نسبت به MD5 فراهم می کند.

دلیل این امر این است که با md5 می توانید بگویید کدام یک رمز عبور مشابه دارد زیرا هیچ salt وجود ندارد (در رمزنگاری، salt بک داده تصادفی است که به عنوان یک ورودی اضافی برای عملکرد یک طرفه داده های “هش”، استفاده می شود.)، بنابراین همه افرادی که با یک رمز عبور مشابه هستند ، یک رشته md5 کد گذاری شده مشترک دارند. با crypt ، رمز های آنها متفاوت خواهد شد .

ممکن است برای داده هایی که برای بازیابی شما اهمیت دارد، نخواهید بدانید که دو قسمت اطلاعات یکسان هستند، اما شما این اطلاعات را نمی دانید و می خواهید فقط کاربران مجاز قادر به بازیابی آن باشند. بنابراین Pgcrypto روش های متعددی برای انجام این کار فراهم می کند،

ماژول pgcrypto توابع رمزنگاری را برای PostgreSQL فراهم می کند. برای مشاهده ساختار این ماژول به صفحه رسمی زیر مراجعه کنید

www.postgresql.org

7. ثبت نام

Postgresql  طیف وسیعی از پارامترهای پیکربندی را برای کنترل زمان و مکان ورود فراهم می کند.

همچنین می توانید اتصال به جلسه و قطع ارتباط، نمایش داده های طولانی مدت، اندازه فایل های temp و غیره را فعال کنید. این می تواند به شما در دریافت اطلاعات بهتر در مورد حجم کار کمک کند تا رفتارهای فردی را شناسایی کنید. شما می توانید تمام گزینه های ورود به سیستم را در لینک زیر دریافت کنید

https://www.postgresql.org/docs/9.6/static/runtime-config-logging.html

برای اطلاعات بیشتر در مورد حجم کار تان ، می توانید ماژول pg_stat_statements را فعال کنید، که ابزار را برای ردیابی آمار اجرای تمام دستورات SQL اجرا شده توسط سرور فراهم می کند. برخی از ابزارهای امنیتی وجود دارد که می تواند داده ها را از این جدول بیرون بیاورد و یک لیست سفارشی sql ایجاد خواهد کرد تا شما را قادر به شناسایی پرس و جو هایی که الگوهای مورد انتظار را دنبال نمی کنند باشید.

برای اطلاعات بیشتر

 https://www.postgresql.org/docs/9.6/static/pgstatstatements.html.

8. حسابرسی و ممیزی

توسعه ممیزی PostgreSQL یا (pgAudit) از طریق ورودی استاندارد PostgreSQL، امکان ثبت لاگ های ورود به سیستم را فراهم می کند. شرح لاگ ها را می توان با استفاده از تابع logging استاندارد با log_statement = all ارائه کرد.

این روش برای نظارت و استفاده های دیگر قابل قبول است اما سطح جزئیات مورد نیاز برای ممیزی را فراهم نمی کند. داشتن فهرستی از تمام عملیات انجام شده علیه پایگاه داده کافی نیست و ممکن است برای پیدا کردن موارد خاصی که برای ممیزی مورد توجه قرار گیرند دچار اشکال شویم .

تسهیلات ورود به سیستم استاندارد نشان می دهد که کاربر چه درخواستی کرده است، در حالی که pgAudit روی جزئیات وقایع زمانی که بانک اطلاعاتی را رد درخواست می کند، تمرکز می کند.

9. پچ کردن

صفحه اطلاعات امنیتی PostgreSQL به طور منظم و اغلب برای به روز رسانی و وصله های امنیتی بحرانی باید به طور مداوم بررسی شود . در نظر داشته باشید که اشکالات امنیتی سیستم عامل و یا کتابخانه ها می تواند نشت اطلاعات پایگاه داده را نیز داشته باشد، بنابراین از پچ بودن اطمینان حاصل کنید .

ClusterControl  گزارش عملیاتی را ارائه می دهد که به شما این اطلاعات را می دهد و وصله ها و به روز رسانی ها را برای شما اجرا می کند.

10.دانستن روال کاری خود (pg_stats_statement)

علاوه بر سیستم امتیاز استاندارد SQL که از طریق GRANT موجود است،

جداول می توانند خط مشی های امنیتی ردیفی را که بر اساس هر کاربر محدود می شوند، توسط ردیف های معمولی نمایش بدهند یا دستورات تغییر داده را وارد ، به روز و یا حذف کنند . این ویژگی همچنین به عنوان Level-Level Security شناخته می شود.

وقتی امنیت سطر روی یک جدول فعال می شود ، دسترسی کلی به جدول برای انتخاب سطر ها یا اصلاح سطر ها باید با یک سیاست امنیتی سطر مجاز باشد.

در اینجا یک مثال ساده برای ایجاد یک سیاست در رابطه با حساب وجود دارد که اجازه می دهد فقط اعضای مدیران دسترسی به سطرها و فقط ردیف حسابهایشان دسترسی داشته باشند:

1

2

3

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);

برای اطلاعات بیشتری در مورد این ویژگی در مستندات postgresql جستجو کنید .

https://www.postgresql.org/docs/9.6/static/ddl-rowsecurity.html

همچنین می توانید از چک لیست های امنیتی دیگر وب ساید بازدید بفرمایید

نتیجه

اگر نکات گفته شده در سرور را با دقت دنبال کنید نسبتا امن تر خواهید بود ،و دقت کنید این بدان معنی نیست که کارایی و سهولت استفاده سرور افت خواهد کرد

برای امنیت بیشتر توصیه می شود از یک ابزار تست امنیتی مانند Nessus یا با تست دستی مبتنی بر دانش فردی برای شناخت آسیب پذیری های اصلی خود استفاده کنید و سعی کنید آنها را حل کنید.

همچنین می توانید پایگاه داده خود را با ClusterControl نظارت کنید. با این کار می توانید در زمان واقعی آنچه که در پایگاه داده های خود اتفاق می افتد را مشاهده کنید و آن را تجزیه و تحلیل کنید.

 

دیدگاه شما:

نوشته های مرتبط