botmingoc
Member
Thiết kế bảo mật cho app.
Không thể nói là app tao 100% vô địch bảo mật vì vỏ quýt dày có móng tay nhọn, tuy nhiên từ những vụ lùm xùm như [thanh niên security researcher của AWS brute force key của app COVID] hay [chuyên gia thaidn hack được rất nhiều app của chú phỉnh],… Mình thấy nên có 1 vài notes trong việc thiết kế bảo mật cho system.
(Security cũng rất rộng nên mình chỉ nói theo góc nhìn từ dev/solution architect theo kinh nghiệm của mình)
Nếu size của cty vài trăm dev đổ lên, nên có 1 security board review: threat model, crypto review, data lưu ở đâu, bảo mật thế nào, có khoá mật mã nào ko,… Những người này là chuyên gia về security: thời gian bạn bỏ công ra ngồi code thì họ cũng bỏ công ra nghiên cứu, kiến thức của họ sẽ rất chuyên sâu => đúng người đúng việc là tiết kiệm thời gian.
Nếu bạn team bé, startup muốn move fast: vậy thì dựa theo những chuẩn đã có, đừng sáng tạo. Ae dev nên theo:
Ví dụ evaluate process:
Bạn có 1 system đơn giản: app mobile và API.
Giờ giữa app và API, để thông tin trao đổi secure, cứ dựa trên https.
Bạn muốn thiết kế user login, protect resource: vậy thì apply Oauth2 vào.
Bạn muốn more secure, Oauth2 token có thể bị đánh cắp từ session này sang -> token binding, chuyển từ Bearer token sang Pop token.
Bạn có những thông tin quan trọng hơn nữa cần bảo mật, lúc này cần phân tích sâu về use cases. Phải thật rõ ràng bạn muốn đạt được điều gì và khả năng setup của hệ thống bạn ntn.
Security ko chỉ làm 1 cái là xong nghỉ luôn. System của bạn phát triển thì security cũng cần được nâng cấp. Nên có lịch định kỳ threat model, protocol security review, scan code,… để đảm bảo an toàn. Mỗi lần nên rotate người, có góc nhìn mới. Nếu ko thì lại: ồ giống lần trc, ko có gì giải tán sớm.
Đấy là cách chỗ mình làm handle security. Ae chém cho vui, đời dev cứ chém là vui.
Không thể nói là app tao 100% vô địch bảo mật vì vỏ quýt dày có móng tay nhọn, tuy nhiên từ những vụ lùm xùm như [thanh niên security researcher của AWS brute force key của app COVID] hay [chuyên gia thaidn hack được rất nhiều app của chú phỉnh],… Mình thấy nên có 1 vài notes trong việc thiết kế bảo mật cho system.
(Security cũng rất rộng nên mình chỉ nói theo góc nhìn từ dev/solution architect theo kinh nghiệm của mình)
Nếu size của cty vài trăm dev đổ lên, nên có 1 security board review: threat model, crypto review, data lưu ở đâu, bảo mật thế nào, có khoá mật mã nào ko,… Những người này là chuyên gia về security: thời gian bạn bỏ công ra ngồi code thì họ cũng bỏ công ra nghiên cứu, kiến thức của họ sẽ rất chuyên sâu => đúng người đúng việc là tiết kiệm thời gian.
Nếu bạn team bé, startup muốn move fast: vậy thì dựa theo những chuẩn đã có, đừng sáng tạo. Ae dev nên theo:
- Về lý thuyết mật mã, NIST công bố rất nhiều tài liệu hữu ích về tiêu chuẩn: symmetric encryption thì khoá phải ít nhất bao nhiêu, RSA key length thế nào, ECC dùng những curve nào…. Nếu đọc sẽ tránh những lỗi ngớ ngẩn như app covid dùng khoá RSA 512 quá ngắn nó brute force 2 tiếng là xong.
- Về protocol, RFC là nguồn tài liệu tuyệt vời. AuthN/AuthZ thế nào (Oauth2), communication between client<->server thế nào (JWS/JWE), rồi cả những tài liệu chi tiết tầng dưới như TLS1.2, 1.3… Để thiết kế tốt hơn, mình phải hiểu rõ hiện tại như thế nào đã (với app thông thường mình nghĩ cứ 99% áp dụng là ngon, app nào chuyên bảo mật thì toàn cao thủ rồi ko phải dạy
) - Về cách implement: lời khuyên là đừng tự implement crypto primitive. Hãy dùng những thư viện có sẵn từ OS (Apple/Google/Microsoft cung cấp rất nhiều từ OS của họ) hoặc các 3rd uy tín (như OpenSSL hoặc tool từ OWASP). Nếu app bạn rất thông thường nhưng muốn thuật toán về crypto OpenSSL ko support, nên đặt câu hỏi ngược lại là mình có thực sự cần không?
- Những tool scan code cũng rất tốt cho review. Nếu có redteam hay pentester thì tốt rồi, nếu không thì cài những tool scan code cho hook vào project trước khi big release cũng được.
Ví dụ evaluate process:
Bạn có 1 system đơn giản: app mobile và API.
Giờ giữa app và API, để thông tin trao đổi secure, cứ dựa trên https.
Bạn muốn thiết kế user login, protect resource: vậy thì apply Oauth2 vào.
Bạn muốn more secure, Oauth2 token có thể bị đánh cắp từ session này sang -> token binding, chuyển từ Bearer token sang Pop token.
Bạn có những thông tin quan trọng hơn nữa cần bảo mật, lúc này cần phân tích sâu về use cases. Phải thật rõ ràng bạn muốn đạt được điều gì và khả năng setup của hệ thống bạn ntn.
- Thông tin ai cũng xem đc nhưng ko ai temper đc?
- Thông tin ko muốn ai xem, chỉ có mình và server?
- Key setup thế nào, pre-shared hay wrap hay key agreement? Ai tạo key, ai giữ key, ai có quyền dùng key…
Security ko chỉ làm 1 cái là xong nghỉ luôn. System của bạn phát triển thì security cũng cần được nâng cấp. Nên có lịch định kỳ threat model, protocol security review, scan code,… để đảm bảo an toàn. Mỗi lần nên rotate người, có góc nhìn mới. Nếu ko thì lại: ồ giống lần trc, ko có gì giải tán sớm.
Đấy là cách chỗ mình làm handle security. Ae chém cho vui, đời dev cứ chém là vui.
Từ việc bảo mật tầng network, đến bảo mật các service, việc tích hợp với 3rd-party.
