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

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

אתם יכולים להשתמש ב-Cloud SQL כדי לאחסן את הפרטים האישיים המזהים בצורה מאובטחת. אתם רוצים לוודא שהמידע הזה יעובד עם ההגנה הכי גבוהה על הפרטיות, כדי שלא תהיה אליו גישה בטעות. לדוגמה, אם אתם מאחסנים פרטי כרטיס אשראי או נתונים רפואיים במסדי הנתונים שלכם, אתם יכולים להשתמש ב-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 מאבטח את הפרטים האישיים המזהים של ג'ק ואליס בעמודות האלה.

אפשר גם להשתמש בהצהרת 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 OR REPLACE 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, לטבלאות יכולות להיות מדיניות אבטחה ברמת השורה שמגבילה, על בסיס משתמש, את השורות שהמשתמשים יכולים לראות על ידי יצירת שאילתות, או את השורות שהמשתמשים יכולים להוסיף, לעדכן או למחוק על ידי הפעלת פקודות לשינוי נתונים.

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

--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, פועלים לפי השלבים הבאים:

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

  2. אם אתם מתכננים להשתמש במסכות דינמיות והטבלאות שאתם רוצים להסתיר לא נמצאות בסכימה public, צריך להגדיר את הדגל anon.sourceschema לשם הסכימה שמכילה את הטבלאות האלה. בדוגמאות שבדף הזה, הדגל מוגדר לערך secure_schema.

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

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

--Verify that the masked user is configured. The search_path must include
--the mask schema followed by the schema set in the anon.sourceschema flag.

SELECT rolconfig FROM pg_roles WHERE rolname = 'analyst_ro';
              rolconfig
--------------------------------------
 {"search_path=mask, secure_schema"}

--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" (open a new connection; 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 user_details;
 id | name  | age |       email_id         |    password
----+-------+-----+------------------------+-----------------
  1 | jack  |  34 | alisontodd@example.com | 13d249f2cb4127b
  2 | alice |  37 | amanda35@example.com   | 13d249f2cb4127b

--The masked user can't query the source table directly.

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

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

  • מבטלת את ההרשאות שניתנו ישירות לתפקיד בסכימת המקור.
  • ההרשאה USAGE ניתנת לתפקיד בסכימה mask, וההרשאה SELECT ניתנת לתפקיד בכל תצוגה בסכימה, כולל תצוגות של טבלאות שהתפקיד לא יכול היה לשלוח להן שאילתות לפני כן.
  • מגדירים את search_path של התפקיד לסכימה mask, ואחריה לסכימת המקור.

משתמש עם גישה מוגבלת רואה נתונים מוסתרים רק כשהוא שולח שאילתה לטבלה בלי לציין את שם הסכימה, כך שהשם יומר לתצוגה בסכימה mask. שאילתות שמציינות את שם הסכימה, כמו SELECT * FROM secure_schema.user_details, מדלגות על הסכימה mask ונכשלות עם שגיאת הרשאה. ההגדרה search_path חלה כשהמשתמש מתחבר, ולכן משתמשים עם כתובת אימייל מוסתרת צריכים לפתוח חיבור חדש אחרי שאתם מתייגים את התפקיד.

מסכה סטטית

התממת מידע סטטית משמשת להסרת פרטים אישיים מזהים (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 | 13d249f2cb4127b
  2 | alice |  37 | annebenitez@example.com         | 13d249f2cb4127b

dump אנונימי

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

--Launch pg_dump_anon to apply earlier defined masking rules. pg_dump_anon
--reads the source table directly, so connect as a user that has the SELECT
--privilege on the table and that isn't labeled as MASKED.

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

הצפנת נתונים

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

כדי להצפין את הפרטים האישיים המזהים (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

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

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