Từ khi nào doanh thu với security đi cùng với nhau vậy
. Security là cái chỉ khi nào incident xảy ra nó mới thể hiện thôi. Nói chả đâu xa 2 công ty có văn phòng ở VN như Quoine hay Sky Mavis, doanh thu cũng cả vài chục triệu 1 tháng, dính 1 2 security incidents là đủ để sập cả công ty. Sky Mavis còn hên là có nhà đầu tư đỡ hộ cho chứ không cũng sập như Quoine . Còn ví dụ chiếm quyền sao thì đọc comment nãy của tôi ngay ở phía trên đó.
thì t đang def lại ý này của a thôiTừ khi nào doanh thu với security đi cùng với nhau vậy
Đương nhiên nó bảo mật hơn vì nó có thêm 1 lớp bảo mật
. Cái tôi nói chả phải lý thuyết, công ty tôi đang làm nó không chỉ authen mà có cả authorization cho service to service communication, không có thì đừng có mơ mà gọi được service khác.
Ví dụ attacker/insider vào được service A thì attacker đó cũng không lấy được dữ liệu ở service B. Nó làm giảm blast radius của một security incident.Đã vào được mạng nội bộ rồi thì nó còn thiếu quyền gì nữa mà sợ mấy cái auth token
... Nãy giờ mình nói lý thuyết nhiều quá giờ ví dụ thật nè
Chính xác, vậy nên mới có nguyên lý defense in depth, để khi 1 layer bị lọt qua thì vẫn còn vài layer khác để chặn lại.
Devops nó có full quyền rồi thì bạn prevent kiểu gì?
Devops có full quyền là ngay từ đầu làm sai về security. Mọi thay đồi liên quan tới infrastructure đều phải được tự động hoá và thông qua review (gitops/tools). Trong trường hợp khẩn cấp mới được cho phép can thiệp vào hệ thống manual. Lúc đó sẽ có cơ chế gọi là break glass, cho phép operator vượt rào. Ngay cả khi break glass cũng phải có approval của người thứ 2.
Cảm ơn thím tôi không có nhu cầu, tôi đã từng cãi nhau chán với team security về mấy vụ này rồi. Cứ mỗi api qua lại là phải chạy 1 nùi security check rồi lại dồn hết qua con auth service. Đến giờ cao điểm là bottle neck rồi phải tra 1 nùi log prod để giải thích cho các cốp lý do.
Thiết kế có vấn đề lại đổ cho team security, rồi lại bảo không có nhu cầu tìm hiểu rồi sau này lại thiết kế sai tiếp
. Ngay cả request từ external client lên, nếu làm stateless auth cũng không bao giờ gặp phải chuyện bottleneck ở auth service cả, vì token nó sẽ valid trong 1 khoảng thời gian tương đối dài 1-15 phút. Tương tự như vậy với service to service communication. Thậm chí cách đơn giản nhất để đảm bảo authen trong service to service communication secure là mutual tls nó cũng chả cần đụng tới service thứ 3.
Hoàn toàn đồng ý, nãy giờ mình chỉ trả lời vì có bác khuyên là "không nên" có authentication trong service vì dư thừa, hay có bác bảo là làm làm gì cho phức tạp đằng nào cũng có lỗ hổng khác.
Đúng rồi bác, chẳng qua là chưa có điều kiện làm thôi chứ về bản chất nội bộ cũng cần bảo vệ. Giờ việc tấn công ngang hàng nhiều không bảo vệ thì service team khác lỗi bị tấn công thì gọi thông tuông qua team mình cũng toang.
Chuẩn r bác ơi, em làm trong domain fintech, các hệ thống internal gọi lẫn nhau vẫn phải có cơ chế Auth
AuthN/AuthZ trên từng service/cluster là bình thường và nên làm chỉ có điều cty có chịu đầu tư đến mức nào hay không thôi.
