Senior Data Security - Data Division

Phần lớn sự cố cloud đến từ cấu hình sai và quản lý danh tính lỏng lẻo, không phải lỗ hổng của nhà cung cấp.

Lỗi nguy hiểm hay gặp:

• Bucket/storage để public, database mở ra Internet.
• Access key dài hạn bị lộ, quyền quá rộng.
• Tắt hoặc không bật log audit.

Biện pháp:

• IAM least privilege, ưu tiên role và credential ngắn hạn; MFA cho mọi người.
• Guardrail cấp tổ chức chặn cấu hình nguy hiểm.
• Bật log audit, đưa vào SIEM; dùng công cụ CSPM để phát hiện cấu hình sai liên tục.
• Mã hoá mặc định, quản lý khoá tập trung.
• Hạ tầng qua IaC có quét và review.

Người phỏng vấn muốn nghe: nắm mô hình trách nhiệm chung giữa bạn và nhà cung cấp.

Ưu tiên theo rủi ro: chặn những con đường tấn công phổ biến nhất với chi phí thấp nhất trước.

Thứ tự hợp lý:

1. Kiểm kê tài sản và dữ liệu quan trọng: không biết có gì thì không bảo vệ được.
2. MFA cho email, VPN, tài khoản quản trị, cloud.
3. Quản lý bản vá, nhất là hệ thống lộ ra Internet.
4. Backup tách rời, có diễn tập khôi phục.
5. EDR trên máy trạm và server, log tập trung.
6. Đào tạo nhận diện phishing, quy trình báo cáo dễ dàng.

Đo lường: tỷ lệ tài khoản có MFA, thời gian vá lỗ hổng nghiêm trọng, thời gian phát hiện và xử lý sự cố, kết quả diễn tập.

Người phỏng vấn muốn nghe: nói được ngôn ngữ rủi ro kinh doanh với ban lãnh đạo.

Authentication trả lời "bạn là ai"; authorization trả lời "bạn được làm gì". Lỗi phân quyền (Broken Access Control) đứng đầu OWASP Top 10 trong các bản gần đây.

Lỗi hay gặp:

• IDOR: đổi /orders/123 thành /orders/124 xem được đơn người khác vì server không kiểm tra chủ sở hữu.
• Chỉ ẩn nút trên giao diện mà API vẫn cho gọi.
• Tin vào role gửi từ client.

Cách phòng:

• Kiểm tra quyền ở server cho mọi request, mặc định từ chối.
• Tập trung logic phân quyền vào một chỗ (middleware, policy).
• Viết test cho trường hợp người dùng A truy cập dữ liệu của B.

Không kết luận chỉ vì con số cao hơn; cần kiểm tra thiết kế thí nghiệm và ý nghĩa thống kê.

• Chỉ số chính và cỡ mẫu phải được định trước; không nhìn kết quả liên tục rồi dừng khi thấy đẹp (peeking).
• Kiểm tra sample ratio mismatch: tỷ lệ chia nhóm thực tế có khớp thiết kế không.
• Xem khoảng tin cậy và p-value, không chỉ chênh lệch trung bình.
• Chạy đủ chu kỳ (ít nhất trọn tuần) để tránh hiệu ứng ngày trong tuần, hiệu ứng mới lạ.
• Kiểm tra chỉ số bảo vệ (guardrail): doanh thu, tỷ lệ huỷ, tốc độ trang.
• Cẩn thận khi cắt quá nhiều phân khúc: dễ có kết quả "có ý nghĩa" do ngẫu nhiên.

Người phỏng vấn muốn nghe: phân biệt ý nghĩa thống kê với ý nghĩa kinh doanh.

Star schema là mô hình dữ liệu cho phân tích: một bảng fact ở giữa nối với nhiều bảng dimension xung quanh, giúp truy vấn đơn giản và nhanh.

• Fact: ghi các sự kiện đo đếm được (đơn hàng, lượt xem), chứa số đo (số tiền, số lượng) và khoá ngoại tới dimension. Thường rất nhiều dòng.
• Dimension: mô tả ngữ cảnh (khách hàng, sản phẩm, ngày, cửa hàng), ít dòng, nhiều cột thuộc tính.
• Phải xác định rõ grain: mỗi dòng fact là gì (một đơn hay một dòng sản phẩm trong đơn).

Hay sai: trộn nhiều grain trong một bảng fact, dẫn đến cộng trùng khi tổng hợp.

JWT là token tự chứa thông tin, server kiểm tra bằng chữ ký mà không cần tra DB; điểm yếu là khó thu hồi trước khi hết hạn.

• Luôn kiểm tra chữ ký với thuật toán cố định phía server; từ chối alg: none.
• Kiểm tra exp, iss, aud.
• Access token sống ngắn (vài phút), kèm refresh token có thể thu hồi và xoay vòng.
• Payload chỉ base64, ai cũng đọc được: không chứa dữ liệu nhạy cảm.
• Trên trình duyệt, cân nhắc cookie HttpOnly thay vì localStorage để giảm hậu quả nếu có XSS.
• Khoá ký đủ mạnh, quản lý trong secret manager.

Người phỏng vấn muốn nghe: hiểu đánh đổi giữa JWT và session lưu phía server.

SIEM thu thập log từ nhiều nguồn (firewall, endpoint, server, cloud, AD), chuẩn hoá, tương quan và sinh alert theo rule hoặc phát hiện bất thường.

Quy trình xử lý alert:

1. Triage: đọc alert, xác định tài sản và người dùng liên quan, mức độ quan trọng.
2. Điều tra: đối chiếu log xung quanh thời điểm, tra IOC (IP, hash, domain) với threat intel.
3. Kết luận: dương tính thật hay giả; ghi lại bằng chứng.
4. Leo thang theo playbook nếu là sự cố thật.
5. Tinh chỉnh rule nếu là báo động giả lặp lại.

Người phỏng vấn muốn nghe: ghi chép đầy đủ và biết khi nào cần leo thang thay vì tự xử lý.

Ý chính là "shift left": phát hiện lỗi sớm, tự động trong pipeline, nhưng không làm chậm team quá mức.

• Thiết kế: threat modeling cho tính năng nhạy cảm (thanh toán, đăng nhập).
• Code: SAST, quét secret ở pre-commit và CI.
• Phụ thuộc: SCA quét thư viện có lỗ hổng, cập nhật tự động; tạo SBOM.
• Build: quét image container, ký artifact.
• Chạy thử: DAST trên staging.
• Hạ tầng: quét IaC tìm cấu hình sai.

Chặn build chỉ với lỗi mức cao có thể khai thác; lỗi khác đưa vào backlog có hạn xử lý.

Hay sai: bật mọi công cụ với ngưỡng gắt, dev ngập báo động giả và tìm cách tắt.

SCD là cách xử lý khi thuộc tính của dimension thay đổi theo thời gian, ví dụ khách hàng chuyển thành phố hoặc đổi hạng thành viên.

• Type 1: ghi đè giá trị cũ. Đơn giản nhưng mất lịch sử; báo cáo quá khứ hiển thị theo giá trị mới.
• Type 2: thêm dòng mới cho mỗi thay đổi, kèm valid_from, valid_to, is_current và surrogate key. Giữ được lịch sử, fact trỏ đúng phiên bản tại thời điểm phát sinh.

Chọn Type 2 khi nghiệp vụ cần phân tích theo trạng thái lúc xảy ra (doanh thu theo hạng khách hàng lúc mua).

Hay sai: join fact với dimension Type 2 mà quên điều kiện thời gian hoặc is_current, làm nhân bản dòng.

Cho thấy bạn tách góp ý khỏi cảm xúc cá nhân và biến nó thành hành động.

• Lắng nghe hết, hỏi lại để hiểu ví dụ cụ thể và kỳ vọng.
• Cảm ơn, kể cả khi chưa đồng ý hoàn toàn; nếu có góc nhìn khác, trao đổi bằng thông tin, không phòng thủ.
• Lên kế hoạch cải thiện và chủ động xin phản hồi lại sau một thời gian.

Câu mẫu: "Có lần lead góp ý code review của em quá dài, khó review. Lúc đầu em hơi chột dạ, nhưng em hỏi anh muốn chia thế nào cho dễ. Từ đó em tách pull request nhỏ theo từng thay đổi, thời gian review của team giảm hẳn và em cũng ít bị yêu cầu sửa lại hơn."

Hay sai: nói "em luôn vui vẻ đón nhận mọi góp ý" mà không có ví dụ.