نام من دنیس روژکوف است، من رئیس توسعه نرم افزار در شرکت Gazinformservice در تیم محصول هستم. جاتوبا. قوانین و مقررات شرکتی الزامات خاصی را برای امنیت ذخیره سازی داده ها تحمیل می کند. هیچ کس نمی خواهد اشخاص ثالث به اطلاعات محرمانه دسترسی داشته باشند، بنابراین مسائل زیر برای هر پروژه مهم است: شناسایی و احراز هویت، مدیریت دسترسی به داده ها، اطمینان از یکپارچگی اطلاعات در سیستم، ثبت رویدادهای امنیتی. بنابراین، من می خواهم در مورد چند نکته جالب در مورد امنیت DBMS صحبت کنم.

مقاله بر اساس سخنرانی در @DatabasesMeetup، سازماندهی شده است Mail.ru Cloud Solutions. اگر نمی خواهید بخوانید، می توانید تماشا کنید:

مقاله دارای سه بخش خواهد بود:

• نحوه ایمن سازی اتصالات
• ممیزی از اقدامات چیست و چگونه می توان آنچه را که در سمت پایگاه داده اتفاق می افتد و اتصال به آن ثبت کرد.
• نحوه محافظت از داده ها در خود پایگاه داده و چه فناوری هایی برای این کار موجود است.

سه جزء امنیت DBMS: حفاظت از اتصال، ممیزی فعالیت و حفاظت از داده ها

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

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

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

• آیا یک کاربر تجاری معادل یک کاربر DBMS است؟
• آیا دسترسی به داده‌های DBMS فقط از طریق یک API که شما کنترل می‌کنید ارائه می‌شود یا اینکه آیا جداول مستقیماً قابل دسترسی هستند.
• آیا DBMS به یک بخش محافظت شده جداگانه اختصاص داده شده است، چه کسی و چگونه با آن تعامل دارد.
• آیا از لایه‌های ادغام/پراکسی و میانی استفاده می‌شود، که می‌تواند اطلاعات مربوط به نحوه ایجاد اتصال و استفاده از پایگاه داده را تغییر دهد.

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

1. از راه حل های کلاس فایروال پایگاه داده استفاده کنید. یک لایه حفاظتی اضافی، حداقل، شفافیت آنچه را که در DBMS اتفاق می‌افتد، افزایش می‌دهد و حداکثر، می‌توانید محافظت بیشتری از داده‌ها ارائه دهید.
2. از سیاست های رمز عبور استفاده کنید. استفاده از آنها بستگی به نحوه ساخت معماری شما دارد. در هر صورت یک رمز عبور در فایل پیکربندی یک برنامه وب که به DBMS متصل می شود برای محافظت کافی نیست. تعدادی ابزار DBMS وجود دارد که به شما امکان می دهد کنترل کنید که کاربر و رمز عبور نیاز به به روز رسانی داشته باشند.

   می‌توانید درباره عملکردهای رتبه‌بندی کاربر بیشتر بخوانید اینجا، همچنین می توانید درباره MS SQL Vulnerability Assessmen اطلاعات کسب کنید اینجا. 

3. زمینه جلسه را با اطلاعات لازم غنی کنید. اگر جلسه غیرشفاف باشد، متوجه نمی شوید چه کسی در چارچوب آن در DBMS کار می کند، می توانید در چارچوب عملیاتی که انجام می شود، اطلاعاتی در مورد اینکه چه کسی و چرا انجام می دهد اضافه کنید. این اطلاعات را می توان در حسابرسی مشاهده کرد.
4. اگر جداسازی شبکه بین DBMS و کاربران نهایی ندارید، SSL را در یک VLAN جداگانه پیکربندی کنید. در چنین مواردی، حفاظت از کانال بین مصرف کننده و خود DBMS ضروری است. ابزارهای امنیتی نیز به صورت متن باز موجود هستند.

این چگونه بر عملکرد DBMS تأثیر می گذارد؟

بیایید به مثال PostgreSQL نگاه کنیم تا ببینیم SSL چگونه بر بار CPU تأثیر می گذارد، زمان بندی را افزایش می دهد و TPS را کاهش می دهد و آیا اگر آن را فعال کنید، منابع زیادی مصرف می کند.

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

تست 1 بدون SSL و با استفاده از SSL - اتصال برای هر تراکنش برقرار می شود:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

تست 2 بدون SSL و با استفاده از SSL - همه تراکنش ها در یک اتصال انجام می شود:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

vs

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

تنظیمات دیگر:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

نتایج آزمون:

 
بدون SSL
SSL

برای هر تراکنش یک اتصال برقرار می شود

میانگین تاخیر
MS 171.915
MS 187.695

tps شامل برقراری اتصالات
58.168112
53.278062

tps به استثنای اتصالات ایجاد شده
64.084546
58.725846

پردازنده
٪۱۰۰
٪۱۰۰

تمام تراکنش ها در یک اتصال انجام می شود

میانگین تاخیر
MS 6.722
MS 6.342

tps از جمله برقراری اتصالات
1587.657278
1576.792883

tps به استثنای اتصالات ایجاد شده
1588.380574
1577.694766

پردازنده
٪۱۰۰
٪۱۰۰

در بارهای سبک، تأثیر SSL با خطای اندازه گیری قابل مقایسه است. اگر مقدار داده های منتقل شده بسیار زیاد باشد، وضعیت ممکن است متفاوت باشد. اگر در هر تراکنش یک اتصال برقرار کنیم (این نادر است، معمولاً اتصال بین کاربران به اشتراک گذاشته می شود)، تعداد اتصالات/قطعات زیادی دارید، ممکن است تأثیر آن کمی بیشتر باشد. یعنی ممکن است خطرات کاهش عملکرد وجود داشته باشد، با این حال، تفاوت آنقدر بزرگ نیست که از محافظت استفاده نکنید.

لطفاً توجه داشته باشید که اگر حالت‌های عملیاتی را مقایسه کنید تفاوت شدیدی وجود دارد: شما در یک جلسه یا در جلسات مختلف کار می‌کنید. این قابل درک است: منابع صرف ایجاد هر اتصال می شود.

موردی داشتیم که Zabbix را در حالت Trust وصل کردیم، یعنی md5 چک نشد، نیازی به احراز هویت نبود. سپس مشتری درخواست کرد تا حالت احراز هویت md5 را فعال کند. این بار سنگینی را بر روی CPU وارد کرد و عملکرد آن کاهش یافت. ما شروع به جستجوی راه هایی برای بهینه سازی کردیم. یکی از راه حل های ممکن برای حل این مشکل، اجرای یک محدودیت شبکه، ایجاد VLAN های جداگانه برای DBMS، افزودن تنظیمات برای مشخص کردن اینکه چه کسی از کجا وصل می شود و حذف احراز هویت است. همچنین می توانید تنظیمات احراز هویت را برای کاهش هزینه ها هنگام فعال کردن احراز هویت بهینه کنید. ، اما به طور کلی استفاده از روش های مختلف احراز هویت بر عملکرد تأثیر می گذارد و نیاز به در نظر گرفتن این عوامل در هنگام طراحی قدرت محاسباتی سرورها (سخت افزار) برای DBMS دارد.

نتیجه‌گیری: در تعدادی از راه‌حل‌ها، حتی تفاوت‌های کوچک در احراز هویت می‌تواند تأثیر زیادی بر پروژه بگذارد و بد است که این موضوع تنها زمانی که در تولید اجرا شود مشخص شود.

حسابرسی اقدام

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

در DBMS های سطح سازمانی تجاری همه چیز با ممیزی خوب است، اما در منبع باز - نه همیشه. در اینجا چیزی است که PostgreSQL دارد:

• ورود پیش فرض - ورود به سیستم داخلی؛
• پسوندها: pgaudit - اگر ورود به سیستم پیش فرض برای شما کافی نیست، می توانید از تنظیمات جداگانه ای استفاده کنید که برخی از مشکلات را حل می کند.

ضمیمه گزارش در ویدئو:

"گزارش اولیه بیانیه را می توان توسط یک تسهیلات گزارش استاندارد با log_statement = all ارائه کرد.

این برای نظارت و سایر کاربردها قابل قبول است، اما سطح جزئیاتی که معمولاً برای حسابرسی مورد نیاز است را ارائه نمی دهد.

داشتن لیستی از تمام عملیات انجام شده در پایگاه داده کافی نیست.

همچنین باید بتوان اظهارات خاصی را یافت که مورد علاقه حسابرس است.

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

برای مثال، حسابرس ممکن است بخواهد بررسی کند که یک جدول خاص در یک پنجره نگهداری مستند ایجاد شده است.

ممکن است این یک کار ساده با حسابرسی و grep اولیه به نظر برسد، اما اگر مثالی شبیه به این (عمداً گیج کننده) به شما ارائه شود چه می شود:

DO$$
شروع
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

ثبت استاندارد به شما این را می دهد:

LOG: بیانیه: DO $$
شروع
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

به نظر می رسد که یافتن جدول مورد نظر ممکن است به دانش کد در مواردی که جداول به صورت پویا ایجاد می شوند نیاز داشته باشد.

این ایده آل نیست، زیرا ترجیح داده می شود به سادگی بر اساس نام جدول جستجو کنید.

اینجاست که pgAudit به کار می آید.

برای همان ورودی، این خروجی را در گزارش تولید می کند:

حسابرسی: SESSION,33,1,FUNCTION,DO,,,Do $$
شروع
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

نه تنها بلوک DO ثبت می شود، بلکه متن کامل CREATE TABLE با نوع عبارت، نوع شی و نام کامل نیز ثبت می شود که جستجو را آسان تر می کند.

هنگام ثبت دستورات SELECT و DML، pgAudit را می توان پیکربندی کرد تا یک ورودی جداگانه برای هر رابطه ارجاع شده در بیانیه ثبت کند.

برای یافتن تمام عباراتی که یک جدول خاص را لمس می کنند، نیازی به تجزیه نیست.*) »

این چگونه بر عملکرد DBMS تأثیر می گذارد؟

بیایید تست ها را با فعال بودن ممیزی کامل اجرا کنیم و ببینیم چه اتفاقی برای عملکرد PostgreSQL می افتد. بیایید حداکثر ثبت پایگاه داده را برای همه پارامترها فعال کنیم.

ما تقریباً هیچ چیز را در فایل پیکربندی تغییر نمی دهیم، مهمترین چیز این است که حالت debug5 را روشن کنید تا حداکثر اطلاعات را به دست آورید.

postgresql.conf

log_destination = 'stderr'
logging_collector = روشن
log_truncate_on_rotation = روشن
log_rotation_age = 1d
log_rotation_size = 10 مگابایت
log_min_messages = اشکال زدایی 5
log_min_error_statement = اشکال زدایی 5
log_min_duration_statement = 0
debug_print_parse = روشن است
debug_print_rewritten = روشن
debug_print_plan = روشن است
debug_pretty_print = روشن
log_checkpoints = روشن
log_connections = روشن
log_disconnections = روشن
log_duration = روشن است
log_hostname = روشن
log_lock_wait = روشن است
log_replication_commands = روشن است
log_temp_files = 0
log_timezone = 'اروپا/مسکو'

در یک DBMS PostgreSQL با پارامترهای 1 CPU، 2,8 گیگاهرتز، 2 گیگابایت رم، 40 گیگابایت هارد دیسک، با استفاده از دستورات، سه آزمایش بارگذاری انجام می دهیم:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

نتایج آزمون:

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

کل زمان پر شدن پایگاه داده
43,74 ثانیه
53,23 ثانیه

رم
٪۱۰۰
٪۱۰۰

پردازنده
٪۱۰۰
٪۱۰۰

تست 1 (50 اتصال)

تعداد تراکنش ها در 10 دقیقه
74169
32445

معاملات / ثانیه
123
54

تأخیر متوسط
405 ms
925 ms

تست 2 (150 اتصال با 100 اتصال ممکن)

تعداد تراکنش ها در 10 دقیقه
81727
31429

معاملات / ثانیه
136
52

تأخیر متوسط
550 ms
1432 ms

در مورد اندازه ها

اندازه DB
2251 MB
2262 MB

اندازه گزارش پایگاه داده
0 مگابایت
4587 مگابایت

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

بیایید به پارامترهای دیگر نگاه کنیم:

• سرعت تغییر زیادی نمی کند: بدون ورود به سیستم - 43,74 ثانیه، با ورود به سیستم - 53,23 ثانیه.
• عملکرد RAM و CPU آسیب می بیند، زیرا باید یک فایل ممیزی ایجاد کنید. این در بهره وری نیز قابل توجه است.

با افزایش تعداد اتصالات، به طور طبیعی، عملکرد کمی بدتر می شود.

در شرکت های دارای حسابرسی حتی دشوارتر است:

• داده های زیادی وجود دارد؛
• ممیزی نه تنها از طریق syslog در SIEM، بلکه در فایل‌ها نیز مورد نیاز است: اگر اتفاقی برای syslog بیفتد، باید فایلی نزدیک به پایگاه داده وجود داشته باشد که داده‌ها در آن ذخیره می‌شوند.
• یک قفسه جداگانه برای ممیزی مورد نیاز است تا دیسک های ورودی/خروجی هدر نرود، زیرا فضای زیادی را اشغال می کند.
• این اتفاق می افتد که کارکنان امنیت اطلاعات در همه جا به استانداردهای GOST نیاز دارند، آنها نیاز به شناسایی ایالت دارند.

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

بیایید به فناوری هایی که برای محافظت از داده ها و دسترسی به آن در DBMS های تجاری و منبع باز استفاده می شود نگاه کنیم.

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

1. رمزگذاری و مبهم سازی رویه ها و توابع (Wrapping) - یعنی ابزارها و ابزارهای مجزا که کدهای قابل خواندن را ناخوانا می کنند. درست است، پس نه می توان آن را تغییر داد و نه می توان آن را بازگرداند. این رویکرد گاهی اوقات حداقل در سمت DBMS مورد نیاز است - منطق محدودیت های مجوز یا منطق مجوز دقیقاً در سطح رویه و عملکرد رمزگذاری می شود.
2. محدود کردن دید داده‌ها بر اساس ردیف‌ها (RLS) زمانی است که کاربران مختلف یک جدول را می‌بینند، اما ترکیب متفاوتی از ردیف‌ها در آن وجود دارد، یعنی چیزی در سطح ردیف به کسی نشان داده نمی‌شود.
3. ویرایش داده های نمایش داده شده (Masking) زمانی است که کاربران در یک ستون جدول یا داده ها یا فقط ستاره ها را می بینند، یعنی برای برخی از کاربران اطلاعات بسته می شود. این فناوری تعیین می کند که کدام کاربر بر اساس سطح دسترسی آنها چه چیزی نشان داده شود.
4. امنیت DBA/Application کنترل دسترسی DBA/DBA به جای محدود کردن دسترسی به خود DBMS است، یعنی کارکنان امنیت اطلاعات را می توان از مدیران پایگاه داده و مدیران برنامه جدا کرد. چنین فناوری‌هایی در منبع باز کم وجود دارد، اما تعداد زیادی از آنها در DBMS‌های تجاری وجود دارد. آنها زمانی مورد نیاز هستند که کاربران زیادی به سرورها دسترسی داشته باشند.
5. محدود کردن دسترسی به فایل ها در سطح سیستم فایل. شما می توانید به دایرکتوری ها حقوق و امتیازات دسترسی بدهید تا هر مدیر فقط به داده های لازم دسترسی داشته باشد.
6. دسترسی اجباری و پاک کردن حافظه - این فناوری ها به ندرت مورد استفاده قرار می گیرند.
7. رمزگذاری انتها به انتها مستقیماً از DBMS رمزگذاری سمت مشتری با مدیریت کلید در سمت سرور است.
8. رمزگذاری داده ها. به عنوان مثال، رمزگذاری ستونی زمانی است که از مکانیزمی استفاده می کنید که یک ستون واحد از پایگاه داده را رمزگذاری می کند.

این چگونه بر عملکرد DBMS تأثیر می گذارد؟

بیایید به مثال رمزگذاری ستونی در PostgreSQL نگاه کنیم. یک ماژول pgcrypto وجود دارد که به شما امکان می دهد فیلدهای انتخاب شده را به صورت رمزگذاری شده ذخیره کنید. این زمانی مفید است که فقط برخی از داده ها ارزشمند باشند. برای خواندن فیلدهای رمزگذاری شده، کلاینت یک کلید رمزگشایی را ارسال می کند، سرور داده ها را رمزگشایی کرده و به مشتری برمی گرداند. بدون کلید، هیچ کس نمی تواند با داده های شما کاری انجام دهد.

بیایید با pgcrypto تست کنیم. بیایید یک جدول با داده های رمزگذاری شده و داده های معمولی ایجاد کنیم. در زیر دستورات ایجاد جداول وجود دارد، در همان خط اول یک دستور مفید وجود دارد - ایجاد پسوند خود با ثبت DBMS:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

در مرحله بعد، بیایید سعی کنیم از هر جدول یک نمونه داده تهیه کنیم و به زمان بندی اجرا نگاه کنیم.

انتخاب از جدول بدون عملکرد رمزگذاری:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

کرونومتر روشن است.

  شناسه | text1 | متن 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 خط)

زمان: 1,386 میلی‌ثانیه

انتخاب از یک جدول با تابع رمزگذاری:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

کرونومتر روشن است.

  شناسه | رمزگشایی | رمزگشایی
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 خط)

زمان: 50,203 میلی‌ثانیه

نتایج آزمون:

 
بدون رمزگذاری
Pgcrypto (رمزگشایی)

نمونه 1000 ردیف
1,386 ms
50,203 ms

پردازنده
٪۱۰۰
٪۱۰۰

رم
 
+ 5٪

رمزگذاری تاثیر زیادی بر عملکرد دارد. می توان دید که زمان افزایش یافته است، زیرا عملیات رمزگشایی داده های رمزگذاری شده (و رمزگشایی معمولاً هنوز در منطق شما پیچیده می شود) به منابع قابل توجهی نیاز دارد. یعنی ایده رمزگذاری تمام ستون های حاوی برخی داده ها مملو از کاهش عملکرد است.

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

وقتی یک کلید برای کل ستون برای همه کاربران وجود دارد (حتی اگر نه برای همه، اما برای مشتریان یک مجموعه محدود)، این همیشه خوب و صحیح نیست. به همین دلیل است که آنها شروع به رمزگذاری انتها به انتها کردند، در DBMS آنها شروع به در نظر گرفتن گزینه هایی برای رمزگذاری داده ها در سمت مشتری و سرور کردند، و همان ذخیره سازی های ذخیره سازی کلید - محصولات جداگانه ای که مدیریت کلید را در DBMS ارائه می دهند، ظاهر شدند. سمت.

نمونه ای از این رمزگذاری در MongoDB

ویژگی های امنیتی در DBMS های تجاری و منبع باز

توابع
نوع
خط مشی رمز عبور
ممیزی
حفاظت از کد منبع رویه ها و توابع
RLS
رمزگذاری

وحی
تجاری
+
+
+
+
+

MsSql
تجاری
+
+
+
+
+

جاتوبا
تجاری
+
+
+
+
ضمیمهها

PostgreSQL و
رایگان
ضمیمهها
ضمیمهها
-
+
ضمیمهها

MongoDb
رایگان
-
+
-
-
فقط در MongoDB Enterprise موجود است

جدول هنوز کامل نیست، اما وضعیت این است: در محصولات تجاری، مشکلات امنیتی برای مدت طولانی حل شده است، در منبع باز، به عنوان یک قاعده، نوعی افزودنی برای امنیت استفاده می شود، بسیاری از توابع از دست رفته است. ، گاهی اوقات باید چیزی اضافه کنید. به عنوان مثال، سیاست های رمز عبور - PostgreSQL دارای پسوندهای مختلف (1, 2, 3, 4, 5) که سیاست های رمز عبور را پیاده سازی می کنند، اما، به نظر من، هیچ یک از آنها تمام نیازهای بخش شرکت های داخلی را پوشش نمی دهد.

اگر چیزی را که در جایی لازم دارید ندارید، چه باید بکنید? به عنوان مثال، شما می خواهید از یک DBMS خاصی استفاده کنید که عملکردهای مورد نیاز مشتری را ندارد.

سپس می توانید از راه حل های شخص ثالث استفاده کنید که با DBMS های مختلف کار می کنند، به عنوان مثال، Crypto DB یا Garda DB. اگر ما در مورد راه حل هایی از بخش داخلی صحبت می کنیم ، آنها بهتر از GOST ها نسبت به منبع باز می دانند.

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

این گزارش برای اولین بار در @Databases Meetup توسط Mail.ru Cloud Solutions. نگاه کن تصویری اجراهای دیگر و مشترک شدن در اطلاعیه رویدادها در تلگرام در اطراف Kubernetes در Mail.ru Group.

چه چیز دیگری در مورد موضوع بخوانید:

1. بیشتر از Ceph: ذخیره سازی بلوک ابری MCS.
2. چگونه یک پایگاه داده برای یک پروژه انتخاب کنید تا مجبور نباشید دوباره انتخاب کنید.

منبع: www.habr.com