MB Trainee- Information Security GRC (Fresher, Intern)

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.

CIA là ba mục tiêu cốt lõi: Confidentiality (bí mật), Integrity (toàn vẹn), Availability (sẵn sàng). Mọi biện pháp bảo mật đều nhằm bảo vệ ít nhất một trong ba.

• Confidentiality: mã hoá dữ liệu khi lưu và truyền, phân quyền theo least privilege, MFA.
• Integrity: hash và chữ ký số, kiểm soát thay đổi, log audit không sửa được.
• Availability: dự phòng, backup, chống DDoS, vá lỗi kịp thời.

Người phỏng vấn muốn nghe: các yếu tố đôi khi xung đột, ví dụ khoá tài khoản sau nhiều lần sai mật khẩu tăng bí mật nhưng có thể bị lạm dụng để làm người dùng thật không đăng nhập được.

Chuẩn hoá là tách dữ liệu để mỗi thông tin chỉ lưu ở một chỗ, tránh dư thừa và sai lệch khi cập nhật.

• 1NF: mỗi ô một giá trị nguyên tử, không lưu danh sách trong một cột.
• 2NF: cột không khoá phụ thuộc vào toàn bộ khoá chính, không chỉ một phần.
• 3NF: cột không khoá không phụ thuộc bắc cầu qua cột không khoá khác.

Denormalize khi đọc nhiều hơn ghi rất nhiều và JOIN trở thành điểm nghẽn: lưu sẵn comment_count trong bảng bài viết, chép customer_name vào đơn hàng để giữ đúng tên tại thời điểm đặt, hoặc dựng bảng báo cáo riêng.

Hay sai: denormalize mà không có cơ chế đồng bộ (trigger, job, event) nên số liệu lệch dần. Hãy nói rõ cái giá phải trả là logic ghi phức tạp hơn.

JOIN quyết định giữ lại những dòng nào khi ghép hai bảng theo điều kiện.

• INNER JOIN: chỉ giữ dòng khớp ở cả hai bảng.
• LEFT JOIN: giữ mọi dòng bảng trái; bảng phải không khớp thì cột thành NULL.
• RIGHT JOIN: ngược lại với LEFT, ít dùng vì có thể đổi chỗ bảng.
• FULL OUTER JOIN: giữ tất cả dòng của cả hai (MySQL không hỗ trợ trực tiếp, phải UNION hai LEFT JOIN).

Ví dụ tìm khách chưa từng đặt hàng:

SELECT c.id, c.name
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

Hay sai: đặt điều kiện lọc bảng phải trong WHERE (vd. WHERE o.status = 'paid') làm LEFT JOIN biến thành INNER JOIN; điều kiện đó phải để trong ON.

INNER JOIN chỉ giữ dòng khớp ở cả hai bảng; LEFT JOIN giữ mọi dòng bảng trái, phía phải không khớp thì NULL; FULL OUTER JOIN giữ tất cả; CROSS JOIN ghép mọi cặp.

Dòng bị nhân bản khi khoá join không duy nhất ở một phía (quan hệ một-nhiều hoặc nhiều-nhiều). Ví dụ join orders với payments khi một đơn có nhiều lần thanh toán, rồi SUM(order_amount) sẽ bị cộng trùng.

• Kiểm tra độ duy nhất của khoá trước khi join.
• Gộp (aggregate) bảng chi tiết trước rồi mới join.

Hay sai: đặt điều kiện lọc bảng phải trong WHERE sau LEFT JOIN, vô tình biến nó thành INNER JOIN; nên đặt trong ON.

Đối xứng dùng một khoá cho cả mã hoá và giải mã (AES), nhanh; bất đối xứng dùng cặp khoá công khai/bí mật (RSA, ECC), dùng cho trao đổi khoá và chữ ký số; hash là hàm một chiều, không giải mã được.

• HTTPS kết hợp cả hai: bất đối xứng để thoả thuận khoá, đối xứng để mã hoá dữ liệu.
• Mật khẩu: lưu bằng hàm hash chậm có salt như Argon2id, bcrypt hoặc scrypt.

Hay sai:

• Lưu mật khẩu bằng MD5/SHA-256 thuần: quá nhanh, dễ bị dò hàng loạt.
• Gọi base64 là "mã hoá".
• Mã hoá mật khẩu (giải ngược được) thay vì hash.

SQL injection xảy ra khi dữ liệu người dùng được ghép thẳng vào câu SQL, khiến dữ liệu bị hiểu thành lệnh. Cách phòng chính là tách dữ liệu khỏi câu lệnh.

// Sai: ghép chuỗi
db.query("SELECT * FROM users WHERE email = '" + email + "'");
// Đúng: tham số hoá
db.query("SELECT * FROM users WHERE email = $1", [email]);

• Dùng prepared statement hoặc ORM đúng cách; cẩn thận với các hàm cho viết raw SQL.
• Tên cột/bảng động thì kiểm tra theo danh sách cho phép.
• Tài khoản DB của ứng dụng chỉ có quyền tối thiểu.
• WAF và SAST là lớp bổ sung, không thay cho code đúng.

XSS là khi script lạ chạy trong trang của bạn trên trình duyệt người dùng; CSRF là khi trang khác lợi dụng phiên đăng nhập của người dùng để gửi request thay họ.

Phòng XSS:

• Escape đầu ra theo ngữ cảnh (framework hiện đại làm mặc định); cẩn thận với dangerouslySetInnerHTML, innerHTML.
• Sanitize HTML do người dùng nhập bằng thư viện uy tín.
• Content-Security-Policy, cookie phiên đặt HttpOnly.

Phòng CSRF:

• Cookie SameSite=Lax hoặc Strict.
• CSRF token cho request thay đổi dữ liệu; kiểm tra header Origin.
• Không dùng GET để thay đổi trạng thái.

Hay sai: nghĩ HTTPS chống được XSS hay CSRF.

Đây là câu mở đầu gần như chắc chắn có. Dùng công thức Hiện tại – Quá khứ – Tương lai, gói trong khoảng 1–2 phút.

• Hiện tại: vị trí, số năm kinh nghiệm, mảng/công nghệ chính.
• Quá khứ: một hai dự án hoặc thành tích liên quan nhất tới vị trí đang tuyển.
• Tương lai: vì sao bạn quan tâm tới vị trí này.

Câu mẫu: "Em là backend developer, khoảng 3 năm kinh nghiệm, chủ yếu làm Java Spring cho hệ thống thanh toán. Ở dự án gần nhất em phụ trách module đối soát và tối ưu các truy vấn báo cáo chạy chậm. Em đang tìm môi trường làm sản phẩm lâu dài để đi sâu hơn về thiết kế hệ thống, nên rất quan tâm tới vị trí này."

Hay sai: kể từ quê quán, trường cấp ba, hoặc đọc lại nguyên CV.