אסטרטגיות לשמירה על פרטיות הנתונים

‫MySQL | PostgreSQL | SQL Server

פרטיות נתונים היא הגנה על נתונים כמו פרטים אישיים מזהים (PII) מפני אנשים שלא אמורה להיות להם גישה אליהם. בדף הזה מתוארות כמה גישות לפרטיות נתונים שבעזרתן אפשר להגן על פרטים אישיים מזהים (PII) ב-Cloud SQL.

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

כדי לאבטח את הפרטים האישיים המזהים (PII) ב-Cloud SQL, אפשר להשתמש בשיטות הבאות:

אבטחה ברמת העמודה
גישה שמבוססת על צפיות
אבטחה ברמת השורה
הסתרת נתונים ואנונימיזציה שלהם
הצפנת נתונים

אבטחה ברמת העמודה

אבטחה ברמת העמודה מאפשרת להגביל את האנשים שיכולים לראות את התוכן בעמודות ספציפיות בטבלאות של מסד הנתונים. הרשאות ברמת העמודה רלוונטיות להצהרות INSERT,‏ UPDATE,‏ SELECT ו-REFERENCES.

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

--User: "admin"

CREATE SCHEMA secure_schema;

CREATE TABLE secure_schema.user_details(id bigint, name text, age smallint, email_id text, password text);

--For this example, passwords are stored in plain text for demonstration
--purposes only. In production, never store passwords in plain text.

INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'jack@example.com','testpass');
INSERT INTO secure_schema.user_details VALUES(2,'alice',37,'alice@example.com','testpass');

GRANT USAGE ON SCHEMA secure_schema TO analyst_ro;

--Grant read permissions on specific columns only.

GRANT SELECT (id, name, age) ON secure_schema.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT * FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT name, age, password FROM secure_schema.user_details;
ERROR:  permission denied for table user_details

SELECT id, name,age FROM secure_schema.user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

אם כוללים את העמודות המוגבלות בהצהרת SELECT או מזינים SELECT *, תוצג הודעת שגיאה. ‫Cloud SQL מאבטח את פרטי ה-PII של ג'ק ואליס בעמודות האלה.

אפשר גם להשתמש בהצהרת GRANT אחת כדי לשלב הרשאות שונות.

GRANT SELECT (id,name,age), UPDATE (name) ON secure_schema.user_details TO analyst_ro;

גישה שמבוססת על צפיות

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

בדוגמה הבאה אפשר לראות איך משתמשים בגישה מבוססת-תצוגה באתר קמעונאי כדי להגן על הפרטים האישיים המזהים של ג'ק ואליס:

--User: "admin"

CREATE SCHEMA analyst_ro;
CREATE VIEW analyst_ro.user_details AS SELECT id, name, age FROM secure_schema.user_details;
GRANT USAGE ON SCHEMA analyst_ro TO analyst_ro;
GRANT SELECT ON analyst_ro.user_details TO analyst_ro;

--User: "analyst_ro"

SELECT id,name,age FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

SELECT * FROM user_details;
 id | name  | age
----+-------+----
  1 | jack  |  34
  2 | alice |  37

בדוגמה הזו, נוצרת סכימה נפרדת לתצוגה כדי שהשם שלה יישאר זהה לשם הטבלה. בגישה שמבוססת על תצוגות, אפשר להשתמש ב-SELECT *.

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

CREATE VIEW analyst_ro.user_details AS SELECT id, name, age, 'redacted@example.com' as email_id,'*****'::text as password FROM secure_schema.user_details;

SELECT * FROM user_details;
 id | name  | age |     email_id         | password
----+-------+-----+----------------------+---------
  1 | jack  |  34 | redacted@example.com | *****
  2 | alice |  37 | redacted@example.com | *****

אבטחה ברמת השורה

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

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

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

--User: "admin"
--Create and enable a policy for row-level security

CREATE POLICY user_details_rls_pol ON secure_schema.user_details FOR ALL TO PUBLIC USING (name=current_user);
ALTER TABLE secure_schema.user_details ENABLE ROW LEVEL SECURITY;

SELECT * FROM secure_schema.user_details;
 id | name  | age |     email_id      | password
----+-------+-----+-------------------+---------
  1 | jack  |  34 | jack@example.com  | testpass
  2 | alice |  37 | alice@example.com | testpass

--User: "jack"

SELECT * FROM secure_schema.user_details;
 id | name | age |    email_id      | password
----+------+-----+------------------+---------
  1 | jack |  34 | jack@example.com | testpass

--User: "alice"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+-------------------+---------
  2 | alice |  37 | alice@example.com | testpass

משתמשים שהוקצו להם תפקידים עם המאפיין BYPASSRLS יכולים לעקוף את אבטחת הנתונים ברמת השורה כשהם ניגשים לטבלה. בעלי הטבלה יכולים גם לעקוף את האבטחה ברמת השורה. אם רוצים להחיל אבטחה ברמת השורה על בעלי טבלה, משתמשים בפקודה ALTER TABLE ... FORCE ROW LEVEL SECURITY.

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

הסתרת נתונים ואנונימיזציה שלהם

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

השימוש בתוסף במקום בגישה שמבוססת על תצוגות מפורטות מספק לכם את היתרונות הבאים:

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

התקנה והגדרה של התוסף `postgresql_anonymizer`

כדי להשתמש בתוסף הזה במכונת Cloud SQL, פועלים לפי השלבים הבאים:

עורכים את המופע ומגדירים את cloudsql.enable_anon flag ל-on. מידע על הגדרת דגלים ועל הדגלים שהתוסף תומך בהם זמין במאמר הגדרת דגלים של מסד נתונים.

כדי ליצור את התוסף במסד הנתונים, מריצים את הפקודה הבאה:

--Connect to the PostgreSQL database

CREATE EXTENSION IF NOT EXISTS anon CASCADE;
SELECT anon.init();

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

מסכה דינמית

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

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

--Activate the dynamic masking engine

SELECT anon.start_dynamic_masking();

--Declare the masking user and masking rules
--analyst_ro is the masked user with select privileges on the
--user_details table

SECURITY LABEL FOR anon ON ROLE analyst_ro IS 'MASKED';

SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.email_id IS 'MASKED WITH FUNCTION anon.fake_email()';
SECURITY LABEL FOR anon ON COLUMN secure_schema.user_details.password  IS 'MASKED WITH FUNCTION anon.hash(password)';

--User: "admin" (can see all unmasked data)

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+------------  -----+---------
  1 | jack  |  34 | jack@example.com  | testpass
  2 | alice |  37 | alice@example.com | testpass

--User:"analyst_ro" (note that the "email_id" and "password" columns are
--replaced with masked data,)
--Data in the password column is truncated for better formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |       email_id         | password
----+-------+-----+-----------------  -----+----------------
  1 | jack  |  34 | alisontodd@example.com | 13d249f2cb4127b
  2 | alice |  37 | amanda35@example.com   | 13d249f2cb4127b

מסכה סטטית

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

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

--User: "admin"

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id       | password
----+-------+-----+--------------  ---+---------
  1 | jack  |  34 | jack@example.com  | testpass
  2 | alice |  37 | alice@example.com | testpass

--Apply earlier defined masking rules to the table permanently.
--Now all users see masked data only.

SELECT anon.anonymize_table('secure_schema.user_details');
 anonymize_table
-----------------
 t

--User: "analyst_ro"
--Data in the password column is truncated for better formatting.

select * from secure_schema.user_details;
 id | name  | age |           email_id              |  password
----+-------+-----+-------------------------  ------+---------------
  1 | jack  |  34 | christophercampbell@example.com | 13d249f2cb412c
  2 | alice |  37 | annebenitez@example.com         | 13d249f2cb4127

העברה אנונימית

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

--Launch pg_dump_anon with the masked user to apply earlier defined --masking rules

pg_dump_anon -h HOSTIP -p 5432 -d DATABASE_NAME -U analyst_ro --table=secure_schema.user_details --file=user_details_anonysms.sql

הצפנת נתונים

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

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

לתוסף pgcrypto יש מספר פונקציות של hash ו-encrypt.

גיבוב (hash)

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

בדוגמה של אתר קמעונאי, אפשר להשתמש בתוסף pgcrypto כדי לבצע גיבוב של הסיסמה של ג'ק לפני שמירתה בטבלה user_details.

--Hash passwords before storing them in the user_details table.

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,'jack@example.com',crypt('testpassword', gen_salt('bf')));

--Match the hashed data with user entered password

SELECT id, name FROM secure_schema.user_details WHERE email_id = 'jack@example.com' AND password = crypt('testpassword', password);
 id | name
----+-----
  1 | jack

הצפנה

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

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

--"user_acc_key" is the encryption key

TRUNCATE TABLE secure_schema.user_details;
INSERT INTO secure_schema.user_details VALUES(1,'jack',34,pgp_sym_encrypt('jack@example.com','user_acc_key'),pgp_sym_encrypt('testpassword','user_acc_key'));

--User: "admin" (queries without an encryption key)
--Data in the email_id and password columns are truncated for better
--formatting.

SELECT * FROM secure_schema.user_details;
 id | name  | age |    email_id     | password
----+-------+-----+-----------------+-------------------
  1 | jack |  34 | \xc30d0407030209 | \xc30d040703028962

--User: "app_user" (queries with a valid encryption key)

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_acc_key'),pgp_sym_decrypt(password::bytea,'user_acc_key') FROM secure_schema.user_details;
 name | pgp_sym_decrypt   | pgp_sym_decrypt
------+-------------------+----------------
 jack | jack@example.com  | testpassword

--If a user uses the wrong encryption key, then the following error message appears:

SELECT name,pgp_sym_decrypt(email_id::bytea,'user_bad_key'),
pgp_sym_decrypt(password::bytea,'user_bad_key') FROM secure_schema.user_details;
ERROR:  Wrong key or corrupt data

המאמרים הבאים

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