Luật quyền riêng tư định hình thiết kế
Cũng có bằng 28 ngôn ngữ khác
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Mô-đun 4 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Hiểu dữ liệu của bạn · Tiếp theo: Sự đồng ý và quyền được lãng quên
Câu hỏi mô-đun này trả lời: Các quy định về quyền riêng tư và ngành nghề đòi hỏi gì ở một thiết kế Salesforce?
Khi làm việc ở Úc, tôi gặp rất nhiều người muốn trở thành kiến trúc sư chưa từng nghe về GDPR. Người châu Âu thường chưa nghe về luật quyền riêng tư của California, hay của Canada, hay của Brazil. Điều đó tự nhiên thôi: bạn biết các quy định ở nơi mình làm việc. Nhưng những luật này vươn qua biên giới, và chúng định hình thiết kế hệ thống dù không luật nào nói về Salesforce. Vì vậy chúng thuộc về một khóa học kiến trúc dữ liệu.
Bạn không cần trở thành luật sư. Bạn cần thấy rằng một quy định có thể thay đổi nơi dữ liệu được lưu, bạn thu thập gì, ai thấy nó, vì sao bạn được dùng nó, bạn giữ nó bao lâu, bạn gửi nó đi đâu, bạn có xóa được nó không, bạn giữ lịch sử gì, và sau này bạn chứng minh được gì. Đó không chỉ là câu hỏi pháp lý. Đó là những câu hỏi kiến trúc dữ liệu.
Mô-đun này là hướng dẫn kiến trúc, không phải tư vấn pháp lý. Đội pháp chế và tuân thủ quyết định luật nào áp dụng và chúng yêu cầu gì. Kiến trúc sư biến những yêu cầu đó thành thiết kế thực thi được.
Luật không dừng ở biên giới
Phần tiêu đề “Luật không dừng ở biên giới ”Hiểu lầm lớn nhất trước: “chúng tôi không ở châu Âu, nên GDPR không áp dụng.” Có thể đúng, có thể không. Phạm vi lãnh thổ của GDPR vươn tới các tổ chức bên ngoài EU cung cấp hàng hóa hay dịch vụ cho người ở EU, hoặc theo dõi hành vi của họ ở đó (Điều 3, Regulation (EU) 2016/679 (opens in a new tab), tiếng Anh). Vì vậy nơi công ty bạn đặt trụ sở chưa phải là kết thúc của câu hỏi. Khách hàng, nhân viên, những người có dữ liệu bạn nắm giữ, hệ thống của bạn, các bên xử lý của bạn ở đâu? Dữ liệu di chuyển đến đâu? Lại là bản đồ hệ thống của chương 4. Bạn không thể đưa ra quyết định tốt về quyền riêng tư mà không biết dữ liệu đi đâu.
Các quy định bạn nên nhận ra
Phần tiêu đề “Các quy định bạn nên nhận ra ”Đây là những cái tên một kiến trúc sư nên biết, cùng với phạm vi của mỗi cái. Đó là một bảng để nhận diện, không phải ma trận áp dụng: đừng đọc nó rồi quyết định “chúng tôi có khách hàng ở California, nên yêu cầu X áp dụng”. Đó là quyết định của bộ phận Pháp chế. Việc của bạn là biết đủ để đặt câu hỏi trước khi hệ thống được xây.
| Luật hoặc tiêu chuẩn | Ở đâu hoặc về gì | Vì sao kiến trúc sư nên nhận ra nó |
|---|---|---|
| GDPR (opens in a new tab) | Liên minh châu Âu | Dữ liệu cá nhân, xử lý hợp pháp, quyền cá nhân, lưu giữ, chuyển giao, quyền riêng tư ngay từ thiết kế |
| CCPA, sửa đổi bởi CPRA (opens in a new tab) | California | Quyền của người tiêu dùng đối với thông tin cá nhân mà doanh nghiệp thu thập về họ |
| PIPEDA (opens in a new tab) | Canada | Cách các tổ chức khu vực tư nhân xử lý thông tin cá nhân |
| LGPD (opens in a new tab) | Brazil | Luật chung về bảo vệ dữ liệu cá nhân của Brazil |
| Privacy Act 1988 (opens in a new tab) | Úc | Cách các tổ chức xử lý thông tin cá nhân, theo các Nguyên tắc quyền riêng tư của Úc |
| HIPAA (opens in a new tab) | Y tế Mỹ | Thông tin sức khỏe được bảo vệ trong các bối cảnh thuộc phạm vi |
| PCI DSS (opens in a new tab) | Thẻ thanh toán | Bảo vệ dữ liệu tài khoản thẻ thanh toán |
| Sarbanes-Oxley (SOX) (opens in a new tab) | Công ty đại chúng Mỹ | Các biện pháp kiểm soát và bằng chứng đằng sau báo cáo tài chính |
| COPPA (opens in a new tab) | Mỹ, trẻ em trực tuyến | Thông tin cá nhân thu thập trực tuyến từ trẻ em |
Danh sách này còn dài thêm (nhiều bang của Mỹ có luật riêng), và các luật thay đổi. Đó là lý do tôi không muốn bạn thuộc lòng một bảng rồi nghĩ rằng mình đã học xong kiến trúc quyền riêng tư. Hãy học các cái tên, rồi học những câu hỏi tồn tại lâu hơn chúng.
Điểm chung của các luật
Phần tiêu đề “Điểm chung của các luật ”Chi tiết thì khác nhau, nhưng các luật quyền riêng tư lớn cứ quay về cùng một vài điều, và mỗi điều đều chạm đến kiến trúc.
Quyền cá nhân. Người ta có thể yêu cầu xem dữ liệu của mình, chỉnh sửa, xóa và mang nó theo; theo luật của California và Brazil, họ còn có thể từ chối việc dữ liệu của mình bị bán. Mỗi yêu cầu như vậy đều có nghĩa là phải tìm ra dữ liệu của người đó, toàn bộ.
Chuyển giao. GDPR và LGPD kiểm soát việc dữ liệu cá nhân rời khỏi khu vực tài phán của chúng và yêu cầu sự bảo vệ thỏa đáng ở nơi dữ liệu đến; PIPEDA đòi hỏi cùng mức bảo vệ khi một bên thứ ba xử lý dữ liệu, dù ở bất cứ đâu. Lại là bản đồ hệ thống: những mũi tên nào vượt qua biên giới?
Thông báo sự cố rò rỉ. Khi dữ liệu cá nhân bị lộ, các luật yêu cầu bạn báo cho cơ quan chức năng, và đôi khi cho cả những người bị ảnh hưởng, trong một thời hạn khác nhau tùy luật. Bạn không thể thông báo về dữ liệu mà bạn không biết mình đang giữ, hay nói được cái gì đã bị lộ nếu bạn không tìm ra các bản sao.
Trách nhiệm giải trình. Bạn phải chứng minh được sự tuân thủ: hồ sơ về những gì bạn xử lý và vì sao, đánh giá tác động cho các hoạt động xử lý rủi ro cao, và, theo GDPR và LGPD, một nhân viên bảo vệ dữ liệu (DPO). Kiến trúc phải tạo ra được các hồ sơ đó.
Bắt đầu với những gì mang tính cá nhân
Phần tiêu đề “Bắt đầu với những gì mang tính cá nhân ”Trước khi bảo vệ thông tin cá nhân, hãy tìm ra nó. Một số thì hiển nhiên: tên, địa chỉ nhà, điện thoại, email. Một số thì không: vị trí, mã định danh thiết bị, địa chỉ IP, hình ảnh, dữ liệu hành vi, bất cứ thứ gì có thể liên kết ngược về một người. Và bối cảnh quan trọng. Một lần giao hàng của Steve Trucking mang tên, địa chỉ, số điện thoại, ghi chú giao hàng và ảnh của Người nhận. Một bức ảnh có thể cho thấy một chiếc hộp trên hiên nhà, hoặc một con người, hoặc bên trong một ngôi nhà. Lần giao hàng là dữ liệu vận hành, nhưng một số thuộc tính của nó mang tính cá nhân. Đó là lý do mô-đun 3 phân loại các trường: quyền riêng tư bắt đầu bằng việc biết bạn đang nắm giữ gì.
Nó nằm ở đâu?
Phần tiêu đề “Nó nằm ở đâu? ”“Salesforce.” Có lẽ không chỉ Salesforce. Nó có đến từ một Đối tác bán lẻ không? Có được sao chép sang Snowflake, được Data 360 nạp vào, ghi vào nhật ký tích hợp, được người dùng xuất ra, còn lại trong lịch sử trường, được lưu trữ, sao chép vào sandbox, chuyển cho đối tác, dùng trong cuộc hội thoại của tác tử không? Dữ liệu cá nhân lan rộng. Vì vậy khi Pháp chế hỏi “chúng ta giữ thông tin của người này ở đâu?”, “chúng tôi biết giá trị hiện tại ở đâu” không phải là câu trả lời. Tôi muốn có bản đồ hệ thống và dòng dõi dữ liệu: các bản sao đã đi đâu.
Một số điện thoại, nhiều bản sao. Quyền riêng tư cũng áp dụng cho các bản sao.
Vì sao bạn được phép dùng nó?
Phần tiêu đề “Vì sao bạn được phép dùng nó? ”Có dữ liệu và được phép dùng nó không phải là một. Steve Trucking có số điện thoại của Người nhận để phối hợp lần giao hàng hôm nay. Điều đó có biến nó thành một danh sách marketing không? Không. Cơ sở pháp lý tùy thuộc vào khu vực tài phán và tình huống, và Pháp chế hướng dẫn điều đó, nhưng kiến trúc phải mang được câu trả lời: vì sao nó được thu thập, việc sử dụng nào được cho phép, có cần sự đồng ý không, sự đồng ý đã được đưa ra, đã bị rút lại chưa, và cho kênh, địa chỉ và mục đích nào. Sự cho phép dùng dữ liệu phải biểu diễn được dưới dạng dữ liệu, vì một tài liệu chính sách không thể ra quyết định lúc hệ thống đang chạy. Mô-đun tiếp theo mô hình hóa nó.
Thu thập ít hơn là một quyết định kiến trúc
Phần tiêu đề “Thu thập ít hơn là một quyết định kiến trúc ”Một trong những biện pháp kiểm soát quyền riêng tư mạnh nhất là không thu thập dữ liệu, hoặc không sao chép nó đến nơi không cần. Snowflake có cần số điện thoại của Người nhận không? Phân tích có cần địa chỉ đầy đủ không? Sandbox có cần ảnh giao hàng thật không? Một tác tử có cần thông tin cá nhân của Người nhận để trả lời câu hỏi này không? Nếu không, biện pháp kiểm soát mạnh nhất có thể là đừng đưa nó vào đó. Mỗi bản sao bạn không tạo ra là một bản sao bạn không phải bảo mật, lưu giữ, xóa, theo dõi sự đồng ý, kiểm toán hay báo cáo khi bị rò rỉ. Dữ liệu nhạy cảm rẻ nhất để quản trị là dữ liệu bạn chưa bao giờ sao chép.
Lưu giữ là một phần của mô hình
Phần tiêu đề “Lưu giữ là một phần của mô hình ”“Tạm thời cứ giữ mọi thứ” là một chính sách lưu giữ. Chỉ là một chính sách tồi. Với dữ liệu quan trọng, ngay lúc thiết kế tôi muốn biết chúng ta cần nó bao lâu và vì sao; có quy định nào đặt mức tối thiểu hay quy định khác đặt mức tối đa không; đồng hồ bắt đầu tính từ khi nào; và chuyện gì xảy ra khi hết hạn: xóa, lưu trữ, khử định danh, và các bản sao ở đâu? Hồ sơ tài chính có thể phải được giữ trong một khoảng thời gian xác định. Mã cổng của một Người nhận không có mục đích gì nhiều năm sau lần giao hàng. Những quyết định đó không chờ đến khi cơ sở dữ liệu lớn lên.
Ẩn danh hóa, giả danh hóa, mã hóa, che dữ liệu
Phần tiêu đề “Ẩn danh hóa, giả danh hóa, mã hóa, che dữ liệu ”Thay “Jane Smith” bằng 7F92A1. Jane đã được ẩn danh hóa chưa? Chưa, nếu một bảng khác vẫn ghi 7F92A1 = Jane Smith. Đó là giả danh hóa: mã định danh trực tiếp được thay thế, nhưng dữ liệu có thể được liên kết lại bằng thông tin giữ riêng, và theo GDPR dữ liệu giả danh hóa vẫn là dữ liệu cá nhân (Điều 4(5)). Ẩn danh hóa đi xa hơn: dữ liệu không còn có thể được liên kết với người đó một cách hợp lý (Đoạn dẫn nhập 26). Vì vậy khi ai đó nói “chúng ta không cần xóa, chỉ cần bỏ tên đi”, hãy cẩn thận. Nếu người đó vẫn có thể được nhận diện một cách hợp lý, bạn chưa vượt qua lằn ranh đó. Một kết quả có thỏa mãn luật hay không là quyết định của Pháp chế; việc của kiến trúc sư là nói chính xác hệ thống làm gì: nó có thể được liên kết lại không, còn những khóa nào, các bảng ánh xạ ở đâu?
Hãy dùng từ ngữ chính xác, vì chúng giải quyết những vấn đề khác nhau. Mã hóa bảo vệ dữ liệu khỏi bị tiết lộ trái phép; người dùng được phép vẫn giải mã được. Che dữ liệu thay đổi những gì người dùng hay môi trường cụ thể nhìn thấy. Giả danh hóa tách danh tính trực tiếp ra trong khi vẫn giữ một đường quay lại. Ẩn danh hóa xóa bỏ khả năng hợp lý để nhận diện người đó. Chỉ cái cuối cùng mới đưa dữ liệu ra khỏi phạm vi “cá nhân”.
Quy định trở thành yêu cầu
Phần tiêu đề “Quy định trở thành yêu cầu ”Pháp chế không cần bảo tôi tạo một bộ quyền; đó là phần việc của tôi. Pháp chế có thể nói “chỉ những nhân viên có nhu cầu nghiệp vụ chính đáng mới được truy cập loại thông tin cá nhân này”. Rồi tôi chuyển dịch: họ là ai, chúng ta xác định loại thông tin đó thế nào, quyền truy cập được cấp ra sao, chuyện gì xảy ra khi ai đó đổi công việc, một tích hợp có đọc được nó không, một tác tử thì sao, nó có xuất ra được không, và chúng ta chứng minh ai đã xem nó thế nào? Chủ sở hữu đặt chính sách; kiến trúc sư thực thi nó. Pháp chế và tuân thủ thiết lập nghĩa vụ, chủ sở hữu dữ liệu đặt chính sách nghiệp vụ, và kiến trúc sư thiết kế việc thực thi.
Từ quy định đến bằng chứng: Pháp chế diễn giải, chủ sở hữu đặt chính sách, kiến trúc sư làm cho nó vận hành được và chứng minh được.
Và tuân thủ không phải là một sản phẩm. Bạn không thể mua “tuân thủ: bật”. Mã hóa có thể hỗ trợ một yêu cầu, các tính năng kiểm toán cung cấp bằng chứng, công cụ lưu giữ thực thi chính sách, dữ liệu đồng ý hỗ trợ việc sử dụng được phép, nhưng mua giấy phép một tính năng không làm cho một kiến trúc tuân thủ. Tuân thủ đến từ toàn bộ thiết kế: con người, chính sách, quy trình, dữ liệu, biện pháp kiểm soát và bằng chứng. Salesforce là một phần của nó, không phải tất cả. Và nếu một chính sách đủ quan trọng để thực thi, hãy hỏi nó có đủ quan trọng để chứng minh không: ai đã truy cập bản ghi này ngày 17 tháng 3, ai đã thay đổi trường này, bản xuất đó chứa gì? Mô-đun 6 trình bày về bằng chứng.
Quyền riêng tư thay đổi bản đồ hệ thống
Phần tiêu đề “Quyền riêng tư thay đổi bản đồ hệ thống ”Ở Steve Trucking, dữ liệu cá nhân của Người nhận đến qua ba tích hợp đối tác. Salesforce cần nó để vận hành việc giao hàng; tổ giao hàng cần một phần, chỉ cho các điểm dừng của chính họ, chỉ trong ngày; Snowflake muốn phân tích giao hàng; tài chính cần đủ để lập hóa đơn, nhưng không cần những gì tổ giao hàng thấy. Và một Đối tác bán lẻ không bao giờ được thấy Người nhận của đối tác khác. Quyền riêng tư thay đổi các mũi tên: một số trường không đi vào Snowflake, phân tích nhận một phiên bản ít định danh hơn, tổ giao hàng chỉ thấy điểm dừng của mình, việc lưu giữ ở các hệ thống phía sau khác với lưu giữ vận hành. Yêu cầu về quyền riêng tư không nằm bên cạnh sơ đồ bản đồ hệ thống. Nó thay đổi sơ đồ đó.
Những câu hỏi tồn tại lâu hơn các quy định
Phần tiêu đề “Những câu hỏi tồn tại lâu hơn các quy định ”Quy định thay đổi, nên hãy mang theo một bộ câu hỏi bền vững cho mọi dữ liệu nhạy cảm hay chịu quản lý:
- Nó là gì? Dữ liệu cá nhân, nhạy cảm, tài chính, sức khỏe, thanh toán, của trẻ em hay chịu quản lý theo cách khác?
- Nó nằm ở đâu? Mọi bản sao: tích hợp, lịch sử, phân tích, kho lưu trữ, sandbox, nhật ký, việc sử dụng cho AI.
- Vì sao chúng ta được dùng nó? Mục đích và cơ sở pháp lý nào áp dụng? Có liên quan đến sự đồng ý không?
- Ai được dùng nó? Con người, hệ thống, đối tác, tích hợp, tác tử.
- Chúng ta giữ nó bao lâu, và chuyện gì xảy ra khi hết hạn?
- Người đó có thực hiện được các quyền của mình đối với nó không? Truy cập, chỉnh sửa, xóa, chuyển dữ liệu, phản đối, theo quy định của luật.
- Chúng ta có chứng minh được điều gì đã xảy ra không? Truy cập, thay đổi, xuất dữ liệu, sự đồng ý, xóa, lưu giữ.
Quản trị AI đang trở thành luật
Phần tiêu đề “Quản trị AI đang trở thành luật ”AI thêm một bên tiêu thụ dữ liệu được quản trị nữa. Một hệ thống AI có được dùng dữ liệu này không, cho mục đích gì, làm dữ liệu neo, kết hợp với gì, có nhắc lại trong đầu ra không, ghi nhật ký ở đâu, trong bao lâu? Việc quản trị AI đang chuyển từ chính sách công ty sang luật: Đạo luật AI của Liên minh châu Âu (Regulation (EU) 2024/1689 (opens in a new tab), tiếng Anh) là ví dụ rộng đầu tiên. Nó yêu cầu gì tùy thuộc vào hệ thống và cách sử dụng. Hướng đi cho kiến trúc sư thì rõ ràng: AI không nằm ngoài quản trị; nó là một bên tiêu thụ khác của dữ liệu được quản trị.
Kiến trúc sư quyết định gì ở đây
Phần tiêu đề “Kiến trúc sư quyết định gì ở đây ”- Dữ liệu chịu quản lý hay nhạy cảm đi vào, nằm ở, di chuyển và được sao chép ở đâu trên bản đồ hệ thống.
- Chính sách pháp chế và tuân thủ trở thành các yêu cầu thực thi được thế nào, mà kiến trúc sư không phải tự diễn giải luật.
- Mỗi hệ thống nhận dữ liệu nhạy cảm có cần nó không, hay một phiên bản ít định danh hơn là đủ.
- Lưu giữ, xóa, ẩn danh hóa, giả danh hóa, bảo vệ và bằng chứng định hình vòng đời của dữ liệu thế nào.
- Bằng chứng nào phải tồn tại để cho thấy các biện pháp kiểm soát quan trọng thực sự đã hoạt động.
Quy định không trở thành kiến trúc bằng cách đặt tên của chúng lên một trang slide. Chúng trở thành kiến trúc khi chúng thay đổi cách dữ liệu được thu thập, phân loại, di chuyển, bảo vệ, lưu giữ, xóa và chứng minh.
Tìm hiểu thêm
Phần tiêu đề “Tìm hiểu thêm ”- Nguồn chính thức của các quy định được liên kết trong bảng ở trên (tiếng Anh), kiểm tra ngày 2026-10-14.
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab): Điều 3 (phạm vi lãnh thổ), Điều 4(5) (giả danh hóa), Đoạn dẫn nhập 26 (thông tin ẩn danh).
- Regulation (EU) 2024/1689 (Đạo luật AI) (opens in a new tab), EUR-Lex.