שמי דניס רוז'קוב, אני ראש פיתוח תוכנה בחברת Gazinformservice, בצוות המוצר ג'טובה. חקיקה ותקנות תאגיד מטילות דרישות מסוימות לאבטחת אחסון הנתונים. אף אחד לא רוצה שצדדים שלישיים יקבלו גישה למידע סודי, ולכן הנושאים הבאים חשובים לכל פרויקט: זיהוי ואימות, ניהול גישה לנתונים, הבטחת שלמות המידע במערכת, רישום אירועי אבטחה. לכן, אני רוצה לדבר על כמה נקודות מעניינות לגבי אבטחת DBMS.

המאמר הוכן על סמך נאום בשעה @DatabasesMeetup, מְאוּרגָן פתרונות ענן של Mail.ru. אם אתה לא רוצה לקרוא, אתה יכול לראות:

המאמר יכלול שלושה חלקים:

• כיצד לאבטח חיבורים.
• מהי ביקורת פעולות ואיך מתעדים מה קורה בצד בסיס הנתונים ומתחברים אליו.
• כיצד להגן על הנתונים במסד הנתונים עצמו ואילו טכנולוגיות זמינות לכך.

שלושה מרכיבים של אבטחת DBMS: הגנת חיבור, ביקורת פעילות והגנה על נתונים

אבטחת הקשרים שלך

אתה יכול להתחבר למסד הנתונים באופן ישיר או עקיף באמצעות יישומי אינטרנט. ככלל, המשתמש העסקי, כלומר האדם שעובד עם ה-DBMS, מקיים איתו אינטראקציה בעקיפין.

לפני שמדברים על הגנה על קשרים, עליך לענות על שאלות חשובות שקובעות כיצד יבנו אמצעי אבטחה:

• האם משתמש עסקי אחד שווה ערך למשתמש DBMS אחד?
• האם הגישה לנתוני DBMS מסופקת רק דרך API שאתה שולט בו, או אם יש גישה לטבלאות ישירות;
• האם ה-DBMS מוקצה למקטע מוגן נפרד, מי מתקשר איתו וכיצד;
• האם נעשה שימוש בשכבות מאגר/פרוקסי ושכבות ביניים, שיכולות לשנות מידע על אופן בניית החיבור ומי משתמש במסד הנתונים.

עכשיו בואו נראה באילו כלים ניתן להשתמש כדי לאבטח חיבורים:

1. השתמש בפתרונות כיתת חומת אש של מסד נתונים. שכבת הגנה נוספת תגביר, לכל הפחות, את השקיפות של המתרחש ב-DBMS, ובמקסימום תוכל לספק הגנה נוספת על מידע.
2. השתמש במדיניות סיסמאות. השימוש בהם תלוי באופן שבו הארכיטקטורה שלך נבנית. בכל מקרה, סיסמה אחת בקובץ התצורה של אפליקציית אינטרנט שמתחברת ל-DBMS אינה מספיקה להגנה. ישנם מספר כלי DBMS המאפשרים לך לשלוט בכך שהמשתמש והסיסמה דורשים עדכון.

   אתה יכול לקרוא עוד על פונקציות דירוג משתמשים כאן, תוכל גם לברר על MS SQL Vulnerability Assessmen כאן. 

3. להעשיר את ההקשר של הפגישה במידע הדרוש. אם הפגישה אטומה, אינכם מבינים מי עובד ב-DBMS במסגרתו, ניתן במסגרת הפעולה המתבצעת להוסיף מידע מי עושה מה ולמה. מידע זה ניתן לראות בביקורת.
4. הגדר SSL אם אין לך הפרדת רשת בין ה-DBMS למשתמשי הקצה; זה לא ב-VLAN נפרד. במקרים כאלה, חובה להגן על הערוץ בין הצרכן ל-DBMS עצמו. כלי אבטחה זמינים גם בקוד פתוח.

כיצד זה ישפיע על הביצועים של ה-DBMS?

הבה נסתכל על הדוגמה של PostgreSQL כדי לראות כיצד SSL ​​משפיע על עומס המעבד, מגדיל תזמונים ומפחית 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

נוצר חיבור לכל עסקה

ממוצע השהיה
171.915 ms
187.695 ms

tps כולל יצירת קשרים
58.168112
53.278062

tps לא כולל יצירת חיבורים
64.084546
58.725846

CPU
24%
28%

כל העסקאות מבוצעות בחיבור אחד

ממוצע השהיה
6.722 ms
6.342 ms

tps כולל יצירת קשרים
1587.657278
1576.792883

tps לא כולל יצירת חיבורים
1588.380574
1577.694766

CPU
17%
21%

בעומסים קלים, ההשפעה של SSL דומה לשגיאת המדידה. אם כמות הנתונים המועברים גדולה מאוד, המצב עשוי להיות שונה. אם ניצור חיבור אחד לכל עסקה (זה נדיר, בדרך כלל החיבור משותף בין המשתמשים), יש לך מספר רב של חיבורים/ניתוקים, ההשפעה עשויה להיות קצת יותר גדולה. כלומר, ייתכנו סיכונים לירידה בביצועים, עם זאת, ההבדל אינו כה גדול עד לא שימוש בהגנה.

שים לב שיש הבדל גדול אם אתה משווה את מצבי הפעולה: אתה עובד באותה סשן או במצבים שונים. זה מובן: משאבים מושקעים ביצירת כל חיבור.

היה לנו מקרה כשחיברנו את Zabbix במצב trust, כלומר, md5 לא נבדק, לא היה צורך באימות. לאחר מכן ביקש הלקוח להפעיל מצב אימות md5. זה הכניס עומס רב על המעבד והביצועים ירדו. התחלנו לחפש דרכים לייעל. אחד הפתרונות האפשריים לבעיה הוא הטמעת הגבלות רשת, יצירת VLAN נפרדים עבור ה-DBMS, הוספת הגדרות כדי להבהיר מי מתחבר מאיפה ולהסיר אימות. ניתן גם לייעל את הגדרות האימות כדי להפחית עלויות בעת הפעלת האימות, אך באופן כללי השימוש בשיטות שונות אימות משפיע על הביצועים ודורש לקחת בחשבון את הגורמים הללו בעת תכנון כוח המחשוב של שרתים (חומרה) עבור ה-DBMS.

מסקנה: במספר פתרונות, אפילו ניואנסים קטנים באימות יכולים להשפיע מאוד על הפרויקט וזה רע כאשר זה מתברר רק כאשר מיושם בייצור.

ביקורת פעולה

ביקורת יכולה להיות לא רק DBMS. ביקורת עוסקת בהשגת מידע על המתרחש במגזרים שונים. זו יכולה להיות חומת אש של מסד נתונים או מערכת ההפעלה שעליה בנוי ה-DBMS.

ב-DBMS ברמת Enterprise הכול בסדר עם ביקורת, אבל בקוד פתוח - לא תמיד. הנה מה שיש ל-PostgreSQL:

• יומן ברירת מחדל - רישום מובנה;
• הרחבות: pgaudit - אם רישום ברירת המחדל אינו מספיק עבורך, תוכל להשתמש בהגדרות נפרדות שפותרות חלק מהבעיות.

תוספת לדיווח בסרטון:

"רישום הצהרות בסיסי יכול להינתן על ידי מתקן רישום סטנדרטי עם log_statement = all.

זה מקובל לניטור ולשימושים אחרים, אך אינו מספק את רמת הפירוט הנדרשת בדרך כלל לביקורת.

לא מספיק שיש רשימה של כל הפעולות שבוצעו במסד הנתונים.

כמו כן, צריך להיות אפשרי למצוא הצהרות ספציפיות שמעניין את רואה החשבון המבקר.

רישום רגיל מציג את מה שהמשתמש ביקש, בעוד pgAudit מתמקד בפרטים של מה שקרה כאשר מסד הנתונים ביצע את השאילתה.

לדוגמה, המבקר עשוי לרצות לוודא כי טבלה מסוימת נוצרה בתוך חלון תחזוקה מתועד.

זו אולי נראית כמו משימה פשוטה עם אודיטינג ו-grep בסיסיים, אבל מה אם יוצג לך משהו כזה (מבלבל בכוונה) הדוגמה הזו:

עשה $$
התחל
בצע 'ייבוא ​​יצירת טבלה' || 'ant_table(id int)';
END$$;

רישום רגיל ייתן לך את זה:

LOG: הצהרה: DO $$
התחל
בצע 'ייבוא ​​יצירת טבלה' || 'ant_table(id int)';
END$$;

נראה כי מציאת טבלת העניין עשויה לדרוש ידע מסוים בקוד במקרים בהם טבלאות נוצרות באופן דינמי.

זה לא אידיאלי, מכיוון שעדיף פשוט לחפש לפי שם טבלה.

זה המקום שבו pgAudit שימושי.

עבור אותו קלט, הוא יפיק את הפלט הזה ביומן:

ביקורת: SESSION,33,1,FUNCTION,DO,,,"DO $$
התחל
בצע 'ייבוא ​​יצירת טבלה' || 'ant_table(id int)';
END$$;"
ביקורת: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE חשוב_טבלה (מזהה 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 = 10MB
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_waits = פועל
log_replication_commands = פועל
log_temp_files = 0
log_timezone = 'אירופה/מוסקבה'

ב-PostgreSQL DBMS עם פרמטרים של מעבד 1, 2,8 GHz, 2 GB RAM, 40 GB HDD, אנו עורכים שלוש בדיקות עומס באמצעות הפקודות:

$ 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 שניות

רם
24%
40%

CPU
72%
91%

בדיקה 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 מגה בייט
2262 מגה בייט

גודל יומן מסד נתונים
0 MB
4587 MB

בשורה התחתונה: ביקורת מלאה אינה טובה במיוחד. הנתונים מהביקורת יהיו גדולים כמו הנתונים במאגר עצמו, או אפילו יותר. כמות הרישום שנוצרת בעבודה עם DBMS היא בעיה נפוצה בייצור.

בואו נסתכל על פרמטרים אחרים:

• המהירות לא משתנה הרבה: ללא רישום - 43,74 שניות, עם רישום - 53,23 שניות.
• ביצועי זיכרון RAM ומעבד ייפגעו, מכיוון שאתה צריך ליצור קובץ ביקורת. זה מורגש גם בפרודוקטיביות.

ככל שמספר החיבורים יגדל, באופן טבעי, הביצועים יידרדרו מעט.

בתאגידים עם ביקורת זה אפילו יותר קשה:

• יש הרבה נתונים;
• יש צורך בביקורת לא רק דרך syslog ב-SIEM, אלא גם בקבצים: אם משהו קורה ל-syslog, חייב להיות קובץ קרוב למסד הנתונים שבו הנתונים נשמרים;
• הביקורת דורשת מדף נפרד כדי לא לבזבז דיסקי קלט/פלט, מכיוון שהוא תופס הרבה מקום;
• קורה שעובדי אבטחת מידע צריכים תקני GOST בכל מקום, הם דורשים זיהוי מדינה.

הגבלת גישה לנתונים

בואו נסתכל על הטכנולוגיות המשמשות להגנה על נתונים וגישה אליהם ב-DBMS מסחריים ובקוד פתוח.

במה אתה יכול להשתמש בדרך כלל:

1. הצפנה וערפול של נהלים ופונקציות (Wrapping) - כלומר, כלים וכלי שירות נפרדים שהופכים קוד קריא לבלתי קריא. נכון, אז לא ניתן לשנות אותו או להחזיר אותו מחדש. גישה זו נדרשת לעיתים לפחות בצד ה-DBMS - ההיגיון של הגבלות רישיון או לוגיקה של הרשאות מוצפן בדיוק ברמת הפרוצדורה והפונקציה.
2. הגבלת הנראות של נתונים לפי שורות (RLS) היא כאשר משתמשים שונים רואים טבלה אחת, אך הרכב שונה של שורות בה, כלומר, לא ניתן להציג משהו למישהו ברמת השורה.
3. עריכת הנתונים המוצגים (מסיכה) היא כאשר משתמשים בעמודה אחת של הטבלה רואים נתונים או רק כוכביות, כלומר, עבור חלק מהמשתמשים המידע ייסגר. הטכנולוגיה קובעת לאיזה משתמש יוצג מה על סמך רמת הגישה שלו.
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

שעון העצר פועל.

  id | טקסט1 | טקסט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

שעון העצר פועל.

  id | פענוח | לפענח
——+—————+————
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

CPU
15%
35%

רם
 
+% 5

להצפנה יש השפעה גדולה על הביצועים. ניתן לראות שהתזמון גדל, שכן פעולות פענוח של נתונים מוצפנים (ופענוח עדיין עטוף בלוגיקה שלכם) דורשות משאבים משמעותיים. כלומר, הרעיון של הצפנת כל העמודות המכילות נתונים מסויימים טומן בחובו ירידה בביצועים.

עם זאת, הצפנה אינה כדור כסף שפותר את כל הבעיות. הנתונים המפוענחים ומפתח הפענוח במהלך תהליך הפענוח והעברת הנתונים נמצאים בשרת. לכן, המפתחות יכולים להיות מיירטים על ידי מישהו שיש לו גישה מלאה לשרת מסד הנתונים, כגון מנהל מערכת.

כאשר יש מפתח אחד לכל העמודה עבור כל המשתמשים (גם אם לא עבור כולם, אלא עבור לקוחות של סט מוגבל), זה לא תמיד טוב ונכון. לכן התחילו לעשות הצפנה מקצה לקצה, ב-DBMS החלו לשקול אפשרויות להצפנת נתונים בצד הלקוח והשרת, והופיעו אותם אחסון מפתח-כספת - מוצרים נפרדים המספקים ניהול מפתחות ב-DBMS צַד.

דוגמה להצפנה כזו ב- MongoDB

תכונות אבטחה ב-DBMS מסחרי וקוד פתוח

פונקציות
סוג
מדיניות סיסמאות
ביקורת
הגנה על קוד המקור של נהלים ופונקציות
RLS
הצף

אורקל
מִסְחָרִי
+
+
+
+
+

MsSql
מִסְחָרִי
+
+
+
+
+

ג'טובה
מִסְחָרִי
+
+
+
+
סיומות

PostgreSQL
חופשי
סיומות
סיומות
-
+
סיומות

MongoDb
חופשי
-
+
-
-
זמין ב- MongoDB Enterprise בלבד

הטבלה רחוקה מלהיות מלאה, אבל המצב הוא כזה: במוצרים מסחריים, בעיות אבטחה נפתרו כבר זמן רב, בקוד פתוח, ככלל, משתמשים בתוספות מסוימות לאבטחה, חסרות פונקציות רבות. , לפעמים צריך להוסיף משהו. לדוגמה, מדיניות סיסמאות - ל-PostgreSQL יש הרחבות שונות (1, 2, 3, 4, 5), שמיישמות מדיניות סיסמאות, אבל, לדעתי, אף אחת מהן לא מכסה את כל הצרכים של הפלח הארגוני המקומי.

מה לעשות אם אין לך את מה שאתה צריך בשום מקום? לדוגמה, אתה רוצה להשתמש ב-DBMS ספציפי שאין לו את הפונקציות שהלקוח דורש.

אז אתה יכול להשתמש בפתרונות צד שלישי שעובדים עם DBMSs שונים, למשל, Crypto DB או Garda DB. אם אנחנו מדברים על פתרונות מהמגזר המקומי, אז הם יודעים על GOSTs טוב יותר מאשר בקוד פתוח.

האפשרות השנייה היא לכתוב את מה שאתה צריך בעצמך, ליישם גישה לנתונים והצפנה באפליקציה ברמת הפרוצדורה. נכון, זה יהיה קשה יותר עם GOST. אבל באופן כללי, אתה יכול להסתיר את הנתונים לפי הצורך, לשים אותם ב-DBMS, ואז לאחזר אותם ולפענח אותם לפי הצורך, ממש ברמת האפליקציה. יחד עם זאת, חשבו מיד כיצד תגן על האלגוריתמים הללו באפליקציה. לדעתנו, זה צריך להיעשות ברמת DBMS, כי זה יעבוד מהר יותר.

דוח זה הוצג לראשונה ב @Databases Meetup מאת Mail.ru Cloud Solutions. תראה וידאו הופעות אחרות והירשם להודעות על אירועים בטלגרם סביב Kubernetes בקבוצת Mail.ru.

מה עוד לקרוא בנושא:

1. יותר מ-Ceph: אחסון בלוק ענן של MCS.
2. כיצד לבחור מסד נתונים לפרויקט כך שלא תצטרך לבחור שוב.

מקור: www.habr.com