kiến thức [Event tặng Title] Security khi phát triển system

Tôi chỉ thắc mắc ông làm sao cho một đồng chí dev lương 5tr/tháng hiểu cái đống ở trên mà implementation cho nó đúng thôi. Best practices thì có rất rất nhiều, còn làm đúng được hay không, có ra sản phẩm tốt được hay không "mệt lắm"

Mấy cái nói ở #1 chỉ phù hợp với app thực sự cần sec và quan tâm tới sec cũng như có ... nhiều tiền Những startup nay sống mai chết thì chỉ làm được ở một mức tối thiểu thôi

broke.the.rule đã nói:

Giải pháp thì chắc là audit data + alert khi dữ liệu được truy cập. Có mấy cái này thì đám malicious insider sẽ sợ hơn.

Nhấp để mở rộng...

Chính xác, nó là tiêu chuẩn của ISO 27001 với ISO 27017 rồi mà.

Bạn được làm mọi thứ bạn cần để hoàn thành công việc, nhưng nếu bạn làm gì đó khuất tất, sẽ có chế tài xử lý bạn

Cuối tuần đi chơi với vợ con bỏ thớt, sorry anh em

Fire Of Heart đã nói:

Nice!
Có 1 câu hỏi như này cho chủ thớt và anh em chém gió cho vui, với cũng muốn nghe xem cty các bạn handle như nào.
Db của 1 cty thì bao giờ cũng sẽ có 1 số ít nắm quyền super user, ví dụ devops/CTO chẳng hạn.
Bạn làm thế nào để có thể đảm bảo dc với khách hàng, v.v… rằng sẽ hạn chế nhất tình huống những ng nắm account super user này can thiệp ngầm vào DB nhằm mục đích cá nhân?
Đôi khi có những chỉnh sửa nho nhỏ trên 1 record cũng có thể trục lợi hàng ngàn đô rồi. Ng ảnh hưởng trực tiếp sẽ là khách hàng hoặc chính công ty.

Nhấp để mở rộng...

Cái này theo mình hiểu thì là security với DB/DBA. Thực sự mình ko có nhiều kinh nghiệm DB chuyên sâu, thím nào DBA chia sẻ xem

joonkim đã nói:

Phạm trù bảo mật cho 1 ứng dụng khá rộng 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.

Nên bác có thể nói rõ hoặc chia sẻ hơn về mặt bảo mật cho ứng dụng, tạm thời nên giới hạn ở website application nhé.

Ví dụ như em có đọc 1 page github https://github.com/donnemartin/system-design-primer#security


Ví dụ phần Encrypt in transit and at rest. khi triển khai api cho resful như nào, có phần gì cần chú ý hay không ?

Phần dưới này nữa

Nhấp để mở rộng...

Bold: đồng ý
- Encryption in transit: nếu API theo TLS thì mình nghĩ đã được encrypt rồi. TLS mình hiểu sẽ ebstalish keys ở 2 bên bước handshakes, sau đó thì data truyền đi được encrypt.
Nếu app bạn vì đặc thù muốn extra protection (khỏi MITM attack, poisoned CA cert) thì lúc đấy lại cần phân tích tiếp: Ví dụ SSL pinning là một cách để protect against compromised cert root or intermediate CA nhưng rất costly để implement cross-platform: nền tảng không support hoặc nếu có support thì khả năng bạn sẽ phải tự build lại/custom network classes nhiều risks. (trc mình có gặp trường sec team đòi SSL pinning, bảo lại thì ae dev kêu như vạc vì nhiều case nếu có VPN (legit) vào thì connection unstable...)
- Encryption at rest thì với tuỳ client/server và loại data mình nghĩ chiến thuật sẽ khác nhau. Server mình control 100% nên data có thể store raw, hoặc encrypt rồi cho vào db.
Với client-side, thì ví dụ như 1 cái flow: user gõ acc/pwd. gửi server. server trả về profile user + OAuth2 tokens. Bạn muốn lưu ở phía client:
User profile: không cần bảo mật cao, lưu flat file hoặc db mình nghĩ ok.
tokens: bạn muốn bảo mật hơn. lưu ở db sợ ngta chạy root export db mình ra đc -> vậy mình lưu ở OS keychain hoặc tự encrypt. OS keychain thì cái security task đc OS nó làm hộ mình rồi, mình chỉ setup access control là xong. Nếu muốn tự encrypt thì sẽ rắc rối hơn: chọn enc alg, trả lời keys ở đâu ra (server gen, client gen...), bảo mật key như thế nào, cần rotate key ko, cần backup key không...? Nếu key mà client hardcode hoặc key client gen nhưng cuối cùng vẫn lưu ở đâu đó không secure thì thực sự ko có ý nghĩa gì lắm, lưu raw data cho xong....
Loanh quanh cũng chỉ tìm câu trả lời: cái gì trong system bạn tin được, cái gì là source of trust.

• Sanitize all user inputs or any input parameters exposed to user to prevent XSS and SQL injection.
• Use parameterized queries to prevent SQL injection.

=> 2 cái này OWASP họ cung cấp rất đầy đủ, cả tool để scan nữa, chạy cái là ra à.
- Use the principle of least privilege.
=> Cái này là nguyên tắc thiết kế chung chung thôi, cần đến đâu cấp quyền đến đấy. Ví dụ như dev thì ít khi đc quyền vào prod, chỉ đc vào dev/test DB thôi, rồi deploy lên prod thì có devops hay dba họ giúp.

làm sao chống hacker dịch ngược mã nguồn , đọc mã nguồn rồi crack, hack nhỉ

Nhấp để mở rộng...

Cái này mình chịu nha, mình chỉ biết cũng có tool để code obfuscation nhưng mấy ông hacker vẫn quật được hết Code obfuscated xong nhìn nó như mớ giấy lộn, cả nghìn dòng toàn kiểu a.b -> c.d gì đó nhưng vẫn bị crack bt.

Có nhiều loại attack, để chống lại replay attack thì mình nghĩ cách đơn giản nhất là dùng nonce. Nonce chỉ đơn giản là data ngẫu nhiên, được nhúng vào dữ liệu này đảm bảo nó chỉ được dùng một lần. Cách nhúng thì có thể nhét vào payload rồi signature, hoặc include trực tiếp vào encryption algorithm ( các thuật toán hiện đại mình thấy đều yêu cầu có nonce)

MrTux đã nói:

Tôi chỉ thắc mắc ông làm sao cho một đồng chí dev lương 5tr/tháng hiểu cái đống ở trên mà implementation cho nó đúng thôi. Best practices thì có rất rất nhiều, còn làm đúng được hay không, có ra sản phẩm tốt được hay không "mệt lắm"

Mấy cái nói ở #1 chỉ phù hợp với app thực sự cần sec và quan tâm tới sec cũng như có ... nhiều tiền

Những startup nay sống mai chết thì chỉ làm được ở một mức tối thiểu thôi

Nhấp để mở rộng...

Mình chia sẻ ae đọc cho vui thôi, ai thấy hữu ích thì thấy chứ ko bảo nhất định app nào cũng phải thế nọ thế kia đc
Sec cũng hay mà, khối non-startup rất quan trọng. Có rất nhiều nhánh nghề nghiệp trong đó, ae làm crypto research, pentest, red team,... rồi coin củng. Mấy ông btc/eth đẻ ra rất nhiều crypto protocol hay để phục vụ cho crypto-currency.

lan man 1 tý , có cách nào xóa được mấy cái CA status R ko các thím, mấy cái này có phải mặc định thằng mic cài vào máy ko nhỉ, em giả sử nếu em buil 1 con máy từ linux kennel , mà em ko install mấy cái CA này vào thì khi server nó gửi cert cho client làm sao client chứng thực đc cái cert đó nhỉ ?

botmingoc đã nói:

Nếu app bạn vì đặc thù muốn extra protection (khỏi MITM attack, poisoned CA cert) thì lúc đấy lại cần phân tích tiếp: Ví dụ SSL pinning là một cách để protect against compromised cert root or intermediate CA nhưng rất costly để implement cross-platform: nền tảng không support hoặc nếu có support thì khả năng bạn sẽ phải tự build lại/custom network classes nhiều risks. (trc mình có gặp trường sec team đòi SSL pinning, bảo lại thì ae dev kêu như vạc vì nhiều case nếu có VPN (legit) vào thì connection unstable...)

Nhấp để mở rộng...

SSL pinning vẫn bypass dễ dàng được mà bác nhỉ

Em làm dev trước sếp em cũng kêu tụi mày tìm cách giấu API đi được không thì em có tranh luận kêu giấu kiểu gì cũng tìm ra được thôi, chỉ có là đáng công để tìm hay không. Thay vì đó thì thiết kế bảo mật kỹ data dưới backend, kiểm tra user, phân quyền,.. thì hay hơn.

botmingoc đã nói:

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

Nhấp để mở rộng...

Hay quá thím, viết rất đầu tư và bài bản nè.

Fire Of Heart đã nói:

Nice!
Có 1 câu hỏi như này cho chủ thớt và anh em chém gió cho vui, với cũng muốn nghe xem cty các bạn handle như nào.
Db của 1 cty thì bao giờ cũng sẽ có 1 số ít nắm quyền super user, ví dụ devops/CTO chẳng hạn.
Bạn làm thế nào để có thể đảm bảo dc với khách hàng, v.v… rằng sẽ hạn chế nhất tình huống những ng nắm account super user này can thiệp ngầm vào DB nhằm mục đích cá nhân?
Đôi khi có những chỉnh sửa nho nhỏ trên 1 record cũng có thể trục lợi hàng ngàn đô rồi. Ng ảnh hưởng trực tiếp sẽ là khách hàng hoặc chính công ty.

Nhấp để mở rộng...

Hóng lời giải đáp. Em mới vào nghề. Cũng làm nhiều về phần Database/back-end. Nhưng nghĩ mãi ko ra đc cách để làm sao thuyết phục đc Khách hàng tin tưởng khi nhập data vào db của mình.
Nhưng theo hiểu biết non nớt của e thì chắc là nên log lại hết các action insert/change khi trong db trong vòng vài tháng cho tới vài năm.

Mình chưa thử nhưng nhớ là có 1 số DB hỗ trợ tích hợp với HSM, không nhầm là mongo db. Cơ chế là dữ liệu trước khi lưu vào DB sẽ được mã hoá bởi key, lúc đọc ra cũng cần key để giải mã. Key được lưu an toàn trong HSM. Tuy nhiên như vậy sẽ ảnh hưởng nhiều đến performance. Nhớ không nhầm thì mongo db có hỗ trợ thì phải. Tuy nhiên triển khai thì mình chưa gặp bao giờ

via theNEXTvoz for iPhone

Hoặc đơn giản hệ thống phân quyền quản trị ra. Dữ liệu nào sensitive sẽ được mã hoá trước khi lưu vào DB. Key mã hoá có thể:

• Trong HSM: khác với comment trên là thay vì tích hợp thẳng vào engine của DB thì server thực hiện mã hoá/ giải mã.
• File mềm trên server
• PIN của người dùng

Ông quản trị DB không có quyền quản lý HSM/ hoặc không có quyền truy cập key mềm và ngược lại


via theNEXTvoz for iPhone

Fire Of Heart đã nói:

Nice!
Có 1 câu hỏi như này cho chủ thớt và anh em chém gió cho vui, với cũng muốn nghe xem cty các bạn handle như nào.
Db của 1 cty thì bao giờ cũng sẽ có 1 số ít nắm quyền super user, ví dụ devops/CTO chẳng hạn.
Bạn làm thế nào để có thể đảm bảo dc với khách hàng, v.v… rằng sẽ hạn chế nhất tình huống những ng nắm account super user này can thiệp ngầm vào DB nhằm mục đích cá nhân?
Đôi khi có những chỉnh sửa nho nhỏ trên 1 record cũng có thể trục lợi hàng ngàn đô rồi. Ng ảnh hưởng trực tiếp sẽ là khách hàng hoặc chính công ty.

Nhấp để mở rộng...

chém gió tí.

1. vấn đề truy cập db.

• - không cho phép truy cập db từ internet đối với account có quyền quản trị.
• - account quản trị chỉ được phép truy cập từ một hoặc vài địa chỉ IP nội bộ trong công ty và phải thực hiện thông qua mạng công ty, không cho xài VPN cho chắc.
• - máy mà account quản trị kết nối vào phải được monitor đầy đủ, log rõ thời gian login-logout của quản trị viên.

2. về các hành động mà account quản trị được phép thực hiện.

• - các truy vấn/chỉnh sửa mà account quản trị viên thực hiện trên db phải được review và approve bởi cấp có thẩm quyền trong công ty và cả khách hàng nếu cần (nếu mấy ông này chơi xấu thì ggwp) và report lại cho khách hàng chi tiết về thay đổi. Nếu sợ nó múa rìu qua mắt thợ thì khi chỉnh sửa db cần có sự hiện diện của thằng quản lý tại thời điểm đó (tôi nghĩ chắc chả thằng nào làm đâu)
• - tất cả các action trên db phải được ghi log đầy đủ.
• - thực hiện tạo bản sao lưu trước và sau khi chỉnh sửa trên db.

Chặn thì theo em không thể chặn được rồi, vì chặn ở bước này thì nó có thể leak dữ liệu bước khác.
Trước có nghe anh thaidn bảo bên google người ta đầu tin là tin tưởng nhân sự của mình, tiếp theo đó mọi action đều được ghi lại và tuỳ mức độ để cảnh báo.

Ghi log và cảnh báo là cách làm hiệu quả nhất vì không hệ thống nào an toàn tuyệt đối. Giống việc bảo vệ nhà vậy, ngoài xây tường rào cao thì nên có thêm camera, cảm biến các kiểu.

Các hệ thống ghi log và cảnh báo này thì khi có action bất thường như access trực tiếp vào DB thì sẽ cảnh báo.

sigel đã nói:

chém gió tí.

1. vấn đề truy cập db.

• - không cho phép truy cập db từ internet đối với account có quyền quản trị.
• - account quản trị chỉ được phép truy cập từ một hoặc vài địa chỉ IP nội bộ trong công ty và phải thực hiện thông qua mạng công ty, không cho xài VPN cho chắc.
• - máy mà account quản trị kết nối vào phải được monitor đầy đủ, log rõ thời gian login-logout của quản trị viên.

2. về các hành động mà account quản trị được phép thực hiện.

• - các truy vấn/chỉnh sửa mà account quản trị viên thực hiện trên db phải được review và approve bởi cấp có thẩm quyền trong công ty và cả khách hàng nếu cần (nếu mấy ông này chơi xấu thì ggwp) và report lại cho khách hàng chi tiết về thay đổi. Nếu sợ nó múa rìu qua mắt thợ thì khi chỉnh sửa db cần có sự hiện diện của thằng quản lý tại thời điểm đó (tôi nghĩ chắc chả thằng nào làm đâu)
• - tất cả các action trên db phải được ghi log đầy đủ.
• - thực hiện tạo bản sao lưu trước và sau khi chỉnh sửa trên db.

Nhấp để mở rộng...

Để tôi phân tích
01 - Truy cập DB

- Không cho phép truy cập DB từ internet với account người quản trị? Các account không phải quản trị thì thả cửa? Thế SaaS BI muốn access thì làm thế nào? Phần này nó phụ thuộc vào business. Secure nhất là dùng One Time Password cho các lần access DB khác nhau và tự động expired, IAM role .v.v.

- Việc limit access ở phía network cho dù là internal hay VPN về bản chất risk là như nhau trong môi trường hybird hay cloud.

- Việc monitoring nó phải ở phía server, chứ chả nhẽ xóa hết logging/audit logs ở machine quản trị là mất hết dấu vết?

02 - Bạn focus chủ yếu vào process để reduce deployment risk thì đúng hơn. Những action của bạn như "cấp có thẩm quyền" hay "có sự hiện diện" về cơ bản không có gì khác nhau nếu người giám sát không hiểu người thực hiện đang làm gì. Quy trình vẽ ra vòng vèo để ... làm chậm quá trình thực thi chứ không improve security rõ ràng

P/S: Quan điểm trên là quan điểm cá nhân để thảo luận, vui lòng không công kích cá nhân.

Fire Of Heart đã nói:

à yeah, cái mình nói nó ko phải là security cho API mà là cho hệ thống. Đọc bài của chủ thớt có đoạn phía dưới cũng liên quan nên tiện hỏi luôn.

Cam kết và policy là 1 chuyện thôi, mình có thể triển khai các biện pháp kỹ thuật thêm, thì khách hàng mới tin dc. Thực ra với super user thì rất khó chặn, chỉ là làm nó khó hơn, có thể ko riêng với super user mà với dev cầm account có permission insert/update chẳng hạn.
Riêng chặn dev táy máy thôi cũng nhiều cái có thể làm. T*k* cũng từng đuổi 1 ông dev trộm coupon rồi (nghe đồn)

Nhấp để mở rộng...

về vấn đề toàn vẹn dữ liệu này thì smart contract là phương án tuyệt vời nhất, chỉ cần số node đủ nhiều để đảm bảo ko CTO/super user ko control được hơn 50% số node

còn nếu như đang nói đến một hệ thống đã chạy hoặc ko thể sử dụng smart contract thì có thể hash record mỗi lần có thay đổi, gửi hash này kèm record id sang bên phía khách hàng hoặc 3rd party độc lập nào đó store. Khách hàng có thể chạy audit định kỳ (daily, weekly...)

Fire Of Heart đã nói:

à yeah, cái mình nói nó ko phải là security cho API mà là cho hệ thống. Đọc bài của chủ thớt có đoạn phía dưới cũng liên quan nên tiện hỏi luôn.

Cam kết và policy là 1 chuyện thôi, mình có thể triển khai các biện pháp kỹ thuật thêm, thì khách hàng mới tin dc. Thực ra với super user thì rất khó chặn, chỉ là làm nó khó hơn, có thể ko riêng với super user mà với dev cầm account có permission insert/update chẳng hạn.
Riêng chặn dev táy máy thôi cũng nhiều cái có thể làm. T*k* cũng từng đuổi 1 ông dev trộm coupon rồi (nghe đồn)

Nhấp để mở rộng...

Ah trước tơ có làm cái hệ thống hạn chế quyền truy cập của nhân viên access vào app, db, aws, rds theo yêu cầu client. Đại khái là ai muốn vào các hệ thống trên. Phải vào hê thông cấp quyền trước. Đăng ký thời gian vào và ra, max là 8h. System sẽ auto grant quyền và remove quyền truy cập. Bach chạy 5p một lần để check. Như vậy nếu có lỗi, leak gì sẽ biết được ai làm

Sent using vozFApp

botmingoc đã nói:

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

Nhấp để mở rộng...

Anh em làm quen, giao lưu cái nhỉ.

hừm bác thớt có vẻ chỉ nói về security về app/db các thứ
vậy các protocol network access chưa thấy bác theard chỉ đến, chưa đề cập vấn đề access control and access management ?

design security, có align với well architect framework hoặc blue architecture...

Các bác hay xử lý phân quyền cho user như thế nào? Có nên làm riêng 1 service chỉ để xác thực và phân quyền k?