Yêu cầu kỹ thuật HIPAA cho developer: encryption, logging, access control

Yêu cầu kỹ thuật HIPAA nằm ở technical safeguards của Security Rule, 45 CFR §164.312: năm standard gồm access control, audit controls, integrity, person or entity authentication và transmission security. Trong đó user ID riêng và thủ tục truy cập khẩn cấp là required; tự động đăng xuất, mã hóa khi lưu, cơ chế xác thực toàn vẹn và mã hóa khi truyền là addressable.

Bài này đi theo góc nhìn của người viết code; tổng quan về luật nằm ở HIPAA là gì.

Khi nào code của bạn nằm trong phạm vi HIPAA?

Code nằm trong phạm vi HIPAA khi công ty bạn tạo, nhận, lưu hoặc truyền ePHI thay mặt covered entity (bệnh viện, phòng khám, health plan, clearinghouse) hoặc thay mặt một business associate khác; khi đó công ty là business associate và hệ thống phải đáp ứng Security Rule. Ví dụ: phần mềm quản lý bệnh nhân cho bệnh viện Mỹ, nền tảng telemedicine cho phòng khám, hệ thống lưu hồ sơ khám. Website marketing không chạm tới PHI thì không thuộc phạm vi. Không có chứng nhận HIPAA chính thức nào được HHS phê duyệt (Microsoft Learn); nghĩa vụ được xác lập qua BAA và quy định. Chi tiết về phạm vi có trong bài HIPAA có áp dụng cho công ty Việt Nam không.

ePHI xuất hiện ở đâu trong code?

PHI là thông tin sức khỏe định danh được một cá nhân, do covered entity hoặc business associate nắm giữ (45 CFR §160.103); ePHI là PHI ở dạng điện tử, và Security Rule chỉ áp dụng cho ePHI. Trong hệ thống, ePHI nằm ở database record, API response, file người dùng tải lên, message queue, cache, log và bản backup. Danh sách 18 nhóm định danh (tên, đơn vị địa lý nhỏ hơn tiểu bang, mọi thành phần ngày trừ năm, số điện thoại, email, số hồ sơ bệnh án, địa chỉ IP, URL, ảnh toàn khuôn mặt…) là danh sách phải loại bỏ để de-identify theo phương pháp Safe Harbor (§164.514(b)(2)). Developer dùng nó theo chiều ngược lại: nếu dữ liệu test hoặc log còn bất kỳ định danh nào trong danh sách đi kèm thông tin sức khỏe, hãy coi đó là ePHI.

Required và addressable khác nhau thế nào?

Security Rule gắn nhãn cho từng implementation specification, còn bản thân các standard thì luôn phải đáp ứng. Required là phải triển khai. Addressable là phải đánh giá: triển khai nếu hợp lý và phù hợp, nếu không thì ghi lý do và áp dụng biện pháp thay thế tương đương (§164.306(d)). Addressable vì vậy không có nghĩa là tùy chọn; nó có nghĩa là quyết định phải dựa trên risk analysis và được ghi lại.

Access control cần triển khai những gì?

Access control yêu cầu chính sách và thủ tục kỹ thuật để chỉ người hoặc phần mềm được cấp quyền mới truy cập được ePHI (§164.312(a)(1)). User ID riêng là yêu cầu cứng: không dùng tài khoản chung cho hệ thống chứa ePHI, kể cả tài khoản admin của team. Thủ tục truy cập khẩn cấp cũng là required; cách thường dùng là tài khoản break-glass chỉ kích hoạt theo điều kiện định trước, mọi thao tác đều được log và được review sau sự kiện. Tự động đăng xuất là addressable và quy định không đưa con số; hãy chọn thời gian timeout dựa trên rủi ro của từng giao diện và ghi lại lý do. Phân quyền theo vai trò (RBAC) và minimum necessary là cách thông dụng để giới hạn ai đọc được bản ghi nào.

Audit controls cần ghi những gì?

Audit controls yêu cầu cơ chế phần cứng, phần mềm hoặc thủ tục ghi lại và cho phép kiểm tra hoạt động trên hệ thống chứa hoặc sử dụng ePHI (§164.312(b)). Một bản ghi log hữu ích có:

• User ID hoặc service account thực hiện
• Thời điểm, kèm múi giờ
• Hành động: đọc, tạo, sửa, xóa, xuất
• Đối tượng bị tác động: ID bản ghi bệnh nhân, ID tài liệu
• Nguồn: IP hoặc workstation
• Kết quả: thành công hay bị từ chối

Log cần được bảo vệ khỏi việc bị sửa hoặc xóa bởi chính người dùng. Trong cloud, cách thường dùng là ghi log vào một bucket hoặc dịch vụ riêng, application layer chỉ có quyền ghi. Quy định không ấn định thời gian lưu log; nhiều tổ chức chọn 6 năm cho khớp với yêu cầu lưu hồ sơ tại §164.316(b)(2). Việc review log định kỳ thuộc administrative safeguard "information system activity review" và là required (§164.308(a)(1)(ii)(D)).

Integrity controls bảo vệ dữ liệu khỏi điều gì?

Integrity yêu cầu chính sách và thủ tục bảo vệ ePHI khỏi bị sửa hoặc hủy trái phép (§164.312(c)(1)); cơ chế xác thực rằng ePHI không bị sửa là addressable. Các cách phổ biến:

1. Lưu hash khi ghi và kiểm tra lại khi đọc.
2. Dùng audit table hoặc event log để giữ lịch sử thay đổi, không chỉ trạng thái cuối.
3. Ký số tài liệu quan trọng như kết quả xét nghiệm, đơn thuốc.
4. Dùng storage bất biến (immutable) cho bản lưu cần giữ nguyên.

Integrity không chỉ chống tấn công: nó còn bắt lỗi phần mềm ghi đè dữ liệu, lỗi đĩa và bug trong migration script.

Person or entity authentication triển khai thế nào?

Standard này yêu cầu xác minh người hoặc hệ thống truy cập ePHI đúng là đối tượng họ khai báo (§164.312(d)). Quy định hiện hành không nêu tên MFA, nhưng MFA cho người dùng và xác thực mạnh cho service-to-service (mTLS, token ngắn hạn, workload identity) là cách phổ biến và là câu khách hàng Mỹ thường hỏi trong security questionnaire.

Transmission security cần gì?

Transmission security yêu cầu biện pháp chống truy cập trái phép vào ePHI đang truyền qua mạng (§164.312(e)(1)); kiểm soát toàn vẹn và mã hóa khi truyền là addressable. Trong thực tế:

• Mọi endpoint mang ePHI chỉ nhận HTTPS; TLS 1.2 trở lên, cấu hình theo NIST SP 800-52 Rev. 2.
• Không tắt kiểm tra certificate trong production.
• Mã hóa cả lưu lượng nội bộ nếu mạng không được kiểm soát hoàn toàn.
• Không gửi ePHI qua email thường; dùng dịch vụ có BAA và mã hóa, hoặc gửi link tới cổng an toàn.

Mã hóa khi lưu trữ có bắt buộc không?

Mã hóa khi lưu là addressable, nhưng risk analysis của hầu hết hệ thống cloud sẽ dẫn tới việc mã hóa. Lý do thực dụng: theo hướng dẫn của HHS về PHI "unsecured", dữ liệu được mã hóa đúng chuẩn NIST (với khóa không bị lộ) không kích hoạt nghĩa vụ báo breach khi bị lộ (HHS, Breach Notification guidance). NIST SP 800-111 hướng dẫn mã hóa lưu trữ. Các lỗi thường gặp:

• Mã hóa database nhưng quên backup và snapshot.
• Để khóa cạnh dữ liệu hoặc hardcode trong source code.
• Mã hóa trường dữ liệu nhưng để lộ metadata định danh được.
• Mã hóa ở tầng ứng dụng nhưng log và công cụ monitoring vẫn thấy plaintext.

Developer dùng AI coding tools có ảnh hưởng gì?

AI coding tools không tự vi phạm HIPAA; rủi ro là ePHI đi tới vendor chưa ký BAA qua prompt, file được index hoặc log. Khả năng ký BAA tùy vendor và gói dịch vụ, nên hãy kiểm tra trang compliance hiện hành của vendor và lưu câu trả lời. Chi tiết trong bài AI coding tools và HIPAA.

Developer nên làm gì khi nhận dự án có PHI?

Khi nhận dự án có khả năng chạm tới PHI, đi theo thứ tự:

1. Xác định dữ liệu nào là ePHI và nó đi qua component nào.
2. Hỏi về BAA: ai ký với ai, và đã có BAA với nhà thầu phụ và các dịch vụ cloud chưa.
3. Kiểm tra mọi truy cập ePHI có được log và log có được bảo vệ không.
4. Kiểm tra mã hóa khi lưu và khi truyền, gồm cả backup.
5. Kiểm tra access control theo minimum necessary.
6. Xác nhận quy trình báo sự cố: business associate báo covered entity không chậm trễ vô lý và chậm nhất 60 ngày kể từ khi phát hiện (§164.410), BAA thường đặt thời hạn ngắn hơn.
7. Kiểm tra backup và khả năng khôi phục cho ePHI.
8. Dùng dữ liệu giả trong môi trường dev và với AI coding tools.

pTrackly hỗ trợ phần kỹ thuật thế nào?

pTrackly không triển khai mã hóa hay logging trong code của bạn; phần đó thuộc về team. pTrackly giữ bằng chứng và nhịp kiểm tra: compliance matrix của framework HIPAA map từng specification tại §164.312 sang control và cho phép ghi lý do, biện pháp thay thế cho addressable specification; evidence task như "review audit log" có tần suất và nhắc 7, 3, 1 ngày trước hạn; access review gom tài khoản và lưu kết quả; Cloud Tests kiểm tra cấu hình AWS (S3, IAM, KMS, CloudTrail…), GCP, Azure và Cloudflare. Xem thêm checklist HIPAA cho công ty phần mềm và HealthTech, HIPAA tracking trong sprint DevOps và HIPAA với pTrackly.

Câu hỏi thường gặp

HIPAA có quy định thời gian timeout session cụ thể không?

Không. Automatic logoff là addressable và quy định không đưa con số; hãy chọn theo rủi ro của từng giao diện và ghi lý do vào tài liệu.

HIPAA có bắt buộc MFA không?

Security Rule hiện hành yêu cầu xác thực người hoặc hệ thống truy cập ePHI tại 45 CFR §164.312(d) nhưng không nêu tên MFA. MFA là cách phổ biến để đáp ứng và thường được khách hàng yêu cầu.

Audit log có phải là required không?

Audit controls là một standard tại §164.312(b) nên phải đáp ứng; quy định không có specification riêng. Review log định kỳ là required theo §164.308(a)(1)(ii)(D).

Dữ liệu test có tên giả nhưng ngày sinh thật có phải ePHI không?

Có thể có. Ngày sinh đầy đủ là một trong 18 nhóm định danh của Safe Harbor tại 45 CFR §164.514(b)(2), nên dữ liệu đó chưa được coi là de-identify nếu đi kèm thông tin sức khỏe.

Không mã hóa ePHI có vi phạm HIPAA không?

Không tự động vi phạm, vì mã hóa là addressable. Nhưng bạn phải có đánh giá ghi lại và biện pháp thay thế tương đương, và dữ liệu không mã hóa bị lộ sẽ phải xét nghĩa vụ báo breach.

Tài liệu tham khảo: 45 CFR §164.312 (Cornell LII) · 45 CFR §164.306 · HHS: Security Rule · NIST SP 800-111