Senior Security Consultant (Offensive)

Ý 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.

Theo vòng đời ứng phó sự cố: chuẩn bị, phát hiện và phân tích, ngăn chặn, loại bỏ, khôi phục, rút kinh nghiệm.

1. Xác nhận và báo cáo theo quy trình, lập nhóm xử lý, ghi mốc thời gian.
2. Ngăn chặn: cô lập máy khỏi mạng nhưng không tắt nguồn vội, để giữ bằng chứng trong RAM.
3. Thu thập bằng chứng: snapshot đĩa, bộ nhớ, log; giữ chuỗi bảo quản.
4. Xác định phạm vi: tài khoản, máy khác, dữ liệu bị ảnh hưởng.
5. Loại bỏ và khôi phục: dựng lại từ image sạch, đổi toàn bộ credential liên quan, vá lỗ hổng gốc.
6. Sau sự cố: báo cáo, bổ sung rule phát hiện; thông báo theo nghĩa vụ pháp lý nếu lộ dữ liệu cá nhân.

Hay sai: chỉ xoá mã độc rồi dùng tiếp máy đó.

Zero Trust bỏ giả định "ở trong mạng nội bộ là tin cậy": mọi truy cập đều được xác thực, kiểm tra thiết bị và cấp quyền tối thiểu theo từng ứng dụng.

Lộ trình thực tế:

• Tập trung danh tính (SSO), bắt buộc MFA, ưu tiên loại chống phishing (passkey, FIDO2).
• Kiểm kê tài sản và ứng dụng, phân loại dữ liệu.
• Kiểm tra trạng thái thiết bị (đã mã hoá, đã vá, có EDR) trước khi cho truy cập.
• Thay VPN toàn mạng bằng truy cập theo từng ứng dụng qua access proxy.
• Phân đoạn mạng để hạn chế di chuyển ngang.
• Ghi log mọi truy cập và giám sát liên tục.

Người phỏng vấn muốn nghe: Zero Trust là chiến lược làm dần, không phải mua một sản phẩm.

asyncio chạy nhiều coroutine trên một thread. Khi coroutine gặp await một thao tác I/O, nó nhường quyền cho event loop chạy coroutine khác. Đây là đa nhiệm hợp tác: coroutine nào không await thì chiếm luôn cả loop.

Trong FastAPI:

• async def khi mọi thứ bên trong đều async (httpx.AsyncClient, driver DB async).
• def khi dùng thư viện blocking (requests, ORM đồng bộ). FastAPI sẽ chạy hàm này trong threadpool, nên không chặn loop.
• Gọi song song: await asyncio.gather(fetch_a(), fetch_b()).

Hay sai: viết async def rồi gọi requests.get() hoặc time.sleep() bên trong. Cả server đứng hình trong lúc chờ. Nếu buộc phải gọi code blocking, dùng await asyncio.to_thread(func).

Người phỏng vấn muốn nghe: async tăng khả năng xử lý đồng thời cho I/O, không làm code CPU nhanh hơn.

CPython dùng reference counting: object bị giải phóng ngay khi số tham chiếu về 0. Bộ thu gom gc chạy thêm để dọn các vòng tham chiếu (A trỏ B, B trỏ A).

Nguyên nhân leak hay gặp:

• Cache toàn cục (dict, lru_cache không giới hạn) chỉ thêm không xoá.
• Biến ở module hoặc class tích luỹ dữ liệu qua các request.
• Đọc cả file hay cả queryset lớn vào bộ nhớ thay vì xử lý theo lô.
• Extension C giữ bộ nhớ ngoài tầm GC.

Cách điều tra:

• tracemalloc: chụp snapshot hai thời điểm rồi so sánh dòng code cấp phát nhiều nhất.
• Theo dõi RSS theo thời gian, thử tái hiện với một loại request.
• Giải pháp tạm: cấu hình worker tự khởi động lại sau N request (Gunicorn max_requests, Celery max_tasks_per_child).

Người phỏng vấn muốn nghe: bạn đo trước khi đoán, và biết giải pháp tạm không thay cho việc tìm nguyên nhân.

Từ Go 1.18, hàm và kiểu có thể nhận type parameter với ràng buộc (constraint):

func Map[T, U any](in []T, f func(T) U) []U {
    out := make([]U, 0, len(in))
    for _, v := range in {
        out = append(out, f(v))
    }
    return out
}

• Constraint có thể là any, comparable, cmp.Ordered, hoặc interface tự định nghĩa chứa tập kiểu (~int | ~float64).
• Thư viện chuẩn đã có các package generic như slices và maps.

Khi nào dùng:

• Generics: cấu trúc dữ liệu và hàm tiện ích làm việc giống hệt nhau với nhiều kiểu (cache, set, hàm lọc, phân trang).
• Interface: khi cần hành vi khác nhau cho từng kiểu (lưu vào DB hay vào file, nhiều cổng thanh toán).

Hay sai: generic hoá mọi thứ ngay từ đầu. Code Go chuộng đơn giản; hãy viết cụ thể trước, khi có hai ba chỗ lặp lại thật sự thì mới trích generic.

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.

Cho thấy bạn có cách làm cụ thể, không chỉ nói "em chịu được áp lực".

• Chia nhỏ việc, ưu tiên phần quan trọng nhất cho mục tiêu.
• Báo sớm cho lead/PM nếu thấy không kịp, đề xuất cắt phạm vi hoặc xin hỗ trợ.
• Giữ chất lượng ở phần cốt lõi; ghi lại nợ kỹ thuật để xử lý sau.
• Giữ bình tĩnh, giao tiếp ngắn gọn, rõ ràng với team.

Câu mẫu theo STAR: "Trước buổi demo cho khách, team phát hiện lỗi tích hợp chỉ còn hai ngày. Em liệt kê các phần bị ảnh hưởng, cùng PM chọn luồng nào bắt buộc phải chạy cho demo, phần còn lại hẹn bàn giao tuần sau. Demo diễn ra suôn sẻ và khách đồng ý với lịch mới."

Hay sai: khoe thức trắng nhiều đêm. Người phỏng vấn muốn thấy bạn quản lý được áp lực, không chỉ chịu đựng.